Security

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

Previously I’ve written a post about security for development teams, and now it’s time for the continuation. Just as for developer there are great benefits in performing security tests for administrators. However, the methodology when testing the infrastructure is not the same as when testing an application. 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. ...

There are very few, if any, development teams that introduces vulnerabilities into their software out of malicious intent. Instead it is mistakes that are introduced due to lack of time, awareness, or something alike. There are lots of materials out there that are either super detailed for a specific technology stack, or on such a high level it is hard to apply in the real world. 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. ...

I’ve gotten a bit curious about what data different companies are collecting about me. This have led to a couple of GDPR requests to companies to provide the data so I can analyse it. In this post I will share my thoughts about the content of the report I got from Spotify, and the process of fetching the data. 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. ...

A couple of weeks back I had a very interesting meeting at work. After meeting a new development team and discussing security (testing), they commented on how great it was to work with a driven and interested security engineer instead of a nay-sayer. This got me thinking about the overall view of security professionals from others, and realised that we are often seen as a hindrance. 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. ...