Root Cause and Following Actions
Can you identify the root cause? What I mean is, if you were presented with a question, about how an event occurred, could you show the logical progression of how that event occurred? And then describe to me the actions that followed? Maybe you are not the network/system/security administrator of your organization. Fine. Can your people answer those questions for you?
The SANS Glossary of Security Terms defines an event as “an observable occurrence in a system or network.” It also defines an incident as “an adverse network event in an information system or network or the threat of the occurrence of such an event.” But I am not talking about an incident. I don’t care if you have had an incident. What I want to know is if your organization has the ability to determine the steps that lead up to and happened after an “event.”
Because if you cannot describe to me the circumstances surrounding an event, you cannot describe to me the circumstances surrounding an incident. If you cannot tell me who initiated a connection to your web server from an internal asset, then you cannot tell me the actions that person performed after creating that connection.
Do you want to know what happened to your information or system at a certain time period? Are you obligated to know by policy, regulation, or just plain common sense? I can go so many different directions with this thought process. Really, it all depends on the persons that I am talking to and their roles within the organization.
One of the first things that I tell people who are just starting out in the security industry is that security is really the art of implementing good business practices. Although there are several specialized portions of the security industry, the majority of us are employed to ensure an organization is implementing sound and well documented methods to maintain a well-structured and profitable business. Unfortunately, the thing about good business practices is that it is driven by continued profit. And as we can see from the state of the economy, those profits are the very thing that can blind us to the affects of risk. Or at least provide us with the motivation to accept the risk. Of course I would love to believe my predictions from my last post about Conficker/Downadup – Securing The Internet as it is in my nature to trust these types of eventualities. But most likely a writer over at VistaSpyware.com is correct in the assumption that it is not in the nature of the industry to do so.
Although you might think that I am straying from the “Root Cause” theme here I am not. Because being able to determine root cause and follow on actions invariably depends on the methodology that you and your organization have implemented within your environment. If you have been lazy or sloppy about patch and asset management then you are not going to be able to attest to the state of your infrastructure. If you have decided to roll back logging and alerting because of the impact to storage space or network bandwidth instead of augmenting the technologies to handle the loads properly then you are not going to be able to attest to the state of your infrastructure. Scaling back on the infrastructure that does not necessarily provide an immediately measurable positive monetary impact on your environment will eventually lead to a state that you cannot provide accurate and detailed information about the root cause and follow on actions of an event.
Certainly, a good incident response team can piece many things together. Through hard work, knowledge, perseverance, and a lot (and I mean A LOT) of your money they will be able to provide you with the best report they can generate. And sometimes the information will be helpful possibly finding the root cause and follow on actions. But there are going to be other times when they cannot. Sometimes they will finish the initial contact phone call by providing you with quick recommendations on how to proceed, thanking you for your time, and then gently let you know that there just is not enough information to proceed with an analysis.
Now, here is the part where I ask you if you want this to be you. Well, actually, I am not going to. You have already decided. Or, it has already been decided for you. What I mean by that is that the resources you have already been given are in place and you will more than likely not get anything else. Or, at least, you need to begin thinking that way. I say that because everybody needs to start thinking about the resources that they already have in place and start implementing them properly. Start utilizing the technologies that have been deployed, determine how they work together and can augment each other, and then configure and manage them correctly. Pull back and start asking yourself, your team members, and your organization if you are doing the basics correctly. After you have done that, take a look at your more advanced technologies and determine if they are employed correctly to assist your organization in implementing the basics more effectively and efficiently. Because that is how the more advanced technologies are intended to be implemented. Until you have done all of this you should not be trying to find the next best security or business technology to act as your silver bullet or to help you “pull it all together.” Because if you do not have it all together in the first place, dropping something more complex into the mix is going to move you further away from your ultimate goal of cost effective implementation, stream-lined business methodology, and low-risk high-yield technology to revenue ratios (not sure where that last one came from, but it sounds good so I’ll leave it in).
To summarize, if you want to know when, how, and why you or your organization got hacked you have to prepare before hand. You have to employ basic business, technology, and security strategies thoroughly and correctly. Only then will you get a good answer to the question, “What was the root cause of this event/incident and what has occurred since the initial occurrence?”
Go forth and do good things,
Don C. Weber
Help support my training and travel to security conferences. Get your SANS Training and GIAC Certifications through the Security Ripcord.
You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.









January 24th, 2009 at 1:50 pm
I hope this does not distract from the spirit of your post, but your thoughts are applicable when it comes to some of the PCI requirements. Of course, there is the aspect of validating that the detect and response controls are effective – but the spirit of the “detect and respond”-related PCI requirement security controls are to facilitate RCA and hopefully minimize exposure.
January 24th, 2009 at 4:27 pm
[...] cause analysis” (RCA) in cases of payment card related events and or incidents (read blog post by Don C. Weber – “get [...]
February 11th, 2009 at 5:55 am
[...] Recent Comments Sandro Süffert on Leasons from GSP vs. BJ UFC FightDanny on Canceling Monster.comSecurity Ripcord » Blog Archive » Canceling Monster.com on Education and CertificationsSecurity Ripcord » Blog Archive » Canceling Monster.com on Cutaway Security LinkedInPCI-DSS Is Not About “Security by Obscurity” « Risktical Ramblings on Root Cause and Following Actions [...]