Using tools to set up and comply with a systems security policy

Information security is a reactive world. The next intrusion, vulnerability or worm is always right around the corner. With critical issues arising everywhere, the typical chief information security officer and IT security organization spend most of their time reacting to outside forces rather than getting ahead of the curve.

One way out of this predicament is to establish a systems security policy and a method of ensuring compliance. Systems security policy management tools are growing in popularity. These tools automate the process of viewing and setting the configurations of a large number of systems and reporting on their configurations against a security policy to give measurable results. Improperly configured systems, including items such as permissions, user rights and operating system security parameters, cause most common security problems.

The basic process of using these tools is to continuously audit, assess and comply. That is, audit your systems against the security policy, assess the results of the audit and comply with your policy by applying settings or patches on systems that are out of compliance. Here's a step-by-step process for using these applications to implement a systems security policy:

Step 1: Choose or set up a policy.

Some products come preconfigured with industry-standard best practices templates. These templates are available as documents from operating system vendors (Microsoft Corp., Sun Microsystems Inc., IBM and Hewlett-Packard Co., for example) on how to set up their systems securely. Similar documents are available from third-party and government organizations such as the SANS Institute, the National Institute of Standards and Technology and the National Security Agency.

These documents can list hundreds of permissions and configuration parameters that should be set properly to ensure a secure system. A good systems security policy tool will have these policies as templates in an application that can be customized to the needs of the company. These documents, and the software's implementation of them, should be thoroughly reviewed and understood. The implementation should also be tested in the lab to assess the effect of locking down the systems on corporate applications.

Step 2: Identify the systems to be secured.

Some of these applications will autodiscover the systems available and will allow the user to choose from a list. Others require that a list of machines be provided. Systems security policies should be applied to the most critical servers first, and then rolled out in a phased approach that makes sense for the enterprise.

Step 3: Schedule or activate an audit.

The audit is the process that will gather data from each machine over the network. Some of the applications do this without additional software, and some require a specialized agent installed on the target system.

Step 4: Run a report and assess the results.

A good selection of reports to use out of the box or for customization is critical. These should include detailed reports, with item-by-item and machine-by-machine listings, roll-up reports with machine summaries for finding problem areas, executive summary reports with overall status reporting and high-level charts, and trend reports that can be used to illustrate progress over time.

Step 5: Comply with your policy.

Apply the needed changes or patches to systems that are out of compliance, and then begin again at Step 3. A flexible product will allow the administrator to select which changes to be applied or automatically apply all changes. Changes or patches should be tested first before being applied to production systems.

The return on investment of this approach is significant:

Fred Pinkett
  • Properly configured and patched systems are less vulnerable to attacks, reducing incident-response costs.
  • Automated tools reduce the cost and resources required to get into and stay in compliance.

Finally, here are some key factors to consider when choosing a systems security policy management product:

  • Agentless vs. agent-based architectures: If there are only a few systems and the administrators are willing, then agents can be installed on audited systems. For large numbers of systems, both desktops and servers, an agentless approach is desirable. It reduces the cost and time to deploy the application and eliminates the need and cost to manage and upgrade the agents.
  • Policy flexibility: The audit must measure against the specific policy of an organization. The policy customization function must be able to cover the items being audited and must be intelligent enough to account for different circumstances. Items such as the missions of the audited systems (such as database, Web or file server) and the platforms of the systems (such as Unix or Windows 2000) will require different data to be collected and measured.
  • Central database: The information gathered from an audit of a large number of machines is substantial. A tool that stores this data in a database via a standard interface such as Open Database Connectivity will make this information more manageable. A central database also provides for easier custom reporting.
  • Reporting flexibility: The data produced must meet the needs of the organization. The ability to generate custom reports from a database of results is often required to meet these needs if the "canned" reports provided by the tool don't suffice.

With the right tools, systems security can be accurate, efficient and complete, providing a stronger level of security to the company while reducing the cost.

Copyright © 2003 IDG Communications, Inc.

7 inconvenient truths about the hybrid work trend
Shop Tech Products at Amazon