Introduction
Earlier in this blog series, we discussed the importance of system audit logs and the regular review of those logs, and system alerts for events that lead to a failure in the audit logging process. In this blog, we will look at what happens when information is received, in the form of system alerts or otherwise, that indicates the possibility of an incident.
Incident Response readiness not only requires advance system configuration and monitoring controls for detecting system anomalies and audit failures, it also necessitates having a plan of action in the event an incident is confirmed, training those that would potentially be involved in the incident handling process, and periodically testing the plan to ensure readiness at all times.
The Federal Information Security Modernization Act of 2014 (FISMA) defines the term “incident” as “an occurrence that (A) actually or imminently jeopardizes, without lawful authority, the integrity, confidentiality, or availability of information or an information system; or (B) constitutes a violation or imminent threat of violation of law, security policies, security procedures, or acceptable use policies.”[1]
Establish the Capability
| Control | |
| 3.6.1 | Establish an operational incident-handling capability for organizational systems that includes preparation, detection, analysis, containment, recovery, and user response activities |
Incident Response Plans should include the following six key elements:
Preparation
Preparation activities include actions such as creating an incident response methodology, establishing an Incident Response Team, performing a criticality analysis to prioritize system recovery plans, developing and implementing training, and ensuring affiliated organizational procedures and documentation are up to date (corrective action procedures, interested party contact list, etc.).
Detection
Monitoring of system logs and proactive networking with other industry professionals and organizations are examples of activities that aid in the detection of anomalies that may point to an incident.
Analysis
Once an incident has been detected, immediate action should be taken to invoke the Incident Response Plan and determine basics such as “when did the event happen?”, “have other systems been impacted?”, “what is the scope of the compromise”, and “how does it affect operations”? In addition to identifying what data has been breached, investigation into the cause of the security breach must be undertaken. Analysis may include actions such as reviewing system logs and other supporting data. The “forensic analyst” must keep the entire Incident Response Team up to date on potential further threats and risks.
Evidence collected during analysis must be saved in a restricted repository in the event of a law enforcement investigation. Consider implementing chain of custody procedures for the data.
NIST SP 800-86, Guide to Integrating Forensic Techniques into Incident Response, provides information on digital forensics processes.[2]
Containment
NIST SP 800-61 – Computer Security Incident Handling Guide[3] states that, “Containment provides time for developing a tailored remediation strategy.” Full resolution of incidents causes may take significant time, and it is essential to know how to triage before further damage is done. Possible containment actions such as isolation of a system or network segment or a coordinated shutdown should be considered. Note that different systems may require different containment strategies!
Recovery
Having a Recovery Plan in place will help your organization resume business activities in as timely a fashion as possible. Recovery Plans should include prioritized lists of critical business functions and minimum resources needed to restore operations. Recovery Time Objectives (RTO) should be established, as well as the roles and responsibilities those in your organization will need to undertake.
User Response
Potential actors in an incident response event will require training specific to the role each actor will need to play. This may include senior leadership, system owners and administrators, Human Resource and Legal representatives, security personnel, operations personnel, and the organization’s safety team.
Incidents
| Control | |
| 3.6.2 | Track, document and report incidents to designated officials and/or authorities both internal and external to the organization |
DFARS 252.204-7012 includes a Cyber-Incident Reporting clause that requires the contractor to “conduct a review for evidence of compromised covered defense information, including “analyzing covered contractor information systems that were part of the cyber incident”, and then “rapidly report” cyber incidents to the DoD. A Medium Assurance Certificate is required to register on the DoD cyber reporting site.
Your organization may also have contractual obligations for reporting incidents to interest third parties. Incident reporting requirements can be different from contract to contract, so a repository for tracking those requirements should be kept in a location accessible to the Incident Response Team.
Test the Capability
| Control | |
| 3.6.3 | Test the organizational incident response capability |
Testing the Incident Response Plan may also be a contractual obligation, as well as a legal one. Practically, periodic exercising of the plan enables the organization to evaluate the effectiveness of the processes and also to let those potentially involved to become more familiar with their responsibilities.
There are various methods for testing an Incident Response Plan. The two methods below are among the most common:
- Tabletop Exercise – Key personnel in roles aligned with the Incident Response Team gather to discuss a hypothetical incident. Advanced planning should be done to determine the goal for the exercise and the hypothetical scenario.
- Walkthrough – The team works its way through the plan as written, and takes physical action to verify that aspects of the plan are viable, such as calling personnel to confirm the contacts list is current or examining systems to ensure asset lists are up to date.
Need Help?
If you are an Organization Seeking Certification (OSC) and are overwhelmed by the enormity and complexity of CMMC, consider professional services to help you plan, implement, and maintain compliance and ensure uninterrupted eligibility for DoD work.
FoxGuard Solutions delivers reliable, secure and configurable solutions to solve technology and compliance challenges faced by critical infrastructure entities. With over four decades of experience, our team focuses on delivering customized cybersecurity and compliance solutions.
Our services will help guide your organization through the Discovery, Planning, Execution and Maintenance phases necessary to allow your organization to attain Cybersecurity Maturity Model Certification (CMMC). Our team of experts will partner with you to review existing policies, processes, procedures, and technical controls to identify any gaps with CMMC requirements. An execution plan will be created that aligns with your needs, budget and timeline, and which outlines a recommended approach to attain CMMC.
As a Microsoft Gold Certified Partner, FoxGuard Solutions has experience in delivering both on-premise as well as cloud-based solutions to assist you with your compliance needs.
FoxGuard Solutions is ISO 9001 and ISO 27001 certified and is a CMMC-AB Registered Provider Organization.
Please visit https://foxguardsolutions.com/cmmc/ for more information.
[1] 44 U.S.C. § 3552(b)(2)
[2] https://csrc.nist.gov/publications/detail/sp/800-86/final
[3] https://csrc.nist.gov/publications/detail/sp/800-61/rev-2/final