MSc Cyber Security
Facilitator guide: Incident Response
Introduction
This guide provides:
1.
2.
3.
4.
The details of the attack
Possible Learning issues
Possible solutions
Resources
How to use this scenario
The scenario can be used in several ways. Two proposed approaches are:
1. As a PBL scenario which is a basis for students to learn some (or all) of the concepts of
incident management: incident planning, Identifying an incident, Incident response
team responsibilities, Incident management team responsibilities, Incident triage,
Incident management life cycle, Incident management and response purpose, Incident
management processes. It is based around activities for the Incident Management
lifecycle:
1. Detect incidents
2. Diagnose incidents
3. Manage incidents
4. Contain, minimize damage & eradicate threat.
5. Restore affected services
6. Determine root causes
7. Implement improvements to prevent recurrence or minimize the impact of
future, similar events
The scenario is relatively complex, so it is recommended that students are introduced
to incident planning through a simpler scenario in preparation for this one. The NIST
document (Cichonski et al, 2012) provides several such scenarios.
The scenario is divided into 3 stages, to provide opportunity for discussion of the
actions taken at each stage, and to introduce the next part of the attack.
2. As a pseudo real-time exercise which provides a series of events to which the team
must respond. This is an assessment scenario, where students are already assumed to
have appropriate knowledge.
1
The Attack
The attack takes the form of a professional cyber-criminal gang using an information stealing
Trojan firstly to gain access to the computers of members of the organisation and siphon out as
much information as they can before the response process can interrupt or deny them the
chance. This Trojan has the ability to download and run further packages. The Cyber Kill Chain
(Carr,2008) is a useful model for analysing cyber-attacks. The Kill Chain originated as a military
targeting concept defined by linked steps (a chain) for detecting and engaging the enemy. The
phases are shown below and can comprise one of the learning goals for the scenario.
1.
2.
3.
4.
5.
6.
7.
Reconnaissance
Weaponisation
Delivery
Exploitation
Installation
Command and Control (C2)
Actions on Objectives
The Topology is included in the student scenario. An expanded version with named and sequence numbered
events, which are as follows:
1. Malware Spam email received and opened by work from home developer.
2. Trojan makes successful command & control connection via Dev's home DSL due to the proxy circumvention
around corporate VPN.
3. Adversaries obtain unauthorised access to Edgecoin's dev environment, resulting in the exfiltration of a
subset of live customer data used for Live Proving.
4. Customer data used in spear phishing campaign to harvest credentials via a phishing page (first comment in
red from FacilitatorGuide.docx).
5. New HIPs policy update alerts Security Team to the developer's compromise.
6. Remote Forensics and clean-up result in Zeus Trojan artefact being retrieved. Running through Cuckoo
sandbox gives IOCs in form of checksums of malware and the malware C&C - which resolves back to IP
addresses in Russia and Ukraine.
6a. VPN access needs to be revoked, proxy circumvention removed and machine should be sent in for
full forensic examination - if not adversaries exploit residual access remains and step 11 happens.
7. Initial DDoS tickle to test responses, gauge size of attack needed.
8. Fraud against customer accounts, being transferred to accounts in multiple banks mostly with eastern
European names.
9. UDP Flood - DDoS mitigation should be enacted.
10. Residual layer 7 (https) attacked that cannot be mitigated are identified and blocked at firewall 11.
Dependent on 6a - if dev machine not fully contained, then adversaries destroy the dev environment.
Any actions after the actual incident students should assume that all systems that have been affected have
logged events in a verbose manner and are preserved centrally.
2
3
The timeline for this attack is shown in the table below
Stage
Events
Stage 1
A developer who works remotely has been compromised and not detected,
because he used his tech skills to circumvent the VPN policy and direct internet
browsing via his local ADSL line to access developer forums that had not been
whitelisted by Edgecoin.
The gang realise that this is a valuable target and make plans to exploit the
foothold by taking over the developer’s computer and exfiltrating Egecoin’s
customer data. After infecting the system, the malware gives the attacker control
of the infected machine with the help of a Virtual Network Computing (VNC, for
remote access) and SOCKS proxy server.
Edgecoin’s policies allow live data in testing, so developers have access
permission to the production systems. The gang is therefore able to hijack the
developer’s machine and use his VPN access to obtain and exfiltrate customer
data from the production systems. This data is used to craft spear phishing
attacks on Edgecoin’s customers, directing them to a spoof website to harvest
authentication details. (Or compromise their machines and install a Zeus variant
man in the browser access with injects specifically to gain access to EdgeCoin PLC
logon credentials?)
There is a high volume of alerts for a Backdoor Trojan traffic block from the HIDS
on the computer of a remote developer, reported through the SIEM system.
The Trojan is attempting to contact its command and control (C2) parent and
exfiltrate data.
Facilitator needs to discuss the following prior to stage 2.
Initial analysis shows that the developer is circumventing the proxy.
1. Team should seek to contain the malware using remote forensics
capability and return the user to browsing via corporate infrastructure.
2. Team should perform analysis of malware to extract Indicators of
Compromise (IOC)s.
3. Increase defensive posture by ensuring IOCs are blocked in the gateway
and sent to 3rd party to be blocked – this will stop the criminal group
being able to tell the malware to download another package so remote
access can be re-established to destroy the dev environment
4. IOCs should be shared with malware community – this will result in
confirmation that it’s linked to recent malware spam sent to customers
5. If any team did not bring the developer into the corporate infrastructure
and block the IOCs as a result of malware analysis then they should be
informed that their developer environment has been destroyed. The
account used to do so is traced back to the developer who circumvented
corporate security policy.
6. Forensic analysis of his/her machine shows that all of the data from the
developer environment was first exfiltrated out. This undermines the
security of the entire platform.
The Security team respond by installing a policy update which means the domain
name used for remote access has been stopped, they contact the developer and
remove the machine from the network, requiring it to be returned for forensic
analysis.
At this stage the security team believe the incident has been contained and threat
eradicated.
4
Stage 2
With the denial of access to the compromised developer machine the group
decide to bring their plans forward and cause as much damage as possible. They
decide to perform a large scale attack on the organisation by performing as much
fraud as possible in a short space of time, exfiltrating as much data as possible
and then DDoS EdgeCoin PLC’s network range as a finale to stop Edgecoin’s fraud
team from accessing the production systems and retrieving the cash transfers. As
a preliminary test, they previously performed a small DDoS ( known as a “tickle”)
a small attack as a preliminary to determine the defences of the victim
organisation. There was no response to the tickle so the gang feel confident that
their major attack will be successful.
Fraud staff report multiple accounts being debited to mule accounts only just
created. (At what point does the source – Eastern Europe become apparent?)
Not much can be done here, fraud team have to try and claim money back or stop
it leaving.
Team should treat this as a warning that something larger is happening
Network monitoring shows that bandwidth is utilised to full capacity.
Team should speak to network team and reach out to 3rd parties, most likely
DDoS mitigation provider
Within a few minutes firewall provider calls to say they’ve detected UDP attack
traffic and suggest going into mitigation
Team should looks to go into mitigation – this may take 10 minutes or so
Team should request sources of attack traffic
Business demands to know what’s happening and when operations will be
restored.
Customers are calling in to complain as the website was unavailable, but now is
very very slow and often keeps failing.
Team should speak to 3rd party firewall company and understand if all traffic is
being mitigated
Facilitator needs to discuss the students’ & recommended responses prior to
stage 3
Stage 3
Discussions with network 3rd party show that there are multiple SSL encrypted
tunnels consuming large amounts of traffic. This is a layer 7 attack as well, with
attackers constantly pulling large documents.
Team should seek to block these connections at the firewall.
The attack has now been largely carried out; they will now have to weather the
DDoS.
Containment should prioritise the preservation of evidence, however should not
supersede it. Teams should have documentation of information given, actions
taken by whom and when.
Eradication actions should be considered to transition any short term
containment actions into long term solutions restoring operational effectiveness.
Actions such as the replacement of developer machine.
Forensic analysis of the attack evidence, firewall logs etc.
Need to reset customer accounts.
CiSP/ other sharing of threat intelligence.
5
Future – policies to prevent live data used in testing (the source of the IDs used in
phishing)
Mitigation technology against MIB attacks & fraudulent logins – eg anomalous
behaviour.
Students should consider what they have available to effectively carry out the
post incident activity. They should start with a complete review of all available
logs to identify the chain of events to identify weaknesses applying all of the
standard steps in Incident Response process.
~ Preparation
~ Detection & Analysis
~ Containment, Eradication & Recovery
~ Post Incident Activity
This is cyclical - when setting up an Incident Response function all of your work
going into Preparation - based on the strategy of the organisation, the risks it
faces, the vulnerabilities it's particularily exposed to you'll be able to set up the
most effective Detection and aquire the tools you need for Analysis.
The central core of Incident Response is Containment, Eradication & Recovery
and the speed by which you can achieve this. Once the mess is mopped up, the
Post Incident activity is written up and dropped back in at the top with more
Preparation.
I was thinking that the video could cover the first 3 stages of the kill chain, to set the scene as
to a group of miscreants organising an attack? Perhaps discussing selection of target
organisation, trawling linkedin and googling. Discussing which malware to use, performing
configuration and finally crafting emails to send into the organisation.
Prerequisite Knowledge
The scenario is adaptable, and the prerequisite knowledge is not essential, some of it may be
considered part of the learning outcomes. The following identify concepts/ technologies/
processes that are required for successful completion of the scenario.
1. Information Security concepts / controls including:
a. Two factor authentication.
b. Virtual Network Computing (VNC)
c. Host Intrusion detection systems
d. Firewall
e. Distributed Denial of Service attack
f. Malware: Trojan and Indicator of Compromise
g. Security information and event management (SIEM)
h. CERT-UK, CiSP
2. Incident management planning/ preparation concepts:
a. Prepare/Detect/Analyse/Contain/Eradicate/Restore/Post-Event
b. CSIRT composition/ role/ purpose.
3. Teamwork.
6
Possible Learning Outcomes
On completion of the scenario, students will be able to:
1.
2.
3.
4.
5.
6.
Articulate the Incident management Lifecycle
Perform basic diagnosis of types of incident
Explain appropriate responses to the attacks
Explain the communication strategy.
Explain the purpose of, and complete appropriate documentation for an incident.
Explain the role of Incident management within a systemic approach to Information
Security.
Resources
There are a number of resources available to you:
Edgecoin incident response policy/plan
CARR,J (2008) The cyber kill chain
CERT-UK: https://www.cert.gov.uk/
Cyber-security Information Sharing Partnership (CiSP) https://www.cert.gov.uk/cisp/
CICHONSKI,P., MILLER,T.,GRANCE, T., SCARFONE, K. 2012. Computer Security Incident Handling
Guide: Recommendations of the National Institute of Standards and technology, NIST Special
Publication 800-61 rev. 2, www.csrc.nist.gov/publications/nistpubs/800-61-rev2/sp80061rev2.pd f
ISACA, 2013. CISM Review Manual. Rolling Meadows: ISACA.
ISO 22301:2012 Societal security -- Business continuity management systems --- Requirements
ISO/IEC 27001:2013 Information technology — Security techniques — Information security
management systems — Requirements
ISO/IEC 27002:2013 Information technology — Security techniques — Code of practice for
information security controls
ISO/IEC 27035:2011 Information technology — Security techniques — Information security
incident management
British Standards ISO 27001 Overview: http://emea.bsiglobal.com/InformationSecurity/index.xalter [ Last accessed 22-Sep-2014]
Context
Reference documents which underpin the knowledge/tasks for incident management are
summarised below:
ISACA CISM Relevant Task statements
T4.1 Establish and maintain an organizational definition of, and severity hierarchy for,
information security incidents to allow accurate identification of and response to incidents.
T4.2 Establish and maintain an incident response plan to ensure an effective and timely
response to information security incidents.
7
T4.3 Develop and implement processes to ensure the timely identification of information
security incidents
T4.4 Establish and maintain processes to investigate and document information security
incidents to be able to respond appropriately and determine their causes while adhering to
legal, regulatory and organizational requirements.
T4.5 Establish and maintain incident escalation and notification processes to ensure that the
appropriate stakeholders are involved in incident response management.
T4.6 Organize, train and equip teams to effectively respond to information security incidents in
a timely manner.
T4.7 Test and review the incident response plan periodically to ensure an effective response to
information security incidents and to improve response capabilities.
T4.8 Establish and maintain communication plans and processes to manage communication
with internal and external entities.
T4.9 Conduct postincident reviews to determine the root cause of information security
incidents, develop corrective actions, reassess risk, evaluate response effectiveness and take
appropriate remedial actions.
T4.10 Establish and maintain integration among the incident response plan, disaster recovery
plan and business continuity plan.
ISO/IEC 27001:2013/ 27002:2013
This scenario relates principally to Control categories in Clause A16.1 of ISO27002. It also
relates to ISO/IEC 27035:2011 Information technology. Security techniques. Information
security incident management.
A.16 Information security incident management
A.16.1 Management of information security incidents and improvements
Control Objective: To ensure a consistent and effective approach to the management of
information security incidents, including communication on security events and weaknesses.
A.16.1.1 Responsibilities and procedures
Control Management responsibilities and procedures shall be established to ensure a quick,
effective and orderly response to information security incidents.
A.16.1.2 Reporting information security events
Control Information security events shall be reported through appropriate management
channels as quickly as possible.
A.16.1.3 Reporting information security weaknesses
Control Employees and contractors using the organization’s information systems and services
shall be required to note and report any observed or suspected information security
weaknesses in systems
or services.
A.16.1.4 Assessment of and decision on information security events
Control Information security events shall be assessed and it shall be decided if they are to be
classified as information security incidents.
A.16.1.5 Response to information security incidents
Control Information security incidents shall be responded to in accordance with the
documented procedures.
A.16.1.6 Learning from information security incidents
8
Control Knowledge gained from analysing and resolving information security incidents shall be
used to reduce the likelihood or impact of future incidents.
A.16.1.7 Collection of evidence
Control The organization shall define and apply procedures for the identification, collection,
acquisition and preservation of information, which can serve as evidence.
9