Avoiding the Security Gate

The worst place for a security program is to be a gate at the end.

What happens in organizations where security is seen as the final hurdle in order to launch a new service or feature? Security becomes the enemy. The development team has toiled for months to create and build the new code. They're over budget, over worked, over schedule and all they want to do now is launch. But one thing stands between them - the nod from the security team.

In this scenario the developers don't care about security. They have no interest in best practices, least privilege or layers of defense. All they want is the green check that means there code is shipped to the world.

This is not to say that developers don't care about security - in fact, I'd argue they very much do care. Instead, this is a reflection of a poorly built system that places one team in a position of superior control and results in the natural level of frustration and animosity.

If this sounds like your organization then you've done something wrong.

Over the next several posts I'll talk about avoiding the security gate and building an effective security program. We'll explore the following topics, and maybe more.

• Team structures for security
  
• Pushing security left
• Inverting the scanning model
• Operating at scale

Stay tuned for more...

-Michael Coates - @_mwc

OWASP Talk at RSA Well Received - Audience Feedback

This year I presented for OWASP at RSA. The talk was titled Security: Looking Forward - Protecting Critical Applications with OWASP

About 100 people attended (filled the room) and a quarter of the attendees submitted feedback. Happy to see the talk was well received.

 

-Michael Coates - @_mwc

Speaking at RSA for OWASP

I'll be speaking at RSA 2013 on behalf of OWASP. Hope to see you there.

Friday, March 1
10:20 AM - 11:20 AM 
Room 123

Security: Looking Forward - Protecting Critical Applications with OWASP  

Top 10 application security risks, free online security training, advanced application security testing tools, guidance on secure development lifecycle – these are all free resources produced by the OWASP open source community. Join this session and find out how to support and leverage the OWASP organization to help the fight for secure applications!

--

Also make sure to check out Jerry Hoff and Jim Manico's 4 hr seminar on Approaching Secure Code/

Monday, February 25
1:00 PM - 5:00 PM
 Room 132

OWASP-001 - OWASP: Approaching Secure Code – Where do I Start? (Half Day)

Regardless of your chosen/mandated framework for building web applications: Spring, Struts, Rails, PHP, Python, etc., you want to make your life easier, and potentially less embarrassing. Don’t be the one who left the door open for hackers. Learn handy tips from one of the world’s leading AppSec experts. Recommended for: Developers (dev managers welcome, assign people from your team to attend). Bring yourself, no materials required.


-Michael Coates - @_mwc

Leading Change in an Open Organization

Below is an email I recently sent to the OWASP leader's list. I think this perspective applies to many open source projects.

(Minor corrections for typos.)

---

We had a lively debate of various points this week. The actual issues aside, I’d like to provide some perspective on leading change. 

The takeaway from the heated discussion was:
1. Some people feel X is bad
2. Other people feel X is fine
3. Some people feel some small tweaks would have made X better

There was some good civil discussion, some shouting occurred, accusations were thrown around, and in the end the issue slowly fell away.

What were the results of this conversation?
1. Some people felt better to share their thoughts on an issue
2. Other people were likely offended from accusations
3. A list of several hundred people watched the back and forth
4. We ended where we started – this may be because our current stance is acceptable or because our approach to initiating change was poor

My two cents on how to lead effective change at OWASP
Keep the stones you are about to throw in your pocket. Use those stones to build a bridge.

* Change happens when people evaluate a situation, receive a variety of feedback, and build consensus around a path forward
* Assume good intent – everyone is putting in countless hours of time, when situations get close to the grey zone, let’s assume good intent and act as a team
* Apply change in a forward-looking fashion.  Most people are happy to get on board with an approach that is well thought out, socialized with the community, and better for OWASP.
* Look at issues holistically. If the whole forest is on fire, it doesn’t do any good to pick a single tree and focus on that. Look at the overall incentive structure, and the public guidance – we likely need to rethink the overall program.

How does this manifest at OWASP?
Do you think X, Y, or Z can be better? If so, start a global initiative and get some people involved from various perspectives (for and against, various vantage points/backgrounds). Evaluate the situation and consider the various incentives at play. 

Is this red tape? Not really, you’re free to approach the problem however you choose. But please consider this advice as you drive to lead change in an organization that spans the world, is completely open and volunteer driven, and is trying to fundamentally change knowledge sharing around an area that many people don’t understand.

-Michael Coates - @_mwc

The Safest Car Possible Provides No Safety

Let's design the safest car on the market. Not just a 5 star safety rating safe, but the absolute safest.  Our goal will be to prevent a death from ever happening with this car. We'll fight vehemently for every safety control and block any feature that doesn't provide the highest degree of safety. After all, we know how to design safety controls for nearly every potential risk.

What kind of car would we get? Well, it certainly would be the safest. But it probably also wouldn't move past 20 mph since high speeds create risk. The doors would have foam on the edges since people often hit themselves when opening it. Don't even think about windows that roll down, people often loose limbs by hanging their arms out into the fresh air. But, fear not this would be the safest car around and experts will applaud its extreme safety.

Now that we have a safe car let's ask ourselves this question, are drivers actually safer? No, because no one will buy the car. It may be safe, but the car can't compete in terms of expected features and normal usability. Since no one is using the car, the level of safety of drivers remains unchanged. They all still use the same cars designed by competitors with varying degrees of safety.


In order to be disruptive in a particular market on safety you have to first ensure you car is competitive on all other fronts. Only then can you focus efforts on excelling on safety. In addition, design decisions that unilaterally prioritize safety over basic and expected use cases and features must be rethought.

Is this to say that safety must be deprioritized in order to build a competitive car? Absolutely not. In fact, safety can be used as an amazing differentiator.  Get the best and brightest safety engineers and approach safety in new ways. You could very well build a car that can do amazing things while still being safe. Tackle new crazy features that drivers would love to have in their car but no one else can figure out how to design safely. Combine tried and true safety knowledge with new and creative approaches to safety that pass comprehensive testing.  This is how you can win on safety and build a car that will protect drivers - because they actually want to buy it.


Don't build a car that no one buys. You aren't protecting anyone.


-Michael Coates - @_mwc