There’s a news story going around that talks about how horrible computer security tends to be in hospitals. This probably doesn’t surprise anyone who works in the security industry, security is often something that gets in the way, it’s not something that helps get work done. There are two really important lessons we should take away from this. The first is that a doctor or nurse isn’t a security expert, doesn’t want to be a security expert, and shouldn’t be a security expert. Their job is helping sick people. We want them helping sick people, especially if we’re the people who are sick. The second is that when security gets in the way, security loses. Security should lose when it gets in the way, we’ve been winning far too often and it’s critically damaged the industry. ...

The Red Hat Summit is happening this week in San Francisco. It’s a big deal if you’re part of the Red Hat universe, which I am. I’m giving the Red Hat security roadmap talk this year. The topic has me thinking about the future of security quite a lot. It’s easy to think about this in the context of an organization like Red Hat, we have a lot of resources, and there are a lot of really interesting things happening. Everything from container security, to operating system security, to middleware security. My talk will end up youtube at some point, I’ll link to it, but I also keep thinking about the bigger picture. Where will security be in the next 5, 10, 15 years? ...

If you’re a fan of the cryptocurrency projects, you’ve heard of something called Ethereum. It’s similar to bitcoin, but is a seperate coin. It’s been in the news lately due to an attack on the currency. Nobody is sure how this story will end at this point, there are a few possible options, none are good. This got me thinking about the future of security, there are some parallels when you compare traditional currency to crypto currency as well as where we see security heading (stick with me here). ...

Due to various conversations about security this week, Voltron came up in the context of security. This is sort of a strange topic, but it makes sense when we ponder modern day security. If you talk to anyone, there is generally one thing they push as a solution for a problem. This is no different for security technologies. There is always one thing that will fix your problems. In reality this is never the case. Good security is about putting a number of technologies together to create something bigger and better than any one thing can do by itself. ...

I recently finished reading the book Ghost Fleet, it’s not a bad read if you’re into what cyberwar could look like. It’s not great though, I won’t suggest it as the book of the summer. The biggest thing I keep thinking about is I’ve yet to really see any sort of book that takes place in the future, with a focus on technology, that isn’t a dystopian warning. Ghost Fleet is no different. ...

Every time I start a discussion about how we can solve some of our security problems it seems like the topics of professional organizations and regulation are where things end up. I think regulations and professional organizations can fix a lot of problems in an industry, I’m not sure they work for security. First let’s talk about why regulation usually works, then, why it won’t work for security. What is regulation? You may not know it, but you deal with regulated industries every day. The food we eat, the cars we drive, the buildings we use, the roads, our water, products we buy, phones, internet, banks; there are literally too many to list. The reasons for the regulation vary greatly, but at the end of the day it’s a nice way to use laws to protect society. It doesn’t always directly protect people, sometimes it protects the government, or maybe even a giant corporation, but the basic idea is because of the regulation society is a better place. There are plenty of corner cases but for now let’s just assume the goal is to make the world a better place. ...

Last week I spent time with a lot of normal people. Well, they were all computer folks, but not the sort one would find in a typical security circle. It really got me thinking about the bubble we live in as the security people. There are a lot of things we take for granted. I can reference Dunning Kruger and “turtles all the way down” and not have to explain myself. If I talk about a buffer overflow, or most any security term I never have to explain what’s going on. Even some of the more obscure technologies like container scanners and SCAP don’t need but a few words to explain what happens. It’s easy to talk to security people, at least it’s easy for security people to talk to other security people. ...

If you’re in the security industry these days things often don’t look very good. Everywhere you look it sometimes feels like everything is on fire. The joke is there are two types of companies, those that know they’ve been hacked and those that don’t. The world of devices looks even worse. They’re all running old software, most will never see updates, most of the people building the things don’t know or care about proper security, most people buying them don’t know this is a problem. ...

Almost every industry goes through a time when new novel features are sold as some sort of add on or extra product. Remember needing a TCP stack? What about having to buy a sound card for your computer, or a CD drive? (Does anyone even know what a CD is anymore?) Did you know that web browsers used to cost money? Times were crazy. Let’s think about security now. There is a lot of security that’s some sort of add on, or maybe a separate product. Some of this is because it’s a clever idea, some things exist because people are willing to pay for it even if it should be included. No matter what we’re talking about, there is always a march toward commoditization. This is how Linux took over the universe, the operating system is a commodity now, it’s all about how you put things together using things like containers and devops and cloud. ...

A long time ago Ken Thompson wrote something called Reflections on Trusting Trust. If you’ve never read this, go read it right now. It’s short and it’s something everyone needs to understand. The paper basically explains how Ken backdoored the compiler on a UNIX system in such a way it was extremely hard to get rid of the backdoors (yes, more than one). His conclusion was you can only trust code you wrote. Given the nature of the world today, that’s no longer an option. ...