- Email: [email protected]
Developing a Windows NT security policy
Information Security Technical Report, Vol. 3, No. 3 (1998) 31-43
Develobina a Windows NT Security Policy -
I-
~~
_~
__
_ __
_
~~
_
need revision to keep pace with the dynamic nature of the ‘cat and mouse’ game played between the attackers and the system administrators. A recommended strategy is therefore to include more general security control objectives within each section of the policy, with specific details being provided as and when appropriate, possibly through one or more appendices or supplements.
By Ian Whife, Zergo Lfd The choice of Windows NT as the sfrafegic platform for the deskfop and shared application server is becoming more widespread. A challenge for fhe security team is to provide guidelines on the minimum level of security controls fhaf should be implemented on these systems. This article discusses some of the controls that might be expected to be included within such a Windows NT Security Policy (the policy).
Introduction Probably the most important consideration when developing a Windows NT Security Policy is to decide who the intended audience is and what they are expected to do with the policy. The level of detail that should be provided will change significantly between a policy supplied to all users and one that is targeted primarily at system administrators and other technical personnel. In many organizations the Windows NT Security Policy is itself treated as a restricted document, the concern being that the level of detail provided may highlight which security controls are implemented and which are not. As such the policy may prove a valuable source of information to any potential attacker. A related issue is whether the policy should provide all the information with respect to required changes in a ‘vanilla’ NT system or instead act as a guide on general principles, referring to other sources for more details. Whilst it seems reasonable to expect the policy to provide information about required changes, some of these changes may only relate to a specific software release, service pack level or hotfix. Any detailed security policy written even one year ago is likely to
0167-4048/98/$19.00 0 1998, Elsevier Science Ltd
Finally, the structure of the Security Policy needs some thought. Whilst it may seem sensible to attempt a layout that is based upon the Windows NT Security Model, most organizations will prefer to define a common format that applies across all platform-specific security policies. In either case the main consideration should be how to make it easy for a reader to find the information that they need. For the purpose of this article the format provided within the BS7799 Code of Practice has been loosely adopted, using the main headings and initial control objectives from Section 5 onwards as convenient subject headings. For reference, BS7799 section numbers are also included.
Windows NT Security Policy Physical and Environmental Security BS7799 5.1 Secure Areas Objective: “To prevent unauthorized access, damage and interference to IT services. .. . ” 5.2 Equipment security
I
“To prevent loss, damage or Objective: compromise of assets and interruption to business activities. ... ”
31
Developing a Windows NT Security Policy
General The Windows NT security model provides for both the authentication of users and the logical protection of system resources through the use of Access Control Lists (ACLs). An underlying assumption is that all disks are formatted as NTFS and that the access will only be through the Windows NT operating system. The policy should require the use of NTFS for all disks. The use of a dual boot system (e.g. Windows NT and DOS) should also only be permitted where no other technical solution is possible. In such cases a full security risk assessment should also be conducted to identify any compensating controls that might be required. Physical The physical protection of the Windows NT environment is an essential requirement to ensure that the security model may not be subverted or bypassed. Until the release of Windows NT 5.0 and the planned encrypted version of NTFS, all application and system data held on disk is unencrypted. Use of another operating system with a driver capable of understanding NTFS, for instance NTFSDOS, enables the user to bypass all NTFS permissions and read/copy any or all files and thereby gain access to the information. Alternatively, a user may just remove the system or hard disk containing the information and access it from their own system, where they have full administrative rights. The policy should provide for physical protection of all Windows NT systems, especially where the data held upon them is confidential or critical. Domain controllers (primary and backup) should be included within this group of systems. Protective measure may include placing systems in locked environments and blocking use of the diskette drive, if installed. Where occasional
32
use of diskettes is supported then either a physical drive lock or use of a software block should be considered. An example of such a software-based control is the NT Resource kit floplock utility. This runs as a service within the NT system and blocks access to the diskette drive for all users that are not a member of an administrative group (administrators and power users). Physical protection should also include associated network equipment and cabling, to minimize the chance of an attacker using a network ‘sniffer’ to record user password hash values for subsequent ‘cracking’. Syskey Any attacker who gains access to the SAM database component of the registry, or any backup media containing a copy of this critical system file, will be able to ‘break’ the passwords of all users through the use of a suitable cracking tool (e.g. lophtcrack). The user account password hash information stored within the Windows NT Registry may be encrypted through the Syskey feature provided within NT 4.0 sp3. For most production environments, Syskey should be implemented. The policy must, however, ensure that the implementation of Syskey takes into account the need to provide key recovery as the loss of the Syskey cryptographic key value will result in the system becoming unusable. UPS Minimum environmental requirements such as air conditioning and stable power supplies should also be specified within the policy. Windows NT supports the provision of smartUPS. The UPS service is able to execute a small number of commands prior to complete power failure, perhaps closing a critical application database. Many Windows NT services, including UPS, run under a system
Information
Security Technical
Report, Vol. 3, No. 3
Developing a Windows NT Security Policy
account by default. The UPS service may be used to attempt to introduce commands to perform unauthorized actions under the system account upon a power failure. For example, installing a Trojan horse to monitor and record password entry. The policy should ensure that this and other similar services running under a system account may only execute known and authorized command scripts. This may require changes to the associated registry key and command file permissions. Computer and Network Management BS7799 6.1 Operational responsibilities
procedures
and
Objective: “To ensure that the correct and secure operation of computer and network facilities. ... ” 6.2 System planning and acceptance Objective: “To minimize failures. ... ”
the risk of systems
6.4 Housekeeping Objective: “To maintain the integrity availability of IT services. ... ”
and
6.6 Media handling and security Objective: “To prevent damage to assets and interruptions to business activities. .. . ” Sys tern Administration A number of built-in administrative groups are provided within Windows NT. Membership of these groups confers specific administrative rights or capabilities upon the user. The policy must not only define which administrative groups should be used but also indicate who should have membership of these groups by default. This is particularly important within a domain, where global groups may confer administrative rights to
Information
Security Technical
Report, Vol. 3, No. 3
member accounts across all systems within the domain. The local administrators group provides members with the right to perform both user and system administration. Within a domain the global group of domain_admins will be defined by default as a member of each local administrators group. Use of this global group supports central administration of users and resources within a domain. Many of the required system configuration changes that need to be applied to Windows NT can only be applied by a member of the local administrators group. Where such changes are performed through a remote server (for example through SMS) then the policy should indicate what procedures must be followed to implemented the latest hotfixlservice pack in a controlled manner. All Windows NT systems have a local account called administrator. This account has a number of special properties that make it the first target for any attacker. Use of this special account should be restricted as much as possible. In fact many organizations rename the account, give it a complex password (14 random letters, special characters and numbers) and keep the details locked away for use only in an emergency. The policy should provide guidelines on usage of the administrator account both to protect the account from external attack as well as providing accountability for its use. Housekeeping The policy should highlight any specific housekeeping requirements that apply to all Windows NT systems, possibly with more detailed requirements for application servers and domain controllers. Likely areas to be covered in any discussion on housekeeping include Event Log processing, use of the
33
Developing a Windows NT Security Policy
Schedule service and backup policy. Special consideration needs to be given to how often backups of the NT registry will be performed and what protection will be provided to the resulting backup media to minimize dictionary attacks against a copy of the SAM database and the stored password hash values (refer Syskey). Computer and Network Management
6.3 Protection from malicious software 1Objecfive: “To safeguard the integrity of soffware ~and data. ...‘I ~6.5 Network management
Objective: “To ensure fhe safeguarding of information in networks and the protection of the supporting infrastructure. ...‘I I 6.7 Data and software exchange Objective: “To prevent misuse of data. ... ” -~__ ____.
loss, modification
or
Virus Protection Although the design of Windows NT provides some protection against boot sector viruses there is no built-in protection against other types of unauthorized code, for example a macro virus for Word. The policy should indicate which anti-virus software must be implemented and how frequently this will be updated. Where diskettes or other portable media are used to exchange data, the use of a standalone system to perform virus checking may also be appropriate. Data Exchange Most Windows NT systems share information with other systems through one or more of the following technologies: E-mail, Web
34
technology, file transfers and network shares. The policy needs to address each of the supported mechanisms and highlight any particular security requirements. For example, Windows NT uses the standard Server Message Block (SMB) protocol when exchanging information through a network share. This protocol provides little protection against unauthorized modification or disclosure of the transmitted information. Where Windows NT is sharing information with another Windows NT system, providing they are both at a minimum service level of NT 4.0 sp3, the packets of information may be digitally signed to ensure they have not been altered and that they are genuine. The use of this technique may be appropriate on more sensitive systems where the integrity of the information is paramount. The introduction of this feature may, however, increase the processor resources required for both sending and receiving NT systems in order to avoid impacting system performance. Remote Access A minimum set of security requirements on any remote access should be specified in the policy where facilities such as RAS and RRAS are permitted. These requirements might include whether dial-back security is required, the selection of the MS-CHAP protocol options for user authentication and data encryption (Figure 1) and the enforcement of the NTLM hash rather than the weaker LAN Manager alternative. The policy should also state whether or not a user can access resources across the whole network remotely or just those located at the RAS server. The circumstances under which usage of the Point-to-Point Tunnelling Protocol (PPTP) is permitted should also be specified. Designed as an Internet tunnelling protocol that allows a user to remotely connect to their Windows NT domain, PPTP has been subject to numerous
information
Security Technical
Report, Vol. 3, No. 3
Developing a Windows NT Security Policy
assessment consideration should also be given as to what minimum level of protection must be provided for locally held data. System Access Control User Account Policy BS7799 7.1 Business requirement for system access Objet tive: “To control information. ... ”
access
to business
7.2 User access management Objective: “To prevent unauthorized access. ...‘I
computer
7.3 User responsibilities Objective: “To prevent unauthorized user access. ... 1, 7.4 Network access control Objective: “Protection of netzuorked devices. ...‘I Figure 2: RAS Options selecting MS-CHAP
studies that have in the past highlighted a number of potential security vulnerabilities. Where the use of this protocol is supported within an organization then the policy should highlight required patches and perhaps limit the information that can be transmitted across such a link by classification category. For production Windows NT environments the use of third-party user authentication and encryption products may also be required by the policy, especially if the connection is across a potentially hostile network such as the Internet. A security risk assessment should always be conducted when considering remote access to the production environment in order to identify whether such additional controls are required. As part of this
Information
Security Technical
Report, Vol. 3, No. 3
7.5 Computer access control Objective: “To prevent unauthorized access. ... ”
computer
As a general guideline, all users within a production environment should be responsible for their own user account and should be accountable for any actions performed using that account. Whilst a builtin anonymous guest account is provided within Windows NT, this would normally be expected to be disabled unless there is a specific business requirement for its usage. The policy should not only define the format to be used for the account name but also specify the rules governing usage of the account. For example, password length and frequency of change, working hours restrictions and the rules governing
35
Developing a Windows NT Security Policy
what happens password attempt.
after
an
invalid
Figure 2 illustrates an example Windows NT Account Policy implementing a set of complementary account-related controls. Other account-related controls may be implemented through the screen for adding a new user within User Manager. Note that the choice of options, for example what action to take upon repeated password failure, can have a significant impact upon the amount of user administration intervention that will be required within an organization. The policy should also provide advice on password selection, perhaps requiring the use of the resource kit passprop utility or implementation of the password filter (passfiltdll) to enforce such guidelines. Note that the password filter is an NT 4.0 facility and as such will not be invoked where a user changes their password through other clients, such as Windows 95.
Sys tern Account Usage By default a number of standard Windows NT Services and functions run under the Any process using system account. this account has full rights over system resources. Whilst it is possible for some of the built-in services such as Schedule to run under the context of a less powerful local account, in practice this may be hard to implement. An alternative approach is for the policy to require that access to registry settings, parameter files and commands relating to services are restricted. In particular the everyone group should be specified with the least level of permissions required for the proper functioning of the service. In many cases the everyone group may be safely removed from the appropriate ACL. Group Membership Within Windows NT, each user account has a unique Security Identifier (SID) that may be used within a resource ACL to control the level of access granted. An account may also be added to one or more groups, each of which also has a unique SID that can be used within an ACL. The policy should provide guidance on group structure and group membership.
Figure 2: Example
36
Account
Policy.
The specification of default User Rights or Privileges to be associated with each group is also important. The privileges a user has determines how they interface with Windows NT itself. For instance, are they permitted to logon through the network or must they use the keyboard to logon interactively. Some privileges such as the ability to change the system time may be acceptable on a workstation but not on a shared server whilst others such as debug or act as part of the operating system enable a user to bypass
Information
Security Technical
Report, Vol. 3, No. 3
Developing a Windows NT Security Policy
normal Windows NT security mechanisms and should not be assigned to any user by default. The policy should provide guidance on the default user rights setting at the workstation, at a server and at a domain controller.
knows the correct name to specify. The policy should state who may generate network shares, which information (files/folders) may be shared across the network and finally what default permissions should be defined within the network share ACLs.
Access to data
By default a number of so called administrative shares are also generated, enabling remote access by the administrators group to the root directory of each disk (e.g. CS) and the system directory (e.g. ADMIN$). The policy should state whether or not remote administrator access is permitted. Where such access is not required then the administrative shares should be suppressed to prevent possible dictionary attacks against the built-in administrator account. In situations where this account is required to be used across a network share the resource kit pmsprop utility should be invoked to enable suspension of this account from network access upon repeated password failures.
Resources such as application and system files, as well as registry keys, are protected through NTFS file permissions. By default the everyone group will be granted FulZ Control over many of these system and file resources. Over the past year, a number of attacks against Windows NT systems have been possible due to the everyone group being given higher levels of access to system files and registry keys than strictly required. For example all users will by default have Full Control at a root level on all disks, giving any user the permission to delete sub-directories, subject to NT enqueing mechanisms! The policy should specify the default levels of access for production application files and critical system resources (files and registry entries). As part of this process standards on the location of files may also be defined, for example whether application files should reside on the workstation or the server. Network Shares Windows NT supports the sharing of information within a domain or Workgroup through network shares. A user may access information located upon another Windows NT system providing they are defined within the appropriate ACL associated with that share and have the correct level of access through the resource ACL itself. To prevent the presence of the share being displayed throughout the network a “$” may be added to the end of the share name. These hidden shares are still available, providing the user
Information
Security Technical
Report, Vol. 3, No. 3
When a user displays a list of users from a trusted domain, or checks the shares available through Network Neighbourhood, their Windows NT system must obtain information from other Windows NT systems. This is performed through an anonymous account. The anonymous account has been exploited in a number of ways, including the so called Redbutton attack. The vulnerability lies through the automatic membership of the nnonymous account in the everyone group. The policy should require the implementation of available patches against such attacks as well as defining changes to the permissions granted to everyone on critical system resources to reduce this exposure. Domain Structure
The Windows NT domain can be considered as a single administrative unit, with membership of a domain or global group providing privileges and/or access rights to
37
Developing a Windows NT Security Policy
resources on systems within the domain. Under Windows NT 4.0 (and prior releases) the domain structure will be determined through considerations about performance, where responsibility for capacity and administration of user and resources should be performed. The policy should identify the domain model appropriate for the organization, for example Master Model, taking into account such considerations as the requirement for centralized user account management. The policy must also provide guidelines on the definition and maintenance of trust relationships. These trust relationships provide the mechanism through which a user in one domain may access resources in another domain without relying upon ‘guest access’. The trusting domain trusts that the trusted domain performs user account management and authentication in an acceptable manner. Any decision concerning setting up a trust relationship with an external organization should take into account both their account policy settings and any relevant procedures associated with user account management (adding, changing, removing). User Rights
The User Rights policy identifies how each defined group of users interact with the Windows NT operating system. Figure 3 provides an example of the screen used to specify the various user rights or privileges. All such settings should be defined within the policy to ensure that the security of the environment is not compromised through a user being granted a higher level of user rights than required. Desktop Security
An important aspect of information security in any organization is ensuring that users understand the importance of protecting their
38
Back UD files and dwectorles Bypass’traverse checking Change the system time
Figure 3: User Rights Policy screen.
desktop when they are not at the desk. Not only might confidential information be being displayed but also someone might use the to perform an logged on account unauthorized action that the account holder will be held accountable for. Windows NT provides both a terminal lockout facility, invoked through the secure attention sequence (crtl-alt-del) and support for 32-bit screen savers that require the user to enter their NT account password. The policy should specify minimum time-out values and also which screen savers can be used at the desktop. Note that the choice of options may be different for a physically secure server, where the presence of a screen saver may be an unnecessary drain on processor resources. Implementation of a standard desktop is also possible through the use of both user profiles and the more recently introduced System Policy. The Windows NT policy should detail the default settings to be used for different types of users. Through the use of multiple policies a number of standard desktop environments can be constructed, with various levels of controls being implemented depending upon which user logs onto the specific Windows NT system.
Information
Security Technical
Report, Vol. 3, No. 3
Developing
a Windows NT Security Policy
implemented and only their network ports enabled.
I3
l&J System pplications
I3 e ? ?e
Windows NT Shell Windows NT System
associated
The policy should also provide guidelines as to which protocols are to be supported, which network adapters they are to be bound to and whether or not II’ forwarding will be supported. The choice of protocol, their bindings and whether or not forwarding is supported can have a significant impact upon whether or not an attacker may use the NT system as a staging post for an attack against other systems on the same internal network. System Logging
Figure 4: Local User Sys tern Policy. Figure 4 illustrates some of the settings available through the System Policy. Although the figure shows the Local User Properties, this information may also be stored as a separate System Policy file that can be invoked upon user account logon. Network Security As a general rule, it is important that a Windows NT system only supports the protocols and network services that are actually required. The policy should identify which network services are required and which are not to be used. For example, whether or not users can use services such as telnet or ftp. Where a service is not to be used then the associated network port should be disabled for both II’and UDI? Failure to do so may result in the system being vulnerable to a denial-of-service attack utilizing one of these port addresses. As a general guide, only required network services should be
Information Security Technical Report, Vol. 3, No. 3
By default Windows NT will not perform security-related logging to the built-in audit trail, the security event log. The policy should indicate which security-related events should be logged and possibly also identify specific files and other resources that require access logging to be performed. Whilst each organization will have its own rules on the logging of security events, most will require security-related failed attempts to be logged (e.g. failed logon attempt) as well as a record of any security related changes. Figure 5 shows a possible set of default Audit Policy settings that would provide logging of most security related events. Note that some options also require changes to be performed within the resource ACL itself or in some cases the definition of specific registry settings in order to actually generate any records. Management of the event logs should also be considered within the NT policy. For each of the three event logs (system, application and security) the system administrator can specify both the size of the log and what action to take when the log becomes full (Figure 6). Three possible actions are available; wrapping around automatically, overwriting entries
39
Developing a Windows NT Security Policy
System development and Maintenance System Maintenance _ BS7799 8.1 Security requirements of systems Objective: “To ensure that security is built into IT systems. ...‘I 8.2 Security in application systems Objective: “To prevent loss, modification or misuse of user data in application systems. ...‘I 8.3 Security of application system files greater than a pre-determined number of days and stopping the system until the built-in administrator account is used to reset a registry entry and manually clear the log. Whilst the latter may seem appropriate for the security log the operational implications of the system ‘crashing’ when the event log is full need to be considered carefully. One possible solution is to copy and clear the log through a procedure invoked by an alert issued when the log is 70% full (or some other suitable value). Finally the policy should indicate how frequently log entries should be checked and what incident reporting procedures should be followed.
1?gure 6: Event Log Options.
40
Objective: “To ensure that IT projects and support activities are conducted in a secure manner. ...” 8.4 Security in development environments
and support
Objective: “To maintain the security application system software and data. ...‘I
of
A number of utility programs are available for maintaining the system, for example the Registry Editor regedt32. Where such utility programs are authorized for use, the policy should indicate who should have access to them and whether they may be used remotely, either through the network or through a remote connection using RAS. Any requirements with respect to change control or other company specific procedures should also be defined. The use of the System Policy Editor may also be specified in the policy as a preferred mechanism for performing standard registry updates across multiple systems. Figure 7 illustrates the default screen for updating registry settings such as the legal notice displayed upon system start-up and suppression of the name of the last user to logon. The use of system policies may be extended through defining company specific entries within the policy files.
Information
Security Technical
Report, Vol. 3, No. 3
Developing a Windows NT Security Policy
Care must also be taken to ensure that any software patches or updates to be applied to a production NT environment are both genuine and tested. In particular, any changes to the operating system components and the registry should only be performed after an appropriate backup has been performed.
Primary Domain Controller (PDC) to one or more Backup Domain Controllers (BDCs). A related consideration is the fact that each Windows NT system has a unique SID (local master SID) and that within a domain each Windows NT system has a domain account, the account name being the computer (NetBIOS) name.
Application Level Security Compliance The policy should specify any particular requirements with respect to the location of application files, NTFS permissions to be applied by default and who should be the NTFS file ‘owner’. Where appropriate, guidelines might also be provided on the use of cryptographic routines (e.g. CAPI) and the implementation of application level user authentication calls (e.g. the new SSPI planned to be introduced within Windows NT 5.0). For applications written to use the Microsoft DCOM, a set of additional security controls are available within Windows NT. The policy should highlight any minimum security controls that need to be implemented for such distributed applications.
BS7799 10.1 Compliance with legal requirements Objective: “To avoid breaches of any statutory, criminal or civil obligations and of any security requirements. ... ”
i
All products implemented within a Windows NT environment must be used in accordance with the terms of the appropriate software The policy should indicate licence. what procedural and possibly automatic
Business continuity planning
9.1 Aspects of business continuity planning Objective: “To have plans available to counteract interruption to business activities. ... ” The policy should identify requirements for system recovery, including the use of RAID facilities to protect against individual disk failure and the implementation of clustering for critical business servers. Any business continuity planning (BCP) for Windows NT must take into account the structure of the domain, with a single user account database being replicated from the
information
Security Technical
Report, Vol. 3, No. 3
Figure 7: Local Computer Sys tern Policy.
41
Developing a Windows NT Security Policy
software licensing implemented.
controls
will
be
A message may also be automatically displayed on system start-up to discourage unauthorized users from proceeding with entering the system. The policy should specify the wording of such a message in order to notify potential users of their liabilities under the UK Computer Misuse Act or similar legislation. A standard message may be implemented across a domain through the use of a system policy file (refer Figure 7).
only. A security risk assessment should be performed to ascertain which controls are appropriate in any particular environment, taking into account specific business, technical and operational considerations. All proposed changes to policies, NTFS permissions, registry entries or other system configuration changes should always be fully tested prior to roll-out within a production environment. The taking of a full system backup prior to implementing such changes is strongly recommended.
Further Sources of Information Conclusions A number of possible controls that might be specified within a Windows NT security policy have been discussed using the framework provided by the British Standard BS7799: Code of Practice for Information Security Management. To be successful, such a policy must ensure that the required baseline set of controls may be implemented without incurring excessive administrative or system overheads. Checking compliance with the policy must also be practical, with a consistent approach being required across many NT systems. For many organizations the solution to these implementation issues will be the choice of a suitable Windows NT ‘add-on’ security product. Where the decision is made to rely upon standard Windows NT facilities only, the use of System Policies in conjunction with scripts built around resource kit and option pack utilities may be appropriate.
Disclaimer The controls discussed in this article and the examples used are for illustrative purposes
42
The primary source for information concerning recommended NTFS permissions, operating system hot fixes and service packs should be Microsoft Corporation, either through technical resources such as Technet or through their Internet site. For information about security-related matters, the Microsoft Security Advisory site (http://microsoft.com/security/) provides guidance and information on how to ‘harden’ the Windows NT operating system. Links from this site are also provided to organizations that have compiled Windows NT guidelines or example policy documents. Examples of such links include the SANS Institute (http://www.sans.org) who market a step by step guide to the set-up of Windows NT security and Trusted Systems (http://www.trustedsystems.com) who offer best practice advice on the creation of a secure environment. Other companies and organizations may also be able to provide additional information on how to secure the Windows NT environment. For example the European Security Forum has compiled a set of Windows NT Security Guidelines that is available to members.
Information
Security Technical
Report, Vol. 3, No. 3
Developing a Windows NT Security Policy
Finally, additional up-to-date security-related information for NT may be obtained from mailing lists such as NTBugtraq and its archives:
Information
Security Technical
Report, Vol. 3, No. 3
NTBugtraq Home Page http://ntbugtraq.ntadvice.com NTBugtraq List Charter http://ntbugtraq.ntadvice.com/ntbugfaq.asp
43
Develobina a Windows NT Security Policy -
I-
~~
_~
__
_ __
_
~~
_
need revision to keep pace with the dynamic nature of the ‘cat and mouse’ game played between the attackers and the system administrators. A recommended strategy is therefore to include more general security control objectives within each section of the policy, with specific details being provided as and when appropriate, possibly through one or more appendices or supplements.
By Ian Whife, Zergo Lfd The choice of Windows NT as the sfrafegic platform for the deskfop and shared application server is becoming more widespread. A challenge for fhe security team is to provide guidelines on the minimum level of security controls fhaf should be implemented on these systems. This article discusses some of the controls that might be expected to be included within such a Windows NT Security Policy (the policy).
Introduction Probably the most important consideration when developing a Windows NT Security Policy is to decide who the intended audience is and what they are expected to do with the policy. The level of detail that should be provided will change significantly between a policy supplied to all users and one that is targeted primarily at system administrators and other technical personnel. In many organizations the Windows NT Security Policy is itself treated as a restricted document, the concern being that the level of detail provided may highlight which security controls are implemented and which are not. As such the policy may prove a valuable source of information to any potential attacker. A related issue is whether the policy should provide all the information with respect to required changes in a ‘vanilla’ NT system or instead act as a guide on general principles, referring to other sources for more details. Whilst it seems reasonable to expect the policy to provide information about required changes, some of these changes may only relate to a specific software release, service pack level or hotfix. Any detailed security policy written even one year ago is likely to
0167-4048/98/$19.00 0 1998, Elsevier Science Ltd
Finally, the structure of the Security Policy needs some thought. Whilst it may seem sensible to attempt a layout that is based upon the Windows NT Security Model, most organizations will prefer to define a common format that applies across all platform-specific security policies. In either case the main consideration should be how to make it easy for a reader to find the information that they need. For the purpose of this article the format provided within the BS7799 Code of Practice has been loosely adopted, using the main headings and initial control objectives from Section 5 onwards as convenient subject headings. For reference, BS7799 section numbers are also included.
Windows NT Security Policy Physical and Environmental Security BS7799 5.1 Secure Areas Objective: “To prevent unauthorized access, damage and interference to IT services. .. . ” 5.2 Equipment security
I
“To prevent loss, damage or Objective: compromise of assets and interruption to business activities. ... ”
31
Developing a Windows NT Security Policy
General The Windows NT security model provides for both the authentication of users and the logical protection of system resources through the use of Access Control Lists (ACLs). An underlying assumption is that all disks are formatted as NTFS and that the access will only be through the Windows NT operating system. The policy should require the use of NTFS for all disks. The use of a dual boot system (e.g. Windows NT and DOS) should also only be permitted where no other technical solution is possible. In such cases a full security risk assessment should also be conducted to identify any compensating controls that might be required. Physical The physical protection of the Windows NT environment is an essential requirement to ensure that the security model may not be subverted or bypassed. Until the release of Windows NT 5.0 and the planned encrypted version of NTFS, all application and system data held on disk is unencrypted. Use of another operating system with a driver capable of understanding NTFS, for instance NTFSDOS, enables the user to bypass all NTFS permissions and read/copy any or all files and thereby gain access to the information. Alternatively, a user may just remove the system or hard disk containing the information and access it from their own system, where they have full administrative rights. The policy should provide for physical protection of all Windows NT systems, especially where the data held upon them is confidential or critical. Domain controllers (primary and backup) should be included within this group of systems. Protective measure may include placing systems in locked environments and blocking use of the diskette drive, if installed. Where occasional
32
use of diskettes is supported then either a physical drive lock or use of a software block should be considered. An example of such a software-based control is the NT Resource kit floplock utility. This runs as a service within the NT system and blocks access to the diskette drive for all users that are not a member of an administrative group (administrators and power users). Physical protection should also include associated network equipment and cabling, to minimize the chance of an attacker using a network ‘sniffer’ to record user password hash values for subsequent ‘cracking’. Syskey Any attacker who gains access to the SAM database component of the registry, or any backup media containing a copy of this critical system file, will be able to ‘break’ the passwords of all users through the use of a suitable cracking tool (e.g. lophtcrack). The user account password hash information stored within the Windows NT Registry may be encrypted through the Syskey feature provided within NT 4.0 sp3. For most production environments, Syskey should be implemented. The policy must, however, ensure that the implementation of Syskey takes into account the need to provide key recovery as the loss of the Syskey cryptographic key value will result in the system becoming unusable. UPS Minimum environmental requirements such as air conditioning and stable power supplies should also be specified within the policy. Windows NT supports the provision of smartUPS. The UPS service is able to execute a small number of commands prior to complete power failure, perhaps closing a critical application database. Many Windows NT services, including UPS, run under a system
Information
Security Technical
Report, Vol. 3, No. 3
Developing a Windows NT Security Policy
account by default. The UPS service may be used to attempt to introduce commands to perform unauthorized actions under the system account upon a power failure. For example, installing a Trojan horse to monitor and record password entry. The policy should ensure that this and other similar services running under a system account may only execute known and authorized command scripts. This may require changes to the associated registry key and command file permissions. Computer and Network Management BS7799 6.1 Operational responsibilities
procedures
and
Objective: “To ensure that the correct and secure operation of computer and network facilities. ... ” 6.2 System planning and acceptance Objective: “To minimize failures. ... ”
the risk of systems
6.4 Housekeeping Objective: “To maintain the integrity availability of IT services. ... ”
and
6.6 Media handling and security Objective: “To prevent damage to assets and interruptions to business activities. .. . ” Sys tern Administration A number of built-in administrative groups are provided within Windows NT. Membership of these groups confers specific administrative rights or capabilities upon the user. The policy must not only define which administrative groups should be used but also indicate who should have membership of these groups by default. This is particularly important within a domain, where global groups may confer administrative rights to
Information
Security Technical
Report, Vol. 3, No. 3
member accounts across all systems within the domain. The local administrators group provides members with the right to perform both user and system administration. Within a domain the global group of domain_admins will be defined by default as a member of each local administrators group. Use of this global group supports central administration of users and resources within a domain. Many of the required system configuration changes that need to be applied to Windows NT can only be applied by a member of the local administrators group. Where such changes are performed through a remote server (for example through SMS) then the policy should indicate what procedures must be followed to implemented the latest hotfixlservice pack in a controlled manner. All Windows NT systems have a local account called administrator. This account has a number of special properties that make it the first target for any attacker. Use of this special account should be restricted as much as possible. In fact many organizations rename the account, give it a complex password (14 random letters, special characters and numbers) and keep the details locked away for use only in an emergency. The policy should provide guidelines on usage of the administrator account both to protect the account from external attack as well as providing accountability for its use. Housekeeping The policy should highlight any specific housekeeping requirements that apply to all Windows NT systems, possibly with more detailed requirements for application servers and domain controllers. Likely areas to be covered in any discussion on housekeeping include Event Log processing, use of the
33
Developing a Windows NT Security Policy
Schedule service and backup policy. Special consideration needs to be given to how often backups of the NT registry will be performed and what protection will be provided to the resulting backup media to minimize dictionary attacks against a copy of the SAM database and the stored password hash values (refer Syskey). Computer and Network Management
6.3 Protection from malicious software 1Objecfive: “To safeguard the integrity of soffware ~and data. ...‘I ~6.5 Network management
Objective: “To ensure fhe safeguarding of information in networks and the protection of the supporting infrastructure. ...‘I I 6.7 Data and software exchange Objective: “To prevent misuse of data. ... ” -~__ ____.
loss, modification
or
Virus Protection Although the design of Windows NT provides some protection against boot sector viruses there is no built-in protection against other types of unauthorized code, for example a macro virus for Word. The policy should indicate which anti-virus software must be implemented and how frequently this will be updated. Where diskettes or other portable media are used to exchange data, the use of a standalone system to perform virus checking may also be appropriate. Data Exchange Most Windows NT systems share information with other systems through one or more of the following technologies: E-mail, Web
34
technology, file transfers and network shares. The policy needs to address each of the supported mechanisms and highlight any particular security requirements. For example, Windows NT uses the standard Server Message Block (SMB) protocol when exchanging information through a network share. This protocol provides little protection against unauthorized modification or disclosure of the transmitted information. Where Windows NT is sharing information with another Windows NT system, providing they are both at a minimum service level of NT 4.0 sp3, the packets of information may be digitally signed to ensure they have not been altered and that they are genuine. The use of this technique may be appropriate on more sensitive systems where the integrity of the information is paramount. The introduction of this feature may, however, increase the processor resources required for both sending and receiving NT systems in order to avoid impacting system performance. Remote Access A minimum set of security requirements on any remote access should be specified in the policy where facilities such as RAS and RRAS are permitted. These requirements might include whether dial-back security is required, the selection of the MS-CHAP protocol options for user authentication and data encryption (Figure 1) and the enforcement of the NTLM hash rather than the weaker LAN Manager alternative. The policy should also state whether or not a user can access resources across the whole network remotely or just those located at the RAS server. The circumstances under which usage of the Point-to-Point Tunnelling Protocol (PPTP) is permitted should also be specified. Designed as an Internet tunnelling protocol that allows a user to remotely connect to their Windows NT domain, PPTP has been subject to numerous
information
Security Technical
Report, Vol. 3, No. 3
Developing a Windows NT Security Policy
assessment consideration should also be given as to what minimum level of protection must be provided for locally held data. System Access Control User Account Policy BS7799 7.1 Business requirement for system access Objet tive: “To control information. ... ”
access
to business
7.2 User access management Objective: “To prevent unauthorized access. ...‘I
computer
7.3 User responsibilities Objective: “To prevent unauthorized user access. ... 1, 7.4 Network access control Objective: “Protection of netzuorked devices. ...‘I Figure 2: RAS Options selecting MS-CHAP
studies that have in the past highlighted a number of potential security vulnerabilities. Where the use of this protocol is supported within an organization then the policy should highlight required patches and perhaps limit the information that can be transmitted across such a link by classification category. For production Windows NT environments the use of third-party user authentication and encryption products may also be required by the policy, especially if the connection is across a potentially hostile network such as the Internet. A security risk assessment should always be conducted when considering remote access to the production environment in order to identify whether such additional controls are required. As part of this
Information
Security Technical
Report, Vol. 3, No. 3
7.5 Computer access control Objective: “To prevent unauthorized access. ... ”
computer
As a general guideline, all users within a production environment should be responsible for their own user account and should be accountable for any actions performed using that account. Whilst a builtin anonymous guest account is provided within Windows NT, this would normally be expected to be disabled unless there is a specific business requirement for its usage. The policy should not only define the format to be used for the account name but also specify the rules governing usage of the account. For example, password length and frequency of change, working hours restrictions and the rules governing
35
Developing a Windows NT Security Policy
what happens password attempt.
after
an
invalid
Figure 2 illustrates an example Windows NT Account Policy implementing a set of complementary account-related controls. Other account-related controls may be implemented through the screen for adding a new user within User Manager. Note that the choice of options, for example what action to take upon repeated password failure, can have a significant impact upon the amount of user administration intervention that will be required within an organization. The policy should also provide advice on password selection, perhaps requiring the use of the resource kit passprop utility or implementation of the password filter (passfiltdll) to enforce such guidelines. Note that the password filter is an NT 4.0 facility and as such will not be invoked where a user changes their password through other clients, such as Windows 95.
Sys tern Account Usage By default a number of standard Windows NT Services and functions run under the Any process using system account. this account has full rights over system resources. Whilst it is possible for some of the built-in services such as Schedule to run under the context of a less powerful local account, in practice this may be hard to implement. An alternative approach is for the policy to require that access to registry settings, parameter files and commands relating to services are restricted. In particular the everyone group should be specified with the least level of permissions required for the proper functioning of the service. In many cases the everyone group may be safely removed from the appropriate ACL. Group Membership Within Windows NT, each user account has a unique Security Identifier (SID) that may be used within a resource ACL to control the level of access granted. An account may also be added to one or more groups, each of which also has a unique SID that can be used within an ACL. The policy should provide guidance on group structure and group membership.
Figure 2: Example
36
Account
Policy.
The specification of default User Rights or Privileges to be associated with each group is also important. The privileges a user has determines how they interface with Windows NT itself. For instance, are they permitted to logon through the network or must they use the keyboard to logon interactively. Some privileges such as the ability to change the system time may be acceptable on a workstation but not on a shared server whilst others such as debug or act as part of the operating system enable a user to bypass
Information
Security Technical
Report, Vol. 3, No. 3
Developing a Windows NT Security Policy
normal Windows NT security mechanisms and should not be assigned to any user by default. The policy should provide guidance on the default user rights setting at the workstation, at a server and at a domain controller.
knows the correct name to specify. The policy should state who may generate network shares, which information (files/folders) may be shared across the network and finally what default permissions should be defined within the network share ACLs.
Access to data
By default a number of so called administrative shares are also generated, enabling remote access by the administrators group to the root directory of each disk (e.g. CS) and the system directory (e.g. ADMIN$). The policy should state whether or not remote administrator access is permitted. Where such access is not required then the administrative shares should be suppressed to prevent possible dictionary attacks against the built-in administrator account. In situations where this account is required to be used across a network share the resource kit pmsprop utility should be invoked to enable suspension of this account from network access upon repeated password failures.
Resources such as application and system files, as well as registry keys, are protected through NTFS file permissions. By default the everyone group will be granted FulZ Control over many of these system and file resources. Over the past year, a number of attacks against Windows NT systems have been possible due to the everyone group being given higher levels of access to system files and registry keys than strictly required. For example all users will by default have Full Control at a root level on all disks, giving any user the permission to delete sub-directories, subject to NT enqueing mechanisms! The policy should specify the default levels of access for production application files and critical system resources (files and registry entries). As part of this process standards on the location of files may also be defined, for example whether application files should reside on the workstation or the server. Network Shares Windows NT supports the sharing of information within a domain or Workgroup through network shares. A user may access information located upon another Windows NT system providing they are defined within the appropriate ACL associated with that share and have the correct level of access through the resource ACL itself. To prevent the presence of the share being displayed throughout the network a “$” may be added to the end of the share name. These hidden shares are still available, providing the user
Information
Security Technical
Report, Vol. 3, No. 3
When a user displays a list of users from a trusted domain, or checks the shares available through Network Neighbourhood, their Windows NT system must obtain information from other Windows NT systems. This is performed through an anonymous account. The anonymous account has been exploited in a number of ways, including the so called Redbutton attack. The vulnerability lies through the automatic membership of the nnonymous account in the everyone group. The policy should require the implementation of available patches against such attacks as well as defining changes to the permissions granted to everyone on critical system resources to reduce this exposure. Domain Structure
The Windows NT domain can be considered as a single administrative unit, with membership of a domain or global group providing privileges and/or access rights to
37
Developing a Windows NT Security Policy
resources on systems within the domain. Under Windows NT 4.0 (and prior releases) the domain structure will be determined through considerations about performance, where responsibility for capacity and administration of user and resources should be performed. The policy should identify the domain model appropriate for the organization, for example Master Model, taking into account such considerations as the requirement for centralized user account management. The policy must also provide guidelines on the definition and maintenance of trust relationships. These trust relationships provide the mechanism through which a user in one domain may access resources in another domain without relying upon ‘guest access’. The trusting domain trusts that the trusted domain performs user account management and authentication in an acceptable manner. Any decision concerning setting up a trust relationship with an external organization should take into account both their account policy settings and any relevant procedures associated with user account management (adding, changing, removing). User Rights
The User Rights policy identifies how each defined group of users interact with the Windows NT operating system. Figure 3 provides an example of the screen used to specify the various user rights or privileges. All such settings should be defined within the policy to ensure that the security of the environment is not compromised through a user being granted a higher level of user rights than required. Desktop Security
An important aspect of information security in any organization is ensuring that users understand the importance of protecting their
38
Back UD files and dwectorles Bypass’traverse checking Change the system time
Figure 3: User Rights Policy screen.
desktop when they are not at the desk. Not only might confidential information be being displayed but also someone might use the to perform an logged on account unauthorized action that the account holder will be held accountable for. Windows NT provides both a terminal lockout facility, invoked through the secure attention sequence (crtl-alt-del) and support for 32-bit screen savers that require the user to enter their NT account password. The policy should specify minimum time-out values and also which screen savers can be used at the desktop. Note that the choice of options may be different for a physically secure server, where the presence of a screen saver may be an unnecessary drain on processor resources. Implementation of a standard desktop is also possible through the use of both user profiles and the more recently introduced System Policy. The Windows NT policy should detail the default settings to be used for different types of users. Through the use of multiple policies a number of standard desktop environments can be constructed, with various levels of controls being implemented depending upon which user logs onto the specific Windows NT system.
Information
Security Technical
Report, Vol. 3, No. 3
Developing
a Windows NT Security Policy
implemented and only their network ports enabled.
I3
l&J System pplications
I3 e ? ?e
Windows NT Shell Windows NT System
associated
The policy should also provide guidelines as to which protocols are to be supported, which network adapters they are to be bound to and whether or not II’ forwarding will be supported. The choice of protocol, their bindings and whether or not forwarding is supported can have a significant impact upon whether or not an attacker may use the NT system as a staging post for an attack against other systems on the same internal network. System Logging
Figure 4: Local User Sys tern Policy. Figure 4 illustrates some of the settings available through the System Policy. Although the figure shows the Local User Properties, this information may also be stored as a separate System Policy file that can be invoked upon user account logon. Network Security As a general rule, it is important that a Windows NT system only supports the protocols and network services that are actually required. The policy should identify which network services are required and which are not to be used. For example, whether or not users can use services such as telnet or ftp. Where a service is not to be used then the associated network port should be disabled for both II’and UDI? Failure to do so may result in the system being vulnerable to a denial-of-service attack utilizing one of these port addresses. As a general guide, only required network services should be
Information Security Technical Report, Vol. 3, No. 3
By default Windows NT will not perform security-related logging to the built-in audit trail, the security event log. The policy should indicate which security-related events should be logged and possibly also identify specific files and other resources that require access logging to be performed. Whilst each organization will have its own rules on the logging of security events, most will require security-related failed attempts to be logged (e.g. failed logon attempt) as well as a record of any security related changes. Figure 5 shows a possible set of default Audit Policy settings that would provide logging of most security related events. Note that some options also require changes to be performed within the resource ACL itself or in some cases the definition of specific registry settings in order to actually generate any records. Management of the event logs should also be considered within the NT policy. For each of the three event logs (system, application and security) the system administrator can specify both the size of the log and what action to take when the log becomes full (Figure 6). Three possible actions are available; wrapping around automatically, overwriting entries
39
Developing a Windows NT Security Policy
System development and Maintenance System Maintenance _ BS7799 8.1 Security requirements of systems Objective: “To ensure that security is built into IT systems. ...‘I 8.2 Security in application systems Objective: “To prevent loss, modification or misuse of user data in application systems. ...‘I 8.3 Security of application system files greater than a pre-determined number of days and stopping the system until the built-in administrator account is used to reset a registry entry and manually clear the log. Whilst the latter may seem appropriate for the security log the operational implications of the system ‘crashing’ when the event log is full need to be considered carefully. One possible solution is to copy and clear the log through a procedure invoked by an alert issued when the log is 70% full (or some other suitable value). Finally the policy should indicate how frequently log entries should be checked and what incident reporting procedures should be followed.
1?gure 6: Event Log Options.
40
Objective: “To ensure that IT projects and support activities are conducted in a secure manner. ...” 8.4 Security in development environments
and support
Objective: “To maintain the security application system software and data. ...‘I
of
A number of utility programs are available for maintaining the system, for example the Registry Editor regedt32. Where such utility programs are authorized for use, the policy should indicate who should have access to them and whether they may be used remotely, either through the network or through a remote connection using RAS. Any requirements with respect to change control or other company specific procedures should also be defined. The use of the System Policy Editor may also be specified in the policy as a preferred mechanism for performing standard registry updates across multiple systems. Figure 7 illustrates the default screen for updating registry settings such as the legal notice displayed upon system start-up and suppression of the name of the last user to logon. The use of system policies may be extended through defining company specific entries within the policy files.
Information
Security Technical
Report, Vol. 3, No. 3
Developing a Windows NT Security Policy
Care must also be taken to ensure that any software patches or updates to be applied to a production NT environment are both genuine and tested. In particular, any changes to the operating system components and the registry should only be performed after an appropriate backup has been performed.
Primary Domain Controller (PDC) to one or more Backup Domain Controllers (BDCs). A related consideration is the fact that each Windows NT system has a unique SID (local master SID) and that within a domain each Windows NT system has a domain account, the account name being the computer (NetBIOS) name.
Application Level Security Compliance The policy should specify any particular requirements with respect to the location of application files, NTFS permissions to be applied by default and who should be the NTFS file ‘owner’. Where appropriate, guidelines might also be provided on the use of cryptographic routines (e.g. CAPI) and the implementation of application level user authentication calls (e.g. the new SSPI planned to be introduced within Windows NT 5.0). For applications written to use the Microsoft DCOM, a set of additional security controls are available within Windows NT. The policy should highlight any minimum security controls that need to be implemented for such distributed applications.
BS7799 10.1 Compliance with legal requirements Objective: “To avoid breaches of any statutory, criminal or civil obligations and of any security requirements. ... ”
i
All products implemented within a Windows NT environment must be used in accordance with the terms of the appropriate software The policy should indicate licence. what procedural and possibly automatic
Business continuity planning
9.1 Aspects of business continuity planning Objective: “To have plans available to counteract interruption to business activities. ... ” The policy should identify requirements for system recovery, including the use of RAID facilities to protect against individual disk failure and the implementation of clustering for critical business servers. Any business continuity planning (BCP) for Windows NT must take into account the structure of the domain, with a single user account database being replicated from the
information
Security Technical
Report, Vol. 3, No. 3
Figure 7: Local Computer Sys tern Policy.
41
Developing a Windows NT Security Policy
software licensing implemented.
controls
will
be
A message may also be automatically displayed on system start-up to discourage unauthorized users from proceeding with entering the system. The policy should specify the wording of such a message in order to notify potential users of their liabilities under the UK Computer Misuse Act or similar legislation. A standard message may be implemented across a domain through the use of a system policy file (refer Figure 7).
only. A security risk assessment should be performed to ascertain which controls are appropriate in any particular environment, taking into account specific business, technical and operational considerations. All proposed changes to policies, NTFS permissions, registry entries or other system configuration changes should always be fully tested prior to roll-out within a production environment. The taking of a full system backup prior to implementing such changes is strongly recommended.
Further Sources of Information Conclusions A number of possible controls that might be specified within a Windows NT security policy have been discussed using the framework provided by the British Standard BS7799: Code of Practice for Information Security Management. To be successful, such a policy must ensure that the required baseline set of controls may be implemented without incurring excessive administrative or system overheads. Checking compliance with the policy must also be practical, with a consistent approach being required across many NT systems. For many organizations the solution to these implementation issues will be the choice of a suitable Windows NT ‘add-on’ security product. Where the decision is made to rely upon standard Windows NT facilities only, the use of System Policies in conjunction with scripts built around resource kit and option pack utilities may be appropriate.
Disclaimer The controls discussed in this article and the examples used are for illustrative purposes
42
The primary source for information concerning recommended NTFS permissions, operating system hot fixes and service packs should be Microsoft Corporation, either through technical resources such as Technet or through their Internet site. For information about security-related matters, the Microsoft Security Advisory site (http://microsoft.com/security/) provides guidance and information on how to ‘harden’ the Windows NT operating system. Links from this site are also provided to organizations that have compiled Windows NT guidelines or example policy documents. Examples of such links include the SANS Institute (http://www.sans.org) who market a step by step guide to the set-up of Windows NT security and Trusted Systems (http://www.trustedsystems.com) who offer best practice advice on the creation of a secure environment. Other companies and organizations may also be able to provide additional information on how to secure the Windows NT environment. For example the European Security Forum has compiled a set of Windows NT Security Guidelines that is available to members.
Information
Security Technical
Report, Vol. 3, No. 3
Developing a Windows NT Security Policy
Finally, additional up-to-date security-related information for NT may be obtained from mailing lists such as NTBugtraq and its archives:
Information
Security Technical
Report, Vol. 3, No. 3
NTBugtraq Home Page http://ntbugtraq.ntadvice.com NTBugtraq List Charter http://ntbugtraq.ntadvice.com/ntbugfaq.asp
43