subject: The Panacea of Information Security
posted: Wed, 01 Sep 2004 11:22:50 +0100


http://www.securityfocus.com/columnists/260

The Panacea of Information Security

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.
By Jason Miller Aug 12 2004 11:18AM PT

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 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.

---
* Origin: [adminz] tech, security, support (192.168.0.2)

generated by msg2page 0.06 on Jul 21, 2006 at 19:04:06

 search: