If you're anywhere near the security space you've heard it: "Security slows everything down." And while we may roll eyes and offer up a quick, "yeah but..." in some cases, we know that sentiment can be true. Of course businesses need security; and of course security is expected - but I often find myself challenging the bias that security has become an anticipated barrier in the pace of development. After all, security exists to enable the business to achieve its goals, right?
It has to work
I’ve been in eight industries over the past 20+ years and one constant observation is that development teams are incentivized by speed and function. It just has to “work,” and it has to work fast. Security, which requires hygiene and design time to consider various threat vectors and attack scenarios, is often put on the back burner - something that’s bolted on at the end or left as a remediation feature when findings from a scan or a pen-test come through, often with a higher cost to fix. Rarely do companies embed security into the development process itself. For companies embracing this effort – to truly bring security into the definition of function and quality - it’s always a challenge to support speed. As security pros, we have to find a way to embed security into technology and processes with as little friction as possible to help the business meet its goals. While noble and common sense - when staring down years of security and technology debt, or complex hybrid architectures, the problem - while basic in principle- is daunting on the execution side.
Start with the data
For many shops, guarding against the misuse or breach of sensitive data is top of mind. Although it’s a strong focus for companies, interestingly, very few know what their sensitive data is and even fewer know where it is stored, how it is used, and who has access to it. As companies develop more products over time, merge with other companies, and blend their infrastructures between on-prem and the cloud, we see less clarity on what data is valuable and even less consistency on how it's protected.
Why? Speed.
As more applications are developed, and even more become aged, companies lose track of maintaining the metadata or records of what each application stores, accesses, and uses. Definitions of “sensitive” evolve and in the absence of resources, maintenance, and focus, hygiene and organization of these principles erode over time. We see an increase in scope for types and amounts of data being collected, stored, and shared without a strategy in place on how to safeguard it. Data stores become commingled, multiplied and shared in unintended ways; applications start to creep in scope and access. Labels and tags start to lose consistency and become less useful. For example - one application might label a social security number as “SSN,” while another might tag it as “TIN,” “National ID,” or any variation in between. The result? Repeated data calls (what does this app do?), increased audit scopes, longer IR investigations, slower response and containment. "I don't know what's relevant so everything is." Basically – a blind mess.
How do we fix it? Data Store and Object Security
Well-intentioned companies will eventually embark on efforts to “clean up” their data starting with the applications and what they access. This usually takes a herculean effort, but as new applications are developed or acquired, and established ones grow in features and scope, the hygiene degrades over time.
What if we started with a different approach? Instead of looking at the application, what if we looked at the data stores themselves? Instead of trying to define rules and entitlements around the connector, why not focus on the treasure and build defenses and hygiene around that first?
If we focus attention on the data itself, then we can learn what uses the data, where and how it should be stored, and more importantly - what and who should not use it and how it should not be stored. Developers would not have to continuously define metadata around what their application touches - resulting in faster, cleaner development. If companies understood data sensitivity and relevance at the field level, then answering the question “what is in scope?” for an audit, to meet regulation requirements, or to avoid a data breach would be easier and less time consuming.
As more companies embrace the importance of “watching the data,” there will be less need to choose between speed and security. The long-term goal is to see these priorities being met simultaneously and with equivalent emphasis.
Anne Marie Zettlemoyer, vice president of security engineering, Mastercard
