Database Security Overview

Editor's Notes

• #2: Welcome Please mute cell phones Presentation overview Focus on how to become more engaged in with enterprise security planning. Goal is to establish a relationship with the security team to maximize the security of database systems We DO NOT address implementation specifics, more of a general model of how to maximize your engagement
• #3: A little about me Husband and father of 3 My professional focus has been on AppsDBA/core DBA, EBS supporting technologies, and security architecture Spend a great deal of time evaluating software and designing software portfolios to help clients make the most of the technologies they have invested in
• #6: As a DBA, why do we need to be “smart” on security? Consider your image of the typical security analyst Meticulous Binary solutions (pass/fail) Is this really how we view our databases? Can greater engagement help create more holistic security solutions? Consider how the push to move to the cloud changes security posturing Designed to expedite data access Security perimeter has essentially disappeared How do we protect our data???
• #7: With this in mind, what do DBAs need to know about Security? Get smart quick & prepare for continuous learning Realize that security truly boils down to CIA Not talking about the agency, talking about the security “triad” Confidentiality Integrity Availability These should already be familiar topics to a DBA Where is data at risk in the data lifecycle? How is data being accessed (URL, interface, batch loads, etc.)? What ports/protocols are used? Where does security get injected in the development lifecycle? How is CM leveraged by projects and how can it help ensure security?
• #8: I’ve posed a number of questions. How do you position yourself to provide valuable input in the process? Formal education is probably the most obvious. There’s a big time commitment here, but universities are increasing their flexibility on this front. Certifications – look impressive, can open doors, but ultimately provide a snapshot of your knowledge. (ISC)2 certs – gold standard, think OCM vs. OCP CSA – cloud security concepts, losing credibility now that CCSP is available. SANS – focus on specific security “execution” areas: PenTest, Ethical Hacking, Incident Response, etc. Oracle – Domain expertise in areas like database security or MAA. Check websites and make connections on social media, which we will delve into a little deeper now
• #9: What websites should you check frequently? Assuming everyone is on IOUG and ODTUG! Great content & webinars (12 months of 12c) Do yourself a favor & subscribe to Pythian’s blogs Keep an eye out for presentations too. Simon Pane did a phenomenal database security presentation at Collaborate 16. Oracle Security & OTN Great information to help you understand Oracle’s security offerings Don’t forget to check the Communities menu – Oracle on youtube has interviews with knowledgeable database security resources like Rob Lockhart SANS Certification may not be a “fit” for a DBA, but the site has a wealth of information across various security domains. Create an account & you can get newsletter emailed to you. CSA Great material on cloud-centric security requirements/issues (ISC)2 TONS of security information across all security domains Access Control; Bus. Continuity/DR; cryptography; governance/risk mgmt.; legal; opsec; physical sec; architecture/design; software dev sec; telco/network sec ISACA Audit/security management focused CYBRARY Online infosec training (some free) KREBS ON SECURITY Commentary and insight on security issues/trends
• #10: These are the most useful security-related handles I follow. I’ve grouped them to better discuss. Media Outlets – great information. Also tend to send info on upcoming webinars/conferences that you may not know about. Security Organizations – get the latest info from the major players in INFOSEC Consulting Services – News from SI’s/feet on the ground. People – INFOSEC superheros & DB security masterminds. Technology – tools/software to enhance security posture. Why EM? – think compliance & configuration management Delphix – game changer; data confidentiality isn’t only for production! OTN/Oracle Security/Oracle Database – self-explanatory IOUG – know what is going on in the user community MAA? – There’s the “A” in “CIA”
• #11: You have all this great information, so who do you share it with to develop a robust security plan? No different than any other requirements gathering process – the more people you engage, the more complete the requirement. Stewards – data owner. Who has ultimate responsibility for a specific type of data? Security folks – what are the latest trends & internal policies we need to adhere to? Architects – how is the solution being built? Network – data access points & data in-transit. Where is it vulnerable? Developers – secure design, don’t bolt-on. PMO/CM – how is security being integrated into our processes? Auditors – assuming you can get info out of them, how do you design for “continuous security improvement”? Remember – adversaries don’t focus on “check the box” security requirements. They are looking to exploit the boxes that haven’t even been created yet!
• #12: The rule of thumb is to always focus on CIA for your data. If you don’t, you may be trying to CYA later. Confidentiality will typically pertain to your security staff & data stewards. Working with a DBA the following questions should be considered: Sensitive data? Storage? Data lifecycle? User access to data?  architect/developers Cost of compromise?  PMO Integrity concerns go beyond the data steward & place greater emphasis on architects, network staff, developers, and security staff. Think about: Points of interception Points of data manipulation Does the application maintain data integrity – interfaces, data loads, data entry, etc.
• #13: Availability should be familiar to most of us & requires a great deal of PMO engagement to understand how downtime impacts the business. Focus on SLA requirements for uptime Work with leaders to truly understand what costs are associated with downtime? Based on that, how long can we afford to be down? This will enable an architect to design an architecture that fits with the downtime requirements. Are there any pre-existing requirements that need to be met? Think about system baselines required to operate in production. Things like O/S and/or database hardening. Are these requirements understood by all impacted parties? DISA Security Technical Implementation Guides are the perfect example of requirements that can be interpreted in various ways.
• #14: Here’s a prime example of how vague some requirements can be. Read the long name Anyone have a magic 8-ball? How are we defining “secure”? How does the definition of “secure” change based on DoD, vendor, or commercially accepted practices? Who determines where this will be applicable?
• #15: DISA STIGs are a wonderful example of cryptic requirements. They introduce variability which, in turn introduces RISK. How do we mitigate this? Communication, communication, communication. Ensure everyone speaks a common language – very likely that “secure” means very different things to a business analyst vs. an architect vs. developer vs. security officer. Example of Pat & Chris – would occasionally use Afrikaans terms in conversation. Left everyone clueless except them. Always comical to see who would question them vs. try to figure out the context. Don’t try to figure out the context – simply put, QUESTION EVERYTHING! There is always the possibility of an audit finding, or worse a breach. You may be called on to explain why something was done (or not done). Responding with “I thought…” or “it was my understanding…” does not help you. If someone pushes your bellybutton about a security finding, you MUST be able to back up your decision with clear, concise facts.
• #16: You have a team, you speak a common language, and your asking questions. YAY US! Not quite – understanding a security requirement is one thing, assessing the impact this change could have is quite different. The last thing you want to do is make security configuration a check the box activity. This approach creates its own issues: You are only “secure” for a point in time Malicious actors are looking “between” the boxes. They tend exploit what you haven’t taken care of yet. As an example – a common security practice is to revoke rights to SYS objects from PUBLIC. That’s a very easy task. **CHECK Done!** What happens to interfaces, diagnostic utilities, or patches/upgrades as a result of this update? High probability something will end up broken. How do you prevent this? Get a handle on what schemas call these objects and grants access explicitly. Consider what the results of an update will be. Here’s a great example – limbs off tree; cutting at height to keep from falling on house; someone supporting the ladder. *thumbs up* good to go! Not quite…
• #17: You have a strong team, generating great requirements, considering downstream impact of the requirements… Now we all enter the cage and see who comes out on top. But WAIT! There is a much more peaceful approach. Consider what industry you support and look for guidelines to determine what should be critical. For Federal agencies this typically revolves around STIG compliance. CAT I findings, not good. You may be able to squeak some CAT II findings through (depending on the auditors), but a mitigation plan & timeline will be critical. Commercial entities don’t seem to have such a standardized approach. You’ll have guidelines concerning how you should handle PII, PHI and PCI, but there are no “teeth” for enforcement. Recent breaches are changing oversight on this, so time will tell. Here’s some examples where companies fell short: OPM – PII compromise. Didn’t even know it happened until a vendor discovered it! VA – Multiple PHI compromises. Yahoo! – 500 million accounts compromised. Stock price hit, executive compensation impacted, value of sale to Verizon cut by $350M! VTech/CloudPets – database exposed to Internet unprotected. Impact still being assessed. DNC Breach – Social engineering/phishing attack. AWS S3 failures – where’s the “A” of CIA??? Turns out it was a process error!
• #18: I’ve talked to you about a number of different things: Where to gain knowledge Who to work with How to identify and prioritize requirements Making sense of the information you have Thinking about the net effect of security changes So, the stream of consciousness would be Identify requirements/risks Prioritize them Determine a mitigation plan for them Determine the level of effort for a given mitigation plan Identify the costs associated with implementing a given mitigation plan Let’s walk through a some simple examples.
• #19: Remember – there’s always more than one way to skin a cat. Think, listen, question, understand. It will take every resources in your “security village” to make a definitive plan that EVERYONE has a vested interest in. The biggest mistake you can make is trying to be a macho man. Speak to the village people frequently so the team can make informed decisions!
• #20: I appreciate you taking the time and hope you enjoy the rest of the conference. Any questions?