Security is important and yet product people (managers, designers) see it solely as an engineering problem whereas engineers striving for an MVP often put security features on a shelf labelled “Nice to Have”. The shelf is hardly ever looked at and grows dustier and dustier over months and years. This makes security undoable, deprioritized and kind of forgotten until a serious breach happens.
Difficult and scary
Another challenge in the way we think about security is that it’s difficult to write secure code. I empathise with engineers who have simply given up on security, willingly or unconsciously. If you hear repeatedly that something is difficult, you won’t be excited when you get a vulnerability to fix, right?
When I joined a security team in 2021, I had nearly a decade of software engineering under my belt. Staying in the same organisation allowed me to watch it from different perspectives - via engineering and security lens. I understood quickly that one of the problems with security is… security itself.
Security is complex
Think about what secure software means to you. How do you know that your application is secure? Now ask two of your colleagues. I can bet that you will hear different answers. Security is complex. I like to think about it as an ocean of topics:
- Application security, infrastructure security, IT security, Cloud Security, Risk management, Vulnerability management, Vulnerabilities, Broken Access Control, Misconfiguration, Outdated Components, Server-Side Request Forgery, SQLInjections, XSS, DDOS etc.
And you’re just a developer in a tiny boat. The waves move your boat further away from a beach and you feel overwhelmed.
During my transition from development to security, I took classes on cybersecurity and read some books. One piece of theory stopped me. And ever since I want everyone to learn it.
Put the ocean into buckets
Think about the ocean again. There are thousands of threats and attack vectors. Listing all of them is impossible and will make you dizzy. BUT all of the threats can be assigned to one of the three categories.
Yes, you read right. One, two, three categories.
It means that we can put the whole ocean into three buckets. These buckets are Confidentiality, Integrity and Availability, known as the CIA triad.
What is the CIA triad?
Let's go through these three categories and see what they mean.
Confidentiality - we want secrets to be secret. We don't want anyone to know credentials, we don’t want anyone to have access to something they should not have access to.
Integrity - we get what we expect. We don’t want just any person to edit, delete our resources.
Availability - we can always access the information.
Why is the CIA triad so cool?
The knowledge of the CIA triad allows us to reverse the way we approach security! Instead of
There are so many vulnerabilities, how can I possibly know if this code is safe?
You can ask the CIA question:
How can the CIA of this project be broken?
The beauty of it is that it will work for any project you will ever work on. No matter the technology, language, frontend, back-end, mobile, devops. No matter if you’re a junior, senior, staff, director, designer or product manager, you can always ask the CIA question.
Is one question enough?
Depending on what you’re building, the CIA question will become questions. Here I share examples that should give you an idea.
- How can confidentiality be broken?
- Who can see this resource?
- How do we store credentials?
- Do we put sensitive data into logs?
- How can integrity be broken?
- Who can create, update, remove a resource?
- Do we have a way to see a potentially malicious actor who deletes all resources at once?
- What if someone sends malicious data via form to perform an SQL injection?
- How can availability be broken?
- Is this endpoint rate-limited?
- What happens when an external product we rely on is unavailable?
- How is a database migration performed? IS there a need for a maintenance window?
- Is a person on support and on-call informed about this ?
Don’t do it alone
The fun part of using the CIA triad to improve the security of your product is that you can brainstorm it with your teammates. I’d suggest you meet for 30 minutes to an hour, and try to find as many problems with solution design as you can. You can repeat the process if you need. It’s helpful to have different perspectives in the room. Maybe your security team can help you too.