Thursday, November 16, 2006

Common Security Mistakes

I received an email asking me to name common enterprise security mistakes and how to avoid them. If I'm going to provide free advice via email, I'd rather just post my thoughts here. This is my answer:


  1. Failure to maintain a complete physical asset inventory

  2. Failure to maintain a complete logical connectivity and data flow diagram

  3. Failure to maintain a complete digital asset/intellectual property inventory

  4. Failure to maintain digital situational awareness

  5. Failure to prepare for incidents


The first three items revolve around knowing your environment. If you don't know what houses your data (item 1), how that data is transported (item 2), and what data you are trying to protect (item 3), you have little chance of success.

Once you know your environment, you should learn who is trying to exploit your vulnerabilities to steal, corrupt, or deny access to your data (item 4). Security incidents will occur, so you should have policies, tools, techniques, and trained and exercised personnel ready to respond (item 5).

15 comments:

LonerVamp said...

Excellent advice!

I hope it drives home the need for what basically boils down to documentation. The kind of stuff far too many techies groan about. Inventory, diagrams, asset lists, processes...security is not all about the fun metasploits and ethereals and IDS appliances.

Anonymous said...

Richard,

Well done! I couldn't agree more!

Very often when I'm on-site, I tend to ask questions regarding connectivity that the client simply cannot answer.

Many times during an engagement, the client will ask me if there was any sensitive personal info (SSN, credit card numbers, etc.) on the system that was attacked/compromised...and very often, I'm incredulous. I mean I simply find it hard to believe that I'm on-site to help "put out the fire" as it were, and I'm being asked by the person who owns the system what's on it (ie, applications, data, etc.).

Very well done!

Harlan
http://windowsir.blogspot.com

iamnowonmai said...

Thank you for the free advice via you blog!

Anonymous said...

Do you have example or link to an example of a complete logical connectivity and data flow diagram.
Thank you very much

Rob Lewis said...

These comments are good and to the point. I would like to tie them into the "Firewall This" diagram by Andre Durand from the previous Five Blog Posts You Should Read post.

Looking at that convoluted mess that represents a complex enterprise today, and applying your statements, how could one not start at the core where the data is kept and determine business data flow (file access) from there, as opposed to edge security?

NoticeBored said...

Um, I beg to differ. Having inventories, meaning documented lists of things (as implied by most of the previous comments if not stated by Richard), is 'just' a documentation exercise. There's surely a danger of 'knowing the price of everything but the value of nothing', in other words the inventories are only helpful if management uses and makes sense of the raw data. Risk analysis is, for me, the essential element: someone has to look at what the organization has, identify the information security threats, vulnerabilities and impacts, and design appropriate security controls that need to be implemented. The inventories are one way to start the process, admittedly a good way but strictly speaking not the only way. It is equally possible, for example, to start with the "obvious at-risk information assets" - the databases of corporate and personal secrets, the 'bet the business' applications, the 'business critical networks' etc. that senior management or any knowledgeable independent observer would regard as vital [many organizations are doing this already in the guise of "SOX-relevant processes and systems"]. If these are properly secured as a first step, other less-critical information assets necessarily get protected at the same time and the remainder can be addressed through second and subsequent steps. Classification of information assets is another way to achieve this aim. We do not need to complete a thorough, complete and accurate classification in order to appreciate that certain assets are bound to require strong security measures. You could even say that completing the inventory or classification is merely wasting time that could be better spent on securing the vital assets.

Richard Bejtlich said...

NoticeBored,

I think it is important to have an inventory of every host for which you are responsible. Anything can be a vector for attack. I've seen print controllers used to attack other hosts, and no one knew these boxes even had IP addresses or ran a vulnerable version of Windows (or ran Windows at all)!

Of course you should care about the high priority items as determined through risk assessment, but how can you perform that exercise if you haven't identified every asset?

Richard Bejtlich said...

I hope everyone realizes that I am not advocating FISMA or C&A or the other broken .gov approaches when I mention "inventories."

Anonymous said...

noticebored,

Having inventories, meaning documented lists of things...is 'just' a documentation exercise.

I'm sorry, but I cannot agree with that.

As a responder, I've been called on-site to examine systems that could be located via the network, but not physically within the server room. Nobody, including the person who administered them on a daily basis, knew where they were physically located.

I can't tell you how many times I've sat down with an image of a system and been asked by the client's IT staff if there was any personal sensitive data on the system. That's right...they had no application inventory, and though they knew that there was a system someplace that processed credit card transactions, they had no idea where it was in their infrastructure.

From a business perspective, look at it this way...the IT staff can run through the "documentation exercise" and limit the effects of an incident prior to calling in responders (who bill out at $300+ per hour) or they can sit back and let the responders chew up hours doing it for them, while there's an ongoing incident.

...the inventories are only helpful if management uses and makes sense of the raw data.

Very true. I've been advocating more senior management focus on security in my blog.

Adam said...

Excellent list Richard! Add a few more mistakes and go into some detail and you'd have a pretty nice book. Speaking of which, can you say what the topic of your next book going to be?

Richard Bejtlich said...

Hi Adam,

Thanks for your comments. I have a few projects in mind.

The first is a second edition of Tao that incorporates Tao and Extrusion.

The second is a second Real Digital Forensics, but not a second edition -- an entirely new book.

The third is Hacking TCP/IP Illustrated, based on my TCP/IP Weapons School class.

The fourth is tentatively called Network Forensic Analysis, which would be the network equivalent of Brian Carrier's File System Forensic Analysis book.

Adam said...

Wow. They all sound great, I'd happily buy any one of them. Try not to make us wait too long though, the wait for RDF and ED nearly killed me. :)

Anonymous said...

If peoples are good educated in all these security features, then will be less problems!
Information security awareness triaining: www.infosecuritylab.com

LonerVamp said...

I guess I cannot easily fathom how inventories are a management function and that some places just don't do them. We don't, I admit, but it digs at me every single week and I hate it. Inventories, to me, are a fundamental concept that are required for my to function. Kind of like being presented with a complex problem and not having access to the data or multiplication tables...you can only make stabs and guesses...

Anonymous said...
This comment has been removed by a blog administrator.