Computer Security Review

This section includes the following topics:

Background

The key element of security is knowledge. Being aware of security issues and understanding how to curtail their affect is paramount.

A security risk is the likelihood of a disruption relative to the consequences of the disruption. A security threat is any event that interferes with the reliability of a system, specifically within any of the four areas of information security: confidentiality, integrity, availability, and accountability. These different areas are often complexly interrelated.

The goal of securing a computer system is to identify and reduce security risks. An OSMS is middleware that exists over an OS, and both layers must be secure for the entire system to be secure. Therefore, to secure an OSMS environment, you must consider the threats to which both layers might be exposed, consider what risks these threats pose, and then determine which processes might reduce the risks to an acceptable level.

Areas of Concern

Confidentiality—Concerns controlling who may access particular information, such as limiting which employees are permitted to view confidential corporate information or preventing an eavesdropper from recording a network transaction. For example, the OpenSSH suite provides an encrypted secure shell that enables secure connections between systems either by users or by automated systems. For more information, see the OpenSSH Web site at:

http://www.openssh.org




	NOTE: The examples presented throughout this white paper are intended to provide one of many of the available options.

Integrity—Indicates the level of assurance that items have not succumbed to tampering and altering, except by users and processes explicitly given privileges. For example, GnuPG provides digital signature capabilities for items such as e-mail and files to detect tampering. For more information, see the GnuPG Web site at:

http://www.gnupg.org

Availability—Aims to reduce the risks of unreliable access to information and services. For example, network servers experience a denial-of-service (DoS) attack if their network paths are congested with malicious traffic, and successful system intrusion allows the attacker to shut down services at will. Often attacks send malformed requests to a service forcing the service to handle them inefficiently. For example, ModSecurity is an open source intrusion detection and prevention engine that examines HTTP requests before a system can fully examine them. In this way, ModSecurity can filter out bad traffic that would otherwise deny service availability from legitimate requests. For more information, see the ModSecurity Web site at:

http://www.modsecurity.org

Accountability—Concerns providing reliable identification of users and agents. Accountability is associated with non-repudiation, authentication, and authorization, and it fits under the broader topic of identity management. For example, connections to and from a database server might require encrypted communication channels since database tables should remain unaltered except by those users and processes explicitly given administration privileges. Passwords alone are weak authentication, but the added use of encrypted credentials on a smart card provides strong authentication.

OpenSSL provides OSMS with encrypted network connections and manages eavesdropping risk for a secure Web transaction. For more information, see the OpenSSL Web site at:

http://www.openssl.org

Though it is not strictly a security tool, OpenLDAP can be used to implement the backend for the management of user information. Each user provides identifying credentials to the access control system, and in return, the system grants privileges based on who the user is or what work the user does. Both JBoss and Apache can rely upon OpenLDAP as a directory service repository, storing information about users for access control.

http://www.openldap.org

Using a load-balancing configuration, OSMS Blueprints can be used to gain high-availability properties that also provide resilience against DoS attacks.

Malicious attacks involve all four areas of concerns. As soon as a malicious intruder gains control of a system, the intruder can affect any part of the system at will. Data can be intentionally lost, corrupted, or shared. Intruders can shut down services, and can even cover their tracks in system logs. By strengthening a system's ability to resist attacks, you can lower a wide range of security risks.

The Security Policy

Computer systems are expected to be secure, yet often these expectations are not stated explicitly. Security begins with a formal statement of expectations, which logically occurs before the implementation of any security measures. This formal statement, called a security policy, answers the following questions about a system:

What are attackers likely to pursue, what is of value, and what needs protection?
—For example, data or computer resources
What threats are present, and how likely is it that they will occur?
—For example, automated scripts, targeted attacks, or disgruntled insider sabotage
What are the consequences of a security breach?
—For example, loss of reputation, loss of sensitive data, or loss of resources

After developing the security policy, a security audit should be performed to measure security risks and to identify items of value that are at risk as defined by the policy. An audit review schedule should be defined and executed on a regular and ongoing basis. A security pseudo-formula, which generates a measure of security risk for each item, is as follows:

(Threat – Countermeasure) x Value ⇒ Risk

where:

Threat is the potential of a real interruption to a security concern.

Value is anything you do not want to be affected by the interruption of a security concern.

Risk is the potential of a security breach combined with the damage it would produce.

Countermeasures are processes, tools, and configurations that might reduce threats, thus lowering a risk so it is closer to your security policy guidelines.

Risk can have much more complicated representations than indicated by the simplified security pseudo-formula. However, this simplified formula allows you to compare an item’s risks level to that of the risk level allowed by the security policy.

Figure 2 shows the items of interest in this simplified formula. For a given item facing a threat without countermeasures to protect it, a risk exists only if the item is of value. Therefore, you do not need to protect unimportant items. The formula does not make sense if there are more countermeasures in place than there are threats, because then the risk is negative. This is the case for decoy systems, which contain no value but are used as bait to study attacks.

Figure 2 Risk Mitigation Process

What does securing OSMS mean? You must define what to secure, what threats it needs to withstand, and what safeguards will provide protection from these threats. Determining that an OSMS environment is secure means having confidence that the OSMS system will not succumb to a security breach in its operating environment, nor will it introduce unnecessary security risks to the system that contains it, as defined by a security policy.

For example, using a J2EE OSMS Blueprint on SLES9 is “secure” because doing so meets mandates within the security policy for providing sufficient protection for the information it serves and the threat environment in which it resides. This was achieved by hardening the host OS and configuring the blueprint securely. In addition, the J2EE system resides in a DMZ, to mitigate risks to other systems associated with opening necessary ports in the firewall for J2EE services. For more information regarding the blueprint in this example, see HP Open Source Middleware Stacks Blueprint: J2EE Application Server Based on HP ProLiant and BladeSystem x86_64 Servers and on Novell SUSE Linux Enterprise Server 9 Service Pack 3 at:

http://www.docs.hp.com/en/linuxsuse.html#Open%20Source%20Middleware%20Stacks%20%28OSMS%29

Steps for Securing Computer Systems

After creating a security policy, you can begin the task of applying the policy. Perform the following steps on an ongoing basis to ensure the security policy is applied throughout the life of the systems.

Identify:
Determine the required security level of each computer system, component, or service based on the item's importance (as specified in the security policy) and the degree of risk to which each item might be exposed in its deployed environment.
Protect:
Implement security measures to mitigate the risks identified in the first step. These security measures adjust the risk to an acceptable level, as described in the security policy. Test these measures to ensure they are operating as intended, and then adjust them as needed. Testing is particularly important after any changes to the system. Protection is not static, so the processes for securing a system changes over time. The goal is to uphold the security policy at all times.
Detect:
Ensure security policy breaches are detected by using tools and regular audits. Detecting a breach soon after it occurs can limit the damage it causes.
Respond:
Use knowledge gained through the entire process to strengthen security implementation and mitigate security policy breaches when then occur. Monitor changes to the threats a system might experience by implementing additional countermeasures.

Apply Best Practices

In general, security practices should follow these well-known principles:

Keep it simple:
Complicated systems provide more possibility for errors, which, in this context, means security risks. The need for simplicity touches most every aspect of security. The system design itself has the most obvious need for simplicity because complexity relates to errors. However, a simple administration tool, clear user instructions, and simple error messages are important too.
Do not “do it yourself”:
Contrary to the open source ideals, security is not a do-it-yourself project. Your newly created security application has more potential for flaws than one that passes a far-reaching examination. Insist on an exhaustive review of any security design.
Use well-known security techniques:
- Do not rely solely on clever hiding of important items, which is often referred to as "Security through Obscurity". For example, when an application call requires authentication, do not hide the password in a binary file or some other obscure location that you think is not obvious.
- The security of an algorithm should not depend on its secrecy. Relying on a hidden design for the security of an application represents a security hole. You are assuming that only the development team knows the ways to exploit the algorithm, and that know one else will discover what you know. For example, do not hide the house key under the doormat.

Follow the principle of least privilege:

This principle is to deny all privileges, except those that are explicitly allowed. In other words, deny access to users and processes first, and then grant privileges on a case-by-case basis only when needed, in accordance with the security policy.
Services that run under root privilege enable a compromised process to have authority over the entire system. Instead, create a user for each process and assign ownership of only the resources each user needs.
Do not forget to audit the access controls periodically and to revoke privileges when needed. The security policy defines a schedule of audit record review and when to take action.

One way to secure an Apache server, is to avoid using the root account. Rather, you should create a new user (often named www-data) account and ensure that it has only minimal access to the system and its functions. Permit access to the www-data account to only users with a genuine need and to as few users as possible. Then run Apache using www-data and if it is compromised, the attacker will not have root privileges.

Security tools do not mean security:

Having tools does not ensure security. What is important is what you build and configure with the tools, which might or might not be secure.
Tools might imply security. However, improperly configured tools or alerts that go unnoticed imply a false sense of security, which is worse than no security at all.

Do not assume that using OpenSSL automatically secures your communications. Using OpenSSL and failing to configure a chain of trust for the server certificates leaves a security hole. This hole allows an attacker to launch man-in-the-middle attacks with the same result as if the connection was not using OpenSSL.

Additionally, OpenSSL protects only the connection between computers; the information stored on the computers is still susceptible to attack.

Make it user-friendly:
Balance both the use and the security of a system. Understandably, security often seems to impede usability and users do not appreciate obtrusive security implementations. Elegantly implemented security measures avoid hindering users, while maintaining your security policy.
Never believe you are finished:
Security is an ever-changing domain. What you consider secure today might be insecure tomorrow. Advice in security papers such as this paper, becomes outdated with the release of new component versions or new attack vectors. Reliable security is a process that requires constant vigilance. Establish a set of policies and procedures to manage security needs over the life of the system.

Computer Security Review

Technical documentation

» Table of Contents

Background

Areas of Concern

The Security Policy

Steps for Securing Computer Systems