Risk

Lately, I’ve been thinking about the complexity of securing the software supply chain. If there’s one lesson we’ve learned from incidents like the SolarWinds and Kaseya attacks, it’s that our supply chains are increasingly becoming the weakest link in our cybersecurity defenses. What makes it even more challenging is the regulatory landscape—particularly within the European Union (EU)—which is evolving to place more responsibility on organizations to secure their supply chains. ...

While looking into IT Service Change Management, and primarily in accordance with ITIL, there was one thing that stood out. There seems to be a disconnect between the the development point of view and how change management is implemented by operations. With that I mean that the implementations I have seems to be more applicable for finished product than with software developed in house. The change management processes works when a change is either adding a new product or installing a new version. When it comes to full software development, the change management process gets fuzzy and drawn out. This gets even more distinct when looking at the more agile or DevOps ways of working of development. ...

In the world of cybersecurity there is a lot of specific definitions, a type of insider lingo that we assume that everyone agrees on the definition of. However, herein lies the problem. We assume, without discussing. I have ended up in multiple discussions that occurs due to different interpretations of a definition. In this post I’ll give my view of one of the biggest differences of definition that I have seen, namely what we include in the term cybersecurity. ...

After the devastating vulnerability in Log4j last month we’ve seen some changes in how companies view open source. The ones whom previously had no policies at all have now began looking into this. For now the main thing we see is asking the question about where Log4j has been used, but that will likely change to. It is important for all the users of open source to understand the nature. You cannot just expect or pressure the maintainers to update their software. Especially not if you use something with a small group of maintainers or being maintained in the spare time. Instead you have to get into the open source mindset and take advantage of the fact that everything is open. This means that anyone can read the code, and if needed create a fix. If a company decides to use free open source software they cannot expect the same level of service as if they bought a commercial product, but instead be ready to either wait or do the work themselves. ...

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