The InfoSec Blog
31Jan/11

IT AUDIT VS Risk Assessment – 2

We were discussing which should be done first and someone said:

The first has to be risk assessment as it is foundation of information
security. You first need to know where is the risk before putting up
any controls to mitigate that risk. Putting up adhoc controls will not
make the controls effective nor will it protect the organizations
against the risk.

While I understand the intent, I think that is very prejudicial language.

Donn Parker makes a very good case that we have the cultural context - read that sophistication and awareness of the baseline risks - to see that there should be a set of baseline controls. IAM, firewall, AV, backups and so forth. We don't need to leave the assets exposed to threats while we we wait around for a Risk Analysis to tell us that these baseline protective controls are needed.

Risk Analysis

You don't need to know the specific risks any more than you need to know the specific risks to have a lock on the front door of your house and close your windows.

I certainly wouldn't call this approach "ad-hoc".

English: The World Trade Center in New York. N...

Secondly, as I have pointed out many times, a Risk Analysis does NOT tell you what controls to implement.

This whole process has another logical flaw in that it analyses 'what is' and the risks to 'what is' and tries to protect 'what is'.
Sometimes that is far from efficient.

A simple example of this came from Padgett Peterson. He suggested that in the DMZ you should have one server for each protocol .... SMTP, POP, IMAP, HTTP, SSH, and so on. The firewall rules start with a "DENY ALL TO ALL" and then allow only the one protocol to each machine, and each machine has the minimum software to service that protocol. After all, machines are cheap.

Padgett proposed that model in the days before cheap '86 virtualization, and the usual complaint was the proliferation of machines. A CPU version of RAID :-)

But look what its done. It has ensured there is a separation of functionality. If a hacker takes over the SMTP server he have access to no other facilities.

Think "Security By Design".

A more common 'Security by design' (which I see lacking at many sites) is sub-netting. Even VLANs offer some separation - though I wouldn't assert that they are as definite a separation as a real subnet.

Sad story: I visited Staples (http://www.staples.ca) for some printer paper this week. They had a clearance on and were selling Cisco, LinkSys and 3COM Switches -- 16 port, 32 port, some rack-mount; all under $100. But none of those had VLAN capability. They seemed targeted at SMB; Someone in product marketing decided that SMBs don't need VLAN. How sad; how dumb.

My point here is that not only will will waiting for a RA leave you exposed when there are sensible and 'obvious' baseline controls you can put in, but that a RA will not only fail to tell you what controls you need, but won't tell you that you're doing things in an awkward and inefficient manner.

Yes, a smart auditor might.
Yes, a good systems architect might.

But my 30+ years experience as a consultant and the stories I hear from colleagues at various get-togethers tell me that companies of all sizes fail to get good initial advice and its not until they've been kicked in the teeth by a security incident do they think about security from an architectural point of view.

Of course there are exceptions, companies started by:

  • People from the military or law enforcement
  • People from companies that have been though the process and learnt

But there are enough companies lacking, small and large, to keep us all in jobs for a very, very long time.

To summarise:

  • Don't wait for a RA. Put the BASELINE controls in right away.
  • Baseline controls are NOT "ad-hoc".
  • RA Won't tell what controls you need, only what risks you face.
  • Good security architecture does a lot of the job and makes implementing controls easier.
Enhanced by Zemanta

Posted by Anton Aylward

Comments (0) Trackbacks (0)

No comments yet.


Leave a comment

No trackbacks yet.