Architecture on Edbro.net - A Cybersecurity Blog

Threat Modelling and Threat Actors

Sun, 02 Jul 2023 07:35:48 +0200

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:

The Pentest definition: According to the Penetration Testing Execution Standard (PTES) the goal of a threat modelling exercise is to understand what potential targets an attacker has on the network, and how an attacker might reach them. The process is a part of the testing phase to prioritise test cases and help assess the severity of findings.
The Appsec definition: Open Worldwide Application Security Project (OWASP) on the other hand focuses on finding security hotspots as early on in the development phase as possible, preferably as early as the design phase. There are multiple structured ways of getting there, one of the most common is STRIDE.

Both of these have their value. The main point is to ensure that everyone is aware of what version of threat modelling that is discussed or performed. Regardless of model, it is helpful to not only think about the potential threats, but also what threat actors are relevant.

When I have read about identifying threat actors previously, I’ve dismissed it as overcomplicating. That might be true if you are looking at the differences between ransomware gangs, but just grouping the threat actors into categories. For example, noting that we trust our users in the air-gapped system to not be malicious and instead focussing on not getting malware installed through third parties as a way of performing industrial espionage. This is a quite extreme example, but it shows a valid point. By noting industrial espionage as a threat actor we need to discuss the security in another way than if we are looking at disgruntled employees.

By being aware of the threat actors against our organisation or application we can focus on the correct threats in the threat modelling sessions. This will certainly improve the accuracy of the identified threats, and the risk towards them. Furthermore, this will allow us to focus our efforts on the most important actions to improve the security posture.

In summary, as a part of our security practices we should identify both threat actors and potential threats. This is just as valid if it is software developed inhouse or if it is third party software.

IT vs OT Security

Sat, 26 Feb 2022 00:00:00 +0000

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.

But what are the differences when it comes to how to secure OT? The main thing is to be aware of the system that shall be secured. Just as with IT security it is important to classify the system, but not only classifying the information. Instead the classification should include the risk and the impacts of an attack, both for the information and the operations in the real world. An electronic locking system could both be attacked to gain information (whom is entering and exiting), locking people in or out (disturbing the business), or unlocking (enabling unauthorized access).

Due to the added impacts of an attack OT has, there is an extra focus on safety. When downtime can result in the loss of human life, everything gets a deeper meaning. This also shows in the patch cycles. Where a slow IT system can be patched once a quarter or year, OT can be patched every ten years. When any downtime results in the industry needing to be stopped, or have disastrous consequences, the stability is rated much higher than updates. Instead of patching a vulnerability it is easier to just add some kind of protection minimizing its exposure.

In the end the difference between IT and OT security are not so different. Even though the tech often is different, and the impact if an error occur is more severe, the basic principles of IT security is still applicable. It is still important to validate everything (input, users, authorization etc.), ensuring access control and so on. This is especially true in the development process of OT, since the update schedule is so much longer, meaning that we can draw further lessons from old, slow development cycles. Looking forward OT is standing in front of the challenge of allowing updates without risking devastating errors.

Decision-Making in Security

Sat, 19 Feb 2022 00:00:00 +0000

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.

Based on the external intelligence it is time to look inwards. What intelligence can we find internally, and how do we use it. Here we once more need to figure out what the end goal is. After that we need to ask the correct questions. The answers to the questions are often distributed among products or departments, and therefore there can be lots of data collected. However data is not everything, you need to interpret the data to gain insights that are applicable to the task at hand.

Let’s look at an example, were in our system is there a need for further investments to increase our overall security posture. We begin by looking externally at what are the most common attack vector for malicious actors and after some research we find that outdated software with known vulnerabilities is the biggest risk. Based on this we need to ask internal questions. The first question to ask is do we know what known vulnerabilities exists in our environment. Therefore we go to all system owners to verify that they scan their systems with the vulnerability scanner. If not this is a good place to start. If not, we move forward and look at the findings for each system. Depending on our focus we can ask different questions:

Which systems has the most risks?
Which systems has the most critical risks?
Which systems have a negative trend, gaining more vulnerabilities over time?

Based on the question we wish to focus on we can make a decision on where to invest.

One note however, whatever we chose we have to remember that the reason for measuring is making good decisions to improve security. We need to ensure that everyone has what they need to reach the goals, not to blame the ones that do not reach them. This is true for everyone, not only in security, but for measuring everything. And in this context the end goal is to make good decisions.

Measuring Security, OWASP SAMM

Sun, 26 Sep 2021 00:00:00 +0000

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.

The SAMM model measures 15 security practices in five business areas. Each practice contains two streams, represented by a set of activities and resulting in a maturity level on a scale from 1 - 3. In addition to helping the organization find lowpoints in their work with cybersecurity the activities can give a hint of good next steps. Even though the policy in it self does not specify a way to summarize the scores for each activity, it is possible to summarize the scores into a practice or business area to get a better overview. I’ve seen other models using radar charts to display the results, and I think it would be applicable here as well. An example would be to summarize the actions for each practice and then put all 15 practices into the diagram. But which are the practices. In the table below the business areas are the headers, and then the practices are listed below.

Governance	Design	Implementation	Verification	Operations
Strategy & Metrics	Threat Assessment	Secure Build	Architecture Assessment	Incident Management
Policy & Compliance	Security Requirements	Secure Deployment	Requirements-driven Testing	Environment Management
Education & Guidance	Security Architecture	Defect Management	Security Testing	Operational Management

To gain enough insight to perform an assessment in accordance to SAMM i recommend reading their website, but to gain some insight into how it is intended to work lets dive all the way down to the questions asked to perform the assessment. Let’s look at Security Architecture in the business area Design. It contains two different streams that are measured, Architecture Design and Technology Management.

For Security Architecture the first maturity level is about “Insert[ing] consideration of proactive security guidance into the software design process.” In Architecture Design this would mean that the teams are trained in basic security principles and how to use them during the design process. To help with assessing if this is achieved SAMM supplies a question, answer alternatives, and quality criteria. This is also true for every other maturity level, stream, and principle. The question in this example is “Do teams use security principles during design?” To answer this there are four alternatives:

No
Yes, for some applications
Yes, for at least half of the applications
Yes, for most or all of the applications

The quality criteria used to help with answering the question in a correct way are:

You have an agreed upon checklist of security principles

You store your checklist in an accessible location

Relevant stakeholders understand security principles

Overall this model can help an organization measure their maturity in security. For me it is great that it is so detailed and help the organization down to the level of what questions to ask to asses the quality of their implementation. Therefore it can be of great help regardless if the organization is in the beginning of their security journey, or if they have grown more mature.

A Look at Defence In Depth

Sat, 31 Oct 2020 00:00:00 +0100

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.

Example application and its vulnerabilities.

Let us look at a simple system to exemplify potential vulnerabilities. This system is simplified and super minimalistic, but still shows several ways to attack components on the internal network. The application is a web shop exposed to the internet through a firewall. The web shop fetches prices and products from a database. To manage the prices and products employees uses another administrative interface. The administrative interface connects to the same database to update the web shop. In this example, only the web shop is accessible from the internet, and the employee workstation is the only component with unrestricted access to the internet.

Let’s take a look at a couple of ways this architecture potentially could be exploited and how defence in depth could reduce the impact of these vulnerabilities.

Infecting the Workstation

The most obvious way into the network is to infect the employee workstation. This can for example be done by using trojans through emails or public exploits in the operating system. Regardless of how the initial attack is performed, the goal is the same, hijacking the employee workstation to get access to the internal network. To mitigate this it is important to include the workstations in the security policy of the organisation. For example the software on the workstation needs to be up to date with the latest security patches.

In addition to patches, using a good antivirus software will keep a lookout for malicious code on the computer, helping users to distinguish trojans from legitimate files and programs. As an added bonus, the antivirus will log incidents, ensuring that the organisation is aware of failed attacks, and can investigate suspicious activities.

These technical solutions might however not be enough. To circumvent patched software and antivirus the most dedicated attackers might hack the employee instead of the workstation. This can be done in multiple ways. Some examples include social engineering and bribery. Whatever the way the best way to protect the organisation against these attacks is through security awareness training. By getting the employees to be on the lookout for and report suspicious activities most of these attacks will fail.

Through the Web shop

Organisations are now getting quite good at securing their web applications against attacks that affect their corporate networks. However, there are a couple ways a vulnerable webserver can be abused to gain a foothold and enter the network. In my experience the two most common are components with known vulnerabilities, or administrative interfaces exposed to the internet. Note that these administrative interfaces might be anything from a WordPress admin interface to a SSH server. Neither of which is weak if configured correctly, but far to often they have accounts that can be bruteforced, allowing an attacker to try different credentials until they successfully sign in. The goal of this is to gain access to the solution and then get further access into the corporate network.

Another possibility is to circumvent the webserver and just attack the network directly. This can for example be done by using a SQL-injection or server-side request forgery. An SQL-injection would allow the attacker to execute database commands in the database through the web application, attacking it directly. A server-side request forgery is a vulnerability that abuses a server to make requests against other applications. This means that the attacker can attack any system that the server can connect to, including on the internal network.

Vulnerabilities in the Administrative Interface

There are multiple vulnerabilities that can occur in web applications that could be exploited from the internet, even though the application is not accessible. These vulnerabilities uses a legitimate user of the internal application to perform the attack. Attacks that can be exploited could be clickjacking or cross-site request forgery. Both of which rely on a legitimate authenticated user of the vulnerable system visiting a malicious webpage on the internet. While the user thinks they are visiting this webpage on the internet, the attacker is using their browser to send requests to the internal systems, signed in as the victim. The result of this attack can range from the attacker being able to perform actions as the victim, to them being able to exploit other vulnerabilities with an even greater impact.

There are ways to protect against these attacks, but since they exists it is important to not forget these internal systems in regards to security. They should not be allowed to ignore the security recommendations just because they are not exposed to the internet.

Conclusion

There are multiple ways for an attacker to gain access into the internal network of an organisation without them being accessible from nor have access to the internet. Therefore it is important to include all systems in the security work. No systems should be excused because they are not exposed to the internet, you never know how an attacker can gain access to them.

When looking at a more complex system than this, other and more complex attacks emerges, but the conclusion is the same. Do your due diligence for the security of the solution, not only focusing on the exposed parts, but also on the components behind it.

Handling Penetration Test Findings can be more than Vulnerabilities

Sat, 19 Sep 2020 00:00:00 +0100

In my years of working as an application security (appsec) penetration tester I’ve come to the conclusion that there are so much more value to be added than pure technical vulnerabilities. To deliver the most value you have to be willing and able to walk the extra mile. Before getting into what can be done to increase the value, let’s dig into the two most common types of vulnerabilities.

Technical Vulnerabilities

The technical vulnerabilities are the most common vulnerabilities we see. This is where the application is abused to do something it shouldn’t, for example by injecting code or abusing weak cryptography. Even though the vulnerability is technical, it is important for the reporter to describe how it will impact the business. Otherwise the receiving organisation might not have enough of an understanding to prioritise the issues, and handle them accordingly. Even though a code injection can be used to pivot to other machines, the main impact for the business can often be linked to the confidentiality, integrity and availability of the application. As a tester it can be hard to accept, but a dom based XSS might be an accepted risk if the only impact is defacing the sight by pasting code into the searchbox.

Logical Vulnerabilities

Logical vulnerabilities are closer connected to the business risks. Instead of abusing the technical capacities of the application, the attacker here abuses the logic of the application. The most common example would be to order -1 books from a webshop. Will that remove cost from the total? Since these logical vulnerabilities are coupled to the business logic, it is often easier to explain them to the business and therefore get them fixed.

There are exceptions however. I would like to split the Logical vulnerabilities into to categories:

Abusing unintended behaviour
Abusing intended behaviour
Risks introduced by behaviour

The previously described example for webshops is an example of an unintended behaviour. Abusing intended behaviours however is harder to pinpoint, and even harder to explain to the business. This is when a feature is used as intended, but has an unintended consequence. This would for example include a forgot password function sending the password to the users email. The feature works as intended, but it’s still a security problem, or even multiple problems.

Sending the password to the email is a low risk vulnerability, since email is an unsafe way to send information [1]
The application sending the password to the user means that the password is stored either in clear text, or with reversible cryptography. This increases the risk that if the application gets hacked the passwords will be leaked, and due to password reuse this might mean that users are affected on other sites as well.

The third category, risks introduced by behaviours are even more tricky. It could be functionality that is added, but introduces the risk. This can be the possibility to send a download link via text to a validated phonenumber. Spamming one self might not be a huge risk, but if each text message costs 1 cent for the sending company sending enough texts will have a financial impact. I would also argue that privacy of the user falls into this category, since it might impact the public relations of the company as well as adding value to the customers.

the Extra Mile

So with this knowledge, how can we as tester go the extra step to increase the value for our customers? I would argue that in addition to the usual findings that clearly can be exploited, it is our duty to inform the customers about their more subtle risks. By understanding their business as well as their application it is possible to find and report risks introduced by their behaviours. We should think outside the CIA (Confidentiality, Integrity, Availability) triad and think of other risks. With our expertise we have a good possibility to think about privacy and other business impact. It requires a bit more work, but in my experience it is often worth it. The testers experience with security, privacy, and thinking outside the box will often lead to some findings that give aha moments to the client, even if they are not traditional security risks.

References

https://en.wikipedia.org/wiki/Email#Privacy_concerns

Humane Technology, or Ethics in Software Design

Wed, 02 Sep 2020 00:00:00 +0100

We live in a world where technology compete for our attention, especially on our smartphones. Apps do everything they can to get us to open the app, and not leave it. At least that’s how I feel, with endless newsfeeds, notifications and autoplay, it’s so easy to just open the phone and get stuck. The feeling is not new, but the thing that pinned it down for me was the book Zucked by Roger McNamee [1]. It highlighted the reason for the feelings, both why companies do it and what they do. By using data companies have on their users they maximise their consumption. This can be in the form of video content on a streaming platform or browsing the newsfeed on social media.

I would argue that there are two kinds of platforms, the ones where you pay with money, and the one you pay with data. When paying with data, the user is often the product. The way companies sell that product and make money is advertisement. By knowing their users, companies are able to tailor the most appropriate ads for that user. The more ads the user sees, the more revenue for the company earn. Therefore it is in the companies best interest to keep the user engaged and coming back. For social media, it’s profitable to be addictive. The more users stay on the platform, and the more they interact with it, the more the platforms know about the user and therefore can show more and better ads.

As an answer to this exploitation of users and their data a movement have risen. Humane technology aims for ethical technology. By focusing on adding value to the user, without exploiting the nor their data, it is the polar opposite of where many of the major platforms are heading. The Center for Humane Technology is a great source of both inspiration and knowledge when it comes to these areas. They even propose the following principles[2]:

Obsess over Values; Today there is an obsession with clicks, likes, and other instant reaction metrics. This promotes clickbait to maximise the metrics. Instead we should use metrics of actual value (fun, creativity, well-being), what did the user get out of this? It is harder to measure, but ensures greater value for all parties.
Strengthen Existing Brilliance; Technology is moving very fast, and enters more and more spaces. But not all things needs a technical adaptation or solution. Some things cannot be replaced with technology. For example, If you feel lonely a weekend evening after being home alone, the solution might be to invite some friends over for dinner and discussion. Tech could help you set it up, prepare the meal etc. but when you are seated at the table, it’s you and your friends that bring each other joy.
Make the Invisible Visceral; To ensure that we consider every ethical and safety aspect of our product it can be a good idea to how we frame our user personas in the design. By considering a random old lady to be a relative of yours, perhaps your grandmother, you might be more cautious about how the product might affect her.
Enable Wise Choices; By changing the way we frame the information we help the readers to make a choice. All information will have a bias for one interpretation. A common example is the cows are deadlier than sharks statistic, that is biased towards the dangers of cows due to the large difference in shark to cow population. This does however not mean that cows are more dangerous than sharks.
Nurture Mindfulness; To ensure the well-being of the user it is important to allow for a balanced experience. By nurturing the users mindfulness their awareness increases. When there is not a new notification prompting them to engage whenever there is a dull moment it promotes actively searching out whatever the user needs, and sometimes that is just a calm moment to relax.
Bind Growth with Responsibility; The only goal should not be in the number of users, platforms and other technology should take their responsibilities to grow ethically. How can we grow without compromising our values? You should not be willing to grow at any cost, but rather find a balance where your ethics are sound, and your users happy.

These steps are a great way to start working towards a humane technology, but as with the prisoners dilemma [3] it is still easy for others to not play nice, and exploit the user to gain more influence. I hope that we continue to move in a direction where the users gain enough insight to reward nice and ethical behaviour (humane technology) over exploiting users.

a Journey from Technical Debts to Risks

Thu, 20 Aug 2020 00:00:00 +0100

Technical debt has become a common term when discussing the quality and maintainability of code. There are a lot of definitions of the debt, but they all have some things in common, that debt are the things in the solution that should be fixed but haven’t been fixed yet. This could include everything from lack of documentation or test coverage to code complexity. The debt might not have been there from the beginning, but rather been introduce while the solution grows. Another common denominator is that the debt will increase the cost of continued development within the solution. This can be seen in several different ways, for example adding a feature to a complex codebase would require more time than adding the same feature to the simple.

So why does not everyone just keep the technical debt low? There are a couple of different reasons, firstly it is a bit more expensive to add a feature neatly (reducing technical debt) than to just add it quick and dirty. This could be a part of a deliberate choice to introduce debt, either due to time constraints or due to the necessity to ship what you got and deal with the consequences. The second way technical debt can be introduced without knowing about it in the first place. The reason for this might be due to lack of research and knowledge, or only seeing the impact of decisions in hindsight.

No matter which of these types, or combinations of types, of debt can be found in a software the main point is that they add to the time it takes to develop in the codebase. It also increases the risk of introducing bugs, due to complexity, lack of automatic test cases, or any of several other reasons. The price of the debt is paid each time a change is made, and if no changes are made there are no payments.

Up until this point the information presented is mostly based on Martin Fowlers blog posts [1, 2], but I think these definitions misses one important part of technical debt, the dependencies. Joab Jackson argues that any dependency, such as libraries or frameworks, adds to the technical debt. By adding a dependency, the codebase often increases much more than needed. In doing so the amount of fluff that you need to understand to work in the codebase increases as well, increasing the time it takes and the risk of bugs being introduced. [3] However I would argue that even if there is debt introduced by third party dependencies, it can easily be worth it to use the dependency. The increase in development time and expertise needed when using dependencies save huge amounts of times in relation to the increased time it takes to maintain. One would have to weigh the technical debt from the dependency, and the debt from implementing the code inhouse to know which is the correct way forward.

However, I would argue that there is another technical debt introduced, the debt of keeping the dependencies up to date. The cost of this maintenance is required throughout the whole lifecycle of the solution, to ensure that no bugs are inherited. In a worst-case scenario these bugs could be security bugs with impact on the solution.

The recurring theme when it comes to security and technical debt is that they are not directly linked. From my experience I conclude that there is not any direct security related technical debt. Instead the technical debt could have one of many impacts. For example, it increases the risk of bugs being introduced. These bugs can be functional or non-functional, usability, or security bugs. Technical debt is a general concept in software development, that can be used to communicate the state of the solution. The impacts of the technical debt are what’s explained to the leadership, such as time spent and bugs introduced. The source of the debt on the other hand could be a lack of documentation or complex code, which is what the developers have to live with.

To work with technical debt in a structured, and well documented way one could frame the debt as business risks. For example, the technical debt in the codebase introduce risks such as:

Lack of automated testcases increase the risk of introducing bugs
Code complexity may increase cost of introducing a new feature
Onboarding team members consumes more time than expected due to lack of documentation
Etc

By handling the debt as business risks, it shows how the technical debt can impact the business, and help prioritising it in relation to other risks. In doing so, technical debt and code neatness can be clearly defined together with environmental, juridical and other risks.

My conclusion is that we should be careful when splitting out different problems, calling them different things and handling them in unique ways. A bug is a bug, it might have functional or security impact, but it’s still a bug. They should be prioritised based on their impact, and not be separated out. Risks should be handled in the same way, according to a general process where they can be prioritised and acted upon, regardless of if it has security, cost or other impact.