HP OSMS white paper: Security of Open Source Middleware Stacks

• 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.
Essential Security
This section includes the following topics:
• “Known Versus Unknown Attacks ”
• “Keeping Systems Updated”
• “Making Configurations Secure”
• “Additional Best Practices”
Known Versus Unknown Attacks
Remember that security is really a measure of acceptable risk. Therefore, only a security policy can define
what is secure. Keep this point in mind when you are contemplating how to fix a security flaw in a software
package by implementing a security fix. Also, remember that the terms “secure” and “not secure” pertain
to the software packages that you are concerned with because of your security policy. Sometimes a particular
security issue is not relevant to a system based on the definition of risk in the security policy governing
the system.
Essential Security 11