Day Zero Security

September 02, 2022 byShane Curran

At Evervault, our mission is to encrypt the web. To achieve this, we need to move security from being something layered on once a product is built, to something integrated into software from the very beginning — Day Zero.

Most developers recognize the importance of protecting their data and infrastructure from potential hackers. Stories of data breaches, regulatory fines, and hacks flood our newsfeeds and remind us of the need for proper cybersecurity. The challenge is keeping up with the latest exploits and attack vectors, as doing so requires swathes of security engineering teams and superhuman foresight.

In this post I’ll cover:

  1. Why companies fall into the trap of not taking security seriously from Day Zero
  2. How security and compliance exist in tension
  3. How most companies “solve” security today
  4. Why encryption is the most important tool in security

Security is on the roadmap

Why companies fall into the trap of not taking security seriously from Day Zero.

As developers, we’re under constant pressure to quickly ship new products, features and bug fixes to demanding customers. This pressure is most felt by developers working at early-stage companies, where delivering a feature on time can be the difference between winning over or losing out on an important customer — shipping fast is a means of survival.

Asking a developer whether they care about security almost seems like a rhetorical question, and most developers respond with a resounding “yes”. So why do we still see so many data breaches, if developers are majorly concerned about security?

The answer isn’t as straightforward as you might expect. The simple answer is while security is almost always a priority for developers, it’s rarely priority #1. I’ve lost count of how many times I’ve heard a developer or startup founder say, “Improving our security is on the roadmap. We just need to ship some new features first”. This sounds fine, in theory — why should they care about the risk of a data breach if there’s a risk their company won’t exist in the absence of the Next Big Feature? The problem is there's always another feature on the roadmap which takes precedence over security.

Startups are generally great at shipping new features and products their customers love — at least in comparison to their more established counterparts. This speed is partly because they are focused on survival, and product is their only method of meaningful differentiation (given resource constraints). As a result, the Next Big Feature always ends up becoming the priority.

After a period of successful building, the focus on survival suddenly turns to a focus on growth — customers keep knocking on the door looking to buy your product, and all of your KPIs all move in the right direction. Overnight, founders go from selling to other start-ups to enterprise customers who ask you to fill out a security questionnaire before they even look at a demo.

At this point, founders have the jarring revelation that they need to “become compliant” — fast. They rush to Google and spew in the alphabet soup of compliance certifications — SOC 2, ISO 27001, PCI DSS, GDPR etc. Six-figure deals hang in the balance — especially when their potential customers see security as an afterthought to their business as they scramble to show they have done the groundwork (even when they haven’t!).

Typically, startups buy compliance automation software from providers like our partners Vanta and Secureframe, find an auditor, and get their compliance certifications quickly — all is well, right?

“We’re secure now, our SOC 2 auditor said so!”

Compliance ≠ Security

How security and compliance exist in tension.

Some time passes, and you meet a Head of Security who looks like somebody who sits in the back row of a DEFCON talk (while wearing a hoodie emblazoned with the logo of an esoteric Linux distribution). Let’s call this persona “Hackerman”.

Hackerman in his natural habitat

Hackerman doesn’t care about your standard operating controls or compliance frameworks. He cares about the technical barriers preventing a potential attacker from getting unauthorized access to your infrastructure. Before long, Hackerman finds an unauthenticated endpoint, a privilege escalation vulnerability, or an open port.

In the best scenario, Hackerman is the friendly Head of Security working for a potential customer. In a parallel universe, however, Hackerman is unemployed and spends most of his time attempting to exfiltrate data from insecure software and threaten to share it on the web if a ransom isn’t paid. In this scenario, not only is Hackerman unimpressed by your product — compliance teams and lawyers are too. What a mess!

Startups are designing security for the compliance teams, not for the real enemy — hackers!

Many founders will then drift mindlessly towards hiring a security team in a dazed panic, which is rarely the best solution. Your product team is your security team; they just don’t know it yet!

Build the wall

How most companies “solve” security today.

There is a common misconception amongst security practitioners that using more third-party security tools and products to help secure your infrastructure will materially protect your company against attackers — let’s call this the “build the wall” approach.

The Walled Garden of Cybersecurity

It’s understandable why those tasked with security at companies feel the urge to build the wall. Whilst under constant pressure from leadership, the board and—most importantly—customers, tracking security progress through heuristics like “number of new technologies implemented” feels like the right thing to do. The challenge, however, is that keeping afloat of new security technologies and products is more than a full-time job. The average security team is using over 70 security tools and there are hundreds of potential security vendors, all of whom protect against different attacks and integrate at different levels of the stack. Despite the sheer number of security tools available to companies, the sad reality is that modern security doesn’t focus on the root problem: protecting the data itself. Instead of building walls around our sensitive data, we should simply keep the sensitive data protected.

The latest challenges in security are a great illustration of the symptom vs. root cause effect. Most security tools are focused on addressing the challenges related to specific symptoms of security breaches, and tools that provide endpoint monitoring, threat intelligence tooling and similar offerings don’t provide any assistance in addressing the root cause of security. In the best-case scenario, they’ll tell you when an attack is happening and maybe actively protect your infrastructure some percentage of the time — but they never make your software truly secure. Fundamentally, addressing symptoms and not root cause is a losing strategy. By going a layer deeper in the security stack and thinking through security from first principles, many popular surface-level security tools are rendered obsolete.

To illustrate how this can be solved easily, let’s refer to the following sample database:

A standard database with data being stored in plaintext

This table structure (and data housed within it) is unremarkable to your typical developer — many of us deal with data this sensitive everyday. Keeping this data safe sounds easy in theory, but most efforts are futile in the absence of viable and robust technology to protect it.

At Evervault, we believe that encryption is the most powerful weapon in a modern cybersecurity arsenal — when implemented correctly.


Why encryption is the most important tool in security.

Thanks to the dramatized portrayals of encryption in movies (like Benedict Cumberbatch’s Alan Turing cracking the Enigma Code in “The Imitation Game”), many of us already have a basic conceptual understanding of what encryption is. The potential gotchas and vagaries in implementation standards are much more opaque — even to a seasoned developer.

In its simplest form, encryption splits a piece of data into two components: the ciphertext and the key. Encrypting and decrypting the original data requires access to both the ciphertext and key, alongside a known encryption algorithm like AES[1].

Anybody who has the ciphertext and doesn’t have the key can’t access the original data. However, anybody who steals the key and ciphertext now has the original sensitive data, as if the encryption wasn’t even there[2]. The key is just as sensitive as the original sensitive data and must be treated as if it was the original secret you were looking to keep safe. All encryption does is split one secret into two, and key management is an extremely challenging problem.

More broadly, implementing encryption properly is hard. You have to:

  1. Pick which open-source library to use (and ensure it is well implemented and tested!).
  2. Generate and store the keys yourself (and deal with all of the “gotchas” involved in handling keys — generation, storage, rotation, deletion and more).
  3. Still handle sensitive data in plaintext before encrypting it.
  4. Decrypt the data every time you want to use it.

Even with just these four steps, encryption is very frequently implemented incorrectly. Worse still, in most cases bad encryption isn’t any better than having no encryption at all.

All of this being said, it’s intuitively clear that data encryption is a good thing. Theoretically, a developer should be able to post their entire database on a billboard and not worry about any sensitive data being stolen.

Posting sensitive data on a billboard wouldn't pose any risks

Taking the previous database as an example, a truly secure database should look something a little bit more like this:

A standard database with sensitive data encrypted at the field level

The structure and data remain exactly the same, but the values of sensitive fields are replaced by the encrypted values.

Developers should be empowered to use encryption, and own the security of their software end-to-end — not pass on the responsibility for security to another person or team. With services like Evervault helping make good encryption accessible, developers have the tools at their disposal. It is now our responsibility to wield them!

Our goal is to make encryption easy to integrate and hard to get wrong, from Day Zero. Ultimately, we hope to encrypt the web — so we can go from a world where Zero Day exploits leak all of our sensitive data to a world where data breaches are a thing of the past, thanks to Day Zero security.

[1] N.B. There are more complicated instances of cryptography, like asymmetric cryptography, but the security model is roughly the same for the purposes of this overview.

[2] Assuming they know what encryption scheme is used—a very straightforward procedure for most attackers. Even in a scenario where a more obscure scheme is used, secure systems should always be designed with Kerckhoff’s Principle in mind; loosely distilled by Claude Shannon as “the enemy knows the system”.