[SANS ISC] Investigating Security Incidents with Passive DNS

I published the following diary on isc.sans.org: “Investigating Security Incidents with Passive DNS“. Sometimes when you need to investigate a security incident or to check for suspicious activity, you become frustrated because the online resource that you’re trying to reach has already been cleaned. We cannot blame system administrators and

[The post [SANS ISC] Investigating Security Incidents with Passive DNS has been first published on /dev/random]

Continue reading [SANS ISC] Investigating Security Incidents with Passive DNS

FIR (Fast Incident Response) – Cyber Security Incident Management Platform

FIR (Fast Incident Response) is a cyber security incident management platform designed for agility and speed. It allows for easy creation, tracking, and reporting of cybersecurity incidents. In the fields of computer security and information technology… Continue reading FIR (Fast Incident Response) – Cyber Security Incident Management Platform

Nip Those Incidents in the Bud!

I’m dating myself here, but I used to love to watch the Andy Griffith Show. I liked Andy’s calm demeanor as he tried to raise little Opie. Barney Fife was his neurotic sidekick. I enjoyed this exchange between the two of them as they discussed raising kids: Barney Fife: Well, today’s eight-year-olds are tomorrow’s teenagers.…

The post Nip Those Incidents in the Bud! appeared first on Speaking of Security – The RSA Blog.

Continue reading Nip Those Incidents in the Bud!

FIRST TC Amsterdam 2017 Wrap-Up

Here is my quick wrap-up of the FIRST Technical Colloquium hosted by Cisco in Amsterdam. This is my first participation to a FIRST event. FIRST is an organization helping in incident response as stated on their website: FIRST is a premier organization and recognized global leader in incident response. Membership

[The post FIRST TC Amsterdam 2017 Wrap-Up has been first published on /dev/random]

Continue reading FIRST TC Amsterdam 2017 Wrap-Up

Before, During and After: Dealing With Attacks and Applying Effective Incident Management

A planned, communicated, rehearsed and organizationally tailored incident management program is central to an effective security strategy.

The post Before, During and After: Dealing With Attacks and Applying Effective Incident Management appeared first on Security Intelligence.

Continue reading Before, During and After: Dealing With Attacks and Applying Effective Incident Management

[SANS ISC Diary] Full Packet Capture for Dummies

I published the following diary on isc.sans.org: “Full Packet Capture for Dummies” When a security incident occurred and must be investigated, the Incident Handler’s Holy Grail is a network capture file. It contains all communications between the hosts on the network. These metadata are already in goldmine: source and destination

[The post [SANS ISC Diary] Full Packet Capture for Dummies has been first published on /dev/random]

Continue reading [SANS ISC Diary] Full Packet Capture for Dummies

Cyber Security Incident Management, Response and Recovery Guidance

Yesterday I spoke at the R3 Summit (Resilience, Response and Recovery) in London, on the topic of Cyber Security Incident Management and response. Given the Q & A and the ensuing discussion after my talk, the attendees were particularly interested in my views on incident containment ahead of recovery. Below is a summary of what I said.


Step 1: Incident Management Planning and Preparation
The most crucial part of incident management is the preparation, it is important to always consider cyber security incidents as a ‘When’ not an ‘If’ as you plan ahead. So here’s my ‘brain dump’ of an incident management planning strategy:

  • A company Cyber Security Incident Management Policy
    • It must define what the company (aka the board) consider as a cyber security incident
  • Cyber Security Incident notification communications channel or even better a reporting application/system
    • Upon identifying an incident who do staff notify (the incident management team)
    • Staff awareness of how to detect and report incidents is a key element.
  • Verify the ability to detect incidents, not just IT system alerts, but human side (staff)
  • Document the Incident Management Team and Response Plan
  • Incident Management Team
    • A pool of contacts with responsibility or expertise covering every possible type and aspect of a cyber security incident
    • An Incident Management Team will be assembled based on what’s required for specific cyber security incident types
      • Note. Every team member must play an active part or not be in the team
    • Communication plan i.e. document team member phone numbers and a have dedicated incident management telephone conference call line
      • Do not rely on computer IT systems like email (what if they are taken down)
    • Tools (forensics) and an ability to IT access systems and logs (to investigate and obtain incident facts)
  • Business Risk Assessment
    • The business critical services must be risk assessed, so the business impact of any incident can be known and understood by the incident management team
  • Cyber Threat Assessment
    • Performing a cyber threat assessment against critical business services, aside from possible risk mitigation, threat assessing enables various cyber attack scenarios to be documented and incident response planned for and tested. Threat assessments can play a key role in helping the cyber security incident management teams prepare for incidents.
  • Test the Cyber Security Incident Management Plan regularly. (at the very least annually)
    • Use different attack / breach scenarios
  • Always keep Incident Management Team documentation up to date (at least a quarterly review of documentation)

Step 2: Incident Identification
Upon initially identifying a cyber security incident, the very first question to answer is; what is the actual or potential business impact of the incident? On the face of it this can be a difficult question to answer, as the facts tend to be rather scant upon initial incident identification. However, the worse case scenario, the potential business impact, must be regarded as the actual business impact until facts are presented, through incident investigation, to prove otherwise. For example, take an online database holding 10,000 user accounts, in the space of a few hours, 20 users report via the company helpdesk that their accounts have been hacked into. Without further facts it should be assumed the entire database, all 10,000 user accounts, are compromised. This should remain the case until further facts are established to disprove which accounts have been and not been compromised. Cyber security incident investigations can take weeks to complete, and may never reach a conclusive finding on the scope of IT system or data compromise, in which case the worst case scenario must remain adopted.

Step 3: Incident Containment
Once the actual or potential business impact is understood, the next thought should be to contain the incident. The objective of containment is to limit the business impact of an incident. This is where the preparation work and the identification stage in knowing the business impact comes into play, if the potential cost and reputational damage caused by an incident, is greater than taking down business services over a period of time, then the correct business decision is to pull the plug on the service. So incident recovery may have to take a back seat for a while in order to protect the business’s overall interests. If this means pulling a plug on a busy ecommerce website, or downing an entire company network, if this course of action is the lesser of the two evils in terms of business impact, it is always the correct decision to take. Judging the business impact in knowing how long business systems need to remain down depends on Step 4.

Step 4: Incident Investigation and Forensics
As most cyber security incidents involve law breaking, whether external hackers or internal disgruntled staff, your servers and infrastructure must to be regarded as a crime scene, and so processed accordingly. There is always forensic data to collect, which may hold vital clues to the incident cause and scope, often these data clues are volatile, and can be lost if not collected quickly and correctly. Therefore any investigation and forensics work must be performed by an appropriate qualified internal or third party, while ensuring there is a legal ‘chain of custody’, in case either criminal or civil action occurs down the line. The amount of time to engage and complete computer forensic investigations can be significantly reduced, if you plan for them as part of the incident management preparation (step 1). If you do not have any qualified resource within your organisation, I recommend arranging to have a third party provided external computer forensic investigator on a retainer; typically they will provide a 4 hour call out response time.

Aside from the potential court room battles, the other primary reason to perform a proper forensic investigation is to establish the facts of an incident occurred. Without knowing the detailed facts of just how the breach occurred, you cannot know whether restored systems (step 5) will be still vulnerable or not. For example if you intend to restore systems from a backup, how do you know which backup is compromised or still vulnerable? It is imperative you know exactly when and how a cyber security incident occurred before engaging a recovery process, as in repeating an incident. there can be significant business impact, especially reputationally.

Step 5: Incident Recovery
Only once the facts of the incident are fully known, can you ensure eradication of the incident vulnerabilities and/or malware, and confidently recover systems and business services.

Step 6: Learning the Lessons
The final stage of cyber security incident management, and arguably the second most important step after the incident management preparation, is ensuring the business learns lessons from incidents. This is a healthy way to improve the business security posture, and there is nothing worse than repeating an incident.

Continue reading Cyber Security Incident Management, Response and Recovery Guidance