Chapter 5. Security Compliance Manager design
5.2 Design objectives
This section describes the design objectives that are related to the infrastructure and operation of the security compliance management solution.
5.2.1 General and infrastructure objectives
The complexity of ABBC’s heterogeneous, multi-layered enterprise makes it a challenge to manage compliance with ABBC’s security policies and standards. The design of the security compliance management solution must cover multiple operating systems, critical business applications across the enterprise, and may not impact the confidentiality, the integrity, and the availability of corporate assets. Therefore, the security monitoring infrastructure itself must be treated as a critical system and designed carefully. The general design objectives for the monitoring environment include:
Minimal impact on scanned IT systems
The Security Compliance Manager client running on the IT systems may only slightly impact the performance during its installation, data collection, and data transfer to the Security Compliance Manager server.
Centralization
To reduce infrastructure and administration costs, the security compliance management system uses a centralized Security Compliance Manager server for all regions.
Scalability
The centralized solution must be easily scalable to allow, in a cost effective manner, the addition of new Security Compliance Manager client systems.
Support secure communication and privacy
Critical information exchange, such as security compliance data, user ID, and password data for authentication, must be transmitted in an encrypted form. Applications and core system components should not rely on weak or clear text password processing or storage.
The password rules implemented in the security monitoring systems must fulfill the requirements defined in the security policy.
OS hardening
The Security Compliance Manager infrastructure has to comply to the security class 1 defined in the enterprise security policy. Only authorized users can access the Security Compliance Manager servers and
applications. Only required services are installed on the security monitoring systems.
Confidentiality
Security compliance data must be processed, transmitted, and stored in a secure fashion.
5.2.2 Platform specific security concepts
This section discusses integration aspects for specific platforms and subsystems that need to be included in the automated security compliance process.
Integration of Tivoli Risk Manager
Tivoli Risk Manager leverages the Tivoli Enterprise Console event management system to centrally manage enterprise security threats. Integrating Security Compliance Manager with Tivoli Risk Manager consists of two independent steps:
Security deviation notification
Security Compliance Manager is able to inform Tivoli Risk Manager about a security compliance deviation immediately after detecting it. The integration
This feature is important for machines at high risk, for example, machines in a DMZ that are accessible from external networks.
Tivoli Risk Manager monitoring
Security Compliance Manager can be exploited to perform security compliance management for Tivoli Risk Manager components. Typically, a Risk Manager infrastructure consists of a central Risk Manager Event Server and multiple Risk Manager Gateways or Clients. It is important to ensure the correct configuration of the Risk Manager components to avoid undetected intrusion attempts.
Integration of databases
Protecting and securing important information has always been a number one priority. ABBC stores the most important information assets in relational databases. Usually, database systems are open for public access, yet well equipped with advanced security options. The serious database administrator (DBA) has to implement a database security policy choosing between the operating system security, additional specialized security software, or using integrated database security features. The target security policy that is implemented is often a combination of all of them. ABBC’s security policy standards define strict configuration settings and protection measures. Obviously, it is a high priority for the security compliance project to include databases in the automated security compliance process. The project team decides to implement Security Compliance Manager Java collectors and policies for DB2 and Oracle databases that cover the following data:
Database system configuration
The database Java collectors gather information stored in the configuration files of the database systems and operating system platforms. Most of the required information can be gathered using standard collectors provided by the Security Compliance Manager policies for operating system platforms.
Database content
The ABBC security policy requires gathering data that is stored in database tables like database authorization information. The project team designs generic database collectors using SQL statements to retrieve data from database tables.
Considerations about clients on high secure systems
ABBC operates a number of systems that provide security functions, such as proxies and application-level gateways/firewalls. These systems are located in a a separate network segment (Demilitarized Zone (DMZ)) between the external Internet and the (considered internal) segment holding the Internet facing application servers. Because these proxies are a major protection against threats
from the Internet, they must have as little vulnerabilities as possible towards attacks. Therefore, one of the protective measures taken is that only the absolute minimum of services/applications is active and even installed on those systems, which are otherwise
normal
AIX systems, an approach calledhardening
. So on the one hand, it is required to have only the minimal amount of services installed, but on the other hand, it is obviously necessary to check thecompliance status of those systems carefully and often. As a result, the question needed to be analyzed is whether it is a higher risk to install additional software, the Security Compliance Manager client, for compliance checking, using some other solution or not checking the systems automatically. The latter alternative, no or manual compliance checking, was quickly ruled out by the IT Security department, so that the only question that remained was if Security Compliance Manager clients could be used or some other solution would be preferable. A risk analysis of the Security Compliance Manager client components identified and discussed the following risks:
Risk: The installation of a TSCM client may void the warranty or support on "black boxes" such as firewalls, for example, the Checkpoint Secure Platform (SPLAT) or other appliances. Such "black boxes" often contain a “stripped down” version of Linux or Windows for which the security standards and policies apply as well. However, some vendors state that they will not support a deployed system if additional software is installed.
– Discussion: For such systems, you must evaluate whether the installation of a non-intrusive software component such as the TSCM client can be tolerated by the vendor or if the vendor has a different policy. If not, the risk of losing the warranty (or being required to reproduce an error without the TSCM client installed) must be weighted against the risk of a breach of security in or through this system due to flaws in the security configuration. – Additional mitigating actions: Verify with the system vendor if there is a
testing/certification process for third-party products.
Risk: The Security Compliance Manager client requires the installation of a Java Runtime Environment. A Java Runtime Environment is often accessible by all users of a system. There have been vulnerabilities in the Java Runtime Environment in the past that allowed for privilege escalation (Privilege Escalation, SUN Alert 57221, Oct 031) and there may be issues in the future. – Discussion: The Java Runtime Environment installed by the Security
Compliance Manager client installer is executable only with root user privileges (Administrator). If another Java Runtime Environment is used, it can be restricted to be only executable by root so that no other user can access it. Privilege escalation is therefore not a issue.
– Additional mitigating actions: Ensure that, if a third-party JRE is used, it is only executable by root.
Risk: The Security Compliance Manager client opens a listening port for communication with the Security Compliance Manager server using Java Sockets provided by the Java Runtime Environment. There have been vulnerabilities in Java Sockets in the past (Remote Denial of Service Vulnerability, SUN Alert 57555, May 042) and there may be issues in the future. In some cases, it is not possible to only run the Security Compliance Manager client in push mode, so that the Security Compliance Manager client initiates the connection to the server, due to network connectivity issues. – Discussion: Any solution that does not require a
handshake
betweencompliance management client and server cannot be tamper resistant, because the authenticity of the compliance management client cannot be verified by the server. Any alternative would therefore also require a listening port (where push cannot be used). As a result, Java Sockets is preferable to any alternative because Java Sockets is under intense scrutiny by vendors, programmers, and security experts worldwide and it is less likely that a vulnerability is known only to attackers for a long period of time.
In addition, Java is used in other parts of the organization and already covered by the Computer Emergency Response Team (CERT) processes that alert the organization to critical vulnerabilities in deployed software packages.
– Additional mitigating actions: The filter rules of the routers and firewalls of this segment must ensure that the Security Compliance Manager client is only accessible by the Security Compliance Manager server (or proxy). In conclusion, the installation of Security Compliance Manager on hardened systems was authorized by the IT Security Department.