Now we are at my favorite part of the book where I recruit you all to switch over to the security side. It is an area that you have to be passionate about because some days there is just one grant too many, but if you are a control freak and like solving puzzles, it is definitely something to consider. Wait, did I just call myself a control freak? Well, most DBAs are, but it is part of our superpowers, and we are just using them on the security side.
Security is everyone’s responsibility, probably something you have heard before, but it is true. Protection of the company assets (data being the focus asset) is for everyone to participate in. The DBAs as the guardians of the data have a unique position and higher responsibility with the privileged access that has been entrusted to us. We have opportunities to drive security initiatives that reduce the risks in the database environments.
A DBA transformation to a security engineer or to the security is a logical step because of the skill sets both technical and soft skills. The database provides ways to secure the data and the DBAs know the day-to-day tasks that still need to be accomplished while also securing the privileged users.
Migrating over to a security team does not mean you have abandoned your DBA friends. It also does not mean that you can play a spy for the DBAs and continue to have possible risks in the environment. Moving to the security team provides the working knowledge and technical skills to leverage the database to secure the systems and reduce risk across the enterprise.
Even though most of the security teams have been focused on network and protecting the perimeter, thoughts of not being able to get to the data have been considered. The database security to look specifically at protecting data assets is now something that security teams are looking to add and take the activity and audit logs from the databases to incorporate that into the overall security posture of the enterprise. The problem is a shortage of security engineers and qualified individuals to join the security teams, and plenty of people are needed because of the work and growth in this area.
DBAs transforming to the security team bring a greater understanding of what jobs need to be accomplished while being able to secure the data.
Just watching the news and seeing the next data breach has convinced companies that they need to invest in security and make it a priority. That doesn’t mean there are always resources, like people or time from other teams, but working on security allows the DBA to help prioritize the project and security work for the databases.
There is education that happens with security teams too. Depending on their backgrounds they might have different expectations of the database security, and clarification is going to allow the right security rules and policies to be put into place. There are even defaults that come with databases that should be discussed with the security team to take advantage of already existing security and look to what can be standardized across the enterprise.
Building a Team
There will be opportunities to build out database security teams . The team will work closely with the security teams to understand the auditing issues, policies, and priorities in the company for the security projects. The team will also work closely with the database teams as they will be part of the solution and project, whether they will be implementing it or observers of it. Remember the discussion of the soft skills that DBAs have naturally developed over the years, this is the perfect opportunity to utilize them. The collaboration between teams and communication will allow the DBA to transition to security and work on building a team of security engineers for implementation of database security.
The characteristics of a team are enterprise thinking, database skills, and willingness to continue to learn and research. Enterprise thinking is important because in large environments, manual processes are not going to be sustainable. The big picture is to include all of the possible database platforms and minimize solutions. Definitely not one solution fits all mentally, but how can a solution support and automate as much as possible to cover ground on many databases.
Teaching database experience is one way to develop this characteristic on the team, or teaching security is the other way to go. Most DBAs have been exposed to security just from the grants and roles that are created in the database. Also teaching an area that is not the main focus of the tasks might distract from the understanding of the database. Either way, a database security team member should have experience in one area and be able to learn in the other.
There are always new and not-so-new ways to use exploits and vulnerabilities. There are new tools that might make security easier. Just as with the database environments and how DBAs have constantly been learning the features and new releases, the security team is constantly researching and learning – good skills to have as a database professional, technology person, even just basically in life.
Security on DBA Team
Another option for database security is to take a couple of DBAs and just designate them with the security role. They would not shift over to the security team. This helps with some of the implementation of the security products and the DBAs with the security role can handle this effort. However, in being on the same team there might be a conflict of interest and the separation of duties might become blurred.
Staying as a DBA with just the focus of security can also make it difficult to just focus on security. Other priorities come up and other tasks might get in the way of the security. There are ways with roles to separate out Security DBAs from System and Application DBAs, so use of these roles will make it possible to only have the access needed. With these separations of duties for the DBAs, the reporting structure up to the database or security teams might not be as important.
Coordination with both the security and database is important. Knowledge and understanding of the database is important to have in order to effectively implement various security products and options. After team decisions are made and set up, the next step is to look at the security to be implemented and see how transforming from DBA will make sense.
Securing the database environment is a process. There are several configurations and products working together to provide the security. The planning needs to match up the enterprise security policies, compliance, and regulations with what is being implemented. Examples of standards can be found in the National Institute of Standards and Technology (NIST) Cyber Security Framework , if one set does not exist in your company. Even if one does, it might be worth evaluating it against the NIST cybersecurity framework.
Figure 6-1 stacks the different focus areas for these policies and what the security projects are going to fall under for implementation. They highlight the issues with the database environment that needs to have security wrapped around it for protecting the data.
Figure 6-1 Main Areas where security is needed
Authentication and authorization will handle password management and level of privileges. Ideally this would be a centralized repository for managing the users in the database. For Microsoft SQL Server, this would typically be Active Directory, and for Oracle either Oracle Unified Directory with Active Directory or other LDAP for users. The database user can be stored in one place and have security privileges managed with group access.
Data protection covers data at rest, in transit, and when accessed in the databases. Encryption of data at rest and in transit will protect the data files. Highly privileged users need to be handled differently to prevent unauthorized access to sensitive data. Activity monitoring sits on top of these configurations to confirm the proper controls and audit access and activity.
Regulations and compliance rules might be different for the location of the data or new rules might apply. It is a piece that security professionals need to understand the business, data, and requirements for the environment to comply to these regulations. For example, the General Data Protection Regulation (GDPR) will require any company with data from a citizen of the EU to comply with the regulation. The regulation needs to be reviewed and processes will need to be implemented to handle reporting a data breach within 72 hours of becoming aware. Notification is not the only process but the removal of the data from the system can also be requested. Security teams need to work with the database teams to get these processes and rules in place. Knowing the database like a DBA is definitely going to accelerate the ability to accomplish this.
Vulnerabilities and risk can be reduced with patching and maintaining the secure baselines. Patching has become easier for several database environments but still requires testing and managing of users’ expectations of what maintenance windows and outages may occur. It is important to consider that the security fixes patch-known vulnerabilities so that reduces the risk in the environment.
Analyzing the risk in an environment helps to decide priorities and recognize the risks that are there. It allows for evaluation of the effort to reduce the risks and possible outcomes if it is not addressed. With all of the moving parts and how access is needed to the data, it is not likely that a database will be 100% secure, unless there was no access allowed to the server or database, and even then what if there was a backup that could be compromised.
The experienced DBA brings important understanding of the risks in the databases. There is knowledge about gap and if certain configurations are implemented how that protects or leaves other gaps in the environment. As DBAs are transforming to security, additional work is done focused on security to manage risk, where previous experience is focused on performance, resources, or other component of the database. This is a combination of the soft skills that are developed by the DBA to research the environment, create a plan, and communicate with various groups the discovered details and proposals of what to do about it.
For reducing risk, this is a high level of activities that are performed, including a loop back to review and test again.
Understand the Risk
Develop Mitigation Plan
Report the Issue along with Mitigation Plan
Evaluate Cost (Time/Money/Resources) to Mitigate
Review Risks Again
Security planning is based on this research of the risks in the environment and what has already been implemented to protect the data. Again, it is a continuous process to reduce risk in the database environment. Implementing security options, configurations, and products will work in preventing access to the data or performing malicious attacks on the environment.
Monitoring is a way to start to reduce risk and be able to know what is running and verify the configurations. The next step would be to be able to proactively handle the risk, and block malicious activity or unauthorized access from happening. This is a process to first understand which view into the environment helps to protect, then actually blocking and preventing for additional risk reductions. The process continues to monitor if there is any other activity that needs to be blocked. It almost sounds like a tuning process or troubleshooting, and it is very similar just focused on security.
The Security DBA will be able to identify risks, plan to mitigate the risks, prioritize, and communicate the risk and details of the remediation steps.
We already discussed cloud database security in the previous chapter. However, as part of the security team, the scope is to incorporate the security plan of the cloud databases with policies to the overall security posture. The security offerings of the cloud need to be implemented and it is part of the security team to validate that the features are being used. The Cloud DBAs will be implementing the features and the Security DBA will be able to monitor and audit the security as seen in Figure 6-2. The cloud environment does simplify and reduce risk because of the automation and baselines that are implemented.
Figure 6-2 Standardization Security in the Cloud
Cloud database provide the baselines, and in a similar role the security professional can influence the options and levels of security that are needed in the cloud. These would be deployed consistently across the databases, which does simplify the auditing and validation of the security configuration.
Oracle database cloud will be providing databases that are autonomous and learning to handle malicious activity on the database. The computers are being trained to recognize this abnormal activity and can react faster than receiving an alert and especially read a very large report. The database can patch itself and apply the security fixes and not wait for a DBA to schedule a maintenance window, and they can still have the data available. This doesn’t remove the need for database knowledge, as security and others are discussed in this book as opportunities to use these skills and gain new ones. Instead of having to worry about applying the patches, the focus can be other risks in the environment.
With databases in the cloud, security options should be researched, implemented, and validated. Options for the database in the different cloud providers can provide various levels of security. The Cloud DBA would be implementing the security options and the Security DBA will be reporting and verifying it.
Auditing and Reporting
Auditing can be accomplished in many ways, and the audit or reporting is only useful if it is being used. The security reports need to be reviewed for the abnormal activity and drift in configurations. Notifications and alerting would grab the attention of the security team to start drilling into any issue. These are all components of the monitoring and auditing from the security side. Policies are put into place for gathering details around highly privileged users and execution of certain activities. For many databases it is not something that can be accomplished manually, but it needs to be looked at analytically.
Security Information and Event Management (SIEM) tools can be used to gather these logs and analyze the data from the security logs for trends, which are behaviors to detect anomalies. DBA transformation to learn SIEM tools is a great possibility and leverages SIEM to report on the needed information and weed through the noise of a busy databases.
Configuration drift is part of the audit and checking because even if there are controls in place, there might be unauthorized access, a gap before the next level is implemented, or a new exploit being discovered. Auditing the configurations and baselines will be needed for the audits and provide opportunities to address the issues and understand what else might be happening. The security team can also be updating baselines as new features are implemented or change in versions or platform of the database require new standards.
Audit policies also need to be implemented and researched by the security team. They can make sure that as databases and applications change, the right information is being captured. There might be other information that flows through the SIEM tool that is gathered to provide even better policies and other details. Audit policies are based on the enterprise policies and what is being met in the security tool implementations. Checks and validations can be set up to automatically check and report on.
Individual policies and databases are not going to each be examined by the security team. They need tools and automation to make this happen. Just as with the new offerings from cloud databases, the trend is for the database and technology to handle the work. Self-driving databases are what Oracle is talking about. This gives us the answers and information, but policies and some of the actions need to be determined by the Security DBA. It can let the database patch for remediation of known issues but processes need to be developed for automation and included to match up processes and checks.
With the amount of security and audit logging, automation of reviewing to provide alerts or proactive changes needs to be part of the database environment for security.
Addressing vulnerabilities is not just about patching, ok mostly about patching but it does require some additional information. As risk is being reduced in an environment through other security measures, it might not be as easy to exploit. The pieces and controls in the environment need to be included in the assessment. Even with database applying its own patches and reducing risk, vulnerabilities that are outside of the software or built into other application code need to be examined.
DBAs are use to testing and working through upgrades and after patching and patch sets are applied. Security fixes might be part of the first set of fixes, but additional areas might be covered as part of a bigger patch set.
Security teams need to take into consideration the various tools, monitoring, auditing, and blocking that is configured to provide weighted details about the risk. Weighted scores for vulnerabilities are part of the Common Vulnerability Scoring System (CVSS) and is from National Vulnerability Database . The list of vulnerabilities and scores are reported here with details about the vulnerability. This information along with any vendor information can be used to assess the risk in the current environment.
The vulnerabilities are another reason that database knowledge on the security team is important, as details of how it can be exploited might not mention much information, but a DBA might understand it more and realize that it is a higher or lower risk then scored.
DBAs enjoy that they are always learning. There are new databases platforms, cloud environments, and new security risks and vulnerabilities. The security teams also have to continue to learn and research the details of possible exploits and research issues that might have happened. There are tools that are being used and with AI, the databases and machines are also learning.
Learning is not just one sided with the security teams. Education has to be passed along to others. The database options are not going to fill in all of the gaps, so education is around what layers of security are handling the different risks.
Instruction around access and process helps to explain how they should be participating in the security in the environment. DBAs are focused on the development or systems of high availability to get their tasks done. They are not focused on the security and even though they may be concerned about the access, they might not know or understand the tools that they have to implement the security.
As the security team, design, process, and documentation need to be created to provide to the DBAs and others using the database to include them in the processes. These will keep the environments consistent and using the same secure configurations. Information around auditing will also help to keep them honest with the procedures and processes as well as protect them from activity that might occur.
Providing new information and project planning for overall enterprise security needs education for the various teams. DBAs will be interested to know the perimeter security around their databases and the other teams will receive information on how the data is being protected. Allow the teams to understand the security requirements and become part of the projects and solutions to support the security initiatives for the databases in the future too.
The Security DBA needs to be able to explain to management about the potential risks and help them to comprehend the priorities of the risk remediation. It is not the same as putting permissions on a file for read, write access. The granularity of the database security is much deeper. The solutions and risk mitigation for the solutions are going to be more complex and detailed. The databases also affect other applications and how they behave so the layers of applications to database must be taken into consideration with the security of the system. Explanations and education up and down the company ladder are requirements for any security professional to help inform and help in making decisions for what comes next.
The Security Professional is going to be securing the database environment. There are serious concerns about the vulnerabilities, issues, and other risks associated with database access and unauthorized access from internal and external sources. Figure 6-3 shows the security solution stack to start with in applying encryption, privilege management especially for privileged users, least privilege roles and groups, monitoring and auditing, and patching that will help protect against vulnerabilities.
Figure 6-3 Security Solutions for the Database
In the cloud or on-premise the database security is a responsibility of a team. The security team can support the enterprise policies and baselines in the database. It is the knowledge of the database that makes it easier to know where the risks are and prioritize the initiatives. The DBA that is transitioning to the security role has the opportunity to learn skills for managing the security and audit logs in SIEM tools. DBAs can utilize their skill set in order to design how to mitigate vulnerabilities and risk in the environment. With automation processes, the monitoring analysis becomes preventative actions to protect the data.