Password Management
Oracle has included its own authentication and password
management system since the very beginning. At first, the system was barebones.
Each user got a password; the password was assigned and set by the DBA. Users
had no means to change their own password, and Oracle had no automated controls
for password management. Passwords never expired, never needed to be changed,
and could be as simple or as complex as the DBA chose. Initially, the problem
with this system was password distribution. Since the DBA had to set each
users password, they would also have to distribute the password to each user.
This could be a challenge in a large organization with dozens or even hundreds
of database users. Hand written notes, phone calls, and personal visits were
commonly used to distribute the passwords, but that took time and users had to
wait their turn to get their new password before being allowed into the
database. At the time, it was not entirely uncommon for a DBA to simply give
each user the same password. This made it easy to distribute the passwords, but
created new security nightmares. Anyone with access could essentially log in
with anybody elses account and privilege level. Things needed to change.
Before long, Oracle gave users the ability to alter their own
password. This was a big improvement. The distribution problem was almost
solved. DBAs still needed to set each users initial password, and the same
problems apply to distributing those initial passwords. However, the scope of
the issue was drastically reduced. DBAs would instruct each user to change
their initial password the first time they logged in to the database. They
could even use the auditing system to ensure that a password change had been
made. However, Oracles password controls were still well behind those offered
by the popular OSes of the time, which started to become a legitimate concern
when Oracle databases began to accept connections from across the network.
Profiles
True password management features were first offered in the
database in Oracle8, with a system called Profiles. Profiles provide a means
for setting controls on passwords, and then applying those controls to users in
groups (in a manner very similar to how roles allow permissions to be managed
in groups). DBAs could create custom profiles for each group of users, with
controls tailored to each groups needs. A DEFAULT profile was provided as a
catchall. Any users not explicitly assigned to a profile would be assigned the
DEFAULT profile, ensuring that the password management features apply to
everyone. This profile system remains in use today and has been largely
unchanged since its initial release. Oracle now had password management on par
with most operating systems.
FAILED_LOGIN_ATTEMPTS This feature, often referred to as account
lockout, is designed to effectively thwart any password guessing attempts
against the database. Without this control in place, an attacker can literally
spend eternity attempting to break into Oracle by repeatedly guessing passwords
and attempting to log in. No matter how strong or complex the passwords, given
enough time, an attacker could brute-force the system and gain access. The
account lockout feature prevents this attack by enforcing a threshold of failed
login attempts before an account is disabled or locked, meaning it is no longer
permitted access to the database, even if the correct password is supplied. By
setting this parameter to a reasonable value, 5 for example, DBAs can ensure
that brute-force password-guessing attempts will almost always fail, while
giving users a few opportunities to make a mistake typing in their password
before their account is locked. Once an account has been locked, a DBA must
manually unlock it, unless the database is configured to do so automatically.
PASSWORD_LIFE_TIME
Even the strongest passwords need to be
changed periodically, and relying on the DBA to remember when that time comes
for each user leaves a big opportunity for forgetfulness. The
PASSWORD_LIFE_TIME setting enforces password changes automatically after the
lifetime, set in number of days, has expired. Once a users password life time
has passed, the database forces the user to change their password on the next
login, denying access to the database until the password has been changed. Alternately,
a DBA can set a grace period after a users password has expired, during which
the password will still work to gain access to the database. However, a warning
message will be displayed, informing the user that their password has expired
and must be changed soon.
PASSWORD_REUSE_TIME
In order to prevent users from trying to
trick the password management system into letting them keep their existing
password once it has expired, Oracle tracks password history and can enforce a
minimum length of time before a password can be reused. Without this feature,
when a users password expires, they could easily change the password to some
new value, allowing the database to log them in, then change the password right
back to the old value. The password reuse time setting enforces a number of
days before a password can be reused. This value can be set to UNLIMITED to
ensure that a user can never use the same password twice.
PASSWORD_REUSE_MAX
Similar to PASSWORD_REUSE_TIME, the
reuse max value controls how many times a user can reuse the same password
before it is permanently banned.
PASSWORD_LOCK_TIME
As mentioned earlier, Oracle can be
configured to automatically unlock accounts that were locked by the
FAILED_LOGIN_ATTEMPTS control. The password lock time controls if and when
those accounts are automatically unlocked. This parameter is configured with a
number of days for automatic unlock, or set to UNLIMITED to force the DBA to
unlock accounts manually.
PASSWORD_GRACE_TIME:
Once a users password life time has expired, they may be given a grace period
during which they are asked, but not forced, to change their password. The
duration of this grace period is controlled by the PASSWORD_GRACE_TIME parameter,
set in days. Once the grace period has expired, a user must change their
password in order to successfully log in to the database.
PASSWORD_VERIFY_FUNCTION
Probably the most powerful and flexible
of all password management features is the PASSWORD_VERIFY_FUNCTION. This
setting points Oracle to a user-defined function, typically written in C, that
can enforce any complexity rules desired on a new password. Want to enforce a
minimum length? Require users to include a digit? Special character? The password
verify function can be as simple or complex as desired, the only limitation is
your programming ability. Oracle comes with a default password verify function
which enforces several controls. We will cover the password verify function in
detail in Chapter 8.
Data Compartmentalization
In the database world, compartmentalization of data is
something that is uniquely offered by Oracle. The concept involves classifying
data elements, and then controlling access to those elements based on the
classification and a users access or security level. By assigning a security
level and compartment to each row of data in the database, access can be
tightly controlled on a row-by-row basis, even when permissions have been
granted on the entire table. When queries are issued, the system compares the
security level and compartments on the data being accessed with the security
authorizations of the user executing the query. Only the rows that match the
users authorizations are accessible, enforcing mandatory access control.
Trusted Oracle7
Data compartmentalization features first appeared in an add-on
product to Oracle7, called Trusted Oracle7, primarily driven by Oracles
clientele in the US
military. Based on the Bell-LaPadula security model, Trusted Oracle7 came
pre-configured with three security levels: Confidential,
Secret, and Top Secret. By combining these levels with a set of compartments,
say one for each project that uses the database, it was possible to create a
hierarchical set of controls that limited each user to accessing only the data
from their project(s) at their security level. At the top of the hierarchy,
users could see data from any compartment with any security level. At the
bottom, a user could be restricted to seeing only Confidential data (not Secret
or Top Secret) for their one compartment (or project).
Trusted Oracle7 offered some significant benefits, but came
with a significant amount of baggage, as the complexity of configuring and
implementing the system could be quite daunting, particularly in a system
hosting a dozen or more projects with millions of rows of data stored in the
database. The system was deployed in some military and even a few commercial
applications, but it was widely viewed as too burdensome and complex for broad
market acceptance. Even after enhancing the product to allow for the
utilization of user-defined roles to define compartments, the commercial world
continued not to accept the product, and eventually it was redesigned and
renamed.
The Bell-LaPadula
model was invented by David Elliot Bell and Len LaPadula in 1973, in an effort
to define a multi-level security policy for the US Department of Defense. The
model defines a set of security labels, ranging from Top Secret down to
Unclassified (or Public) that can be used to enforce controls on access to
data. Bell-LaPadula is defined as a state
machine with a clearly defined set of states and functions to transition
from one state to the next. When implemented properly, a system can be proven
to satisfy its security design requirements.
Beyond basic access
controls, Bell-LaPadula enforces two main rules, called the simple security property and the *-property. The simple security property
ensures that a user cannot read data that is classified above their security
level (no read up). This means that a user assigned the Secret classification
can read both Secret and Confidential data, but cannot read anything labeled
Top Secret. The *-property (read as star-policy) ensures that a user cannot
write data that is classified below their security level (no write down). A
user with the Secret classification can write Secret and Top Secret data, but
cannot input any data that is classified as Confidential. A modification to the
*-property, called the strong *-property
restricts users to writing data at their own level only, never above or below.
Virtual Private Database
While Trusted Oracle7 proved too rigid and difficult to
implement, it provided a feature that the market clearly desired: a mechanism
to allow multiple users within the same schema to see only the data that
applied to them. Consider an online retail system, where customers can log in
and view the status of their pending orders. Its likely that the orders for
all customers are stored in the same table and its important that each user
cannot view the orders that belong to others. Some means of access control is
required. Before the release of Virtual Private Database (VPD), organizations
generally implemented this access control in the application. A simple approach
was taken. Construct a query that includes a WHERE clause that ensures only the
current users data is returned. This works great until the user finds a way to
connect to the database directly, then all bets are off. Once connected
directly, there is nothing to limit the data that a user can see. If they have
rights on the Orders table, they have rights on all of the data in that table.
VPD was introduced to eliminate this concern and enforce security within the
database, so that no matter what application is used to connect, each user can
only see their data.
VPD uses a simple mechanism to enforce this access control. By
transparently appending a WHERE clause to every query a user runs, VPD can
effectively limit access to data by matching each user to a set of labels
stored with the data. Users are granted access to data with specified labels,
the VPD is configured, and then Oracle does the rest.
Oracle Label Security
With the release of Oracle8i came the new version of Trusted
Oracle7, now dubbed Oracle Label Security. Based on the same classification
levels as were used in Trusted Oracle7, Oracle Label Security was essentially a
pre-configured VPD for military applications. Oracle Label Security came with
several innovations, particularly around the capability to create custom
configurations with user-defined labels and compartments. The tool also came
with an intuitive graphical user interface (GUI) for configuration called
Oracle Policy Manager. The Policy Manager product allowed DBAs to set up
policies, define labels and their functions, and control user authorization.
Once the set up is complete, Oracle will create a VPD designed to enforce the
desired policies and authorizations.
Label Security can be applied at either the schema or
individual table level, offering complete flexibility. Most applications
require only a small percentage of the data they store to be secured by Label,
by allowing Label Security to be implemented on the few tables that require it.
Configuration and management of the database is vastly simplified over what was
offered in Trusted Oracle7. Organizations now had a set of powerful tools to
create a highly compartmentalized database, with effective access controls in
place to ensure that users can only access the data they need to get their job
done.
Oracle10g and Beyond
Oracle10g represents the state-of-the-art in database
security. With more effective security features packed into the product than
ever before, 10g and the upcoming Oracle11g offer an unprecedented level of
control over who can get into your database and what they can access while they
are there, while ensuring that an audit trail is kept that can log everything
that goes on. It is likely that Oracle databases offer more security features
than any other piece of software that has ever been created.
While this all sounds great, with all these features comes
tremendous complexity. Therein lies the problem. Complexity is bad for
security. The more features and options you have, the more potential for
misconfigurations. Even worse, the more complex the code, the more
opportunities there are for making mistakes, the kind of mistakes that can void
all of the fancy security features. Oracle is not immune to making coding
mistakes. In fact, so many vulnerabilities have been found that Oracle has been
forced to implement a quarterly patch release schedule, solely for fixing
security holes in their products. Each quarter, more devastating
vulnerabilities are announced and fixed, and with each release, more
researchers and hackers jump into the fray, finding more and more
vulnerabilities for the software giant to fix. Several of the vulnerabilities
found thus far have been extremely disastrous. In more than 10 cases,
vulnerabilities have been discovered that allow an unauthenticated user to
connect to the database and assume the role of SYSDBA, taking complete control
over the database and everything in it, regardless of the security features
that are enabled at the time. This is a fascinating dichotomy, as Oracle is
likely both the most secure and the most vulnerable database in existence
today.
The Regulatory Environment Driving Database Security
Over the last several years, things have changed dramatically
in the IT Security world. Data security has become a major focus area for both
government and industry regulations, real regulations with real consequences
for non-compliance. At the heart of any data security program must be a
database security program, as most of the worlds sensitive data spends 95+
percent of its time in a database, most commonly an Oracle database. We have
all heard of Sarbanes-Oxley (SOX) , the US Federal regulation enforcing strict
control financial reporting practices for publicly traded companies, but there
are a host of other regulations that govern data security in a similar way.
Financial institutions must comply with the Gramm-Leach-Bliley Financial
Services Modernization Act (GLBA), requiring protection of personally
identifiable information. Health care institutions must comply with the Health
Insurance Portability and Accountability Act (HIPAA), requiring protection of
patient health information. Retailers and credit card processors must comply
with the Payment Card Industry Data Security Standard (PCI-DSS), requiring
strong protection of cardholder information. US Federal government departments
must comply with the Federal Information Security Management Act (FISMA),
requiring proper safeguards to protect all sensitive data stored in Federal
systems. The list goes on and on, with a large backlog of pending legislation
dealing with data security currently working its way through both the state and
Federal legislation process.
The world of the DBA has permanently changed. While security in
the database was often ignored, or more commonly was left for the firewall and
network team to handle, todays regulatory environment has changed all that.
Inadequate security controls at the database level can now lead to fines,
penalties, loss of business, and in extreme cases even jail time. Organizations
are no longer left to their own devices to ensure the security of their
systems. Today, third-party audit firms police data security under the auspices
of auditing regulatory compliance. There is no longer a choice but to draft and
enforce an effective security program around protecting the confidentiality and
integrity of sensitive data. Database security has entered the limelight.
Lets examine some of the regulations that you are likely to
run into which mandate that you secure your databases.
The Sarbanes-Oxley Act
Sarbanes-Oxley (SOX) is probably the most widely known
regulation governing the protection of corporate data. Also known as the Public
Company Accounting Reform and Investor Protection Act of 2002, SOX requires
that all public companies implement effective internal controls around
financial reporting, and mandates review of those controls by independent
auditors. SOX was passed amidst a storm of corporate disclosure of illegal and
irresponsible accounting practices led by Enron, WorldCom, and Tyco. The fury
over re-establishing investor confidence was overwhelming, and when put to a
vote the bill passed in the Senate 99 to 0 and in the House 423 to 3.
SOX includes several requirements that directly relate to data
security, primarily focused around ensuring the integrity of financial
information that will be reported to the public. SOX makes corporate Chief
Executive Officers (CEOs) and Chief Financial Officers (CFOs) accountable for
the accuracy of financial reports, requiring them to provide personal certification
of each report released. Jail time is stipulated for those executives who
purposefully misstate financial performance. Computer systems that store,
process, and manage financial data are recognized as tightly coupled with the
overall financial reporting process, and are therefore required to be secured.
Typically, organizations implement strong access controls, auditing of access
to financial reporting systems, strict segregation of duties, and a thorough
vulnerability management process in order to comply with SOX and eliminate the
potential for a mistake or attack sending an executive off to the big house.
The Gramm-Leach-Bliley Act
The Gramm-Leach-Bliley Financial Services Modernization Act
(GLBA) passed in November 1999 in an effort to reform rules governing the
financial institutions. The bill repeals the Glass-Steagall Act, allowing banks
to offer investment, commercial banking, and insurance services. GLBA paved the
way for mega-mergers in the financial services industry, including the combination
of Citibank and Travelers Group, forming Citigroup, the largest financial
institution in America.
GLBA includes two key rules which govern the collection,
storage, protection, and disclosure of customers personal financial
information by financial institutions: the Financial
Privacy Rule and the Safeguards Rule. The Safeguards Rule mandates
financial institutions to develop and document an information security plan to
protect clients personal data stored within their systems. The plan must
include a process for performing risk analysis on existing systems and
controls, a process to monitor access to personal information, and a program to
test the effectiveness of the security controls in place. Since nearly all
personal data stored by financial institutions is kept within a database, GLBA
has direct implications on database security.
California Senate Bill 1386
Leading what has become a national charge, in 2003, California passed a bill
requiring companies to disclose any incident where the unencrypted personal
information was, or is, reasonably believed to have been acquired by an
unauthorized person. Since the bill passed, several other states have enacted
similar legislation, and it is only a matter of time before the Federal
government passes a breach disclose bill as well (at the time of this writing,
more than a dozen such Federal bills have been proposed).
The motivations behind California Senate Bill 1386 are clearly
stipulated in the text of the law; privacy and financial security are at risk
because of a significant increase in the incidences of identity theft. The bill
notes a 108 percent year over year increase in identify theft cases in Los Angeles County in 2000. Before the passage of
this bill, it was commonplace for organizations that experienced some kind of
breach to keep it a secret, not even reporting the theft to law enforcement.
Senate Bill 1386 changed all that, leading to what have become regular
disclosures of major data breaches that have made headlines embarrassing
companies and devastating consumer confidence. The threat of disclosure alone
has been enough to force many companies into establishing real programs for
data security, often grounded within the database infrastructure.
The Health Insurance Portability and Accountability Act
Passed in 1996, the Health Insurance Portability and
Accountability Act (HIPAA) is designed to protect workers and their families
from losing their health insurance when they change or lose their jobs. HIPAA
also establishes a set of Administrative Simplification provisions which serve
several functions including creating national standards for electronic health
care transactions and ensuring the security and privacy of Protected Health
Information (PHI). PHI is interpreted as any data about medical records or
health care payment history that can be linked to an individual.
HIPAA compliance requires that organizations implement
administrative, physical, and technical safeguards to ensure the protection of
PHI. Administrative safeguards are a documented set of procedures that
demonstrate the mechanisms by which an organization will comply with the act.
Physical safeguards are a set of controls designed to protect against an
unauthorized person gaining physical access to protected data (for example, by
taking a server or hard disk). Technical safeguards are access controls
intended to ensure that only authorized individuals can gain logical access in
order to view, modify, or delete protected data. This includes protecting data
at rest while stored in a database, as well as data in transit while traversing
the network.
The Payment Card Industry Data Security Standard
Before the Payment Card Industry issued their first Data
Security Standard (PCI-DSS) in January 2005, each one of the major credit card companies
had created their own set of standards for how their merchants, issuers, and
acquirers should protect cardholder information. Visa CISP, MasterCard SDP,
Discover DISC, Amex DSOPit was an alphabet soup of standards that were similar
to one another but never the same. For large merchants that accept each type of
card, compliance to the letter of each standard was nearly impossible. In an
effort to simplify compliance and achieve broad acceptance of a single,
well-considered set of standards, the PCI Security Standards Council was
founded by American Express, Discover, JCB, MasterCard, and Visa. This group
has worked together to produce two revisions of the PCI-DSS. The latest
version, 1.1, was approved in September 2006.
The PCI standard is significantly different than the government
standards we have covered so far. PCI-DSS provides specific details on what
steps must be taken in order to properly secure cardholder data. At the top
level there are six categories of controls that must be implemented:
- Build and Maintain a Secure Network
- Protect Cardholder Data
- Maintain a Vulnerability Management Program
- Implement Strong Access Control Measures
- Regularly Monitor and Test Networks
- Maintain an Information Security Policy
The PCI DSS is a multifaceted
security standard that includes requirements for security management, policies,
procedures, network architecture, software design, and other critical
protective measures. This comprehensive standard is intended to help
organizations proactively protect customer account data.
The Federal Information Security Management Act
The Federal Information Security Management Act (FISMA) was
enacted in 2002 as part of the E-Government Act, designed to modernize the
inner workings of the US Federal government. Before FISMA came along,
information security was largely neglected in the government, particularly by
the civilian agencies. The situation was clear; there was little motivation or
budget allocated to cyber security, so Congress intervened in an attempt to
make implementing security controls a mandatory responsibility of government IT
shops.
FISMA requires that
any information system used or operated by a US Federal agency, including those
run by contractors and others on behalf of the government, follow a set of
prescribed security processes. These processes are not defined within the FISMA
regulations, but rather FISMA makes reference to other pertinent standards and
legislation, including Federal Information Processing Standards (FIPS)
documents, National Institute of Standard and Technology (NIST) special
publications, HIPAA, and the Privacy Act of 1974.
FISMA mandates that
all Federal information systems be reviewed to determine the types of data
contained within the system, and then categorized based on the damage that
could be caused if the systems confidentiality, integrity, or availability
were to become compromised. There is significant debate as to the effectiveness
of FISMA; however, few will argue the fact that FISMA and its web of related standards
is extremely complex. Minimum security requirements for Federal agencies are
outlined in FIPS 200, which refers to security controls described in NIST SP
800-53 (Recommended Security Controls for Federal Information Systems). NIST
800-53 is further broken down into categories for various types of information
systems, and describes both operations and technical safeguards that must be
implemented for each. It should be no surprise that NIST has created documents
in the 800-53 series that directly address databases and database security.
Compliance with
FISMA is generally evaluated on a departmental level by the Office of the
Inspector General (OIG). This process is referred to as certification and
accreditation (C&A) and includes a review of the controls and processes in
place, and then signoff that the controls and processes meet Federal standards.
Typically, each system must pass the C&A process at least once every three
years or whenever a major change is made to the system, whichever comes first.