What You Need to Know About Cyber Incident Reporting

What You Need to Know About Cyber Incident Reporting

Defense contractors operate in one of the most heavily regulated industry sectors of all. They face a wide range of threats from various sources, such as insider threat, social engineering, and state-sponsored attacks. Taking every possible step to achieve the standards demanded by the DFARS 252.204-7012 framework is essential to mitigate those risks and validate your efforts to remain compliant.

The DoD requires that cybersecurity incidents be reported within 72 hours of their discovery, and there is a raft of information that must be gathered to provide a complete report. This can be done with informational triage, which begins with advance preparation for deployment when an incident occurs. Even despite the very short reporting window, organizations must provide 90 days’ worth of monitoring data from the affected systems for conducting forensic analysis.

Reporting versus incident response

Incident response is one of the 14 requirements outlined in the NIST 800-171 framework, upon which the DFARS rules are based. Reporting is a key part of any incident response plan, but they are not the same thing. Rather, incident response also includes the other actions taken to mitigate the effects of a data breach, such as disaster recovery and forensic analysis. The first thing to do following an incident, as to gather all the information necessary to support the follow-up investigation.

The moment a data breach has been discovered, the first thing to do is identify which systems, applications, and user accounts were affected. Any interdependencies should also be included in the report, which you will need to pass on to the DoD for further investigation. Gathering all this information is next to impossible if you do not already have a sufficient incident response process in place already. However, with comprehensive monitoring systems in place, it should be possible to quickly gather all facts specific to the incident.

Defining roles and responsibilities

In cybersecurity, an ad-hoc response will lead to ad-hoc results. For example, if everyone in the IT team is considered an incident responder, then chances are no one will have a clear picture of their roles and responsibilities. This might sound obvious, but it is something that is surprisingly easy to overlook. For example, an outdated incident response plan might specify a particular employee whose responsibility it is to report a cybersecurity incident to the DoD, but if they have since left the company, then there could be a serious delay.

Every incident response plan should have a clear set of workflows with specific individuals in the organization tasked with overseeing them. This includes incident reporting, information-gathering, remediation, and any other related tasks. There should also be a backup plan, just in case the regular incident responder is unavailable. The processes should be formalized and documented, not to mention updated regularly to ensure they remain in accordance with both internal policies and externally mandated regulations.

The importance of training and awareness

Formally reporting a cybersecurity incident to the DoD will be the responsibility of a particular individual in your organization. However, it is also important to remember that security is the responsibility of everyone on your team. Regardless of how minor an incident might seem, the first person to discover it could be anyone in the workspace. No matter who discovers it, they should know who to report to, and then the security team can take over to determine whether the event was a real threat or a false positive.

Creating a culture of accountability requires ongoing security awareness training. After all, the security team cannot be everywhere at all times, which is why all employees need to be the eyes and ears of your organization. This is also important because anyone is a potential target, so everyone needs to understand their own responsibilities regarding reporting incidents.

Managing your incident response

Reporting is just one part of any full-scale incident response plan. Once an incident has been reported, it is important to collect any further information that might help with the investigation into the nature and circumstances of the incident. Furthermore, any affected systems should be instantly isolated from others, and new controls should be put in place as soon as possible to prevent ongoing or future attacks of a similar nature. Finally, you may need to prepare legal and public statements as well as produce evidence that the incident was not a result of your failing to comply with the DFARS standards.

Charles IT helps ensure your business is up to speed with their latest NIST 800-171 standards. Get in touch today to schedule your first security audit for DFARS compliance!

Most tech consulting starts with “Press 1”

We just like to start with “Hello.”