"If we guard our toothbrushes and diamonds with equal zeal, we will lose fewer toothbrushes and more diamonds.”
- McGeorge Bundy, National Security Advisor to President John F. Kennedy and President Lyndon B. Johnson
It’s no secret that most of us operate with a finite security budget and are constrained by our security resources. There is only so much time in the day, and only so many skilled people that we can assign to projects. That’s why prioritizing our investments is so important. We don’t want to invest so much in protecting our toothbrushes that we don’t take care of our diamonds!
When it comes to cybersecurity, databases are like diamonds. Databases have large amounts of data – frequently sensitive, and often the MOST sensitive data your organization deals with. Databases are designed for easy retrieval, analysis and storage of that sensitive data. Compare the level of effort required to search for sensitive data in a database with the level of effort required to search for similar data in a file system directory of documents – there’s no contest!
The level of data risk inherent to a database is almost always higher than the level of risk for a laptop or mobile phone – yet we typically see far more attention and resources invested in protecting relatively lower-level threat vectors like endpoints. That’s like prioritizing toothbrushes over diamonds! If your security program can’t confidently state that your databases are protected at least as well as your laptops, then you may have a problem with how you are prioritizing your security investments.
Not all databases are created equal, just like there are some laptops that are WAY more important than others. In selecting which databases to invest in additional security for, we typically evaluate:
- Regulatory requirements for the organization
- Specific regulatory requirements for data within the database
- Types of and amounts of sensitive data contained within the database
Many organizations operate in sectors where security controls are mandated externally, by regulators. That might be because of a law, an industry regulation, or contractual obligations. I’ve long ago given up on beating my head against this wall – I might meet with my organization’s legal counsel to validate that the requirement applies, and if does, then I just do it and get it over with. While I’ve had limited short-term success in avoiding regulatory requirements that don’t make good business sense, in the long term it’s almost always more effort to demonstrate that the requirement doesn’t or shouldn’t apply than it is to just comply with it.
Determining types of and amounts of sensitive data feels to me like actual value-add work. I’ve always been more of a blue-team (defense) cybersecurity player than a red-team (offense) person. Evaluating the risk inherent to a data store based on the nature of the data contained within that data store, along with the access paths open to that data, is the heart of blue-team cybersecurity operations. Evaluating risk based on the types of and amounts of sensitive data takes us back to the first paragraph of this blog – sorting out the diamonds we’re going to invest in from the toothbrushes that we try not to spend too much time on.
There are lots of tools that scan a database to evaluate sensitive data types and amounts, but this blog post isn’t going to cover any of them! Instead, let's focus on what we do with the results of those scans.
Using your assessment of sensitive data contained within the database, combined with your evaluation of the risk associated with the access paths open to that data, assign a risk-classification to the database. You probably already have a classification system in place – it might be something as simple as bronze/silver/gold or public/internal/restricted, or more complex like public/internal/confidential/restricted/highly restricted. If you do have such a system, use what you have; don’t create something new. That way you can piggy-back on existing organizational awareness of your classification scheme, and possibly even reinforce it to help with security across all assets, not just databases.
Next, create a control matrix based on your classification. Not every database will need the Maximum Security Architecture, but most databases need some level of security. Does this level of risk require encryption in motion? At rest? What level of auditing is appropriate? How frequently will you check configuration to assess drift? How will you manage periodic privilege and access reviews? This control matrix forms the basis for your database security posture and strategy.
The hard part is now done – from here on out it’s a technology issue – implementation of your policy and tracking exceptions.
Don’t forget – databases are your diamonds! Let’s protect them accordingly!