Getting Started With A Secure Configuration Effort
Hi, this is Chad Hughes again. In order to maintain a proper security posture, an organization must commit to developing and maintaining secure configurations on all layers of its environment. Such commitment may require the organization to reconsider commonly accepted assumptions, dispel security myths, or just �get back to the basics� of security.
For example, the �Chronology of Data Breaches� compiled by the Privacy Rights Clearinghouse includes a number of instances where the improper disclosure of sensitive information could have been prevented by common sense, or basic security policies and procedures. It is therefore not surprising that a recent Ponemon Institute survey sponsored by Oracle found that �42 % of IT practitioners believe their organizations can do more to prevent loss or theft of confidential information� and �Only 55 % of IT respondents believe they would be able to notify users and customers impacted by a data breach. Of course, these issues are not limited to businesses, but also impact government organizations as well. For example, a recent article on CSO Online related how the U.S. Department of Agriculture managed to expose thousands of social security numbers.
Incorrect technical assumptions can also be very damaging. For example, while many IT professionals may think that databases are usually sheltered within corporate firewalls, in his 2005 and most recent 2007 �Database Exposure Survey � research, David Litchfield found that many databases are directly exposed to the Internet. Unfortunately, generally innocuous search sites such as Google can be used to search for specific systems and services exposed to the Internet, and known vulnerabilities on those systems. See for example �Google Code Search peers into programs' flaws� on SecurityFocus or �Google Your Site For Security Vulnerabilities� on Security Devcenter. Michael Sutton's blog entry, �How Prevalent Are SQL Injection Vulnerabilities,� includes an example of a simple Google query intended to find databases exposed directly or indirectly to the Internet.
A myopic concern with external threats and hackers may also lead organizations on the wrong path by focusing the security effort exclusively towards securing the perimeter of the organization. For example, a quick glance at the web site of the Computer Crime & Intellectual Property Section of the United States Department of Justice shows that employees (both current and former) and contractors represent a significant portion of perpetrators. When hardening exercises are performed in production environments, far too often only the Internet-facing edge of production environments get the hardening treatment, creating a hard, crunchy shell, but leaving a soft, gooey center. The problem is that the hard crunchy shell often allows outside access to sensitive resources at the center to provide legitimate access to a set of services or applications. When hardening the center is neglected, leaving it soft and gooey, it may be vulnerable to attack through these holes intentionally left open in the hard, crunchy shell. As a result, it is not uncommon to witness situations where a compromised web applications server has resulted in the compromise of internal servers, sometimes even granting the attacker with privileged access on these machines. An unprotected center also may unnecessarily expose valuable resources to internal threats such as human error, disgruntled employees, and malware propagation.
Even when an organization understands the need to work on all layers of its production environment, often enough, the secure configuration effort is hampered by the belief that such effort will require a tremendous amount of resources. However, this is not necessarily true!
The effort of limiting the attack surface of the environment can yield significant security benefits. This is because, in complex applications, no one-size-fits-all configuration can possibly accommodate the needs of every customer. In most instances, customizing the installation to leave the proper balance of functionality is desirable to meet production and security objectives. Production systems that are left in their default state are likely to contain unused functionality that varies from customer to customer. Unused functionality in production environments needlessly increases the exposure surface, or total number of possible attack vectors. To reduce the exposure risk, customers can limit production system functionality to that which is required.
The greatest advantage of reducing surface area of production environments is that it contributes to significantly increasing the security posture of the organization at a relatively small cost. This is particularly true when hardening can be automated so the incremental cost to harden is low. Hardening production environments by reducing the attack surface is relatively inexpensive compared to many other defense in depth safeguards: it typically doesn�t require expenses for acquiring additional licenses or hardware; hardening effort can be incremental so as to not dramatically impact production environment, etc. Most importantly, the security return of a surface reduction effort is obvious -- if a defect is found in functionality you're not using, you're likely to be protected. And you're likely to be protected before patching, before upgrading, before employing a work-around...nothing additional is required. If a 0-day exploit happens to reside in unused functionality that was already disabled by a previous hardening exercise, you're protected.
For more information on Oracle�s Secure Configuration initiative, see my previous blog entry �Oracle�s Approach to Configuration Hardening.� Finally, the Oracle Software Security Assurance Resource Library includes valuable links to technical white papers and security checklists providing guidelines for reducing surface areas, or engaging in a more comprehensive hardening effort.
NOTE: Opinions expressed by the authors of the white papers and articles cited in this blog entry do not reflect the position of Oracle. Any advice, conclusion, or recommendations discussed on these sites (or sites they link to) are not validated by Oracle.
