CIA: Confidentiality, Integrity & Availability
The goal of the security architecture is simply to protect the confidentiality, integrity and availability of the information system itself, the data within it and the security controls that protect it.
- Confidentiality – Information should only be disclosed to authorized systems or personnel. Common controls used to enforce confidentiality include encryption and role based access controls (RBAC). Examples of common breaches of confidentiality include: sharing passwords, shoulder-surfing, sniffing unprotected wireless networks and stolen laptops and/or removable media.
- Integrity – Protecting information from unauthorized changes. Common controls used to enforce integrity include enforcement of a least privilege access control model, regular job rotations and technical controls such as referential integrity, anti-virus software and Virtual Private Database (VPD). Examples of common breaches include: computer viruses and SQL Injection attacks.
- Availability – Ensuring the system, as well as the access, audit and other security controls that protect the system, are continuously available as per business requirements. Common controls used to enforce availability include redundant hardware and software, Oracle Real Application Clusters (RAC) and disaster recovery sites. Examples of common breaches of availability include Denial of Service (DoS) attacks and single points of hardware or software failure.
CPUs, CIA and CVSS
Since the October 2006 Critical Patch Update (CPU), Oracle has used the Common Vulnerability Scoring System (CVSS) to evaluate the impact of Oracle security vulnerabilities on CIA. It is strongly recommended that information technology organizations that use Oracle products analyze the quarterly Oracle CPUs, their associated CVSS scores and their own security controls in order to determine an appropriate patching strategy. For more information on CVSS see http://www.first.org/cvss/cvssguide.html and the CVSS calculator at http://nvd.nist.gov/cvss.cfm?calculator&version=2 .
Defense in Depth
Defense in depth has its origins in military strategy. Conventional military theory amassed troop concentrations along the front line of the battlefield but if the enemy broke through that line there were no other defenses available. A defense in depth strategy spreads forces out into successive lines of protection well before the front line of battle. The strategy also employs multiple technologies in anticipation of differing military attack strategies, for instance, interspersing anti-tank trenches to
stymie armored attacks or lines of barbed wire to slow infantry attacks. The strategy allows defensive troops to fall back in a controlled manner, thus slowing down the enemy and giving military commander’s time to determine the location of the attack and respond accordingly with additional military support.
Defensive strategies have matured within information security in a similar fashion. Originally, information security concentrated on protecting the perimeter, or edge, of your environment with firewalls and possibly Network Intrusion Detection Systems (NIDS) which was tantamount to putting all your defenses on the front line. Such a strategy is often called “crunchy on the outside, soft on the inside.” It has the same pitfalls as the similar military strategy in that once the perimeter is breached;
there are no other defenses available to protect your systems. It also provides no protection from security breaches INSIDE the firewall, and current published estimates report that inside attacks account for 70-90% of all incidents.
Within information security, defense in depth represents a layered approach to security by addressing the security posture of not only the technology stack but the operational and management controls within the system as well. A comprehensive list of controls can be found in the National Institute of Standards and Technology (NIST) “Recommended Security Controls for Federal Information Systems”, aka NIST 800-53: http://csrc.nist.gov/publications/nistpubs/800-53-Rev2/sp800-53-rev2-final.pdf.
We recommend at minimum the following technical controls within your system(s):
- Use firewalls to carve out, at minimum, three zones of protection:
- Demilitarized Zone or DMZ which will typically contain your proxy servers
- Intranet or trusted zone that will contain your application servers
- Database or restricted zone that will contain your database servers
- Use at least two different types of firewall technologies so that a breach of a single firewall does not compromise all the security zones
- Use separate network infrastructure (routers, switches, etc.) for internet-facing components in the DMZ from that used within your intranet
- Use a switched network to restrict traffic to point-to-point communicationeploy
- Deploy a Network Intrusion Detection System (NIDS)
- Deploy a Host Intrusion Detection System (HIDS) on all servers
- Centrally manage NIDS and HIDS, typically from a Security Operations Center or SOC which is responsible for security incident management
- Harden all components (network, servers, web servers, application servers and database servers) based on secure benchmarks such as those provided by the Center for Internet Security (CIS) at http://www.cisecurity.org
- Insure all inbound http traffic flows through a reverse proxy server and all outbound http traffic flows through a forward proxy server
- Use redundant servers at all tiers including RAC at the database tier
- Encrypt all end user web traffic, preferably with a hardware-based SSL accelerator, typically deployed at the load balancers in front of the web or reverse proxy servers.
- Use only Federal Information Processing Standard FIPS 140-2 certified cryptographic modules for encryption. A list of vendors using such modules can be found at http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/1401vend.htm. Note that if you do not see your vendor on the list that they might have licensed crypto-technology from a vendor already on the list. Contact your vendor to verify.
- Do not allow end-users to directly access the database. Such access should be available only through an application.
- Harden your database listener by turning on valid node checking and providing a list of invited nodes that is restricted to your application servers
- Avoid the use of DNS on servers where possible. DNS adds another attack vector when name resolution on servers can typically be handled by /etc/host files.
