When Prevention Fails, Incident Response Begins

Published: 2015-04-27. Last Updated: 2015-04-27 16:37:32 UTC
by Richard Porter (Version: 1)
1 comment(s)

          I’ve been asked a few times this year ($dayjob) to discuss and review incident handling practices with some of our clients. This topic seems to have come up to the surface again, and with some breaches getting main-stream coverage, it only makes sense. Taking a look at some of our past posts here on the ISC, I was pleasantly greeted with a long history on this topic (see list below).

For those that have not seen it yet should read the 2015 Verizon Data Breach Report  (DBIR) [1]. A couple of notes on DBIR (very brief as it seems everyone is reviewing it [2]), we are getting better. The entry on page 5 that is called out stuck with me “In 70% of the attacks where we know the motive for the attack, there’s a secondary victim.[1]”  Some homework, go read page 5!

The second take away from DBIR tells me that we can prevent quite a bit. Remember where prevention stops, incident handling starts. If you jump to page 15 a big lesson that you’d THINK we’ve learned? PATCH“99.9% of the exploited vulnerabilities had been compromised more than a year after the associated CVE was published.[1]

Some Observations

In my travels it has been observed that more companies are starting to negotiate contracts with outside incident management firms proactively. This is a great sign, one thing I am still noting an area of weakness is in the internal incident handling skills. We should still have some staff that at least understands the process (thinking evidence handling here). These staffers should act as both liaison to contract staff and aid with guidance to management.

Most, if not all, companies that I have visited have solid policies and standards in place. Along with a surprising number that including marketing and public relations. It seems we are getting a little better here. Note: Have a list of those that are cleared to speak to any media, your average journalist will eat an engineer alive. Know when to say “I cannot comment on that”

 

Parting references I use for incident management:

http://csrc.nist.gov/publications/nistpubs/800-61rev2/SP800-61rev2.pdf

http://csrc.nist.gov/publications/nistpubs/800-86/SP800-86.pdf

http://csrc.nist.gov/publications/nistpubs/800-83/SP800-83.pdf

http://www.ncix.gov/publications/reports/fecie_all/Foreign_Economic_Collection_2011.pdf

http://energy.gov/sites/prod/files/oeprod/DocumentsandMedia/26-CIP_CyberAssessmentGuide.pdf

http://www.ietf.org/rfc/rfc2350.txt

http://www.cert.org/csirts/resources.html

http://www.iso27001security.com/html/27035.html

http://www.itu.int/en/ITU-D/Cybersecurity/Documents/ALERT.pdf

http://www.itu.int/ITU-D/membership/portal/index.asp?Name=45047

http://www.itu.int/ITU-D/asp/CMS/Events/2011/CyberCrime/S6_Mohamad_Sazly_Musa.pdf

http://csrc.nist.gov/groups/SMA/fasp/documents/incident_response/CIRT-Desk-Reference.pdf

The Practice of Network Security Monitoring: Understanding Incident Detection and Response by Richard Bejtlich Link: http://amzn.com/1593275099

http://www.sans.org/reading-room/whitepapers/incident/incident-handling-process-small-medium-businesses-1791?show=incident-handling-process-small-medium-businesses-1791&cat=incident

http://www.sans.org/reading-room/whitepapers/incident/computer-incident-response-team-641?show=computer-incident-response-team-641&cat=incident

http://www.cert.org/csirts/csirt_faq.html

http://www.veriscommunity.net/doku.php

http://www.ietf.org/rfc/rfc2350.txt

References

[1]  http://www.verizonenterprise.com/DBIR/

[2]  http://researchcenter.paloaltonetworks.com/2015/04/2015-verizon-data-breach-investigations-report-dbir-insights-from-unit-42/

1 comment(s)

Comments

Useful document from Enisa on this topic: Good Practice Guide for Incident Management : https://www.enisa.europa.eu/activities/cert/support/incident-management

Diary Archives