What needs to be done?
Before a driver heads out on the road, it is important for him or her to know the rules. Not just common sense stuff like “don’t drive on the wrong side of the road”, but the actual rules and laws that govern what you’re about to do, like obeying a speed limit. In the same way as a new driver getting behind the wheel needs to be well versed on those rules, there is no way for you as a DBA to responsibly, securely design or administer your Oracle database system if you don’t know what is expected of you. You need to know which software you are allowed to use and which you aren’t, which rules are applicable to you, where to find them, and how to interpret them. Some important questions to consider are:
- Will you be bound in your design decisions by laws or requirements particular to your location, the owner of the data, or the type of data you will be storing?
- Will your management understand that the rules may drive certain design or architecture decisions?
- Will your application developers understand that certain types of code libraries may not work in your regulatory framework, or that particular application features may be mandatory (or forbidden!) and not just nice to have?
So why is it so important for the DBA to have the answers to all of these? What I have found in my own experience to be often true is that the DBA is often the only person in the room with a “big-picture” technical view of what is going on. Developers are often focused on their code and on how pretty the user interface will be. System administrators are happy if the server is up and the disk partitions aren’t too full. Network administrators are happy if bandwidth is available. Management is happy when everyone else looks happy. I can say this because at one point or another in my career I have been each of these people. The DBA is often the only one who is concerned about how an application is coming together on a holistic level – security, performance, usability, availability, etc. – because the database is often the only place where all of those other concerns intersect. As such the DBA is often the only one paying much attention to the rules governing overall system security. It is critical therefore to be ready to raise concerns when necessary – with management – and be prepared to back them up with support from the appropriate legal sources.
How can I do that?
The short answer is to start reading. I can’t use this post to go into depth on every standard and guideline out there, but in the United States these are just a few of the most common ones that come up when designing data systems:
- The Fair Credit Reporting Act (“FCRA”) defines requirements for the collection, disclosure, and disposal of data collected by consumer reporting agencies.
- The Gramm-Leach-Bliley Act (“GLBA”) establishes data security requirements for “financial institutions”.
- The Children’s Online Privacy Protection Act (“COPPA”) requires covered website operators to maintain reasonable procedures to protect the personal information of children.
- The Health Insurance Portability and Accountability Act (“HIPAA”) requires health care providers to maintain security standards for protected health information.
- The Health Information Technology for Economic and Clinical Health (HITECH) Act strengthens penalties for HIPAA violations and extends HIPAA violation liability.
- The Federal Information Security Act of 2002 (FISMA) requires each federal agency to develop, document, and implement an agency-wide program to provide information security.
In general if you are administering a system that contains financial, health, or personal data of any kind, or if you are supporting a military system, one or more of these laws or regulations will apply directly to you.
“When you break the big laws, you do not get freedom; you do not even get anarchy. You get the small laws.” – G. K. Chesterton
There is often a trickle-down effect of these top-level laws as well. For example, most of my security-related experience is related to the military environment, which has a multitude of additional directives, instructions, and guidelines. The high level laws don’t lay down the nitty gritty details of how I should secure my database; rather, they designate people in federal agencies to be responsible for coming up with an information security plan with all the details that I need to know. So from that we get the following rules:
- The DODD 5144.02 directive establishes a DoD Chief Information Officer (CIO), responsible for cybersecurity.
- The DODI 8500.01 instruction from the CIO establishes a DoD cybersecurity program to protect and defend DoD information and information technology.
- The DODI 8510.01 instruction from the CIO establishes a risk management framework for DoD information and information technology as a part of the overall cybersecurity program. This rule specifically charges the Defense Information Systems Agency with creating guidelines called Secure Technical Implementation Guides (STIGs) for specific products to ensure a secure configuration.
- The DODI 5200.40 instruction defines the process by which DoD information systems are accredited and receive permission to operate on DoD networks, which includes a risk management review.
- The NIST SP 800-53 standard identifies the specific risk management controls for each information system that must be documented as part of the risk management review.
- The Oracle 11.2g Database STIG – Version 1, Release 1 lays out the specific do’s and don’ts (almost 300 of them!) for the actual Oracle database implementation to satisfy the NIST controls.
Within the STIG, the higher level rules and regulations are called out specifically:
DoD Instruction (DoDI) 8500.01 requires that “all IT that receives, processes, stores, displays, or transmits DoD information will be […] configured […] consistent with applicable DoD cybersecurity policies, standards, and architectures” and tasks that Defense Information Systems Agency (DISA) “develops and maintains control correlation identifiers (CCIs), security requirements guides (SRGs), security technical implementation guides (STIGs), and mobile code risk categories and usage guides that implement and are consistent with DoD cybersecurity policies, standards, architectures, security controls, and validation procedures, with the support of the NSA/CSS, using input from stakeholders, and using automation whenever possible.” This document is provided under the authority of DoDI 8500.01.”
Additionally, the DISA web site FAQ states the following, in regards to a STIG’s applicability to specific DoD systems:
“The most direct path to your answer appears in the DoD Directive 8500.1 as follows:
- The directive applies to all applications: Section 2 (Ability and Scope) Paragraph 2.1.2: All DoD-owned, or controlled information systems that receive, process, store, display, or transmit DoD information, regardless of mission assurance category, classification or sensitivity …
- The directive also states as policy: Section 4 (Policy) paragraph 4.1: IA requirements will be identified and included in the design, acquisition, installation, operation, upgrade, or replacement of all DOD information systems …
Section 4 (Policy) paragraph 4.13: All DoD information systems shall be certified and accredited in accordance with DoD instruction 5200.40 (reference (U)).
Section 4 (Policy) then goes on to address IA-enabled entities as a separate item.
Enclosure 2 (definitions) contains definitions for Application, DoD Information System, and other terms used in this document.
To summarize, the FSO and DISA consensus has always been that the 8500.1 directive applies to all DoD compute assets, unless specifically exempted (such as weapons systems for war fighters)…”
In other words, the STIG is the law of the land within DoD. The “implementation guides” are an integral part of system accreditation, and any deviation from the standard must be documented, justified, and approved by higher authorities if an information system is to receive its authority to operate on the network. In addition to the Database STIG, there are implementation guides for operating systems, web servers, application servers, network devices, desktop software, and even for the entire application development process. It all adds up to hundreds or even thousands of individual controls or requirements that have to be met for every information system in DoD.
How does that help?
So what does all of this have to do with cost-effective implementation? Designing, implementing and maintaining an information system is not cheap. Sure, hardware and software cost money, but more than that time is money. A little time spent getting to know the rules up front can save you a lot of time and trouble later on. How much time would be wasted if the people involved in design and implementation of an information system were ignorant of the rules by which they and the system are required to operate? What if an unfortunate design decision costs the team weeks or months of work because it turns out their plan won’t meet regulatory requirements? What happens if the system fails its accreditation process because it wasn’t properly put together? The entire program could be scrapped! Worse, what happens if a system is implemented without proper accreditation and something happens to the data for which you are responsible? Think those things never happen? Just look back to the HealthCare.gov rollout…
Depending on the environment you are working in, failure to comply with the appropriate laws and regulations could result in a data breach, compromised consumer or government data, the system being shut down, loss of jobs, massive fines, or even jail time! At the very least, thousands of dollars per man hour may be at stake for as long as it takes to correct the problem. So whatever industry you are supporting, get to know the rules for your road as soon as possible. Be aware of changes when they occur and how they might affect your system, and be ready to tell management the truth.
Unfortunately, my personal experience has been that because of my unique perspective I am often forced to play the devil’s advocate and remind people (especially management!) to do or not to do certain things. I have been called obstructionist, negative, and a giant pain in the a$$ more than once over the years. If you stick to your guns on the rules you probably will be too. But if you as the DBA do your job correctly and raise legitimate concerns, then management will have the best information available to make their decisions, and they won’t be able to claim ignorance down the road if something goes sideways. Management can always (and often does) make bad decisions regarding regulatory compliance, but that’s what they are there for – they get “paid the big bucks” to make the decisions and take the heat. If you don’t do your job correctly, and don’t pay attention to the rules, then it might not be management that takes the heat.