Securityblog

I listen to a lot of podcasts. A lot of podcasts. I was listening to the Dave and Gunnar Show podcast episode 212 with guest David A. Wheeler. The Titanic was used as an example of changing process after a security incident. This opened up a flood of thoughts to me, but not for the reasons intended in the conversation. The point of the suggestion was the Titanic sinking created changes to international requirements to help avoid a similar disaster next time, and we should be viewing SolarWinds in a similar way. The idea being we should use the SolarWinds event to drive meaningful change to make security better. Why no change will come of this is a different conversation: TL;DR it’s because nobody important died from SolarWinds, the Titanic killed a lot of important people. But I think this is an interesting way to talk about how we tend to deal with problems in software and how we deal with them in real life. ...

I’ve been thinking about what open source is a lot lately. I mean A LOT, probably more than is healthy. There have been a ton of open source happenings in the world and the discussions around open source licenses have been numerous. There are even a lot of discussions around the very idea of open source itself. What we once thought was simple and clear is not simple or clear it would seem. ...

What a year it’s been! I feel like 2021 went by like a … it’s still January??? So it’s pretty much impossible to ignore any of the events of the last month. I want to talk about something that’s near and dear to my heart, and in the news, not for a good reason. Software supply chains. This is probably a dreadful topic to most, but I love software supply chains. I was talking about them before anyone was even thinking about them. I’m not going to pull a “get off my lawn” here, I think it’s cool everyone is starting to care. I want to talk about how to be realistic about your supply chain. Almost all advice I’ve seen of the last month has been terrible, so I’m going to also give some terrible advice. ...

I wrote a blog post about looking back, and I have a bit of snark in there where I talk about slowing down the future. I wanted to explain this a bit more and give everyone some food for thought around how we used to do things and how we should do them moving forward. There are groups and people that exist to slow things down. Sometimes that’s on purpose for good reasons, sometimes it’s on purpose for bad reasons, sometimes it’s not on purpose at all. ...

For the last few weeks Kurt and I have been having a lively conversation about security ratings scales. Is CVSS good enough? What about the Microsoft scale? Are there other scales we should be looking at? What’s good, what’s missing, what should we be talking about. There’s been a lot of back and forth and different ideas, over the course of our discussions I’ve come to realize an important aspect of security which is we don’t look forward very often. What I mean by this is there is a very strong force in the world of security to use prior art to drive our future decisions. Except all of that prior art is comically out of date in the world of today. ...

This tweet from Jim Manico really has me thinking about why we like to consider security bugs special. There are a lot of tools on the market today to scan your github repos, containers, operating systems, web pages … pick something, for security vulnerabilities. I’ve written a very very long series about these scanners and why they’re generally terrible today but will get better, but only if we demand it. I’m now wondering why we want to consider security special. Why do we have an entire industry focused just on security bugs? ...

Every company tells you they take security seriously. Some even take it very seriously. But do they? I started to think about this because of a recent Slack bug. I think there are a lot of interesting things we can look at to decide if a company is taking security seriously or if the company thinks security is just a PR problem. I’m going to call the behavior we want to look at “security signals”. ...

A few days ago I ran across this report from MITRE. It’s titled “2020 CWE Top 25 Most Dangerous Software Weaknesses”. I found the report lacking the sort of details I was hoping for, so I’m going rogue and adding those details myself because it’s a topic I care about and I like seeing conclusions. Think of this as a sort of modern graffiti. Firstly, all of my data and graphs come from the NVD CVE json data. You can find my project to put this data into Elasticsearch then doing interesting things with it on GitHub here. All graphs are screenshots from Kibana. ...

I’ve been thinking about this one for a while. I’ve seen some CISOs who are amazing at what they do, and I’ve seen plenty that can’t get anything done. After working with one that I think is particularly good lately, I’ve made some observations that has changed my mind about the modern day CISO reporting structure. The TL;DR of this post is if you have a CISO that claims they can only get their job done if they report to the board or CEO, you have an ineffective CISO. ...

This blog post originally started out as a way to point out why the NVD CVSS scores are usually wrong. One of the amazing things about having easy access to data is you can ask a lot of questions, questions you didn’t even know you had, and find answers right away. If you haven’t read it yet, I wrote a very long series on security scanners. One of my struggles I have is there are often many “critical” findings in those scan reports that aren’t actually critical. I wanted to write something that explained why that was, but because my data took me somewhere else, this is the post you get. I knew CVSSv3 wasn’t perfect (even the CVSS folks know this), but I found some really interesting patterns in the data. The TL;DR of this post is: It may be time to start talking about CVSSv4. ...