Why Does This Have to Be So Hard? The Trade Off Between Speed and Security

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 many cases, we know that sentiment is true. Of course security is needed; of course security is expected – but I often find myself challenging the notion that security is expected to be a hindrance to the pace of development. After all, security is here to enable the business to achieve its goals, right?

It has to work

I’ve been in 8 industries over the past 20+ years and one constant observation is that development teams are incentivized by speed and function. It has to just “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 is bolted on at the end or left as a remediation feature when findings from a scan or a pen-test comes through often at a much higher cost. Rarely is security embedded into the development process itself and for companies bracing this effort – to truly bring security into the definition of function and quality, it’s always an uphill battle for speed.

…embed security… with as little friction as possible to enable the business to meet its goals.

As security pros, we have to find a way to embed security into technology and processes with as little friction as possible to enable the business to meet its goals. While noble and common sense – when you’re staring down years and 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 companies, security is focused on protecting the data. Protecting the infrastructure, availabilityAvailability is a key aspect of information security, ensuri..., and continuity of business is just as critical; but for many shops that are focused on regulation or compliance as a first step to security, guarding against the misuse or breachA breach in cybersecurity refers to an incident where data, ... of sensitive dataSensitive data refers to any information that, if disclosed,... is usually top of mind.

What is interesting, is that although data security is a strong focus for many companies, 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 and less clarity on what data is valuable and even less consistency on how it’s protected. Why? Speed.

…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 more applications are developed, and even more become aged, companies lose track of maintaining the metadataMetadata is data that provides information about other data.... 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 Stores and Object Security (DSOS)

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, this clean up effort starts to degrade 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?

…focus on the treasure and build defenses and hygiene around that first.

If we watch the data, then we can learn what uses the data, where and how it should be stored, and more importantly – what should not use it and how it should not be stored. Doing so would mean that developers would not have to continuously define metadata around what their application touches – resulting in faster, cleaner development. If companies were able to understand 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 breachA data breach is a security incident in which sensitive, pro... 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.