HP OSMS white paper: Security of Open Source Middleware Stacks

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.
1. 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.
2. 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.
3. 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.
4. 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.
10