How do you go about ensuring the safety of the systems that your engineers develop? You can hire security experts (at great expense), who will review all code for security flaws. You can, and should, have a strict peer review process in place through your Secure Development Lifecycle (SDLC). You can also have regular application assessment/penetration tests done by internal or external security teams.
But all of those options are expensive and not really unlike having a round of antibiotics during your annual health-checkup. It’s expensive, has questionable efficacy, and will at best maintain the status-quo. Most likely it will also lose any efficiency over time.
So how do you go about actually ensuring that the code your developers eventually ship to production is secure? How do you make sure your development processes actually result in systems that are not adding risk to your organization?
First, we have to reason about learning. As we’ve already discussed in-depth in this blog, you have to learn by doing and see how insecurity looks in practice for you to spot it and thus avoid it from occurring.
For this discussion, let’s not think so much about the process of writing code in a secure way. People make mistakes, that is simply part of being human. But you have to trust that your SDLC processes are adapt enough at catching insecure code when it goes through peer review processes. That means we shift our focus from wanting people to not make individual mistakes to recognizing that they are your company’s immune system that keeps the bad things at bay. You empower them rather than look at them as a risk.
Your developers are your organization’s T-Cells in your immune system. T-Cells remember what sort of pathogens it has discovered and successfully eradicated in the past. These pathogens are security flaws in your system or coding mistakes that were a risk to the host organism. And the T-Cells are responsible for finding these flaws and destroying them.
But take note of the fact that in order to have a memory of pathogens you have to have encountered it before. That means you have to have had exposure to them, sometimes multiple times. That’s not ideal when it’s a pathogen that has a legitimate chance of crippling, or killing you. That’s why we vaccinate people, through the introduction of pathogens that resemble the type of risk we want to defend against. In these cases, they are harmless versions. But it allows the immune system to learn to detect similar pathogens and remove them before they do any harm.
Come flu season, we vaccinate people with a whole host of different strains of the flu virus to train the immune system on a wide range of variations. One example is not enough. This goes for security too. Learning is usually done by trial and error. Vaccinations are a go-to therapy, because it makes the body go through a lot of trials in a short time, without the risk of error. Developers need the same when it comes to security flaws. Teaching your body how to deal with the flu once you’re already infected is really not pleasant.
You’d be foolish to rely on a single person to prevent any and all security issues. The protection that you get from that is extremely dependent on the skillset and experience that they have. And it’s frankly unrealistic to expect a single person to have not only experienced, but also retained the learning from those experiences. This is no different from how the immune system has different types of T-Cells for different purposes. By approaching the issue from the perspective of every single developer being a part of the team that ensures security, you empower them to actually take responsibility, and do it well. And in the process, you create herd immunity.
But as you know, when you get vaccinations, you have to have multiple shots over time. Because not only do you need to teach the immune system in a way that will not overpower it and risk the chance of weakening it. Therefore, you have to repeat exposure over time. Both with different slight variants on the actual pathogen, but also for the purposes of increasing retention.
This is stressed by the German psychologist Hermann Ebbinghaus, who was a pioneer in the field of memory, and learning. Learning has to occur over time, with multiple learning sessions. Otherwise, you run into the forgetting curve, where you will gradually lose the memory of it. So how could one ever expect a single day of slides about security, to actually result in learning outcomes?
To summarize, nature is a beautiful thing that provides beautiful solutions to problems. As such, in order to ensure that your secure development lifecycle process (immune system) is effective, you have to:
- Recognize it’s a team effort. Everybody plays a role and works together towards the same goal: Defense against pathogens
- You have to expose them, in a controlled setting, to nasty things. Otherwise, they will not be able to respond to them when they encounter them.
- Repeat that exposure with variance in the presentation. Memory fades and context matters.
These 3 key realizations are critical to not only checking the check-box of SDLC, but actually make a real-world impact on the development process.