Computer and network security incident response is widely accepted and implemented in recent times due to the frequency of attacks attempting to compromise personal and business data. It’s critical for our organization to have the ability to systematically handle incidents by implementing a consistent incident handling methodology which enables us to respond quickly and appropriately. In addition to implementing a proper security incident management program, a sound patch management program will help create a robust defense of architectural designs for our organization as outlined below. Protecting company assets from attacks by patching vulnerabilities is only part of the risk equation where combined with an incident handling management program, institutes a good overall approach to risk management.
Patch and security incident management go hand in hand by helping our organization meet various security compliance frameworks, mandates, and other policies. As an example: NIST SI-2 “Flaw and remediation security control” includes process for installing security relevant software and firmware patches, pre-installation patch testing, and incorporating patches into organizational configuration management processes. In another example, PCI-DSS requires the installation of latest patches while setting the maximum time allowed for critical patch installations.
Our organization frequently needs to communicate issues regarding incidents with outside parties in an effort to combating such incidents in a wholly unified and cohesive manner. It’s critical that a fully comprehensive communications structure is established to limit response times.
The development of a structured incident response team will assist anyone, who suspects or discovers an incident, to communicate said incident or incidents to the proper authority, thus, opening the appropriate communications channels.
Recommended incident team modeled structure:
- Distributed Incident Response Team: multiple teams tasked with the handling of incidents occurring organization wide, each responsible for a specific physical or logical segment within the organization. Effective for a large organization such as ours that handles massive amounts of computing power and resources at numerous local and distant locations on a global scale. There exists a single coordinated entity which maintains consistency throughout the company regarding shared information.
Recommended staffing models:
- Partially Outsourced: Portion of incident response work is outsourced.
- The most prevalent arrangement is for the organization to outsource 24-hours-a-day, 7-days-a-week (24/7) monitoring of intrusion detection sensors, firewalls, and other security devices to an offsite managed security services provider (MSSP). The MSSP identifies and analyzes suspicious activity and reports each detected incident to the organization’s incident response team.
- Some organizations perform basic incident response work in-house and call on contractors to assist with handling incidents, particularly those that are more serious or widespread.
Team model selection:
- The Need for 24/7 Availability. Most organizations need incident response staff to be available 24/7. This typically means that incident handlers can be contacted by phone, but it can also mean that an onsite presence is required. Real-time availability is the best for incident response because the longer an incident lasts, the more potential there is for damage and loss. Real-time contact is often needed when working with other organizations—for example, tracing an attack back to its source.
- Full-Time Versus Part-Time Team Members. Organizations with limited funding, staffing, or incident response needs may have only part-time incident response team members, serving as more of a virtual incident response team. In this case, the incident response team can be thought of as a volunteer fire department. When an emergency occurs, the team members are contacted rapidly, and those who can assist do so. An existing group such as the IT help desk can act as a first POC for incident reporting. The help desk members can be trained to perform the initial investigation and data gathering and then alert the incident response team if it appears that a serious incident has occurred.
- Employee Morale. Incident response work is very stressful, as are the on-call responsibilities of most team members. This combination makes it easy for incident response team members to become overly stressed. Many organizations will also struggle to find willing, available, experienced, and properly skilled people to participate, particularly in 24-hour support. Segregating roles, particularly
Patch management, in most cases, integrates with incident management at the “Containment, Eradication, and Recovery” stage as highlighted in figure 1 below.
Figure 1. Incident Management
The patch management process flow, as seen in figure 2 below, will occur as part of the eradication stage during incident handling. During the investigation and diagnosis stage, processes take place where an incident hypothesis is concluded and deemed as accurate. At this points, once the incident has been diagnosed, staff will have the option to actuate a solution, such as, software setting changes, applying patches, and/or ordering new or replacement hardware.
The patch management process has distinct processes that can be divided up into 4 stages:
- Evaluate & Plan
Figure 2. Patch Management Process Flow
Although the four stages identified above appear to be linear, they are in fact, recurring events. Some of the challenges faced with patch management include dealing with remote users and foreign connected computers, including but not limited to: contractors, customers, vendors, and end users’ home computing devices. Many, if not all, of the aforementioned issues can be resolved, or at least made largely more manageable, through the use of automation tools, which are prevalent in today’s marketplace.
Souppaya, M., & Scarfone, K. (2013, July). Guide to Enterprise Patch Management Technologies. Retrieved October 12, 2016, from nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-40r3.pdf
Cichonski, P., Millar, T., Grance, T., & Scarfone, K. (2012, August). Computer Security Incident Handling Guide. Retrieved October, 2016, from nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-61r2.pdf