1. Windows 2000 Security
I will give a high-level overview on W2K Security, which is complex
I am not an expert on Windows Security
Probably some of you know better than me, so please do not hesitate to correct me 

2. Windows 2000 Security Overview Complexity or Assurance?
This section provides an overview of Windows 2000 security, but be warned that W2K security is complex!
W2K provides an excellent illustration of a Fundamental Design Principle:
Complexity or Assurance?

3. Windows 2000
W2K is heavily based on its predecessor, Windows NT, and all the significant security features on NT have been carried over to W2K.
W2K comes in various flavours – Workstation, Server, Advanced Server and Datacenter. The basics are the same in all cases, but the administration is quite different. We will concentrate on the Workstation variant mostly.

4. Object-Oriented Design
W2K is object-oriented (objects = files, memory, devices, processes, etc).
An object is a self-contained entity that contains its own data and functions needed to manipulate that data.
What can be done to the object is defined by the object type.
Objects can only be accessed through the Operating System.
The security system checks all accesses to objects and all such events can be logged by the auditing system.
Note that a program cannot access an object directly, it must be done via the Operating System.

5. Security
Within the overall W2K architecture, there are two major components with respect to security:
Object Manager
Manages objects, including files, folders, ports, processes and threads; is in charge of naming, maintaining security, allocating and disposing of objects.
Security Reference Monitor (SRM)
Validates access rights; compares a process’ access token with an object’s ACL and determines whether the requested access is granted; called by the Object Manager.

6. Security Objectives W2K attempts to meet the following security goals:
Single sign-on in the enterprise
Integrated security services
Strong authentication
Standards-based protocols for interoperability
Auditing services
The ability to provide the majority of this functionality is based on policies (i.e. to group together security features) and the Active Directory (AD).

7. W2K Security Subsystem
The main components of the security subsystem are:
Kerberos (v5) – default authentication protocol in W2K; all authentication between W2K machines, as well as clients that support Kerberos authentication.
NTLM – NT LAN Manager - Windows NT Challenge/Response authentication protocol - used in W2K as the authentication protocol for logon to local user account; also supported in domain logons for older Windows machines.
Local Security Authority (LSA) – A protected subsystem that authenticates and logs users onto the local system. It also generates access tokens. LSA also maintains information about all aspects of local security on a system, collectively known as the Local Security Policy of the system.
Security Reference Monitor (SRM) – see earlier
Secure Sockets Layer (SSL) – provides an encrypted channel for authentication.
Security Accounts Manager (SAM) – database of local users and accounts; used for local user authentication; stored locally on all non-domain controller W2K machines.

8. More Terminology
SID (Security Identifier): A globally unique value that identifies user, group, and computer accounts. Every account on a network is issued a unique SID when the account is first created. Internal processes refer to an account's SID rather than the account's user or group name.
It has a long format but need not be remembered
Principals: Active entities in a security policy: entities that can be granted or denied access
Principals can be users, groups, aliases, machines, services,..
Principals have a human readable name (user name) and a machine readable identifier (SID - security identifier)

9. Domains
If you are user on a network, it would too cumbersome to login over and over again when you need access several resources. What you need a facility for “single sign-on”. Domains are used for this purpose
Domain: scope of principals controlled by the same authority;
The authority has information about the principal’s password and can act as a trusted third party when the principal authenticates itself to some other entity
accounts in a domain are global accounts.
Principals associated with a domain is specified as e.g.
Domain controller (DC): machine that provides the security services for a domain. A domain can have more than one replicated domain controllers
Note: Local Security Authority (LSA) are for local accounts

10. User Accounts User Account
Contains information about Users (name, user name, password, access to network resources, etc). When an account is created, it is assigned a globally unique security identifier (SID). All internal processes use the SID.
When W2K first installed, two accounts are created:
Administrator
highest level account; full access to system or domain. This account should be renamed, assigned a password to hide it from attack. Use to create other Administrator accounts. Only an Administrator can create or modify a user account.
Guest
restricted access for users without accounts. Default = disabled (keep it that way!).

11. Groups
Group
A Group is a collection of user accounts. Capabilities can be assigned to a Group. The use of groups, rather than individual accounts, simplifies administration.
Global Groups: are defined for the domain
Local Groups: are defined for a workstation
Global and local groups provide means of two layers of control between subjects and objects.

12. Example Principals World (Everyone) S-1-1-0
SYSTEM S the O/S on a machine runs locally as S ; to other machines in the domain the machine is known under a separate, domain specific, SID
Administrator S <domain> user account created during O/S installation
Domain Administrators S <domain> global group, member of the Administrators group on all machines in the domain
Administrators S built-in group with administrator privileges, contains initially only the Administrator account

13. Predefined Groups for a Domain
There are a number of predefined groups for a domain, mainly for management tasks. For example:
Administrators
Users with rights to manage the system
Account Operators
Users with rights to manage user accounts.
Server Operators
Users with rights to manage servers.
Users
Normal users with accounts
Guests
Users without accounts who have restricted rights.
etc

14. Interactive Login/Authentication
Access to a computer is via User Name and Password. This information is then checked against the user account database in the SAM. This is for authentication purposes and performed by the auth package.
Winlogon: Manages the logon and logoff of users; recognises the Secure Attention Sequence (SAS), i.e. Ctrl+Alt+Del, calls:
Graphical Identification and Authentication (GINA): Gathers logon data and passes it to the LSA for validation.
If authentication is successful, then LSA creates SAT (Security Access Token) for further access control decision

15. Network Authentication
Two authentication protocols supported:
NTLM: legacy protocol from Windows NT
Kerberos V5: implements RFC Kerberos is flexible to authenticate any principal by providing its SID in the tickets. Kerberos is default for W2K.

16. User Rights (Privileges)
Privileges control access to system resources (access rights control access to objects). Do not get confused!
Examples:
Others: Add workstations to a domain, Back up files and directories, Increase quotas ,Load and unload device drivers, Generate security audits, Take ownership of files and other objects, Shut down the system
Right
Description
Default Groups
Act as part of the OS
Allows a user or group to run a process as a trusted part of the OS
None
Bypass traverse checking
Allows users/groups to traverse folders for which they have no access to allow access to a child folder to which they do have access.
Everyone
Administrators
Authenticated Users
Change the system time
Allows a user or group to set the system time of the computer
Server Operators
Power Users

17. Access Control Access control decisions consider the
- subject requesting access: credentials of the subject, including its principal, are stored in its token
- object access is requested for: security attributes stored in its security descriptor
- desired access (access operation): given as an access mask

18. Subjects & Tokens
Subjects are the active entities in the operational system: processes are subjects
Security credentials for processes are stored in tokens; the credentials include the principals associated with the process

19. Creating Subjects When a user logs on to a machine,
system logon session collects credentials (e.g. user password) and presents it to the LSA
The LSA verifies the user’s password
the system logon session creates an interactive logon session for that user (principal)
Each logon session has a locally unique 64-bit identifier (LUID)
Logging off destroys the logon session

20. Token Contents
Identity and authorisation attributes: user SID, group SIDs, user name, privileges
Defaults for new objects: owner SID, group SID, ACL
Miscellaneous: logon session ID, token ID, modification ID, token type, expiration time (unused), impersonation level
Some of these fields are read-only, others may be modified

21. Creating More Subjects
The logon session caches the user’s network credentials (e.g. password) in a token
The logon session can create network logon sessions for that user at other machines; network logon sessions do not normally cache credentials
A process can start (‘spawn’) a new process (subject) by calling CreateProcess
Each process has its own token: different processes within a logon session can have different credentials

22. Objects Executive objects: processes, threads,…
File system objects: files, directories
Registry keys, printers, …
Securable objects have a security descriptor (SD) that contains
The SID of the user who owns the object, usually the creator of the object.
The Discretionary Access Control List (DACL), which holds information about which users or groups are granted or denied access the object. A DACL is a list of Access Control Entries (ACEs).
A System Access Control List (SACL) which defines the auditing policy for the object. i.e. specifies the types of access attempts that generate audit records for the object

23. Permissions (Access Rights)
Describe what one can do with an object
Rather complex mechanism
Permissions are encoded as 32-bit masks
Standard permissions (mostly for controlling SD)
DELETE
READ_CONTROL: read access to security descriptor excluding SACL info
WRITE_DAC: write access to DACL
WRITE_OWNER: write access to owner (for take ownership)
SYNCHRONIZE: The right to use the object for synchronization. Not useful for all object types

24. Generic Permissions Generic permissions:
GENERIC_READ
GENERIC_WRITE
GENERIC_EXECUTE
GENERIC_ALL
Each class of objects has a mapping from the generic permissions onto real permissions

25. The Owner A security descriptor indicates the owner of the object
The owner is a principal
Objects get an owner when they are created
The owner always has READ_CONTROL and WRITE_DAC permission
Ownership can also be obtained via the privilege ‘Take ownership of files and other objects’

26. Access Control Lists + 0x10 Veli WRITE_OWNER
DACL in security descriptor: list of access control entries (ACEs)
ACE format:
Type: positive (adds permission) or negative (denies permission)
Inheritance mask
Trustee: a SID (individual, group, alias) to which ACE applies
Mask: permission (32-bit mask) +
0x10
Veli
WRITE_OWNER

27. Access Check
Accumulate permissions: go through DACL and check ACEs where the subject’s token contains a matching SID:
deny access once a relevant negative ACE is found or the end of the DACL is reached
grant access once all permissions needed for the requested access are obtained
For negative ACEs to take precedence over positive ACEs, they must be placed at the top of the DACL
Empty DACL: nobody is granted any permission
No DACL (NULL DACL): everybody gets all access

28. Access Control Example
File Object
Access Token
Entry 1
Deny Sales Write X
UserId: Mick
GroupId: Users
Managers
Everyone
Security Reference Monitor
Entry 2
Allow Users Read X
Entry 3
Allow Everyone Read X
Desired Access:
Read/Write
Entry 4
Allow Managers Read/Write 
Entry 5
Allow Mick Full Control

29. ACE Inheritance
Inheritance allows an ACE to propagate from a “parent” to a “child”. For example, this allows the setting of a DACL/SACL on a Directory and have that propagate down its directory structure.

30. ACE Inheritance ACE has inheritance mask, e.g.
0x00: ACE not propagated to children
0x10: ACE inherited from parent
0x03: ACE will be propagated to children
0x13: ???
An ACE in the parent (directory) with the inheritance flag set will be inherited by all children (files in the directory);
Inherited ACEs are marked as such and cannot be changed for the child

31. ACL Inheritance
Change to the ACE in the parent is propagated to child unless inheritance is blocked by setting the SE_DACL_PROTECTED or SE_SACL_PROTECTED flag in the security descriptor
An ACE generated directly for an object will be placed in front of the inherited ACEs in the DACL
Hence, a positive ACE can appear before a matching negative ACE

32. Example 1 C F D E +
0x03
Lecturers
all
0x00
Fred
read
0x13
0x10

33. Example 2 C F D E + 0x03 Lecturers all 0x00 Fred read Admin list 0x13
add new ACE for admin

34. Example 3 C F D E + 0x03 Lecturers all 0x00 Fred read - 0x13 Guest
Admin
list
0x10
add new ACE for admin
add new ACE for guest

35. Granting Selective Access+
0x00
Fred
read C F D E
0x03
Lecturers
all -
add new ACE for Fred
0x13
0x10
Lectures

36. Audit
Any security system should include some form of audit system and W2K is no exception!
W2K auditing is an Administrator function (or can be assigned to an “Auditor” group, for example).
Audit event categories include (can set audit success and/or fail):
System events
Process Tracking
Privilege use
Policy change
Object access ,
Logon events
Directory Service access
The Security Log can be accessed via the Event Viewer. Filtering options can be applied, logs can be saved to file, log sizes can be restricted, etc.

37. Audit
Audit rules coded in the SACLs, which are non-discretionary and set by administrators
ACE format in SACL:
Type: positive (audit grant of permission) or negative (audit denial of permission)
Trustee: a SID (individual, group, alias)
Mask: permission (32-bit mask)
An ACE can be both positive and negative

38. If you log it then look at it!
Audit Do’s and Don’t’s
Decide what information needs to be collected.
Decide what information does not need to be collected.
Decide who should have access to the information.
Configure the system as appropriate to the environment.
Use a third-party log consolidation product if it is not practical to review all logs manually.
Review the information and, if necessary, act upon it.
If you log it then look at it!

39. Extra tips for self-study
W2K Security Policies

40. Policies
In W2K, (Security) Group Policies are used to define configurations for users and computers, which allow the creation of granular configuration for users and groups. Account Policies may be used to control password restrictions and account lockouts.
A Security Policy is an organisation’s statement about how it will provide security, handle intrusions and recover from damage caused by security breaches (prevention, detection and reaction). Security policies tend to be relatively high-level statements, that will eventually be refined to procedures and standards. There will be many security policies, including (for example) one for W2K.

41. A W2K Security Policy
In the following slides we provide extracts from a “real” W2K security policy.
In fact, the organisation concerned calls their document a W2K Security Standard – the difference between a Standard and a Policy is somewhat unclear!
The purpose here is to give examples of how theory is turned into practice.

42. Protect the Default Administrator Account
The Administrator account must be renamed to xxxxxx, the description modified and the renamed account assigned a new complex password that is then stored securely.
A dummy account named “Administrator” with minimal privileges and a complex password of 14 characters minimum must be created.
The renamed Administrator account, xxxxxx, must not be used unless as part of a disaster recovery or in instances where a server cannot establish a network connection. Suitable alerts must be set so that any activity on the account is brought to the attention of Operational staff.
All use of the renamed administrator account, xxxxxx, must be subject to a full audit trail of all actions performed on the system.
Any attempted logon activity pertaining to the dummy Administrator account should be investigated.
The renamed administrator account, xxxxxx, must be prevented from accessing the server across the network by assigning the “Deny access to this computer from the network” right.

43. Disable the Default Guest Account
The built in Guest account must be renamed to yyyyyy and disabled.
The built in Guest account must be assigned a complex password of 14 characters minimum to prevent accidental or unauthorised use.
The renamed Guest account must be alarmed so that any activity on the account is brought to the attention of operational staff.

44. Password and Account Lockout Policy
Enforce password history: 12 password remembered
Maximum password age: 90 days
Minimum password age: 1 day
Minimum password length: 8 characters
Store password using reversible encryption for all users in the domain: Disabled
Note: A custom Bank password filtering .dll must be used to enforce the following additional password requirements: passwords must be alphanumeric, maximum of three consecutive repeating characters, must not contain the username, must not contain certain common words (eg password, major cities, etc).
Account lockout duration: 15 minutes
Account lockout threshold: 3 invalid logon attempts
Reset account lockout counter after: 15 minutes

45. Object Access
The setting of folder/file permissions must be performed by authorized support groups only.
Access Control Entries (ACEs) must relate to groups not individual users. Explicit permissions for individual user accounts must be avoided.
Inheritance of Access Control Entries (ACEs) should be allowed (but see Point 4 below).
For business critical and sensitive objects, protected permissions must be applied. Inheritance of ACEs must be suppressed to avoid permissions being accidentally overwritten.
Any group-based access structure must be documented.

46. Control User Rights and Privileges
General users must not be granted rights to system administration and configuration functions.
The minimum level of privileges must be granted to each group of users.

47. Securing of Audit Logs
Access to Windows 2000 audit logs must be secured as follows:
Administrators and SYSTEM: Full Control
Authenticated Users and Server Operators: Read & Execute, List Folder Contents, Read
Domain Security Auditors: Read & Execute
Additional “Security Auditor” groups may be created and given the Read & Execute permission, as required. Approval must be sought from Regional Information Security in advance.
Note: The Domain Security Auditors group is not a built-in group, and must be created. Only those users approved by Information Security ‘Central Operations’ may be added to this group.

48. Group Account Management
Local groups created on servers must be given meaningful names and descriptions.
User accounts must not be given direct membership of local groups. Access to resources must be granted using Domain Global groups.
Normal users must not be allowed membership (direct or indirect) of default privileged security groups (eg Administrators, Backup Operators).