While every company understands this in principle, protecting data in reality is much more difficult. Information is everywhere and is increasing rapidly, with research from IDC showing that data is growing at an annual rate of 58% and is now stored in a wide variety of locations across organizations.
The first step to identifying any vulnerabilities is to find the data, classify it, and assess any potential risks. That means locating every database, whether in production or other environments like development or testing, and then mapping the data within it. Organizations need to understand where the data is, who has access to it and what its level of sensitivity is. For example, while both need to be kept safe, protecting credit card details is clearly a greater priority than safeguarding anonymous transaction data that cannot be attributed to specific individuals.
Eliminate all vulnerabilities
After data has been classified as sensitive and at risk, it needs to be protected by limiting access and making it impossible to share the information widely. While this is central to good DevSecOps practice, it does create a potential blocker to the streamlined processes which DevOps encourages.
Developers often need a copy of the production database to use in development, test, and QA environments, for example. While this is important in ensuring any proposed changes will work smoothly once deployed, production databases invariably contain the sensitive data that needs to be protected.
A workaround could be to copy the production database schema and import a limited, anonymous dataset. This lacks realism or scale, however, so the impact of any changes on the production database cannot be measured effectively. An alternative is to take a copy of the production database and manually mask the data. Again, this has drawbacks. Given the rate of changes to the production database (with many companies deploying multiple times a day or week), this will become out of date very quickly, thus making it unrealistic.
Instead, companies should look to implement data masking measures like anonymization, pseudonymization, encryption and aggregation. There are third party tools that help with this masking process, ensuring that data is protected yet retains its referential integrity and original distribution characteristics.
Adopt a secure coding approach
In the same way that application developers use specific languages (such as C#), so do database developers. For example, in the case of SQL Server they use T-SQL to write the code that creates, maintains and updates their databases.
Individual developers, however, often write T-SQL differently and like to format and structure it in multiple ways, depending on their own preferences and level of experience. This can lead to confusion with different team members struggling to understand what a colleague has written, or even errors being missed, causing deployments to fail.
Ideally, code should be written in the same style, good code that is often repeated should be shared across teams, code from third party sources should be avoided, and static code analysis should be used to highlight errors or bad code as soon as it is written.
Introduce automation where possible
The ninth point on Gartner’s list is to implement strong version control, and that’s just as important for the database. Database code should also be version controlled, preferably by integrating with and plugging into the same version control system used for applications.
The first advantage is that there is the one source of truth for both the application and the database, which shows what changes were made when and why.
The second is that it opens the doors to automation which DevOps encourages and makes the whole development process more secure. When database changes are committed to version control, for example, a continuous integration process can be triggered which tests the changes automatically and flags up any errors in the code instantly.
Embracing the Database with Security
Delivering successful DevOps means embracing the database—but also ensuring that the highest security standards are being applied. Extending DevSecOps to the database is therefore critical to balancing speed and flexibility with protection and compliance, driving faster, more successful releases.