Configuration

Objective

To produce applications which are secure out of the box.

Platforms Affected

All.

Relevant COBIT Topics

DS6 – Manage Changes – All sections should be reviewed

Best Practices

 Turn off all unnecessary features by default

 Ensure that all switches and configuration for every feature is configured initially to be
the safest possible choice

 Inspect the design to see if the less safe choices could be designed in another way. For
example, password reset systems are intrinsically unsound from a security point of view.
If you do not ship this component, your application’s users will be safer.

 Do not rely on optionally installed features in the base code

 Do not configure anything in preparation for an optionally deployable feature.

Default passwords

Applications often ship with well-known passwords. In a particularly excellent effort, NGS
Software determined that Oracle’s “Unbreakable” database server contained 168 default
passwords out of the box. Obviously, changing this many credentials every time an application
server is deployed it out of the question, nor should it be necessary.

How to identify if you are vulnerable

 Inspect the application’s manifest and ensure that no passwords are included in any form,
whether within the source files, compiled into the code, or as part of the configuration

 Inspect the application for usernames and passwords. Ensure that diagrams also do not
have any

How to protect yourself

  Do not ship the product with any configured accounts

 Do not hard code any backdoor accounts or special access mechanisms

Secure connection strings

Connection strings to the database are rarely encrypted. However, they allow a remote
attacker who has shell access to perform direct operations against the database or back end
systems, thus providing a leap point for total compromise.

How to identify if you are vulnerable

 Check your framework’s configuration file, registry settings, and any application based
configuration file (usually config.php, etc) for clear text connection strings to the
database.

How to protect yourself

 Sometimes, no password is just as good as a clear text password

 On the Win32 platform, use “TrustedConnection=yes”, and create the DSN with a stored
credential. The credential is stored as a LSA Secret, which is not perfect, but is better
than clear text passwords

 Develop a method to obfuscate the password in some form, such as “encrypting” the
name using the hostname or similar within code in a non-obvious way.

 Ask the database developer to provide a library which allows remote connections using a
password hash instead of a clear text credential.

Secure network transmission

By default, no unencrypted data should transit the network.

How to identify if you are vulnerable

 Use a packet capture tool, such as Ethereal and mirror a switch port near the database or
application servers.

 Sniff the traffic for a while and determine your exposure to an attacker performing this
exact same task

How to protect yourself

  Use SSL, SSH and other forms of encryption (such as encrypted database connections) to
prevent data from being intercepted or interfered with over the wire.

Encrypted data

Some information security policies and standards require the database on-disk data to be
encrypted. However, this is essentially useless if the database connection allows clear text access
to the data. What is more important is the obfuscation and one-way encryption of sensitive data.

How to identify if you are vulnerable

Highly protected applications:

 Is there a requirement to encrypt certain data?

 If so, is it “encrypted” in such a fashion that allows a database administrator to read it

without knowing the key?
If so, the “encryption” is useless and another approach is required

How to protect yourself

Highly protected applications and any application that has a requirement to encrypt data:

 Passwords should only be stored in a non-reversible format, such as SHA-256 or similar

 Sensitive data like credit cards should be carefully considered – do they have to be stored
at all? The PCI guidelines are very strict on the storage of credit card data. We
strongly recommend against it.

 Encrypted data should not have the key on the database server.

The last requirement requires the attacker to take control of two machines to bulk decrypt
data. The encryption key should be able to be changed on a regular basis, and the algorithm
should be sufficient to protect the data in a temporal timeframe. For example, there is no point in
using 40 bit DES today; data should be encrypted using AES-128 or better.

Database security

Data obtained from the user needs to be stored securely. In nearly every application,
insufficient care is taken to ensure that data cannot be obtained from the database itself.

How to identify if you are vulnerable

  Does the application connect to the database using low privilege users?

 Are there different database connection users for application administration and normal
user activities? If not, why not?

 Does the application make use of safer constructs, such as stored procedures which do
not require direct table access?

 Highly protected applications:

1. Is the database is on another host? Is that host locked down?

2. All patches deployed and latest database software in use?
3. Does the application connect to the database using an encrypted link? If not, is the
application server and database server in a restricted network with minimal other
hosts, particularly untrusted hosts like desktop workstations?

How to protect yourself

 The application should connect to the database using as low privilege user as is possible

 The application should connect to the database with different credentials for every trust
distinction (eg, user, read-only user, guest, administrators) and permissions applied to
those tables and databases to prevent unauthorized access and modification

 The application should prefer safer constructs, such as stored procedures which do not
require direct table access. Once all access is through stored procedures, access to the
tables should be revoked

 Highly protected applications:

1. The database should be on another host, which should be locked down with all
current patches deployed and latest database software in use.
2. The application should connect to the database using an encrypted link. If not, the
application server and database server must reside in a restricted network with
minimal other hosts.
3. Do not deploy the database server in the main office network.

Further Reading

 ITIL – Change Management http://www.itil.org.uk/