Learning from Code Red IIDeveloping information-security programs can help mitigate the business risks of compromised networksBy Stephen T. Barish In mid-August, an Internet worm dubbed Code Red II exploited a well-known vulnerability in Microsoft's Internet Information Server. In the weeks that followed, this self-replicating software wriggled its way into hundreds of companies, compromising several hundred-thousand Internet servers and triggering massive losses both in organizational productivity and missed revenue opportunities. Today, most of these companies are still struggling to recover from the assault, with IT departments searching for the technological fixes that will speed recovery and protect their operations from future attacks - and senior management teams focusing on regaining the trust of the consumers, clients, and business partners that are the lifeblood of their businesses. Although remedial technical actions are the priority at this juncture, companies reliant on networking technology should also take the time to assess their business risks - and move to mitigate them through the development of information-security programs. By implementing a plan for how to communicate honestly with all external stakeholders if and when future trouble strikes, companies can control the negative perceptions that inevitably arise when an organization's network is compromised. GETTING STARTEDThe first step in assessing a security strategy is to determine how it interrelates with the core business processes that generate revenue and drive the organization. Companies must identify those portions of their business operations that are dependent on information and determine the value of that information. Once this step is done, businesses can begin to mitigate their exposure by developing an information-security program that uses a combination of people, processes, and technologies to close identified gaps. Although strategic planning is essential, it is not the sole determinant of how well a company will control the fallout from a major security breach: Business partners and customers will pay very close attention to the actions a company takes to respond to a network attack. By adopting a disciplined incident-response process - one that includes technical as well as operational plans to repair breaches in security - companies can develop a solid foundation for communicating with partners and customers. SEVEN STEPS TO SECURITYHere are seven steps to take in creating an information-security program: 1. Preparation. Anticipating and preparing for a security breach is the best evidence of a company's commitment to maintaining a secure computing environment - and retaining the trust of its strategic partners and customers. Having a well-articulated plan is especially important if a company's stakeholders depend on secure network services as part of their own core business processes. Initial preparations should address such fundamentals as establishing companywide security policies, procedures, and standards and creating a disciplined process for handling specific incidents. Once in place, companies must regularly exercise and refine this process to maintain its currency and effectiveness. 2. Detection. Implicitly part of any incident-response process, detection is a tricky business. Today, most companies operate with a minimal intrusion-detection system infrastructure in place, so incidents are typically worked in extremely data-sparse environments. Yet, an enterprise network is really very rich in security-related information if a company knows where to look: For example, router, switch, and firewall logs may contain traces of an ongoing attack. In the case of Code Red II, Web-server logs can help detect attempts to exploit servers. In addition, the same performance-monitoring tools that let network-operations staffs assure availability and troubleshoot systems in real time can also help detect certain kinds of attacks. During the propagation phase of the Code Red II life cycle, companies found that extremely high volumes of traffic often degraded networks and, in some cases, crashed firewalls - a clear indicator of malicious activity at work. 3. Identification. If detection is the event that triggers the incident-response process, identification is the activity that shapes the way that process unfolds. It begins when analysts move to determine if the detected activity really constitutes a security incident and continues as they investigate the nature of the incident and decide how the company can best recover from it. Generally, identification takes place at once, with events quickly categorized either as true incidents or false positives. Some events, such as a remote buffer overflow granting root access, will be identified immediately, leaving it up to those in charge to determine which containment and recovery actions to take. This step is when executive management begins implementing the communications strategies developed during the preparation phase, alerting business partners to unfolding events. 4. Containment. The goal of any recovery effort is to limit the effect of an incident and prevent it from becoming worse - or contaminating other equipment in the enterprise. Executives and others who focus their attention on affixing blame for how the trouble started can easily lose sight of the actions they need to take in order to regain control of compromised portions of a network. Now is the time to be proactive: Inform employees, clients, suppliers, and the general public about what has transpired - although, generally, it is better to make announcements about security breaches or investigations after they have been contained. Law enforcement agencies also must be notified if criminal prosecution or civil actions are in order. 5. Eradication. Network gaps must be closed to prevent attackers from reentering the enterprise - or a virus or worm from reinfecting the network. As companies make plans to recover compromised systems or data, they should also take the following steps:
For most companies, recovery - determining whether exposed or affected systems can remain in the enterprise or must be entirely rebuilt - is a major challenge. In reviewing their options, the incident-response team must understand that the scope of their decisions will dramatically affect recovery timelines and cost. Indeed, the best decisions often are a trade-off between security and business realities. 6. Recovery. If good planning has taken place in the early phases, the incident-response team's recovery recommendations should be implemented; newly recovered systems and network segments must be closely monitored to ensure that corrective actions are effective. 7. Follow-Up. Security incidents can almost always be traced to a series of failures in policies, procedures, technologies, and people. To move forward, companies must break the chain of circumstances that allow such incidents to recur. By having the incident-response team generate a detailed report of the incident and distribute it to executives, managers, and stakeholders, lessons learned can result in corrective actions that will strengthen enterprise security. Stephen T. Barish [stephen.barish@ey.com] is a specialist in online intrusion detection and incident response. Prior to joining Ernst & Young, he was the lead engineer for the Air Force's computer network defense efforts at the Air Force Information Warfare Center. |
Most Popular This Week
IE Weekly Newsletter
Subscribe to the newsletter
|
|
|











