Oracle Security: The Big Picture - Page 2January 15, 2008 Password ManagementOracle 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 user’s 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 else’s 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 user’s 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, Oracle’s 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. ProfilesTrue 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 group’s 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.
Data CompartmentalizationIn 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 user’s 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 user’s authorizations are accessible, enforcing mandatory access control. Trusted Oracle7Data compartmentalization features first appeared in an add-on
product to Oracle7, called Trusted Oracle7, primarily driven by Oracle’s
clientele in the 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. Tip 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 DatabaseWhile 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. It’s likely that the orders for all customers are stored in the same table and it’s 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 user’s 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 SecurityWith 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 BeyondOracle10g 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 SecurityOver 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 world’s 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, today’s 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. Let’s examine some of the regulations that you are likely to run into which mandate that you secure your databases. The Sarbanes-Oxley ActSarbanes-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 ActThe 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 customer’s 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 client’s 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 1386Leading what has become a national charge, in 2003, 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 The Health Insurance Portability and Accountability ActPassed 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 StandardBefore 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 DSOP—it 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:
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 ActThe 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 system’s 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. |
|
|
The Network for Technology Professionals
Legal Notices, Licensing, Permissions, Privacy Policy.
Advertise | Newsletters | E-mail Offers
