+Technology Lifecycle Management
---+Stable Versions
---+Removal of Previous Versions

Technology Lifecycle Management

Description

Mechanisms exist to manage the usable lifecycles of Technology Assets, Applications and/or Services (TAAS).

Possible Solutions & Considerations

Micro-Small Business (<10 staff) / BLS Firm Size Classes 1-2

∙ Computer Lifecycle Program (CLP)
∙ IT Asset Management (ITAM) program
∙ Defined Mean Time to Failure (MTTF) for critical assets

Small Business (10-49 staff) / BLS Firm Size Classes 3-4

∙ Computer Lifecycle Program (CLP)
∙ IT Asset Management (ITAM) program
∙ Defined Mean Time to Failure (MTTF) for critical assets

Medium Business (50-249 staff) / BLS Firm Size Classes 5-6

∙ Computer Lifecycle Program (CLP)
∙ IT Asset Management (ITAM) program
∙ Defined Mean Time to Failure (MTTF) for critical assets

Large Business (250-999 staff) / BLS Firm Size Classes 7-8

∙ Computer Lifecycle Program (CLP)
∙ IT Asset Management (ITAM) program
∙ Defined Mean Time to Failure (MTTF) for critical assets

Enterprise (> 1,000 staff) / BLS Firm Size Class 9

∙ Computer Lifecycle Program (CLP)
∙ IT Asset Management (ITAM) program
∙ Defined Mean Time to Failure (MTTF) for critical assets

SCR-CMM

Level 0 Not Performed

Practices are non-existent, based on the inability to demonstrate an implemented and operational capability. A reasonable person would conclude the control is not being performed.

Level 1 Performed Informally

Secure Engineering & Architecture (SEA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:
▪ Policies, standards & procedures associated with SEA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.
▪ Security engineering-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.
▪ IT and/or cybersecurity personnel use an informal process to design, build and maintain secure, compliant and resilient solutions.

Level 2 Planned Tracked

Secure Engineering & Architecture (SEA) capabilities are requirements-driven, but are not standardized across the entity (e.g., local/regional level consistency). Capability criteria associated with this control reasonably expect the following criteria to exist:
▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity.
▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are documented and maintained by process owners.
▪ IT and/or cybersecurity personnel work with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with SEA domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).
▪ Secure engineering and architecture-related controls are primarily administrative and preventative in nature (e.g., policies, standards and procedures & guidelines).
▪ Secure engineering and architecture management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.
▪ IT and/or cybersecurity personnel define entity-specific secure engineering practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the entity's TAASD.
▪ IT and/or cybersecurity personnel align secure engineering practices with the entity's broader IT architecture practices.
▪ IT and/or cybersecurity personnel use secure engineering practices to influence Secure Baseline Configurations (SBC).

Level 3 Well Defined

Asset Management (AST) capabilities are standardized across the entity for applicability to People, Processes, Technologies, Data and/or Facilities (PPTDF) to ensure consistency for Technology Assets, Applications, Services and/or Data (TAASD). Capability criteria associated with this control reasonably expect the following criteria to exist:
▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.
▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are well-documented and kept current by process owners.
▪ An IT Asset Management (ITAM) team, or similar function, is appropriately staffed and supported to implement and maintain AST domain capabilities.
▪ Technology is leveraged to enhance the efficiency and accuracy of ITAM operations (e.g., ITAM platform, (e.g., Configuration Management Database (CMBD) Asset Management solution).
▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, works with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with AST domain capabilities to address Minimum Compliance Requirements (MCR) (e.g., applicable statutory, regulatory and/or contractual requirements) and Discretionary Security Requirements (DSR) (e.g., entity-required controls).
▪ An implemented and operational capability exists to manage the usable lifecycles of TAAS.

Level 4 Quantitatively Controlled

Secure Engineering & Architecture (SEA) capabilities, in addition to being standardized across the entity and centrally managed to ensure consistency across Technology Assets, Applications, Services and/or Data (TAASD), efforts are metrics driven to provide sufficient insight for decision makers to predict optimal performance, ensure continued operations and/or identify areas for improvement. Capability criteria associated with this control reasonably expect the following criteria to exist:
▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.
▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).
▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).
▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.
▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).
▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.
▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.

Level 5 Continuously Improving

Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:
▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control.
▪ Level 5 capabilities should be considered “world-class” where the control builds on Level 4 capabilities, but are continuously improving through Artificial Intelligence (AI) and/or Machine Learning (ML) technologies.
▪ While it may be possible to develop responsive capabilities for this control through the use of AI and/or ML technologies, the criteria would be organization-specific to define.

1. Ħarsa ġenerali

Stable Versions

Description

Mechanisms exist to install the latest stable version of any software and/or security-related updates on all applicable systems.

Possible Solutions & Considerations

Micro-Small Business (<10 staff) / BLS Firm Size Classes 1-2

∙ Use stable/supported versions of software

Small Business (10-49 staff) / BLS Firm Size Classes 3-4

∙ Policy requiring use of vendor-supported software versions

Medium Business (50-249 staff) / BLS Firm Size Classes 5-6

∙ Formal software lifecycle policy
∙ Prohibition of unsupported/EOL software

Large Business (250-999 staff) / BLS Firm Size Classes 7-8

∙ Enterprise software lifecycle management
∙ Automated detection of EOL/unsupported software

Enterprise (> 1,000 staff) / BLS Firm Size Class 9

∙ Enterprise software lifecycle management platform
∙ Automated EOL detection (e.g., CSAM, Flexera)
∙ Remediation workflows for EOL software

SCR-CMM

Level 0 Not Performed

Practices are non-existent, based on the inability to demonstrate an implemented and operational capability. A reasonable person would conclude the control is not being performed.

Level 1 Performed Informally

Vulnerability & Patch Management (VPM) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:
▪ Policies, standards & procedures associated with VPM domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.
▪ Attack Surface Management (ASM)-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.

Level 2 Planned Tracked

Vulnerability & Patch Management (VPM) capabilities are requirements-driven, but are not standardized across the entity (e.g., local/regional level consistency). Capability criteria associated with this control reasonably expect the following criteria to exist:
▪ Policies and standards associated with VPM domain capabilities are formally documented and centrally-managed by the entity.
▪ Standardized Operating Procedures (SOP) associated with VPM domain capabilities are documented and maintained by process owners.
▪ IT and/or cybersecurity personnel work with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with VPM domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).
▪ Vulnerability management-related controls are primarily administrative and preventative in nature (e.g., policies, standards and procedures & guidelines).
▪ Vulnerability management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.

Level 3 Well Defined

Asset Management (AST) capabilities are standardized across the entity for applicability to People, Processes, Technologies, Data and/or Facilities (PPTDF) to ensure consistency for Technology Assets, Applications, Services and/or Data (TAASD). Capability criteria associated with this control reasonably expect the following criteria to exist:
▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.
▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are well-documented and kept current by process owners.
▪ An IT Asset Management (ITAM) team, or similar function, is appropriately staffed and supported to implement and maintain AST domain capabilities.
▪ Technology is leveraged to enhance the efficiency and accuracy of ITAM operations (e.g., ITAM platform, (e.g., Configuration Management Database (CMBD) Asset Management solution).
▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, works with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with AST domain capabilities to address Minimum Compliance Requirements (MCR) (e.g., applicable statutory, regulatory and/or contractual requirements) and Discretionary Security Requirements (DSR) (e.g., entity-required controls).
▪ An implemented and operational capability exists to install the latest stable version of any software and/or security-related updates on all applicable systems.

Level 4 Quantitatively Controlled

Vulnerability & Patch Management (VPM) capabilities, in addition to being standardized across the entity and centrally managed to ensure consistency across Technology Assets, Applications, Services and/or Data (TAASD), efforts are metrics driven to provide sufficient insight for decision makers to predict optimal performance, ensure continued operations and/or identify areas for improvement. Capability criteria associated with this control reasonably expect the following criteria to exist:
▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.
▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).
▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).
▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.
▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).
▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.
▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.

Level 5 Continuously Improving

Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:
▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control.
▪ Level 5 capabilities should be considered “world-class” where the control builds on Level 4 capabilities, but are continuously improving through Artificial Intelligence (AI) and/or Machine Learning (ML) technologies.
▪ While it may be possible to develop responsive capabilities for this control through the use of AI and/or ML technologies, the criteria would be organization-specific to define.
Removal of Previous Versions

Description

Mechanisms exist to remove old versions of software and firmware components after updated versions have been installed.

Possible Solutions & Considerations

Micro-Small Business (<10 staff) / BLS Firm Size Classes 1-2

∙ Remove old versions of software when updating

Small Business (10-49 staff) / BLS Firm Size Classes 3-4

∙ Policy requiring removal of previous software versions after update

Medium Business (50-249 staff) / BLS Firm Size Classes 5-6

∙ Formal previous version removal process and verification

Large Business (250-999 staff) / BLS Firm Size Classes 7-8

∙ Enterprise software version management
∙ Automated detection of old versions

Enterprise (> 1,000 staff) / BLS Firm Size Class 9

∙ Enterprise software lifecycle management platform
∙ Automated previous version detection and removal

SCR-CMM

Level 0 Not Performed

Practices are non-existent, based on the inability to demonstrate an implemented and operational capability. A reasonable person would conclude the control is not being performed.

Level 1 Performed Informally

Vulnerability & Patch Management (VPM) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:
▪ Policies, standards & procedures associated with VPM domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.
▪ Attack Surface Management (ASM)-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.

Level 2 Planned Tracked

Vulnerability & Patch Management (VPM) capabilities are requirements-driven, but are not standardized across the entity (e.g., local/regional level consistency). Capability criteria associated with this control reasonably expect the following criteria to exist:
▪ Policies and standards associated with VPM domain capabilities are formally documented and centrally-managed by the entity.
▪ Standardized Operating Procedures (SOP) associated with VPM domain capabilities are documented and maintained by process owners.
▪ IT and/or cybersecurity personnel work with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with VPM domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).
▪ Vulnerability management-related controls are primarily administrative and preventative in nature (e.g., policies, standards and procedures & guidelines).
▪ Vulnerability management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.

Level 3 Well Defined

Asset Management (AST) capabilities are standardized across the entity for applicability to People, Processes, Technologies, Data and/or Facilities (PPTDF) to ensure consistency for Technology Assets, Applications, Services and/or Data (TAASD). Capability criteria associated with this control reasonably expect the following criteria to exist:
▪ Policies and standards associated with AST domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.
▪ Standardized Operating Procedures (SOP) associated with AST domain capabilities are well-documented and kept current by process owners.
▪ An IT Asset Management (ITAM) team, or similar function, is appropriately staffed and supported to implement and maintain AST domain capabilities.
▪ Technology is leveraged to enhance the efficiency and accuracy of ITAM operations (e.g., ITAM platform, (e.g., Configuration Management Database (CMBD) Asset Management solution).
▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, works with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with AST domain capabilities to address Minimum Compliance Requirements (MCR) (e.g., applicable statutory, regulatory and/or contractual requirements) and Discretionary Security Requirements (DSR) (e.g., entity-required controls).
▪ An implemented and operational capability exists to remove old versions of software and firmware components after updated versions have been installed.

Level 4 Quantitatively Controlled

Vulnerability & Patch Management (VPM) capabilities, in addition to being standardized across the entity and centrally managed to ensure consistency across Technology Assets, Applications, Services and/or Data (TAASD), efforts are metrics driven to provide sufficient insight for decision makers to predict optimal performance, ensure continued operations and/or identify areas for improvement. Capability criteria associated with this control reasonably expect the following criteria to exist:
▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.
▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).
▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).
▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.
▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).
▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.
▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.

Level 5 Continuously Improving

Vulnerability & Patch Management (VPM) capabilities, in addition to being standardized across the entity and centrally managed to ensure consistency across Technology Assets, Applications, Services and/or Data (TAASD), efforts are metrics driven to provide sufficient insight for decision makers to predict optimal performance, ensure continued operations and/or identify areas for improvement. Capability criteria associated with this control reasonably expect the following criteria to exist:
▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.
▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes.
▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies.

1.1 Referenzi

1.2 Rekwiżiti identifikati

1.3 Regolamenti relatati

2. Rekwiżiti identifikati

Rekwiżiti

3. Regolamenti relatati

Regolamenti
EULAW Artikolu 4 Politika tal-ġestjoni tal-assi tal-ICT
-
EULAW Artikolu 4 Politika tal-ġestjoni tal-assi tal-ICT
-
EULAW Artikolu 34 Sigurtà tal-operazzjonijiet tal-ICT

Artikolu 34

Sigurtà tal-operazzjonijiet tal-ICT

L-entitajiet finanzjarji msemmija fl-Artikolu 16(1) tar-Regolament (UE) 2022/2554 għandhom, bħala parti mis-sistemi, mill-protokolli u mill-għodod tagħhom, u għall-assi kollha tal-ICT:

(a) 

jimmonitorjaw u jimmaniġġaw iċ-ċiklu tal-ħajja tal-assi kollha tal-ICT;

(b) 

jimmonitorjaw jekk l-assi tal-ICT humiex appoġġati minn fornituri terzi ta’ servizzi tal-ICT ta’ entitajiet finanzjarji, meta applikabbli;

(c) 

jidentifikaw ir-rekwiżiti tal-kapaċità tal-assi u l-miżuri tal-ICT tagħhom biex iżommu u jtejbu d-disponibbiltà u l-effiċjenza tas-sistemi tal-ICT u jipprevjenu n-nuqqas ta’ kapaċitajiet tal-ICT qabel ma jimmaterjalizzaw;

(d) 

iwettqu skennjar u valutazzjonijiet awtomatizzati għall-vulnerabbiltajiet fuq l-assi tal-ICT proporzjonati għall-klassifikazzjoni tagħhom kif imsemmi fl-Artikolu 30(1) u għall-profil tar-riskju ġenerali tal-assi tal-ICT, u jużaw is-software korrettiv biex jirrimedjaw il-vulnerabbiltajiet identifikati;

(e) 

jimmaniġġaw ir-riskji relatati ma’ assi tal-ICT skaduti, mhux appoġġati jew miruta;

(f) 

jirreġistraw avvenimenti relatati mal-kontroll loġiku u fiżiku tal-aċċess, mal-operazzjonijiet tal-ICT, inklużi l-attivitajiet tat-traffiku tas-sistema u tan-network, u l-ġestjoni tat-tibdil fl-ICT;

(g) 

jidentifikaw u jimplimentaw miżuri għall-monitoraġġ u l-analiżi ta’ informazzjoni dwar attivitajiet u mġiba anomali għal operazzjonijiet kritiċi jew importanti tal-ICT;

(h) 

jimplimentaw miżuri għall-monitoraġġ ta’ informazzjoni rilevanti u aġġornata dwar it-theddid ċibernetiku;

(i) 

jimplimentaw miżuri biex jidentifikaw tixrid possibbli ta’ informazzjoni, kodiċi malizzjuż u theddid ieħor għas-sigurtà, u vulnerabbiltajiet magħrufa pubblikament fis-software u fil-hardware, u jivverifikaw aġġornamenti korrispondenti ġodda dwar is-sigurtà.

Għall-finijiet tal-punt (f), l-entitajiet finanzjarji għandhom jallinjaw il-livell ta’ dettall tar-reġistri mal-iskop u l-użu tagħhom tal-assi tal-ICT li jipproduċi dawk ir-reġistri.
EULAW Artikolu 34 Sigurtà tal-operazzjonijiet tal-ICT

Artikolu 34

Sigurtà tal-operazzjonijiet tal-ICT

L-entitajiet finanzjarji msemmija fl-Artikolu 16(1) tar-Regolament (UE) 2022/2554 għandhom, bħala parti mis-sistemi, mill-protokolli u mill-għodod tagħhom, u għall-assi kollha tal-ICT:

(a) 

jimmonitorjaw u jimmaniġġaw iċ-ċiklu tal-ħajja tal-assi kollha tal-ICT;

(b) 

jimmonitorjaw jekk l-assi tal-ICT humiex appoġġati minn fornituri terzi ta’ servizzi tal-ICT ta’ entitajiet finanzjarji, meta applikabbli;

(c) 

jidentifikaw ir-rekwiżiti tal-kapaċità tal-assi u l-miżuri tal-ICT tagħhom biex iżommu u jtejbu d-disponibbiltà u l-effiċjenza tas-sistemi tal-ICT u jipprevjenu n-nuqqas ta’ kapaċitajiet tal-ICT qabel ma jimmaterjalizzaw;

(d) 

iwettqu skennjar u valutazzjonijiet awtomatizzati għall-vulnerabbiltajiet fuq l-assi tal-ICT proporzjonati għall-klassifikazzjoni tagħhom kif imsemmi fl-Artikolu 30(1) u għall-profil tar-riskju ġenerali tal-assi tal-ICT, u jużaw is-software korrettiv biex jirrimedjaw il-vulnerabbiltajiet identifikati;

(e) 

jimmaniġġaw ir-riskji relatati ma’ assi tal-ICT skaduti, mhux appoġġati jew miruta;

(f) 

jirreġistraw avvenimenti relatati mal-kontroll loġiku u fiżiku tal-aċċess, mal-operazzjonijiet tal-ICT, inklużi l-attivitajiet tat-traffiku tas-sistema u tan-network, u l-ġestjoni tat-tibdil fl-ICT;

(g) 

jidentifikaw u jimplimentaw miżuri għall-monitoraġġ u l-analiżi ta’ informazzjoni dwar attivitajiet u mġiba anomali għal operazzjonijiet kritiċi jew importanti tal-ICT;

(h) 

jimplimentaw miżuri għall-monitoraġġ ta’ informazzjoni rilevanti u aġġornata dwar it-theddid ċibernetiku;

(i) 

jimplimentaw miżuri biex jidentifikaw tixrid possibbli ta’ informazzjoni, kodiċi malizzjuż u theddid ieħor għas-sigurtà, u vulnerabbiltajiet magħrufa pubblikament fis-software u fil-hardware, u jivverifikaw aġġornamenti korrispondenti ġodda dwar is-sigurtà.

Għall-finijiet tal-punt (f), l-entitajiet finanzjarji għandhom jallinjaw il-livell ta’ dettall tar-reġistri mal-iskop u l-użu tagħhom tal-assi tal-ICT li jipproduċi dawk ir-reġistri.
EULAW Artikolu 34 Sigurtà tal-operazzjonijiet tal-ICT

Artikolu 34

Sigurtà tal-operazzjonijiet tal-ICT

L-entitajiet finanzjarji msemmija fl-Artikolu 16(1) tar-Regolament (UE) 2022/2554 għandhom, bħala parti mis-sistemi, mill-protokolli u mill-għodod tagħhom, u għall-assi kollha tal-ICT:

(a) 

jimmonitorjaw u jimmaniġġaw iċ-ċiklu tal-ħajja tal-assi kollha tal-ICT;

(b) 

jimmonitorjaw jekk l-assi tal-ICT humiex appoġġati minn fornituri terzi ta’ servizzi tal-ICT ta’ entitajiet finanzjarji, meta applikabbli;

(c) 

jidentifikaw ir-rekwiżiti tal-kapaċità tal-assi u l-miżuri tal-ICT tagħhom biex iżommu u jtejbu d-disponibbiltà u l-effiċjenza tas-sistemi tal-ICT u jipprevjenu n-nuqqas ta’ kapaċitajiet tal-ICT qabel ma jimmaterjalizzaw;

(d) 

iwettqu skennjar u valutazzjonijiet awtomatizzati għall-vulnerabbiltajiet fuq l-assi tal-ICT proporzjonati għall-klassifikazzjoni tagħhom kif imsemmi fl-Artikolu 30(1) u għall-profil tar-riskju ġenerali tal-assi tal-ICT, u jużaw is-software korrettiv biex jirrimedjaw il-vulnerabbiltajiet identifikati;

(e) 

jimmaniġġaw ir-riskji relatati ma’ assi tal-ICT skaduti, mhux appoġġati jew miruta;

(f) 

jirreġistraw avvenimenti relatati mal-kontroll loġiku u fiżiku tal-aċċess, mal-operazzjonijiet tal-ICT, inklużi l-attivitajiet tat-traffiku tas-sistema u tan-network, u l-ġestjoni tat-tibdil fl-ICT;

(g) 

jidentifikaw u jimplimentaw miżuri għall-monitoraġġ u l-analiżi ta’ informazzjoni dwar attivitajiet u mġiba anomali għal operazzjonijiet kritiċi jew importanti tal-ICT;

(h) 

jimplimentaw miżuri għall-monitoraġġ ta’ informazzjoni rilevanti u aġġornata dwar it-theddid ċibernetiku;

(i) 

jimplimentaw miżuri biex jidentifikaw tixrid possibbli ta’ informazzjoni, kodiċi malizzjuż u theddid ieħor għas-sigurtà, u vulnerabbiltajiet magħrufa pubblikament fis-software u fil-hardware, u jivverifikaw aġġornamenti korrispondenti ġodda dwar is-sigurtà.

Għall-finijiet tal-punt (f), l-entitajiet finanzjarji għandhom jallinjaw il-livell ta’ dettall tar-reġistri mal-iskop u l-użu tagħhom tal-assi tal-ICT li jipproduċi dawk ir-reġistri.

Kwistjonijiet marbuta

Links
is related to Annual
is related to relative Control Weighting = 07
is related to Process
is related to Protect
is related to SCRM Focus Tier 1 STRATEGIC
is related to SCRM Focus Tier 2 OPERATIONAL
is related to SCRM Focus Tier 3 TACTICAL
blocks Loss, Theft or Damage of Assets
blocks Business / Service Interruption
blocks Reduced Operational Productivity
blocks System / Data Compromise (Technical Vector)
blocks Exposure from Unaddressed Vulnerabilities
blocks System / Service Compromise
blocks Failure to Support Business / Mission Objectives
blocks Unaddressed Security / Compliance Exposure
blocks Third-Party Dependency Failure
blocks Loss of Data / Service Availability
blocks Drought & Water Shortage
blocks Earthquakes
blocks Fire & Wildfires
blocks Floods
blocks Hurricanes & Tropical Storms
blocks Landslides & Debris Flow
blocks Pandemic (Disease) Outbreaks
blocks Severe Weather
blocks Space Weather
blocks Thunderstorms & Lightning
blocks Tornadoes
blocks Tsunamis
blocks Volcanoes
blocks Winter Storms & Extreme Cold
blocks Malicious Cyber Activity
blocks Dysfunctional Management Practices
blocks Human Error
blocks Technical / Mechanical Failure
blocks Statutory / Regulatory / Contractual Change
blocks Economic Shock / Market Disruption
blocks Geopolitical Conflict / Government Intervention
blocks Sanctions / Trade Restriction Disruption
blocks Counterfeit / Non-Conforming Products
blocks Manufacturing Capacity / Supply Disruption
blocks Product Defect / Design Failure
blocks Supplier Financial Distress / Insolvency
blocks Workforce Shortage / Loss of Critical Skills / Labor Disruption
blocks Transportation / Logistics Disruption
is blocked by AST-37 Technology Lifecycle Management – Assessment Procedure
blocks SA-03 System Development Life Cycle
blocks SA-03(01) Manage Preproduction Environment
blocks SA-03(03) Technology Refresh
blocks SA-08(30) Procedural Rigor
blocks SA-03 [L] System Development Life Cycle
blocks SA-03 [M] System Development Life Cycle
blocks SA-03 [H] System Development Life Cycle
blocks SA-03 [P] System Development Life Cycle
blocks 03.16.02 Unsupported System Components
blocks GV.SC-09 Supply chain security practices are integrated into cybersecurity and enterprise risk management programs, and their performance is monitored …
blocks ID.AM-08 Systems, hardware, software, services, and data are managed throughout their life cycles
blocks PR.PS-02 Software is maintained, replaced, and removed commensurate with risk
blocks PR.PS-03 Hardware is maintained, replaced, and removed commensurate with risk
  • Secure Controls Framework -

    The Secure Controls Framework® (SCF)

    "The SCF is the Common Controls Framework™ (CCF), the world's most comprehensive cybersecurity and data privacy metaframework - it is also free to use. The entire concept is building secure, compliant and resilient capabilities in the most efficient and cost-effective manner possible.

    The SCF is more than just a unified control catalog, since its included content creates a playbook for Governance, Risk & Compliance (GRC) capabilities. Used globally by organizations of every size, the SCF is a robust and scalable solution for security, compliance and resilience controls. As a comprehensive security framework, the SCF maps 1,400+ controls across 200+ laws, regulations, and industry frameworks so you can implement once and comply everywhere.

    Like it or not, cybersecurity is a protracted war on an asymmetric battlefield, where the threats are everywhere and as defenders we have to make the effort to work together to help improve cybersecurity and data privacy practices, since we all suffer when massive data breaches occur or when cyber attacks have physical impacts. Hackers share information on attack methods with other hackers, so why shouldn’t the good guys share information on how to best protect an organization? We decided to take action and make a difference, since we feel it is too important to wait for someone else to fix the problems that exist.

    The SCF is made up of volunteers, mainly specialists within the cybersecurity profession, who focus on GRC and the cybersecurity side of data privacy. These are auditors, engineers, architects, incident responders, consultants and other specialists who live and breathe these topics on a daily basis. The end product is "expert-derived content" that makes up the SCF." https://securecontrolsframework.com/ 

    Terms & Conditions

    The SCF End User License Agreement (EULA) governs the use of the Secure Controls Framework® (SCF) under the Creative Commons Attribution-No Derivatives 4.0 International Public License.