Recently I delivered a cyber security training course to the developers in a financial services client. This group was made up of the technical champions in their organisation and our course was focused on giving them a taste of cyber security from a pentesters perspective. Essentially, a crash course in what every pentester wants developers to understand about cyber security.
I loved having this opportunity to teach developers a pentester's take on security and to learn from them. Education is always a two-way street and more harmony between pentesters and developers can only make us all more secure.
With this in mind, I wanted to share three things that I believe all developers should know about cyber security:
Law / ethics
Frameworks - MITRE & OWASP
Pentesters are your friends
Let's get into each one of these and investigate a bit more what I mean by them.
Laws and ethics
It is vital that anyone working around hacking understands the laws and ethics around it. Even if you are just dabbling in hacking because you want to become a better developer, or someone looking to get into cyber security full time, you have to at least be familiar with the legal and ethical framework.
Not knowing about a law does not mean you cannot break it. During the training mentioned above we covered some of the main laws, such as Computer Misuse Act (CMA, 1990), PECR (2003), DPA (2018) etc. However, the most interesting topic that we covered in are was around the ethics and morals. Ethical issues crop up for pentesters more often than many people realise.
As Spiderman often quotes, "with great power comes great responsibility", and as you start to learn the tools and techniques that security specialists (and criminals) use, then you start to wield an access to data that can cause a tremendous amount of harm - as well as good!
Whilst the legal side can be somewhat fuzzy and open to interpretation, which is the job of lawyers to understand, the moral and ethics involved can be even more fuzzy and harder to comprehend the balance between ethics and law. Let me give you a couple of examples questions to explore the law vs ethics.
You find your partner's email password among a dataset from a breach, and you decide to look at their emails
Is this legal? is this ethical? It's very easy to assume it's not illegal because the data is now public, however the data was stolen! Obviously doing it is unethical, you're spying on someone's private data. You're also breaking the CMA by accessing someone else's data without permission too.
Some of you might even have permission from your partner to read their email, however even with permission from them and legitimate access to their password, you are probably going to be breaking the terms of service of the email provider, almost all of them will say you can not share your login details with anyone. See how messy a simple question can get?
Frameworks
When you started to read, your family and teachers didn't get you Dostoevsky or Dante and hope that you would learn the different letters, then just get good at reading. You were (most likely) taught in a fairly well thought-out way and, not only that, a way in which many other people were taught as well.
Everyone who can read English knows that an A is an A and B is a B. With the other 24 letters agreed, we could then agree on different structures of those letters to represent objects in the real world. We agree on what a ball or a bat is because we have a framework to use to build words. Punctuation is then a second framework on how to put those agreed words together. There is a huge difference between "Fire?" and "Fire!".
Computer security is an amazing labyrinth of rabbit holes, it covers a huge breadth of things and it's ten times deeper than it is wide. Understanding how all these things fit together is achievable, the knowledge however of every facet of it is an impossible task of Sisyphus proportions. But that doesn't mean we as an industry haven't tried to make it easier to work out areas that you can learn and use as jumping points to different rabbit holes.
The best framework I can recommend is the MITRE ATT&CK framework, this lays out the Adversarial Tactics, Techniques & Common Knowledge. We covered this in our cyber security for developers course, because it helps makes sense of the attack landscape.
It's a huge framework that is split into verticals, each vertical is broken down into different techniques, each one of those is then further split. How far you go down each is up to you, but like learning to read, first understand the columns then the techniques and then you can go further.
This is an overview of the first two levels of the MITRE framework, as you can see its pretty extensive and a little overwhelming at first.
Building your knowledge takes time, patience and practice. There is no shortcut to genuine knowledge, and understanding the fundamentals of cyber security will allow you to go further in the field. You wouldn't try to build a nuclear reactor without first understanding basic physics.
To help you build your knowledge, we can turn to the OWASP Top Ten, a document that highlights the top ten security risks to web applications. It has a periodic update timeframe, starting back from 2003. Find the most recent one and start to learn what these risks mean. Almost every big vulnerability you are going to deal with will fall within one of these main risk areas.
Another framework that we cover in the course is the CWE list. This is a tree-like structure of Common Weaknesses (the E stands for Enumeration for some reason). Let's take a look at how this structure works.
XSS (aka Cross-Site Scripting) is an attack almost everyone in security and related fields knows of, and it is referenced as CWE-79. The full name of CWE-79 is pretty long, but its actually called "Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')".
But the way CWE works is a child/parent structure and CWE-79 is actually the child element of a more encompassing CWE, in this case, CWE-74 "Improper Neutralization of Special Elements in Output Used by a Downstream Component ('Injection')".
CWE-74 again is a child element of CWE-707 "Improper Neutralization".
As a tree structure it looks a little like this:
CWE-707
L CWE-74
L CWE-79
It is therefore easy to see that 'fixing' XSS can be done at multiple levels. The higher up the tree the harder it is to do, but you will prevent more issues. Do you want to tackle fixing just one issue or take out the root cause of hundreds?
We can map XSS (CWE-79) into the OWASP Top Ten as issue number three, Injection, from the 2021 list. We can also map it across to the ATT&CK framework under Initial Access, Drive-By Compromise.
I hope you take a look at all three of these frameworks. While there are several others, I find these three are the easiest way to get your hands dirty with the organised complexity of cyber security.
Pentesters are your friends
No really, we are!
It is easy to think that pentesters just come in and pull everything you made apart. I know it can feel like that, but really we are all on the same side.
If your code goes into production with flaws and those flaws are then exploited by a criminal gang, it's your job on the line. Maybe not just yours but it could affect the entire company and everyone's jobs could be at jeopardy, as well as client data. Maybe even the personal and financial data of your colleagues. Depending on how big your company is, and what it does, this could have a real world impact on the lives and wellbeing of many people. Not to be a scaremonger here, I am just telling the truth.
Of course, you work within a system. This will impact the extent to which you are working as part of a positive security culture. If you're working in an organisation that prioritises security and encourages a just culture around incidents, your job will be a lot easier. Bit if you're not, you can still prioritise security by taking some initiative.
Security is often left to the last minute in a project: "why bother testing something that isn't finished" right? That would be like saying let's build a car, then crash it to test that the seatbelts we made and then having to redesign the whole car frame because the seat belts were not properly embedded. You are better off testing the seatbelt on its own before it's even near a car, so you can work out all of the major issues before you see how it performs in a real crash much much later on. That way if there is a major redesign needed, it happens sooner and cheaper too.
The one adage I think sums up the software development cycle and security testing is "fail faster". The sooner you find a security issue, the easier and cheaper it is to fix. The ultimate goal - and the goal of our training course - is to help developers understand security implications of the code you are writing. What is often called 'pushing left' e.g pushing security to the left of the development timeline.
If you understand the security vulnerabilities that come from input fields, and you can make better decisions on how to code those input fields, that removes whole swathes of vulnerabilities. Security testing doesn't come along later telling you what's wrong and you won't have to re-write anything. This means less time for everyone, and less time means less money is spent overall. Another added benefit is that you get more time to work on other projects because you are not going back to fix older problems. So whilst it may seem an impossible effort right now, the long term benefits are magnified.
Next time you get a security report from a pentester asking you to fix this or that, don't think of them as the enemy. Take it as a way to learn about that vulnerability and learn how next time you can prevent it by coding in a different manner. We pentesters love educating people that want to learn and we respect those who build the technology that we have fun trying to break. We are not monsters, we are here to help you!
If you'd like to know more about the cyber security training that we deliver to developers, please get in touch.
And, don't forget to subscribe to our mailing list to stay up to date with all of the happenings at Cygenta HQ.