So one of the really cool things about working at Red Hat is we get to actually talk about what we do. Openness is a really important ideal the company has. I'm currently working to create a security development program inside Red Hat, which is also going to have to be open source friendly. As this is interesting, hard, fun, hard, and useful, I'm going to do my best to keep the world filled in on how things are going. If someone else can benefit from my mistakes, I shall be very happy.

So after all the various things I've read regarding things like Microsoft's Security Development Lifecycle, BSIMM, CERT documentation, it's very clear that there is a lot of information regarding what a secure development program should look like. There is almost no information about actually starting one.

The Roadmap
A big challenge with starting a secure development program is that you can't just show up and start telling people how to do their jobs. You'll probably last two days before someone beats you up in the parking garage. This is especially true when you take open source into consideration. If I tried to tell the folks at Apache how to develop, I'd likely be laughed out of the room (or mailing list in this instance). A program like this needs careful planning. You'll get one chance to make it work, if you blow it, nobody will ever listen to you again.

This is where a sound roadmap comes into play. While the overall look of my roadmap continues to change as I talk to people, the first step has to be training. If we don't train the involved parties, nobody will understand what's going on or why certain practices should be adopted. This includes training from the point of basic security, all the way to training on various security concepts such as secure design, development, training, and response.

Phase 1: Training
Security is hard, if nobody knows what you're talking about, you will fail. It's also dangerous to assume everyone understands security basics. Security is one of those areas where the more you learn the less you know. It's also changing constantly. What was sound security advice a few years ago may not be anymore. Various security technologies continue to evolve, and new ones are developed. New exploitation techniques are constantly changing. It's very hard to keep tabs on everything.

Our current initial focus on training is going to focus on these topics:

Security basics. This includes information on the security development lifecycle as a whole, and understanding what a security flaw is, why it's a problem, and some history. If we don't know where we've been, it's hard to see where we're going.

Secure design. If you don't have a secure design before you start to write the code, it may become impossible to fix some problems without a significant amount of work. Secure design from the start will include topics like threat modeling, defense in depth, secure defaults, and principal of least privilege.

Secure development. This topic is very broad and has the potential to get overly technical. A huge challenge here is how much information is enough? It's not going to be productive if you end up creating developers who are so worried about security issues that their productivity drops to zero.

Secure testing. An important part security development is to test what you create. There is never going to software that is totally free of security flaws. By doing certain testing though you can catch some things before it leaves the door. This is where using things like dynamic and static testing is helpful. Agan though, there has to be certain sensible limits. At some point the law of diminishing returns kicks in. We need to figure out where that is.

There are of course other areas for training, but the above are some of my initial goals. I also hope to make some portion of this training material available to the open source community. I'm not entirely sure how all that will happen long term, but it's something on the list.

As my plans continue to grow and evolve, I'll be certain to fill in more details.
Until next time.

So the year 2012 is finally here, the world is supposed to end this year (someday one of these predictions will be right). With every new year there are always a bunch of new exciting predictions about computer security. Most are wrong. If we knew what was going to happen, we'd stop it from happening, hopefully.

Rather than make a pointless prediction for 2012, I have a few goals for the year. As I announced previously, I'm working on a security effort inside Red Hat to bring proactive security measures to our products. The Red Hat Product Security Team if you will. Some of my current goals for the year (which are subject to change) stand as:

Security training materials
The team is working on various security training materials. Topics ranging from secure design, development, and testing. Some of this will stay internal to Red Hat, but I hope to make much of it public for the general open source community to leverage. I've done a fair amount of research on this topic. There is a lot of really quality material out there, but finding it can be difficult.

Security development principals for open source
There are numerous security development lifecycle programs out there, but none are geared for the unique challenges open source faces. I've yet to find a project that doesn't want to write secure code, or handle security flaws properly. I have found many that don't really know where to start though. While I've done a lot of investigating about existing security development programs, most lack the very crucial step of where and how to start. Stay tuned for updates in this area.

Investigate various security tools
There are a lot of interesting security tools out there. Things from static analysis, dynamic analysis, fuzzing, and testing. Some work well, some don't, some are hard to use. One of my goals is to sort this out, and make the findings available to anyone who is interested.

Work with open source projects
One of my biggest gripes about security efforts is they often work like this: "here's some information, good luck". Rather than just dump things like training materials and principals to the world, we need to work with projects who have an interest in this. One of the really hard, and really interesting aspects of open source is that every project is very different, and many use a lot of volunteers who aren't going to be receptive to the idea of a bunch of new process. I can't say I know how this one is going to end, but I have plenty of ideas where it can start.

In general I see 2012 as being very busy and exciting, which isn't a bad problem to have at all.

If you have any questions, or want to have a chat about any of this, feel free to mail me, bressers@redhat.com.

There is a really cool utility from the selinux folks called sandbox. It's lets you run an application inside a sandbox which has limited permissions on the system. The idea being that you could run an untrusted process which shouldn't be able to cause any real damage. I dare say these days the most untrusted process is a web browser. I know Chrome uses a technology similar to this where each tab gets its own sandbox, but I don't run Chrome, so my goal is to make Firefox as safe as possible. Plus I'm a paranoid nut, so this sort of thing I find really interesting.

The sanbox program is part of the policycoreutils-python package in Fedora. It has the unique feature of being able to run an X application inside the sandbox. This is done by using a Xephyr X server. Getting this to run Firefox the way I wanted took a bit of work, but it's quite handy now that I have it working.

The biggest advantage I now have are multiple browsers running as my user. I have one browser for general browsing. This browser I never enter a password into, as I presume some of the sites I visit could be malicious in nature.

My other browser is for trusted sites, like webmail and my bank. I'm able to run any number of browsers I wish, since each runs in its own sandbox, I don't have to worry about any resource collisions. If I have a questionable site to investigate (which happens in the security world fairly often), I just run another browser, check the site then close it. The sandbox cleans up any mess left behind when I'm done.

More after the fold.


Continue reading "Firefox in a sandbox with Fedora"

News is starting to make the rounds that Sony's PSN users had their personal info stolen nine days ago.
Sony: Your PSN Personal Info Was Stolen Nine Days Ago

Most people are now thinking NINE @#$%ING DAYS!!!

The wording Sony is using is fairly vague, nothing sounds concrete. This is most likely because they don't know for sure. I suspect it took them nine days to release this news because they spent the first five days running around in an utter panic waiving their hands in the air.

I'm not going to pick on Sony for being broken into, this happens. Even the best networks in the world have flaws. Nothing is perfect. Given how long it's taken them to respond, they probably didn't have a proper incident handling plan. It's easy to see security as a useless cost until you need it, then it looks pretty cheap.

Someday, you too will be compromised. What will you do when it happens?

There has been a lot of noise lately about Apple and Google phones tracking people. This isn't very surprising honestly. Everything tracks what you do these days. Your web browser tracks the sites you visit. I would be amazed if more than half of your travel time isn't recorded on some sort of video security system (think about how many public and private video cameras you see, if you can see it, it can see you). Even when you spend money, it's being tracked. There are debates as to how anonymous cash is, for now, let's just presume it's not anonymous. Even the books you read are easier than ever to track thanks to ereaders (sure they know you bought The Catcher in the Rye, but now they know you read it once a month).

We live in a world where we have no privacy. This probably won't ever change since companies want to know this information. I'd be surprised if any single group has managed to put it all together yet, but there is a giant pile of gold waiting for whoever does (my current money is on Facebook, as long as someone doesn't swoop in and get it right before they're done floundering).

The real question is what can we do about it? There are really only three options. Go live in a shack in the woods and never ever spend money or use technology. Stop caring. Don't do silly things.

The vast majority of people live in the "Stop caring" option since they don't know any better. Living in the woods is probably out of the question fo most of us as something will eat us on day 3 if we haven't starved to death. The right answer is to not be silly.

Continue reading "If a phone tracks you in the forest, does it makes a noise?"

I've finally gotten around to setting up a new GPG key for myself. It can be found on the keyservers, signed with my old key for those of you interested. The fingerprint is

CFB1 136C 6DD0 5BB9 D798 A78E 1CD8 ACDD BBE0 9A0F

The really cool thing about this key is I have it living on an OpenPGP smartcard. Such a card can be found from kernel concepts. This means that it's quite difficult for someone to steal this key from me. It will take a physical theft for someone to gain the key. The best a remote attacker can do is decrypt or sign a things as me while I have the card plugged into my computer.

As a warning, I wasn't able to generate my keys using the Omnikey or Gemalto USB keyreaders I have. I bought SIM sized smart cards so I can easily carry both the card and reader with me at all times. It turned out that GPG could generate the keys on Windows, so I ended up having to to do a clean windows install to generate the keys (which was promptly destroyed afterwards), it was a rather silly waste of time, but it did work.

Last week there was an Exim 0day flaw found in the wild. This hasn't happened to something this widely used in quite a long time. It's worth pointing out that all the right folks came together to get this fixed in an amazing amount of time. They did a great job and deserve a lot of credit. This could have been a lot worse than it was.

Upstream sent this message giving a pretty good run down of events.

Their openness is certainly the best way to have handled this. If you treat security like a PR problem, it becomes a PR problem.

The short story is that on December 7, a vigilant sysadmin (Sergey Kononenko) noticed a compromised server, and luckily grabbed a dump of the data. It wasn't widely noticed for about two days. During this time investigation began. Here is where open source showed its real power. When the folks investigating were having issues, they started asking other community folks to help, this eventually made its way to various vendors. Everyone brought a different piece to the puzzle, and the next day the problem was understood, and vendors started to patch their copies of Exim. It turned out upstream had fixed the issue quite some time ago.

It's not uncommon for emergencies to go horribly wrong, but when the right people do the right things, things can work nicely.