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 CISO and IT security organization spend most of their time reacting to outside forces and not nearly enough time getting ahead of the curve.
One way out of this downward spiral is to get proactive with a system security policy and a method of ensuring compliance. This can change the environment from scrambling to planning, increasing the value and reducing the cost of security. But how can this be accomplished without time, resources and a radical change in the environment?
System security policy management tools are growing in popularity. These tools automate the process of viewing and setting the system 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 OS security parameters cause most common security problems. Keeping critical systems updated with current patches is also a part of this process. Properly configured and patched systems are less vulnerable, leading to fewer security incidents.
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. The process of using these applications to implement a system security policy works as follows:
Phase 1: Choose or set up a policy. Some products come pre-configured with industry-standard, best practices templates to start from. Industry best practices security templates are available as documents from the OS vendors (Microsoft, Sun, IBM, HP) on how to set up their systems securely, or similar documents from third party and government organizations such as SANS, CIS, or the NSA. These documents can list hundreds of permissions and configuration parameters that should be set properly to ensure a secure system. A good system security policy tool will have these policies as templates in the application that can be customized to the particular needs of the enterprise. 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 on corporate applications of locking down the systems.
Phase 2: Identify the systems to be secured. Some of these applications will auto-discover the systems available and will allow the user to choose from a list, while others require that a list of machines be provided. System 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.
Phase 3: Schedule or activate an audit. This is the data collection 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.
Phase 4: Run a report and assess the results. A good selection of reports to use out of the box or for customization is critical. Reports 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 when can be used to graph progress over time.
Phase 5: Comply with your policy. Apply the needed changes or patches to systems that are out of compliance, and then begin again at Phase 3. A flexible product will allow the administrator to select which changes to be applied, or automatically apply all changes. Of course, any changes or patches should be tested first before being applied to production systems.
The return on investment of this approach is significant:
1. Properly configured systems are less vulnerable to attacks,
reducing incident response costs.
2. Patched systems are less vulnerable to attacks, reducing incident
response costs.
3. Automated tools reduce the cost and resources required to get
and stay in compliance.
Of course, there are key considerations when looking at enterprise system security policy management products:
1. Agentless vs. agent-based architecture. 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.
2. 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 be intelligent
enough to account for different circumstances. Items such as the
missions of the audited systems (e.g. database, web, file server)
and the platforms of the systems (e.g. UNIX or Windows 2000)
will require different data to be collected and measured.
3. 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 ODBC, will
make this information more manageable. A central database also
provides for easier custom reporting.
4. Reporting Flexibility. The data produced must meet the needs of
the organization. The ability to do custom reports from a
database of results is often required to meet these needs if the
"canned" reports provided by the tool do not suffice.
With the appropriate enterprise system security policy management tool, system security can be accurate, efficient and complete, providing a stronger level of security to the enterprise while reducing the cost of maintaining this security.
Fred Pinkett, vice president of product management, Pedestal Software
