Architecture

As security professionals working with software components it is not always easy to prioritise what security raising actions should be prioritised. According to most security standards (such as ISO27000) require a risk based security approach. Regardless if we are building our own applications, or we are installing third party software in our network we need to understand what threats there are to our environment. After understanding what threats there are, we prioritise them and thereby also prioritise what actions we should take to minimise the risk. Many organisations use threat modelling to understand what threats they have in their environment. However, I have lately come to understand that the definition of threat modelling varies widely between organisations. There are two main variants: ...

When people are talking about cybersecurity they are often talking about IT-security, but there are also OT-security. But what are the difference? Most people in tech know what IT is, the tech that handles information. The focus is on handling data, collecting, modifying or providing it. OT (Operational Technology) on the other hand is focused on the tech that impacts the real world. An example could be a control-system that manages the indoor climate in an office. An easy example are the smart homes, where IoT devices control the the house. ...

As in all fields there are lots of decisions that has to be taken in Cyber Security. But how can we maximise our chances to take the correct decisions? This question has many answers, but from my experience many of them boil down to information. To make the correct decision one needs to make an informed decision. But what information is it that is needed, and how can we gather it efficiently? This depends on the decision to be taken, but let’s try to boil it down to some general guidelines that can be applied to all decisions. The first step is to split the information into two categories, internal and external. The external information is what usually comes from Cyber Threat Intelligence. This can answer questions that are generalized outside the own organisation, such as “What attack vectors are most commonly used to by attackers to gain a foothold in organisations?” How to find the answers of these questions is an area of it’s own, so I’m not going to dig deep into it, instead we leave the answers to this kind of questions to external reports published by researchers focusing in the area. A common example of this is OWASP top 10 that shows the most common attacks used to attack web applications. There is however a secondary kind of external information needed to make good decisions in, and that is in regards to the legal or regulatory requirements. These impact all areas of the business, including cyber security. ...

When working with cybersecurity in any development organization it is inevitable that management asks the difficult question. The question that puts us in a very difficult position of grasping the current status of the organizations security efforts. The question I am talking about is as follows, or a version of: How far have we come in our work with cybersecurity? It is an understandable question. We need to see that the time and money put into security are adding value to the business. However assessing the progress in a comparable way is not always easy. As luck would have it there are standards for measuring the maturity level of cybersecurity. One of these models are OWASP Software Assurance Maturity Model, SAMM for short. As it is provided by OWASP it is an open source model that can be used by anyone free of charge, and the results are comparable both over time and between organizations. There are other models that do similar things, but due to the open nature of SAMM it’s a good starting point for any organization getting started. ...

Far to often organisations do all their security work on the few systems that are exposed to the internet. This might be acceptable when you begin the structured and ongoing work with security, but you should try to move on to defence in depth as soon as possible. Defence in depth is where you do not leave security to one layer of an application (or solution), but instead validate the security every step of the way. A common example for this is that even if you have a network firewall you do not disable the firewall in the operating system. This can be transferred to software development as well. In a more complex system each component should get the same security controls. It should not only be the frontend API that validates the input, instead each component should validate the data as untrusted when it receives it from another component. By doing so the resilience of the solution as a whole is greatly improved, where a single issue have limited impact, and might not even be exploitable. ...