We’ve examined security mechanisms throughout this book, but to be able to successfully protect an organization, security must start at the topmost level and filter down throughout the organization. Executive management must define at a high level what security policies should be put in place, the type of information to be protected, and the level of protection that is required. Employees, especially IT personnel, must be made aware of these organizational security policies and adhere to them or otherwise deal with the consequences for noncompliance.
Employing security policies and the tools used to enforce the policies is the first step in keeping the organization secure; these elements provide the framework for the amount of security that the business requires. Without them, some areas may be protected, whereas others are neglected. This can ultimately jeopardize the organization by leaving security holes in which external and internal users can take advantage and compromise security.
This chapter outlines what security policies are and how they are used by organizations to create a security framework using administrative, physical, and technical controls. In addition, this chapter covers general and Windows Server 2003 security-focused technologies that can be applied as controls for a security framework.
At its core, a security policy is what defines the security posture of an organization. This posture should include protecting an organization’s information, information systems, and people in a manner that reduces or manages the risk to these assets. To perform this role, a security policy must define the rules for expected behavior and what the consequences are for violations of the policy, and it must provide a method to authorize security personnel to monitor, investigate, and respond to intruder alerts. In all cases, a security policy should provide a clear directive that provides a path for reaching an objective through procedures or actions that must be carried out.
Security policies vary from organization to organization, and they may depend on laws and regulations as well as liability issues for the industry or specific organization. For instance, healthcare-related companies have stricter security policies for keeping medical information private to conform to the Health Insurance Portability and Accountability Act (HIPAA), whereas financial institutions must ensure compliance with the Gramm-Leach-Bliley Act (GLBA).
Note
For more information on HIPAA and GLBA, go to http://cms.hhs.gov/hipaa/ and http://www.senate.gov/~banking/conf/, respectively.
Security policies incorporate standards, guidelines, procedures, and other mechanisms. These elements can be organized on how they apply to the organization. No matter what security policies are in place, they should be well documented, reviewed, taught, and practiced.
An organization’s security policies are not all the same. Many different types of policies apply to different levels within an organization. The level at which a policy applies in an organization is defined by a policy hierarchy. Because of differences between organizations, policy hierarchies might differ. Regardless, three policy levels are almost always included within all policy hierarchies: enterprise, issue-specific, and procedures and checklists.
The intention of developing enterprise policies is to address security requirements for the entire organization rather than a specific system or group of systems. Many of these security policies relate to employees, their education, and the enforcement of security policies.
Issue-specific policies address specific security needs within an organization. Examples of issue-specific policies are password policies, Internet usage policies, and antivirus policies.
Procedures and checklists are not actually policies, but instead are designed to eliminate errors with policy compliance by providing a clear path for making decisions. To do this, procedures and checklists are created to define the how, where, and when of policies.
When a security policy is created, the roles and responsibilities of individuals associated with the security policy must be defined. Defining roles and responsibilities dictates how individuals are to interact with a policy. For example, the creation and update of, enforcement of, or adherence to a policy are all responsibilities that must be assigned to individuals within an organization. If these roles are not defined, a policy effectively doesn’t apply to anyone and becomes just another document.
Desktop security policies vary between organizations as well as within an organization. Predominately, specific desktop security policies are managed with GPOs to control or lock down the client machines. It’s also important to have clearly defined security policies documented in the employee forms mentioned earlier in this chapter. Security policies relating to the desktop that may be enforced using a GPO or other means must support the formal, documented security policies for the organization. For more information on GPOs and how they can be applied to network clients, refer to Chapter 29, “Group Policy Management for Network Clients.”
Another variance in how desktop security policies apply may depend on what the users’ responsibilities and roles are within the organization. For example, you may require more control of the desktop for data entry workers than for knowledge workers.
Some possible desktop security policies to consider implementing include, but are not limited to, the following:
Limit the number of applications a user has access to use.
Restrict users from using company resources to play games, or even restrict them from installing any software.
Remove the username of the person who logged on last to the client machine. This keeps people from discovering other usernames and passwords.
Require users to change their passwords periodically. You may also want to consider tightening password history, length, and strength requirements. Also, users must not keep this information on sticky notes on their computers.
Mandate keeping documents on the file servers so that they are backed up every night. You can help alleviate concerns that documents aren’t being backed up by using folder redirection.
The basic reason you should consider application security policies is that any invoked application or code can potentially identify or exploit security holes. A human resources (HR) application, for example, may unintentionally give access to confidential information after a specific key sequence is pressed.
As a best practice, consideration should be made for reviewing and documenting the following application-level security policies:
Establish Windows Server 2003’s software restriction policies. This service provides a transparent, policy-driven means to regulate unknown or untrusted applications.
Support only those applications that are approved and are critical to the business.
Routinely update antivirus definition files to improve resilience against getting a virus.
Provide the least privilege principle to what data an application has access to.
Use Group Policy Objects (GPOs) to lock down the desktop so that users aren’t given full access to the system. For example, disable the
Runcommand or disallow use of the command prompt.Thoroughly test Windows Server 2003 service packs and updates (especially the security-related updates) in a lab environment before deploying them in production.
Test and review application updates and patches to determine how they may affect application security and reliability.
An organization can benefit from many other possible application security policies. The type of security policy that you have will depend on business requirements. In any case, thoroughly reviewing and documenting these application security policies can benefit the network environment by tightening application security.
Network security policies are intended to provide specific and often detailed guidelines and rules to keep the network environment running optimally and securely. Specific policies should be set regarding network access, firewalls and required filtering, specific address or time restrictions, and much more.
Note
In addition to evaluating the best practices and recommendations regarding security in this book, it is also recommended to use the recommended best practices compiled by the National Institute of Standards and Technologies (NIST) and the National Security Agency (NSA). Both agencies provide security lockdown configuration standards and guidelines that can be downloaded from their Web sites (http://www.nist.gov and http://www.nsa.gov, respectively).
Both LAN and WAN environments should have security policies in regard to how and when the network is accessed. LAN and WAN environments are typically protected by firewalls or other security devices, but placing security policy restrictions on how and when users can access the network further tightens security.
If the network access security policy states that users are required to use virtual private network (VPN) connections or Terminal Services instead of dial-up to gain remote access, a possible intruder’s options are further limited. Additional policies may also limit how VPN or Terminal Services connections can be made and what specific configurations are required (for example, every VPN must use L2TP and IPSec).
Network access auditing policies are also a recommended measure to monitor the environment. Reviewing audit logs on a predetermined schedule can identify possible attempts and security breaches.
A security framework is a set of controls that is used to limit exposure to vulnerabilities and threats. As a result, controls also enforce an organization’s security policies and reduce the risk to which an organization is exposed. Although a wide range of potential controls can be implemented within a security framework, all controls are generally classified either as administrative, physical, or technical controls.
When choosing to implement a control, the following items should be considered:
Controls should be implemented as a response to risk.
Controls should be implemented at multiple levels throughout an organization. This is the practice of defense-in-depth (DID).
Controls should be monitored, reviewed, and audited to verify effectiveness.
A control can never completely eliminate risk. In relation, there is a fine line between an effective control and usability. A balance must be struck that addresses both risk and usability.
Administrative controls can be security policies or items such as standards, guidelines, procedures, checklists, and executive enforcement statements that set a clear directive for individuals to follow to ensure security. Because these controls interact directly with individuals, they tend to be scrutinized more rigorously than other controls. In addition, administrative controls are the foundations from which technical and physical controls are implemented and managed.
Although administrative controls contain many different important aspects, all organizations need to address four areas within their administrative controls. Organizations must educate their individuals about their security policies while enforcing those policies. Furthermore, there are form-based controls that must be applied to employees and IT staff.
To comply with security policies that are in effect, users need to know what those security policies are, the consequences of breaking those policies (for example, a warning letter and then termination), and most importantly, how breaking a security policy affects the organization, department, and individual.
Educating users on the organization’s security policies can take many forms, including but not limited to the following:
Two important points to consider when training users is that simply handing them information is not an effective means to educate users, and security policy education should be addressed continually. In other words, you should provide various forms of security policy education and do so on a periodic basis.
Policy enforcement can be a tricky matter and, although enforcement may not be the most enjoyable aspect of security policies, it is a necessity. If you do not enforce the policies and the corresponding consequences, they are essentially ineffective.
This means that if consequences are defined, it is an information security department’s job to provide information about compliance for a policy to ensure the enforcement of security standards. It is not, however, the job of the information security department to enact the consequences that are defined within a policy. The job of enforcement should fall squarely with the realm of the human resources department with support from upper management.
Therefore, enforcement must be tailored to the security policy rather than the individual. For instance, after setting a specific consequence such as termination for revealing to the public confidential information on a new product or service, following through with termination for a developer but not a management-level person can have grave consequences for the security policies and the organization.
There are countless forms relating to an organization’s security and corresponding policies. A few of these forms that should be signed prior to employment or as a mandatory procedure for existing employees are listed here:
Confidentiality agreement
Identification (such as badges, key cards, and usernames and passwords)
Software license agreement (such as policies on copying company software or installing unapproved software on the network)
After your organization creates employee security policy forms, it is recommended that you seek legal counsel to review these documents. Doing so helps to keep the documents in good standing.
In addition to the employee forms that apply to all employees, IT personnel should be required to sign additional forms to protect the network environment. These forms can include
Incident reporting policies and high-level procedures
Privacy agreements pertaining to the way systems are administered or operated
Additional integrity and ethics agreements in regard to system usage, disclosure of sensitive or confidential information, and more
Physical controls relates to how the organization is physically protected from intrusion. Locking mechanisms (both externally and internally), video surveillance, facility-access control such as electronic or smartcard mechanisms, and perimeter boundaries (such as fences and gates) are all examples of how the organization can be protected. Simply documenting what is and is not in place is effectively an internal security audit. Audits often can strengthen security policies and practices.
Technical controls are technical items that are put in place to protect information systems and data. Examples of technical controls range from hardware-based firewalls and antivirus software, to any security feature that is inherit within a technical item. When implementing a technical control, it is important to understand that the threats posed to an organization are dynamic and changing. Therefore, technical controls should be implemented so they can quickly be adapted to changing threats and in an overlapping fashion at many levels within an organization. Furthermore, a technical control should be under constant review and audited to verify effectiveness and identify instances where the control has been circumvented.
Firewalls are often thought of as control points between an organization and the Internet. Although this is true, firewalls can also segment and protect internal areas within a company. There are many different types of firewalls, and their capabilities vary. The types of firewalls used in an organization should be consistent so that the configurations can be similar. In other words, it may be better to use a single firewall vendor throughout the organization rather than have multiple firewall types spread throughout all locations. This helps reduce complexity and ensures that the entire organization follows the same policy. On the other hand, security requirements may be stringent enough to warrant having two or more types of firewalls. For instance, two separate firewalls guarding the Internet border might be required to significantly reduce the likelihood of intrusion. Although the two firewalls increase the environment’s complexity, two firewalls will be less likely to share the same vulnerabilities.
Equally important is that if your company uses more than one firewall, the configurations should be similar if not identical to other firewalls. Specific protocol or port rules should, where applicable, be applied in all locations. For example, a security policy stating that NetBIOS should be stopped at the firewall may keep a hacker from using NetBIOS ports to gain unauthorized access to the network. A security policy would help to prevent any other firewalls in the environment from opening ports 137, 138, and 139.
Note
Windows Server 2003 with SP1 contains a built-in firewall called Windows Firewall. Windows Firewall is a host-based stateful firewall designed to provide Windows servers and clients protection from network attacks that pass through perimeter controls or originate from within an organization. Windows Firewall is not designed to act as a perimeter firewall and should only be used as a supplemental control in conjunction with a full-featured firewall solution such as Microsoft Internet Security and Acceleration Server 2004 or Cisco PIX.
An intrusion detection system (IDS) is used to detect and notify administrators about malicious activity within an organization’s network and information systems. If an IDS system is a reactive system, it not only notifies administrators but takes evasive action to protect the system or network it is monitoring. The typical use of IDS, however, is passive in nature and the use of reactive systems should be limited to special cases that require immediate action when an attack is encountered.
To detect malicious activities, an IDS may either use signature-based or anomaly-based detection methods. The signature-based detection method watches for patterns of activity identified as malicious based on a database of known past attacks. In some cases depending on the rule set, however, an IDS might be able to identity new attacks based on shared characteristics with past attacks. The second detection method, called anomaly-based detection, identifies malicious activity based on baselines that have been defined by administrators or learned from sampling past activity (network- or application-based). If an anomaly-based IDS perceives activity to be different from normal activity, it treats the activity as malicious.
There are two types of IDSs. The most known type is called a network intrusion detection system (NIDS). A NIDS is used to capture network traffic information from various sensors usually positioned at network choke points. The captured network data is then analyzed for traces of malicious activity. The second type of IDS is called a host-based intrusion detection system (HIDS). A HIDS resides on a host system and identifies malicious behavior by monitoring such things as application logs, file system changes, application calls, and other system activities.
Policies surrounding IDSs often involve schedules for keeping the versioning up to date and the procedures to follow after the alarm has been sounded. For instance, if the IDS detects an attack pattern in the network traffic, certain IT personnel should be alerted, and certain procedures should be followed, such as trying to determine the source of the attack or locking down the system from the Internet. The policies that are put in place help to prevent the information systems and networks from being compromised.
In addition to some of the possible security policies mentioned earlier, some network environments also have documented security policies stating that access to specific areas of the network is limited to specific IP addresses. Often these restrictions are placed to minimize security risks associated with ports or paths of communication from a system in the DMZ to the internal network. For example, only Server1 in the DMZ can communicate directly with Server2 using port 1433. However, some organizations have even restricted remote administration to specific IP addresses within the internal network.
Authentication defines how users are to be identified. It is also the primary authentication mechanism. After a user or system is identified, authentication must occur in Windows Server 2003. Authentication is the process in which a system or user verifies the identification of the other. In other words, the users prove that they are really who they say they are. This is similar to presenting a cashier with a credit card and the cashier asking for a driver’s license or other photo ID.
Windows Server 2003 offers several different authentication mechanisms and protocols, including
Kerberos
.NET Passport
Digest
Secure Sockets Layer (SSL)
HTTP
S/MIME
These protocols should be chosen based on the features that you need. For example, for authenticating to Active Directory in a LAN environment, Kerberos is probably the preferred method.
As best practice, security policies relating to authentication should specify the following:
The authentication mechanisms required for performing certain tasks. For example, all traffic to the development Web site must use certificate authentication before establishing an SSL connection.
The number of authentication factors (that is, the number of authentications) required before accessing a specific system or group of systems.
After a user is authenticated, anytime that user requests access to a resource such as a file, folder, share, printer, and so on, Windows Server 2003 checks to see whether the user has the necessary access rights to access and use that resource. For instance, a user can use a Kerberos session ticket to gain access to many different resources or objects. If the user has the necessary rights, that resource can then be accessed and used. This process is called authorization.
Authorization uses access control methods to determine whether a user has the proper rights to access resources. These access control methods are access control lists (ACLs) and roles.
The New Technology File System (NTFS) is one of the primary ways to set access control; it can be used to gain control over authorized and unauthorized access by assigning permissions. It also incorporates the Encrypting File System (EFS), which can be used to further tighten security by encrypting sensitive and confidential information.
The following are some best practices for using NTFS that can also be incorporated into a security policy:
Remove the Everyone group from permissions.
Use groups instead of individual users when configuring access controls.
Use the least-privilege principle so that users can access only the information that they need.
Ensure that administrators have full control on all files, folders, and shares unless the organization specifically dictates otherwise.
Allow only administrators to manage resources.
When organizations build servers from scratch, typically the configurations are built inconsistently. In other words, some file and print servers may have IIS, Remote Desktop for Administration, various NTFS permissions, and more, whereas other servers do not. From an administration, maintenance, troubleshooting, or security point of view, such configurations can be a nightmare. Each server must be treated individually, and administrators must try to keep track of separate, incongruent configurations.
Base installation security policies and server build documentation help to create a standard baseline for how a specific type of server is built and the type of security that is applied. They can contain step-by-step instructions on how to build different types of servers without sacrificing security. From this, all administrators have a common ground or knowledgebase of configuration information, including security configurations, which can save time when administering, maintaining, and troubleshooting.
A Public Key Infrastructure (PKI) is an infrastructure model that manages the creation and distribution of public key certificates. Public key cryptography used to secure (encrypt and verify) communication for a wide number of IT services such as HTTP traffic, VPN connections, network authentication, secure email exchanges, etc. PKI facilitates a web of trust to be established between members of a PKI and their public keys. This web of trust is used by members to provide authentication, identity verification, and confidentiality for intra-party communications.
A CA stores the private and public keys and is responsible for issuing and signing certificates. These certificates are digitally signed agreements that bind the value of the public key with a distinct private key. Certificates typically contain information on the name of the user or service, the time in which the certificate is valid, CA identifier information, the public key value, and the digital signature.
Protecting the network environment with various security policies and mechanisms is, without question, necessary. However, monitoring is also key to enforcement and identifying security policy violations. For instance, all the security policies and mechanisms can be in place, but without monitoring, there is no way to identify and determine whether they are effective.
Some common monitoring tools found within an organization include syslog, SNMP, traffic sniffers, and IDS. The most common Windows Server 2003 monitoring tool is the Event Viewer. The Event Viewer captures audited events such as account logon, account management, directory access, object access, policy change, and more. By default, initial auditing parameters are set to audit successful account logon events. Moreover, logging is configured to use up to 128MB of disk space before overwriting events.
Note
New logon type events can be monitored, including cached logons and remote interactive (Terminal Services) logons.
Application logs are also commonly reviewed for security purposes. Log files are usually generated by services and applications, and the level of detail can often be configured to provide just general information up to the maximum amount of detail. The level of detail that can be provided and the configuration options vary. When you’re configuring these options, keep in mind the amount of disk space required as well as how this information will be reviewed.
Tip
It is highly recommended that you consider using Microsoft Operations Manager (MOM) to monitor and manage the Windows Server 2003 network environment. It can consolidate security-related events and provide a convenient, centralized location to review security information on multiple Windows Server 2003 systems.
Numerous security stress-testing tools are available from third-party vendors. Many have very specific functionality such as port scanning, password cracking, buffer overflow identification, and more. For example, LC4, formerly known as Lophtcrack, can be used as a password-auditing tool to discover weak passwords, but it’s not designed to uncover other vulnerabilities.
When choosing a third-party security tool, you must carefully choose your target area before conducting a stress test.
To ensure policies are adhered to organizations must enforce their security policies. In addition to the preceding general technology controls Windows Server 20003 has integrated many different tools to enforce security policies throughout an organization’s Windows based systems.
Windows Server 2003 has the capability to act as a certificate authority (CA). This service in Windows is called the certificate services and is available on Windows Server 2003 Standard Edition, Enterprise Edition, and Datacenter Edition.
Note
Windows Server 2003 Enterprise Edition or Datacenter Edition is required to configure version 2 certificate templates for auto-enrollment.
To install Windows Server 2003 certificate services, do the following:
Choose Start, Control Panel and then select the Add or Remove Programs icon.
Select Add/Remove Windows Components to display the Windows Components Wizard window.
Check the Certificate Service box. When you see a warning message, click Yes to proceed. Click Next to Continue.
Choose the type of CA to install. You can choose from the following options:
Enterprise Root CA—. This CA requires Active Directory, and is the topmost level of the certificate services hierarchy. It can issue and sign its own certificates.
Enterprise Subordinate CA—. This type of CA is subordinate to the enterprise root CA. It requires Active Directory and can obtain certificates from an enterprise root CA.
Standalone Root CA—. This CA is the topmost level of the certificate services hierarchy and can issue and sign its own certificates. Standalone CAs do not require Active Directory.
Standalone Subordinate CA—. Similar to the enterprise subordinate CA, this CA is subordinate to the standalone root CA.
Checking this box and then clicking Next allows you to select the cryptographic service provider (CSP), hash algorithm, and key pair configuration as shown in Figure 15.1.
Identify the CA by entering the appropriate common name. You can also set how long the CA is valid (the default is five years). Click Next to continue.
Verify the location of the certificate database, logs, and shared folder. Click Next to continue.
Click Finish to complete the CA creation.
Note
Windows Server 2003 contains a command-line utility called certutil.exe that can provide a wealth of information about a CA and certificates. Microsoft touts this as a powerful troubleshooting tool and rightly so. Its many capabilities include, but are not limited to, verifying certificates and services, displaying certificate services configuration information, re-associating private keys with the proper certificate, publishing a certificate revocation list, and revoking certificates. As you can see, however, this tool is also very useful for keeping security policies enforced and in the proper configuration.
Windows Server 2003’s integrated Security Configuration and Analysis tool is used to compare the current security configuration against a database. This database uses one or more predefined security templates. If more than one security template is used, the settings from each security template are merged, which may result in a combination of security configurations. If a conflict occurs between the database and the last-applied security template, the last security template takes precedence.
Note
The Security Configuration and Analysis tool displays indicators on each security configuration as to how it ranks when compared to the analysis database. For instance, a red X indicates that values between the database and the current configuration do not match.
To begin using the Security Configuration and Analysis tool, do the following:
Select File, Add/Remove Snap-In.
Click the Add button and choose Security Configuration and Analysis. Click the Add button in the Add Standalone Snap-in page.
Click Close and then OK to return to the Microsoft Management Console.
Click Security Configuration and Analysis in the left pane. If this is your first time using the tool, you’ll see instructions on how to open a Security Configuration and Analysis database or create a new one.
If you want to create a new database, right-click Security Configuration and Analysis in the left pane and select Open Database.
Browse to the location you want to store the database and then type in its filename.
Click Open to create the new database.
In the Import Template dialog box, choose which security template to use and then click Open. In this example, use
setup security.inf.Select Action, Analyze Computer Now.
In the Perform Analysis window, specify the location and name of the log file you want to use. Click OK when you’re done.
After the Security Configuration and Analysis tool finishes analyzing the system against the analysis database, you can browse and review the security configurations, as shown in Figure 15.2. At this point, you can either selectively configure security settings or select Action, Configure Computer Now to set the security settings.
Security Configuration and Analysis is a great tool for standardizing Windows Server 2003 security throughout the network. It is also very useful for ensuring that security configurations are set properly. Use this tool at least every quarter and on new systems to keep security policies enforced.
The Microsoft Baseline Security Analyzer (MBSA) is a tool that identifies common security misconfigurations and missing updates through local or remote scans of Windows systems. MBSA scans either a single Windows system or a group of Windows systems and obtains a security assessment, as well as a list of recommended corrective actions. Furthermore, administrators can use the MBSA tool to scan multiple functional roles, such as a Microsoft SQL Server or Exchange system, of a Windows-based server on the network for vulnerabilities to help ensure systems are up-to-date with the latest security-related patches.
To run MBSA, do the following:
The Security Configuration Wizard (SCW) is a tool provided in Windows Server 2003 Service Pack 1 that can significantly improve a computer’s or a group of computers’ security. As the name implies, SCW is wizard-based, designed to determine the specific functionality required by the server. All other functionality that is not intended or required by the server can then be disabled. This reduces the computer’s attack surface by limiting functionality to only that which is required and necessary.
SCW reviews the computer’s configuration, including but not limited to the following:
Services—. SCW limits the number of services in use.
Packet filtering—. SCW can configure certain ports and protocols.
Auditing—. Auditing can be configured based on the computer’s role and the organization’s security requirements.
IIS—. SCW can secure IIS, including Web Extensions and legacy virtual directories.
Server roles and tasks—. The role (file, database, messaging, Web server, client, and so on), specific tasks (backup, content indexing, and so on), and placement in an environment that a computer may have is a critical component in any lock-down process or procedure. Some of the roles and tasks that are evaluated are illustrated in Figures 15.3 and 15.4. Application services are also evaluated from products such as Exchange Server 2003, SQL Server 2000, ISA Server, SharePoint Portal Server 2003, and Operations Manager.
IPSec—. SCW can be used to properly configure IPSec.
Registry settings—. After careful analysis, SCW can modify the LanMan Compatibility level, SMB security signatures, NoLMHash, and LDAP Server Integrity parameters based on down-level computer compatibility requirements.
Caution
SCW is a very flexible and powerful security analysis and configuration tool. As a result, it is important to keep control over when and how the tool is used. Equally important is testing possible configurations in a segmented lab environment prior to implementation. Without proper testing, environment functionality can be stricken or completely locked.
SCW is used to assist in building specific security-related policies and to analyze computers against those policies to ensure compliance. In many ways, SCW can be considered a replacement for other Microsoft security-related tools that have already been mentioned in this chapter. For instance, SCW can take existing security templates created from the Security Configuration and Analysis tool and expand upon the restrictions to meet an organization’s security policy requirements. In addition, SCW can create, edit, and apply system security policies to computers, integrate with Group Policy, and provide a knowledge base repository for system security policies.
Windows Rights Management Services (RMS) is an unprecedented new feature that enables users to more securely create and control information. It gives the creator of the specific information control over the following:
What can be done with the information
Who can perform actions or tasks with the information, such as who can review or print a document or whether a message can be forwarded
The lifetime of the information meaning the time the information can be reviewed or used
RMS is intended to complement and co-exist with other security measures within an organization. Security mechanisms, policies, practices, and technologies should work seamlessly together to provide the most effective safeguarding of information and property, but at the same time, they should be as unobtrusive as possible to the end user. Therefore, RMS is not confined to a specific network or Web site—it extends beyond transport layer boundaries.
RMS further granularizes security for browsers and applications such as Microsoft Office 2003 that are WRM-aware by using encryption, Extensible Rights Markup Language (XrML)-based certificates, and authentication. Security administrators can establish RMS-trusted entities with users, groups, computers, and applications that are then used to assign security rights to information. The security rights are stored in a publishing license, which is encrypted along with the information. As information is requested, RMS validates credentials and usage rights.
Security policies shape a Windows Server 2003 network environment into a more controlled, more secure environment. Overall, they establish baselines that can more easily be enforced. Because security policies are based on business requirements more so than technical reasons, the entire organization must comply with these policies. The security policy tools examined in this chapter help to enforce the security policies and maintain the secured environment.
Executive management must define what security policies to put in place, the type of information to be protected, and the level of protection that is required.
Educate employees on the organizational security policies and the corresponding consequences for noncompliance on a periodic basis.
Review the Health Insurance Portability and Accountability Act (HIPAA) for health-care-related security policies at http://www.hipaa.org/.
Review the Gramm Leach Bliley Act (GLBA) for financial institutions at http://www.senate.gov/~banking/conf/.
Enforce security policies to make them effective.
Periodically perform security audits to define and strengthen security policies and practices.
Hire a security expert or firm to perform security audits on your infrastructure.
Create system-level security policies to provide baseline system specifications.
Define the primary authentication mechanism and the ways users are to be identified.
Identify which authentication mechanisms are required for performing certain tasks.
Practice defense-in-depth (DID) when constructing a security framework.
Use NTFS whenever possible.
Remove the Everyone group from permissions.
Use groups instead of individual users when configuring access controls.
Use the least privilege principle so that users can access only the information that they need.
Ensure that administrators have full control on all files, folders, and shares unless the organization specifically dictates otherwise.
Allow only administrators to manage resources.
Establish Windows Server 2003’s software restriction policies. This service provides a transparent, policy-driven means to regulate unknown or untrusted applications.
Support only those applications that are approved and that are critical to the business.
Routinely update antivirus definition files to improve resilience against getting a virus.
Practice the least privilege principle to the entire organization.
Use Group Policy Objects (GPOs) to lock down the desktop so that users aren’t given full access to the system. For example, disable the
Runcommand or disallow use of the command prompt.Thoroughly test Windows Server 2003 service packs and updates (especially those that are security-related) in a lab environment before deploying them in production.
Test and review application updates and patches to determine how they may affect application security and reliability.
Limit the number of applications a user has access to use.
Remove the username of the person who logged on last to the client machine. This keeps people from discovering other usernames and passwords.
Require users to change their passwords periodically.
Consider tightening password history, length, and strength requirements.
Mandate keeping documents on the file servers so that they are backed up every night.
Help alleviate concerns that documents aren’t being backed up by using folder redirection.
Use the Security Configuration and Analysis tool to compare the current security configuration against a predetermined security requirement.