When discussing penetration testing, it’s helpful to break down the ways a test can be executed into distinct approaches. This is just one of many ways to clarify expectations and align the scope of a test with the goals of both the tester and the client. In this post, I’ll focus on three key areas, each of which requires a different set of skills and expertise:

1. Compliance testing involves executing a predetermined list of test cases to ensure the system adheres to specific standards or regulatory requirements. This type of testing benefits from familiarity with the relevant compliance frameworks and the ability to systematically assess against defined criteria.
2. Configuration weaknesses and known vulnerabilities focuses on identifying and exploiting known vulnerabilities and misconfigurations within the system’s components, leveraging established methods to evaluate the system’s current posture. Expertise in vulnerability databases, common misconfigurations, and practical exploitation techniques is critical here.
3. In vulnerability research the goal is to discover zero-day vulnerabilities—previously unknown flaws within the system—through deeper analysis. This requires advanced skills in reverse engineering, protocol analysis, and often a creative mindset to uncover new attack vectors.

Each of these approaches offers valuable insights, but understanding their differences is essential for setting clear expectations and aligning the test to the organization’s needs.

Compliance Testing

Compliance testing is valued for its repeatability. By following a predetermined set of test cases, it ensures consistency across tests, making it easier to measure improvements over time and identify recurring issues. This makes it an excellent choice for organizations with strict standards or regulatory requirements.

However, the structured nature of compliance testing can also be a limitation. It lacks the exploratory element that allows testers to uncover novel or unexpected vulnerabilities, as it focuses strictly on predefined test cases. Despite this, compliance testing can be particularly useful in rapidly changing environments, as it ensures consistent coverage with every iteration.

Frameworks like PCI-DSS, focused on securing payment card data, and OWASP ASVS, which sets security standards for web applications, provide clear guidelines for compliance testing. While this approach may not catch everything, it is essential for organizations to demonstrate adherence to industry standards, build trust, and maintain accountability.

Configuration Weaknesses and Known Vulnerabilities

This type of testing often covers a broad scope, such as an entire organization or a data center. Unlike compliance testing, it is typically black or gray box, focusing on what can be observed or accessed from a specified starting point. The goal is to identify and exploit known vulnerabilities or misconfigurations to see how far an attacker could progress towards a predetermined objective.

This approach is particularly valuable for assessing the organization’s current security posture against well-documented risks. Testers rely on vulnerability databases, exploit frameworks, and knowledge of common misconfigurations to simulate realistic attack scenarios. For example, they might exploit unpatched software, default credentials, or exposed services to gain deeper access into the environment.

The advantage of this method is its ability to uncover weaknesses that arise from day-to-day operations or overlooked configurations. However, it is not designed to find new, undiscovered vulnerabilities, as its focus remains on existing attack vectors. Organizations benefit from this type of testing by identifying practical areas for improvement, such as patch management, network segmentation, and access controls.

Vulnerability Research

Vulnerability research is typically narrower in scope, focusing on a single system, application, or specific component. Unlike other types of testing, its primary goal is to uncover unknown vulnerabilities—commonly referred to as zero-days—that have not yet been documented or exploited. This makes it one of the most resource-intensive approaches to penetration testing.

The process often involves deep analysis of the target system, including reverse engineering, protocol analysis, and code review. Testers employ creative problem-solving and advanced techniques to identify weaknesses that standard testing methods might miss. For example, they might analyze how an application processes input, searching for subtle errors that could lead to memory corruption or privilege escalation.

This type of testing is particularly important for vendors and organizations managing critical systems. For vendors, performing even basic vulnerability research during development helps identify and address zero-day vulnerabilities before release, reducing the risk of shipping insecure software. For critical systems or those likely to face targeted attacks, discovering even a single zero-day can have significant implications, making this approach invaluable in safeguarding users and maintaining trust.

Conclusion

Penetration testing is not a one-size-fits-all process. Each of the approaches discussed—compliance testing, configuration weaknesses and known vulnerabilities, and vulnerability research—serves a unique purpose, addressing different aspects of an organization’s security. Compliance testing ensures consistency and alignment with standards, configuration testing identifies practical vulnerabilities within a broader scope, and vulnerability research uncovers critical zero-days within specific systems.

Choosing the right type of penetration test depends on your goals, resources, and the systems in scope. Equally important is finding the correct expertise for the job. Each approach requires specialized skills, from regulatory knowledge for compliance testing to deep technical expertise for vulnerability research. The success of a penetration test lies not only in the methodology but also in the proficiency of the testers conducting it.

By understanding the differences and value of each approach, organizations can better align their testing strategies with their needs, ultimately strengthening their overall security posture.

In this post, I’ll dig into some of the key EU regulations that are directly shaping supply chain security and discuss practical steps you can take to build a more resilient supply chain. When we talk about supply chain attacks, we’re not just referring to the direct targets, but to the entire ecosystem. Attackers often exploit the weakest point in the chain—perhaps an unpatched vulnerability in a third-party component or even malicious code that has been slipped into a software update. This makes supply chain security not just an IT issue, but a critical business concern.

A significant risk comes from the potential for backdoors to be introduced into widely-used software libraries. One notable example is the backdoor found in XZ Utils, a compression library used in many Linux distributions. This incident revealed how even seemingly trusted and ubiquitous software components could be compromised, providing attackers with hidden access.

EU Regulations Shaping Supply Chain Security

NIS2 Directive

The NIS2 Directive is one of the key regulations directly targeting supply chain security. It places obligations on “essential” and “important” sectors to actively manage their supply chain risks as part of their overall cybersecurity strategies. This means that organizations can’t just focus on securing their own systems—they need to also assess and manage the risks associated with their suppliers and service providers. In other words, if you’re relying on third-party software, you’re responsible for its security too.

Digital Operational Resilience Act (DORA)

DORA focuses on the financial sector and aims to ensure that financial institutions can withstand ICT-related disruptions, including supply chain incidents. A significant part of DORA’s requirements revolves around third-party risk management. Financial entities are required to monitor and manage risks stemming from their ICT service providers continuously. I find this particularly interesting because it reflects how the financial sector is being pushed to develop more rigorous and transparent supply chain security practices.

Cyber Resilience Act (Proposed)

The Cyber Resilience Act is an upcoming regulation that explicitly addresses software supply chain risks. It aims to impose mandatory cybersecurity requirements for software products, including the need to manage vulnerabilities throughout the software lifecycle. Although it’s still in the proposal stage, this act signals the EU’s intention to address software security from the development phase through to deployment, emphasizing that security isn’t just a one-time effort but a continuous responsibility.

Practical Steps for Building a Secure Supply Chain

With this evolving regulatory landscape in mind, how can businesses actually address these supply chain security concerns? Here are some practical steps:

1. Create and Use an SBOM (Software Bill of Materials) for Supply Chain Visibility

Building an SBOM (e.g., in formats like CycloneDX or SPDX) is one of the most effective ways to gain visibility into your software’s supply chain. Think of an SBOM as an ingredient list that provides detailed information about every component and dependency, including their versions and origins. By maintaining an SBOM and mapping your entire supply chain, you make it easier to identify affected components quickly when new vulnerabilities, like Log4Shell, are disclosed. It also enables you to scrutinize any changes or new additions that might introduce new risks, such as a backdoor in a dependency. Having this level of insight is crucial for addressing both security threats and regulatory requirements around supply chain transparency.

2. Regularly Assess Your Suppliers

Relying solely on certifications isn’t enough. Regular assessments of your suppliers are vital in maintaining a secure supply chain. This might involve reviewing their security practices, examining their own use of SBOMs, and conducting periodic audits. Keep an eye out for signs of compromise, such as unusual changes in the software packages they provide. By continuously evaluating your suppliers’ security measures, you reduce the risk of supply chain attacks and ensure that your suppliers are maintaining a security posture that aligns with your standards.

3. Adopt a Zero-Trust Approach

Implementing a zero-trust model in your supply chain management is an effective way to minimize the potential impact of a supplier breach. This approach assumes that no supplier is fully secure and therefore segments access to your network. By limiting the access that suppliers and third-party components have, you can contain the potential damage if one of them is compromised. This mindset not only mitigates risks but also supports a more robust, layered defense strategy that aligns well with the evolving landscape of supply chain security.

Conclusion

Supply chain security is no longer just an optional extra—it’s an essential part of any robust cybersecurity strategy, especially as the EU continues to tighten its regulatory requirements. Regulations like the NIS2 Directive and DORA directly call for organizations to address supply chain risks actively. Meanwhile, the proposed Cyber Resilience Act signals the EU’s growing focus on software security throughout its lifecycle.

While compliance is important, practical measures like using an SBOM and adopting a zero-trust mindset will go a long way in building a more resilient supply chain. Don’t overlook the risk of backdoors and malicious code in your dependencies. Supply chain security isn’t just about patching vulnerabilities; it’s about ensuring the integrity of every component in your software.

References

1. NIS2 Directive
2. Digital Operational Resilience Act (DORA)
3. Cyber Resilience Act (Proposal)

The first and easiest viewpoint is that of a business that isn’t producing a digital product, neither for yourself nor for your customers. Noteworthy here is that any website is acquired as a product from a third party. This means that no product development is performed in house. In this case the full extent of cybersecurity is to ensure that the IT-environment does not get breached. This means a focus on raising security through configurations and products as well as ensuring that you trust the products provided by your suppliers.

Next up we take the viewpoint of a Something as a Service (XaaS) provider. In this case you develop a digital solution and manage the data of your clients in your IT-environment. This includes both traditional software companies (such as Google) and organisations that build software to better serve there clients, e.g. the local sports team building an e-shop to sell tickets online. Now there is an extra focus on ensuring that the in-house software does not contain neither vulnerabilities nor malware. Since both these cases can have an impact on both the company themselves and the customers.

For a company that provides software that is run purely in the environment of their customer the focus might be more focused on providing software without malware. Since the impact of a vulnerability in the product is lower for them, while being part of a supplychain attack will be devastating.

With these viewpoints we note that your needs might vary, and once again we see the risk of confusion due to reading different things into the word cybersecurity. I’ve been guilty of this myself, as someone whom have worked close to vulnerabilities throughout my career I’ve had a focus on application security and delivering software without vulnerabilities. But that is just a small part of the field of cybersecurity.

But what part of this is most important? That is up to each organisation to decide. However, for a general answer we can look to the statistics. IBM has provided a report on the Cost of a Data Breach that can be used to gain some insights. In this report we see that the most common initial access vectors (entry point for bad actors) are still human related. The two most common attacks are phishing and stolen or compromised credentials. If we combine known vulnerabilities and zero days (not yet reported vulnerabilities) we end up in the same range. My conclusion is that the focus we have on vulnerabilities in the cybersecurity industry has paid of, and it is now easier to exploit the humans where the technical protections have not kept up.

Summary

Cybersecurity can be difficult due to the different meanings. One way to brake it down is into the following three focus areas:

1. Ensuring that the own internal IT-environment doesn’t get breached
2. Ensuring that delivered products are without vulnerabilities
3. Ensuring that delivered products are without malware

Depending on your organisation the priority of these might change, and one might affect another. Regardless, you need to understand what part or parts of cybersecurity is relevant to you and your customers. If not, you might be spending your money without protecting what’s important.

Lastly we have to normalize discussing the definitions of what we are talking about. Sometimes it’s not enough to ask if you know, we also need to clarify that we agree on the meaning.

1. 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.
2. 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.

The Three Categories of Vulnerabilities

The three categories are presented in this post are:

1. Context Dependant Vulnerabilities
2. Business Logic Vulnerabilities
3. Vulnerabilities Abusing the Technology Stack

Context Dependant Vulnerabilities

This group of vulnerabilities is mostly relevant in system development. They include vulnerabilities that are based on input and output of data. Whenever data is entered into the system, and then exit the system there is a risk of Context Dependant Vulnerabilities. One of the most common examples are Cross-Site Scripting vulnerabilities (also known as XSS). This vulnerability occurs when the system somehow allows a user to inject code into the website (JavaScript), that then will execute. In doing so the attacker gains access to everything on the webpage, allowing them to perform any action as the user. In this example the web application does not accurately handle the data that is input as text (string) and printed on the webpage (HTML encoded string).

This kind of issue mainly occurs when developing new systems or application. Therefore, it is important to have an awareness throughout the whole development process about the risk. The requirements, design, implementation and testing needs to take this kind of vulnerability into account. A good way to initiate discussions about this kind of vulnerabilities is Threat Modelling. By threat modelling the team initiate a discussion about the system, any integrations between parts, as well as the risks that might occur.

Even though it seems to be a daunting task to look at all data flows, the good thing is that as long as no changes are made to the system, no new vulnerabilities will be introduced. Context dependant vulnerabilities are therefore stable, and will have a limited growth over time.

Business Logic Vulnerabilities

Business Logic vulnerabilities occurs as a result of misunderstandings between the business and the team implementing the system. What happens if someone can abuse the business functions? A common example is the web shop that allowed users to order -1 items, debiting their account accordingly. However this can be much more complex, and require an intricate understanding of the business.

To minimise the risk of this kind of vulnerabilities there are two things to do. Firstly the requirements for the system needs to be complete. They should not only indicate what functionality should be there, but also what should not be allowed. By detailing the requirements the business gives the team implementing the features a better understanding and therefore allow them to see the risks. The second step is a good old fashioned risk analysis. However, it is important to emphasise that the risk analysis should be of the system, not the project that implements it. In what way could the system be abused and what could the goals for an attacker be?. These questions needs to be answered to minimise the risk.

Vulnerabilities Abusing the Technology Stack

If the two previous kinds of vulnerabilities have their root in the development phase, this category is more based on configuration and maintenance. This is known vulnerabilities that occurs due to a lack of system hardening (e.g. weak passwords or outdated web-server). This also means that even though no further development of the system has occurred, new vulnerabilities may arise. When implementing the system it is important to harden the system, and then after release it should be maintained and its life cycle managed.

Due to the sheer number of devices relying on common software (such as web-servers or operating systems) this group of vulnerabilities are often used for non targeted attacks. For example a ransomware gang might not care whom it infects and therefore just scan the internet for vulnerable systems. These systems are then automatically infected. The goal is infecting as many victims as possible not just a single target.

Always updating soft- and hardware is an endless battle. A race against the attackers. How can we ensure that systems are up to date and hardened according to the latest standards? In addition, any update might have an impact to the functionality. Therefore there needs to be a balance with stability requirements.

This group might have the easiest solution, just update and configure, but the time investment is huge. Since you need to continuously need to maintain the system the investments are recurring. Depending on the size of the company the goals might be different. However, the risk of attack has to be weighed against the cost in an analysis for each business.

Summary

Any business using IT systems needs to be aware of the kind of vulnerabilities that might impact them. By having a basic awareness and specify the requirements of their systems the business will be better equipped to manage their risk.

We as cybersecurity professionals need to be better at leveraging this diversity of skills and knowledge to our advantage. We can learn from each other when it comes to securing our business, because that is what’s most important. There is no need to be territorial about our knowledge, we need to share with and learn from others. This is not only applicable for skills and knowledge, but also for ways of working and other methodology. It is always a good idea to leverage the diversity of a group.

IT and OT-Security

Two fields that rarely communicate, but I feel could learn lots from each other are IT and OT security. There are things in both areas that are not transferable between them, but that does not mean that nothing can be transferred. For example IT and OT is moving towards convergence on a technical level, therefore it could do the same on a technical level.

The following talk by Mats Karlsson Landré is a great starting point for this kinds of discussions. Here he describes the current state of OT-Security, and at what points a discussion between IT and OT professionals will be relevant.

Lawyers and Practitioners

When we talk about cybersecurity professionals we should not get stuck in the box with whom we are talking to. For example a lawyer could be invaluable for a practitioner, regardless if they are technical penetration testers or management consultants writing a policy. For example a penetration test could yield extra findings due to stricter regulations for healthcare providers. If you only know the technical part, how would you know the difference?

In the other direction lawyers might get better at triaging after discussing with the Security Operation Center (SOC) team. In their field it is important to get a priority at a glance, and know what tasks needs to be fixed immediately and which can wait.

Security and Developers

Due to my work in AppSec, my experience of the importance of sharing is not only with other security professionals. It is just as much, if not more, with developers. When it comes to complex vulnerabilities in a system I often discuss them with developers. Since I need to support developers for different systems, programming languages, and deployments I cannot be an expert of the ins and outs of each of them. Therefore, it is much more efficient to have a discussion with an expert. Often when I describe the risk (how I think it will be possible to exploit something) the developer can show how it is not a problem, or we together build an exploit that helps the developer understand why it is an issue. Either way, we build trust with the development team, I learn about the specific system/language etc, and the developers learn about potential risks to avoid. All of which are desirable outcomes.

Conclusion

The security field, as well as IT in general is a huge field. No one can be an expert at everything, but everyone has their niche. To protect the business as well as we can we need to communicate between disciplines and learn from each other.

By just working together and getting the chance to get a common language and ask why to things the overall understanding increases in the organisation, while the overall risk is lowered. When everyone get to ask questions, we broaden our views and sees things from other points of view. In doing so we also find both problems and solutions that otherwise never would have been found.

For anyone interested in the benefits of great communication (outside security), and generally on how to improve a workplace I must recommend anything by Adam Grant. He has TED talks, books and podcasts etc. Usually all of them gives insights into how we can improve the workplace.

Photos

Photos from Unsplash

1. Photo by Rod Long on Unsplash
2. Photo by Alvaro Reyes on Unsplash

What are Security Champions?

Security Champions are individuals throughout the organisation that takes an extra responsibility about security. Exactly how many there are varies, from one per dev-team to one per product or office location. The goal is to have a local contact that ensures that security is on the agenda.

This does not mean that the Security Champion is doing everything about security in their part of the organisation. The clue is in the name, Security Champion, they should Champion security. Keeping tabs on what is going on, asking questions and being a natural communication way between the organisation and the security department. This communication should be two-way, both from the security specialists to the organisation (eg. we have a new tool you can use) and back (eg. we are implementing this and could use help assess the risk).

Why use Security Champions?

Security Champions are a great way to broaden the security team. To get the security team to reach the whole organisation is a big challenge, but by using Security Champions as a middle man one can gain a lot. In addition to just advocating for security throughout the organisation, they have a better understanding about their business area, and therefore they are also better equipped to find the risks. The main goal of the Security Champions is not to take them from their original tasks, rather to give them the tools to continue doing so while ensuring that they and their colleagues keep security and risk in mind.

In the end, Security Champions allow the dedicated security team to effortlessly spread information to, and collect information from the whole organisation

How to Implement Security Champions Efficiently?

To successfully implement a Security Champion program is not a thing that can be done overnight. It takes dedication and time. From experience, I would recommend the following steps to build a successful Security Champion program:

1. Build interest in security
2. Educate the Security Champions
3. Give the freedom to make an impact
4. Exchange information between Security Champions and the security team
5. Motivate through networking between Security Champions in different parts of the organisation

Let us dig a bit deeper into each of these steps. First we have to find our Security Champions. The good Security Champions needs to have a genuine interest in security. That is not that common to begin with, but it can be nurtured. For example if you have security awareness training, this is a great occasion to motivate and build the interest in security. In addition, you can find the individuals who are interested and recruit them as Security Champions.

With our Security Champions found it is time to ensure that they feel important. Otherwise, the risk of them loosing interest will be rising. It cannot only be a hazel to be a Security Champion, it must give something back as well. That might be the possibility to learn more things over time. My recommendation is to arrange an initial Security Champion Training in areas relevant to your organisation, and then continuously (eg. yearly) arrange something new and interesting, such as inviting a guest lecturer or an internal conference.

During their time as Security Champions everyone needs to be able to make an impact. They need their freedom to drive security forward in their area. As with everything this is done through giving responsibilities as well as mandate to make decisions. In addition, they need to have the time provided to make a difference. Once more, being a Security Champion should not be a hazzle.

Lastly I recommend creating a network of Security Champions throughout the organisation. This network should meet regularly to exchange learning, as well as discuss news that have an impact on the organisation. This is also a great time to align the security work, ensuring that the Security Champions and the Security Team are working together towards a common goal.

Conclusion

Security Champions are a great way to extend the security teams reach throughout the organisation. By educating and networking we build a set of individuals that can work together to champion security, and keep it on the agenda everywhere. In addition, the Security Champions improves the information flow around security throughout the organisation, increasing the visibility of the security team, making it more likely that important questions reach them. ''

Overall the goal with Security Champions is communication and alignment. Ensuring that the organisation is aware of risks and actively works towards being more secure.

Photos

Photos from Unsplash

1. Photo by mahdis mousavi on Unsplash
2. Photo by Stijn Swinnen on Unsplash
3. Photo by Samrat Khadka on Unsplash

Note: Any specific examples in this post are fictional, but the concepts are quite common from looking around and talking to businesses.

Separate Guests and Internal Users

To minimise the exposure of the systems the business require to operate and therefore also minimize the risk it is important to reduce the number of people whom have access to the network. The main thing here is to keep any visitors (or customers) from accessing the same network as the internal systems (fileservers, cash registers etc.). A common solution for this is to have two separate networks, a guest network and a company network. For larger companies this separation might need to be taken even further, but this is a great first step.

The main goal with separation is to implement what is commonly called Defence in Depth. This means that if one of the security measures would fail, all would not be lost. Instead there would be another defence that would hinder the attack. By restricting what an attacker can access, the risk that they can exploit a vulnerability decrease as well.

Secure the Internal Network

No matter how well separated the internal network (and its users) are from the external users it has no effect if there are ways to circumvent the separation. For example if in a café a customer can plug into the access-point and access the internal network. Another perhaps more common error is to have an easily guessable password for the internal network. If the WiFi name is used as password, it is the same as if there was no password at all. An attacker would swiftly test different passwords, and the name of the network would absolutely be one of the first ones.

Change Default Settings

After taking a look at the network as a whole it is time to look at the systems on the network. When adding a new system it is important to take a look at the vendors configuration recommendations. Are there any security features that can be enabled? Another important step is to change any default passwords in the system.

Overall the goal in this step is to minimise the risks by utilising any defences of the systems on the network.

Keep Systems Updated

Lastly, all devices on the network needs to be maintained. Vulnerabilities will be found in the solutions used on the network, and there is nothing that can be done about it. As a business owner the only thing to do is to be aware and ensure to have a regular update schedule. When a vulnerability pops up, the patch needs to be applied as soon as possible. One way to do this is by automating the installation of updates. This ensures swift updates without adding the overhead of keeping track of when updates are released and applying them manually.

Installing updates without first testing them adds another risk in the form of supply chain attacks. However, the risk in comparison to the cost of mitigation is quite low. Every business needs to make their own analysis, but from my point of view, the benefit of swift updates outweigh the risks for most small companies.

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.

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:

1. Which systems has the most risks?
2. Which systems has the most critical risks?
3. 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.

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.

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:

1. No
2. Yes, for some applications
3. Yes, for at least half of the applications
4. 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.

In this post I’m going to introduce categories of testing for administrators in much the same way as I did for developers, allowing any team to begin thinking about security and performing basic security testing. The categories proposed can also be adapted to be used as requirements, more so than the ones used for developers. This is since they are easier to apply regardless of what solution is tested.

Exposure Vulnerabilities

The first category of vulnerabilities are related to exposure. To minimise the risk, it is important to not expose functionality that is not required. This could for example be blocking access to the database so that only the application can connect to it. There is no reason that it should reachable by everyone.

By limiting the exposure the impact of other vulnerabilities are limited. The possibility to attack a vulnerable administrative interface gets limited if only users on the administrative network are allowed to connect to it. However, it is important to remember that separation is not the silver bullet that protects against everything, but rather one layer of the defence.

Application Configuration Vulnerabilities

All solutions have a function that needs to be exposed to it’s users. This functionality cannot be blocked and therefore has to be protected by other means. Here most providers of applications do (or should) provide best practices for how to configure their application in a secure manner. Exactly how this should be configured are dependant on the application used, but the main goal is to minimise the risk of the application being exploited.

There are multiple examples of configuration that can be configured in applications. Some examples are:

1. Enabling security functions
2. Disabling unused functionality
3. Change default credentials

A common example of vulnerable configuration on the web is regarding encryption and HTTPS. To be secure it is important to both enable TLS by allowing connecting in HTTPS, and disable vulnerable versions of TLS, such as TLSv1.0. To know exactly what is secure and what is not is difficult, and therefore the best practices provides guidance.

Vulnerabilities in Outdated Components

Last, but not least it is important to keep the environment up to date by applying the patches provided by the supplier. Patching is not only applicable for the main application, but for all software running on the system. To once again use the web as an example an up to date webserver might be exploited by using an outdated version of openssl (that provides TLS).

To keep a system up to date might be more work than expected since you have to keep up to date with what patches are provided, verify their functionality and then update. To help with the keeping up to date part many suppliers provide newsletters and advisories that informs their subscribers when a new update is available.

Summary

When it comes to security for administrators it’s important to have a defence in depth strategy. It is not enough to protect against any single one of these categories of vulnerabilities. To protect efficiently all layers of security needs to be applied.

This methodology does not protect against exploits in the application, since each application might be vulnerable. It assumes that the suppliers have their own way of ensuring that their product is secure. If the application is vulnerable np configuration will protect, and testing for these categories of vulnerabilities will not help. Instead it is recommended to read the post security for development teams.

With this post I will try to do the impossible, to describe how you work with security in a practical manner, regardless of what technology you use. I will highlight three categories of vulnerabilities, and describe them in a technology independent way. My hope with this is to allow any development team to have a think about security, and apply them to their specific technologies.

Throughout the article I will use the word component to describe a piece of software. This can be as small as a function, or as big as a financial system. The main thing is that the software takes some kind of input, and based on that input performs some actions which leads to a result. This could be sending a request to a web API which returns user information, or pushing a button resulting in raising the target temperature of a room. However small or big the component is, the concepts explained will be applicable. This input is used both for legitimate usage, and for potential attacks, and therefore is it important to understand the risks.

I will in this post propose that there are three different kinds of vulnerabilities that can be found in any type of software. This will allow us to have a common ground for discussing security between different domains, and adapt it to where you have your expertise.

Context Dependent Vulnerabilities

Lots of technical vulnerabilities is due to a change of context from where data is inserted into a component, and where it is used. If the context of the data is changed, but the data is not adapted correctly the risk for a possible exploit increases. The goal of an attacker when attacking the contexts is to break out off the assigned field of the data and in doing so gaining access to data or functionality that it is not intended to have.

One of the most well known example of context dependent vulnerabilities are an SQL injection. In an SQL injection the attacker breaks out of the data context of the database query to create one specified by the attacker. In doing so the attacker can fetch any data in the database, or even modify the data.

To test or mitigate these issues the development team should think about the context of the input and output data. The data input might need to be decoded before logic is performed on it. To decode the input correctly the development team needs to understand the input context, and any encodings used in the context. Next up the same considerations needs to made on the output context. If data is output into an HTML context, the relevant characters needs to be HTML encoded.

Business Logic Vulnerabilities

The second kind of vulnerabilities are vulnerabilities that directly affect the business logic. These are often the easiest to understand and explain, since they directly has a business impact. A simple example would be in a web shop. The intended function is for the price to pay equals the sum of all the products. But what would happened if you tried to order a negative number of products? The reasoning does not make sense in a business perspective, but if there are no protections the web shop will give a negative total.

A common way to work with business logic vulnerabilities is through abuser-stories or abuse-cases. These are tightly related to their respective user-stories or use-cases, but helps to show what an attacker want. In doing so it highlights the risks, and adds them to the requirements (how to work with abuse-cases and abuser-stories will however have to be another post in the future). This way they are both tracked and tested along the functional requirements, removing some of the fog around security.

Abusing the Technology stack

The last kind of security is the hardest to describe broadly, since it is connected to the technology stack used in the project. Any technology has its own risks and vulnerabilities, therefore you need to read up on what is applicable in your area. This could be vulnerabilities specific to your programming language (buffer overflow in c), to the tools you are using (XML External Entity attack when using XML or clickjacking on the web), or specific to your dependencies (known vulnerabilities in the used versions). When becoming an expert on the technology stack I would argue that it is required to also have an insight into the vulnerabilities that are specific to that stack. However this cannot be done once, just as the technology evolve so does the potential attacks. You have to keep up to date.

Even though this requires actively seeking some knowledge in the area, it is an important expertise to have in the teams. A third party tester does rarely get the same insight into the technologies used as the team has, and therefore they might miss some important finding. By combining the tester outside the team with the one inside, the risk of vulnerabilities being missed are minimised.

Summary

The work of security professionals are often seen as obscure and mystic. They come in and points to errors, just to leave and not return until the next release. However their goal align with the goal of the team, the delivery of high quality software. By breaking down security vulnerabilities into three groups I aim to bridge some of that gap between security professionals and the teams. Anything the team can find and fix is a plus. By thinking of the three areas of security vulnerabilities (Context Dependent, Business Logic, and Abusing the Technology stack) I hope that development teams gain the introduction needed to begin working with security. It is no magic, it is just another part of the toolbox that all development teams need to produce great software.

The Download Process

The process to get access to your data is quite straight forward. There are clear descriptions on how to download your data under privacy settings, where you can request a download. The collection process takes a while and an email is sent when your data is ready to be downloaded. In the email there are a link that allows you to download a zip archive containing your information.

Analysis of the Data

After extracting the data we find the following files:

$ ls -lah
total 1.4M
drwxr-xr-x 1 edbro 197121    0 Jan  6 11:06 .
drwxr-xr-x 1 edbro 197121    0 Jan  8 11:45 ..
-rw-r--r-- 1 edbro 197121   62 Jan  6 11:06 DuoNewFamily.json
-rw-r--r-- 1 edbro 197121  222 Jan  6 11:06 Follow.json
-rw-r--r-- 1 edbro 197121 1.1K Jan  6 11:06 Inferences.json
-rw-r--r-- 1 edbro 197121  105 Jan  6 11:06 Payments.json
-rw-r--r-- 1 edbro 197121 170K Jan  6 11:06 Playlist1.json
-rw-r--r-- 1 edbro 197121 183K Jan  6 11:06 Read_Me_First.pdf
-rw-r--r-- 1 edbro 197121  12K Jan  6 11:06 SearchQueries.json
-rw-r--r-- 1 edbro 197121 952K Jan  6 11:06 StreamingHistory0.json
-rw-r--r-- 1 edbro 197121  308 Jan  6 11:06 Userdata.json
-rw-r--r-- 1 edbro 197121 7.6K Jan  6 11:06 YourLibrary.json

The read me first PDF file contains some information about what’s not included and how to get access to it. For example it links to https://support.spotify.com/uk/article/gdpr-article-15-information/ about the legal grounds for the processing of data. It also links to an article about how to understand the information in these files. It explains what the files contain on a high level (https://support.spotify.com/uk/article/understanding-my-data/). If you have some experience I feel like you would get the same from reading the json files, but it is nice that they include it. After reading the PDF, let’s dig into the actual user data.

The first analysis is to get an overview of the size of the files and if they are interesting. This gave some basic information about the files, as listed below:

• DuoNewFamily.json Only contains the address of the family account (yes I use Spotify duo).
• Follow.json Small file containing information about my followers as well as users and artists i follow. Note however that only the artists I follow are listed, the other parts are just in numbers.
• Inferences.json Contains a list of categories which Spotify have classified me into. Gives an insight into what Spotify knows about me, but does not need any further investigation. Example categories are: “1P_Custom_Samsung_Galaxy_S10_Users” and “1P_Podcast Listeners_True Crime”.
• Payments.json Contains information about when my account was created, and how I pay for the service.
• Playlist1.json Fully lists the playlists I’ve created. The file is large and will be inspected more deeply.
• SearchQueries.json Lists the searches performed, and on what device it was performed, as well as the timestamp for the search.
• StreamingHistory0.json Contains all the songs listened to, for how long, and when.
• Userdata.json About what you expect, information about your user. Nothing more and nothing less.
• YourLibrary.json A big file containing things you like, everything from podcasts or artists to songs. In addition it shows songs you’ve disliked and that are hidden from your account.

Let’s dig a bit deeper into some of these files and look what they are hiding.

Playlist1.json

Each playlist are listed with the following information:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

    {
      "name": "TEST",
      "lastModifiedDate": "2020-10-20",
      "items": [
        {
          "track": {
            "trackName": "Party In The U.S.A.",
            "artistName": "Miley Cyrus",
            "albumName": "The Time Of Our Lives"
          },
          "episode": null,
          "localTrack": null
        },
        {
          "track": {
            "trackName": "Year of the Young",
            "artistName": "Smith & Thell",
            "albumName": "Year of the Young"
          },
          "episode": null,
          "localTrack": null
        }
      ],
      "description": null,
      "numberOfFollowers": 0
    }

The information is exactly what’s expected, containing information about your playlists and their contents, but nothing more. Noteworthy is however that there are no information about the lists that you follow, only the ones you have created.

SearchQueries.json

After looking at the file, the contents only show the searches for the last three months. This indicates that Spotify does regularly clean up their data to avoid collecting to much of it, a big plus from me!

each query has the following information:

1
2
3
4
5
6
7
8

  {
    "platform" : "ANDROID_ARM",
    "searchTime" : "2020-10-09T10:36:07.879Z[UTC]",
    "searchQuery" : "lofi ",
    "searchInteractionURIs" : [
      "spotify:playlist:0pGdGpMm84h2Jl6Q1KmTMn"
    ]
  }

Here are some more data, but not so much as to raise any flags. The platform might not be necessary in this context, but I’m not that surprised to se it.

StreamingHistory0.json

This file logs all the songs you have listened to within the timespan of the log. For me this is a bit more than 12 months, but I cannot specify that exactly with this data. The log contains about what you expect, such as time, how long the song was listened to, and what song.

1
2
3
4
5
6

  {
    "endTime" : "2020-12-17 14:28",
    "artistName" : "RadioClub",
    "trackName" : "Never Gonna Give You Up",
    "msPlayed" : 161297
  },

Userdata.json

The user-data collected about the user. Note, here I’ve changed my information to XXX. If there is a NULL, Spotify has not populated the data.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14

{
  "username": "XXX",
  "email": "XXX",
  "country": "SE",
  "createdFromFacebook": false,
  "facebookUid": null,
  "birthdate": "XXX",
  "gender": "male",
  "postalCode": "XXX",
  "mobileNumber": null,
  "mobileOperator": null,
  "mobileBrand": null,
  "creationTime": "XXX"
}

I find it interesting that Spotify collects information about the mobile brand and operator. I cannot tell why this is not populated for my account, but might be something to watch out for.

Missing Information

After investigating the full data export from Spotify I feel that there are some data missing. I cannot find any references to playlists that I follow. When reaching out to Spotify about this they recommended that I look for it in the second level of data. The support representative triggered the collection, and after that the data was downloaded the same way as the level 1 data.

Analysis of the Level 2 Data

The second level of data contains a lot more than the first. As shown below there are 111 files in the second level.

ls -lah
total 27M
drwxr-xr-x 1 edbro 197121    0 Jan 13 18:16 .
drwxr-xr-x 1 edbro 197121    0 Jan 13 18:16 ..
-rw-r--r-- 1 edbro 197121  42K Jan 13 18:28 A11yFeatureUsage.json
-rw-r--r-- 1 edbro 197121 1.9K Jan 13 18:28 AccountMutated.json
-rw-r--r-- 1 edbro 197121  768 Jan 13 18:28 ActionLog.json
-rw-r--r-- 1 edbro 197121  44K Jan 13 18:29 AdRequestEvent.json
-rw-r--r-- 1 edbro 197121 5.8K Jan 13 18:29 AddToPlaylist.json
-rw-r--r-- 1 edbro 197121  393 Jan 13 18:28 AddedToCollection.json
-rw-r--r-- 1 edbro 197121 2.9K Jan 13 18:28 AddedToPlaylist.json
-rw-r--r-- 1 edbro 197121  247 Jan 13 18:28 AddedToRootlist.json
-rw-r--r-- 1 edbro 197121 138K Jan 13 18:29 AndroidDeviceReport.json
-rw-r--r-- 1 edbro 197121 267K Jan 13 18:32 ApAuthenticationSuccess.json
-rw-r--r-- 1 edbro 197121 231K Jan 13 18:29 Ap_AdEvent.json
-rw-r--r-- 1 edbro 197121 2.6K Jan 13 18:29 Ap_AddToPlaylist.json
-rw-r--r-- 1 edbro 197121 4.1K Jan 13 18:30 Ap_BrowseLink.json
-rw-r--r-- 1 edbro 197121 450K Jan 13 18:30 Ap_Download.json
-rw-r--r-- 1 edbro 197121 2.1M Jan 13 18:30 Ap_EndSong.json
-rw-r--r-- 1 edbro 197121 1.4M Jan 13 18:30 Ap_ExternalAccessory.json
-rw-r--r-- 1 edbro 197121  56K Jan 13 18:31 Ap_Interaction.json
-rw-r--r-- 1 edbro 197121 296K Jan 13 18:31 Ap_LogIn.json
-rw-r--r-- 1 edbro 197121 913K Jan 13 18:31 Ap_PageView.json
-rw-r--r-- 1 edbro 197121  59K Jan 13 18:31 Ap_Share.json
-rw-r--r-- 1 edbro 197121 421K Jan 13 18:32 Ap_UIInteraction.json
-rw-r--r-- 1 edbro 197121 552K Jan 13 18:35 AppFocusState.json
-rw-r--r-- 1 edbro 197121 187K Jan 13 18:35 AudioDriverInfo.json
-rw-r--r-- 1 edbro 197121 298K Jan 13 18:37 AudioFileSelection.json
-rw-r--r-- 1 edbro 197121  32K Jan 13 18:37 AudioOffliningSettingsReport.json
-rw-r--r-- 1 edbro 197121 742K Jan 13 18:37 AudioRouteSegmentEnd.json
-rw-r--r-- 1 edbro 197121 230K Jan 13 18:37 AudioSessionEvent.json
-rw-r--r-- 1 edbro 197121 175K Jan 13 18:37 AudioSettingsReport.json
-rw-r--r-- 1 edbro 197121  33K Jan 13 18:38 AudioStreamingSettingsReport.json
-rw-r--r-- 1 edbro 197121  44K Jan 13 18:38 AuthHTTPReqWebapi.json
-rw-r--r-- 1 edbro 197121  595 Jan 13 18:38 AuthorizationCodeExchangeSuccess.json
-rw-r--r-- 1 edbro 197121 227K Jan 13 18:38 BrokenObject.json
-rw-r--r-- 1 edbro 197121 4.3K Jan 13 18:38 CacheError.json
-rw-r--r-- 1 edbro 197121  83K Jan 13 18:38 CachePruningReport.json
-rw-r--r-- 1 edbro 197121 178K Jan 13 18:39 CacheRealmPruningReport.json
-rw-r--r-- 1 edbro 197121 1.4M Jan 13 18:39 CacheRealmReport.json
-rw-r--r-- 1 edbro 197121 351K Jan 13 18:39 CacheReport.json
-rw-r--r-- 1 edbro 197121 9.0K Jan 13 18:39 ClientLocale.json
-rw-r--r-- 1 edbro 197121  47K Jan 13 18:39 ClientRespondedToConnectStateCommand.json
-rw-r--r-- 1 edbro 197121 1.1K Jan 13 18:39 ClientSentConnectStateCommandSourceIP.json
-rw-r--r-- 1 edbro 197121  34K Jan 13 18:39 ClientSentConnectStateCommandTargetIP.json
-rw-r--r-- 1 edbro 197121  48K Jan 13 18:40 ColdStartupSequence.json
-rw-r--r-- 1 edbro 197121 537K Jan 13 18:40 ConfigurationApplied.json
-rw-r--r-- 1 edbro 197121  33K Jan 13 18:40 ConnectDeviceDiscovered.json
-rw-r--r-- 1 edbro 197121 1.2K Jan 13 18:42 ConnectTransferResult.json
-rw-r--r-- 1 edbro 197121 393K Jan 13 18:41 ConnectionError.json
-rw-r--r-- 1 edbro 197121  58K Jan 13 18:42 DailyMixContents.json
-rw-r--r-- 1 edbro 197121  84K Jan 13 18:42 DailyXContents.json
-rw-r--r-- 1 edbro 197121 2.5K Jan 13 18:42 DeeplinkOpen.json
-rw-r--r-- 1 edbro 197121 3.6K Jan 13 18:42 DefaultConfigurationApplied.json
-rw-r--r-- 1 edbro 197121 9.6K Jan 13 18:43 DesktopGPUAccelerationInfo.json
-rw-r--r-- 1 edbro 197121 1.8K Jan 13 18:43 DesktopUpdateDownloadComplete.json
-rw-r--r-- 1 edbro 197121 2.5K Jan 13 18:43 DesktopUpdateMessageAction.json
-rw-r--r-- 1 edbro 197121 3.1K Jan 13 18:43 DesktopUpdateMessageProcessed.json
-rw-r--r-- 1 edbro 197121  23K Jan 13 18:43 DesktopUpdateResponse.json
-rw-r--r-- 1 edbro 197121 128K Jan 13 18:43 DeviceIdentifier.json
-rw-r--r-- 1 edbro 197121 298K Jan 13 18:43 DeviceQuery.json
-rw-r--r-- 1 edbro 197121 6.9M Jan 13 18:44 Download.json
-rw-r--r-- 1 edbro 197121 230K Jan 13 18:44 DrmRequestFailure.json
-rw-r--r-- 1 edbro 197121 129K Jan 13 18:44 ExternalAccessoryRemoteInteraction.json
-rw-r--r-- 1 edbro 197121 1.5K Jan 13 18:44 ExternalDeviceInfo.json
-rw-r--r-- 1 edbro 197121 295K Jan 13 18:44 HeadFileDownload.json
-rw-r--r-- 1 edbro 197121 1.4K Jan 13 18:44 InAppMessageDiscardedEvent.json
-rw-r--r-- 1 edbro 197121 2.2K Jan 13 18:44 InAppMessageImpressionEvent.json
-rw-r--r-- 1 edbro 197121  542 Jan 13 18:44 InAppMessageInteractionEvent.json
-rw-r--r-- 1 edbro 197121 2.1K Jan 13 18:45 InAppMessagePresentationPerformanceEvent.json
-rw-r--r-- 1 edbro 197121 2.1K Jan 13 18:45 KmInteraction.json
-rw-r--r-- 1 edbro 197121 1.8K Jan 13 18:45 KmPageView.json
-rw-r--r-- 1 edbro 197121  13K Jan 13 18:45 LanguageSelection.json
-rw-r--r-- 1 edbro 197121 103K Jan 13 18:45 LocalFilesReport.json
-rw-r--r-- 1 edbro 197121  371 Jan 13 18:45 NewLoginNotificationSent.json
-rw-r--r-- 1 edbro 197121  581 Jan 13 18:45 OAuthAuthorizeGrant.json
-rw-r--r-- 1 edbro 197121  28K Jan 13 18:45 OfflineError.json
-rw-r--r-- 1 edbro 197121 9.6K Jan 13 18:45 OfflineEvent.json
-rw-r--r-- 1 edbro 197121 193K Jan 13 18:45 OfflineReport.json
-rw-r--r-- 1 edbro 197121  38K Jan 13 18:45 ParadoxCampaignOptimizerEvent.json
-rw-r--r-- 1 edbro 197121  234 Jan 13 18:46 PlacedOrderClosed.json
-rw-r--r-- 1 edbro 197121  184 Jan 13 18:46 PlacedOrderCreated.json
-rw-r--r-- 1 edbro 197121 1.7K Jan 13 18:46 PlaybackError.json
-rw-r--r-- 1 edbro 197121 8.5K Jan 13 18:46 PlaybackInitiatedOnDevice.json
-rw-r--r-- 1 edbro 197121 1.3K Jan 13 18:46 PlaybackRetry.json
-rw-r--r-- 1 edbro 197121 1.1M Jan 13 18:46 PlaybackSegments.json
-rw-r--r-- 1 edbro 197121  82K Jan 13 18:46 PlayerStateRestore.json
-rw-r--r-- 1 edbro 197121 907K Jan 13 18:46 Prefetch.json
-rw-r--r-- 1 edbro 197121  54K Jan 13 18:46 PushAndroidDeviceSettingsV1.json
-rw-r--r-- 1 edbro 197121  55K Jan 13 18:46 PushNotificationAndroidOSChannels.json
-rw-r--r-- 1 edbro 197121 1.1K Jan 13 18:46 PushTokenRegistrationErrorV1.json
-rw-r--r-- 1 edbro 197121 4.8K Jan 13 18:46 PushTokenRegistrationV1.json
-rw-r--r-- 1 edbro 197121  12K Jan 13 18:46 PushkaPushEventV1.json
-rw-r--r-- 1 edbro 197121 179K Jan 13 18:16 Read_Me_First.pdf
-rw-r--r-- 1 edbro 197121  198 Jan 13 18:47 RemovedFromCollection.json
-rw-r--r-- 1 edbro 197121  17K Jan 13 18:47 RequestFailure.json
-rw-r--r-- 1 edbro 197121 8.8K Jan 13 18:47 ResolveConfigurationError.json
-rw-r--r-- 1 edbro 197121 396K Jan 13 18:47 SearchViewResponse.json
-rw-r--r-- 1 edbro 197121  43K Jan 13 18:47 SemanticMetricClient.json
-rw-r--r-- 1 edbro 197121 4.2K Jan 13 18:47 Share.json
-rw-r--r-- 1 edbro 197121  397 Jan 13 18:47 SocialConnectSessionCreated.json
-rw-r--r-- 1 edbro 197121  428 Jan 13 18:47 SocialConnectSessionJoined.json
-rw-r--r-- 1 edbro 197121 4.2K Jan 13 18:47 SocialConnectUserActiveDeviceChanged.json
-rw-r--r-- 1 edbro 197121  948 Jan 13 18:47 SongCreditsRequest.json
-rw-r--r-- 1 edbro 197121 1.8M Jan 13 18:47 SportyFormatlistRequest.json
-rw-r--r-- 1 edbro 197121 109K Jan 13 18:48 StartContext.json
-rw-r--r-- 1 edbro 197121 7.2K Jan 13 18:48 Stutter.json
-rw-r--r-- 1 edbro 197121 158K Jan 13 18:48 TrackNotPlayed.json
-rw-r--r-- 1 edbro 197121 4.4K Jan 13 18:48 TrackStuck.json
-rw-r--r-- 1 edbro 197121  381 Jan 13 18:48 TransactionalEmailerEmailEvent.json
-rw-r--r-- 1 edbro 197121 2.1K Jan 13 18:48 UserAuthenticationFailure.json
-rw-r--r-- 1 edbro 197121 141K Jan 13 18:48 UserAuthenticationSuccess.json
-rw-r--r-- 1 edbro 197121 329K Jan 13 18:48 ViewLoadSequence.json
-rw-r--r-- 1 edbro 197121 214K Jan 13 18:48 VoiceAdLog.json
-rw-r--r-- 1 edbro 197121 8.4K Jan 13 18:48 WindowSize.json

Due to the sheer amount of data, my analysis of the second level will not describe it in the same depth as the first level. However, I wish to provide some of the highlights from my analysis.

Device Information

Multiple of the files contain detailed information about the devices used to listen to Spotify. One of the most detailed ones are AndroidDeviceReport.json and DesktopUpdateResponse.json. The first of these, AndroidDeviceReport.json contains detailed information about any android device. As shown below it contains both hardware and software versions used by the device.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22

{
    "timestamp_utc": "2020-10-29T06:08:27.652Z",
    "context_application_version": "8.5.XX.XXX",
    "context_conn_country": "SE",
    "context_device_manufacturer": "OnePlus",
    "context_device_model": "ONEPLUS A5010",
    "context_os_name": "android",
    "context_os_version": "9",
    "context_receiver_service_timestamp": 1603951738251,
    "context_time": 1603951707652,
    "message_cpu_family": 4,
    "message_cpu_features": 127,
    "message_fb_yearclass": 2016,
    "message_firmware": "ONEPLUS A5010_43_XXXXX",
    "message_manufacturer": "OnePlus",
    "message_max_freq": 2457600,
    "message_memory": 5991428096,
    "message_num_processors": 8,
    "message_screen_height": 2160,
    "message_screen_size": 6.021566867828369,
    "message_screen_width": 1080
  }

Note: I have anonymized some of the information with XXX.

DesktopUpdateResponse.json contains similar information about windows devices. Not as detailed, but almost. It contains information such as OS version, and if it can find it the device make and model.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16

{
    "message_is_employee": "\u0000",
    "timestamp_utc": "2020-11-30T13:45:32.882Z",
    "context_application_version": "1.1.46.916",
    "context_conn_country": "SE",
    "context_device_manufacturer": null,
    "context_device_model": null,
    "context_os_name": "windows",
    "context_os_version": "10.0.18363",
    "context_receiver_service_timestamp": 1606743933381,
    "context_time": 1606743932882,
    "message_error_message": null,
    "message_payload_size": 3,
    "message_request_time_ms": 349,
    "message_status_code": 200
  },

The windows data is quite limited in time, and does only seem to be saved for logging and deleted after about 1 - 2 months. The android data on the other hand is saved much longer, my estimate would be about half a year. From a personal perspective I wish that this would have been a bit shorter, but it is not long enough for me to raise any concerns.

Usage Information

As expected the level 2 data contains much more detailed information about any action taken in the software. For example if we look at Ap_EndSong.json it contains information about whenever a song is stopped.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16

{
    "identData_ip_addr": "XXX.XXX.XXX.x",
    "identData_username": null,
    "message_referer": "home",
    "timestamp_utc": "2020-08-16T13:49:51Z",
    "message_incognito_mode": false,
    "message_ms_played": 110066,
    "message_offline": false,
    "message_offline_timestamp": 1597585679267,
    "message_reason_end": "trackdone",
    "message_reason_start": "trackdone",
    "message_shuffle": true,
    "message_source_end": "playlist",
    "message_source_start": "playlist",
    "message_transition": "crossfade"
  },

This contains two timestamps, both one of the server, and one of the local playback device. It tracks how it was played, and why it was ended. Lastly it contains the class C IP address from where the song was played. Note however that I have anonymized the three first octets of the address. The last was not provided by Spotify.

ApAuthenticationSuccess.json

Lets look at a file that warrents a section on its own. ApAuthenticationSuccess.json contains the unique device ID of any device used to sign in. For windows this is a SID, generated when windows was installed. In addition it contains the full IP address, not the masked as used in other files.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

{
    "message_brand": "",
    "message_device_id": "S-1-5-21-3176720717-XXXXXXXXXX-XXXXXXXXXX",
    "message_ip_address": "XXX.XXX.XXX.XXX",
    "timestamp_utc": "2020-12-14T12:31:46.001Z",
    "context_time": 1607949106001,
    "message_client_id": "65b708073fc0480ea92a077233ca87bd",
    "message_language": "en",
    "message_platform": "win32-x86",
    "message_platform_version": "11470XXXX",
    "message_system_info": "Windows 10 (10.0.XXXXX; x64)"
  },
  {
    "message_brand": "",
    "message_device_id": "a404dc240fc3c868",
    "message_ip_address": "XXX.XXX.XXX.XXX",
    "timestamp_utc": "2020-10-21T07:45:31.889Z",
    "context_time": 1603266331889,
    "message_client_id": "9a8d2f0ce77a4e248bb71fefcb557637",
    "message_language": "en_GB",
    "message_platform": "android-arm",
    "message_platform_version": "85800XXXX",
    "message_system_info": "Android OS 9 API XX (OnePlus, ONEPLUS A5010)"
  },

Once more I’ve anonymized the data with XXX. Wherever there is an X in this data I have deleted the information about me and my devices.

The data in this file dates back approximately 3 months from the date when it was extracted. From this I am curious what they use the device ID for. If they need to link a device to an action they could generate a device ID, but to use the one generated by the system will allow them not only to track the movement of the device I use, but also to connect it to any other user that shares that device.

Conclusion

The information I’ve found in my level 1 data export give me a good feeling about what Spotify saves about me. Even though some concerns was raised after the examination of the level 2 data it is over all quite good. When receiving the data, the sheer amount of it was quite daunting, but after analysing it, there was not as many worries as expected.

I do not agree with the extent to which they collect data about my devices, but that is one of very few concerns. After looking through the data, my conclusion is that for the service they provide, the data they collect is acceptable. As always, there are things I wish was better, but the concerns are not critical.

This line of thinking arose once more after reading the “Report on the 2020 FOSS Contributor Survey” [1]. The report highlights that developers of FOSS (Free Open Source Software) have the same view, that security is a hindrance, a necessary evil that has to be done. Something to not spend more time on than absolutely necessary since its just annoying and boring, something that we must strive to change.

Sure there are some times that we have to say no, but developers (and others) does often understand this if we just explain why. It is important to not be the nay-sayers in the corner, but rather get involved. In my eyes security must support the business and the rest of the organisation. Everyone has to be on the same team and work towards a common goal, whether that is a high quality software or good backups in case of ransomware.

To be able to co-operate we need to build trust and ensure good communication. I have not meet a single developer that have introduced a vulnerability with malicious intent, meaning that the best way to get him to want to work with security is to make it easy. Explain your recommendations for a reasonable level of security. No-one can protect against everything, but you must find what level of risk is acceptable in the current scenario. Are you protecting against a national state or against the everyday hackers? The effort needed is greatly different.

In conclusion, security professionals cannot be a breed for them self in a corner. They need to be visible in the organisation, promoting communication and helping the organisation take decisions that improves the security. It doesn’t matter whether the decision is made by the CEO or a junior developer, they are both as important for the overall security posture of the organisation.

References

1. https://www.linuxfoundation.org/blog/2020/12/download-the-report-on-the-2020-foss-contributor-survey/

NO, CIA in this case does not stand for Central Intelligence Agency. In this case CIA stands for the three kinds of impact a vulnerability can have, Confidentiality, Integrity and Availability.

Lets dig a bit deeper, what does each of these terms mean.

Confidentiality

Confidentiality is about not exposing internal information to external parties. This could be anything from trade secrets to personal information. This is the area of security that I currently see discussed in the news. A recent example would be the Gunnebo hack [1], where the attackers stole confidential information and leaked it online.

Integrity

Integrity is in regard to ensuring that data in the system have not been changed. The banking sector excels in this area. Since they handle money and transactions, they have to be certain that no one can add a zero to the content of their bank account.

Availability

The last part of the triad is availability. Here the goal is ensuring the uptime of the system, that an attacker cannot take it down or block it in an unusable state. An availability attack is often (incorrectly) called a DDoS, or Distributed Denial of Service. This is one of the most trivial way of impacting the availability, but not the only. It is achieved by overloading the system with requests.

Media and CIA

In the years I’ve been following cybersecurity closely in media I’ve found that often the focus is on one part of the CIA triad at a time. In the last 5 years there have been a transition from availability to confidentiality. First the discussion was on cryptolockers (malware that encrypts the hard drive and requires a ransom for decryption). Since then the GDPR (General Data Protection Regulation [2]) among others, the discussion have transitioned towards the privacy of users. This highlights the importance of confidentiality of personal data.

This is where we are today, over the last few months there have been multiple instances where media have interviewed security professionals on information disclosed after a hack.

Conclusion

Regardless of what is discussed in media at the moment, all the parts of the CIA triad is important. Even though a businesses might have a prioritised area, they cannot forget the other parts. Any of them can and will have some kind of business impact, costing the organisation in the long run.

References

1. https://www.euronews.com/2020/10/27/thousands-of-sensitive-documents-stolen-in-swedish-data-hack
2. https://en.wikipedia.org/wiki/General_Data_Protection_Regulation

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.

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:

1. Abusing unintended behaviour
2. Abusing intended behaviour
3. 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.

1. Sending the password to the email is a low risk vulnerability, since email is an unsafe way to send information [1]
2. 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

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

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]:

1. 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.
2. 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.
3. 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.
4. 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.
5. 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.
6. 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.

1. https://www.zuckedbook.com/
2. https://www.humanetech.com/technologists
3. https://en.wikipedia.org/wiki/Prisoner%27s_dilemma

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.

1. https://martinfowler.com/bliki/TechnicalDebtQuadrant.html
2. https://martinfowler.com/bliki/TechnicalDebt.html
3. https://thenewstack.io/to-reduce-tech-debt-eliminate-dependencies-and-refactoring/

The thing about the internet today is that everything is links, and many sites such as twitter and bit.ly use link shortening to track usage and hide the original address. This makes it hard to know beforehand if the link is legit, and thus might increase the risk, but the impact will be the same. Here are four risks that I see when clicking a link.

1. The most obvious risk is phishing. An attacker can create a serious looking website with the aim to trick a victim to enter sensitive information such as passwords or credit card information. This would allow the attacker to use the stolen information to either sign into the compromised account, or pay with the credit card. However, these attacks are not performed when you click the link, but rather when you enter the information on the site, meaning that this does not qualify as a risk of clicking a link.
2. There are a few different attacks, for example clickjacking or cross-site request forgery, that targets a website through a victim browsing a third-party website. These attacks allow the culprit to perform actions as a victim on the target site. Instead of infecting the computer of the victim these attacks exploit a vulnerability in the target site to perform actions as the victim.
3. A reflected Cross-Site Scripting attack, also known as an XSS would exploit a vulnerability in a website to perform actions against that website as a victim. The impact is about the same as explained in 2, but the difference is that a legitimate URL to the target site is sent to the victim. To detect this risk, look for html tags such as <script> in the URL. Like the previous attacks, these attacks cannot infect the computer of the victim, but instead performs actions on the target site.
4. The most serious risk discussed is vulnerabilities found in the victim’s web browser. These can allow an attacker to compromise the computer to install malicious software such as spy- or ransomware. The best way to protect oneself from vulnerabilities in the browser is to keep it up to date. Most modern browsers are good at fixing bugs as fast as they become known. There is still a small risk that an unknown (aka 0-day) bug is used. However, these bugs are often used in attacks against high profile targets by well-funded hackers.

In conclusion, there are still risks with clicking links, but they are not as severe for your computer as they once were. I would say that today it is more important to ensure that your software is updated, that you do not enter information to sites you do not trust, and that you use long and unique passwords for accounts. Lastly, if you notice any strange behaviour on an account on a website you use, change your password and notify the owner of the site.