3.12.1 has a weight of -5 points

Cybersecurity & CUI System Security Plan (SSP) – Control 3.12.1 – Assess Security Controls to Determine Effectiveness

1. Introduction

This SSP was established to present an organized approach to assess the effectiveness of security controls under the Cybersecurity & CUI Plan in line with Control 3.12.1. The document underscored the importance of proactive security measures and continuous improvement in the face of ever-evolving cyber threats.

2. Change Control Board (CCB)

A CCB board has been put in place with the critical responsibilities of:

• Conducting annual reviews to assess the effectiveness of all security controls.
• Implementing new controls based on the findings of the reviews.
• Updating the SSP as necessary to reflect changes in controls and security procedures.

3. Quarterly Risk Management Meetings

Implementation of Control 3.12.1 was realized through quarterly risk management meetings. During these sessions:

• Security controls were thoroughly reviewed.
• Root Cause Analyses (RCAs) were carried out to pinpoint the core issues behind security lapses or breaches.
• The organization deliberated on whether the security controls in place were effective or if there were superior alternatives that should have been adopted.

4. Incident Response Plan & Procedures

As part of the broader risk management strategy, and especially during the quarterly risk management meetings:

• The organization consistently aimed to refine its security posture.
• Emerging cybersecurity threats were acknowledged and addressed.
• Staying abreast of the dynamic nature of security threats was deemed crucial, as the threats faced then differed from those encountered previously.

5. Expert-Run Risk Management Meetings

In a commitment to uphold high security standards:

• Expert-led risk management meetings were organized.
• These meetings, helmed by seasoned professionals, ensured a comprehensive analysis of current risks and the formulation of effective strategies.

Plan of Action & Milestones (POA&M) – Control 3.12.1 – Assess Security Controls to Determine Effectiveness

I. Introduction:

This POA&M provides a strategic roadmap to assess the effectiveness of security controls in line with Control 3.12.1 under the Cybersecurity & CUI Plan. It outlines specific actions, responsibilities, and timeframes to ensure that security controls are continuously reviewed and enhanced as required.

II. Action Items:

1. Establishment of Change Control Board (CCB)

   • Description: Formalize the CCB with representatives from IT, Security, and Management.
   • Responsible Party: Cybersecurity Manager
   • Target Completion Date: [Insert Date]
   • Status: Not Started

2. Conduct Annual Review of Security Controls

   • Description: The CCB will execute an annual comprehensive review of all existing security controls.
   • Responsible Party: CCB
   • Target Completion Date: [Insert Date]
   • Status: Not Started

3. Quarterly Risk Management Meetings

   • Description: Organize quarterly meetings to review security controls, evaluate Root Cause Analyses (RCAs), and discuss possible improvements.
   • Responsible Party: Risk Management Team
   • Target Completion Date: [Insert Date for First Meeting]
   • Status: Not Started

4. Implement & Review Incident Response Plan & Procedures

   • Description: Develop and/or review the incident response plan to handle cybersecurity threats effectively. This plan should be tested biannually.
   • Responsible Party: Cybersecurity Team
   • Target Completion Date: [Insert Date]
   • Status: Not Started

5. Conduct Expert-Led Risk Management Meetings

   • Description: Engage external security experts to lead specialized risk management meetings, focusing on emerging threats and advanced mitigation techniques.
   • Responsible Party: External Cybersecurity Consultant
   • Target Completion Date: [Insert Date for First Expert-Led Meeting]
   • Status: Not Started

III. Milestones:

1. Formalization of CCB

   • Milestone Date: [Insert Date]
   • Details: Finalize CCB membership and roles.

2. Completion of First Annual Review

   • Milestone Date: [Insert Date]
   • Details: Complete the first annual review of security controls by the CCB.

3. Initiation of Quarterly Risk Management Meetings

   • Milestone Date: [Insert Date for First Meeting]
   • Details: Hold the inaugural quarterly risk management meeting.

4. Incident Response Plan Testing

   • Milestone Date: [Insert Date for First Test]
   • Details: Successfully test the incident response plan in a simulated environment.

5. First Expert-Led Risk Management Meeting

   • Milestone Date: [Insert Date for First Expert-Led Meeting]
   • Details: Engage with external experts for a deep dive into risk management and control effectiveness.

IV. Monitoring & Reporting:

Regular updates on the POA&M will be provided to senior management on a [quarterly/biannual/annual] basis. The CCB will oversee the execution of the action items and ensure timely completion. Any delays or changes in the plan will be documented and communicated appropriately.

Document Structure for an RCA

1. Introduction
   • Description of the incident or problem
   • Date, time, and location of the incident
2. Background
   • Brief history of operations leading up to the incident
   • Any previous incidents of a similar nature or related events
3. Immediate Causes
   • Direct causes of the incident (e.g., equipment failure, human error)
4. Underlying Root Causes
   • The fundamental issues that led to the immediate causes
5. Analysis Method Used
   • Explanation of the RCA method/tools used (e.g., 5 Whys, Fishbone/Ishikawa diagram, Fault Tree Analysis)
6. Recommendations and Corrective Actions
   • Suggested actions to address the root causes and prevent recurrence
7. Implementation Plan
   • Steps for implementing the recommended actions, responsible parties, and timelines
8. Conclusion
   • Summary of findings and reaffirmation of commitment to safety and improvement
9. Appendices
   • Any supporting documents, diagrams, or photographs

Key Questions to Include in an RCA

1. Descriptive Questions
   • What exactly happened?
   • When and where did it happen?
   • Who discovered the issue, and how was it detected?
2. Immediate Cause Questions
   • What were the direct causes of the incident?
   • Were there any failures in equipment, systems, or processes?
   • Were there human errors? If so, what were they?
3. Root Cause Questions (5 Whys method can be useful here)
   • Why did the incident occur?
   • Why was the immediate cause not detected or prevented?
   • What systemic issues or processes allowed this to happen?
   • Were there training or knowledge gaps that contributed?
   • Were there external factors that influenced the incident?
4. Corrective Actions Questions
   • What can be done to address the root causes identified?
   • Are there changes required in processes, equipment, or training?
   • What can be done to prevent similar incidents in the future?
5. Implementation and Follow-up Questions
   • Who is responsible for implementing the corrective actions?
   • What are the timelines for implementation?
   • How will the effectiveness of the corrective actions be measured?
   • When and how will a follow-up review be conducted?

5 Whys:

1. • Purpose: A simple and straightforward method to drill down to the root cause of a problem by asking “Why?” multiple times (typically five, but it can vary).
   • How it Works: Begin with the immediate problem and ask “Why did this happen?” For each answer, ask “Why?” again until a root cause is identified.
   • Example:
     1. Problem: The server crashed.
     2. Why? – The server overheated.
     3. Why? – The server room’s air conditioning (AC) failed.
     4. Why? – The AC’s maintenance was overdue.
     5. Why? – Maintenance reminders were not set.
     6. Root Cause: Lack of a maintenance reminder system.
2. Fishbone/Ishikawa Diagram:
   • Purpose: A graphical method to identify potential causes for a problem by organizing them into categories.
   • How it Works: The problem is the “head” of the fish, and the “bones” branching off are categories of potential causes. Sub-branches can represent more detailed causes.
   • Common Categories: Methods, Machines, People, Materials, Measurements, and Environment.
   • Example: For a problem like “Defective Product Output”:
     • Method: Lack of training
     • Machines: Malfunctioning equipment
     • People: Fatigue
     • Materials: Sub-standard raw materials
     • Measurements: Inaccurate calibration
     • Environment: High humidity affecting quality
3. Fault Tree Analysis (FTA):
   • Purpose: A top-down approach to analyze the combinations of failures that could lead to a system failure (often used in reliability engineering and safety systems).
   • How it Works: It starts with an undesired event (top event). Using logic gates (like AND, OR), the event is broken down into its potential causes. This process continues until reaching basic failures or events.
   • Symbols: Common symbols include circles for basic events, rectangles for intermediate events, and logic gates to represent combinations of events.
   • Example:
     • Top Event: Car doesn’t start.
       • AND Gate: (All conditions below must be true)
         • Battery is dead (Basic Event)
           • OR Gate: (Any of the conditions below)
             • Lights were left on (Basic Event)
             • Alternator is broken (Basic Event)

Creating a Change Control Board (CCB) is a systematic process that involves defining roles, responsibilities, and workflows to effectively manage and approve changes within an organization, especially concerning IT systems, projects, or procedures. Here’s a step-by-step guide to establishing a CCB:

1. Define the Purpose of the CCB:

• Understand why you need a CCB. Typically, CCBs are created to ensure that all proposed changes are reviewed for potential impacts, benefits, and risks before they’re approved and implemented.

2. Determine Scope:

• Decide on the range of changes the CCB will oversee. It could be IT infrastructure changes, software updates, project modifications, process adjustments, etc.

3. Select Members:

• Choose a cross-functional team representing various departments that the changes might impact. Common roles in a CCB include:
  • Chairperson: Manages meetings and has the final say on decisions.
  • Technical Experts: Provide insights into the technical feasibility and implications of proposed changes.
  • Business/Operational Representatives: Offer a business perspective, ensuring changes align with organizational goals and won’t disrupt operations.
  • Quality Assurance or Risk Management Representative: Assesses potential risks associated with the changes.
  • Project Managers: Especially if the CCB is overseeing project-related changes.

4. Define Roles and Responsibilities:

• Clearly outline what’s expected of each CCB member. This includes preparing for meetings, evaluating proposed changes, and communicating decisions.

5. Develop a Change Management Process:

• Define how changes will be proposed, reviewed, approved, and documented. This might look something like:
  • Submission of a formal Change Request (CR) with details about the proposed change, its reasons, potential impacts, benefits, risks, etc.
  • Preliminary review to ensure the CR is complete and worth discussing.
  • CCB meeting where the CR is discussed, evaluated, and a decision (approve/reject/defer) is made.
  • Communication of the decision to the relevant stakeholders.
  • Documentation of the CR, discussions, and decision for future reference.

6. Set Meeting Cadence:

• Decide how often the CCB will meet. This can be regular (e.g., weekly, bi-weekly) or ad-hoc based on the volume of CRs.

7. Create Templates and Documentation:

• Design standardized forms for change requests, assessments, decisions, etc. This ensures consistency and comprehensiveness in how changes are proposed and reviewed.

8. Establish Communication Protocols:

• Determine how decisions will be communicated to stakeholders and how feedback will be collected and addressed.

9. Review and Refine:

• Periodically assess the effectiveness of the CCB and make necessary adjustments. This might be based on feedback from members, the number of changes successfully implemented, disruptions caused by approved changes, etc.

10. Training:

• Provide initial and ongoing training to CCB members on the change management process, evaluation criteria, tools, etc.

11. Pilot the CCB:

• Before fully institutionalizing the CCB, run a pilot phase where a limited number of changes are reviewed. This helps iron out any kinks in the process.

12. Full Implementation:

• • Once confident in the CCB’s process and effectiveness, roll it out for broader organizational use.