Solid security knowledge among developers is scarce these days, simply because it is not as spectacular and sexy as a new framework or a cool new tech. Nevertheless, it is real and will not go away anytime soon. Your best bet is to start learning about it right now. It will make you more valuable to your team and your organization. Do not think of this as a massive upfront investment; it is not. Once you get the basics right, you can evolve from there and enjoy the benefits. This post will help you get started by introducing you to a simple formula I came up with over the years.
Unsure if it is worth your time? - Check out my first post for a hint.
The formula
Over the years, you most probably have seen several vulnerabilities. They come in various shapes and forms. Chances are, you have forgotten about some of them already. It is hard to remember all of them and knowing each by heart is not the optimal way to build up security knowledge. I believe there are two key elements to success here. This is where my formula comes in: it will help you get started and make sure you stay on track. Without further due, here it is:
Knowledge × Mindset = Smart tradeoffs
There are a couple of things here we need to address. Firstly, I claim that security is all about smart-tradeoffs. More on this later. And secondly, that all you need for this is the right combination of mindset and knowledge. Think about it for a second. These are precisely the elements your attacker possesses. The best defense is a good offense, right?
Multiplication is essential: optimal progress is achieved by developing these two areas in parallel. It is also trivial that neither component can be zero, as that would yield zero as the product.
First, I will discuss knowledge, which, in my opinion, is more readily available. This is probably the area you are more familiar with.
Knowledge
Security building blocks are like tools in this carpentry workshop. Every single piece of hardware in this picture has a dedicated purpose. A skilled carpenter can create beautiful furniture from pieces of wood utilizing his considerable toolset. No tool is misused in the process, for the craftsman knows his trade. As a software engineer, you must also learn to use security building blocks. The software industry is full of misuse. Here are some examples: using JWT for a full-featured session management, claiming HTTPS will protect data-at-rest, encrypting passwords, referring to OAuth as an authentication protocol, etc. This list is by no means complete. Misuse, on some level, is fostered by creativity and the lack of knowledge.
Do not expect to know every tool when you start out. It takes time and effort to master a trade. It is an investment on your part, for which the gains will be realized almost immediately, ultimately leading to smarter tradeoffs.
Next steps
Interested in improving your security knowledge? Invest a few hours of your time, and get a head start. Here is what to do.
- Read the Builder/Developer cheat sheets at OWASP
- Browse the rest of this blog. It is, after all, dedicated to the cause.
Mindset
Improving your mindset comes down to thinking a bit differently; out of the box, if you prefer. Start by asking different questions about the component/feature you are building. Some ideas:
- How could I get around this check?
- What happens in an unexpected edge case?
- How would I abuse this?
- Can I force it to do something it was never designed to do?
Read this article about how attackers think. It will redefine your definition of value.
Ideally, the attacker's mindset is matched with that of the defender's. Unfortunately, this is not always the case. The problem is best illustrated by a well-known concept in the field of security: built-in versus bolted-on. It states that it is easier and more efficient to design and implement securely up front, rather than trying to bolt it on later. There are examples of this all around us. A great one is the email ecosystem. It was designed, like everything back in that day, without security in mind. A few decades and a bunch of acronyms (SPF, DKIM, DMARC) later we are still struggling. Bolted on, failed.
On the other hand, take a look at HTTP/2. It builds security right in.
- It addresses the compression issues with HTTP/1.1 and TLS
- It is strict about TLS settings
- It opts for TLS by default and treats plaintext as a special case
- As of this writing, no browsers support HTTP/2 over plaintext connections
Think of built-in security as clean code. If it is done from the start, it pays off nicely on the long run. However, introducing clean code to a spaghetti legacy codebase is quite a challenge, just like bolting on security to something later on.
Next steps
Improving your mindset is crucial. The best way to get started is by checking out a concept called threat modeling.
- Read about Microsoft's threat model tool called Elevation of Privilege
- Take a look at OWASP's Cornucopia
Smart tradeoffs
The idea behind a smart tradeoff comes down to the question of how much security is enough? The answer is: just enough to lower the risk to an acceptable level for stakeholders. Too abstract? - Read on.
Reducing risk is achieved by a practice called risk management. In summary, it identifies assets, threats, vulnerabilities and the risk associated with a successful exploit. To lessen this risk, one must employ countermeasures. However, mitigations are rarely free; they have a cost associated with them. Ideally, the cost of mitigation does not exceed the cost of potential loss in case of a breach.
The key to a smart tradeoff is stakeholder understanding. Accepting risk without fully comprehending it, is like gambling without knowing the game. Your job is to make sure this does not happen.
Let me give you a specific example of a good tradeoff.
I was tasked with upgrading our TLS settings. After some reading, I put together a very strict config that achieved an A+ on SSL Labs and was compatible with all of our clients, at least on paper. After installing the settings, the service was unreachable for a few users. It was rolled back instantly. Keeping compatibility meant reducing security. This was clearly a business decision. After understanding the risks, they decided to go with compatibility. Finally, I came up with a hardened, more secure than the original, yet still compatible configuration. A smart tradeoff, in my opinion.
Conclusion
It is time to learn about security. You do not need to become an expert, but you do need to be able to help the business make smart tradeoffs. This requires knowledge and a security mindset. Both of which can be bootstrapped by the resources I outlined above.
Improving is a process. Mastering the formula will take time. Reinforce the basics and build on that. Before you know it, you will be making your software more secure.
What smart-tradeoffs have YOU made lately? Share it in the comments.