HP OSMS white paper: Security of Open Source Middleware Stacks

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
Computer Security Review 9