- some fault has occurred and needs fixing
- you network is ( or has been ) under attack
Security Incidents . A definition
An IT security incident is a violation of IT security policy, acceptable use policy or of standard proceduresWhich covers a lot of events, but most frequently amongst small to medium enterprises:
- malware attacks
- virus ( becoming rare )
- worms
- trojan horses
- Denial of Service ( DoS )
- as a side-effect of malware attack
- as a deliberate, intelligent attack
- Intruders, intelligent agent attacks
- insiders
- outsiders
- ex-insiders
- Email
- advertising - SPAM
- scams: phishing, Nigerian, stock market
- malware-carrying: trojans
- Operational incidents
- system failures: crashes, environmental failure
- operator error
It has been estimated that in 2006, New Zealand businesses will lose a total amount of $140-240 million due to security incidents (Ref). This is a very high figure (dodgy statistics warning!) which must be close to the entire IT security revenue figure for New Zealand.
Detecting Incident Occurrence Detection is not always easy, often detection is through observing the side-effects of a security incident (eg. High network traffic). Major incidents are frequently announced by statements such as "that's funny", or "Uh oh" ...
Intrusion detection tools are generally good analysis tools, sometimes useful for tactical alerting. Always good to have in your toolkit.
Assessing the situation
Assess the situation as soon as possible after detection. Ask yourself (and anyone else in the vicinity) the following questions:- what is the business impact of the incident?
- if the affected system(s) are isolated then what is the impact to business?
- how much effort will it take to resolve?
- this estimate can be re-evaluated later
- estimate for repair-in-place
- estimate for offline rebuild from scratch
- estimate to recover from backups ( you do have backups, don't you? )
- is there enough people with enough expertise available?
- if not, think about calling someone - either additional internal resources, or external providers
- document everything
- include dates and times, include contact information
Identifying the people to handle the incident
An incident team for a small to medium enterprise is almost always two people. One will be the technical lead who will perform the bulk of the remedial work, and the other will be a backup person reporting to management and recording the actions taken. Further people may be involved depending on the size of the organisation, usually in the reporting chain rather than in direct involvement. These may include:- the IT manager
- the CEO/CIO/CTO
- Media relations
- Legal
- Law enforcement
- new workstations, servers, switches/routers, firewalls
- IDS tools
- Anti-virus, Anti-spam tools
Forming a plan for resolution
Make a plan, not necessarily written, but at least well communicated. Include the following basic steps:1. Contain the problem
Potentially by isolating the affected systems2. Do No Damage
- make backups of the affected system(s)
- decide if preservation of evidence or critical data is required, if so then backups and correct procedures are critical
3. Resolve the problem
- rebuild systems from scratch?
- load backup data?
- re-secure the affected system(s) as soon as possible
- record all actions taken, and document as much as practical
- updated estimated RTO times
- report to management and other interested parties
Return to Operation
After the incident has been resolved the systems can be returned to operation, but only after they have been tested and re-secured to prevent any re-occurrence.Identify and mitigate all vulnerabilities that were exploited
After return to operations, monitor the system closely to make sure all systems are restored to normal.
Report to management and other interested parties that the system has been restored.
Preventing Reoccurrence
This is by far the most crucial area, unfortunately it is often overlooked. Many problem would not occur if prevention measures had been put in place following the first occurrence.Review the Causes
Was the incident caused by a failure in one or more of the following?- Technical controls?
- Environmental systems?
- Human factors?
- Management & budget constraints?
Review Resolution
- Could the incident have been detected earlier?
- Could the incident have been resolved quicker?
- Did you need more resources?
- Was reporting adequate?
- Would simulations and rehearsals help in resolving similar incidents?
- Would it help to have better incident response plans?
Create a Final Report
... and keep it short and to the point. 1-2 pages is the norm. In the final report detail the incident causes, how it was detected, the handling process, and provide an executive summary.The key is to prevent re-occurrence.
Scenarios
Think about how you would handle each of the following hypothetical situations:Scenario 1
The company's web server slows down then stops responding. High network traffic causes you to suspect a Denial of Service attack.Points to address:
- How will you identify the source of the traffic?
- Should you shutdown the corporate web server?
- How will you stop the traffic?
- How will you prevent it from reoccurring?
Scenario 2
- The organisation starts receiving complaints about spam originating from its network
- The administrator identifies the source as the company.s web server
- How would you validate the source of the spam?
- How would you respond to complaints regarding the spam?
- How would you isolate and repair the web server?
- How would you prevent reoccurrence?
Scenario 3
A new Trojan/worm is released on the Internet - it distributes itself through Email attachments and downloads malicious code from an Internet FTP server. A number of people in your organisation have opened such attachments.Points to address:
- How do you identify infected systems?
- How could you prevent the malware entering the enterprise before antivirus signatures were updated?
- How would you prevent further spread?
Scenario 4
An employee at your site mentions that his bank account has been cleaned out by hackers in Estonia. He has been using online banking from his company workstation.Points to address:
- Could you confirm whether or not his password was stolen?
- How would you report this incident?
- Would you warn other employees?
Scenario 5
The database administrator finds a strange directory on a database server, created by root 6 weeks ago.Points to address:
- How will you identify the source of the attack?
- How will you preserve the system?
- How will you identify what has changed on the system?
- How will you recover the system?
Scenario 6
A network intrusion detector identifies that someone has downloaded malware from a webmail account.- How will you identify the person involved?
- How will you make sure their workstation is unaffected?
- How will you prevent it from reoccurring?
References
1. A survey conducted by the Employers and Manufacturers Association (Northern). Press release 6 December 2005. http://www.nzherald.co.nz/topic/story.cfm?c_id=137&ObjectID=10358566Resources
NIST SP800-61 Computer Security Incident Handling Guide
Tim Grance, Karen Kent, Brian Kim
http://csrc.nist.gov/publications/nistpubs/800-61/sp800-61.pdf
NIST SP800-83 Guide to Malware Incident Prevention and Handling
Peter Mell, Karen Kent, Joseph Nusbaum
http://csrc.nist.gov/publications/nistpubs/800-83/SP800-83.pdf
NIST SP800-86 Guide to Network and Computer Data analysis: Applying Forensic Techniques to Incident Response
Tim Grance, Suzanne Chevalier, Karen Kent, Hung Dang
http://csrc.nist.gov/publications/drafts/Draft-SP800-86.pdf
Best Practices for Security Incident Response
Kerry Thompson
http://www.crypt.gen.nz/papers/incident_response.html
Incident Response
Kenneth R. van Wyk, Richard Forno
O.Reilly & Associates. ISBN 0-596-00130-4
http://www.oreilly.com/catalog/incidentres/index.html