|
|
Before wrapping up this chapter's presentation of attack vectors and mitigation techniques, it is important to consider the importance of having an incident response framework. For any organization, having such a framework is essential when dealing with attacks.
Security is a growing problem, and securing an infrastructure is a critical, complex task of balancing business needs against security risks. As we saw in the sections earlier, it is an alarming fact that gaining unauthorized access to information in an insecure heterogeneous networked environment or launching a DoS-type attack is remarkably easy, and often it is difficult to track the offenders. A network intrusion can cause a broad range of consequences, including network outage, required recovery time, decreased productivity, significant loss in revenue or man-hours, devastating loss of credibility, and legal liability. Effective response and collective actions are required to counteract security violations and activities that lead to security breaches.
This section focuses on how to respond to a security incident and how to understand and prepare for any security event using an incident response framework.
A security incident is any network or system-related intrusive activity with negative security implications to the computer, network, or information systems in general. These incidents are usually in direct or indirect breach of the security policy. A security incident can originate anywhere, including the local trusted network, shared customer network, intranet, extranet, Internet, or from any other network part.
The impact of an intrusion varies depending on the damage it can cause; it can be a relatively trivial incident or a major catastrophe. Each type of attack is unique and is defined by the intent of the intruder, the level of technical sophistication, and the vulnerability exploited.
Security incident response is the process of building an awareness and proactive function into an organization system for managing security events, such as intrusions, cyber thefts, or denial of service (DoS).
Most organizations are not prepared when dealing with security incidents and do not test the appropriate response actions to better evaluate their safeguard options. Such organizations risk a maximum loss in an event of a security incident. A well-documented incident response procedure ensures the speedy recovery of the system and the prompt restoration of an organization's normal operations.
The International Organization for Standard (ISO) has recognized the importance of the incident response mechanism and therefore built a code of practice for incident response into the Information Security Management standard ISO/IEC 17799:2005. Another standard that is widely recognized and popular in Europe is the Information Technology Infrastructure Library (ITIL), which was developed in 1992 and is maintained by the United Kingdom (UK) Office of Government Commerce.
Incident Response Team (IRT) has a number of names that are commonly used: CSIRT (Computer Security Incident Response Team); CERT (Computer Emergency Response Team); and ISIRT (Information Security Incident Response Team). IRT is a team within an organization that is charged with responding to security-related issues. Forming IRT without a goal is like implementing computer security measures without a security policy. If the goal is unclear, functions by the IRT will always be performed on an ad-hoc basis, without a clear idea of the overall security framework.
An IRT can most easily be described by using the analogy of a fire department. Just as a fire department has an emergency number that you call if you have or suspect a fire, an IRT has a number and an e-mail address that you can contact for help if you have or suspect a computer security incident. An IRT service does not necessarily provide response by showing up on your doorstep; it may provide a range of other services in addition to the incident handling service, such as vulnerability handling or the provision of an intrusion detection services.
As shown in Figure 7-14, members of the IRT team should be carefully selected. Various members from the organization across all functional groups should be involved and become part of this team, such as members from the technical security team, network operations team (NOC), operations security (OPSEC), system admin, management, legal, human resources, and public affairs. As you can see from the wide range of organizations included in the IRT, incident response involves much more than knowledge of products and technologies.
Note
Refer to the following comprehensive 200+ page handbook, which provides guidance on the formation and operation of an IRT:
Effective integration of a security incident response function requires a clear methodology and an understanding of the organization's business functions, assets, teams, responsibilities, and threat modeling. A security incident framework should be approached holistically, by employing the necessary disciplines from physical, logical, and organizational security to form the best response function. As shown in Figure 7-15, an IRT reaction to a security incident can typically be categorized by five steps:
1. | Planning and preparation |
2. | Identification and classification |
3. | Reaction |
4. | Postmortem and follow-up |
5. | Archiving |
Note
The steps shown in Figure 7-15 are merely a guideline and should be used as a general template. You should tune the template to the organization's specific needs and requirements.
The most important aspect in a security incident handling is the preemptive preparation phase that handles events that can occur. An IRT must be formed with clearly defined roles and responsibilities and high-level management support.
Knowledge of the incidents that could occur and details on how they are to be handled should be developed and tested to ensure an efficient response mechanism. Ideal responses should be proactively identified and defined, and the tools used to respond should be created and validated through test scenarios. In addition, teams should be trained to deal with the security incident.
One of the major problems seen in the preparation phase is that the security operation teams do not have a security plan and procedure and are not trained in the effective use of the tools.
Another major issue is the dependence and reliance on vendors. Operators who use their vendors as Tier 2 and higher support endanger their network to a security risk. When operators today observe a problem on a device, they immediately call the vendor support center for a resolution. Vendors are partners with an operator. Note that vendors are not responsible for maintaining and troubleshooting the entire network; they facilitate and provision the network devices. The IRT of an organization armed with proper procedures and planning outlined by the security policy should drive the incident process.
In the event of a security incident, the general user community and teams that could be affected by the incident need to be informed of the incident by a predefined notification mechanism (such as e-mail notification, fax, or pager). In some cases, e-mail or other primary communication tools, such as IP phones, may not be the best communication tool, because they may have been compromised. Fax, cell phones, and other out-of-band tools are more appropriate in this situation. Clear instructions should be given to the end users on what needs to be done during the incident. Correct roles, skills, and communication techniques need to be identified to knit the notification procedures into a seamless process.
After an incident is detected or reported, the IRT needs to conduct a detailed analysis to identify the predefined incident resolution process that should be followed. As much as possible, the organization should have agreed on an incident classification, have defined traps, and have mapped the processes that should be followed. In addition, the organization should understand the type of attack and the damage being caused.
As discussed earlier in this chapter, you should use the various classification tools and techniques available (such as NetFlow, NBAR, and MQC) to characterize the attack. In addition, monitor the CPU load, SYSLOG, and SNMP alerts, and monitor protocol and interface statistics such as Input/Output queues, drops on the device interfaces for link saturations, and other traffic flow statistics.
This phase represents the heart of the incident response strategy. Reaction is the response process used to counter the attack. A process that quickly and flexibly contains and eradicates the incident is executed followed by full recovery of business systems to ensure the responses have been effective. The IRT should prepare a detailed report to update both management and the staff that is managing specific security incidents to a successful conclusion. Evidence of misuse needs to be collected swiftly and accurately, with full integrity and provenance.
As discussed earlier, several techniques can be used in this phase to mitigate various types of attack vectors and restore normal business operation. Contact details for appropriate upstream providers (ISPs) need be defined and identified to block the offender.
After the incident is mitigated, the IRT, in conjunction with other relevant teams that were involved during the incident response process, should conduct a review on the technical components of the incident to determine what can be done to build resistance and reduce the risk of reoccurrence. This could include risk assessments, understanding the root cause, reviewing of security policies, identifying trends and patterns of the incident, as well as applying practical safeguards and compensating measures. The process should identify options to tighten or reposition security controls and enact enforcement where needed.
Based on the post-incident review findings, the organization also needs to agree on final closure actions. These could include dissemination of new policy, realignment of asset ownership, running awareness campaigns, implementing patches or new countermeasures, and also disciplinary/legal repercussions where necessary. In addition, the need to review responsibility in the organization needs to be identified to ensure an effective incident management process.
At this stage, all incident information should be archived and saved for future referencing, and of course that means the information related to the incident should be documented. Archiving saves you time in the future. For example, if a phone call conversation was not documented and logged, there is a good chance that a significant portion of the information is either forgotten or misinterpreted, resulting in the repetitive task of contacting the source of the information again.
In the early stages of handling an incident, it is often infeasible to determine whether prosecution of intruders is viable and if the incident is going to be prosecuted. Recording details will provide evidence for prosecution efforts, if the case moves in that direction. Therefore, gather information in a form that is submissible to law enforcement and the court of law.
Documenting an incident will also help with the final assessment of damage that can be reported back to the management; it can also be used to claim insurances where applicable.
|
|