DORA: HOW US BASED FINANCIAL FIRMS NEED TO PREPARE FOR ICT GOVENANCE

 

What is DORA and ICT Governcnace?

There are many laws and regulations that affect many global business entities.  International banking and financial firms face many regulatory hurdles depending on the jurisdiction of where the office and transactions are occurring, thus causing chaos on which law may take precedence over another regulation.  Cybersecurity laws are no exception, as it has been demonstrated that there are differing laws on that subject that range over the 50 states and territories in this country.  Compound that with many of the international regulations and directives from the multitude of countries where these firms do business.  The European Union is one of the parliamentary bodies that has been at the forefront in the creation of cyber laws that pertain to security and privacy.   The most well known one is the General Data Protection Regulation or GDPR[i] as it is commonly referred.  This directive has been laid out with clear concise articles that define the expectations that should be done to protect consumers, as opposed to the vagueness in the FTC Article 5(a).  Recently, a new proposal called the Digital Operational Resilience Act or DORA has been proposed and is expected to become law and enforceable in 2024.  The DORA legislation is the nexus event for the international financial industry in which will usher in new higher standards.

The DORA legislation provides guidance to use the information and communication technology (ICT) guidelines per Final Report on Guidelines on ICT and Security Risk Management[ii].  The legislation is very similar in nature to the NYDFS Cybersecurity requirements for the financial services[iii] providing subject, scope and definitions for governance, strategy, and third-party services.  The ICT guidance is not specific to the financial industry, but it is more similar to the guidance often referred to in the NIST SP 800 and NIST SP 1800 Series documents.  The ICT has a well-defined risk management framework, which is very similar to NIST Special Publication 800-37[iv].  This is the basic baseline for what DORA and ICT will be to US based financial institutions that have operations within the European Union.

RISK MANAGEMENT

Will this be a challenge for US based financial services firms?  While the larger companies should not have an issue with compliance, there will be a number of the smaller firms that will face significant challenges with adherence to the new DORA legislation.  Some of the common factors are that the majority of the firms already have to maintain compliance with US Federal and state laws that pertain to financial industry but also publicly traded companies and other industry mandated standards.  For instance, if a company has anything to do with any type of a credit or debit card, as most financial companies do, then there is the requirement to adhere to the Payment Card Industry standards which are published as the PCI-DSS requirements[v]. The PCI-DSS standards provide for data security that is in motion and for data at rest, security controls, cryptography, monitoring and logging along with many more governance items.  Risk Management is the key component of the ICT Directive part of DORA.  There is a requirement to have a formalized plans that are disaster recovery and business continuity, along with requirements to set up system tools that identify risk and provide for measures to prevent and protect any issues that might arise.  Another covenant is the requirement that management ensures that the staff is properly trained in the control governance to support the operations policies and security risk management processes and procedures.  This requirement has a provision that this must be allocated for in the budget that all staff members receive this training on an annual basis.  This also makes management accountable for creation, approval, and oversight if all strategy related to security risks and cybersecurity.  This closely parallels some of the same requirements that are part of the NYDFS Cybersecurity Requirements.  However, a better approach to meeting and exceeding the requirements of the DORA and ICT Directives would be to model the program after NIST SP 800-37r2: Risk Management Framework for Information Systems and Organizations: A System Life Cycle Approach for Security and Privacy (nist.gov)[vi].  This similarities in these two documents call for the systematic identification of risk and continuous reassessment of any factors, allowing for the calibration of plans, policies, procedures, and tool modifications.  In a Bank of England paper on if a cyber attack could cause impact to the financial sector, risk mitigation is the importance of trust, integrity, availability, and recoverability was stressed in this graphic.[vii]

PRIVACY

One of the other concerns is that if the tenets of the Gramm-Leach-Bliley Act[viii] , specifically the safeguard rule for financial institutions would cause any conflicts with DORA.  There are parallels that can be drawn to the GLBA and DORA where the wording is slightly misaligned, but the meaning is still there.  While the GLBA uses the term privacy of its customers, and the DORA legislation uses confidentiality of data.  The spirit of the meaning is that the integrity, security, and confidentiality of customer financial information must be maintained within any information system maintained by the financial institution or any third-party provider.  The goal is to achieve a trust in the system that all monies and other financial instruments be kept secure and safe from loss.  Privacy and confidentiality are often used interchangeably in cybersecurity doctrine, there are small differences in the vernacular.

 

Third-Party Providers

An attack on the supply chain is a softer target than the defenses that a financial firm would have in place.  The institutions that rely on these third-party services and vendors have historically been a huge attack surface to get a foothold into the enterprise.  An example would be the HVAC vendor used by the merchant, Target, where a hostile entity was able to breach them via links that were meant to modify and monitor the air conditioning and heating units in all the stores.  Under DORA, the European Supervisory Authorities will have the authority to audit, inspect and issue fines for any violations.  The expectation is that these suppliers and vendors will have to meet at least a SOC2-type standards.[ix] The threat of a supply chain attack is a risk that must be addressed, and a focus be made to provide protections.[x] 

Incident Reporting

Under the ICT Directive, the incident reporting would be one of the strictest requirements of reporting any breach of private or confidential data to any that has been affected by the compromise along with proper regulatory agencies.  This is something that is similar to many US State disclosure of breach laws.  The strictest law that most US based financial institutions that are required to comply with is the California Consumer Privacy Act[xi].   Details on how this information and the timeliness of the notification of the breach disclosure is not specific but it is expected to be done at the earliest reasonable time.

 

Intelligence Sharing

Anytime there is a mention of information or intelligence sharing amongst companies, there will be warnings about the possible accusations of collusion triggering talks of the Sherman Anti-Trist Act[xii].  This would not have to be the cause because this data being shared.  The CISA Financial Services Sector Specific Plan[xiii] actively endorses sharing information to create awareness across the industry.   The coordinated effort should help strengthen the industry as a whole and thwart attempts by hostile actors that intend to commit nefarious acts against consumers. 

Business Continuity  

The DORA legislation enforcement of the ICT Directive calls for a formal business continuity plan that is to be tested and reviewed annually.  The expectation is that all staff should know their responsibilities and duties in the event of an event that could cause an interruption to the firm but would need to cause minimal disruption to consumers.  It is of paramount importance that customers have the ability to access their funds. 

Conclusion

The DORA legislation and ICT directive on cybersecurity should have a minimal affect on the way US based financial institutions conduct business within the European Union borders.  This will actually create a uniform law with requirements that will be simpler to follow than all of the individual countries’ rules and regulations.  Most of the larger institutions such as the large banks and brokerage houses already have the infrastructure that complies with these requirements based on many of the laws they are already subjected.  The firms, such as smaller brokerage houses and crowd funding startups are the ones that are going to face the most stringent challenges trying to meet the requirements as they face the increasing costs for procuring the expertise and equipment to be able to adhere to these laws.  The additional expenses of required audits and penetration tests can be a substantial hit to smaller institutions cost of doing business.  This would be a significant barrier of entry for doing business in the European Union and all of the other countries that tend to adopt their laws.  Although, this could limit competition in the EU, the overall effect would be to protect consumers that utilize the financial institutions to issue & trade stock, provide loans and handle funds in the most stable and secure way possible.

 

---

[i] General Data Protection Regulation (GDPR) – Official Legal Text (gdpr-info.eu) https://gdpr-info.eu/

[ii] Guidelines on ICT and security risk management | European Banking Authority (europa.eu) https://www.eba.europa.eu/regulation-and-policy/internal-governance/guidelines-on-ict-and-security-risk-management

[iii] Cybersecurity_Requirements_Financial_Services_23NYCRR500.pdf https://www.governor.ny.gov/sites/default/files/atoms/files/Cybersecurity_Requirements_Financial_Services_23NYCRR500.pdf

[iv] NIST Special Publication 800-37 Risk Management Framework for Information Systems and Organizations: A System Life Cycle Approach for Security and Privacy (nist.gov) https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-37r2.pdf

[v] PCI_DSS_v3-2-1.pdf (pcisecuritystandards.org) https://www.pcisecuritystandards.org/documents/PCI_DSS_v3-2-1.pdf?agreement=true&time=1625337780917

[vi] Risk Management Framework for Information Systems and Organizations: A System Life Cycle Approach for Security and Privacy (nist.gov) https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-37r2.pdf

[vii] Could a cyber attack cause a systemic impact in the financial sector? (researchgate.net) https://www.researchgate.net/profile/Kim-Kaivanto/publication/330324082_Could_a_Cyber_Attack_Cause_a_Systemic_Impact_in_the_Financial_Sector/links/5e67ae7992851c7ce05ad327/Could-a-Cyber-Attack-Cause-a-Systemic-Impact-in-the-Financial-Sector.pdf

[viii] Gramm-Leach-Bliley Act https://www.congress.gov/106/plaws/publ102/PLAW-106publ102.pdf

[ix] EU's DORA regulation explained: New risk management requirements for financial firms https://www.csoonline.com/article/3596881/eus-dora-regulation-explained-new-risk-management-requirements-for-financial-firms.html

[x] P.17  The Ethics of Cybersecurity, Markus Christen, Bert Gordijn, and Michele Loi https://library.oapen.org/bitstream/handle/20.500.12657/47324/9783030290535.pdf?sequence=1#page=111

[xi] California Consumer Privacy Act https://leginfo.legislature.ca.gov/faces/codes_displayText.xhtml?division=3.&part=4.&lawCode=CIV&title=1.81.5

[xii] Sherman Anti-Trust Act - [USC05] 15 USC CHAPTER 2, SUBCHAPTER I: FEDERAL TRADE COMMISSION (house.gov) https://uscode.house.gov/view.xhtml?req=granuleid%3AUSC-prelim-title15-chapter2-subchapter1&edition=prelim

[xiii] Financial Services Sector-Specific Plan 2015 (cisa.gov) https://www.cisa.gov/sites/default/files/publications/nipp-ssp-financial-services-2015-508.pdf

Centralized Access Control

 Centralized Access Control is a component of the AAA (Authentication, Authorization, and Accounting) architecture that provides a centralized system for managing and enforcing access control policies across an organization's resources.

In this architecture, the Access Control component is responsible for managing the rules that dictate which users or systems are authorized to access specific resources. The Access Control component centrally stores and manages access control policies, which are applied consistently across all resources.

Centralized Access Control typically involves a central policy server that maintains a database of access control rules, and agents or client software that enforce those rules on individual systems. These agents or client software communicate with the central policy server to retrieve the appropriate access control rules for a given user or system and then apply those rules to the resources being accessed.

Centralized Access Control can provide several benefits, including more consistent and effective enforcement of access control policies, centralized management and auditing of access control rules, and better scalability for large and complex environments. However, it can also be more complex to set up and manage compared to other access control models.

Some common implementations of Centralized Access Control in AAA Architecture include:

1. Role-Based Access Control (RBAC): This model assigns users to roles based on their job functions and responsibilities. Access control policies are then defined for each role, allowing users to access only the resources that they are authorized to access.

2. Attribute-Based Access Control (ABAC): This model uses attributes such as user ID, job title, location, and time of day to make access control decisions. This allows for more granular access control policies based on multiple attributes.

3. Mandatory Access Control (MAC): This model is used in highly secure environments, such as military and government agencies. Access control decisions are based on a set of predefined rules, which are typically managed by a central authority.

4. Discretionary Access Control (DAC): This model allows the owner of a resource to determine who has access to it. Access control decisions are based on the identity of the user requesting access and the permissions granted by the owner.

5. Rule-Based Access Control (RBAC): This model uses a set of rules to determine access control decisions. The rules may be based on user attributes, resource attributes, or a combination of both.

6. Attribute-Based Access Control (ABAC): This model uses a set of policies to determine access control decisions. The policies may be based on user attributes, resource attributes, or a combination of both.

Overall, Centralized Access Control is a critical component of the AAA architecture that ensures that only authorized users are granted access to network resources. The specific implementation chosen will depend on the specific security needs of the organization.

Several protocols support centralized access control, including:

1. RADIUS (Remote Authentication Dial-In User Service): RADIUS is a widely used protocol for centralized access control, authentication, and accounting. It is commonly used in enterprise networks to control access to network resources such as Wi-Fi networks, VPNs, and remote access servers.

2. TACACS (Terminal Access Controller Access Control System) is a protocol used for providing centralized authentication, authorization, and accounting (AAA) services for network devices. TACACS is often used in conjunction with RADIUS (Remote Authentication Dial-In User Service) to provide a comprehensive AAA solution. While RADIUS is primarily used for authentication and accounting, TACACS is designed to separate authentication and authorization, allowing for greater control and flexibility in network access policies.

3. TACACS+ (Terminal Access Controller Access-Control System Plus): TACACS+ is a Cisco proprietary protocol that provides centralized access control, authentication, and accounting. It is commonly used in large enterprise networks to control access to network devices such as routers and switches. TACACS+ is an updated version of the protocol that provides additional security features and functionality. It uses TCP for reliable transport and encrypts all traffic between the client and server to protect against eavesdropping and tampering.

4. LDAP (Lightweight Directory Access Protocol): LDAP is a protocol used for accessing and maintaining distributed directory information services over an IP network. It is commonly used for centralized authentication and authorization in enterprise networks.

5. Kerberos: Kerberos is a network authentication protocol that provides secure authentication over an insecure network. It is commonly used in enterprise networks to provide centralized authentication and authorization for users and services.

6. EAP (Extensible Authentication Protocol) is another protocol that supports centralized access control. EAP is used for wireless network authentication and is commonly used in conjunction with RADIUS for centralized access control. EAP is an authentication framework that provides support for multiple authentication methods such as passwords, digital certificates, smart cards, and biometrics. EAP is used in wireless networks to provide secure authentication between wireless clients and access points. In the context of centralized access control, EAP is used to authenticate wireless clients before granting them access to the network. EAP messages are encapsulated within RADIUS messages and are sent between the wireless client, the access point, and the RADIUS server. The RADIUS server authenticates the user using the EAP method specified in the EAP message and sends an access-accept or access-reject message to the access point, which then grants or denies access to the wireless client.

Access Control Concepts

 

Access control is a fundamental concept in cybersecurity, which involves controlling who has access to a system, network, or data. There are several access control concepts in cybersecurity, including:

1. Authentication: This is the process of verifying the identity of a user or system attempting to access a resource. Authentication can be achieved through various means, such as passwords, biometrics, or smart cards.
2. Authorization: Once a user or system has been authenticated, authorization determines what actions they are allowed to perform on the resource. This can include read, write, execute, or delete permissions.
3. Principle of Least Privilege: This concept dictates that users or systems should only be given the minimum level of access required to perform their job duties or tasks. This reduces the risk of unauthorized access or accidental misuse.
4. Separation of Duties: This concept involves dividing responsibilities between multiple users or systems to prevent any single user or system from having too much control over a resource.
5. Access Control Lists (ACLs): ACLs are a set of rules that determine which users or systems are allowed to access a resource and what actions they are allowed to perform.
6. Role-Based Access Control (RBAC): RBAC assigns permissions based on the user's job role or function within an organization. This simplifies access control management by grouping users with similar permissions.

Overall, access control concepts play a critical role in maintaining the security and integrity of a system, network, or data.

Service-Oriented Modeling Framework (SOMF)

 

The Service-Oriented Modeling Framework (SOMF) is a methodology used in cybersecurity architecture to design and develop software applications and systems that are service-oriented. SOMF provides a structured approach to modeling and designing service-oriented applications, with a focus on security.

SOMF is based on four key modeling perspectives: the business perspective, the information perspective, the application perspective, and the technology perspective. Each perspective is used to capture the relevant information for a particular aspect of the service-oriented architecture.

The business perspective is concerned with the business processes that the service-oriented application is designed to support. This perspective focuses on the business requirements and how they can be translated into services.

The information perspective is concerned with the data and information that the service-oriented application will manage. This perspective focuses on the data models and the information flows between services.

The application perspective is concerned with the services themselves and how they are designed, developed, and deployed. This perspective focuses on the service interfaces, the service implementation, and the service lifecycle.

The technology perspective is concerned with the underlying technology infrastructure that the service-oriented application will run on. This perspective focuses on the technology components, such as the middleware and the messaging infrastructure, that are required to support the services.

Overall, SOMF provides a structured approach to designing service-oriented applications that are secure, reliable, and scalable. By following SOMF, cybersecurity architects can ensure that the services they develop meet the needs of the business, are well-designed and implemented, and are deployed on a secure and reliable technology infrastructure.

The Business Perspective is one of the four key modeling perspectives in the Service-Oriented Modeling Framework (SOMF) used in cybersecurity architecture. Business Perspective is concerned with the business processes that the service-oriented application is designed to support, and it focuses on the business requirements and how they can be translated into services.

The Business Perspective includes the following details:

1. Business Process Modeling: This involves modeling the business processes that the service-oriented application will support. This includes identifying the key activities, inputs, outputs, and actors involved in each business process.
2. Service Identification: This involves identifying the services that will be required to support the business processes. This includes defining the service boundaries, service interfaces, and service contracts.
3. Service Composition: This involves defining how the individual services will be combined to support the overall business processes. This includes identifying the service dependencies and designing the service orchestration.
4. Service Level Agreements (SLAs): This involves defining the service level agreements that will be required to ensure that the services meet the business requirements. This includes specifying the performance, availability, and reliability requirements for each service.
5. Security Requirements: This involves identifying the security requirements for the service-oriented application. This includes specifying the authentication, authorization, and encryption requirements for each service.
6. Business Rules: This involves defining the business rules that will be used to govern the behavior of the service-oriented application. This includes specifying the conditions under which services should be invoked and how the data should be processed.

Overall, the Business Perspective in SOMF provides a structured approach to modeling the business processes and requirements of a service-oriented application. By following the Business Perspective, cybersecurity architects can ensure that the services they develop meet the needs of the business and are well-aligned with the overall objectives of the organization.

The Information Perspective is one of the four key modeling perspectives in the Service-Oriented Modeling Framework (SOMF) used in cybersecurity architecture. The Information Perspective is concerned with the data and information that the service-oriented application will manage, and it focuses on the data models and the information flows between services.

The Information Perspective includes the following details:

1. Information Modeling: This involves modeling the data that the service-oriented application will manage. This includes defining the data structures, data elements, and relationships between data entities.
2. Service Contracts: This involves defining the service contracts that specify the data elements and formats that will be exchanged between services. This includes defining the input and output parameters for each service.
3. Service Choreography: This involves defining the sequence of interactions between services that are required to support the business processes. This includes specifying the message exchange patterns and the conditions under which each service should be invoked.
4. Data Integration: This involves defining the mechanisms that will be used to integrate data between services. This includes specifying the data transformation and data mapping rules that are required to ensure that the data is exchanged correctly between services.
5. Data Security: This involves identifying the security requirements for the data managed by the service-oriented application. This includes specifying the access control, data encryption, and data backup requirements for each service.
6. Data Governance: This involves defining the policies and procedures that are required to manage the data in the service-oriented application. This includes specifying the data ownership, data retention, and data privacy requirements for each service.

Overall, the Information Perspective in SOMF provides a structured approach to modeling the data and information flows in a service-oriented application. By following the Information Perspective, cybersecurity architects can ensure that the services they develop are well-aligned with the data requirements of the business and are designed to manage data securely and efficiently.

The Application Perspective is one of the four key modeling perspectives in the Service-Oriented Modeling Framework (SOMF) used in cybersecurity architecture. The Application Perspective is concerned with the services themselves and how they are designed, developed, and deployed. It focuses on the service interfaces, the service implementation, and the service lifecycle.

The Application Perspective includes the following details:

1. Service Interface Design: This involves designing the service interfaces that will be used to interact with the services. This includes defining the input and output parameters, the message formats, and the communication protocols that will be used.
2. Service Implementation: This involves developing the service implementation that will execute the business logic of the service. This includes defining the algorithms, the data structures, and the programming languages that will be used.
3. Service Testing: This involves testing the services to ensure that they meet the functional and non-functional requirements. This includes defining the test cases, the test data, and the test scripts that will be used.
4. Service Deployment: This involves deploying the services to the production environment. This includes defining the deployment architecture, the deployment scripts, and the deployment procedures that will be used.
5. Service Monitoring: This involves monitoring the services to ensure that they are running correctly and that they are meeting the performance and availability requirements. This includes defining the monitoring tools, the monitoring metrics, and the monitoring procedures that will be used.
6. Service Maintenance: This involves maintaining the services over their lifecycle. This includes performing maintenance activities such as bug fixing, code refactoring, and performance tuning.

Overall, the Application Perspective in SOMF provides a structured approach to designing, developing, and deploying services in a service-oriented application. By following the Application Perspective, cybersecurity architects can ensure that the services they develop are well-designed and implemented and are deployed and maintained efficiently and effectively.

The Technology Perspective is one of the four key modeling perspectives in the Service-Oriented Modeling Framework (SOMF) used in cybersecurity architecture. The Technology Perspective is concerned with the technology infrastructure that the service-oriented application will use, and it focuses on the hardware, software, and networking components that will support the application.

The Technology Perspective includes the following details:

1. Technology Infrastructure: This involves defining the hardware and software components that will be required to support the service-oriented application. This includes identifying the servers, storage devices, and network devices that will be used.
2. Service Deployment Architecture: This involves defining the architecture that will be used to deploy the services to the technology infrastructure. This includes identifying the service hosting environment, the deployment topology, and the communication protocols that will be used.
3. Service Middleware: This involves selecting the middleware technologies that will be used to support the service-oriented application. This includes selecting the message brokers, the service registries, and the service repositories that will be used.
4. Service Virtualization: This involves defining the virtualization technologies that will be used to manage the service-oriented application. This includes defining the virtualization layers, the virtual machines, and the virtual networking that will be used.
5. Service Orchestration: This involves selecting the orchestration technologies that will be used to manage the service-oriented application. This includes selecting the workflow engines, the business process management systems, and the event-driven architectures that will be used.
6. Service Security: This involves selecting the security technologies that will be used to protect the service-oriented application. This includes selecting the firewalls, the intrusion detection systems, and the security monitoring tools that will be used.

Overall, the Technology Perspective in SOMF provides a structured approach to selecting and deploying the technology infrastructure that will support the service-oriented application. By following the Technology Perspective, cybersecurity architects can ensure that the services they develop are well-supported by the underlying technology infrastructure and are designed to operate securely and efficiently.

Sherwood Applied Business Architecture (SABSA)

 

The Sherwood Applied Business Architecture (SABSA) framework is a methodology for developing security architectures and implementing risk management strategies in complex organizations. It was created by John Sherwood in the 1990s and has since been further developed and refined by a community of security professionals.

SABSA is a business-driven framework that aims to align security with the overall objectives of an organization. It provides a structured approach to developing security architectures that are based on a thorough understanding of the organization's business processes, information assets, and stakeholders.

The SABSA framework is structured around six layers, each of which addresses a specific aspect of the security architecture:

1. The Business Layer: This layer defines the organization's overall mission, goals, and objectives. It identifies the key business processes and stakeholders and establishes the context for the security architecture.
2. The Information Layer: This layer defines the information assets that the organization needs to protect. It includes information classification, ownership, and management.
3. The Application Layer: This layer defines the applications that support the organization's business processes and the security controls that must be implemented to protect them.
4. The Technology Layer: This layer defines the underlying IT infrastructure that supports the applications and the security controls that must be implemented to protect it.
5. The Physical Layer: This layer defines the physical assets that support the IT infrastructure, such as buildings, data centers, and network equipment.
6. The People Layer: This layer defines the human resources that are involved in the operation and management of the security architecture. It includes policies, procedures, and training programs for staff.

The SABSA framework provides a structured approach to developing security architectures that are based on a thorough understanding of the organization's business processes, information assets, and stakeholders. By aligning security with business objectives, SABSA helps organizations to achieve their goals while managing risk effectively.

The SABSA Business Layer is the first layer of the SABSA framework and is one of the most important layers because it sets the context for the entire security architecture.

The Business Layer defines the organization's overall mission, vision, goals, and objectives, and identifies the key business processes and stakeholders. It provides a top-level view of the organization's business functions, strategies, and governance structures, and establishes the foundation for the rest of the security architecture.

In particular, the Business Layer in the SABSA framework focuses on the following areas:

1. Business Drivers: This includes identifying the internal and external factors that drive the organization's business processes, such as market trends, regulatory requirements, and customer needs.
2. Business Objectives: This includes defining the organization's goals and objectives in terms of business outcomes, such as revenue growth, cost reduction, and customer satisfaction.
3. Business Processes: This includes identifying the key business processes and activities that are critical to achieving the organization's business objectives.
4. Business Information: This includes identifying the information assets that are critical to the organization's business processes and activities, such as customer data, financial information, and intellectual property.
5. Stakeholders: This includes identifying the stakeholders who are involved in the organization's business processes and activities, such as customers, employees, partners, regulators, and shareholders.

By understanding the business drivers, objectives, processes, information, and stakeholders, the SABSA framework can help to ensure that the security architecture is aligned with the organization's business goals and objectives. This alignment is critical to achieving a balance between security and business requirements, and to ensuring that security measures are not seen as an impediment to business operations.

In the SABSA Security Framework, the Information Layer is the second layer of the framework and is responsible for defining the information assets that need to be protected. The Information Layer builds on the foundation established by the Business Layer and focuses on identifying and categorizing the organization's information assets.

The Information Layer in the SABSA framework typically includes the following components:

1. Information Classification: This includes identifying the different types of information that the organization uses and establishing a classification scheme based on the sensitivity and criticality of the information. Information may be classified into different levels, such as public, internal, confidential, and restricted.
2. Information Ownership: This includes identifying the stakeholders who are responsible for the information assets, including business units, departments, and individuals.
3. Information Management: This includes defining policies and procedures for managing the information assets, including data governance, data quality, and data lifecycle management.
4. Information Access: This includes defining policies and procedures for granting access to the information assets, including authentication, authorization, and access controls.
5. Information Sharing: This includes defining policies and procedures for sharing information within the organization and with external stakeholders, including partners, customers, and regulators.

By defining and categorizing the organization's information assets, the Information Layer provides the foundation for the rest of the security architecture. It ensures that the security controls are aligned with the sensitivity and criticality of the information assets and that the access controls and sharing policies are consistent with the organization's business objectives and compliance requirements.

In the SABSA Security Framework, the Application Layer is the third layer of the framework and is responsible for defining the security controls that are required to protect the applications that support the organization's business processes.

The Application Layer builds on the foundation established by the Business and Information Layers and focuses on identifying the applications that are critical to the organization's business processes and activities, and the security controls that need to be implemented to protect them.

The Application Layer in the SABSA framework typically includes the following components:

1. Application Identification: This includes identifying the applications that support the organization's business processes and activities and assessing their criticality to the organization's operations.
2. Application Architecture: This includes defining the architecture of the applications, including their components, interfaces, and dependencies.
3. Application Security Requirements: This includes defining the security requirements for the applications, including confidentiality, integrity, availability, and non-repudiation.
4. Application Security Controls: This includes identifying the security controls that need to be implemented to protect the applications, including access controls, encryption, logging, and monitoring.
5. Application Security Testing: This includes testing the applications to ensure that they meet the security requirements and that the security controls are working effectively.

By defining the security controls required to protect the applications, the Application Layer ensures that the security measures are aligned with the organization's business processes and objectives. It also helps to ensure that the applications are secure and reliable, and that they can support the organization's business operations without interruption or compromise.

In the SABSA Security Framework, the Technology Layer is the fourth layer of the framework and is responsible for defining the security controls that are required to protect the underlying technology infrastructure that supports the organization's applications and business processes.

The Technology Layer builds on the foundation established by the Business, Information, and Application Layers, and focuses on identifying the technology components that are critical to the organization's operations, and the security controls that need to be implemented to protect them.

The Technology Layer in the SABSA framework typically includes the following components:

1. Technology Identification: This includes identifying the technology components that support the organization's applications and business processes, including servers, networks, storage devices, and other IT infrastructure.
2. Technology Architecture: This includes defining the architecture of the technology components, including their components, interfaces, and dependencies.
3. Technology Security Requirements: This includes defining the security requirements for the technology components, including confidentiality, integrity, availability, and non-repudiation.
4. Technology Security Controls: This includes identifying the security controls that need to be implemented to protect the technology components, including firewalls, intrusion detection and prevention systems, security information and event management systems, and other security technologies.
5. Technology Security Testing: This includes testing the technology components to ensure that they meet the security requirements and that the security controls are working effectively.

By defining the security controls required to protect the technology infrastructure, the Technology Layer ensures that the security measures are aligned with the organization's business processes and objectives. It also helps to ensure that the technological components are secure and reliable, and that they can support the organization's business operations without interruption or compromise.

In the SABSA Security Framework, the Physical Layer is the fifth and final layer of the framework and is responsible for defining the security controls that are required to protect the physical environment where the organization's technology infrastructure and business processes are located.

The Physical Layer builds on the foundation established by the Business, Information, Application, and Technology Layers, and focuses on identifying the physical assets that are critical to the organization's operations, and the security controls that need to be implemented to protect them.

The Physical Layer in the SABSA framework typically includes the following components:

1. Asset Identification: This includes identifying the physical assets that are critical to the organization's operations, including buildings, data centers, servers, and other IT infrastructure.
2. Asset Architecture: This includes defining the architecture of the physical assets, including their location, access points, and environmental factors.
3. Asset Security Requirements: This includes defining the security requirements for the physical assets, including physical security, environmental control, and disaster recovery.
4. Asset Security Controls: This includes identifying the security controls that need to be implemented to protect physical assets, including access controls, surveillance systems, and environmental monitoring systems.
5. Asset Security Testing: This includes testing the physical assets to ensure that they meet the security requirements and that the security controls are working effectively.

By defining the security controls required to protect the physical environment, the Physical Layer ensures that the security measures are aligned with the organization's business processes and objectives. It also helps to ensure that the physical assets are secure and reliable, and that they can support the organization's business operations without interruption or compromise.

 

The People Layer is not an official layer of the SABSA Security Framework, as the framework only includes five layers: Business, Information, Application, Technology, and Physical. However, some SABSA practitioners may refer to the "People Layer" as a way to describe the importance of considering the human factors in a comprehensive security architecture.

The People Layer refers to the individuals who use, manage, and support the organization's technology infrastructure and business processes. This includes employees, contractors, vendors, and other stakeholders who interact with the organization's systems and data.

The People Layer is critical to the success of a security architecture, as humans can be both a vulnerability and a safeguard. On one hand, humans can make mistakes, fall victim to social engineering attacks, or intentionally engage in malicious activity. On the other hand, humans can also be trained to recognize and respond to security threats, implement best practices for data protection, and support security policies and procedures.

Therefore, the People Layer may be addressed in each of the other five layers of the SABSA framework. For example, the Business Layer may consider the organization's security culture and policies, the Information Layer may consider data classification and access controls, the Application Layer may consider secure coding practices and user authentication, the Technology Layer may consider network security and intrusion detection systems, and the Physical Layer may consider access controls and physical security measures.

Cybersecurity Risk

 

Cybersecurity risk is a constantly evolving threat, and it is important to take proactive steps to minimize your exposure. Here are some ways to deal with cybersecurity risk:

1. Develop a cybersecurity strategy: This strategy should outline the measures you will take to protect your systems and data from cyber threats. It should include measures such as firewalls, antivirus software, and data encryption.
2. Train employees: Employees can unwittingly expose your organization to cyber risks through phishing scams, social engineering attacks, or weak passwords. Providing training to employees on how to identify and avoid such risks is critical to minimizing your cybersecurity risk.
3. Conduct regular security assessments: Regular security assessments can help you identify vulnerabilities in your systems and take corrective action to address them.
4. Back up data regularly: Regular data backups ensure that you have a copy of your critical data in the event of a cybersecurity incident.
5. Monitor and detect: Continuous monitoring of your systems and networks can help you detect and respond to security incidents quickly, minimizing their impact.
6. Respond and recover: Have a plan in place for responding to a cybersecurity incident, including procedures for investigating the incident, containing the damage, and recovering from the attack.

By implementing these measures, you can help minimize your cybersecurity risk and protect your organization's systems and data.

A risk management framework is a structured approach to identifying, assessing, and managing risks to an organization's assets, including its people, processes, technology, and information. The framework provides a systematic process for managing risks throughout an organization's lifecycle, from the identification of potential risks to the implementation of risk mitigation strategies.

A typical risk management framework consists of the following stages:

1. Risk identification: This stage involves identifying all possible risks that may affect an organization's assets, including internal and external risks.
2. Risk assessment: This stage involves assessing the likelihood and impact of each identified risk to determine the level of risk to the organization.
3. Risk prioritization: This stage involves prioritizing the identified risks based on their level of severity, so that resources can be allocated to manage the highest priority risks first.
4. Risk mitigation: This stage involves implementing risk management strategies to reduce or eliminate the identified risks. This can involve implementing controls, transferring the risk, or accepting the risk.
5. Risk monitoring: This stage involves monitoring the effectiveness of risk management strategies and assessing whether the risk has been effectively mitigated.
6. Risk communication: This stage involves communicating the risks and the risk management strategies to stakeholders, including employees, customers, and suppliers.

By following a risk management framework, an organization can take a proactive approach to managing risks and ensure that appropriate measures are in place to mitigate or eliminate potential threats.

Cybersecurity risk management involves several strategies for addressing risks, including risk acceptance, risk mitigation, risk transference, and risk avoidance.

1. Risk acceptance: In this strategy, the organization accepts the risk and decides to do nothing about it. This could be because the cost of mitigating the risk is too high or because the risk is deemed acceptable.
2. Risk mitigation: In this strategy, the organization takes steps to reduce the likelihood or impact of the risk. This can be achieved through implementing security controls, such as firewalls, encryption, and access controls.
3. Risk transference: In this strategy, the organization transfers the risk to a third party, such as an insurance company, by purchasing insurance policies that cover the potential losses from a cybersecurity incident.
4. Risk avoidance: In this strategy, the organization avoids the risk entirely by not engaging in certain activities or using certain technologies that are deemed too risky. For example, an organization might avoid using a particular software program that is known to have vulnerabilities.

It is important to note that risk management is a continuous process, and the strategies used to manage risks may change over time as the threat landscape evolves or as new vulnerabilities are discovered. Effective cybersecurity risk management requires a proactive and dynamic approach to identify, assess, and manage risks as they arise.

FAR 52 204 21

 

FAR 52.204-21 is a federal regulation that requires government contractors who handle federal contract information (FCI) to implement basic safeguarding measures on their information systems.

The regulation outlines 15 basic safeguarding requirements that contractors must implement to protect FCI from unauthorized access or disclosure. These requirements include things like limiting access to authorized users, ensuring the confidentiality of information, and reporting security incidents to the government.

The 15 basic safeguarding requirements under FAR 52.204-21 are:

1. Limit system access to authorized users, processes acting on behalf of authorized users, or devices.
2. Limit system access to the types of transactions and functions that authorized users are permitted to execute.
3. Verify and control the connections to external systems.
4. Employ cryptographic mechanisms to protect the confidentiality and integrity of transmitted information.
5. Maintain and implement software and firmware updates for all components of the system that are necessary to address known security vulnerabilities.
6. Maintain and implement security-relevant software and firmware updates within a time period consistent with risk, but not to exceed 30 days from the release of the update.
7. Generate and retain system audit logs and records to the extent needed to enable the detection, investigation, and response to security incidents.
8. Monitor system security alerts and advisories and take appropriate actions in response.
9. Perform periodic scans of the information system and real-time scans of files from external sources as files are being downloaded, opened, or executed.
10. Implement advanced authentication measures beyond username and password.
11. Ensure that the system automatically locks the account or session after a defined period of inactivity.
12. Employ mechanisms to limit the impact of potential malware propagation.
13. Maintain backup and restoration capabilities.
14. Implement processes to securely transfer data from one system to another.
15. Implement advanced protections for network protocols to ensure integrity and confidentiality of transmitted data.

In addition to the basic safeguarding requirements, the regulation also requires contractors to flow down the same requirements to any subcontractors who handle FCI.

Compliance with FAR 52.204-21 is mandatory for government contractors who handle FCI. Failure to comply with the regulation can result in penalties, including contract termination and legal action.

 

FISMA 2002 and FISMA 2014

 

The Federal Information Security Management Act (FISMA) is a United States law that establishes a framework for securing information and information systems owned or operated by federal agencies. The law was originally enacted in 2002 and was amended in 2014. Here are some of the key differences between FISMA 2002 and FISMA 2014:

1. Scope: FISMA 2002 primarily focused on securing information and information systems within federal agencies. FISMA 2014 expands the scope to include contractors and other non-federal entities that process or store federal information.
2. Continuous Monitoring: FISMA 2014 requires continuous monitoring of information systems and cybersecurity risks. This means that agencies must regularly monitor their systems to identify and address potential security vulnerabilities.
3. Risk Management: FISMA 2014 emphasizes risk management as a key component of information security. Agencies must conduct ongoing risk assessments and implement risk-based security controls.
4. Security Controls: FISMA 2014 places greater emphasis on using security controls that are appropriate for the specific risk level of an information system. Agencies must select and implement controls based on risk assessments and ongoing monitoring.
5. Reporting Requirements: FISMA 2014 streamlines reporting requirements for agencies, with a focus on providing more actionable information to stakeholders. Agencies must report on their security posture, vulnerabilities, and mitigation efforts in a standardized format.

Overall, FISMA 2014 represents a significant update to the original law, with a greater emphasis on risk management, continuous monitoring, and the use of appropriate security controls.

Risk Management Framework

 The Risk Management Framework (RMF) is a set of guidelines and processes used to manage and mitigate risks in information technology (IT) systems. The RMF is a standardized approach developed by the National Institute of Standards and Technology (NIST) to help organizations and government. 

Here's a detailed breakdown of the six-step Risk Management Framework (RMF) process:

1. Categorize: In this step, the information system is identified and categorized based on its mission, the information it processes, and the impact a security breach could have on the system, organization, or individuals. Categorization helps determine the level of security controls needed to protect the system adequately.

2. Select: In this step, the organization selects the appropriate security controls to mitigate the risks identified during the categorization step. The controls can be based on existing frameworks, such as the NIST Cybersecurity Framework, or tailored to the organization's specific needs.

3. Implement: In this step, the selected security controls are implemented and integrated into the system's design and operation. The implementation includes installing, configuring, and testing the controls to ensure they work as intended.

4. Assess: In this step, the effectiveness of the implemented security controls is assessed through testing, evaluation, and verification. The assessment is typically conducted by an independent third party, such as a security auditor or penetration tester.

5. Authorize: In this step, the organization reviews the assessment results and makes a risk-based decision about whether to authorize the system for operation. The decision considers the residual risk, which is the risk that remains after the security controls have been implemented.

6. Monitor: In this step, the organization continuously monitors the system's security controls, assesses their effectiveness, and makes necessary changes to mitigate new or emerging risks. The monitoring includes ongoing security assessments, incident response planning, and continuous improvement of the security posture.

By following this six-step process, organizations can manage cybersecurity risks in a structured and systematic way, ensuring that their information systems remain secure over time.

The Tallinn Manual

 

The Tallinn Manual 2.0 is a comprehensive guidebook that provides legal guidance for states and other actors regarding how international law applies to cyber operations. It is an updated version of the original Tallinn Manual, which was published in 2013.

The manual is named after the Estonian capital, Tallinn, where the first version was created under the auspices of the NATO Cooperative Cyber Defense Centre of Excellence (CCDCOE). The manual is not a binding legal document but provides authoritative guidance on how existing international law applies to cyber activities.

The Tallinn Manual 2.0 addresses a wide range of issues related to cyber operations, including the legal frameworks surrounding cyber warfare, the rules of engagement for cyber operations, the legal implications of cyber espionage, the responsibilities of states to prevent cyber-attacks, and the legal implications of state-sponsored cyber-attacks.

The Tallinn Manual 2.0 is divided into four major parts:

1. Part I: Introduction: This section provides an overview of the manual and the context in which it was developed. It outlines the structure of the manual and discusses the sources of law that are relevant to cyber operations.
2. Part II: International Law Applied to Cyber Operations: This section covers the application of international law to cyber operations. It addresses issues such as sovereignty, the law of armed conflict, human rights law, and state responsibility. It also discusses the principles of necessity and proportionality in the use of force in cyberspace.
3. Part III: Key Issues in the Law of Cyber Operations: This section covers a range of issues related to cyber operations, including cyber espionage, cybercrime, cyber terrorism, and the use of non-state actors in cyber operations. It also discusses the role of attribution in cyber operations and the legal implications of cyber weapons.
4. Part IV: Conclusions: This section summarizes the key findings of the manual and provides recommendations for policymakers, military planners, and legal advisors. It also discusses the need for further research and development of international law in the context of cyber operations.

Overall, the Tallinn Manual 2.0 provides a comprehensive and detailed analysis of the application of international law to cyber operations. It is an important resource for policymakers, legal advisors, and others involved in cybersecurity and international relations.