At the end of January this year, Analyst Group Gartner warned on their web site that Oracle should no longer be considered a “Bastion of Security”. This highlights a common misconception in the Information Technology Industry that certain Vendors can be trusted to provide secure applications, while others cannot.

Vendors such as Microsoft have long been perceived as producing software that contains security flaws, while other vendors have received an (often unjustified) reputation for producing secure software.  Unfortunately, this can result in Systems Administrators focusing on addressing potential security issues with their Microsoft software, without applying the same rigour to software from other vendors who have acquired an unjustified reputation for producing secure software.

The Gartner report “Flaws Show Need to Update Oracle Product Management Policies” highlights the importance of patching and securing all applications. In the latest quarterly patch update (CPU), Oracle released fixes for 82 vulnerabilities, of which 37 related to flaws in Oracle Database products.

Unlike one of its cousin competitor databases, Microsoft SQL, Oracle has not yet received serious attention with regard to exploitation of significant vulnerabilities.  However, like most applications it is only a matter of time. As stated in the advisory posted by Gartner Analyst Rich Mogull, “the range and seriousness of the vulnerabilities patched in this update causes us great concern… Oracle has not yet experienced a mass security exploit, but this does not mean that one will never occur”

Oracle is just one example of the many applications that have long been considered secure without further configuration and management. Regularly organizations place heavy reliance on their border security (perimeter devices etc.) but leave internal applications un-patched or unsecured in the mistaken belief that they are secure due to their location deep within the organization.

When selecting applications for your organization, it is not only important to consider function and cost, but the support the Vendor will provide to you long after you have purchased the software. An increase in pressure from organizations (i.e. the customer) is the only way to convince application Vendors to place a higher focus on creating secure applications and constantly improving the security of their applications as well as reacting to security risks associated with their applications. (Case in point, Microsoft’s recent commitment to security after significant pressure and criticism from the Information Technology community).

However, no matter how committed the vendor may be to producing secure software applications, two points should always be borne in mind:

1. irrespective of the reputation of the software vendor, organizations should always assume that application software will have security vulnerabilities;
2. whilst rigorous patching and locking down of applications can significantly increase your levels of security, a "defence in depth" approach is required to guard against those scenarios where patching and locking down will not be effective..

Application Security – The Basics

No application should ever be left in its “out of the box” configuration after installation – not even a “secure” one. At Safecoms, we have conducted many penetration tests for our clients, and one of the most frequently recurring issues that we identify in the course of these tests is mis-configured applications that give away the keys to the kingdom.

Some of the most frightening examples we have seen have included applications - which by default allow full external access to business critical core infrastructure - configured with default passwords that any hacker will crack in a couple of seconds. These examples are not necessarily due to poor installation configuration, but due to the default installation activating these features with the Administrator being unaware that the feature has even been installed.

Before an application is placed in a production environment, or even before it is connected to a network, the application should be secured or “locked down”. At a minimum the following should be done:

• Only install components that are required. Most applications will allow you to install other components later if required.
• If it is not possible to control which components are installed, disable any that are not needed.
• Where possible, do not allow Microsoft Windows applications to run interactively. (the application is launched by the logged in user). This is very bad from an identity management perspective as it leads to shared passwords or a user locking out other users.
• Always create service accounts where possible, never allow an application to run with a user’s account.
• Lock down the account that an application runs as. Minimise user rights and file access.
• Never run an application as Administrator or Root.

In addition to locking down an application, patches also need to be applied. Unfortunately there are many occurrences where Administrators have attempted to update patching on their applications, but encounter difficulties due to limited availability of patches or practical problems associated with testing and implementing.  Effective patch management is one of the most difficult challenges in the information security world: in particular, how do you secure critical applications against zero day attacks, or attacks that occur before you can role out your patches?  This is where Defence in Depth comes into play.

The Importance of Defence in Depth

Taken from military defence strategy, Defence in Depth (also known as Elastic Defence) is based on the premise that multiple layers of security are stronger than a single layer. Traditional defence strategy would involve concentrating the majority of resources on border protection, which, if penetrated, would leave the inner resources outflanked and probably defeated. A parallel to this would be a company relying solely on its Firewalls or border devices to provide protection. A common comment often heard in this type of environment would be “ We don’t need to worry about hardening our servers or locking down our apps, the firewalls will protect us”.

The Defence in Depth strategy would involve concentrating resources at various points both at and behind the front line with the most valuable data concealed by multiple layers of protection. Although an attacker may breach the external layer of protection, as they advance they will encounter further resistance, to a point where the attacker themselves becomes vulnerable and the attack may stall.

In a well-designed network, as the attacker moves through the various layers of defence, they begin to leave a larger footprint, to the extent that they themselves become vulnerable. Once an attacker is identified they can then be blocked from the network or in some cases tracked and identified.

With the amount of attacks now originating internally and external attacks becoming more sophisticated, the importance of Defence in Depth has increased. A strong Border Security is of no use when the attack is from within or if your sole line of defence has been compromised. It is therefore becoming increasingly important to secure your organisation’s internal resources both internally and externally from both malicious and accidental damage.

Re-enforcing the Troops

Defence in Depth is not solely based on technology. When thinking of Defence in Depth, many IT practitioners think of multiple layers of firewalls. When well implemented, it is actually a combination of:

• Base Server Hardening with “Gold Standard” Templates (for more information see April 2005 Newsletter The Challenge of Hardening Windows Systems)
• Regular patching of Operating Systems and Applications on all devices within the network
• Application Hardening, including
• Restricting account user rights
• Removing Default accounts or re-setting default passwords
• Controlling permissions through Access Control Lists
• Removing unneeded services
• Encryption or protection of data in transit both internally and externally
• Securing Management Channels i.e. restricting use of Telnet and RCP for management.
• Implementing a strong firewall policy
• Implementing an Intrusion Detection System or other system monitoring tools to identify anomalies.
• Ensuring strong Policies, Procedures and Standards not only exist, but are being implemented.
• Implementing Physical Security to compliment IT Security.
• Reviewing the enterprise design for security weak points and implementing De-Militarised Zones (DMZ).
• Regular internal and external Penetration Test.

Defence in Depth should be viewed by your organization as an ongoing process beginning from system design. In essence, each of the above layers is an additional roadblock that requires defeat by an attacker.

By implementing a strong Defence in Depth strategy, many of the risks associated with Application and Operating System security can be minimised or mitigated.

If you need assistance with any of the above, Safecoms consultants offer a wealth of experience in designing Defence in Depth strategies specifically designed to meet the differing needs of different profile organizations.

Nick Gifford
Managing Director