information. All vulnerabilities reported tothe CERT/CC will be disclosed to the pub-lic 45 days after the initial report, regardlessof the existence or availability of patches orworkarounds from affected vendors.Extenuating circumstances, such as activeexploitation, threats of an especially serious(or trivial) nature, or situations that requirechanges to an established standard mayresult in earlier or later disclosure.Disclosures made by the CERT/CC willinclude credit to the reporter unless other-wise requested by the reporter. The CERTsaid they would discuss their publicationplans with any affected vendors, and negoti-ate alternative publication schedules withthe affected vendors when required.Personally, I think the policy is more thanreasonable. A recent example of it was pro-vided by the CERT Advisory CA-2002-10Format String Vulnerability in rpc.rwalld.The rwall daemon (rpc.rwalld) is a utilitythat is used to listen for wall requests on thenetwork. When a request is received, it callswall, which sends the message to all termi-nals of a time-sharing system. A formatstring vulnerability may permit an intruderto execute code with the privileges of therwall daemon. A proof of concept exploit ispublicly available, but we have not seenactive scanning or exploitation of this vulnerability.

Manage system vulnerabili-ties at the company levelGranted that an operation such as the onedescribed above can also be carried out

directly by an end user’s team, the vulner-abilities that are discovered within a net-work or a system are different and regardthe operation of an application more thanits design. This is why, in this case, thevulnerability assessment procedures arecarried out from a higher perspective andmainly regard the following:• The existence or absence of an

upgrade for a platform in which a vul-nerability has been discovered and dis-seminated or a problem ofconfiguration and administration hasbeen reported. This is carried out bythe so-called ‘tiger teams’, who useautomated tools or vertical techniquesto check the state of health of the tar-get system.

• The testing via a black-box approachof the state of health of the targetstructure, mimicking the actions of anexternal attacker who doesn't know alot about an objective other than theinformation available from conven-tional information gathering activi-ties.

• The proposal of corrective measuresfor the problems discovered, whichmay not only be architectural but alsobehavioural or policy related:

Here too the corrective actions for the problems must be carried out thor-oughly and responsibly. Usually a periodof maximum tolerability is indicated inthe literature, after which the vulnerableapplication absolutely has to be upgrad-ed to prevent dangerous phenomena

such as the failure to remediate suchnotorious vulnerabilities as .Ida (cfr.Code Red). In this regard, the recom-mended response times are a maximumof seven working days for the applicationof ‘ordinary’ patches and 48 hours forthe critical ones. This requires full atten-tion to all the news on new bugs andsecurity issues. Some organizations usetesting laboratories in which upgradesundergo a testing period before releaseinto the regular IT life cycle.

ConclusionsThere are currently two topics that ani-mate debate in the technical community.The first one regards the opposing posi-tions of ‘No’ vs. ‘Full’ disclosure of securi-ty bugs. I personally feel that the ‘nodisclosure’ position is potentially counter-productive and, in some cases, also inconflict with the codes of ethics of someprofessionals such as the CISSP, who urgethe prompt release of security informa-tion. In my opinion the policy adoptedby CERT is most reasonable. An equallyimportant issue regards the managementof system vulnerabilities, to be carried outat the company level. In this case the poli-cies must be an action area, with part-icular emphasis on the proactive manage-ment of potential bugs. In short:although there is no unified vulnerabilitymanagement policy, since each segmentdiffers from the others, a shared effort inthe direction of ‘vulnerability manage-ment’ is more than desirable.

13

Given the richness of the functionali-ty within Windows 2000, a majorproblem when trying to secure it is todecide which bits matter. There are somany features and tools, some for secu-rity and some for convenience, and itisn’t always easy to find out preciselyhow they work or what their impactwill be.

The aim of these two articles is to identify the areas which affect securi-ty in a major way. To do this, I’ve donea lot of selecting, and some of the iceI’m skating over is pretty thin.Nevertheless, if you have limited time

feature

Security and Windows2000: Part 1Alison Webb

Microsoft’s entry into network directory services should satisfy two sets ofusers. In the past, most administrators preferred Novell, with its moreadvanced directory services, because it offered more flexible and easier ways tomanage and secure the network. Most end-users, on the other hand, preferredMicrosoft, because the Explorer shell made it easy to look around the networkand perhaps share files in an informal way. Now, Windows 2000 gives us thebest of both worlds: familiar and popular features for users, but with ActiveDirectory to provide the management support.

05 nese may.qxd 5/20/02 4:16 PM Page 13

and want to focus on security, I’ve triedto summarize what seem the mostimportant features. As ever, once youhave some practical experience you willbe able to explore in more depth theareas most appropriate to your site.

This article describes the architectureof Windows 2000, and in particularActive Directory, which is core to thesystem; the second article looks in moredetail at specific security features.

What does Active Directorydo, exactly?I think there’s quite a lot in commonbetween Active Directory and the rule-book for one of those role-play gamespopular at the moment. The idea of sucha game is, very roughly, to act out anadventure story involving a number ofdifferent characters. These characters,each assigned to a player, have clearlydefined personalities which prescribehow they will react in a variety of circumstances. They may also have special powers, like the ability to castspells. Various objects are available tohelp the players, like pack animals orarmoured cars, and they move through apre-defined landscape. Thus the game isa sort of representation of real life, but with significant restrictions on complexity.

The more cynical might say that this isnot so different from the average busi-ness environment — and this is clearlyMicrosoft’s view too. Active Directorydefines the landscape (sites and net-works) the available kit (servers andworkstations) and the characters (usersand administrators). It also defines anyspecial powers they possess. It does thisby holding a definition of each entity or‘object’.

So, as every textbook on Windows2000 emphasizes, how you define yourDirectory structure is crucial because itdefines the rules of your business ‘game’.

Which bits of Active Directorymatter for security?I’m going to concentrate on a limitedsubset of Directory objects. In particular,

I’m going to exclude any objects out-side a single Windows 2000 domain.Domains need to be defined in con-junction with IP domain name ser-vices, so that Active Directory can see the whole network, but this is notreally a security issue. Windows 2000domains can also be installed as parts ofthe larger network structures thatMicrosoft calls trees and forests, but thesefeatures are used only in very complexenvironments and the trust relationshipsbetween domains, trees and forests arefairly clear.

Active Directory holds two main sets ofobjects that matter for security:

• Users — administrators and end-userswho are the characters in the role-playand whose personae are assigned toreal people.

• Computers — servers, client work-stations and the domain controllersthat manage the domain. They arethe equivalent of vehicles and pack animals. They need to be pro-tected as they could be stolen ordamaged, and they need to be con-trolled as they may also be capable ofautonomous action.

You will notice one omission. Securityoften starts with the aim of protectinginformation — applications and data.From Active Directory’s viewpoint, how-ever, these things are passive commodi-ties, the equivalent of the golddoubloons that are perhaps the objectiveof an adventure. Active Directory doesnot record how much money each playerhas: there is a separate way to do this,which is discussed in more detail at theend of this article.

You set the properties for an objectusing a specific utility, Active DirectoryUsers and Computers. Initially, the easi-est way to access this tool is from thedomain controller Start Menu/Admini-strative tools. These days, you probablywon’t have to go to the computer roomto do this: most sites use TerminalServices which allows administrators tosee the console screen as a Window on aclient PC.

Active Directory users andcomputers You might think that the ActiveDirectory screen would show a simplelist of each user and each computer.However, Active Directory is heavilycontainerized. When the operating system is installed, computers areassigned to one of three Containers:‘Domain Controllers’, ‘computers’(servers) or ‘workstations’. Processes andusers created as part of the install process(including the familiar Administratorand Guest) are put in the ‘users’Container. The built-in Container holdsautomatically created user groups,including some of those from WindowsNT, like Account Operators and PowerUsers. The other automatically createdContainers are those used in managingthe operating system itself.

Figure 1 shows a simple domain, with asingle domain controller (Dell), twoworkstations (Compaq and Tecra) andtwo users (test 1 and test 2).

The Containers are rather like resi-dential telephone directories. They arevery useful if you want to process listsin a standard way — like telephonesales staff — but there may be no morein common between objects in aContainer than between people in aphone directory.

The purpose of most Containers is tomake it easier to associate propertieswith objects because assigning themindividually would be both time con-suming and complicated to administer.Containers capable of being associated

14

feature

Figure 1: Active Directory Usersand Computers for a Domain

05 nese may.qxd 5/20/02 4:16 PM Page 14

with lists of properties are known as‘Organizational Units’, or OUs. Thereare just a few automatically createdContainers (including the UserContainer and those used to manage theoperating system) which cannot func-tion as Organizational Units.

How do you adjust the prop-erty settings on a Container?The list of settings associated with anOrganizational Unit (OU) is called a‘Group Policy.’ I find this confusingbecause it has nothing to do with the oldNT Groups, really it is a ‘ContainerPolicy’ or an ‘Organizational Unit Policy’.Each Organizational Unit can have oneor more policies set for it. You accessthem by selecting the OU and looking atits properties, amongst which will be theGroup Policy.

In practice, it is likely that any objectwill be subject to more than one policy,for they can be inherited:

• The domain in which the object existshas by default a policy, and this policywill apply to all the objects in thedomain.

• OUs can hold sub-OUs with theirown policies. Objects in a sub-OUwill not only have the set of sub-OUpolicies but will by default inheritthose of the parent Container.

• Any OU can have more than onedefined policy.

There are rules which define which pol-icy takes precedence in the case of con-flict. Unless special override flags havebeen set, they are applied as follows, withlater settings overriding earlier:

1. Site policy (if there is a site policy: it isnot obligatory).

2. Domain policy (there is always adefault domain policy).

3. OU policy (if there are any — almostcertainly there will be, or there is nopoint in setting up the OU).

4. Sub-OU policy.

If an OU has more than one definedpolicy, they are applied in the order in which you see them listed. You canchange this default order of applicationby setting low-level OUs so they stop higher level policies affecting them but this can be dangerous. It ispossible to ease administration by dele-gating management of objects but youdon’t want to let delegates override site policies that should apply to everyone.For this reason, you can also set high-level OUs which force inheritance, no matter what the policy is lowerdown.

Controlling computersThe next article looks at Group policysettings in more detail, but first its worthconsidering how we should approachcontrolling the individual computers thatform part of the network and which arerecorded in Active Directory. Whatshould concern us is the informationthese computers hold.

In the old days, you logged on to thenetwork using a dumb terminal andwere authenticated by the remote host.If you didn’t, your terminal was useless.With Windows 95 and 98, you loggedon to the network for remote applica-tions and data storage, but if the net-work wasn’t available or you didn’tknow a password to logon, you couldstill access local resources on the PC,usually with no security at all.

With Windows 2000, this last option— of working without any security instandalone mode — is not possible. AllWindows 2000 computers have a subset of the full Windows 2000 con-figuration settings. To adjust the localconfiguration, you need a local userid— one of a set of defined users held onthe local computer. These users arequite separate from the domain usersand the local login is separate from thedomain login you use to access the net-work.

Local computers don’t have an ActiveDirectory, though options are set via theControl Panel. If you promote a serverto be a Domain Controller, its localsecurity settings are adjusted to work in

conjunction with the domain security,but all the other computers runningWindows 2000 have little empires oftheir own, which work independently ofthe domain. This has good points andbad points.

The great advantage, compared withthe old Windows 95 and 98 days, isthat there is now some security onclient PCs or workstations. Local net-work shares, for instance, are restrictedso that ordinary users cannot set shareson local folders and inadvertently makeinformation available to anyone on thenetwork.

One disadvantage is the huge over-head in managing all these littleempires, and in sorting out the problems of users who like to explore.Another is that Windows 2000 considers an administrator, even of ahumble workstation, as a privileged and responsible person, and lets him or her access the administrative shares set by default on all network servers and workstations and even on domaincontrollers.

In practice, it’s usually simpler (andsafer) not to give any user a local login.This sounds odd: how can anyone use aPC when they can’t log in? It’s fine aslong as the user is connected to a net-work with a working domain controller:but suppose the WAN link goes down orthe user is keen to use his or her portableon the train?

If you configure the network withminimal local login, you probably alsoneed to use a feature that some wouldsee as insecure — cached logins.Cached login is enabled by default, andstores the last sets of domain login cre-dentials on the local PC (the number isdefinable). A set is stored for everyonewho uses the PC. If domain authentica-tion is not available, the domain usercan still be checked against locally held credentials and can then work on alocal machine. In a highly secure envi-ronment, this probably wouldn’t beallowed, and there have been somescares about exactly how well protectedthis information is but for practicalpurposes where information is not

feature

15

05 nese may.qxd 5/20/02 4:16 PM Page 15

significantly confidential, this is proba-bly the way to proceed.

So in practice, most people’s approachto local workstation settings is simply tomake sure that users do not logon locally.

ServersServers play a more significant role inthe network, so it’s not so easy to sim-ply disable access. People will need tologon locally to manage the resourcesthat the server distributes, and so theauthentication checking must be set tosecure. You will probably also want tokeep access logs and impose lockoutrestrictions.

If you have many servers, perhapsspread geographically, maintaining thelocal configuration using Control Panelon each server is a significant job. Thisis where the Active Directory tools areso useful. You can use them to definethe settings that a set of servers willhave, by putting them all in the sameContainer and writing a Group Policyfor that Container. The Container poli-cy will be applied to the memberservers without anyone needing to doanything as onerous as drive to theremote site.

The reason this works goes back tothe hierarchy of policies describedabove. Just as OU policies override site

policies, so any settings applied at theActive Directory level will automatical-ly override local settings when the com-puter belongs to a domain — so itdoesn’t matter too much what the localsettings are.

You can see how this works in the fol-lowing example. Figure 2 is a screenprint of Active Directory on the domaincontroller. It shows the Container poli-cy, and a setting for the Password Policyso that the minimum password length is3 characters:

Figure 3 is a screen print fromControl Panel on the local computer.The local policy (in the first column)allows a single character password.However, the domain policy overridesit, so in the second column, the ‘effec-tive’ setting is the three characters set atdomain level.

Access to informationThe properties objects have are obviouslyimportant for security but the otherimportant area is the access those objectshave to resources like data.

This is not the business of an ActiveDirectory Policy. Windows 2000 uses theold Windows NT ‘Groups’ (now some-times called ‘Security Groups’) to defineresource access. An object’s Containerconfers its properties; an object’s mem-bership of one or more Groups deter-mines what files and objects it canmanage. You may feel the distinctionbetween properties and resource access isacademic — and it doesn’t exist in NovellNDS — but this is how it is in Windows2000.

The basic mechanism for applying per-missions to use data is precisely what ithas been since the inception of computersystems. Users and processes that areidentified by a userid are divided intogroups (Security Groups) and access per-missions are normally applied at theGroup level.

As an example, suppose your organi-zation has a standard way of setting upfile access rights so everyone has accessto his or her department’s common

area. To implement this in Windows2000, you define one Group perdepartment: all sales staff, all accountsstaff etc. Then you set permissions on directories by Group, just as you did in Windows NT. This doesn’t meanthat everyone in a Group needs to share the same policy settings. Supposethree sales staff and two accounts staffare mobile, and need to dial-in to usethe network. You want to set passwordpolicies for them that are much stricter than the norm, because of thedial-in risk. To do this, you put theindividual users into one of twoContainers, dial-in users and non-dial-in users, with different passwordpolicies. You don’t put the Groupsthemselves (sales and accounts) ineither Container. In fact you’ll proba-bly choose to have a third Container tohold all the Groups, making them easi-er to review and manage.

This standard file and folder access isextended in Windows 2000 becausepermissions can be set not just to accessfiles, but also to control ActiveDirectory objects. Users can be givenrights to change the rule set for one ormore computers or users. In practice,this has proved to be very useful,because it allows delegation of adminis-tration, and segregation of duties, in away which was not possible inWindows NT.

So, to summarize, the Windows 2000universe is populated by ‘objects’ —primarily users and computers. Objectshave properties, normally by virtue of the Container they are in, and access to resources, by virtue of theSecurity Groups of which they aremembers.

The sorts of properties objects canhave, which matter most for security,and how you might delegate objectmanagement are the subjects of thenext article in Computer Fraud &Security.

Alison Webb BA FCA CISA has been anindependent computer audit consultantsince 1990. Her email address is amwebb-cam@aol.com.

16

feature

Figure 3: WORKSTATION /SERVER: Local setting

over-ridden

Figure 2: DOMAIN CONTROLLER:Container policy sets password

length at 3 characters

05 nese may.qxd 5/20/02 4:16 PM Page 16