In my previous posts about Building a Culture of Data Protection (
Overview,
Development,
Features,
Expectations), I covered the background of building a culture. In this post, I'll be going over the data protection tools, people, and roles I recommend to successful organizations.
Tools
Given the volume and complexity of modern data systems, teams have to use requirements, design, development, test, and deployment tools to adequately protect data. Gone are the days of "I'll write a quick script to do this; it's faster." Sure, scripts are important for automation and establishing repeatable processes. But if you find yourself opening up your favorite text editor to do design of a database, you are starting in the wrong place. I recommend these as the minimum tool stack for data protection:
- Data modeling tools for data requirements, design, development, and deployment
- Security and vulnerability checking tools
- Database comparison tools (may come with your data modeling tool)
- Data comparison tools for monitoring changes to reference data as well as pre-test and post-test data states
- Data movement and auditing tools for tracking what people are doing with data
- Log protection tools to help ensure no one is messing with audit logs
- Permissions auditing, including changes to existing permissions
- Anonymous reporting tools for projects and individuals not following data protection policies
These tools could be locally hosted or provided as services you run against your environments. There are many more tools and services a shop should have deployed; I've just covered the ones that I expect to see everywhere.
People
The people on your team should be trained in best practices for data security and privacy. This should be regular training, since compliance and legal issues change rapidly. People should be tested on these as well, and I don't mean just during training.
When I worked in high-security locations, we were often tested for compliance with physical security while we went about our regular jobs. They'd send people not wearing badges to our offices asking project questions. They would leave pages marked SECRET on the copier and printers. They would fiddle with our desktops to see if we noticed extra equipment. I recommend to management that they do this with virtual things like data as well.
As I covered in my first post, I believe people should be measured and rewarded based on their data protection actions. If there are no incentives for doing the hard stuff, it will always get pushed to "later" on task lists.
Roles
I'm a bit biased, but I recommend that every project have a data architect, or a portion of one. This would be a person who is responsible for managing and reviewing data models, is an expert in the data domains being used, is rewarded for ensuring data protection requirements are validated and implemented, and is given a strong governance role for dealing for non-compliance issues.
Teams should also have a development DBA in order to choose the right data protection feature for ensuring data security and privacy requirements are implemented in the best way given the costs, benefits and risks associated with each option.
Developers should have a designated data protection contact. This could be the project lead or any developer with a security-driven mindset. This person would work with the data architect and DBA to ensure data protection is given the proper level of attention throughout the process.
Quality assurance teams should also have a data protection point of contact to ensure test plans adequately test security and privacy requirements.
All of these roles would work with enterprise security and compliance. While every team member is responsible for data protection, designating specific individuals with these roles ensures that proper attention is given to data.
Finally…
Given the number of data breaches reported these days, it's clear to me that our industry has not been giving proper attention to data protection. In this five post series, I couldn't possibly cover all the things that need to be considered let alone accomplished. I hope it has helped your think about what your teams are doing now and how they can be better prepared to love their data better than they have in the past.
And speaking of preparation, I'm going to leave a plug here for my up-coming In this session, Thomas LaRock and I go over seven features in Windows and SQL Server that you should be using. Don't worry if you aren't lucky enough to use SQL Server; there's plenty of data protection goodness for everyone. Plus a bit of snark, as usual.
I also wrote an eBook for SolarWinds called
Ten Ways We Can Steal Your Data with more tips about loving your data.
See you at
THWACKcamp!
