Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Perimeter

7/15/2009
02:46 PM
John H. Sawyer
John H. Sawyer
Commentary
50%
50%

Incident Response Prep Extends Beyond Tools, Training

Whenever you read information on how to perform forensics and incident response, there is a preparation phase that comes before anything else. Preparation steps cover how to prepare for dealing with an incident in your environment -- but what about making sure your environment is ready for an incident?

Whenever you read information on how to perform forensics and incident response, there is a preparation phase that comes before anything else. Preparation steps cover how to prepare for dealing with an incident in your environment -- but what about making sure your environment is ready for an incident?I've seen many incidents in which the team responsible for its handling had the standard forensic and IR tools in place. Their jump bag was ready to go with hard drives, forensic imaging equipment, laptops, etc., but when they approached the system in question, it was a proprietary or legacy system that wasn't supported by the typical cadre of forensic software available.

While legacy systems and proprietary systems may be absolutely necessary in some situations, more often I've seen them left hanging around because it's easier (and cheaper) to let them do what they do than to upgrade them to a more modern OS that's less esoteric and easier for IR staff to handle. This is a situation where "if it ain't broke, don't fix it" can seriously throw a monkey wrench into an investigation.

Legacy systems, however, are not the source of so many other problems I've come across. The number one core issue is changes made by system administrators and help desk staff during the course of managing systems and during troubleshooting that don't take into consideration what impact it will have if one of those systems is compromised and must be analyzed.

The best example is an issue that resulted from cached pages in an ERP Web portal. The users were experiencing odd behavior with stale pages and values in forms. Troubleshooting the issue led to a "fix," by having the cache and history cleared upon exit, or not record at all. Shortly after the "fix" was put in place, two incidents occurred that were complicated by it. One dealt with inappropriate Web surfing and the other was malware contracted through Web browsing.

I've seen several others, including turning off firewalls to troubleshoot a problem and never turning it back on, logging disabled not to be re-enabled, and other oversights. Some of the problems are from simple forgetfulness after solving a problem and not having any sort of auditing to confirm that settings were what they should be. The Web caching and history problem, though, was a workaround that no one ever considered the ramifications on other areas, such as IR and forensics.

There's no simple solution to preparing your environment to be ready for an incident. Knowing what's there and making sure you have the necessary tools to handle them is key, but so is having clearly defined policies that get regularly reviewed and updated to address changes in the environment. Security needs to be plugged into all the IT processes in an organization and not just be something that one group is responsible for.

This is one of those problems that I'm sure permeates organizations no matter what industry you're in. Leave a comment or send me an e-mail if you've run into the same problem and how you solved it (if you were able to).

John H. Sawyer is a senior security engineer on the IT Security Team at the University of Florida. The views and opinions expressed in this blog are his own and do not represent the views and opinions of the UF IT Security Team or the University of Florida. When John's not fighting flaming, malware-infested machines or performing autopsies on blitzed boxes, he can usually be found hanging with his family, bouncing a baby on one knee and balancing a laptop on the other. Special to Dark Reading.

Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
COVID-19: Latest Security News & Commentary
Dark Reading Staff 6/5/2020
How AI and Automation Can Help Bridge the Cybersecurity Talent Gap
Peter Barker, Chief Product Officer at ForgeRock,  6/1/2020
Cybersecurity Spending Hits 'Temporary Pause' Amid Pandemic
Kelly Jackson Higgins, Executive Editor at Dark Reading,  6/2/2020
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Write a Caption, Win a Starbucks Card! Click Here
Latest Comment: What? IT said I needed virus protection!
Current Issue
How Cybersecurity Incident Response Programs Work (and Why Some Don't)
This Tech Digest takes a look at the vital role cybersecurity incident response (IR) plays in managing cyber-risk within organizations. Download the Tech Digest today to find out how well-planned IR programs can detect intrusions, contain breaches, and help an organization restore normal operations.
Flash Poll
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2020-13864
PUBLISHED: 2020-06-05
The Elementor Page Builder plugin before 2.9.9 for WordPress suffers from a stored XSS vulnerability. An author user can create posts that result in a stored XSS by using a crafted payload in custom links.
CVE-2020-13865
PUBLISHED: 2020-06-05
The Elementor Page Builder plugin before 2.9.9 for WordPress suffers from multiple stored XSS vulnerabilities. An author user can create posts that result in stored XSS vulnerabilities, by using a crafted link in the custom URL or by applying custom attributes.
CVE-2020-11696
PUBLISHED: 2020-06-05
In Combodo iTop a menu shortcut name can be exploited with a stored XSS payload. This is fixed in all iTop packages (community, essential, professional) in version 2.7.0 and iTop essential and iTop professional in version 2.6.4.
CVE-2020-11697
PUBLISHED: 2020-06-05
In Combodo iTop, dashboard ids can be exploited with a reflective XSS payload. This is fixed in all iTop packages (community, essential, professional) for version 2.7.0 and in iTop essential and iTop professional packages for version 2.6.4.
CVE-2020-13646
PUBLISHED: 2020-06-05
In the cheetah free wifi 5.1 driver file liebaonat.sys, local users are allowed to cause a denial of service (BSOD) or other unknown impact due to failure to verify the value of a specific IOCTL.