17

Top Down vs Bottom Up

I recently sat an exam - I won’t name itfor obvious reasons. But it contained aquestion that went something like:

“You have a requirement to protect com-puter systems from theft and tamperingby employees, do you:(a) establish a physical security policy to

require only authorized staff to accesssensitive areas housing equipment

(b) implement physical security controlson computer room doors

(c) spurious answer 1(d) spurious answer 2”

It set me thinking, my gut reaction wasto answer “B” – after all it’s the actualphysical locks themselves that preventstaff from getting into the room – not thepolicy. However, one can also argue thatyou would only implement locks on thedoors because you had a policy in placethat required them. Intuitively we allknow to lock doors to keep people out,but it is not always as clear cut as towhich should come first (or which ismore important), the policy or the con-trol…

In the blue corner “Top-downSecurity”

At its simplest level a top-down approachappears most sensible. You start by defin-ing a High Level Policy which states thecorporate objectives and requirements forsecurity drawn from the business needs.

You then follow this up with SpecificSecurity Policies covering, say, physicalsecurity, user authentication and accesscontrol, use of email/internet access, etc.

These often are followed by Standardswhich take the objectives of a policy andactually state what the configuration of asystem should be, what is acceptable andwhat is not, or what controls must be inplace.

Underlying all this are the Procedures.Technical procedures covering how tobuild a system, how to verify a passwordchange request, how to manage an inci-dent as well as User-level or Operationalprocedures which might cover the processfor logging in, requesting access to a sys-tem, opening email attachments or chal-lenging unrecognized people withoutvisitor badges.

The result of all this documentation, ofcourse, is that a number of controls and configurations will be implement-ed, managed and checked within the

technical and physical environment.One advantage of this is that it is fairly

easy to audit. Within this hierarchy youaudit against Standards (i.e. does the con-figuration of a system match the definedStandards), you audit the completion ofProcedures (i.e. is there a box-file some-where containing signed off incidentreports). When it comes to Policy, thingsget a bit more subjective, you can assesswhether the Policy appears sensible,whether it covers everything it ought to,that there are no gaps – you can also auditthe policies, standards and procedures toensure they are mutually consistent.

In some cases (often where such a rig-orous approach has been taken) there willbe some underlying risk assessmentwhich will have been used to judge busi-ness requirements for security in terms ofthe impacts, threats and priorities forsecurity amongst all the other businessdrivers.

In the red corner “Bottom-upSecurity”

The only problem with this top downapproach of course is that sometimes itcan be heavy handed and a bit long wind-ed. Certainly for those of us with a more

“Top-down” versus“Bottom-up” – DifferentApproaches to Security Piers Wilson, Insight Consulting

Figure 1: Top down security strategy

Top Down vs Bottom Up

18

technical emphasis, or where we just needto get a solution in and working quicklyand with the minimum of fuss, there sim-ply isn’t time to start at that top level andwork down. We often rely more directlyon the experience, knowledge and skill ofour technical or physical security staff.

In many cases, the low-level controlsthat are required are well known. If youare going to connect a network to theInternet virtually everyone recognizes theneed for a firewall. Although you maynot know exactly how it should be con-figured, what the rule base should con-tain or what brand to buy; you would stillrecognize that you need one. For thedetails you speak to your IT, networks orsecurity staff.

It is the same story with anti-virus.No-one would deny that in the modernenvironment organizations need a goodAV software suite installed, but is havingthe software installed more or less impor-tant that having a corresponding policythat states “all files and attachments mustbe scanned for viruses prior to beingopened or saved onto the network” ?

The fact is that without any Policies orStandards at all, you can take an experi-enced IT/network/security consultantand achieve a reasonable level of securityfor your systems using their skills, knowl-edge and a selection of various securitytools and products.

There is this concept of “best practice”or the “industry norm” which many useas a shortcut to allow them to secure anenvironment without having to get thepolicies and documentation exactly right.For example, would you disagree withany of the following axioms?

• Internet connections should be fire-walled.

• Antivirus software must be installedon all systems.

• Users should have unique usernamesand passwords.

Servers/data should be backed up.• Buildings should be locked at night.

We could start with those five andaddress them without worrying about

any kind of formal policy (although onecould argue that we have already drawnup a five point network security policy inthat list).

A bottom-up approach is howeverharder to audit, at least formally. Ratherthan measuring a system against adefined Standard which is derived from aPolicy (and ultimately a risk assessment);we have to examine the environment tofind areas of weakness or back doors,assess configurations against what onewould expect or against “Industry bestpractice” and go through a mental (oractual) checklist as to what controlsshould be in place. Although this can bedone and does seem to work surprisinglywell (hence the market for securityreviews and penetration testing) it isreliant on:(a) the skill of the person doing the

assessment.(b) some assumptions with regard to the

business impacts and commercialimplications of vulnerabilities that arefound.

Seconds out … Round 1…

The reality is of course that neitherapproach on its own gives all the answers,you need to draw a balance.

You can undertake a comprehensiveRisk Assessment, draw up a NetworkSecurity policy only to end up with therecommendation that “you need a fire-wall”. You can almost hear eyes rolling asyou present that gem to the IT/Securitydepartment. You can of course argue thathaving gone through that process, youhave a clear business case for a firewalland that if someone asks you “Why haveyou got a firewall?” you can justify itsexistence.

The reality is though that nowadays inthe IT environment, the pressure of pro-ject schedules and the need to reactquickly to vulnerabilities means thatsometimes you have to just deploy thesolution, activate the fix or make the con-figuration change – that is why you needskilled IT and IT/physical security staff.

The bottom-up approach does carry

with it the risk of point solutions thatmight address a single perceived weaknessbut that don’t address the businessrequirements in the most effective way.So, for example, you might end up with20 individual firewalls securing a numberof external network links rather than asingle large(r) firewall with a DMZ ontowhich all external connections can be ter-minated.

Clearly from a cost and managementperspective, aside from the “Architecturalelegance” the former situation is notideal, at least with a more top-downapproach the requirements for “securingexternal network connections” might atleast lead to some consideration of theover-arching business needs for externalconnections, rather than leaving eachindividual project to secure its own out-side lines.

Seconds out… Round 2…

On the flip side, spending too much timeand placing all your emphasis on gettingthe documentation right you risk leavinglittle room for the technical experts to usetheir skills and creativity to deploy solu-tions that best address the technical aswell as the business requirements. As aclassic example, we have often seen pass-word policies that, having felt that 8 char-acter passwords are not secure, optinginstead for 10 or 12 character passwords.

Straight away this causes problems onsome systems, UNIX for example hastrouble with passwords longer that 8characters and Lotus Notes uses a rathermore elaborate scheme based on com-plexity. You also find that the longer thepassword the more likely, in reality, userswill have to write it down, keep forget-ting it, or just use the same passwordtwice (e.g. “passwordpassword”, ratherthan “password”).

A neater technical solution might be tointroduce a more secure mechanism suchas smart card or token-based login, whichreduces the ability to attack a system butwith greater ease of use for the users (withsmart cards anyway).

19

Vulnerability Analysis

The vulnerabilities all appear to be minor issues which independently onlyhave very limited impact on user systems.

The ease by which certain exploits forInternet Explorer vulnerabilities can bewritten in javascript allow many mali-cious sites to install hostile programs

such as browser tool bars with ads anddialers or other malware.

2003-11-25 - Internet ExplorerSystem Compromise Vulnerabilities

Liu Die Yu stirred together a combina-tion of some of these vulnerabilities and

created a sample exploit, which is able tolaunch arbitrary code on client systems.

The only efficient cure is to disableactive scripting which, unfortunately,only very few system administrators do.secunia.com/SA10298

2003-11-22 - Opera Browser Skin FileHandling Vulnerability

The Opera browser, which generally isconsidered a more secure alternative toMicrosoft's Internet Explorer also suffersits share of vulnerabilities. The latest vul-nerability is caused by an error in the waythat Opera handles skin files (files whichare downloaded automatically and usedto changes the appearance of Opera).secunia.com/SA10277

The Big Picture on BIg HolesThomas Kristenson, CTO Secunia

Once again we have seen information about vulnerabilities in Internet Explorer hit thepublic mail lists before Microsoft was informed.

The moral of this story is I suppose,that wheren a policy is drawn up fromthe top down but without any visibilityof bottom up issues there is likely tocome a point where it either becomes un-implementable or inapplicable, and whenthat happens – you get a Policy excep-tion.

Seconds out… Round 3

Ultimately of course you need a little ofboth. At a management or business levelit is important to develop at least somepolicy, for example a high level CorporateSecurity Policy, specific documents cover-ing high risk areas, perhaps virus con-trols, use of the Internet, physical securityetc…

Also, you have to recognize that eitherwithin the IT or Security departmentsthere is a considerable pool of expertise,or access to external assistance such asspecialist security companies, that willoften – for a given situation – be able tovery rapidly state what security controlsare likely to be required.

The real trick is in developing adequateand pragmatic Policies and Standards in

order that the objectives and baselinerules are defined, whilst ensuring thatexpertise is recognized, fostered and –most importantly – involved in the policymaking and standard setting process.This allows a much more focussed securi-ty strategy to be derived, based clearly onthe business objectives and requirements,but in tune with the technical environ-ment and which result in a usable andmanageable network.

Often when I am involved in projects (atall levels) the most interesting meetings arethe ones where the technical and businessusers of a client finally actually get to dis-cuss the requirements and how they couldbe met. Sometimes this hasn’t happenedup until this meeting, with the result thatyou have policies that don’t apply, aren’t rel-evant and have had to be ignored balancedagainst technical solutions that don’t meetthe business requirements.

In summary, it is as important to devel-op a top-down approach, but with aknowledge and understanding of thetechnical needs and environment, as it isto deliver technical solutions that meetbusiness needs and are in tune with thecorporate strategy.

Organizations have to get away fromthe culture where policy makers ignorethe “techies” as some sort of corporateunderclass more used to crawling roundunder desks and milling about in theserver room, or where business users andpolicy makers are dismissed as “the suits”upstairs who are ridiculed when theymandate that “random source ports mustnot be allowed” and that “only legal IPaddresses must be used”. Yes, I’ve seenboth of those in policies before…

Ladies and gentlemen thewinner by a judges decision inthe third round…

So what was the answer to the question atthe top? Well of course I don’t know, I cansay that I passed the exam so on balance Iprobably got the answer right. And, as aconsultant, I can say that both are needed.With one eye on BS7799 compliance orexternal audit I would also advise that hav-ing appropriate policies is very important.With my “techies” head on I would arguethat policy issues aside, it is the lock on thedoor that keeps people out.I answered B.