Skip to content ↓ | Skip to navigation ↓

Today’s post is all about Control 18 of the CSIS 20 Critical Security Controls – Incident Response and Management (the last post pertained to Control 17).  Here I’ll explore the (9) requirements I’ve parsed out of the control (I used the PDF version, but the online version is here) and offer my thoughts on what I’ve found [*].

Key Take Aways

  1. Start. In my mind, Incident Detection and Response is as important as Asset and Configuration Management.  You simply need to do this at some level.  Find a group of people in your organization – they don’t all need to be in IT, by the way – who are interested and passionate about information security and start.  Get some executive buy-in before you start doing anything with authority.  Get legal involved for any “special” NDA’s the organization might desire for such a team – they may have temporary access to unlimited information, after all.
  2. Join the Community.  Incidents don’t just happen to your organization, they happen to everyone.  Know your local, regional, and National CERTs.  When you’re starting, set the expectation that the organization will share appropriate information with the appropriate external organizations (start with the CERTs).  EMC recently released some open source software to help facilitate incident information sharing, so take a look at how you might leverage that.
  3. Measure Well.  If there’s an area that benefits from effective measurement it’s this one.  If you need some metrics, look for the CIS Security Metrics 1.1.0 and pick up a book or two or three.  Hint: Some of these resources have incident-response-specific metrics laid out for you. Even if you’re starting small, get metrics in place – they will give you focus and provide you with ammunition to continue the mission.

Potential Areas Of Improvement

  1. Add Metrics And Tests. There are no metrics presented for Control 18.  I’m really dumbfounded by this.  See Key Take Away three above.

Requesting Feedback On

  • None.

Requirement Listing

  1. Description: Ensure that there are written incident response procedures that include a definition of personnel roles for handling incidents. The procedures should define the phases of incident handling.
    • Notes: If you don’t have an Incident Detection and Response program, start one. If you don’t know how to start one, make someone accountable for reading NIST guidance on the subject (go ahead and Google ‘NIST Incident Response’). Follow the outline of the guidance therein. Start small and basic then iterate.
  2. Description: Assign job titles and duties for handling computer and network incidents to specific individuals.
    • Notes: The major parts of NIST’s guidance will help here. When an incident is detected it should be triaged – who’s going to do that? Once it’s validated as a security-related incident, then the team needs to come together – who is on the team? Once the team comes together, who is the leader – who is assigned to be Incident Commander?
  3. Description: Define management personnel who will support the incident handling process by acting in key decision-making roles.
    • Notes: For on-the-fly incidents, someone needs to be in command, and this may not necessarily be a ‘manager.’ I would find the best person for the responsibility rather than assigning a manager; I would additionally understand if a manager were the best person for the responsibility.
  4. Description: Devise organization-wide standards for the time required for system administrators and other personnel to report anomalous events to the incident handling team, the mechanisms for such reporting, and the kind of information that should be included in the incident notification.
    • Notes: This is up to you. Do you want incidents to be reported immediately, then triaged, or would you prefer that some of your personnel triage then report upon validation? Additionally, if an incident is due to human error – and some certainly are – it’s important that no retribution happen for the fact of reporting the incident. It’s a fine line to walk, but you want everyone in the organization feeling comfortable with making mistakes. If they aren’t, they won’t report things and you’ll not have a complete picture of what happens in your enterprise.
  5. Description: This reporting should also include notifying the appropriate Community Emergency Response Team in accordance with all legal or regulatory requirements for involving that organization in computer incidents.
    • Notes: This requirement is all about information sharing. Do your tools support information sharing using IODEF, RID, STIX, TAXII, or other potentially proprietary means? If they don’t, then they should. Badger your vendors to integrate with CERTs out-of-the-box.
  6. Description: Assemble and maintain information on third party contact information to be used to report a security incident (i.e., maintain an e-mail address of or have a web page
    • Notes: I’m not sure this is warranted. We already have IETF-related standard practices in place to have addresses like ‘’ and ‘’ Do we really need another? I’m certainly not against this requirement, but I’m wondering what is more difficult: 1) Socializing a new common practice contact address, or 2) adding to the ‘charter’ of an already widely accepted contact address?
  7. Description: Publish information for all personnel, including employees and contractors, regarding reporting computer anomalies and incidents to the incident handling team.
    • Notes: Incident response should be prominently located on your intranet home page (i.e. Wiki, SharePoint). Of course, phone numbers need to be published and single points of failure should be addressed.
  8. Description: Such information should be included in routine employee awareness activities.
    • Notes: If your people don’t know how to detect and respond to an incident, they won’t be of any use to you. Make them aware, but understand that the human is the worst part of the security chain. You want to educate, but not inundate. You want to encourage and not discourage. You want to be clear and not confuse. Keep it simple, and realize that humans take time to learn.
  9. Description: Conduct periodic incident scenario sessions for personnel associated with the incident handling team to ensure that they understand current threats and risks, as well as their responsibilities in supporting the incident handling team.
    • Notes: It is such a disappointment that there are no metrics or tests associated with this Control. It could be argued that this control is more fundamental than many of the others given that it has no visibility/advanced requirements – all the requirements are considered quick wins or basic hygiene.

Other Controls Reviewed In This Series


A method and format explanation can be found at the beginning of Control 1.

Editor’s Note: This article was written by a former contributor to The State of Security who now resides with a non-profit group with an excellent reputation. We thank him for his opinions and perspective, and wish we could acknowledge him directly for his outstanding efforts on this series.


Related Articles:


P.S. Have you met John Powers, supernatural CISO