- Objectives
- Introduction
- AAA Overview: Access Control, Authentication, and Accounting
- Security Administration—The Importance of a Security Policy
- Keeping Up with and Enforcing Security Policies
- Risk Assessment
- Why Data Classification Is Important
- The Importance of Change Management
- Performing Vulnerability Assessments
- Chapter Summary
- Apply Your Knowledge
Keeping Up with and Enforcing Security Policies
You should remember that security policies will create growing pains, and no implementation of a new security policy (especially in places that lacked one in the first place) is easy. In fact, you should expect resistance when the concept is first developed or tested. You can broach the subject of security and why a given set of principles or policies is important in a variety of ways.
One of the more effective means includes a short and to-the-point email that outlines the policies with an invitation to discuss it with you or your IT department at greater length. Or, you can attend a departmental meeting to discuss the issues with a department during its regular meetings, or set up a special meeting with a group or department.
A security policy is a living entityit must be constantly monitored to ensure that the recommended practices are being followed and to ensure that the policy is kept up to date with the current environment on your network and in the outside world. Monitoring how a security policy is being followed can be accomplished with a security checklist.
Understanding Security Checklists
Security checklists help you establish security for your organization, ensure that your security policies and practices are applied in a consistent manner, and confirm the security status of your systems and network. A standard checklist allows you to establish and confirm the security of a single computer as it is having the operating system installed or confirmed. This ensures a desired level of security is established from the start. Then, after a set period of time, you can use the same, or similarly modified, security checklist to recheck the security status of that system. When you recheck your system, you can compare things such as software patches and security fixes to the current available patches and fixes to determine whether the system is still up to date and has the most current security features. If not, you should be able to quickly pinpoint updates that must be performed to keep that system current.
Security checklists are not limited to checking and rechecking your systems and other network infrastructure. Many software vendors offer recommended checklists for securing their products. The security checklist, however, may figure prominently in your security policy and should, therefore, be designed and implemented at or near the beginning of your security implementation. By doing so, you can create repeatable results as you begin implementing at least a minimal level of security on your systems and networks. By using a simple checklist, similar to the following sample, you can dramatically improve the security on your network by repeating the same security settings across the entire breadth of your systems.
Installed operating system:
Installed service pack:
Last administrator password change:
Last installed security hot fixes:
Special services or software and version:
Although it's brief, this security checklist offers key benefits. First, it prompts you to write down the current, pertinent information about the server, which you can compare to known information from the software vendor, or your own security observations that you discovered along the way. Second, it forces you to research which updates are now considered current and any new security vulnerabilities that may have been unearthed since the last time you ran through your security checklist.
Security checklists allow the security administrator to focus on necessary tasks, increasing his productivity. They can also help make management of servers easier because each server will be more or less configured the same, give or take differences in operating systems and installed software and services.
Working with Security Checklists
You can use security checklists from software manufacturers to ensure that their software is configured properly for security, and your own checklists to set benchmarks and assess security on your servers and network. Some of the more useful checklists we have encountered are from Microsoft. One, in particular, is a sample security checklist for Windows 2000 and Internet Information Services version 5 (IIS5). The checklist is designed to appraise Windows 2000 and IIS5 security and is similar to the following:
Server Configuration
Computer name:
Installed by:
Date installed:
Computer make/model:
Processor(s) make and speed:
Installed system RAM:
Network card(s):
Partitions formatted with NTFS? Yes or No:
Current Windows 2000 Service Pack installed:
Current hot fixes installed (Windows 2000):
Current hot fixes installed (IIS5):
Telnet access disabled? Yes or No:
Special notes about TCP services:
Installed Services LogDetermine Whether Services Are Installed
|
Yes |
No |
FTP Publishing: |
|
|
NNTP Service: |
|
|
SMTP Service: |
|
|
Content Index: |
|
|
Certificate Authority: |
|
|
RPC Locator: |
|
|
Server Service: |
|
|
Remote Access Services: |
|
|
Alerter: |
|
|
NT Scheduler Service: |
|
|
Computer Browser: |
|
|
DHCP Client: |
|
|
Instant Messenger: |
|
|
Net Logon: |
|
|
Network DDE: |
|
|
Network Monitor Agent: |
|
|
Simple TCP/IP Services: |
|
|
NetBIOS Interface: |
|
|
WINS Client (TCP/IP): |
|
|
NWLink NetBIOS: |
|
|
NWLink IPX/SPX: |
|
|
System Network Configuration
IP addresses:
Subnet address:
Gateway address:
|
Yes |
No |
DNS server: |
|
|
DHCP server: |
|
|
WINS server: |
|
|
Network Address Translation server: |
|
|
In addition to verifying the currently enabled services and installed patches and fixes, you can catalog this kind of information to make inventory of your systems much easier.
Vendor Security Checklists
In addition to checklists that help you verify configuration and security after the servers have been installed and configured, vendors have security checklists to help you with initial software configuration. The following URLs will direct you to some useful security checklists available for securing operating systems and software:
A security administrator's guide to Linux: http://www.nic.com/~dave/SecurityAdminGuide/SecurityAdminGuide.html
A Microsoft security checklist for IIS5: http://www.microsoft.com/windows2000/en/datacenter/iis/default.asp?url=/WINDOWS2000/en/datacenter/iis/htm/core/iisckl.htm
An excellent Microsoft security checklist for Windows domain controllers: http://www.microsoft.com/technet/treeview/default.asp?url=/technet/itsolutions/security/tools/dccklst.asp
This Web site is a great site with links to many other security checklists for a few different operating systems as well as network security checklists: http://www.iic.at/security/security_checklisten.htm
Start implementing security policies and practices by using security checklists to install and configure software from the start and then using security checklists to assess the current configuration and security of your servers and other network components. In addition, you must also keep up on current security issues, security patches, and fixes. To add to this, you must design, implement, and maintain security principles, policies, and matrices to keep a consistent level of security implemented in your organization to aid in the development and implementation of your security checklists to ensure that the standard of security you have established remains at that level.
Another important concept is that of data aggregation. In and of itself, certain pieces of information might not be classified, but the juxtaposition of them might result in sensitive information. To use a military example, the fact that Sgt. Jones just bought a plane ticket to Africa might not be a state secret. It might also be public knowledge that Sgt. Jones is an expert on Egyptian affairs and that his unit just ordered supplies that would feed 1,000 men for three months. However, the combination of these three facts might lead an enemy to infer that his unit was going to Egypt for an extended operation, which might be a classified fact.