Thought of the Day

I've been working on writing my latest book and got to a section of the first chapter where I talk about analysis and what that means. As I was writing, it occurred to me that there are some basic concepts that some analysts take for granted, and others simply do not understand. Keeping these concepts in mind can help us a great deal with our exams.

Locard's Exchange Principle
Edmund Locard was a French scientist in the early part of the 20th century who originated the principle that when two objects come into contact, material is transferred between them. This is as true in the digital realm as it is in the physical world. When malware reaches out to find other systems to infect or to contact a CnC server, there is information about these connections on the system. When an intruder accesses a system, there is information about the system their connection is coming from as well as information about their activities on the compromised system. In many cases, the information may be degraded due to temporal proximity to the event, but it will have been there.

Least Frequency of Occurrence
I credit Pete Silberman of Mandiant with this phrase, not because he was the first to use it (some searches indicated pretty quickly that it is used in other fields), but because his use of it was the first time I heard it applied in a profound manner to the IR community. At the SANS Forensic Summit in 2009, Pete used this to describe the occurrence of malware on systems, and looking back over other exams I'd performed, it occurred to me that the same thing is true for intrusions.

The concept is amazing in its simplicity...given normal system activity, malware and intrusions occur least frequently on that system. Say, malware is installed as a Windows service set to launch at system startup as part of the SvcHost process...you've got one file (DLL on the drive), a few keys/values in the System hive, and one in the Software hive.

Okay, so the practical application of this is that we're NOT looking for massive toolsets being loaded onto the system. Listing all of the files on the system and sorting by creation date (in the absence of modification of time stamps) is more likely to show you OS and application updates than it is when the malware was installed. The same sort of thing applies to an intrusion.

Goals
In short, goals are the beginning and the end of your exam. What are you looking for, what questions are you trying to answer? Your exam goals drive your analysis approach and what tools you need to use...and it should never be the other way around. Tools should never drive your analysis.

HTH.

Thought of the Day

Don't be dependent upon tools; rather, focus on the goals of your exam, and let those guide you.

When starting an exam, what is the first question that comes to mind? If it's "...now where did I leave my dongle?", then maybe that's the wrong question. I'm a pretty big proponent for timeline creation and analysis, but I don't always start an exam by locating every data source and adding it to a timeline...because that just doesn't make sense.

For example, if I'm facing a question of the Trojan Defense, I may not even create a timeline...because for the most part, we already know that the system contains contraband images, and we may already know, or not be concerned with, how they actually got there. If the real question is whether or not the user was aware that the images were there, I'll pursue other avenues first.

Don't let your tools guide you. Don't try to fit your exam to whichever tool you have available or were trained in. You should be working on a copy of the data, so you're not going to destroy the original, and the data will be there. Focus on the goals of your exam and let those guide your analysis.

Thought of the Day

Today's TotD is this...what are all of the legislative and regulatory requirements that have been published over the last...what is it...5 or more years?

By "legislative", I mean laws...state notification laws. By "regulatory", I mean stuff like HIPAA, PCI, NCUA, etc., requirements. When you really boil them down, what are they?

They're all someone's way of saying, if you're going to carry the egg, don't drop it. Think about it...for years (yes, years), auditors and all of us in the infosec consulting field have been talking about the things organizations can do to provide a modicum of information security within their organizations. Password policies...which includes having a password (hello...yes, I'm talking to you, sa account on that SQL Server...) - does that sound familiar? Think about it...some auditor said it was necessary, and now there's some compliance or regulatory measure that says the same thing.

As a consultant, I have to read a lot of things. Depending upon the customer, I may have to read up on HIPAA one week, and then re-familiarize myself with the current PCI DSS the next. Okay, well, not so much anymore...but my point is that when I've done this, there's been an overwhelming sense of deja vu...not only have infosec folks said these things, but in many ways, under the hood, a lot of these things say the same thing.

With respect to IR, the PCI DSS specifically states, almost like "thou shalt...", that an organization must have an incident response capability (it's in chapter 12). Ever read CA SB 1386? How would any organization comply with this state law (or any of the other...how many...state laws?) without having some sort of incident detection and response capability?

My point...and my thought...is that this is really no different from being a parent. For years, organizations have been told by auditors and consultants that they need to tighten up infosec, and that they can do so without impacting business ops. Now, regulatory organizations and even legislatures have gotten into the mix...and there are consequences. While a fine from not being in compliance may not amount to much, the act of having to tell someone what happened does have an impact.

Finally, please don't think that I'm trying to equate compliance to security. Compliance is a snapshot in time, security is a business process. But when you're working with organizations that have been around for 30 or so years and have not really had much in the way of a security infrastructure, compliance is a necessary first step.