Josh's Blog - Red Hat

Security Development and Open Source

nospam@example.com (Josh Bressers) — Mon, 09 Jan 2012 07:30:00 -0500

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.

What will 2012 bring for security?

nospam@example.com (Josh Bressers) — Tue, 03 Jan 2012 08:00:00 -0500

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.

Expanding Red Hat's Product Security Efforts

nospam@example.com (Josh Bressers) — Mon, 21 Nov 2011 07:17:00 -0500

I'm rather excited to announce an expansion of Red Hat's product security efforts. I've been tasked with creating a team inside Red Hat to formalize our product security work. There is already a lot of really good work happening inside Red Hat in the security space. Technologies such as SELinux, ExecShield, secure development principals, and hardening in the toolchain have come a long way. However as happens with all decent sized companies, the left hand doesn't always know what the right hand is doing. Rather than letting good work go unnoticed, we're going to start formalizing some of these efforts to leverage what's being done, expand existing efforts into other product areas, and develop new programs.

Some additional efforts I would like to further are areas such as secure design principals, developer security training initiatives, secure coding practices, and security testing.

If you're interested in being a part of this effort, I have a number of open positions scattered around the world, feel free to apply directly or contact me if you have any questions. I'm quite happy to discuss location, so don't let that scare you off.

Please note these positions are no longer open. If you want to view open positions, please visit
http://careers.redhat.com

Software Engineer - Security Best Practices Development
Software Engineer - Tool Development
Software Engineer - New Security Technologies Development
Software Engineer - Code Audit Development
Developer Training

I don't expect any of this to be easy, but nothing worth doing is ever easy. I expect many challenges and rewards to come from this. Red Hat is in a unique and great position to take on such a task. Stay tuned for more updates.

Red Hat Summit 2010 - Day 2

nospam@example.com (Josh Bressers) — Wed, 23 Jun 2010 22:25:00 -0400

The breakfast was quite welcome this morning. I needed a cup of coffee, I woke up rather tired. I never sleep well when I'm away from home.

The morning keynotes were great. I love hearing our message, Jim pointed out that most companies sell features, we sell a subscription. This makes me ponder the normal computer product cycle, which falls in line with The Innovator's Dilemma. You have companies that are really only adding new features, and not usually removing old features, as they're selling a box. Disruptive technology bubbles up from the bottom that's not encumbered by 20 years of "needed" features. With open source, I wonder how or if there is a disruptive force that can come in behind it, that isn't just a new open source project.

I also had the joy of working in the Red Hat booth this afternoon. It's always fun to talk to new people and learn about new things. People also seem to really like the Red Hat buttons we're handing out (or I'm just a really good button hander outer). It's almost frightening how many people I now remember the names of. I'm generally really bad at remembering names. Perhaps drinking the city water unfiltered has granted me some sort of super powers.

The evening event was pretty good. We had happy hour in the partner pavilion. I got a way cool USB hub from Enterprise DB. It looks like a children's toy. I love it. Now I just need to keep it away from the kids. The party upstairs was great. The food was good as was the company. I has some grilled swordfish. I won't complain about that. So far this is a pretty good Summit.

I give my talk tomorrow. Luckily I'm not staying up too late this evening, which should work out well as I speak at 10:20am.

Red Hat Summit 2010 - Day 1

nospam@example.com (Josh Bressers) — Tue, 22 Jun 2010 21:57:02 -0400

So the first day of the Red Hat Summit is done. It's been a great day. I got to Boston around noon. I ate lunch at the Barking Crab, which turned out to be a great choice. The oyster Po' Boy sandwich was awesome. I spent a few hours wandering around Boston. I love tourist traps, they're so much fun.

The Summit itself always starts out with a reception. You get to walk around, see the booths and talk to various folks. It's always nice to see people I've not seen for a while (usually about once a year at the summit). The turnout seems good. There are a ton of people here.

The talks start tomorrow, there will be plenty more to say then.

Red Hat Summit

nospam@example.com (Josh Bressers) — Fri, 04 Sep 2009 22:19:00 -0400

So I'm back from the Red Hat Summit now. It was a good show. It's always nice to get some face time with customer folks and co-workers.

My talk went quite well, all things considered. The room while small, was full, which is always nice. My voice was a bit rough. The party the night before I spoke was very loud, which meant in order to talk, you had to yell. This left me with a rather weak voice. Good thing I had a microphone.

The most unexpected outcome from my talk I think was listening to customers talk about how annoying all the false positives they get from various security scanners. This is due to us backporting fixes. I plan to investigate this more in the near future, stay tuned.

Dan Walsh showed off some spiffy stuff. I expect he'll have some blog posts soon about his sandbox project.

There was a party at the Museum of Science and Industry on Thursday night. That place is always a pleasure to visit.

Twittering the summit

nospam@example.com (Josh Bressers) — Mon, 31 Aug 2009 21:39:00 -0400

So while I like to waive around my geezer cane, I think it's time to use twitter for the upcoming Red Hat Summit. While I could just write a blog entry every hour, that is annoying to write, and annoying to read. Twitter offers me a special sort of stream-of-conscience-nonsense.

So feel free to play along at home
http://twitter.com/joshbressers

Off to the Red Hat Summit

nospam@example.com (Josh Bressers) — Mon, 31 Aug 2009 11:04:00 -0400

So I'm heading in the general direction of Chicago in a few hours, as the Red Hat Summit starts tomorrow. I'm giving a talk about Red Hat Security Advisories on Thursday at 11:20. As it's right before lunch, I expect most to be daydreaming about tasty treats.

I do always enjoy the summit, it's nice to get some face time with various co-workers, and speak with customers about our security updates. I'm always happy to hear from folks what we're doing well and what we could stand to improve.

If you're going to be at the summit, feel free to find me and pester me about anything security related. I look forward to it.