Day 31 - Legal Awareness
Happy Halloween and welcome to Day 31 of Security Awareness month. Today is the last day of our recovery week but before we head off into November and our Lessons Learned Days we have one more problem for you to ponder.
Today we are concerned with the legal issues that you may need to consider as you are wrapping up the incident. These could be based in compliance, or regulatory, breach notification, or other legal considerations.
Now over to you...what legal issues do you need to consider as part of incident recovery? Have you planned ahead to ease the legal reporting?
As usual please submit your ideas, and comments via our contact form and we will publish them throughout the day.
Once again, thank you for your ideas and comments...
One astute reader points out...
"The time to consider legal issues is not when you are "wrapping up" an incident. When a security incident is declared (however your team does so) legal should be in the loop from the beginning. Our legal counsel sits in on our CSIRT meetings and there are specific questions that need to be answered within the first 60 minutes of an event as part of our CSIRT SLA.. Discussions about reporting or disclosure requirements, when and how to notify partners, etc. should be known upfront and handled according to a prepared plan. This doesn't mean that there won't be modifications required to fit particular incidents but thinking about these things at the tail end of an incident is a recipe for unhappiness."
another amazing reader commented...
"One thing that should be outlined in anyone's incident response plan is how they're going to handle the data, even before they start any investigation. Especially in criminal cases, if the evidence is not forensically sound or the chain of custody doesn't exist, the evidence is often inadmissable. Improper collection methods are very often used to get evidence removed from cases. OJ's defense attorneys successfully attacked the collection methods of the evidence - the same is true of electronic data. Consider this: If all of the logs/data related to the incident are inadmissable, will you have much of a case against an individual?
Chain of Custody can not be emphasized enough. If you start collecting data for purposes of potential legal action, maintain strict logs, including who collected the data, how it was collected, where it was found, where it is stored, who has accessed it, etc. You can't over-document in this area. Also be sure to restrict access to any of this information - put the information on a removal drive and lock it in a secure location, don't just save it to a network drive where others could, in any way, access it without it being logged. You can be called to testify to the extent of your expertise, collection methods, and to the authenticity of the data. I've watched well seasoned IT professionals crumble under the scrutiny of a good attorney under questioning. One individual would likely have given an arm to have logs of his data collection.
It is often in your best interest to get a certified computer forensic examiner involved. These professionals have the training and knowledge to properly preserve data and ensure it's properly collected should legal actions arise.
In short, have your plan in place long before the incident occurs. You don't want to be contaminating evidence should you find reason to go to court over an incident. If all else fails, C.Y.A. - Call your attorney."
One of our readers from across the big pond pointed out...
"A common mistake I've seen is people trying to apply the legal system they're familiar with to other juurisdictions where legislation, regulations etc. are simply different, sometimes even based on different fundamental principles. If you're a multinational you'll need to take into account all legislation in all your locations into your policies. It's not that easy."
Rick
-- Rick Wanner rwanner at isc dot sans dot org
VMWare ESX security patches
VMWare have released a new security advisory, and has updated two previously announced advisories.
Details are available via the VMWare web site:
- VMSA-2008-0017 (new advisory)
http://lists.vmware.com/pipermail/security-announce/2008/000039.html
Summary : A denial of service flaw was found in the way libxml2 processes certain content. If an application that is linked against libxml2 processes malformed XML content, the XML content might cause the application to stop responding.
CVE Reference: CVE-2008-3281
Summary: A flaw was found in the way ucd-snmp checks an SNMPv3 packet's Keyed-Hash Message Authentication Code. An attacker could use this flaw to spoof an authenticated SNMPv3 packet.
CVE Reference: CVE-2008-0960
Summary: Multiple uses of uninitialized values were discovered in libtiff's Lempel-Ziv-Welch (LZW) compression algorithm decoder. An attacker could create a carefully crafted LZW-encoded TIFF file that would cause an application linked with libtiff to crash or, possibly, execute arbitrary code.
CVE Reference: CVE-2008-2327
- VMSA-2008-0014.3 (updated advisory)
http://lists.vmware.com/pipermail/security-announce/2008/000040.html
This is an updated advisory which impacts a wide range of VMWare products (both desktop and server), and covers 16 CVE's.
- VMSA-2008-0011.3 (updated advisory)
http://lists.vmware.com/pipermail/security-announce/2008/000041.html
This is an updated advisory which ESX products only, but covers 9 CVE's
These advisories list security issues that have been fixed in the patches for ESX 2.5.4, ESX 2.5.5., ESX 3.0.2 and ESX 3.0.3 released on 30th October.
Sprint-Cogent Peering Issue
Several readers have reported that late this afternoon Sprint appears to have depeered Cogent, isolating Cogent from the Internet. We haven't got a lot of concrete details at this time, but will continue to monitor the situation.
-- Rick Wanner rwanner at isc dot sans dot org
Comments