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.