Digg this story   Add to del.icio.us  
The Panacea of Information Security
Jason Miller, 2004-08-12

Step away from all the vendor hype. The one device that will always be the best tool for information security is a competent security professional.

If you listen to enough people (especially vendor sales people), you'll find that there are a lot of different products and technologies being offered as the solution to all of your network security problems. However, any good security professional will tell you that information security isn't a problem that can be solved, but instead, is something that needs to be managed.

In my last two articles, The Allure and Curse of Complexity, and Secure By Default, I talked about some of the golden unavoidable truths of information security. To summarize, these articles talk about the difficulty of maintaining security in complex environments, and the security of operating systems as related to their default configurations. If you look close enough, both of these articles share a common theme, which is something that I'd like to elaborate on.

Security is, at its most basic level, about knowledge and understanding. I know it sounds like a cheesy cliché, but it's certainly the truth.

How Knowledge Fits In - Prevention, Detection, and Response

I'm not certain if it was Bruce Schneier who originally discussed the three-layer concept of Prevention, Detection, and Response, but I was first introduced to this concept in his book Secrets and Lies - a great non-technical book on information security, I might add. These three layers split up the landscape nicely for this discussion, and I'm going to do my best do cover the relationship between knowledge and these three layers of security in as short a space as possible.

Prevention:

Vulnerabilities typically arise when a software developer does not understand what his particular function/module/project will do when fed certain inputs. This could arise from a lack of understanding about the language itself, or the inner workings or interactions of the actual program. An attacker wins when he understands the behaviour of the application better than the developer of the software or the administrators who maintain it within their network infrastructure. The latter case is
especially true when vulnerabilities are configuration-based, and as such, are introduced (or in some cases left in) by an administrator that is not fully aware of the consequences of his configuration choices.

Detection & Response:

As we move to discussion of detection and response, this relationship between knowledge and information security should become immediately apparent. Although it's difficult to say that one aspect of security is more important than another, it is important to note that absolute prevention is impossible. For this reason, the ability to detect attacks, and more importantly the successful ones, is paramount to any solid security policy.

The first technology that's typically associated with attack detection is IDS. We've got NIDS, and HIDS, NIPS, and HIPS, signature and anomaly-based systems, event correlation and log management consoles, and otherwise enough different detection and correlation technologies and acronyms all with multiple meanings to different people that I get sick to my stomach just thinking about it. These devices, though incredibly interesting and powerful, need technically adept analysts to function to their full potential.

In a best case scenario, even if an IDS event is issued, verified, correlated, and presented to an analyst on a silver platter, all but the most simple of attacks will require some solid technical skills in order to determine what has been going on. Was this a known or new vulnerability being exploited? (Anomaly-based systems can certainly catch the latter.) What was targeted, and was it successful? If the attack involved shellcode, what does the shellcode do? What actions did the attacker perform on the compromised computer? Does this compromise reflect an underlying issue in the security policies governing the machine? And so on. The actual response to this issue might involve a post-mortem analysis of the computer, in which case a copy of Encase is only going to get an analyst so far without the right underlying knowledge to understand what to do. If the analyst has the skill to perform this analysis well, a plethora of information about the attack can be determined.

As basic as this sounds, I'm convinced that this isn't common knowledge. If you want to do a good job of preventing, detecting, and responding to compromise, you need competent people to design, implement, and maintain your network. A <insert magical security device here> just isn't going to do it with the same level of effectiveness.

Why Open Source Makes Security Easier

If you didn't buy my piece on complexity being antithesis to security, perhaps this discussion of knowledge and understanding will help you see my point.

If you'd like to understand how a system works, there's no better way than to look at the source code. I know this doesn't apply in every or even the majority of cases, but it does apply to the discussion at hand; the better you understand something, whether it's an operating system, an application, or any other arbitrary system, the better you're going to be able to evaluate
and manage the security risks associated with it.

Now, I'm not suggesting that people running Apache need to be familiar with the source tree, but I do very much believe that a solid understanding of programming (especially C and assembly) will greatly aid any professional involved in information security.

On the other hand, with a closed source system, your options are limited. Sure, you do have options available to you, but they're rarely as good as access to the source code. I personally think that many security professionals would be much more comfortable working on a Windows-based operating system if they were able to understand it as well as they understand Linux or BSD; I know I would. Although something could be said for the complexity of Windows contributing to this just as much as it being closed source, that isn't the point of this article.

Does this make open source systems more secure than closed source systems? Well, yes and no. This is actually a pretty complicated question, and so I'm not even going to address it in this short article. I do, however, find that open source software offers me some definite benefits (and also concerns) over closed source. Open source software gives me a better opportunity to learn and understand some of the tools that I make regular use of, operating systems and applications included.

Knowledge and understanding are directly related to security. This is applicable on several different levels, from application design and programming, to network and operating system administration, and ultimately, security management. Computers and computer networks are pretty complicated, and as such, achieving good information security isn't an easy task. There is, however, one device that will always be the best tool for accomplishing that goal: a competent security professional.


Jason Miller manages the Focus IDS area for SecurityFocus.
    Digg this story   Add to del.icio.us  
Comments Mode:


 

Privacy Statement
Copyright 2010, SecurityFocus