The following excerpt is from Chapter 1 of the free eBook "Administrator shortcut guide to patch management" written by Rod Trent and available at Realtimepublishers.com. Click for the complete book excerpt series.
Eight strategies for securing vulnerabilities
To protect the installed computer base, the goal is to bring each computer to the most current security specification through proactive patching. There are strategies that you can use in combination with patching that can minimize the exposure to dangerous security flaws. The following eight strategies offer an important educational opportunity for providing security knowledge throughout the organization.
TABLE OF CONTENTS
Never assume that a default software installation is secure
Always require strong authentication
Always perform and verify backups
Close all unused ports
Use antivirus software
Use desktop security software
Always monitor logs
Keep software patched
Software vendors tend to make their installation programs as generic as possible, focusing on ease of use rather than good security practices. There are four separate vulnerabilities you should be aware of when installing an OS or application:
- Default services installed (mainly applies to OSs; however, you should always check what services are installed with applications as well as the ports that the applications use to communicate across the network)
- Flaws in code
- Sample scripts and templates
- Default accounts and passwords
If you're looking to disable unnecessary services on your Windows servers for security purposes, the following list highlights services you should never disable. Disabling any of the services in the list will cause key server and network processes to stop functioning. These services are required for a member server to function within a domain structure:
- COM+ Event System -- Permits management of component services
- Dynamic Host Configuration Protocol (DHCP) Client -- Is required to update records in dynamic Domain Name System (DNS)
- Distributed Link Tracking Client -- Is used to maintain links on NTFS volumes
- DNS Client -- Permits resolution of DNS names
- Event Logs -- Permits event log messages to be viewed in the event logs
- Logical Disk Manager -- Is required to make sure dynamic disk information is updates
- Logical Disk Manager Administration Service -- Is required to perform disk administration
- Net Logon -- Is required for domain participation
- Network Connections -- Is required for network communication
- Performance Logs and Alerts -- Collects performance data for the computer, then writes the performance data to a log or triggers alerts
- Plug and Play (PnP) -- Is required for Windows 2000 (Win2K) to identify and use system hardware
- Protected Storage -- Is required to protect sensitive data such as private keys
- Remote Procedure Call (RPC) -- Is required for internal processes in Win2K
- Remote Registry Service -- Is required for the Hfnetchk utility
- Security Accounts Manager (SAM) -- Stores account information for local security accounts
- Server -- Is required for the Hfnetchk utility
- System Event Notification -- Is required to record entries in the event logs
- TCP/IP NetBIOS Helper Service -- Is required for software distribution in Group Policy; can be used to distribute patches
- Windows Management Instrumentation (WMI) Driver Extensions -- Is required to implement performance alerts by using the Performance Logs and Alerts service.
- Windows Time -- Is required for Kerberos authentication to function consistently
- WorkStation -- Is required to participate in a domain
The goal of an authentication system is to verify who a user is, which then determines what data is available to that user. Each company's security level needs will be different, but consider including the following in your password policy: Strong passwords are at least eight characters, do not contain all or part of the user's account name and contain at least three of the four following categories of characters:
- Uppercase letters
- Lowercase letters
- Base 10 digits
- Symbols found on the keyboard (such as !, @, and #)
In an emergency in which one or more of your servers has gone down and must be restored, having reliable backups of your data is critical -- especially if you can't afford to be down for very long. If backups are not made daily or at an interval acceptable to your library, you will not be able to quickly recover (or recover at all) from data loss. You should create backup procedures that state which data must be backed up, when backups must be made, how they must be tested, where the backup media is stored and how restores are performed.
As open windows to a computer, ports wait for a particular kind of communication. The more ports your servers have open, the easier it is for attackers to connect to that server. In addition, the types of ports your server has open can give away a lot of information about it. One of the first things an attacker will do is monitor your network traffic to try to see which ports are in use. An important security implementation is to restrict which traffic is allowed into your network by allowing only traffic through certain ports on your firewall.
Using antivirus software is a necessity. Not only must antivirus software be installed on all servers and workstations but virus definition files (DATs) must be constantly updated. If your environment is large, consider purchasing antivirus software that has a management component that allows automatic DAT updates and virus scans over the network as well as provides central administration features.
In addition to making sure that the antivirus software is up-to-date, you can block specific file types from delivering through your firewall or email system. The following list highlights the most common virus-targeted file types:
- .bas -- Microsoft Visual Basic class module
- .bat -- Batch file
- .cab -- Cabinet Installation file
- .chm -- Compiled HTML Help file
- .cmd -- Microsoft Windows NT Command script
- .com -- Microsoft MS-DOS program
- .cpl -- Control Panel extension
- .crt -- Security certificate
- .exe -- Program
- .hlp -- Help file
- .hta -- HTML program
- .inf -- Setup Information
- .ins -- Internet Naming Service
- .isp -- Internet Communication settings
- .js -- JScript file
- .jse -- Jscript Encoded Script file
- .lnk -- Shortcut
- .mde -- Microsoft Access MDE database
- .msc -- Microsoft Common Console document
- .msi -- Microsoft Windows Installer package
- .msp -- Microsoft Windows Installer patch
- .mst -- Microsoft Visual Test source files
- .pcd -- Photo CD image, Microsoft Visual compiled script
- .pif -- Shortcut to MS-DOS program
- .reg -- Registration entries
- .scr -- Screen saver
- .sct -- Windows Script Component
- .shs -- Shell Scrap object
- .shb -- Shell Scrap object
- .url -- Internet shortcut
- .vb -- VBScript file
- .vbe -- VBScript Encoded script file
- .vbs -- VBScript file
- .wsc -- Windows Script Component
- .wsf -- Windows Script file
- .wsh -- Windows Script Host Settings file
The security features that come with OSs are sometimes not enough to meet the needs of the environment. Such is especially true with public access workstations. For that reason, desktop security software should be added when the OS cannot provide enough security.
Figure 1.1: The ICF dialog box.
Keeping a close eye on a server's logs is one of the best ways to know when your network is under attack. Logs can show which ports are being opened, which files are being accessed, and which services are being run. Even more important, logs can show when someone has tried to log on with an incorrect password or access a resource. If your server or network is attacked, your log files are a good place to start investigating. Archive your logs on a regular basis so that the log files cannot be overwritten or erased by attackers who want to cover their tracks. If possible, configure your logs to automatically alert an IT staffer -- either by sending an email or generating a pager message -- if an attack is detected.
A computer running any version of Windows NT or later records events in three kinds of logs:
- Application log -- The Application log contains events logged by applications or programs. For example, a database program might record a file error in the Application log. Program developers decide which events to monitor.
- Security log -- The security log records events such as valid and invalid logon attempts as well as events related to resource use such as creating, opening or deleting files or other objects. An administrator can specify which events are recorded in the Security log. For example, if you have enabled logon auditing, attempts to log on to the system are recorded in the Security log. Monitoring logon attempts is a good way to detect attacks and suspicious activity. Audit logon events generates logon events on the local system on which the logon occurs, whereas Audit account logon events generates events when someone tries to authenticate with an account that is stored on the computer on which the logon event is recorded. You can configure this setting through Local Security Policy by clicking Start, Run and typing Gpedit.msc.
- System log -- The System log contains events logged by system components. For example, the failure of a driver or other system component to load during startup is recorded in the System log. The event types logged by system components are predetermined.
All software must be kept patched. Server and network administrators must constantly be on the alert for software vulnerabilities, and they must evaluate and install patches as soon as the patches are released. However, not all patches are necessary; administrators must first be sure that their systems need the patches. Also, some patches can cause more trouble than they are worth. If possible, test patches on a non-production system before installing them on critical servers.
Click for the next excerpt in this series: Additonal reasons why patching is important.
Click for the book excerpt series or visit Realtimepublishers.com to obtain the complete book.