Preparation
1 Identification
2 Containment
3
Objective: Establish contacts, define Objective: Detect the incident, determine its Objective: Mitigate the attack’s effects on the
procedures, and gather information to save scope, and involve the appropriate parties. targeted environment.
time during an attack.
Usual channels of detection are: ■ Backup all data stored on the web server for
■ Have up-to-date schemes describing your forensic purposes and evidence collecting. The
applicative components related to the web ■ Webpage monitoring: The content of a web page best practice here if applicable is to make a
server. has been altered. The new content is either very complete bit-by-bit copy of the hard-disk containing
discreet (an “iframe” injection for example) or the web server. This will be helpful to recover
obvious (“You have been 0wn3d by xxx”) deleted files.
■ Build a backup website up and ready, on
which you can publish content.
■ User: users call or notification from employees ■ Check your network architecture map. Verify
about problems they noticed while browsing the that the vulnerability exploited by the attacker is
■ Define a procedure to redirect every visitor to website. not located somewhere else :
this backup website. - Check the system on which the web server is
■ Security checks with tools such as Google
running,
- Check other services running on that machine,
■ Deploy monitoring tools to quickly detect any SafeBrowsing - Check the connections to other systems, which
abnormal behaviour on your critical websites. might be compromised.
Verify the defacement and detect its origin:
■ Export the web server’s log files to an external ■ Check files with static content (in particular, check
If the source of the attack is another system on the
network, disconnect it if possible physically and
server. Make sure clocks are synchronized the modification dates, hash signature). investigate on it.
between each server.
■ Check mashup content providers.
Try to find evidences of every action of the attacker:
■ Reference external contents (static or ■ Check link presents in the web page (src, meta,
css, script, …).
dynamic) and create a list for each of them. ■ Find out how the attacker got into the system in
Don’t forget third parties for advertisement. ■ Check log files. the first place and fix it :
■ Scan the databases for malicious content.
- Web component vulnerability allowing write access:
■ Reference contact points of your hosting fix the vulnerability by applying editor’s fix.
provider. The source code of the suspicious page must -
-
Open public folder: fix the bug.
SQL weakness allowing injection: correct the code.
be analysed carefully to identify the problem clearly. In
■ Be sure your hosting provider enforces particular, be sure the problem is on a web server
-
-
Mashup components: cut mashup feed.
Administrative modification by physical access:
policies to log all events. belonging to the company and not on a web content
modify the access rights.
located outside your infrastructure, like commercial
■ Make sure you have an up-to-date network
banners from a third party.
■ If required (complex issue and very important
map. web server), deploy a temporary web server, up
to date with its applications. It should offer the
same content than the compromised web server or
at least show another legitimate content such as
“Temporary unavailable”. The best is to display a
temporary static content, containing only HTML
code. This prevents another infection in case the
attacker has used vulnerability in the legitimate
PHP/ASP/CGI/PL/etc. code.
Remediation
4 Aftermath
6 Incident Response Methodology
Objective: Take actions to remove the threat Objective: Document the incident’s details,
and avoid future defacements. discuss lessons learned, and adjust plans and
defences.
Remove all altered content and replace it with IRM #6
the legitimate content, restored from earlier Communication
backup. Make sure this content is free from Website Defacement
vulnerabilities. If the defacement has been visible for part of your Live reaction on a compromised web server
users, plan to explain the incident publicly.
___________________________________________________
IRM Author: CERT SG / Cédric Pernet
IRM version: 1.3
Report
E-Mail: [Link]@[Link]
A crisis report should be written and made available to all Web: [Link]
of the involved parties. Twitter: @CertSG
The following themes should be described:
■ Initial detection;
Recovery
5 ■ Actions and timelines;
Abstract
■ What went right;
This Incident Response Methodology is a cheat sheet dedicated
to handlers investigating on a precise security issue.
Objective: Restore the system to normal ■ What went wrong; Who should use IRM sheets?
operations. Administrators
■ Incident cost. Security Operation Center
CISOs and deputies
■ Change all user passwords, if the web
In case of vulnerability discovery, report any
undocumented vulnerability lying on a product
CERTs (Computer Emergency Response Team)
server provides user-authentication, and you running on the web server (like a PHP forum) to its Remember: If you face an incident, follow IRM, take notes
have evidence/reasons to think the passwords editor, so that the code can be upgraded in order to and do not panic. Contact your CERT immediately if
may have been compromised. This can release a fix. needed.
require a large user communication
Capitalize
■ If backup server has been used, restore the Actions to improve the handling of defacement incidents Incident handling steps
primary web server component as nominal should be defined to capitalize on this experience. 6 steps are defined to handle security Incidents
server.
Preparation: get ready to handle the incident
Identification: detect the incident
Containment: limit the impact of the incident
Remediation: remove the threat
Recovery: recover to a normal stage
Aftermath: draw up and improve the process
IRM provides detailed information for each step.
This document is for public use
