- : Executing a Policy
- Security Incident Response
- Computer Security Incident Response Teams
- Preparing for Incident Response
- Management of Security by Teams
- Execution of an Incident Response
- Evaluation of a Security Incident
- Containing the Incident
- Eradicating the Incident
- Recovering From an Incident
- Article Series
- About the Author
- Acknowledgements
- References
- Ordering Sun Documents
- Accessing Sun Documentation Online
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Evaluation of a Security Incident
Prepared policies and procedures, which include the necessary actions to observe systems and networks for signs of unexpected behavior (including intrusions), at the customer site help in the detection of a possible incident and the writing of a report. Observation involves monitoring, inspecting, and auditing the systems and networks. Evaluation is the next step.
The organization's geo-based security officer and that officer's staff should be responsible for the initial evaluation of any security incident, within the scope of that constituency. Evaluation starts with reviewing the report of an incident. Multiple reports might come in within short intervals of time. These reports should be consolidated with the help of the geo-based security officer's staff for the affected constituent, as designated by the worldwide security team. Also, in spite of the different possible ways of communication, points of contact and submission mediums regarding the incident should be standardized as part of the security policy (as discussed in the last article). Note that an incident could be reported by a non-technical person, so the report form could be partially completed in the initial submission. A security expert's help is necessary to complete the form after the initial submission. The following shows an example of a submission form.
|
Incident Response and Reporting Checklist |
|
1. Status |
|
_ Site under attack _ Past incident _Repeated incidents, unresolved |
|
2. Contact information |
|
Name:__________________________ Title:___________________________ |
|
Organization:____________________________________________________ |
|
Direct-dial phone:_____________ Email:___________________________ |
|
Legal contact name:________________________ Phone:_______________ |
|
Location/site(s) involved:_______________________________________ |
|
Street address:__________________________________________________ |
|
City:_________________ State/province:____________ Country:______ |
|
3. What is the nature of the emergency? (Check all that apply.) |
|
_ Denial of service attack _ Unauthorized electronic monitoring |
|
_ Network intrusion _ Insider attack _ Probe/scan |
|
_ Malicious code (virus, trojan horse, worm) |
|
_ Website defacement |
|
_ Other (please explain) ________________________________________ |
|
4. Date: _____________ Time: _______________ |
|
5. Duration of attack: _____________________ |
|
6. Impact of attack |
|
Loss or compromise of business data? ___________________________ |
|
System downtime: __________ |
|
Damage to systems: __________ |
|
Financial loss: ___ (estimated amount: ______________) |
|
Damage to the integrity or delivery of critial goods, services, |
|
or information__________________________________________________ |
|
________________________________________________________________ |
|
Other organizations' systems affected: _________________________ |
|
________________________________________________________________ |
|
7. Severity of attack (include financial loss) _ low _ medium _high |
|
8. Did the attacker gain root, administrative or system access? ___ |
|
9. How was the incident detected? |
|
_ Intrusion detection system or audit logs |
|
_ External complaint |
|
_ User report |
|
_ Other: _______________________________________________________ |
|
10. What are the known symptoms? _______________________________ |
|
11. What business areas are affected? __________________________ |
|
12. What systems are affected? _________________________________ |
|
(Gather as much information as possible about the systems, including suspected systems. For instance, gather the name of the operating system, platform, applications, IP address, associatedor suspected user IDs, most recent changes applied, and otherrelated items, as you deem pertinent. |
|
13. Are the systems still connected to the internal network? ____ |
|
14. Are the systems still connected to the Internet? ____ (Consider disconnecting the systems, if possible.) |
|
15. Are the backups of the perceived affected systems available? __ |
|
(Provide all of the information regarding online, onsite, or offsite backups.) |
|
16. Are the affected systems still at risk or attack? ____ (Consider disconnecting the systems or securing the accounts, if possible.) |
|
17. Will the systems potentially require forensic analysis? ___ (Consider shutting down and securing the system for forensic imaging.) |
Determining If an Incident Is Real
The first task is to determine if the security incident is real. Why? Because, a large percentage of incidents are false alarms. As the first step upon the notification of an incident, the organization's worldwide security team must make every attempt to reduce panic on the affected constituent's behalf. The organization's geo-based customer account manager, who is responsible for the site in question, should deploy the organization's resources to determine if the incident qualifies as a security incident by consulting with the security officer responsible for the geographic area.
Clarity of the Notification
Clarity of communications regarding an incident impacts the ability to determine if an incident is real. In the first article, necessary policy statements were mentioned regarding these communications. FIRST has a document (contributed by AusCERT) that defines how to communicate internationally, limiting confusion (refer to http://www.first.org/docs/international_comms.html).
VCSIRTs must follow these suggestions that cover many topics, such as currency, postal codes, measurements (metric or imperial), time formats and zones, seasons, telephone numbers, and so on.
Trusting the Source of the Notification
Another factor that significantly contributes to the reality judgment is trust. If you do not know the source of notification well, it is difficult to assess the quality and relevance of the contents of the notification of an incident. For example, if your team receives information about a potential new Internet worm from CERT/CC in the U.S. or AusCERT in Australia, it is likely you will pay considerably more attention to it than if it had been received from an unknown, or lessor known, source or from an individual.
Detection of an Incident
Detection implies and embraces potentially a much wider range of incidents than just intrusion detection. For instance, a virus infection can be found using specific detection techniques, but not by intrusion detection tools. Also, depending on the type of intrusion detection (for example, network-based versus host-based), an insider host-level misuse (or what can be defined as a violation of the security policy), resulting in a security incident, might not be noticed.
CERT/CC offers an intruder detection checklist that outlines suggested steps for determining if your system has been compromised (refer to "Intruder Detection Checklist" at: http://www.cert.org/tech_tips/intruder_detection_checklist.html#A1).
The following list contains some of the typical symptoms:
Unusual log file entries (although expert intruders are good at covering their tracks, examples include new accounts, numerous failed login attempts, and logins into dormant or default accounts)
Presence of new setuid or setgid files
Changes in system directories and files
Unusual hidden files or ambiguous files, such as those from past incidents (for example, /tmp/bob and /etc/inet.d)
Altered home pages, which are usually the intentional target for visibility, or other pages on the Web server (these are usually the most obvious signs of a compromised Web server)
Accounting discrepancies
Suspicious probes (for example, login attempts) and browsing
Activity during non-working hours or holidays
Presence of cracking utilities (for example, Crack), which might have been loaded by an authorized user with bad intentions
Unaccounted for changes in the DNS tables, router rules, or firewall rules
Unexplained elevation or use of privileges (for example, gaining superuser privileges)
System crashes
Unexplained poor system performance
Failed or successful social engineering attempts (for example, attempts to obtain a network password over the phone by someone pretending to be an employee)
Clever intruders tend to not use the superuser logins because they attract attention. Instead, they prefer to use raised privileges of a normal user.
Crashes could be due to a planned denial-of-service attack or due to an amateur hacker stumbling out of a system in a hurry, leaving it in a hung or crashed state.
In the case of poor performance, care should be taken because it is difficult to determine that the system has been compromised just because it is performing poorly.
System administrators and security engineers deployed by the VCSIRT at the affected constituent site can use this information to look for and confirm several types of break-ins. Tools, such as Tripwire and MD5 signatures, can help you determine changes in system files and, in turn, provide clues about the actions of attackers and confirmation of a compromise.
For more information about Tripwire, refer to:
http://www.sun.com/software/security/tripwire
The Solaris Fingerprint Database Companion, sfpC, automates the process of collecting and checking MD5 signatures against the Solaris Fingerprint Database, sfpDB.
The Solaris Fingerprint Database Sidekick, sfpS, simplifies the process of checking for the presence of rootkits on the compromised system, which is a sign that an intruder has broken into the system.
NOTE
Rootkits are sets of modified system binaries that provide hackers with hidden backdoors that enable future access to compromised systems.
The Solaris Fingerprint Database Sidekick accomplishes the detection of rootkits by maintaining a list of common trojan-horse software that is intentionally modified with a malicious intent (for instance, Solaris OE executables such as /usr/bin/login or /usr/bin/passwd).
For more information about these tools, refer to:
http://www.sun.com/blueprints/tools/fingerprint_license.html
Determining the Scope
After the incident is qualified as real, the scope of the incident should be quickly determined. The customer account manager should assemble the appropriate field engineer (for example, the organization's field engineer at the site in question or a technical support engineer from the customer service center that is servicing the site) and engineering resources (for example, the organization's security engineer or forensic expert) and work with the security officer to answer the questions in the following two sections. If the security officer for the geographic area in question is not available, then the worldwide security manager should assign another officer.
General Scope Questions
The following list contains general questions that should be asked to determine the scope of the incident:
Is there just one, or more than one, incident involved simultaneously?
Is this a single site or a multisite incident?
Is this a single geo or multi-geo incident (considering that businesses are generally divided into several geographic sub-entities)?
Is sensitive information involved?
What is the entry point of the incident (for example, the network, the phone line, or other)?
What is the potential damage of the incident?
What is the estimated time to close out the incident?
What resources are required to handle the incident?
Will the press be involved?
Should law enforcement be involved?
Answering these questions facilitates the deployment of a proper plan and the resources to mitigate the damage and to restore business operations. After the plan is ready, it should be communicated immediately to the organization's worldwide security manager by the organization's geo-based security officer from the geographic area where the incident took place.
Detailed Scope Questions
More detailed questions should be discussed as experts are engaged by the security officer for the affected constituent. These questions include:
What is at risk?
Was one or more systems affected by the incident?
Was one or more networks affected?
How far into the internal network did the intruder(s) get?
What network segments were affected?
Who knows about the incident?
To what extent does the knowledge of the incident make it worse?
Are applications, middleware, or databases at risk? The higher the number of components affected, the wider the scope of the incident and investigation is.
The more systems affected, the wider the scope is. Different intervention methods are generally required as the scope widens.
As with the case of systems, the more networks involved, the broader the scope is, and the greater the need is for immediate and urgent action.
If a host outside of the security perimeter was affected (for example, on the DMZ), the intensity of the loss could be less than the loss for an internal network host inside of the security perimeter. (The DMZ, or "de-militarized zone," is the network added between a protected network, such as an internal network for the constituent's enterprise, and the external network, which is usually the Internet. The DMZ provides an additional layer of security and typically houses externally reachable services that cross a firewall, such as services provided by domain name servers and Web servers.)
PR and legal departments for the constituent, as well as for the servicing organization, should be concerned about the answers to these last two questions.