3.6.3 Test the Organizational Incident Response Capability

3.6.3 incident response testing assessment objectives

This was originally posted on LinkedIn. Check the original post and community discussion here!

On to the next requirement! 3.6.3 ๐“๐ž๐ฌ๐ญ ๐ญ๐ก๐ž ๐จ๐ซ๐ ๐š๐ง๐ข๐ณ๐š๐ญ๐ข๐จ๐ง๐š๐ฅ ๐ข๐ง๐œ๐ข๐๐ž๐ง๐ญ ๐ซ๐ž๐ฌ๐ฉ๐จ๐ง๐ฌ๐ž ๐œ๐š๐ฉ๐š๐›๐ข๐ฅ๐ข๐ญ๐ฒ.

This is post #5 in my series analyzing the top ten failed / misunderstood NIST SP 800-171 and #CMMC requirements according to DIBCAC. Incident response testing is the 9th most “other than satisfied” requirement.

The assessor expectation for 3.6.3 is that the organization has performed a drill or a test of their incident response procedures and capabilities.

โŒš๏ธ It is important to note that there is no actual minimum frequency or schedule in the requirement, however, most assessors will say that the minimum is one test per year. One test per quarter is a best practice for both compliance and security.

Why do companies fail ? My guess is that they either

โšฐ 1) think that real incidents count as tests *๐˜ต๐˜ฉ๐˜ฆ๐˜บ ๐˜ฅ๐˜ฐ๐˜ฏ’๐˜ต*,

๐Ÿ˜ณ 2) get intimidated by the idea of an incident response test and never do one, or

๐Ÿ˜ด 3) fail to show improvement from lessons learned.

This is NOT technical. You do not need special solutions. You do not need whiz-bang incident commandos. ๐Ÿ‘ฎ
Your regular system administration team can perform an incident response test. Because guess what – they are the ones that WILL respond to a real incident, at least at the beginning stages.

If in doubt, start with these steps.

1) Devise a scenario that would force you to go through all of your incident plans and procedures.
Where possible, make it realistic. “Tom clicked on phishing malware which compromised his cloud account credentials using ‘pass-the-hash’. Any data on Tom’s computer, or anything that could be accessed with his active cloud sessions, is being exfiltrated.”

2) Talk through how this incident would be handled. How is it discovered? Who discovers it? How would they document it? Who would they escalate to? How do they contain the damage?
As you talk through these steps, transcribe notes of what was discussed.

3) Check your policies and procedures as they become relevant. Do you have an incident response form? Try to fill it out. What was helpful? What didn’t work?

4) Test your ability to get help. Do you have a retained incident response firm? Do they answer the phone? Do you have cyber insurance? Would cyber insurance cover this scenario? Can you reach the CISO, President, Public Relations?

5) Test your ability to contact stakeholders. Can you submit this incident to dibnet? Do you know which customer is affected by the exfiltrated data?

6) Test your ability to investigate and gather forensics. Would your existing logs identify this malicious activity?

7) Identify lessons learned. Write down things you want to improve. Start change requests, or modify log settings, as appropriate.

8) Pack all these notes, filled-out forms, and lessons learned together as evidence. ๐Ÿ“‘

Shameless plug: The Kieri Compliance Documentation (Google it) includes all this.


Amira Armond is the President of Kieri Solutions, an Authorized C3PAO. She is a CMMC Provisional Assessor, Provisional Instructor, and has passed the examinations for both CCP and CCA. Amira is the chief editor for CMMCAudit.org and is the vice-chair of the C3PAO Stakeholder Forum.

Leave a Reply

Your email address will not be published. Required fields are marked *