False Positive Forensics

Institutions often have a well defined incident response process, and may have either in-house or contracted forensic and incident analysis professionals. They should have a well defined process for handling incidents, and that well designed response process needs:

• Trained support for end users, servers, and the network that support must have
  
• An escalation process that leads to
  
• A central group or team responsible for investigating incidents who have
  
• A documented process using
  
• Standardized tools which helps shape
• A decision process from which
  
• A report is written in a common and understandable report format which
• Guides management and further responses

Communication of this is also important, as any step that isn't properly communicated can lead to a failure - either in the process, or in the implementation of the process.

Once the process is started however, there are three possible answers that can be found. This post focuses on the third answer, but first we need to discuss the worst case scenarios. In these three scenarios, I use two definitions: event - a documented occurrence that leads to an investigation, and incident - an event that when investigated turns out to be a compromise, exploit, or other actual compromise.

1. There is a real incident, and responses must handle the compromise, data loss, or other event. This may be part of an ongoing cycle, as some compromises lead to further investigation.
   
2. There may be a real incident, but insufficient data is available to assess the situation. In this case, response is typically to restore operation and to verify that the system or application fully meets current standards. This is typically accompanied by further monitoring of the system to ensure that a second compromise does not occur due to an unknown or undocumented problem.
3. Finally, the incident may be a false positive. In this case, the goal is to prove that the event was not an incident. This can be just as difficult, if not more so than proving that an incident occurred.
   

How can your organization handle forensics for these false positives? Often, the best route is to verify 5 things - you may pick and choose from these, depending on the system, and you might even add event appropriate checks beyond this list, but often you must check for these:

1. Verify that there is no sign of the reported event. If a system is reported to have acted like a system infected with a trojan, then verify that the system does not display any of the characteristics of a trojan infected system.
2. Check that the system or application matches its documented configuration. This is where Tripwire and other file integrity checkers may come in handy. In the some cases, simply checking MD5 sums and directory file lists from a matching system may help.
3. Check local logs for signs of compromise.
   
4. Check netflows, firewall logs, and other network traffic logs to determine if the system was inappropriately accessed or if it attempted to connect to remote sites.
5. Finally, look for a plausible cause for the behavior that caused the original alarm. In some cases, this is user error, or a misunderstanding, or a process that resulted in unexpected results.

In most cases, false positive forensics are a best effort task - proving beyond a shadow of a doubt that nothing happened is difficult on any but the best documented and monitored systems, and the great majority of workstations - and even servers don't fall into this category.

Once you have your documentation, two last tasks remain - documentation and communication. A report, even a simple "no sign of compromise" is required, and you should communicate to the affected user and support person. This is where appropriate thanks will pay off for future real events, and it can also serve as an excellent opportunity to sponsor awareness.

Conficker Roundup

The Conficker worm is the current information security hot topic, with tomorrow's activation date looming and lots of press hype. Here are some of the best resources out there for those who have to either fight Conficker, or the hype around it.

• The ISC has an excellent roundup.
  
• Microsoft's technical page on Conficker and their home user page.
  
• F-Secure provides Conficker information in a nice Q&A format.
• Brian Acohido has a timeline of Conficker's verisons
• SRI's technical analysis is great if you want deeper technical view of Conficker.C.
  
• SecureWorks notes that the April 1st date that the media has hyped isn't as significant as other writers might have you believe, "The only thing that will happen with Conficker on April 1st is that already-infected systems will begin to use a new algorithm to locate potential update servers." The article is well written to help explain why April 1st should not be a panic date.
  
• The Honeynet Project has released their paper titled Know Your Enemy: Containing Conficker, as well as a detection tool called Downatool2.
• The Conficker Working Group wiki (edit: currently not available)
• The Malware Protection Center provides detail as well: Information about Worm: Win32/Conficker.D and an Update on Conficker.D. Conficker.D has a better domain generation algorithm, and thus will attempt to download from 500 of 50,000 servers, rather than the much more limited earlier versions.
• The major AV vendors each have a writeup: McAfee, Symantec, Sophos, and others are all on board.

3rd Party Reporting and Monitoring

Various third parties are monitoring for Conficker and will allow you to sign up to receive data about your network using your ASN or IP range. A full list will be available shortly.


Conficker Cleanup and Removal

• F-Secure provides a free tool called Easy Clean
• SecureWorks has removal instructions using F-Secure or Microsoft's Malicious Software Removal Tool.
• McAfee's Stinger now has Conficker support
  
• McAfee and AVG users are advised to run an on demand scans.
  

A Weird Al Virus Alert flashback

A few years ago, Weird Al released a video titled Virus Alert. If you're a Weird Al fan, here's the security video for you.

HITECH, common sense and where's my bailout?

Full disclosure, I am not a lawyer - and you should work with your legal cousel to determine proper courses of action.

If you haven't been following the ARRA (American Recovery and Reinvestment Act of 2009) and the provisions within it you should. Even there you'll find a focus on increased information technology in human services, cybersecurity and consumer rights.

Signed into law March 17 2009, the ARRA includes the HITECH (Health Information Technology for Economic and Clinical Health) provisions which serve to not only urge physicians to adopt the use of electronic health records, but also tweak the original language of HIPAA. Some of these tweaks are good for consumers, as it provides them more control over their private information while at the same time work intensive for health IT professionals, vendors and Business Associates. The latter is so because the HITECH provisions now require an accountability for all disclosures of PHI. This means that any disclosure or use of PHI now must be accounted for within treatment, payment and operations , whereas before the information could be shared without account for these purposes.

While this may seem trivial, the original language providing for unaccountable exchange of your information, allowed EHR vendors or Business Associates to develop and operate systems without the features needed to provide a full account of every disclosure. While the legislation does not kick into force until 2014, patients will be able to request an accounting of disclosures for up to the last three years - read you might need to be ready by January 1, 2011.

Also updated are the breach disclosure provisions which will now require practices to post information about security breaches if a breach affects 10 or more patients. If a larger security breach occurs, one affecting 500 or more patients, practices must notify all of their patients, a local media outlet, and the HHS secretary. This now brings HIPAA regulations in line with many state's legislation regarding breach disclosure.

And then there's the money. HITECH/ARRA also calls for increased enforcement rules and a new fervor in leveeing financial penalties. Fines for security breaches start at $100 and can go as high as $1.5 million. In addition, the legislation empowers state attorneys general to enforce some HIPAA elements and gives them the authority to bring class action suits.

While there are obvious implications for practices small and large - the affect will be felt throughout the health IT community for years to come. If you or the company(ies) you support work at all with medical information (covered entity or not) you should take the time to review this new legislation, audit your systems and review your policies and procedures.

8,000 User IDs Passwords Exposed on Scribd

The New York Times reports that as many as 8,000 usernames and passwords were exposed in what may have been a phishing attack result that was posted on Scribd. Original reports pointed to a potential Comcast connection, but Comcast has denied that idea.

What should horrify security minded readers is the quote from the gentleman, Kevin Andreyo who the article lists as an educational technology specialist in Reading, Pa., and a professor at Wilkes University who made the discovery: "That isn’t just my password for Comcast, it’s my password for everything that is not tied to my credit card".

How many of the people that you are responsible for could say the same thing?

iPhone Security: is the iPhone's security model a threat in your enterprise?

Creative Commons licensed image courtesy Refracted Moments.

SearchMobileComputing's Lisa Phifer interviewed McAfee research scientist Jonathan Zdziarski in a recent article. Zdiarski has done extensive work with iPhone forensics, and points out a number of the major issues with iPhone data security including:

• The easy with with the passcode can be bypassed
• The lack of secure deletion, either via a native utility or an App store application
• Lack of encrypted filespace based on a key in the OS partition
• Unencrypted data synchronization

If you're facing iPhone usage in your organization, this article is one of the better recent overviews. For now, following the CIS iPhone security benchmark draft may be your best bet if you have to support iPhones.

P2P Filesharing Dangers: Marine 1 Blueprints?

Blueprints for Marine 1 were found by employees of Tiversa, a P2P monitoring company. The blueprints and avionics package were found in a file that appeared to have come from a defense contractor's network - the news article's spin sounds like a sales pitch for Tiversa's services, but the point remains useful.

Corporate IT knows the dangers that P2P programs can pose - many have default shares enabled, and some of them share a larger portion of the user's hard drive than might be expected. There are controls: extrusion prevention, local system lockdowns, and periodic software scans, but they require a strong set of corporate IT policies and security standards that are effectively enforced. For some systems, this is where access controls come into play - the system containing protected information shouldn't have had outbound Internet access in the first place!