Blackhat Thoughts

So it’s been a bit quiet as I have been traveling for Black Hat, then went home for the weekend for a Wood Badge staff development weekend and then right back to CA for 2 weeks for some work at HQ. I have some ideas I am working on and will get them out as I can. In the meantime here is a link to where both myself and my team have posted some thoughts on our experience at Black Hat & Defcon 2011.

My first official post on the Mozilla Security Blog!!

Read it here https://blog.mozilla.com/security/2011/07/29/494/.

Security & Feature Pages

Yesterday I talked about what we are doing in bugzilla so today I want to cover the new feature pages and how we are using the new status section to track security interaction there. If you have not seen the new feature pages that are based on media wiki, and they are super _cool_! You can check out dria’s (Deb Richardson) great work in any of our feature pages or at the demo page. This post is meant to help everyone understand what these new things mean and to engage us for the best interaction.

Background
So just like the instance with bugs we have to get a handle on what is going on in what we are doing, not doing or not doing well…we need data. I am going to avoid the historical path of how we got here for now, another post for another day maybe, as this would detract from what I want to focus on here right now. In the pre-new way we would edit a feature page add a name (usually mine) as a security resource and then add a section for security notes. This section would either have the notes from our meetings or a link to the review page. I would also track all this on a hand edited wiki page that first lived in my intranet profile and later moved to the public wiki and was simply known as the “radar”. The big problem is we had no way of knowing what features were coming, wich we had worked on or their status without this very manual page, and I spent a good deal of my time maintaining it as things changed as well as keeping the wiki notes and schedules running.

Where We Are

Now we have this great new wiki media form and the radar has searches (yeah! automation), so a few immediate advantages.

1. We can now search for items that we need to decide on.
2. We can track a workflow for what needs to happen.
3. We have some record of what we did and when
4. We can have a common framework and keywords that have meaning to more than our team.

With the new feature pages there is a great new section ‘Team Status Notes’ that we are going to use to accomplish just that.

The security line is actually made up of 3 elements, 2 you can see right off, the status line and notes; and a hidden element that is only visible when using the form edit ‘security health’ that gives us a color coding for visual indication. Lets start with status.

Status	What it means
` OR [blank]	Untriaged, the team has not looked at it and made an action decision to either do something or do nothing.
sec-review-needed	Item has been triaged and a security review is needed, this could be a design review with the whole team or just one of us is going to look into it. In his case an alias is in the notes section.
sec-review-sched	A review has been scheduled. In this case the date of the scheduled review shows in the notes and a meeting is on the Security Review Calendar.
sec-review-active	The review is ongoing, the team met with the feature owner and decided more work was needed (ie. fuzzing, threat model, implementation review, pen testing, etc.) The notes will reflect this and who is taking responsibility for it.
sec-review-complete	We’re done. The notes section will have a link to the relevant security notes for all that was done. (ex. https://wiki.mozilla.org/Security/Reviews/Firefox6/ReviewNotes/webconsole)
pass	During triage the team decided to not interact with this feature and no security work was done or is scheduled to be done.

The other area that helps convey meaning beyond the notes is the health indicator that has the following set.

Health Indicator	Color	What it means
none/blank
OK		Things are on track, nothing is blocking no concerns at the time.
Blocked		Security is concerned enough about something to block the feature from landing or moving into the next train phase until something is fixed or resolved.
At Risk		Things are not progressing such that the feature will not likely make its designated ship window. This could be for a variety of reasons.
Assigned		Security work is continuing and has been assigned to someone to follow-up and report back on.

This should give anyone who wants to know what is going on with security on any given feature a decent clue. Questions, concerns or smart remarks can be made to me on irc or email.

-curtisk

Security Keywords in Bugzilla

There has been a little confusion over the addition of sec-review-needed and sec-review-complete keywords that were  added to bugzilla.mozilla.org in June that I hope I can clear up with this blog post. I have spoke about these a little on the dev.planning list, in the Tuesday engineering meeting and at the weekly all hands on July 11 (has slides). So I will use this to go into more detail as well as repeat a bit of what I have already presented.

What it is/not
This is a simply an indicator that someone feels the security team should be involved with an item. When I say security team I am talking about security on our development side (not our infrasec team). So if someone sets the keyword sec-review-needed we will triage the item and decide what kind of involvement we think is needed or any at all. This is not meant to block the landing, tracking, approval or any other normal work that would occur for a bug. Right now its just a way for us to get an idea of things we and others think we should be examining to improve security in our products. This is also primarily in Firefox, Thunderbird and their related projects. The idea is to start the scope small and get an idea of what this tells us. All these things could change or even be dropped if they are not useful.

Why
The shortest and best answer is we need data. It would be very useful to know patches or areas that have undergone security review of some kind; and those that have not. If an item later has a security incident we can check if a security was done and what we missed and why, or that a review simply wasn’t done. Taking action without data is just guessing, so we need some data to start with so we can analyze what it means and the impact of actions we take. We are doing much the same thing with features and the feature pages. As with anything we have limited resource and we want to deploy those resources with maximum affect. To do that we have to have data on what we are doing and the outcomes of those actions.

Going Forward
If for any reason you think a bug you own or even if you don’t own it could benefit by some involvement from the security team then set the keyword sec-review-needed, we will triage it; make a decision as to action, make notes in the bug, maybe have some meetings and work with the developers to find the best course of action. Again this is _not_ meant to halt work or a bug, we want to find a constructive path to completion. When we are done we will set the keyword sec-review-complete, from this we should be able to build some basic metrics around our activities and their effectiveness and then continue to drive changes to improve the process.

If you have questions find me on irc or drop me some mail.

curtisk

A new vision for Firefox!

So there has been quite a set of discussions on mailing lists regarding the vision statement for Firefox. Lots of the talk has been about the minutia of various parts of it. I had posted much of what is being said here to the mozilla.dev.planning thread/group; so if you read my comments there this is going to be redundant and I suggest you skip this post. I wanted to blog about it as I think some of what I am trying to focus on is getting buried among the rest of the discussion. Beyond that longer content I want to call attention to 2 items, one specific to the vision statement itself and one on the general idea of vision statements.

This sort of thing (leadership, etc.) is a passion of mine, I am part of a group that teaches advanced leadership skills to adult leaders for the BSA. These are not just outdoor camping kinds of things, we have other courses for that, these are skills leaders need to be successful not just in BSA but just about anywhere. One of the very first things we teach, and I had the honor of leading this part of the course last year, is what we call Values, Vision and Mission. Where we try to impart some wisdom in how you get groups to move towards a common goal given a common understanding. I want to focus on the vision part and I may blog on the other parts another time but for completeness here I am going to cover a small part of them to be clear.

As the name implies it starts with a shared set of values, which I think Mozilla has strongly in its DNA ^[1][2] if not always stated in the most clear fashion, but I am not going to spend time on that as I want to focus on this particular issue here. Stated simply, values are what we believe in and how we will behave and it is from them that we derive a vision.

For me a vision forms when we think far enough ahead to realize there will be important challenges that we can prepare for now, perhaps by doing something simple. And it has some distinct characteristics:
■ A vision engages the heart and spirit.
■ A vision leads toward a worthwhile goal.
■ A vision gives meaning to an effort.
■ A vision is simple.
■ A vision is attainable.
■ A vision can change over time.

Now that we we have a basis for a vision, lets take a look at the proposed Vision for Firefox, mind you this is for the product _not_ Mozilla as a whole. I see some of these things in the what has been proposed:

“Discover, experience and connect with apps, websites and people on your own terms, everywhere.”

This one-liner is the place I want to focus outside the wordiness of the rest of the document, this one statement is the heart of the matter. It’s this one statement that seeks to “rally the troops” to a common goal and build missions that ultimately make it a reality. Personally, I think it’s lacking enough of the criteria above that it needs some word-smithing, I would put it more like:

Firefox will be the premier platform for users to discover, experience, connect with and further the open web on every platform and on their terms.

This is much more clear and to the point, it states exactly what I think should be the focus of this vision, namely Firefox. It leads towards a goal, with some specificity that we want every platform; especially the mobile one that is where we see danger right not of fragmentation and loss of an open web. I think it gives meaning to our efforts for users, to place them firmly at the center of what we do, whether they be individuals, developers, corporate or whatever. I think this is attainable and is simple enough to be clear. It might change over time, only time will tell as that is the nature of time. As such I think this version meets the criteria and keeps the original intent.

The goal here is to get the fabulous team we have focuses on a common goal and the tasks needed to achieve it. Right now I think they are spinning wildly trying to interpret it and while discussion is good if we cant get on the same target we can’t achieve it.

As always these views are my own and not necessarily that of my employer, namely Mozilla.

iPhone Calendar Oddity

Lately I have been traveling back and forth between my home and my new job with Mozilla in Mountain View, CA. As part of this I synch multiple calendars with my iPhone to keep my work and personal life in order. The annoying thing is I found that all my appointments were staying in the Eastern time zone of my home. One of the many things that made me want to chuck my iPhone at the wall! After much fiddling I am happy to report I finally found the problem.

I found the offending item in Settings -> Mail, Contacts, Calendars -> Time Zone Support. I think I may have turned this on not understanding that this would lock my events to the time zone in question. So if you notice that your meetings are not moving times when you phone moves time zones you might have the same problem that drove me mad for 3 months.

Too Quiet

OK, yeah…I have not posted in some time. But I have a good excuse. I have left my old position at a crummy health care company and moved to Mozilla (yeah the guys that make Firefox and Thunderbird). I am the Sr. Security Program Manger (or my self given title of ‘Security Minion’), where I am tasked with bringing more structure and predictability to the process of security integration with development tasks and keeping drag to a minimum. As such I have spent the last 8 weeks getting myself used to the structure, pace and culture of Mozilla; and flying back and forth from my current home in KY to CA (moving in the not to distant future if all plans go as they should). So sorry for the long quiet I am going to do my best to blog here more often to engage the community of Mozilla developers and get feedback on how we are doing with our process and driving security for the community, product and world. -ck

AppSec – InfoSec the Pizza Boxes, et al.

This blog is inspired by an interesting discussion on twitter between Raf Los (Wh1t3Rabbit), Jeremiah Grossman (jeremiahg), Barry Dorrans (blowdart) Jack Daniel (jack_daniel), securityninja (no real name known David Rook) and me chiming in. The discussion started with a simple enough tweet from Raf “AppSec ’till now has been “myopic” in a word; suggestions for the future, and commentary (via FB) http://fb.me/Rm9oAITx”.  But it moved to some key points:

1. AppSec / Infosec has problems because too many want or sell InofoSec as a “pizza box” solution.
2. Business wants to view the problem in the way it has viewed all other problems, I buy something to fix it.
3. Regulations could be a possible solution to the issue.

To me #1 sounds pretty real, I get to see a lot of vendors in my job. Not just for AppSec but for all kinds of security stuff just due to the nature of my job. I can also tell you that nearly 90% of the presentations are “buy this and all problems are solved”. In my mind this thesis only holds true for very small, very well defined issues. The bottom line here is you can’t buy your way out of a security problem most of the time.

As well #2 sounds fairly right on as well, because most business leaders or owners don’t really understand how software is built, designed, whatever. They don’t know how to deal with its security issues. Not to mention they think of most security in terms of regulation they have to comply with not an integrated business process (where I argue it should be).

So that brings us to #3, why not just regulate the industry like everything else. Honestly this deserves a post of it’s own that I think I will go into another time.

I think these things are tied together and to solve the problem you have to address the “InfoSec Triangle”

Security is a three pronged problem in all instances: People, Process and Technology. You have to have the Technology to control or define the rules you want People to follow, there has to be a Process by which the technology is secured and People have to understand both how to use and why it’s important. If you miss either one of the last two you’ve spent a good deal of money on a shiny box with fancy flashing LEDs, and while that may look nice at Christmas time it really doesn’t solve anything. As such the real question here is how to drive real Infosec in real businesses in an effective manner.

I think we can build effective process and effective technology, but we have to solve the People problem to get to an ultimate solution. To me this means education, communication and maybe regulation. How would you solve the people problem?

UPDATE: added real name of SecurityNinja

Passwords–Oh how I hate thee…

Simple title, complex issue. Username-password (U/P) schemes are the oldest form of authentication on the net, and many agree they are getting weaker all the time. The cause of this weakness is human nature with regards to how you go about managing passwords you can remember. We go around the net reusing the same username and in many cases the same weak password. This has two parts to it in my mind the human side and the technical side.

Human Side
Why do users insist on using the same password over and over? Well for a practical reason our memory is limited as to what it can hold and recall when necessary. One could take the Bruce Schneier approach and write U/P pairs on a post-it not held in your wallet to address some of this. This still leaves the possibility for weak passwords and password reuse, not to mention a stolen or lost wallet resulting in the reset shuffle (password reset requests over email). Any non-security minded user likely will not differentiate passwords usage either. What I mean by that is the passwords for use in say financial transactions have a different gradient than those used for email and they too are a different gradient from sites that hold little or no personal information. Most users know their financial transactions are more sensitive but differentiate how they generate passwords for those example categories.

[Partially shameless plug, skip at your convenience] One of the solutions I use for this is somewhat similar to Bruce, but not on a post-it in my wallet and I also employ differentiation. I use KeePass, a free and open source password vault. Passwords I want to readily remember for general use or type-able (not stored) on my mobile are ones I can remember and type at will. For more sensitive actions I use the vault in KeePass. This allows me to set passwords with the maximum length supported by a site and enforce their maximum rules for complexity, thus I get a really ugly human-readable password I can’t remember. When I need it I put in my thumb drive, load the key and pass phrase for the vault and access the password. These tend to be less often accessed and sites that hold my most sensitive data (think banking). As soon as I am done with the password I close the program and safely remove the drive to minimize possible attacks. I also have passwords for sites I use rarely and don’t want to devote biological memory too.

Technical Side
Sites continue to use and ask for passwords on the concept that they want to tailor the service for us or differentiate service to a groups of customers. This makes sense to me, but why my local paper would need this so the stories I want to see are in a particular order does not (cookies work fine in this limited sense for my thinking). The real bottom line is sites and applications continue to use this paradigm because users are comfortable with it and it has very low friction even if it is somewhat broken. Two possible solutions to this are OpenID and Information Cards (IC). I am not going to get deep into the technicals here, there are much better experts than I. What I am intrigued by is how little adoption both have. From a practical standpoint I have tried both, I really don’t like OpenID, the use of URIs, it’s weakness from an identity provider standpoint and just general implementation make it an unattractive solution for the general audience in my mind although at the moment it has good support from Yahoo!, Google and a few others.

What really perplexes me is that I see IC as the clearly better solution here but it’s use is highly limited. The real force behind IC is Microsoft, are they so hated that a good solution doesn’t gain traction? Admittedly they aren’t really using it either (minimal use at Hotmail, which now also appears dead) and a small number of managed providers is likely not helping. I get lots of what I think people want (think Laws of Identity) and an interface I think most users can relate to.

So readers help me out here and comment. Am I barking up the wrong tree? Are we doomed to a continued use of U/P schemes? Will authentication privacy be the wave of future security focus?

Cars and Software and Quality Oh My!

On the way into work this morning I was listening an NPR report on the GM IPO, mind you I don’t want to get into a discussion on GM, the economy or any of that. However, an interesting quote caught my attention:

Hall says GM’s real problem isn’t the bankruptcy, it’s the company’s old culture. For decades, GM leaders protected internal fiefdoms at the expensive of the core business. The old GM sold cars with quality issues at a loss just to protect its market share. In the end, it lost the market share anyway.

To be completely clear it’s the third sentence that grabbed me, and had me thinking about the software implications. For quite sometime companies all over the world doing all kinds of business have created software to further their business goals. Just about any developer will also tell you that working these projects is a pressure cooker of getting to market. Get whatever it is your developing; a web site, a full client application, widget, add-on, whatever; out the door and get it out fast and spend as little as possible. Sound familiar? Sound like a lecture you may have heard about the Project Triangle in school maybe? So if we have the choices of good, fast and cheap and we are pressing for fast and cheap it’s obvious that good (quality) is being sacrificed. And I am not just talking the standard view of quality here, I am a software security guy after all and for me security is a quality metric, this is not about trim, door squeaks and abilities (all good quality metrics themselves).

Now I don’t want to go running down the path of software security as a quality metric or how that fits into software development, all good topics but it was another question that struck me when I heard that as my focal point. What makes us think that we can ship software with security bugs we could fix with a concerted development lifecycle to get to market first and keep our customer confidence/market share? We seem to be making the mistakes of GM almost everyday in a whole set of industries. Some of these industries are quite touchy to normal consumers, health care, financial services and the like. If we fail in our security efforts or just don’t provide focus on them and people loose sensitive information are we really going to keep our market share? Why do we keep operating companies on these models? Just because GM makes cars and we don’t does not mean there are not lessons to learn here.