3.4.3 has a weight of -1 points

(Configuration Management Family) 3/9

Track, review, approve, or disapprove, and log changes to organizational systems.

Video:

Example of Sysytem Security Plan (SSP):

      1. System Security Plan (SSP) – Control 3.4.3: Managing System Changes Impacting Information Security

        Purpose: To ensure a structured process for reviewing, approving, or disapproving system changes that potentially affect information security.

        Scope: This plan covers all modifications, upgrades, or other changes made to the company’s IT systems, including hardware, software, and network configurations.

        1. Change Initiation:
          • All system modification requests impacting security have been introduced via the IT ticketing system.
          • Requests describe the proposed change, its reasons, impacts, and all related information.
        2. Change Control Board (CCB) Meeting:
          • Upon receiving a change request, the COO convenes a CCB meeting.
          • This meeting comprises the COO, FSO, and other relevant stakeholders.
          • Detailed discussions on the implications of the requested change have been conducted.
          • The primary focus is to determine any potential negative security impacts.
        3. Change Management Process:
          • Creation: Change requests are initiated in the IT ticketing system.
          • Review: The IT or security staff have performed a preliminary examination before presenting to the CCB.
          • Planning: Specifics of the change, including logistics and potential rollback strategies, have been outlined.
          • Authorization: The CCB has made an implement or not implement decision after comprehensive discussion.
          • Awaiting Implementation: This status indicates that the change is approved but hasn’t been actioned yet.
          • Implementation/Completion: The change has been successfully executed.
        4. IT Ticketing System:
          • Serves as a historical log of all changes made to organizational systems.
          • Every change status (from initiation to completion) is meticulously documented.
          • Periodic reviews, typically daily, ensure tickets are current and properly closed.
        5. Roles and Responsibilities:
          • System Security Administrator: The primary IT personnel responsible for cybersecurity, they oversee the change process. This role ensures all changes follow the prescribed process and maintains the IT ticketing system’s integrity.
          • COO: Convenes the CCB meetings and holds the final authority on change approvals.
          • FSO: Has participated in CCB meetings, offering insights from a facility security perspective.
        6. Periodic Review:
          • Regular intervals, ideally daily, are established to review the IT ticketing system, ensuring tickets are efficiently managed, updated, and closed.
          • This review guarantees continuous compliance, control, and optimal system performance.

      Example of Plan of Action and Milestones ( POA & M):

      Plan of Action and Milestones (POA&M) for Control 3.4.3

      Control Identifier: 3.4.3

      Control Title: Track, review, approve/disapprove, and log changes to organizational systems.

      System: User System

      Background: As a government contractor handling CUI and leveraging Microsoft GCC High, we are in the process of enhancing our system to be compliant with NIST 800-171 Control 3.4.3 requirements. The goal is to ensure a systematic and secure approach to managing system changes.

      Milestones:

      1. Finalize Change Management Process:

        • Task: Consolidate the draft change management process, ensuring all primary components are included.
        • Deadline: [Specific Date]
        • Responsibility: [Designated Team/Person]

      2. Formalize Change Control Board (CCB):

        • Task: Document the CCB structure, roles, and protocols.
        • Deadline: [Specific Date]
        • Responsibility: COO, FSO, [Other Relevant Roles]

      3. Appoint and Train the System Security Administrator:

        • Task: Finalize the role, responsibilities, and training for the System Security Administrator.
        • Deadline: [Specific Date]
        • Responsibility: [Designated Team/Person]

      4. Operationalize IT Ticketing System:

        • Task: Initiate the full operation of the IT ticketing system, ensuring integration with Microsoft GCC High, if possible.
        • Deadline: [Specific Date]
        • Responsibility: System Security Administrator

      5. Incorporate Configuration Control Mechanisms:

        • Task: Set up and document Configuration Control Boards or Change Advisory Boards, with particular attention to major system upgrades.
        • Deadline: [Specific Date]
        • Responsibility: [Designated Team/Person]

      6. Establish Comprehensive Audit Logging:

        • Task: Design and implement an effective audit log system within Microsoft GCC High to ensure all changes are meticulously logged.
        • Deadline: [Specific Date]
        • Responsibility: IT Team

      Resources Needed:

      • Expertise in Microsoft GCC High for optimal configuration and logging.
      • Dedicated personnel for monitoring and implementing change management.
      • Budget allocation for any required system upgrades or tools.

      Example in Microsoft GCC High:

      Using Microsoft Government Community Cloud (GCC) High, you can track, prove, and disprove role changes using a combination of Azure Active Directory (Azure AD) audit logs and Azure Role-Based Access Control (RBAC). Here’s an example of how you might do this:

      1. Establish Role Definitions:
        • Using Azure RBAC, define specific roles based on the principle of least privilege. Roles should be designed around the tasks a user or group needs to perform.
        • For instance, you can have roles like GCC High Data Reader, GCC High Data Contributor, etc.
      2. Implement Role Assignments:
        • Assign users or groups to the roles you’ve defined.
        • For example, assign a user to the GCC High Data Reader role if they only need to view data.
      3. Monitoring Role Changes:
        • Enable Azure AD audit logs to capture all changes made within the Azure AD environment.
        • Regularly monitor these logs to review any modifications to role assignments.
        • Using the Azure portal, go to Azure Active Directory > Audit logs to view a detailed list of directory activities.
        • Filter these logs for events related to role assignments (e.g., “Add member to role” or “Remove member from role”).
      4. Proving Role Changes:
        • When you need to prove a role change:
          • Navigate to the audit logs for the specific time frame in question.
          • Filter for the user and role change in question.
          • Document the specific entry (or entries) that show the role change, including timestamp, user who made the change, and any other pertinent details.
      5. Disproving Role Changes:
        • If there’s a claim that a role was added or removed, but you believe otherwise:
          • Review the audit logs for the period in question.
          • If no log entry matches the alleged change, it’s a strong indication that the claimed role change didn’t occur.
          • Document the absence of the log entry to disprove the change.
      6. Set Alerts for Unexpected Role Changes:
        • Set up alerts within Azure to notify administrators of any unexpected or unauthorized role changes.
        • For example, if someone is added to an elevated permissions role unexpectedly, the system could automatically alert designated individuals for verification.
      7. Periodic Reviews and Documentation:
        • Periodically review all role assignments to ensure they are still accurate and necessary. Remove or adjust roles as needed.
        • Maintain detailed documentation of role definitions, rationale for assignments, and any changes. This documentation can be vital for audits, investigations, and ensuring overall security compliance.
      8. Additional Measures:
        • Consider implementing Multi-Factor Authentication (MFA) for users with elevated permissions to reduce the risk of unauthorized changes.
        • Regularly review and update role definitions as the organization’s needs evolve and as Azure features are updated or changed.

      This process ensures transparency, accountability, and a strong security posture within Microsoft GCC High, especially when handling Controlled Unclassified Information (CUI) as a government contractor. 

      Example in Google Cloud Platform (GCP):

      If you’re using Google Cloud Platform (GCP) and its associated services, tracking role changes primarily revolves around Cloud Identity and Access Management (Cloud IAM). Here’s an example of how you might track, prove, and disprove role changes using GCP:

      1. Establish Role Definitions:

        • GCP’s Cloud IAM provides predefined roles that grant a set of permissions to users or service accounts.
        • You can also define custom roles based on specific needs using the principle of least privilege.

      2. Implement Role Assignments:

        • Assign users, groups, or service accounts to the predefined or custom roles you’ve established.
        • Role assignments can be made at the organization level, folder level, or individual project level.

      3. Monitoring Role Changes:

        • Enable audit logging for Cloud IAM in GCP.
        • Cloud IAM maintains an audit log of all changes made, such as role additions or deletions.
        • Access the Cloud Logging interface within the GCP console to review IAM logs.
        • Filter these logs for events related to role assignments (e.g., “SetIAMPolicy” or “CreateRole”).

      4. Proving Role Changes:

        • To prove a role change:
          • Navigate to the Cloud Logging interface for the specific time frame in question.
          • Filter for the user and role change event.
          • Document the specific log entry (or entries) that show the role change, including timestamp, user who made the change, and other relevant details.

      5. Disproving Role Changes:

        • To disprove a role change:
          • Review the audit logs for the period in question.
          • If no log entry matches the claimed change, you can reasonably infer the claimed role change did not take place.
          • Document the absence of the log entry to back up your conclusion.

      6. Set Alerts for Unexpected Role Changes:

        • Use Cloud Monitoring to set up alerts that notify administrators of unexpected or unauthorized role changes.
        • For example, if someone gets added to a role granting elevated permissions unexpectedly, the system could automatically notify designated admins.

      7. Periodic Reviews and Documentation:

        • Periodically review all IAM role assignments in your GCP environment to ensure they remain accurate and necessary.
        • Keep detailed documentation of role definitions, rationale for assignments, and changes. This documentation is essential for audits, investigations, and general security compliance.

      8. Additional Measures:

        • Implement Two-Factor Authentication (2FA) for GCP users, especially those with elevated permissions.
        • Regularly review and update role definitions, especially if the organization’s needs evolve or GCP features get updated.

      By following these steps, you can maintain an effective and transparent role management strategy within Google Cloud Platform. This is vital for ensuring the security and integrity of your cloud resources.

      RELEVANT INFORMATION:

      Tracking, reviewing, approving/disapproving, and logging changes is called configuration change control. Configuration change control for organizational systems involves the systematic proposal, justification, implementation, testing, review, and disposition of changes to the systems, including system upgrades and modifications. Configuration change control includes changes to baseline configurations for components and configuration items of systems, changes to configuration settings for information technology products (e.g., operating systems, applications, firewalls, routers, and mobile devices), unscheduled and unauthorized changes, and changes to remediate vulnerabilities. Processes for managing configuration changes to systems include Configuration Control Boards or Change Advisory Boards that review and approve proposed changes to systems. For new development systems or systems undergoing major upgrades, organizations consider including representatives from development organizations on the Configuration Control Boards or Change Advisory Boards. Audit logs of changes include activities before and after changes are made to organizational systems and the activities required to implement such changes. [SP 800-128] provides guidance on configuration change control.



      Resources to consider:

      Security Policy Document:

      This comprehensive document outlines the organization’s security policies and procedures, including information system access controls and the specific measures implemented, such as password protection, multi-factor authentication, and device access controls. It should also cover consequences of unauthorized access and the importance of user training and awareness.

      Asset Inventory and Access Control Sheet:

      Create a spreadsheet that lists all information system resources in your organization, such as laptops, desktops, servers, network devices, printers, scanners, mobile devices, and paper documents. Alongside each resource, include information about authorized users, access rights, and any access restrictions.

      User Account Management Log:

      Maintain a log to track user account creation, modification, and removal. Include details like the date of account creation, purpose, and the individual responsible for approving the account.

      Password and Multi-Factor Authentication Policy:

      Combine the password policy and multi-factor authentication policy into a single document. Outline the organization’s password requirements, including complexity, length, expiration, and regular password change, as well as the implementation of multi-factor authentication for an extra layer of security.

      Process and Script Accountability Log:

      Maintain a log that associates automated scripts and processes with the specific authorized user who initiated them. This ensures accountability and prevents the use of generic accounts for critical processes.

      Device Access Control and VPN Policy:

      Merge the device access control and VPN configuration documents into a single policy. Detail the measures for controlling device access, authentication mechanisms, and VPN configuration, including which devices are allowed to connect and the authentication methods used.

      Access Control Review and Monitoring Schedule:

      Create a schedule for periodic reviews of access controls, including the process for adding, modifying, or revoking access rights based on personnel changes or business needs. Also, document the monitoring mechanisms implemented to track access to the information system, including logs and reports of access attempts and unusual activities.

      User Training and Awareness Materials:

      Prepare training materials and conduct regular sessions for authorized users. Document the topics covered, the date of the training, and the attendees.