3.2 Security & governance

You don't have to be a security genius to deliver secure, compliant applications. You just need a roadmap to follow, a clear strategy and a tactical plan.

Photo by Space Shipguy.

Introduction

Making sure that any new product is safe and secure in production is hard. The security landscape and technology at play is evolving fast. It’s already a complicated space, but more so because new attack vectors and vulnerabilities show up every day. I’ve written about how the explosion of AI is impacting our delivery pipeline and when we should start thinking about security.

Governance brings a new dimension to the conversation. We’re already worried about security, but now we have to plan for governance of our product as well. That touches on compliance. It turns out these topics are tightly connected. In fact, you can’t deliver a secure product without considering compliance too.

When planning our target state security goals, we have to carefully consider how we expect to direct and control them. This is often where compliance comes into the picture. Are we conducting online commerce? Then we need to comply with PCI DSS. Is this a healthcare application? We’ll need HIPAA or PIPEDA. Selling your product to the government or big industry? You’d better look at ISO 27001 and ISO 27002. We’re just getting started.

The good news is, there are already excellent standards, policies and procedures we can follow to guide our hand in building a secure, reliable product. The bad news, there are a lot of them. Decisions will have to be made, and they need to be made before you build the software. If you wait until later, you’ll find yourself doing a lot of unnecessary backtracking and rework.

If you’re new, welcome to Customer Obsessed Engineering! Every week I publish a new article, direct to your mailbox if you’re a subscriber. As a free subscriber you can read about half of every article, plus all of my free articles.

Anytime you'd like to read more, you can upgrade to a paid subscription.

We always think it won’t happen to us

Postponing security and compliance can be alluring. I get it, it’s kind of a headache. Planning your security architecture, looking at different standards, holding a bunch of meetings to talk about the pros and cons of various goals — it’s time consuming. It’s a lot more fun to just code up some features and have a demo, get the applause, and crank out a product.

In fact that’s exactly what one of my clients did. The problem they ran into was the accumulated security and compliance debt — in other words, the cost of going back and fixing it later — just kept on mounting.

What originally seemed like a good decision turned into a really tough burden. “Let’s just get the first version or two out the door, then we can pause and come back to tackle security before we become a real target.”

But inevitably, the lack of careful security and compliance planning meant that “coming back later” would mean ceasing forward motion for a while. The infrastructure wasn’t deployed with secure landing zones, so they’d have to upgrade and reconfigure a lot of servers. Changes in the authentication system would cascade into several different running systems. They’d need a whole new approach to storing personally identifiable information (“PII”), touching just about every product feature. Things that weren’t encrypted or, worse, had been injected into the codebase would need to be encrypted or removed.

The bottom line: the cost of meeting reasonable security and compliance standards kept getting higher and higher. Going back to clean up the debt never happened, and this went on for several years.

And then they had a security breach and critical customer information was stolen.

At that point, the only path forward was to stop development, enter damage control mode, spend time and effort on containing the problem, and invest in what had become a major rewrite. On top of that, the company was dealing with the financial and political aftermath of a public security breach. It cost the company dearly, in effort, time, loss of customer trust, and money.

Their experience draws attention to the importance of an early leadership conversation about cybersecurity. Bolting security on later is a crippling trade off to get some short-term gains. It’s not one a well-informed leadership team should be comfortable with.

If you use the referral button below, you’ll earn free premium access to Customer Obsessed Engineering. Just three referrals will earn a free month!

It’s hard to know how many people, worldwide, have been affected by data breaches. It’s clear the scale is massive. It’s probably in the billions.

The 2024 IBM Cost of a Data Breach Report identified that the average data breach exposed the records of 33,000 individuals globally, with over 4,500 publicly disclosed breaches occurring annually worldwide. That’s almost 150 million people annually. However, this only accounts for known and reported breaches.¹

They also found that the average cost of a data breach is almost $10 million dollars (USD) for firms in the U.S. (the average cost abroad is lower, “merely” half that).

Perhaps more horrifying is how long it takes, on average, for a firm to discover a data breach: about 200 days. That means that after a breach, stolen data is “in the wild” for well over half a year before a firm learns of it, and takes action — taking on average, another 70 days to contain the breach.

If 150 million individuals being hit with a data breach each year isn’t scary enough, here’s another way to look at it: according to Risk Based Security (now part of Flashpoint), the number of records exposed has exceeded 37 billion. There is a little good news though. The same report shows that data breaches in 2020 decreased by 48%, so apparently we’re getting better at preventing them.²

The rest of this chapter is a deep dive into how to design fit for purpose security features into your product and ensure you’re compliant with relevant standards.

We’ll start with an introduction to a few key compliance standards and suggest two that you really need to pay attention to. Then we’ll walk through a tactical plan that includes details on how to design your security and compliance feature set. A template for documenting your security & compliance needs is also included.