Oracle Database Security a technical primer alunite) See RE) fe ere R ec ET‘ED 77/477 SEWAGE © OOM D)—lUe NF ORACLE Foreword Having been in the security space for over 25 years, the front seat view has been exhilarating. Twenty-five years ago, ‘mostly governments and financial institutions were interested in security while everybody else trusted the administrators, users, and computing environment to keep their data secure. It was only when browsers opened up. new vistas for commerce over the net in the 90s that companies began to understand the vital need for security. This new perspective led to SSL, network firewalls, and strong cryptography. Fast forward to the present, and just like before, we find ourselves living in a dramatically different world where every piece of data is online and available 24/7. To address this new reality, we see many different security technologies protecting various layers of the IT stack, from the applications down to the chipsets. While the global security spend is, expected to exceed $195 billion in 2025, hacks are becoming bigger and bolder, impacting everything from customer and citizen databases to vaccine data and Wi-Fi routers. Hackers have built sophisticated tools along with a thriving underground market to go after everything we have, whether on mobile devices, laptops, file servers, or databases. For most hackers, the target of choice is not a laptop or a spreadsheet-the target is most often a database with hundreds of millions of records. The hackers may try to break in through attacks on the network, applications, operating systems, and databases. They primarily target the users who have legitimate access to thase systems. Sometimes, it's the insiders with deep knowledge of data and defenses who attack the systems for nefarious gains, Why are organizations so vulnerable to attacks? Many might say they don't know where their sensitive data is, where they are vulnerable, and what the fixes might be. They might also fear that the fixes may break their applications or ‘that the insiders may exploit the trust placed in them. Too many stop at securing the perimeter, not recognizing how easily hackers can bypass the network perimeter, get to the databases, and quietly walk away with their data. Itis not surprising that, on average, it takes the victims six months to even know that they have been breached, and it also isn't surprising that they typically learn about the breach from customers or law enforcement. Many information technology, database, and security leaders now realize that securing databases should be one of ‘their most important goals. After al, in most companies, itis their databases that contain most of the sensitive data assets. They also acknowledge that while they would never be able to block every path hackers might take, protecting databases serves their constituents well since every path eventually leads to one. During the last twenty years, 've seen a significant shift in how hackers go after databases. In response, Oracle has built multiple security technologies for securing data at the source-within the database. We have focused on all pillars of security: evaluating the risk posture, preventing the attacks, and detecting/alerting malicious behavior. Industry analysts and security professionals recognize that the Oracle Database provides the industry's most comprehensive security. This book, authored by my Database Security Product Management team, explains in simple terms the adversaries of today, how they exploit the weaknesses, and how they access your sensitive data. This book is not meant to be a prescriptive cookbook or a manual but rather a quick study into what every Database or Security Director/ VP should know about the security of Oracle databases. You will earn about multiple assessment, preventive, and detective security controls for databases so that you can provide high-level guidance to your teams on how to shrink the attack surface and keep your databases secure. Breaches are coming faster than we can imagine, and we must be prepared! Your data is your asset, but unless you protect it well, it could fall into the wrong hands and become a liability. Let's start by securing the source! Samar Senior Vice President, Oracle Database Security Development September 2023LA | IY, “EP 77/477 QEOASZR. &. ORACLE From the authors’ desk AAs security product managers, we often hear from customers grappling with the challenge of managing security risks while keeping their databases running 7 * 24. Some were tasked to address a specific compliance requirement or implement a specific security control, while others were asked to improve the security of their databases. Despite Oracle's comprehensive security portfolio, what became evident was the lack of a cohesive strategic approach to securing databases, What to protect? How? From whom? Recognizing that adversaries rarely adhere to a fixed attack pattern, we would advocate for a “defense in depth" mindset. Moreover, we observed that the responsibility for database security was dispersed across different roles within organizations. Some entrusted DBAs and application administrators with this duty, while others placed it in the hands of network and system security administrators who might not possess a deep understanding of database architecture or available tools. This book serves as a security roadmap within the context of the Oracle Database, catering to security officers, database owners, DBAs, application administrators, system administrators, and security teams. Instead of presenting a collection of product highlights, we opted for a threat-and-solution perspective. While this approach may lead to multiple mentions of specific products addressing various threats across chapters, in-depth product features are readily available on our website. ‘After reading this technical primer, we hope you'l gain insight into how the adversaries exploit the vulnerabilities, what database security controls are available to help you secure your databases, and what risks those controls. address. Please note that this ebook is not intended to replace product documentation or offer any regulatory advice. Since the intial publication of this book, its scope has expanded from sixty pages to approximately 180 pages. This, expansion mirrors the evolving threat landscape and regulatory environment, as well as the advancements in database security control and capabilities, We've added an executive summary to help navigate this comprehensive resource — perhaps the longest “executive summary” you've ever seen. We hope this book broadens your perspective on database security, equips you with actionable insights, and helps you secure your data ‘Angeline Dhanarani Bettina Schaeumer Rich Evans. Peter Wahl Hakim Loumi ‘Alan Williams Russ Lowenthal Nazia Zaidi Pedro Lopes Michael MesarosOAM EEA EWN ay “EP 77/477 QEOASZR. &. ORACLE Chapter One; Protecting data Protecting data is what this book is all about. Your Oracle databases hold a significant amount of data, much of it sensitive — intellectual property, personal data, financial information - the list goes on. Protecting that data may be your direct responsibility (perhaps you are the data owner, security administrator, or database administrator), or you ‘may simply be interested in how the data SHOULD be protected. This book takes you through the various aspects of Oracle's defense-in-depth security for databases. It provides a high-level overview of how the different controls work and the types of protection they provide. Chapter Two: Assess database security posture and risk Today's systems are complex, with many security configuration settings. As recent data breaches have demonstrated, itis critical to have properly configured and secure systems. Human errors could leave your database open to everyone, or an attacker could maliciously exploit configuration mistakes to gain unauthorized access to sensitive data, Falling to implement basic security controls may risk exposing customer data, including names, addresses, birth dates, account information, etc. This can have a devastating impact on both your reputation and bottom line. Therefore, you should regularly harden and scan your databases, remediating deviations from security best practices. Many regulations, such as EU GDPR, PCI DSS, Sarbanes-Oxley, and various breach notification laws, promote regular security assessments on the most critical systems, such as databases, to reduce IT risks. Multiple organizations, such as the Center for Internet Security (CIS) and the U.S. Department of Defense, have recommendations for security configuration best practices. It is critical to regularly assess database security posture, considering recommendations from different regulations, security frameworks, and vendor best practices. This chapter describes how Oracle database security solutions can help evaluate your database security posture quickly, categorize the findings, and recommend suitable action to develop a strategy to keep your databases secure. Chapter Three: Discovering sensitive data Before we can protect sensitive data, we have to know where it is. An important step to protect sensitive data is understanding what kind and how much sensitive data a database has and where itis located. This knowledge can be Used to implement appropriate security controls to protect data. This chapter introduces the essential elements of sensitive data discovery and gives you an overview of the Oracle ‘technologies that can be used to discover sensitive data. Chapter Four: Authenticating database users A fundamental step in securing a database system is validating the identity of the users accessing the database (authentication) and controlling the operations they can perform (authorization). This chapter discusses how a proper authentication strategy helps protect the users of databases and the data within. from attackers. It also explains how to manage the user accounts, whether locally within the database or with centralized external services, such as a directory service or a cloud identity provider. Chapter Five: Controlling database accessLA | IY, “EP 77/477 QEOASZR. &. ORACLE In addition to validating the identity of users accessing the database (authentication) discussed in the prior chapter, another fundamental step to secure the database is controlling what operations the users can perform (authorization) This chapter discusses how a robust authorization strategy helps protect the database from mistakes, misuse, and attackers. It also explains how to manage the user account authorizations, whether locally within the database or with centralized directory or identity services. Chapter Six: Enforcing separation of duties Cybersecurity and regulatory concerns drive the use of strong security controls for accounts used by insiders and privileged administrative users. Stealing sensitive data using compromised privileged user accounts is the most common attack vector for database breaches. This chapter discusses how you can minimize the losses from compromised accounts by implementing separation of duties and least privilege. While a single administrator may want to perform multiple functions for convenience, the ability to divide these duties among multiple users and understand exactly which privileges are in use can dramatically improve security. Chapter Seven: Minimize risk from SOL Injection SQL injection is one of the oldest and most frequently encountered database attack methods. Despite years of education and training to solve the problem, it continues to plague data-driven web applications. This chapter discusses the two main approaches to mitigate the risk of SOL Injection: Network-based Database Firewall or built-in SQL Firewall. We will review the differences between the two approaches and suggest strategies for selecting the approach that best fits your needs. Chapter Eight: Data-driven application authorization There are times when your application needs to control access to individual rows of data. Bullding those controls into the application can be costly because changes to the security model also requires changes to the application code. Centrally enforcing fine-grained data access for application users within the database saves you time and effort and can dramatically increase security. Since the database enforces data access policies centrally, those policies are applied equally to alltoots and applications that access the data, This chapter discusses how applications can handle the problem of fine-grained authorization without coding these rules within the application. Chapter Nine: Masking sensitive data Most organizations create copies of their production databases for use in application test and development. These non-production copies also may be used for training or user acceptance testing, Each new copy of a production database increases the risk that data within those databases will be compromised. Data Masking helps mitigate that risk, Data masking hides sensitive data by replacing the original data with realistic-looking but fake data, Data masking ‘may be “static” ~ where the stored data is modified, or “dynamic” - where only the presentation of the data to users is, altered to hide the original data. This chapter discusses how Static data masking can remove sensitive data from non-production environments like test and development, as well as cases where the database is used for training. It further describes how dynamic dataOAM EEA EWN ay “EP 77/477 QEOASZR. &. ORACLE ‘masking prevents the proliferation of sensitive data to users through various fine-grained access control mechanisms. These tools are integral to a comprehensive data privacy strategy, helping you effectively meet compliance requirements such as PCI-DSS and EU-GDPR, Chapter Ten: Data encryption and key management Encryption is the best technique for protecting against database bypass attacks where an attacker attempts to steal data without ever logging into the database. This could be by capturing data in motion aver the network, accessing the underlying files of the database through the operating system, or stealing database backups or exports. This chapter explains how encryption protects data in motion and at rest for the database. It also discusses considerations for securely storing and managing the encryption keys that ultimately protect the encrypted data, Chapter Eleven: Database auditing It's important to monitor database activity to support incident investigation, detect potentially malicious behavior, and fulfil regulatory requirements. This can be done either through database auditing or monitoring network events. This chapter helps you evaluate the pros and cons of these approaches and discusses Oracle's solutions for these approaches. Database auditing provides the most accurate record of database activity. Auditing has a broader contextual view of user activity than database activity monitoring techniques like network-based monitoring. One challenge with network-based monitoring is that direct local logins, recursive SOL, dynamic SQL, or stored procedures ‘may circumvent the monitoring, Chapter Twelve: Database auditing - reporting and alerts Database auditing provides the most accurate record of database activity, but you need to centralize the audit data, analyze it, and create associated reports and alerts. This chapter describes multiple approaches to solve this problem depending upon your requirements: cloud service oF a dedicated on-premises solution. In both cases, you get a central auait collection across your target databases, providing 2 broad list of audit reports with exible fiter capabilities to fulfil your requirements and alert capabilities to notify you of specific user activities or unusual behavicr. Chapter Thirteen: Ransomware and Zero Trust Today, most security conversations are driven by one of these topics: Regulatory compliance, Data breaches, Ransomware, and Zero-trust In this book , so far, we have been discussing mainly data breaches and regulatory compliance. In this chapter, we'll discuss the last two - ransomware and zero-trust - from the standpoint of Oracle Database. We'll open with a tactical approach to dealing with ransomware and close with a strategic approach to improving zero trust. Chapter Fourteen: Database security in the multicloud world Many organizations work with multiple cloud providers to avoid vendor lock-in, improve redundancy, optimize performance, cost, and services, and compliance with data sovereignty. By leveraging the strengths of multiple cloud providers, you can tailor your cloud environments to meet your specific requirements and maximize the benefits ofae ORACLE cloud computing. Multicloud strategies lead to scenarios where one cloud manages identity, another manages applications, the third has security tools, and yet another contains the data, This chapter reviews the security and management of Oracle Database in a multicloud environment. Chapter Fifteen: Securing the Autonomous Database The Oracle Autonomous Database provides standardized, hardened security configurations that reduce the time and ‘money managing configurations across your databases. Security patches and updates are applied automatically, so you don't spend time keeping security up to date. These capabilities protect your databases and data from costly and potentially disastrous security vulnerabilities and breaches. Oracle Autonomous Database automatically encrypts your data at rest and in motion, using industry-standard cryptographic solutions while also providing you with the tools you need to further restrict or isolate sensitive data from privileged users, developers, data analysts, and application administrators. But there are some things the Autonomous Database cannot do for you. It has no way to know if the users you grant access to the database are behaving in accordance with your organization's policies. Nor does the database know what type of sensitive data you may have added to the database, That is why it's so important you read this chapter to understand how security responsibilities are shared between you and your database operations team and why you need to know what tools are at your disposal to help you control risk and better secure your system.> BW 77/47/77 EWA ©] 2 ORACLE Table of Contents Foreword . From the authors’ desk. Protecting data Introduction nnn Data is the new currency 14 The need to protect data has never been greater. Threat actors and the “Dirty Dozen”, Addressing the Dirty Dozen through data security controls. Assess database security posture and risk. Introduction Evaluate and assess database configuration Assessing configuration security of the Oracle Database with DBSAT. zB Assessing your database fleet using Oracle Data Safe 26 Assessment with Oracle Audit Vault and Database Firewall (AVDF). Configuration Assessment with Enterprise Manager... Choosing the right database security assessment tool Reducing the blast radius with Privilege Analysis, Security patch management... Oracle LiveLabs.. SUMMARY sensors Discovering sensitive data Introduction Why is sensitive data important?.. Discovering sensitive dat Discovering sensitive data using DBSAT Discovering sensitive data using Data Safe Discovering sensitive data using Audit Vault and Database Firewall Discovering sensitive data using Enterprise Manager Oracle LiveLabs... 46 Summary.ORACLE Authenticating database users. 48 Introduction AD Users: Your weakest link.. Database authentication methods. Making users resistant to attacks. Protecting your users from getting hacked Oracle LiveLabs Summary. Controlling database access Introduction Types of database users... 57 LA Privileges... Roles. Who can do what in your database? Managing users centrally Protecting database accounts. Oracle LiveLabs Summary... Enforcing separation of duties Introduction nnn 65 Controlling powerful administrators. Control privileged users with Oracle Database Vault... Enforce separation of duties with Oracle Database Vault Control SQL database commands with Oracle Database Vault Operationalizing Oracle Database Vault. Oracle LIVELADS nen 70 Summary. 70 Minimize risk from SQL Injection. IntrodUction wns RQ SQL injection overview. Approaches to address SQL injection attacks. Network-based Database Firewall Database-resident SQL Firewall ‘EP 70/4727 7 EOWA & © 7ORACLE Deciding which to use: Database Firewall or SQL Firewall. 77 Oracle LiveLabs for hands-on experience .. 78 wT len SS SSSA SSS Data-driven application authorization... 79 Introduction Data-Driven, fine-grained authorization Challenges with implementing data authorization in applications. Controlling data access using Virtual Private Databas Controlling data access using data label Controlling data access using Real Application Security. 85 Which data-driven access control should | use?. LA Oracle LiVELAbS wr nnnennn 87 Summary. Masking sensitive data... Introduction Why mask Data?, Use cases for data masking Static data maskin, Dynamic data masking... a” Data subsetting.. Masking formats. Masking techniques.. Masking sensitive data using Oracle Data Safe Masking sensitive data using Oracle Data Masking and Subsetting.. Differences between Data Masking and Subsetting & Data Safe. Masking data dynamicall Oracle Data Redaction nine 98 Data Subsettin Oracle LiveLabs... Summary. Data encryption and key management... Introduction Why encrypt?.. ‘EP 70/4727 7 EOWA & © 7ORACLE Encrypting data in motion - database connections Encrypting data at rest - database files and backups.. Transparent Data Encryption wnnnnnmnnnnnninnnnnnennnn Key Management. Centralized key management with Oracle Key Vault... Oracle LiveLabs Summary. Database auditing .. Introduction Why audit? enone Oracle Database with unified auditing o> Effective database auditing 17 Audit policy provisioning from Data Safe or AVDI Transition from traditional to unified auditing. Oracle LiveLab: Summary. Database auditing - reporting and alerts... Introduction Auditing with Oracle Data Safe 123 Auditing with Audit Vault and Database Firewall (AVDF) Oracle LiveLabs... Summary. Ransomware and Zero Trust. Introduction Zero Trust. Applying Zero Trust to the database. 137 Oracle LiveLab: Database security in the multicloud.. IntrodUction wenn 143 Why multicloud? 143 Identity cloud service Managing security across clouds Managing resources in multiple cloud: ‘EP 70/4727 7 EOWA & © 7 gsORACLE Multicloud service access. Multicloud identity management for Oracle Database. Oracle LiveLabs for multicloud integration v.nsnm:mnsns Summary. Securing the Autonomous Database. Introduction Why Autonomous Database?. The security benefits of Autonomous Databases. The security capabilities of Autonomous Databases ... Shared responsibility Oracle LiveLabs.. Summary Putting it all Together... About the authors y Acknowledgments. i i aORACLE Chapter One Protecting datai ORACLE Introduction Protecting data is what this book is ll about. Your Oracle databases hold a significant amount of data, much of it sensitive — intellectual property, personel data, financial information ~ thelist goes on. Protecting that data may be your direct responsibilty (perhaps you are the data over, security administrator, or database administrator, or you ‘may simply be interested in how the data SHOULD be protected. This book takes you through the various aspects of Oracle's defense-in-depth security for databases and provides a high-level overview of how the different controls ‘work and the types of protection they provide. Data is the new currency Organizations worldwide are experiencing the impact of data breaches at an unprecedented rate. It seems like every day brings a news story about a service provider losing subscribers’ personal information, an employer losing employee HR records, or a government contractor losing sensitive intellectual property. Data is the new currency, and bad actors can often leverage stolen data for financial or political advantage for years after a breach. SSNay : : Healthtare Information FINEErprnt ....ny Street UsernamePayment Card Information. Credit Card Number se2terestmasae spent INOCiIaenship Passport Number Race Postal Code Employee kenticaton Number Linked Personally Identifiable Informationsaiay| QCation ~-Personally Identifiable Information: “CountryFinancial Information &«*Date of Birtheose": Password....!"'3 City iisPersonal Identification Numbers Person's Name aeanmere Detar pone Nuwar Place of Birth aes Figure 1-1: Personal Data And where do they keep their sensitive data? At the end of the day, this data is stored and managed mostly in databases. Perimeter security solutions such as network firewalls were once considered sufficient for protecting internal systems and repositories such as databases from data theft. However, the threat environment for organizations has changed considerably in recent years. Tools vary widely depending upon the attackers, from exploiting unpatched systems to very advanced methods where hackers penetrate a network, search for vulnerabilities, and then covertly exfitrate data from servers, These attacks can go undetected for weeks, months, or even years. The need to protect data has never been greater You operate in an increasingly stringent and fast-evolving regulatory landscape. The United States has more than 20 national privacy and data security laws, with other laws enacted at the state level. The European Union (EU) harmonized data privacy laws across multiple member states with the General Data Protection Regulation (EU GDPR), and in the years since GDPR became law, over 150 countries have enacted similar privacy regulations.ORACLE With most privacy regulations, data breaches can lead to fines. For example, under GDPR, a violation can incur penalties of up to four percent of a company’s global annual turnover or €20 million, whichever is greater. In the past five years, GDPR fines alone totaled more than €45 Billion (USD 4.8 Billion). In addition to the stringent regulatory environment and data privacy issues, threats to data have grown to top-of- mind for most organizations. Ransomware drives much of this, accounting for about 20% of cybercrime, at an annual cost of tens of billions of dollars. Growing political instability also concerns many organizations, with nation-state operators working to steal data to gain economic advantage and corrupt or destroy data to weaken opponents, There are no signs that these trends are slowing - the regulatory environment continues to increase control, ransomware shows no signs of going away, and political instability is spreading. Protecting data and preventing theft, destruction, corruption, or misuse is more important than ever. Threat actors and the “Dirty Dozen” The most effective way to protect data is to enable security controls at multiple levels of the application stack. If an attacker circumvents one security control, additional controls can address the threat. We describe this approach as defense-in-depth. To understand why a defense-in-depth approach to database security is essential, we must examine the actors who want your data and how they try to get it Threat actors can be broadly divided into “outsiders” and “insiders.” Outsiders vary widely in their level of skill and. resources. They include everyone from lone “hacktivists” and cyber criminals seeking business disruption or financial gain to criminal groups and nation-state-sponsored organizations seeking to perpetrate fraud and create disruption at a national scale. Insiders include current or former employees, curiosity seekers, and customers or partners who ‘take advantage of their position of trust to steal data. Both groups’ targets include personal, financial, trade secrets, and regulated data, Insiders Nation states Former employees Criminals Curiosity seekers Customers Competitors Figure 1-2: Threat actors What tools or techniques do these threat actors use to compromise data? Many information security professionals are ‘familiar with the OWASP Top Ten. OWASP stands for the Open Worldwide Application Security Project - an online community founded in 2001 focused on improving application security. The OWASP Top Ten aims to raise awareness about application security by listing the most critical security risks to web applications according to broad consensus. This list is updated regularly by OWASP as the threat environment evolves. Part of the value of the OWASP Top Tenis that it guides web administrators and developers in where to spend their effort and resources to deploy more secure applications. In this way, itis an essential step towards a more secure web infrastructure.‘ED 77/477 SEWAGE © OOM D)—lUe NF DOZEN ORACLE Similarly, we have proposed a list of the twelve most common database security risks we call the “Dirty Dozen.” The items on this list are a hacker's “tool chest” of tactics, techniques and ways they might use to compromise the data stored in databases. These tactics include: Exploiting unpatched systems or misconfigured databases to bypass access controls. Escalating run-time privileges by exploiting vulnerable applications. ‘Searching for sensitive data in unprotected databases, applications and systems. Stealing the credentials of a privileged administrator or application user through email-based phishing and other forms of social engineering or by using malware to sniff for credentials and data. ‘Accessing accounts through password guessing or exploiting careless credential management. Exploiting application weaknesses with techniques like SQL injection, bypassing application layer security by ‘embedding SOL code into a seemingly innocuous end-user-provided input. Exploiting unprotected systems as a bridge to launch attacks against more sensitive systems. Creating rogue user accounts on systems as a base for reconnaissance and possible escalation of privilege. ‘Targeting copies of live production data used in development and test systems where the data is typically not as well protected as in production systems. ‘Accessing unencrypted database system files on the disk or in backup files. Encrypting data or stealing the encryption keys from encrypted data, rendering it inaccessible to users and demanding a ransom, A complete list of the Dirty Dozen appeers in Table 11 Apeek inside the Hacker's tool chest: The most common database security risks THE 1. Insecure configuration and configuration drift 2. Unpatched and out-of-date systems DI RTY 3. Lack of a consistently enforced security policy 4. Lack of visibility into sensitive data placement and quantity COverprivileged database users and administrators 6. Weak authentication and shared accounts 7. SQL Injection vulnerabilities and insecure application design 8, Trusting vulnerable networks 9. Insufficient or inefficient monitoring and auditing 10. Sensitive data proliferation to non-production databases 11. Unprotected servers and database backups 12. Insecure encryption keys and secrets Table 1-1: The Oracle Database Security Dirty DozenBy 77/4707 7 WAGE 97 FOR 2D. #&U'N ORACLE wre system, Application and Database Admins Database Clones Figure 1-3: How hackers attack the database Addressing the Dirty Dozen through data security controls well-structured data security solution can help mitigate the risks from the Dirty Dozen. The best approach incorporates multiple layers of security controls to provide defense-in-depth protection from threats. We can group these controls into the following four categories: * Assessment controls help assess the security posture of a database, including the ability to monitor and Identify configuration changes. They also help you assess your users! security configuration, how much sensitive data you may have in the database, and where it resides. * Preventive controls block access to data by unauthorized users with technologies such as encryption and database-level controls. * Detective controls monitor user and application data access, allowing administrators to detect and block threats and support compliance reporting. © Exposure-timiting controls selectively redact or obfuscate sensitive data to limit their opportunity for ‘compromise or disclosure for various uses, Finally, two additional categories of controls are fundamental to data security. These support the other controls and help provide the required defense-in-depth security for mitigating risks: * Data controls enforce fine-grained access at the row and column level within the database, providing a consistent authorization model across multiple applications, reporting tools, and database clients. * User controls enforce proper user authentication and authorization policies, ensuring only authenticated and authorized users can access their data, Table 1.2 lists database security controls and how they map to Oracle products and technologies.MY AS 7 ORACLE Control Category oo Assessment controls | Security assessment User assessment Privilege analysis Sensitive data discovery Preventive controls _| Network encryption Data encryption Privileged user controls, SQL blocking Automated database patching Cee eee Rec rd Database Security Assessment Tool (DBSAT), Data Safe, Audit Vault and Database Firewall (AVDF) Data Safe Privilege Analysis DBSAT, Data Safe, Data Masking and Subsetting Native Network Encryption, TLS ‘Transparent Data Encryption (TDE), RMAN encryption, Key Vault Database Vault AVDF, SOL Firewall (23¢) Autonomous Database Detective controls | Database activity auditing Audit record collection and reporting SQL monitoring Traditional Audit, Unified Audit AVDF, Data Safe AVDF, SOL Firewall (23c) Exposure-limiting controls Dynamic masking Static masking Data controls, Fine-grained data access controls Label-based access controls. Data Redaction Data Safe, Data Masking and Subsetting Virtual Private Database (VPD), Real Application Security (RAS) Oracle Label Security User controls. Password policies, Strong authentication Centralized user management User profiles Kerberos, Certificate-based authentication, Multi-factor ‘authentication, Token-based authentication (Cloud) Centrally Managed Users in LDAP directories, Cloud- based identity integration Table 1-2: Database security controls with applicable Oracle products and technologies. With this comprehensive set of database security controls, we now begin to see how to deploy defense-in-depth security to address threats such as the Dirty Dozen listed in Dirty Dozen with compensating controls that address these Table 1.1. Table 13 provides an example of connecting the risks, Decca Deu (DD #1) Insecure configur jon and configuration drift Security assessment (DD #2) Unpatched and out-of-date systems (DD #3) Lack of a consistently enforced security policy Automated database patching Fine-grained data access controls (DD #4) Lack of visibility into sensitive data placement and quantity | Sensitive data discoveryMP 77/47 0/77 SWAG O° FER 2. UN ORACLE Deus CeCe (DD #5) Overprivileged database users and administrators Privileged user controls (DD #6) Weak authentication and shared accounts Password policies Strong authentication Centralized user management (DD #7) SQL Injection vulnerabilities and insecure application design | SQL monitoring. SQL blocking (DD #8) Trusting vulnerable networks Network encryption (DD #9) Insufficient or inefficient monitoring and auditing, Database activity auditing Audit record collection and reporting (0D #10) Sensitive data proliferation to non-production databases _| Static data masking (DD #11) Unprotected servers and database backups Data encryption (DD #12) Insecure encryption keys and secrets Key and secrets management Table 1-3: Dirty Dozen security risks and compensating security controls. Insecure Configuration ob users Sat recon Servers ond bocups Unpatched ters Trusted admin acounts ‘tack rough application Excrton ys eo roected dato Trusted networks Excalat rivleges Test ond dev tes y Assess security Control access to Monitor user Protect against data posture and risk sensitive data activities theft + Data Safe configuration, || + User profiles, mu, ss0 | ]+ United Aut + Advanced Security ~ Eneryption User and Dato assessment || + Privege Analysis, Aud Vaultand D8 Frewail| |- Advanced Secuty- Redaction + uct Vault and Database || + Datebove Vault + Data Safe - Auditing + key Vault Frewal = Secunty Posture || + Label Security Data Safe - Masking Management + Victual Private Database + ata Masking / Subsetting esar + Real Applcation Security + Z0URA ‘Apply release updates Figure 1-4: Combatting the Dirty Dozen Initially, many organizations begin by implementing security controls on a project-by-project basis but then later expand the scope after realizing that hackers would target any unprotected system on the network and then use that asa launching point to attack other systems with sensitive data, Many organizations then move to centralized security management using tools and cloud services such as Oracle Data Safe, Oracle Audit Vault and Database Firewall, Oracle Key Vault, and Oracle Enterprise Manager.‘ED 77/477 SEWAGE © OOM D)—lUe NF ORACLE Finally, since many organizations are migrating their workloads to the cloud and embracing new, agile deployment models, these controls need to scale and work seamlessly across on-premises, private cloud, public cloud, and hybrid cloud environments. This book takes you through the various aspects of Oracle's defense-in-depth security for databases and provides a high-level overview of how they work and the types of protection they provide. The following chapters cover different aspects of database security. Let's begin.ORACLE > Chapter Two Assess database security posture and risk BW 77/47/77 EWA ©] 2LA MP 774A’ 7 TARE © 2 5 ORACLE Introduction Today's systems are complex, with many security configuration settings. As recent data breaches have demonstrated, itis critical to have properly configured and secure systems. Huran errors could leave your database open to everyone, or an attacker could maliciously exploit configuration mistakes to gain unauthorized access to sensitive data Falling to implement basic security controls may risk exposing customer data, including names, addresses, birth dates, account information, etc. This can have a devastating impact on both your reputation and bottom line. Therefore, you should regularly harden and scan your databases, remediating deviations from security best practices, Many regulations, such as EU GDPR, PCI DSS, Sarbanes-Oxley, and various breach notification laws, promote regular security assessments on the most critical systems, such as databases, to reduce IT risks. Multiple organizations, such a the Center for Internet Security (CIS) and the U.S. Department of Defense, have recommendations for security configuration best practices. It is critical to regularly assess database security posture, considering recommendations from different regulations, security frameworks, and vendor best practices. This chapter describes how Oracle database security solutions can help quickly evaluate your database security posture, categorize the findings, and recommend suitable action to develop a strategy to keep your databases secure. Evaluate and assess database configuration Attackers take their time to prepare for an attack and usually spend considerable time doing reconnaissance. They Use tools that automate the discovery of databases, open ports, and vulnerabilities, automate application and SQL Injection attacks; and execute brute force password attacks. Once they finish probing, they assess the weakest links and determine the next steps. In essence, the attackers evaluate your security posture to find a way to get to your sensitive data. Some common questions they try to answer while probing your databases: + Which version isthe database? What are the known vulnerabilities? Have those been patched yet? * Are there any known users with default or easy-to-guess passwords? + Who are the privileged users on this database? Is there a way to escalate privileges from regular users? * Which packaged applications are running on this database? Are those running with all-powerful privileges? + Is auditing on? For whom? Which conditions? Can activities be tracked? * Is the data encrypted? If not, can we access the underlying storage or a backup? All these questions are inside the hacker's mind, and the answers help them devise a plan to break into your database and steal data, As data owners, you need to think like a hacker to harden your database's security posture. Properly hardening and securing a database is a challenging task. Success requires understanding the users and their roles, the data and its sensitivity, the security configuration parameters, the enabled features, knowledge about the database attack vectors, and the available security controls to protect the database. Because Oracle Database is highly customizable, assessing security requires understanding the impact of configuration choices on the overall security. Here are some key considerations for protecting your databases: * Almost all databases hold sensitive data, but the level of importance may differ. For example, a customer's date of birth may be more sensitive than their email address. It is essential to find out which databases contain what type of sensitive data so that controls can be implemented accordingly.o> MP 774A’ 7 TARE © 2 5 ORACLE + Common database vulnerabilities include unpatched systems, poor application design, weak user credentials, excessive privilege grants, lack of a trusted path to data, separation of duties, encryption, and inadequate auditing. ‘Security configuration parameters are tightly related to how the database behaves and require understanding the parameters, what they do, the impact of changing them, and their dependencies. ‘+ Notall database users are equal. Apart from the DBAs, several other actors/processes interact with your data through database user accounts—the application, application administrators, security administrators, and others, including service accounts, batch programs, etc. identifying the different types of database users and the activities they need to execute on the database helps you properly manage privileges and roles and implement the principle of least privilege. * Notall databases are created equal. Some databases may be more business-critical or contain more sensitive or highly regulated data. Your investment in security controls (which could be in tools, time, or operational resource commitment) is usually commensurate with the criticality or sensitivity of the database, Several software tools and services can help you assess the security of your databases. These tools include the Database Security Assessment Tool (DBSAT), Oracle Data Safe (an Oracle cloud service), Audit Vault and Database Firewall (AVDF), and Oracle Database Life Cycle Management (a management pack for Oracle Enterprise Manager). Assessing configuration security of the Oracle Database with DBSAT DBSAT identifies areas where your database configuration, operation, or implementation introduces risk. DBSAT collects and analyzes configuration data and parameters from the database. DBSAT then recommends changes and controls to mitigate those risks. ‘Apart from database and listener configuration, DBSAT collects information on user accounts, privileges and roles, authorization control, separation of duties, fine-grained access control, data encryption and key management, auditing policies, and operating system file permissions. DBSAT applies rules to assess the current security status of a database quickly and recommends best practices. Updated best practices rules are delivered periodically with new versions of the tool. DBSAT scans the database for weaknesses and vulnerabilities and indicates findings by risk level to help prioritize work on the most critical weaknesses. DBSAT also provides high-level summaries and specific recommendations for each issue, making it simpler and quicker to act. DBSAT is a free command line tool available to all Oracle customers to quickly find sensitive data, evaluate their database security posture, identify gaps, and help implement the recommended security best practices for their organization, DBSAT is also used worldwide by Oracle consultants and partners while performing database security assessments. DBSAT security assessment reports DDBSAT has three components: collector, reporter, and discoverer. The collector and reporter are used for generating database security risk assessments, andthe discoverer discovers the different types of sensitive data in the database. The DBSAT Collector first gathers security configuration information from the database and underlying OS. The DBSAT Reporter then analyzes the collected data and generates detailed findings and recommendations. The output reports are in HTML, spreadsheet, text, and JSON formats. The DBSAT Discoverer (described later in Chapter Three) helps to identify sensitive data by looking into table metadata (comments and column names), and classifies, and summarizes the findings in HTML and spreadsheet reports. The HTML reports provide detailed assessment results in a format that is easy to navigate. The spreadsheet format provides a high-level summary of each finding so that you can add columns for your tracking and prioritizationMCAT aa ORACLE purposes. A report in text format makes it convenient to copy portions ofthe output for other usages. The JSON. outputs suitable for data aggregation and integration purposes. & son fo) Fen] mm Spreadsheet ig 12,18, 196,216,238 Figure 2-1: Database Security Assessment Tool Oracle Database Security Assessment Highly Sensitive Assessment Date & Time Wed 19 2023 14.0609 UTC¥0000 Wed a 192023 1608-43 UTCO000 2.0 us 2020) - eee Database Identity Name Conner (Type) Paform [Database Role Log Mode Greed Summary, ‘scion ass [evaluate | Advisory] tow | Medium | High Total [ isk Rist” RBC rnaigs ‘niin | ° 1 ser ccunts 10 2 Pleoes and oes ws 2 ‘Autonzation onl 3 5 in-Crained Access Com 5 ing 6 Figure 2-2: Database Security Assessment report summary The resulting analysis is reported as findings that consist of the following:ORACLE ‘© Rule ID: By convention, a rule ID contains a prefix that identifies the report section for the finding, followed by {a period and a name to identify the finding uniquely ‘© One-liner: A single sentence that describes what should be done. ‘+ Status: This indicates the level of risk associated with the finding (Pass, Low Risk, Medium Risk, High Risk) or indicates that the finding is an Advisory for improvement, such as information about an optional security feature currently not in use. In cases where further analysis is needed, the status is shown as “Evaluate.” + Summary: Presents an overview of the finding. 1 ‘© Details: Presents the details of the results, followed by recommendations. ‘+ Remarks: Explain the reason for the rule and recommended actions for remediation, ‘+ References: When applicable, it will reference the corresponding CIS Oracle Database benchmark recommendation, Oracle Database STIG Rule, and the EU GDPR article/recital In the finding below, DBSAT has identified nine users with the DBA role, and that further analysis is needed (Status Evaluate). The Remarks provide more information on why itis important to limit the usage of this role to a small ‘number of trusted administrators. References flag this finding as originating with CIS Oracle Database 12c Benchmark recommendation 4.4.4, DISA STIG rule V237710 and 237711, and an Oracle-recommended best practice. Users with DBA Role von gow | ere 004 nd POR DA ere rtd ei mee es ‘Status Balate Summary Qoutof $3 users have been dety or inrecty rated highly Sesitv DBA/PDB.DEA role via 1 Goer granted high senstve OA/POB_OBA role wth admin option via 1 grant Detals——Gaere with DRA/PDB OMA role omvonsns 199, 98(+) (0) = granted with adnin option. Remarks The DEA and POS_DEA oes are power and can ‘ni orant them toa small numberof red admatatrs. asa bet acc, {tetsmanded to create custom OBA-ike rls withthe miu stoves tat ers tear toexeat ther tasks Gest prviege pine and not grat the DAK or POR DBA roles. Brege Aras can asst n etn eea/unasedpriveges an oes Diferent les wih Iinimum reciredprivieges based onthe types of operations database aaramsvaters execute [ofp achieve Separation of Duties Furthermore, ach usted user should hae annual account or accountability reasons. You ‘Should sud rere wth the O84 or P08 OBA roles to detect unatharizes prvleged act ‘Aoi rating the DBA, PO8 DBA or castom DEA- Ie powerfl ales wi WIT ADMIN option ‘hlessnecessary. Pease note that Oracle may ado remove foes and piles rom the DBA roe DAA ae, {hs Benchmark: Recommendation 44.4 Figure 2-3: Sample finding: Users with DBA role aeo> MP 774A’ 7 TARE © 2 5 ORACLE Assessing your database fleet using Oracle Data Safe DBSAT is a great tool to assess a few databases quickly, but what if you have dozens, hundreds, or thousands of databases? Enter Oracle Data Safe. Data Safe is an Oracle Cloud Infrastructure (OC!) service focused on Oracle Database security. Customers can use Data Safe to gain visibility on their databases’ security whether running on-premises, in the Oracle Cloud, or 3 party clouds. Data Safe provides a comprehensive suite of security capabilities such as security and user assessment, activity auditing, SOL firewall management, data discovery, and data masking for non-production environments. Tightly integrated assessment capabilities provide the ability to simultaneously run assessments on multiple databases, schedule assessments, establish a security baseline, and get a comparison report highlighting the rift between that baseline and the current database security assessment. Data Safe employs a simple “click-and-secure” model designed for users with no special security expertise. Data Safe saves time with an intuitive interface that minimizes error and shortens learning curves. It mitigates security risks by ‘making various aspects of configuration, data, and user security risks immediately visible to database administrators. Multi-Cloud ‘On-Premises / (Oc! Compute Data Safe fl Ss Assess Users Discover Mask Audit Firewall Oracle Cloud Infrastructure GovCloud SES a Figure 2-4; Oracle Data Safe essential security for Oracle databases, both in the cloud and on-premises. Assessing database security with Data Safe Data Safe's security assessment helps identify configuration gaps that could represent a vulnerability. Data Safe performs a comprehensive check of your database configuration. It examines user accounts, privilege and role grants, authorization controls, fine-grained controls, auditing, encryption, and configuration parameters. Data Safe identifies gaps compared to organizational best practices and delivers actionable reports with prioritized recommendations and ‘mappings to common compliance mandates like EU GDPR, DISA STIGs, and CIS benchmarks. The following snippets show a sample security assessment report, including a high-risk finding and a finding that reeds further analysis. The findings include whatever the issue is, its severity, and recommendations on how to remediate it. Data Safe leverages DBSAT and adds enterprise-grade features such as periodic assessment, fleet view (aggregations), filtering, baselining, drift reports, history of assessments, events, and notifications.ORACLE Figure 2-5: Oracle Data Safe: Security assessment Data Safe also allows you to configure acceptable risks. For example, if the assessment lists a finding that needs to be evaluated (“Evaluate’; needs manual confirmation), you can mark the finding as “Pass” after successfully validating that there is no riskin your case. You can lower afinding'sriskif you have other compensating controls that reduce the risk. You can accept the risk if you do not plan to address it no = = Assessment details © ms > reeset > Veet ato + Tae somanoeToNaroUC ion iaae ORACLE Update risk or fining ewe — tees oe Figure 2-6:Oracle Data Safe: Configuring acceptable risks Understanding user risk with Data Safe Data Safe offers a unique capability that allows you to evaluate the risk represented by various database users. User risk assessment evaluates database users, looking at static and dynamic user profile characteristics to identify the highest-risk users, User risk is presented alongside other user details, allowing you to quickly determine which users ‘may be over-privileged or require compensating controls such as auditing. It helps you understand, for example, how ‘many users have net logged in the last three (3) months or longer or have net changed thelr passwords, Suppose there is some suspicion about a user's activity. In that case, Data Safe helps you understand all details about the user, including when they were created, their roles and privileges, and related audit records showing that user's activity. Stealing privileged user credentials is the most common method hackers use to access sensitive data, Data Safe helps you take steps to make your applications more secure by providing the ability to assess and visualize user risk. ‘vorwew | Assessment information Tags Last password eninge « Btight lor? Figure 2-7: Oracle Data Sate: User risk assessment Data Safe User Assessment also provides you with visibility over database user profiles. User profiles include password-related settings that are essential for strengthening passwords. User profiles allow you to limit some actions that users can perform on the database. For example, you can use user profiles to limit the number of failedORACLE User profiles sr pete sammy Tagen Tans | pte nane swag tnt ‘See how else Oracle Data Safe can help: Chapter twelve. ‘ED 77/477 SEWAGE © OOM D)—lUe NF ‘= Identify which profiles are assigned to which users tins) ‘+ To discover sensitive data, please see Chapter three. ‘+ Todetect or block SOL injection attacks, please see Chapter seven, Figure 2-8: Oracle Data Safe: User profile insight + Quickly identify users and profiles with inadequate password governance policies rlelelele tlelsle ‘+ To anonymize sensitive data in non-production environments, please see Chapter nine. login attempts before a user is locked out for a configurable time period, set password governance settings, including complexity requirements, and define password expiration policies User profile insight helps unlock the power of profiles across your fleet of databases, giving you the capability to: ‘+ Review existing user profiles and their parameters, including the password verification function ‘= Contrast user profiles with similar names across multiple databases to spot differences or gaps + Tocollect audit records and centralize reporting and alerting to meet regulatory requirements, please seeMCAT aa ORACLE Assessment with Oracle Audit Vault and Database Firewall (AVDF) Starting with release update (RU) 20.9, AVOF provides a fleet-wide simplified and centralized view of security configuration assessments for all your Oracle databases, along with the security findings and associated risks. Like Data Safe, AVDF also leverages the Database Security Assessment Tool (DBSAT) for Oracle Databases. The full- featured assessment with compliance mappings and recommendations helps you understand the security posture for all your Oracle databases in one central place. You can also define an assessment baseline and determine deviation from that baseline by viewing security assessment drift reports. Insights from the drift reports help you focus only on the changes since the last assessment. Database Security Posture Management in AVDF adds to the existing capabilities of AVDF, including centralized audit ‘monitoring, audit policy provisioning, reporting, and database firewall AVDF also helps you analyze user entitlements (role and privilege grants). AVDF lets you take a snapshot of user privileges at a specific time and label it to compare it with other snapshots to see how entitlements have changed over time, Security Assessment for Oracle Databases Targets Assessed: 7 Targets Not Assessed: 3 Risk Level Risks by Category Pa 2 4n Findings TB Risks High Risk mt Advisory Medium Risk mi Evaluate Privileges And Roles LowRisk — ml Pass 1 User Accounts Figure 2-9: Audit Vault and Database Firewall security posture management To know more about how Oracle Audit Vault and Database Firewall can help: ‘+ Toprevent SOL injection attacks, please see Chapter Seven.ORACLE ‘= Please see Chapter Twelve for information on centrally managing audit records for analysis, alerting, and reporting. Configuration Assessment with Enterprise Manager Oracle also offers the Enterprise Manager Database Lifecycle Management (DBLM) pack to address your enterprise needs for assessing security configuration. DBLM provides numerous reports for security configuration checks and a comprehensive compliance framework. Reports include information on initialization parameters, operating system directory permissions, user account profile, and sensitive object reports. ‘You can customize the compliance framework by adapting existing standards and rules or creating new ones. DBLM. also ships with a DISA Security Technical Implementation Guide (STIG) compliance standard, including rules to validate STIG requirements. soaintra © 1B Onde Database ¥ Paromance w Avalabity © Secsty ¥ Schema ¥ Admnstaion © General Security Reports > Database Account Password Reports Privileged Database Accounts and Roles Reports Canes Aconts Wi EXEMPT ACCESS POLICY Page Cubase Acouts Wit BECOME USER Page Cana Ascot Wit ALTER SYSTEM OR ALTER SESSION Prag Ostabase Acouts Wih Pivoged els 1 > Intaization Parameter and Operating System Directory Permission Reports > General Database Privilege and Resource Profile Reports > Database Auait and Privilege Reports Figure 2-10: Oracle Enterprise Manager general security reports DBLM ships over four dozen out-of-the-box compliance standards, including basic security configuration for Oracle Database, RAC nodes, and Oracle Listener. It also monitors configuration for Exadata Compute nodes and Security Linux packages. In addition, trend analysis allows fine-grained tracking of compliance scores over time. BRLA | “EP 7/AL 77 7 ETA & © 2 ORACLE Oracle 19¢ Database STIG - Version 2, Release 3 for Oracle Database (Compliance Standard) ‘Tuget Scorecard ule Evaluations > rermat ape = equ Date score) ist Euan ewe nase elale 9 ae ma wma _ Figure 2-11: Enterprise Manager STIG compliance standard detail Asset discovery and grouping DBLM eliminates the need to track IT assets, including databases, manually, It provides non-intrusive network scanning capabilities to discover servers, databases, and other applications. With the ever-growing number of systems and services that administrators are responsible for, administrators need a view that includes only those targets they need to monitor and manage. Through such “Groups,” you can monitor and manage different targets collectively, efficiently perform administrative operations against the targets, and consolidate and monitor your distributed targets as one logical entity. For example, you can define a TEST group containing all applications, databases, and host targets within your test environment. From a group's home page, an administrator car * Determine the security configuration compliance of all the members in the group and outstanding alerts, * Drill down and analyze the specifics of a particular target, © Compare multiple targets and find out configuration divergence. For example, it could find out which database has not enabled auditing. Choosing the right database security assessment tool Oracle offers a range of assessment tools to help evaluate and enhance your security posture, Here is a rough guideline to assist you in selecting the right tool. ‘+ DBSAT isa simple standalone tool to assess the security configuration of a single Oracle database. But if you ‘want to assess your fleet or track deviations, consider using Data Safe,‘EP 77/A2 777 EWA E © FOO DCU ORACLE ‘© Suppose you want to run security assessments at scale across many databases, track drift, and benefit from a Unified console with other security services. In that case, Data Safe cloud service is your answer. Data Safe is also the tool of choice if your Oracle databases run in a multicloud or hybrid deployment model and you are ooking for one tool across all those databases. If corporate/regulatory requirements require you to keep all security configuration information on-premises and within your full control, the tool of choice is AVDF. Besides activity monitoring, AVF provides fleet-wide security posture management of your databases. Functionality-wise, both AVDF and Data Safe are very similar from a security assessment perspective. ‘+ Ifyou already use Oracle Enterprise Manager and want to assess beyond the database or need to do ‘customizations, the Database Lifecycle Management Pack is your answer. Reducing the blast radius with Privilege Analysis Assessing a database's security posture deals with more than security configuration settings. The end-goal of the assessment process is to reduce security risk. A large part of the risk is tied up in database user accounts. AS ‘mentioned earlier, most database breaches involve the use of stolen credentials - the bad guys just login to the database and steal your data. Removing unnecessary privileges from user accounts reduces the damage those accounts could cause if they were compromised (and thus reduce the “blast radius” of the event), The problem is that itis tough to determine whether a user has more privileges than they need. One way to identify overprivileged users is through entitlement reviews, where a knowledgeable person reviews the privileges and roles granted to a user and identifies privileges that are not needed. That approach is facilitated by tools like Data Safe's User Assessment or AVDF's entitlement reviews. However, managers may be reluctant to mark privileges, and DBAs may hesitate to revoke roles and privileges from user accounts as the potential impact is unknown. ‘Another way to reduce unnecessary privileges isto track which privileges accounts are actually using and remove ‘those not being used. Oracle Database's privilege analysis (PA) feature dynamically analyzes privilege and role usage for database users and application service accounts at run time. PA identifies unused privileges and roles based on ‘the actual user or application usage of the roles and privileges during a period of time. Removing privileges you know are not being used is easier than asking a user's manager if they still need the privileges they already have. Reports generated by PA reflect the actual privileges and roles used/unused by users and applications during, runtime. The D8A_USED_PRIVS and DBA_UNUSED_PRIVS views show which privileges and roles have been used or not used, respectively. The figure below shows that the APPS user has been granted privileges that are not being used: DROP ANY TABLE, ALTER ANY TABLE, CREATE TABLE, and UNLIMITED TABLESPACE. Also, DROP ANY PROCEDURE and CREATE PROCEDURE granted through bot the APPS and APPS_PATCHING roles were not in use. Could that mean that the APPS User was granted a role once to apply a patch and that the role never got revoked?ae ORACLE ‘SIN Policy Grantee Grantee Type __ System Privieges Grant Path 1 HR Analysis Policy APPS USER DROP ANY TABLE APPS. 2 HR Analysis Pokcy APPS USER ALTER ANY TABLE APPS. 3 HR Analysis Poicy APPS USER (CREATE TABLE APPS. 4 HR Analysis Policy APPS USER UNLIMITED TABLESPACE APPS SHR Analyss Policy APPS USER DROP ANY PROCEDURE APPS,APPS_PATCHING G HR Analysis Policy APPS USER CREATE PROCEDURE _APPS,APPS_PATCHING Figure 2-12: Enterprise Manager report on DBA_UNUSED_PRIVS. The following figure 2.13 also shows interesting details of used roles and privileges. Here, the APPS user was granted SELECT ANY TABLE when, in fact, the user is selecting from specific tables on the HR schema (DEPARTMENTS, J0B_HISTORY, COUNTRIES, EMPLOYEES, LOCATIONS, REGIONS, and 3085). In this case, the DBA should revoke the SELECT ANY TABLE system privilege that allows the APPS user to select from any table in the database and grant an object privilege on the required tables (e.g., GRANT SELECT on HR.DEPARTMENTS to APPS) instead. If APPS requires ‘access to ALL tables in the HR schema, you may GRANT SELECT ANY TABLE on HR to APPS - this is an example of granting schema-level privileges, a new feature in Oracle Database 23c. ~ object ‘Poly User ame Used Role were eae 7 Grant Path 1H Anais Pokey APPS ors, SELECTAN TARE HR DEPARTMENTS TABLE ars ZR AnahssPoky APPS 0s SELECT ANY TARE HR JOB HISTORY TARE 20s 3 HR Anas Poky APPS 07s, SELECT ANY TABLE HR COUNTRES TAME ans HR anayes Pokey APPS rs, SELECT ANY TARE HR ENPLOYEES TABLE ars SHR AnassFoky APPS ars, SELECT ANY TARE HR LoceTions = TAME ars ‘SHR Anahss Pokey APPS 20s SELECT ANY TARE HR SIONS TARE ars 7 HR Anas Poky APPS ors, SELECT ANY TARE HR 108s TARE aps ‘8 Hm anaes Pokey APPS ars CREATE SESSION (ou ans 9H Anas Pokey APPS Pusu (ou) srs (DMS_APPLICATL. PACKAGE Pum 10 8 Ana\ce Pokey APPS Pusu (ou) SYSTEN —PRODUCTLPRIVS VIEW Pua 11 Anas Pokey APPS Pusu (ou) xs ust Tae Pum Figure 2-13: Enterprise Manager report on DBA_USED_PRIVS Static-based role/privilege analysis tools (e.g., DBSAT or Data Safe) provide a good starting point but can only show Which roles and privileges are granted to users. With a deeper understanding of the privileges required for an application to run with the least privileges, database administrators can confidently refine roles and privileges granted to limit unnecessary grants. Reducing unnecessary privileges reduces the attack surface and the potential impact of a stolen database user account credentials or account misuse. Privilege Analysis lets you: ‘+ Report on actual privileges and roles used in the database. ‘+ Identify unused privileges and roles by users and applications, ‘+ Reduce risk by helping enforce least privilege for users and applications Security patch management Patching can be considered part of the assessment since that’s where you're most likely to learn you are missing security updates. Every quarter, Oracle routinely provides database fixes for functional, performance, or security issues discovered by internal testing or reported by customers and external researchers. The security fixes can cover a Wide range of topics, including:‘EP 77/A2 777 EWA E © FOO DCU ORACLE ‘+ Vulnerable SOL statements, buffer overflows, SQL injections, etc. + Vulnerable database clients, JDBC drivers, third-party code, etc. ‘© Weaknesses in cryptography, networking, remote code execution, etc. The timely application of patches is necessary for organizations to maintain a proper security posture. If you are not applying patches, then you are accepting the risk of known vulnerabilities! Proactive Maintenance with RUs and MRPs For proactive maintenance, apply the quarterly patch bundle (Release Update) available from the My Oracle Support (MOS) Customer Portal for each Oracle Database software release, The RUs are released quarterly on the third Tuesday of January, April, July, and October. Each RU gets a maximum of six Monthly Recommended Patches (MRPs). Release Updates (RUs) Us are highly tested bundles of critical fixes that enable you to avoid known issues. They usually contain the following types of fixes: security, regression (bug), optimizer, and functional (which may include feature extensions). Oracle recommends that you stay current by using RUs. Doing this minimizes the chance of encountering known bugs and security vulnerabilities. If you run your databases on Linux x86-64 platforms and have tested an application against an RU and want to go live, you should check for the latest MRP and apply it. Quarterly patch updates are announced on the Critical Patch Updates, Security Alerts, and Bulletins page each January, April, July, and October. Monthly Recommended Patches (MRP) With update 19.17, Oracle began releasing MRPs for Linux x86-64 to provide proactive patching between Release Updates. MRP bundles a collection of recommended one-off fixes, including security fies, delivered monthly as a merge patch via a single downloadable patch for a given RU. Unlike an RU, an MRP does not affect the release ‘number. This distinction may be important if you have to run your application quality assurance/testing cycles with a specific major version and do not want to do it again, MRPs are delivered for each RU in the six months following each RU's release. MRPs include the fixes documented in "Oracle Database Important Recommended Patches" (MOS note 555.1), plus the prior MRPs for the RU. Each MRP includes the latest critical and regression fixes and the critical content released up to six months prior. By waiting to take new RU content for up to six months, you can take a more conservative approach to Oracle Database software maintenance, but you still risk the chance of hitting known issues that are fixed in the most recent RU. The ‘main benefit of this patching strategy is that if any regressions are reported on the base RU or succeeding MRP, they will be fixed in later MRPs.7 Ze Wa GE. 2. 9 25 a Bs ORACLE crear Popes etc) Cadence Quarterly Monthly for long-term releases on Linux x86-64 Zero downtime (ZDT) RAC Rolling RAC Rolling Security fixes Included May include CPU Alerts and fixes for vulnerabilities with high CVSS scores Regression fixes Included Included Proactive functional fixes Included Not included Optimizer plan changes (off by default) | Included Not included Functional enhancements (minor) Included Not included Emergency one-offs Included Included Supported operating systems All supported Linux x86-64 platforms Table 2-1: Difference between RUs and MRPs We strongly recommend keeping your database and Oracle Grid Infrastructure up to date by applying RUs to fix known security vulnerabilities and minimize the risk of a successful attack. RUs include the most recent security, regression, and critical fixes, Staying current with RUs reduces the likelihood of requiring separate interim one-off patches, which lead to unique software baselines and the potential for ongoing costly patch maintenance, Patching tools Patching an Oracle Database requires planning as the process is complex and can lead to downtime if not properly managed. We recommend out-of-place patching for rolling patching, granular patching, and easier rollback. Oracle Fleet Patching and Provisioning (FPP) helps control your database fleet lifecycle using automation, standardization, and out-of-place patching. The FPP drift detection capabilities can verify the compliance of the environments, Routine operations lke provisioning new clusters and databases, installing patched Oracle binaries, patching clusters and databases, or upgrading them, are completely automated with FPP. These blueprints guarantee that all planned maintenance operations are executed inthe correct order, wth the east impact on the business. Larger organizations implementing FPP can patch hundreds or thousands of databases per maintenance window with the minimum human interaction, enabling consistent time and money savings. Small organizations with limited resources can also benefit from it. You can use FPP if your targets have Oracle RAC or Oracle RAC One licenses or have licensed the Enterprise Manager Database Lifecycle Management (DBLM) Pack for single-instance databases Oracle LiveLabs Oracle LiveLabs gives you access to Oracle's tools and technologies to run a wide variety of labs and workshops at your own pace. If you want try the assessment technologies discussed in this chapter, please go to: ‘© Database Security Assessment Tool © Get Started with Oracle Data Safe FundamentalsMCAT aa ORACLE * Audit Vault and Database Firewall workshop + Privilege Analysis workshop. © Oracle Fleet Patching and Provisioning workshop Summary Knowing how securely the database is configured is the foundation for a defense-i depth strategy. Configuration drift needs to be monitored, the database must be patched, and appropriate controls need to be implemented. No system is 100% secure, but overlooking basic security controls only makes life easier for attackers Oracle Database Security Assessment Tool (DBSAT), Oracle Data Safe, Oracle Audit Vault and Database Firewall (AVDF), and Oracle Database Lifecycle Management Pack (DBLM) provide the means to help you identify the gaps in ‘your Oracle database security configuration and the recommendations to overcome these gaps.ORACLE Chapter Three Discovering sensitive data ‘EP 7reAL 7 WAGE 9" FR no ONLA | IY, “EP 77/477 QEOASZR. &. ORACLE Introduction Before we can protect sensitive data, we have to know where its. An important step to protect sensitive data is, understanding what kind and how much sensitive data a database has and where itis located. This knowledge can be Used to implement appropriate security controls to protect data. This chapter introduces the basic elements of sensitive data discovery and gives you an overview of the Oracle technologies that can be used to discover sensitive data, including: ‘+ Database Security Assessment Tool (DBSAT) © Oracle Data Safe ‘© Oracle Audit Vault and Database Firewall ‘+ Enterprise Manager Application Data Modeling, Why is sensitive data important? The amount of data that organizations collect and manage is growing every day. In today's world, data is the most valuable resource and a necessity for every organization. A significant percentage of data is sensitive or personal Malicious actors monetize stolen data by committing identity theft and financial fraud, selling government and trade secrets, or using it for future attacks. Because of its value, data loss can impact companies’ finances, reputations, customer trust, and competitiveness. The importance of data and growing security threats make it necessary to protect sensitive information. At the same time, data privacy laws and standards such as the European Union General Data Protection Regulation (EU GDPR), California Consumer Privacy Act (CCPA), Payment Card Industry Data Security Standard (PCI-DSS), and Health Insurance Portability and Accountability Act (HIPAA) mandate personal data protection, What is considered sensitive? Sensitive data should not be made available to unauthorized people, whether they operate inside or outside the organization. The following figure shows a few examples of the categories and types of senstve data, 7 ~. ws a a F BF [gF & Identification Biographic IT Financial Healthcare Employment Academic sen he Tp Acresso Credit Crd ja Provider un Employes Dp College Nore home Gender UserID. CCSecurty PIN. Insurance -«JabTiteGrade Email Race Password BankName Height Department Student 1D Phone Gtizenstip Hostname ‘Bank Account Blood Type ‘Hie Date Financial id Passport Address GPS locaton BAN Diebiity Salary Admision Date o Family Data SwiftCode Pregnancy Stock Graduation Date Toxo Date of ith : Test Results Attendance Pace o Birth ICD Code Figure 3-1: Examples of sensitive data categories and types These sensitive types are arranged under sensitive categories such as identification, blographic, healthcare, financial, employment, and academic data.LA | “EP 7/AL 77 7 ETA & © 2 ORACLE Discovering sensitive data The most common way to discover sensitive data in a database Is to search for column names using keywords or search patterns (regular expressions). Data patterns can also be used to check values in a column. Combined with a column name or comment match, a data pattern helps raise confidence that a certain column has sensitive data. Oracle provides multiple sensitive data discovery tools: Database Security Assessment Tool (DBSAT), Oracle Data Safe, Oracle Audit Vault and Database Firewall (AVDF), and Enterprise Manager (EM) Application Data Modeling (ADM). They can help discover over 150 common sensitive and personal data. Users can modify the predefined sensitive types and create new ones to meet specific requirements. Discovering sensitive data using DBSAT Chapter Two introduced the Oracle Database Security Assessment Tool (DBSAT) to review database configurations. DBSAT can scan your database to identify sensitive data by inspecting colurn names and comments to determine if they hold sensitive data, DBSAT also checks table statistics in the data dictionary to determine the quantity of sensitive data (number of rows) in the table. DBSAT generates detailed data assessment reports in HTML and spreadsheet formats, with sensitive columns classified into categories for easier management. DBSAT helps discover sensitive columns in English and provides sample files for seven major European languages: Dutch, French, German, Greek, Italian, Portuguese, and Spanish. DBSAT's library of sensitive data definitions Is extensible to include your unique types of sensitive data. Assigned categories can be easily modified to suit your needs. Sensitive data assessment report using DBSAT DBSAT's sensitive data assessment report helps you understand what kind and how much sensitive data a database has, and where itis located, Table 31 shows the summary section that provides information about the number of tables, columns, and rows identified as sensitive, grouped by sensitive category and subcategory.MP 774A 7 OA GE © 2 25 ORACLE Eee eee ee BIOGRAPHICINFO - ADDRESS. 9 36 6307209 BIOGRAPHIC INFO - EXTENDED Pll 2 2 2000 FINANCIAL INFO - BANK DATA 2 2 830 FINANCIAL INFO - CARD DATA 7 7 3235 HEALTH INFO - PROVIDER DATA 1 1 19 IDENTIFICATION INFO - NATIONAL IDS 2 6 2000 IDENTIFICATION INFO - PERSONAL IDS 3 3 405, IT INFO - USER DATA 8 8 13228 JOB INFO - COMPENSATION DATA 10 2 3380 JOB INFO - EMPLOYEE DATA 8 % 406 JOB INFO - ORG DATA 5 6 28 Total 29 132 2617644 Table 3-1 Sensitive Data Report - Category Summary Each sensitive category has a predetermined risk level (high, medium, or low). The report recommends protecting sensitive data based on the associated risk level. Figure 3.2 shows some recommendations for protecting high-risk data, such as personal health information.ORACLE Ri i: High Ri Securty for Environments with High Value Data: Detective plus Strong Preventive Contras Highly Sense ard eglted data shoul be pated fom priveged users, a rom wes without busines need forthe tata Actvy of prvlsged accounts should be conto to protect apint nie hea ‘Who can aces he dtabise and wht canbe excited shoul be controled by establishing Command ules. Sesive data shoul be Yedaced on application fad oy sree. ADatabase Firewall ensures at ony ‘oproved SOL statrents or access by trusted ses reahes he database blocing unknown SOL myecion aac and the use stolen login redentas Recommended como include + Audi al senstive operations including privileged user actives ‘Aut access to application data that bypasses the application Enerypt data to prevent out-of-band access {Mast sensitive data for test and development environments {Restrict databace administrators trom acersng highly sensitive dts ¢ flock the ure of aplication login credentials from otsde ofthe aplication 1 Monitor dstabate acy for anomalies Detect nd prevent SOL Injection tacks ‘valuterOrscie Aust Vaul and Oatabare Firewall Oracle Advanced Security, Oracle Dts Mashing and Subseting, Tables Detected within Sensitive Category: BIOGRAPHIC INFO - ADDRESS Summary Found BIOCRAPHIC INFO - ADDRESS within $1 Columa() in 17 Tables) ‘So-coomasss, sovi uoci0iOns, ar-cOiNraits, ix tocnsTOns,75.AQ5 ORDERS queurraBLe ‘Aoowrsses, iooninstoonie Seaces, ee coérowinss Figure 3-2: Recommendations for protecting data The Sensitive Data Assessment report also provides schema, table, column level details, and statistics to help understand where the sensitive data is and how much you have in the database, These results can be used to implement appropriate security controls to protect sensitive data. Discovering sensitive data using Data Safe Oracle Data Safe, a database security cloud service introduced in Chapter Two, includes discovery capabilities for several country-specific identifiers such as Brazil, Canada, France, Germany, India, Italy, México, Netherlands, Portugal, Spain, the UK, and the US. You can also create your own custom sensitive types and categories. Figure 3.3 shows a sample data discovery report generated by Data Sate.‘ED 47/4707 7 EWA © 9° FO TMHR no UY ORACLE ‘Seraecaac mama | Te Teta SAAN 7 D Sensitive columns. Figure 3-3: Data discovery report in Oracle Data Safe Data Safe scans column names, comments, and data values. Data Safe further identifies relationships between primary and foreign key columns and includes those in the sensitive data model (SDM). Data Safe also allows you to Use non-dictionary referential relationships defined in the application to find sensitive columns. Sensitive Data Models in Data Safe Data Discovery reports provide totals of sensitive tables, columns, and values and details about the sensitive columns. The sensitive columns are categorized based on their sensitive types. These results are stored as a sensitive data ‘model (SDM), allowing it to be shared or reused. You can optionally store metadata in a sensitive data model, including sample data and estimated row counts -depicted in Figure 3.3. This information gives you a perspective on the quantity of the different types of sensitive data in your target databases. When changes accur on a target database, you can perform incremental updates to its sensitive data model, add and remove sensitive columns from the sensitive data model, and manage the referential relationships between the sensitive columns. Data Safe also allows you to start discovery with a smaller scope (e.g, just looking for sensitive ‘types of just one sensitive category or only scanning select database schemas) and then using incremental discovery to broaden the scope of the discovery and the sensitive data model, You can download a sensitive data model, modify it offline, and then upload it into the same or other Oracle Data Safe regions. A sensitive data model is associated with one target database at a time, although you can change that target database as needed,OAM EEA EWN ay “EP 77/477 QEOASZR. &. ORACLE ‘Sensitive data models Figure 3-4: Data discovery sensitive data models Sensitive data models help you design other security controls, such as data masking, auditing, and fine-grained access controls, For example, you can define a masking policy using a sensitive data model to mask the sensitive data on target databases. You can reuse a sensitive data model for multiple masking policies. After discovering sensitive data for a target, you can also get visibility on who accessed sensitive data (if you also have audit policies on those objects) via the Activity Auditing reports, Oracle Data Safe lets you quickly drill down from the sensitive data model to the user activity report. You can also view the sensitive data activity report to review access to sensitive objects across your target databases and all sensitive data models. Discovering sensitive data using Audit Vault and Database Firewall Oracle Audit Vault and Database Firewall (AVDF) assists you in discovering sensitive data and privileged users in Oracle Database. Like DBSAT, AVDF scans column names and column comments. Unlike Data Safe, AVDF does not scan column data, Sensitive data scans are done by scheduling the User Entitlements and Sensitive Object discovery jobs. The sensitive data list could be used to determine how you will protect that data. Audit Vault and Database Firewall can also use the sensitive data list for multiple purposes. Once the privileged users and sensitive objects have been. discovered, they can be added to the Database Firewall privileged user and sensitive object sets, respectively. These sets are global and can be used in multiple Database Firewall policies. As an example, a Database Firewall policy can: ‘+ Monitor user access and their operations on sensitive data ‘* Block unauthorized access to sensitive data ‘* Monitor sensitive data exfitration attempts, Data Privacy reports leverage the discovered sensitive data and audit policies that capture actions on the identified sensitive objects, With the Data Privacy reports, you can view the following: ‘+ Sensitive Data: Target name, schema name, column name, and sensitive type © Activity on Sensitive Data: Displays details about activity on sensitive data by all usersae ORACLE + Activity on Sensitive Data by Privileged Users: Displays activity on sensitive data by privileged users seme = Figure 3-5: Sensitive data report Discovering sensitive data using Enterprise Manager The Application Data Modeling (ADM) feature in Oracle Enterprise Manager (EM) can identify sensitive data present within an application and where it resides within the database schema. Like Oracle Data Safe, ADM examines column names, comments, and data to discover sensitive columns. This helps drive down false negative and false positive rates associated with the data discovery process. For example, ADM can help locate credit card and national identification numbers based on the column name, column comment, and data. Discovering sensitive columns and referential relationships ‘ADM uses sensitive column types to perform pattern matching and identify sensitive columns. Users can review the discovered sensitive columns and manually add additional columns to the list if required. Figure 3.7 shows a list of discovered as well as user-defined sensitive columns. sm + vows hat. Kran onto Oaeme eoeson eter Ipe Comme coment oe omone om ame cra tte ae omones moe ROMO eet tends caren ovo a" enon ae rete oer Fatenctewencu ct Figure 3-6: Sensitive columns discovered using Enterprise Manager ADM ADM analyzes the referential relationships between application objects using foreign key constraints defined inside the database. It also allows automatically discovering application-level referential relationships not defined in the database. Users can review the discovered referential relationships and add additional relationships manually Understanding such dependencies helps preserve application integrity during data masking by ensuring that the data in the related columns is masked consistently. Figure 3.8 shows a list of parent-child relationships found inside the data dictionary.‘ED 77/477 SEWAGE © OOM D)—lUe NF ORACLE ‘Application Object (Columns KeyTyoe Source sam tera i) counrnics ‘coun 0 Paw Dictorany open Locarions ‘coun JO Dependent Ditonay som DEPARTMENTS DeARTIVENT.10 Parent ecteray on ewrovees DePARTIMENT.10 Dependent tora, en 00 J4sTORY DePARTMENT.10 Dependent Ditorary sem ewpovees euP.oree 0 Pent Detoray in DePaRTIENTS MaNuceR 10 Depentot ——Ditoray pen eurovees MANGER 10 Dependent Ditoray en 08. JasTory eurvoree0 Dependent Ditonay joe customers, {ACCOUNT MGAIO operant eter ago conven SALES REPO Depentot ——_Oitorany Figure 3-1 Referential relationships Figure 3.9 puts this all together. ADM automatically discovers sensitive columns, database-defined referential relationships, and application-level referential relationships and stores them in the Enterprise Manager repository. This application data model can be used to implement security controls such as data masking and subsetting. ORACLE 8 a Enterprise Manager C am. rome) Sutmetng —_Expion Database ata @ By otis] commeaay” Me eat soverance ia —__ ‘Appleton eens PES ene ay pass ‘Automated ecovery Figure 3-8: Overview of Application Data Model (ADM) Oracle LiveLabs Oracle LiveLabs gives you access to Oracle's tools and technologies to run a wide variety of labs and workshops at your own pace. If you want to give ita try on the technologies discussed in this chapter, please goto: ‘© Database Security Assessment Too! © Get Started with Oracle Data Safe Fundamentals © Audit Vault and Database Firewall, * Data Masking and Subsetting (including Application Data Model)5 8 HIPAA, ORACLE Summary Understanding sensitive data is an important step in implementing appropriate security controls to protect data, Oracle provides multiple sensitive data discovery tools: Database Security Assessment Tool (DBSAT), Oracle Data Safe, Oracle Audit Vault and Database Firewall, and Enterprise Manager (EM) Application Data Modeling. DBSAT is a lightweight, easy-to-use tool that helps quickly analyze the sensitive data in a database and Understand the risk. It automatically identifies sensitive columns, classifies them into risk categories, and provides detailed reports. Oracle Data Safe offers a comprehensive data discovery feature and is recommended for discovering ‘sensitive data for Oracle databases in the Oracle Cloud, 3rd party clouds, and on-premises. The discovered sensitive objects can be leveraged to review access to sensitive objects in the activity auditing reports and to mask sensitive information in your non-production databases with Data Safe. As Data Safe is a cloud service, ‘customers do not need to manage infrastructure and can use Data Safe APIs to address complex use cases. AVDF leverages DBSAT for sensitive data discovery, integrates the discovered objects into Database Firewall policies, and provides data privacy reports. ‘The Enterprise Manager (EM) Application Data Modeling (ADM) scans are similar to Oracle Data Safe and suitable for customers required to keep all security data locally. Overall, these tools help discover and classify sensitive data, enabling users to implement security controls effectively, minimize security risk, and address requirements associated with regulations such as CCPA, EU GDPR, PCI-DSS, and.ORACLE Chapter Four Authenticating database users ‘ED 77/477 SEWAGE © OOM D)—lUe NFLA MP 774A’ 7 TARE © 2 5 ORACLE Introduction ‘A fundamental step in securing a database system Is validating the identity of the users accessing the database (authentication) and controlling the operations they can perform (authorization), This chapter discusses how a proper authentication strategy helps protect the users of databases and the data within from attackers. It also explains how to manage the user accounts, whether locally within the database or with centralized external services, such as a directory service or a cloud identity provider. The next chapter will focus on user and application authorization to the database, controlling what the user or application can do within the database. Users: Your weakest link The easiest (and unfortunately most common) way to hack into the database is to impersonate an authorized user on that database. Some of the common techniques include: ‘+ Apply social engineering to capture account credentials: With targeted phishing attacks, hackers can target ‘end users or database administrators (DBAs) in an organization (who are easy to find via social media ‘channels such as Linkedin) and steal their credentials, Generative Al (GenAl) makes this task even easier. ‘+ Try passwords used on other compromised sites: Many users use the same password across multiple applications or websites, and if any of them get compromised, attackers can try those passwords to attack your database. ‘+ Find hardcoded database connection information: Applications frequently connect to a database using ‘embedded database usernames and passwords or store these credentials in a clear text configuration file Because application servers tend to be closer to the network edge than database servers, they are frequently ‘easier to hack into. Compromising application service accounts allows hackers to exfiltrate, modiy, or delete any data that the account can access. ‘+ Use default or published passwords: Hackers can try common default passwords to connect as users and use their privileges to access sensitive data, ‘+ Run brute force password attacks: By trying combinations of known passwords and their variations, hackers ‘can break into database accounts with weak passwords when there are no limits on password retries. Brute force attacks are much harder as the database implements exponential backoff on incorrect passwords, but the possibility still exists. Without enforcement of complex passwords, some users may use passwords that are easy to guess, such as ‘password! and ‘Oraclet23. These attacks are not necessarily sophisticated and can be executed by “script kiddies.” Still, they give hackers at least, ‘as much access as that user, and perhaps more if the attacker is even minimally skilled, We will address most of these potential attacks later in this chapter. Database authentication methods Oracle supports different means of authentication, including hashed passwords stored locally in the database or with centralized directory or identity services, Users can also be authenticated by the operating system or external ‘authentication services, including the OCI IAM and Azure AD cloud identity providers, Kerberos, public key certificates, and RADIUS. Passwords are used for one-way user authentication to the database. In contrast, Kerberos, public key certificates, and certain access tokens involving authentication via a third-party service may provide additional layers of protection beyond simple password checks. While passwords are convenient, it may be easier to compromise a user'sMP 77/47 0/77 SWAG O° FER 2. UN ORACLE password than their Kerberos or PK\ credentials, We will describe later how to increase password security through stronger password profiles, Once the user is authenticated, the user is mapped to a database schema consisting of tables, views, indexes, and procedures and then granted appropriate authorization through roles and privileges. The schema and the user are the same entity when using local database password authentication. When the user logs into the database, they are connected to their own schema. When authenticating users with a directory or identity service, users either get their own dedicated database schema (exclusive mapping) or get mapped to a shared schema (shared mapping). Although we won't talk about authorization until Chapter Five, this is a good time to mention that database roles (collections of privileges) can also be managed in the database or, in some cases, managed externally in a directory service, through OS groups, or within a RADIUS server. We'll talk more about roles late. The following table lists the database authentication methods and associated mappings to schemas and roles. Pere) Database Password Sa ‘Schema is the same as user Coon? Managed in the database OS Password Database maps the user to a schema Managed in database or through OS groups Kerberos Database maps the user to a schema Managed in database Public Key (PKI) Database maps the user to a schema Managed in database RADIUS Database maps the user to a schema Managed in database or through RADIUS server Oracle Directory Services Managed in database and directory service Managed in database and directory service Active Directory Managed in database and directory service Managed in database and directory service OCIIAM Managed in database and identity service Managed in database and identity service Azure AD Managed in database and identity service Managed in database and identity service Table 4-1; Database user authentication and authorization methods Making users resistant to attacks With password authentication, users are expected to remember and use complex passwords and enter them when needed. Different passwords should be used for different databases, and the organization should prohibit sharing database passwords, However, administrators and regular users are attracted to convenience and shortcuts, and hackers are ready to exploit such human behavior. Below are mechanisms that put constraints on this potential weakness. Problem: Storing plain text passwords With password:- based authentication, users provide a password when they connect tothe database, but applications, tmiddle-tir systems, and batch jobs cannot depend on a human to type inthe password. Inthe past, a common but insecure way to provide passwords was to embed usernames and passwords in code or scripts, However, this increased the attack surface ofthe database, and people had to ensure the scripts were not exposed. Also, changes to the scripts were required if passwords were ever changed. Secure External Password Stores (SEPS) attempted to solve this problem by storing various authentication credentials, including passwords, private keys, and certificates in an encrypted file form known as an Oracle Wallet. With SEPS, the users need remember only the wallet password, which then unlocks all remaining user credentials ~ potentially for multiple databases. Applications and database servers could also use the auto-login form of the wallet for 24/7 access to credentials. With wallets, the database passwords were no longer exposed on command-lineLA | MP 774A’ 7 TARE © 2 BE ORACLE history or in clear text configuration files. Someone with access to the operating system could not easily discover them. Unfortunately, the SEPS wallet still resided on the application server or client workstation and was only protected by the strength of the wallet passphrase. An attacker who stole the wallet files could use brute force tactics to eventually open the wallet and read the credentials, Over the last few years, secrets management ~ a more modern and secure way to handle password storage and distribution - has become popular. Using a secrets manager like Key Vault, users and applications may retrieve credentials from the Key Vault using an API call. This way, the password is centrally managed and never stored on the application server or user workstation. For those applications that stil use password-based authentication, using a secrets manager is the recommended way to manage the storage and distribution of credentials. Problem: Sharing accounts and passwords Application administrators often need to connect to an application schema for maintenance. If there are multiple application administrators, they all typically know and share the application username and password. If there are multiple DBAs, they also sometimes share passwords. Sharing passwords may be convenient, but it provides no accountability and makes auditing and investigating issues difficult, Proxy authentication solves the problem of allowing an administrator to act as the application account without the ‘administrator knowing the account's password. With proxy authentication, a database user can act as another user working through their own account. Audit records stil reveal the actual end user, and access control policies can consider both the true end user and the proxied account. Proxy authentication helps hold individual administrators accountable. When authorized for proxy authentication to the application account, administrators first authenticate to the database with their credentials and then proxy to the application schema without knowing the password for the application schema account. For example, alice_appdba connects using their password and assumes the identity and privileges of the hrapp schema by proxy as follows: SQL> CONNECT alice_appdba[hrapp] Enter password: The audit records now show hrapp as the DBUSERNAME while the alice_appdba user is recorded as the DAPROXY_USERNANE, The proxy username is also available for policy-driven access control mechanisms like Database Vault, Label Security, Data Redaction, and Real Application Security (discussed later in this book), You can use Oracle Key Vault to securely store and manage database account credentials for application use. Key Vault eliminates the overhead of managing, updating, and protecting Secure External Password Stores (SEPS). OKV allows you to centralize your credentials instead of having local SEPS wallets spread across all your application servers. OKV, acting as a secrets manager, also simplifies password rotation and doesn't require a permanent password footprint on every application server. For those applications that require the use of username/password for authentication, this is the recommended approach, Problem: Poor password hygiene ‘Sometimes, users use very weak and short passwords, making it easy for somebody to guess the password and access their account. User profiles can be used to create a common policy of password and resource authorization parameters for user accounts. Each user account can be associated with a selected user profile to simplify the management of common policies across an organization. Database users always have a profile assigned. The default profile is assigned if no profile is specified when a user is created. The sample profile below (org_profiile) incorporates both password and resource authorization parameters.