3.6.2 has a weight of -5 points

(Incident Response Family) 2/3

Track, document, and report incidents to designated officials and/or authorities both internal and external to the organization.

Video

Example of System Security Plan (SSP):

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

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

Control Title: Tracking, Documenting, and Reporting Incidents

Control Description: The organization ensures timely and accurate documentation, tracking, and reporting of security incidents to both internal and external authorities.

Purpose: To provide a clear roadmap to address any gaps, deficiencies, or improvements in the implementation of Control 3.6.2, ensuring full compliance and enhanced security.

Plan of Action:

  1. Incident Response Plan and Form:

    • Action: Regularly update and revise the Incident Response Plan based on evolving threats and best practices.
    • Milestone: Quarterly review and update of the Incident Response Plan.
    • Target Completion Date: [Date + 3 Months]

  2. Training:

    • Action: Schedule and conduct semi-annual refresher training on cyber incident reporting and DIBNet compliance.
    • Milestone: Completion of the first semi-annual training session.
    • Target Completion Date: [Date + 6 Months]

  3. IT Ticketing System:

    • Action: Integrate automated alerting for high-priority incidents within the IT ticketing system.
    • Milestone: Successful integration and testing of the automated alert system.
    • Target Completion Date: [Date + 2 Months]

  4. Physical Incidents:

    • Action: Develop a specialized training module for the Facility Security Officer (FSO) on handling physical security incidents.
    • Milestone: Completion of the FSO training module.
    • Target Completion Date: [Date + 4 Months]

  5. External Reporting:

    • Action: Establish a quarterly audit to ensure all qualifying incidents are reported externally via DIBNet.
    • Milestone: Completion of the first quarterly audit with a focus on DIBNet reporting.
    • Target Completion Date: [Date + 3 Months]

  6. Awareness:

    • Action: Initiate a monthly security awareness campaign to emphasize the importance of incident reporting and documentation.
    • Milestone: Launch of the first monthly awareness campaign.
    • Target Completion Date: [Date + 1 Month]

  7. Continuous Monitoring:

    • Action: Set up a mechanism for continuous monitoring of incident response effectiveness.
    • Milestone: Implementation and testing of the continuous monitoring tool.
    • Target Completion Date: [Date + 5 Months]

Accountability: Each action item will be assigned to specific teams or individuals who will be responsible for ensuring timely completion.

Reporting: Monthly updates on POA&M progress will be provided to the relevant stakeholders.

Review: The POA&M will be reviewed and updated, if necessary, on a semi-annual basis.

Date Created: [Date]

Created By: [Your Name]

Next Review Date: [Date + 6 Months]

Example of Incident Response Form :

INCIDENT RESPONSE FORM

Date of Incident: [MM/DD/YYYY]

Time of Incident: [HH:MM AM/PM]

Reported By: [Name of the person reporting the incident]

Department/Team: [Department or Team of the reporter]

Incident Details:

1. Type of Incident (Check applicable):

  • Unauthorized access
  • Data breach
  • Malware infection
  • Physical security breach
  • Device theft/loss
  • Denial of Service attack
  • Misconfiguration
  • Others (please specify): _______________

2. Systems/Devices Affected:

  • [Device/System Name, IP Address, Location]

Description of the Incident:

[Provide a detailed description of the incident, including any observations, logs, or evidence that supports the categorization.]

Immediate Actions Taken:

[List any immediate actions that were taken upon discovering the incident.]

Impact Assessment:

  • High: Data exfiltration, system downtime, loss of PII, financial implications, etc.
  • Medium: Minor data exposure with limited potential harm.
  • Low: Minimal impact with no sensitive data involved.

Incident Escalation:

  • Notified IT/Security team
  • Notified management
  • Notified external partners/stakeholders (if applicable)
  • Others (please specify): _______________

Attachments:

[List any attached evidence, screenshots, logs, etc.]

Investigation & Remediation:

[Space for IT/Security team to document the findings of their investigation and the remediation actions taken.]

Reviewer’s Notes:

[Space for managerial or supervisory notes on the incident.]

Form Completed By: [Name of the person filling the form]

Date: [MM/DD/YYYY]

 

DIBNet Criteria :

The criteria for reporting incidents externally, especially via the Defense Industrial Base Network (DIBNet), are governed by the Defense Federal Acquisition Regulation Supplement (DFARS) clause 252.204-7012. The clause mandates that defense contractors report certain cyber incidents that affect Covered Defense Information (CDI) or the contractor’s ability to provide operationally critical support.

Here are some criteria based on the DFARS clause:

  1. Type of Information Compromised: Any incident where Covered Defense Information (CDI) is potentially compromised or exfiltrated needs to be reported. CDI can include Controlled Technical Information, Export-Controlled Information, Critical Information, and more.

  2. Incident Impact: Any cyber incident that may impact the contractor’s ability to provide “operationally critical support”. This means that if the cyber incident affects, or can potentially affect, the defense contractor’s delivery of essential services to the DoD, it needs to be reported.

  3. Compromised System: Incidents that occur on “covered contractor information systems”. Essentially, if the system where the incident occurred is meant to store, process, or transmit CDI or is part of the contractor’s IT system, then it’s under this criteria.

  4. Evidence of Malicious Software: If during the course of the investigation, malicious software (malware) is discovered, that malware and information about its activity must be reported.

  5. External Access: Any incident that provides evidence of unauthorized external access to a contractor’s system or network.

  6. Affected Tools: The compromise of any tools, software, or applications that are primarily intended for use in the development, deployment, execution, maintenance, or analysis of cyber capabilities.

For incidents that meet these criteria:

  • The contractor must report the cyber incident to the DoD via DIBNet within 72 hours of discovering the incident.

  • Along with the report, contractors might be required to share any malicious software that was discovered, as well as provide access to the affected equipment or information for forensic analysis, if deemed necessary by the DoD.

Contractors should always refer to the latest DFARS clause and DoD guidelines when determining the reporting criteria and procedures, as regulations can evolve over time.

 

RELEVANT INFORMATION:

Tracking and documenting system security incidents includes maintaining records about each incident, the status of the incident, and other pertinent information necessary for forensics, evaluating incident details, trends, and handling. Incident information can be obtained from a variety of sources including incident reports, incident response teams, audit monitoring, network monitoring, physical access monitoring, and user/administrator reports. Reporting incidents addresses specific incident reporting requirements within an organization and the formal incident reporting requirements for the organization. Suspected security incidents may also be reported and include the receipt of suspicious email communications that can potentially contain malicious code. The types of security incidents reported, the content and timeliness of the reports, and the designated reporting authorities reflect applicable laws, Executive Orders, directives, regulations, and policies. [SP 800-61] provides guidance on incident handling.



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.