This post discusses the obstacles to implementing security reviews and the secrets to holding effective and successful regular security reviews.

Who’s Involved and What Motivates Them?

Suppose a large enterprise, Contoso Banking, is building its next generation Internet facing web site. Who’s involved and what motivates them?

• Project sponsor. The project sponsor wants to ship the project to the end user’s requirements.
• Project manager. The project manager wants to ship the project on budget and on time.
• Development manager. The development manager wants to ship working version with less bugs as possible.
• Architect. The architect wants to create cutting edge architecture with some new technology TLA’s (three letter acronyms).
• Development Lead. The development team lead wants to build designs to proven patterns and practices saving on dev management costs.
• Developers. The developers want to build the feature and hit code complete mark.
• Systems engineers. The IT system engineers want to support bug free systems that do not require maintenance (or as less as possible).

Who Cares About Security?

Now, who cares about security of the project?

Common sense tells us security is the domain of the security guy’s, say, the Chief Security Officer.

Consider the following (not uncommon) scenario. The Chief Security Officer tells the team that the system needs to support two factor authentication due to regulatory compliance. That would usually result into the following reactions:

Project sponsor will need to tell the customers that web access won’t be as smooth as planned, since they will need to carry smart cards. End users usually get upset with such news. So the project sponsor is unhappy.

Project manager understands that with such requirement she will never ship it neither on budget nor on time.

Development manager freaks out imagining how many more bugs this requirement brings in.

Development team lead after quick search on the web finds designs that require special skills, tools, and methodologies. More sleepless nights ahead.

Developer never used crypto in any of her projects and now she needs serious ramp up on this cryptic topic. She is seriously considering moving on to a better project.

A Proven Pattern for Security Participation

Let’s ask who cares about security once more? All of the project participants suddenly care, but most of them are not pleased with the security focus. Working with my customers I found a proven pattern to get everyone onboard with security. The pattern can be boiled down to the following principles:

• Speak the language people understand.
• Understand motivations of the team.
• Optimize security according to the context.
• Be consistent.
• Be effective.

Speak the language people understand

This might sound funny but what I witness in the field is that people speak different languages, they might all speak their native English, Hebrew, or Russian, but in the end, even when communicating with the same language, no one understands each other. Consider another example, the unexpected security defect.

Tackling the unexpected security defect

Suppose the security tester proudly presents a Cross Site Scripting vulnerability to senior project stakeholders. It goes like this:

- “I found Cross Site Scripting vulnerability in your web site”, - Security Tester happily announces.

- “So?...”, – Project Sponsor asks honestly.

- “So?!?!, Let me repeat what I just said – I found Cross Site Scripting vulnerability in OUR web site”, - Security Tester repeats honestly confused.

- “So?.....”, -  Project Sponsor asks even more confused.

And it goes on and on. Until Project Sponsor asks simple question about the subject he really cares

- “How are the end users affected?”.

- “Their identities can be stolen and abused” – Security Tester explains with huge relief.

- “Oh my!!”, - now Project Sponsor understands the severity of the issue, then he continues – “What should be done to mitigate this?”

- “You need rewrite all web pages, with the right encoding, depending on where the data appears in the HTML output” – answers the Security Tester.

The Project Manager comes to life, he understands that he is not going to hit the deadline. He looks at Development Lead asking him silently with his rolling eyes:

- “How long will it take?”

- “Well.. we need to extend the schedule by… 3 months as our developers are not that proficient with such code”, - the Development Lead answers.

Everyone is upset. Security Tester comes to the rescue:

- “Let me suggest the following. You run this simple search and find all occurrences of the issue, and use a common library to make the encoding a simple one line fix in each case”

Project Manager sees the light in the end of the tunnel. In the end he might hit the deadline.

Speak the language that people understand.

"No matter how it looks at first, it's always a people problem." - The Second Law Of Consulting by Gerald M. Weinberg

Optimize security according to the context (what’s-in-it-for-me in action)

Security means different things to different roles. Understand motivations and show what’s in it for me to each one to make everyone buy in.

• Project sponsor sees security as the main reason to make end user happy or unhappy. Show how a security bug can reveal the end user’s information. Show how security feature alienates end users. Show how security feature actually brings in more end users.
• Project manager sees security feature as the main reason to not hit the deadline or as a reasons for extra expenses. Show how to easily implement security fixes, show how not implementing the fix will bring even more expenses and result in missing the deadline.
• Development manager does not see security vulnerabilities as bugs. Show him or her sample penetration testing report that looks very familiar to the bug reports. Such reports usually get the project from staging environment back to the development to fix the vulnerabilities.
• Development team lead cares to build proven designs. Point him or her to patterns & practices web site where the proven designs live. Save time and use proven practices. Make the development team leader a hero.
• IT System Engineer sees security as more incident calls, more sleepless nights as a result of incident management. Show IT System Engineer how fixing the security bug reduces incident management burden.
• Developer hates security. The code is tricky and the fixes are always urgent. Show Developer that security is actually very simple and can be easily implemented like this.

Be consistent

Consistency is the foundation of effectiveness, which will be discussed later on. Frames of core principles help a lot to be consistent. I found Security Frame very useful. It guides me and the rest of the involved parties, Project Sponsor, Project Manager, Development Manager, Development Team Lead, Developer. It creates a common language that everyone understands. Notice how the Security Frame can be used either for Threats that are relevant to Project Sponsor or for Countermeasures that are relevant to Development Force and more Technical audience.

Be effective

If you speak common a language, you get everyone to buy in. It is show time, time to deliver.

• How do your effectively create security requirements document?
• How do your effectively build secure architecture and designs or inspect those that others created?
• How do you effectively guide developers for security?
• How do you effectively conduct security code reviews and deployment inspections?

The answer is simple; you follow proven patterns and practices. Fortunately, patterns & practices PAG team, led by J.D. Meier, has built fantastic tool, Guidance Explorer that maintains more than 3,500 easily consumable items on security, performance, and Visual Studio topics. J.D. also maintains his SecurityGuidanceShare.com wiki where he chunks the guidance in more consumable way. Guidance Explorer allows quick searches, direct access to the information according to Security Frame. But two features that bring me effectiveness is its ability to create Word documents and ability to be consumed via any RSS reader.

Practices

Apply proven practices. Avoid approaches that do not work. Do more in less time.

The highest return on investment is achieved when security activities match specific phase of the development lifecycle. These activities must produce results that are relevant to key personas of the phase.

The following table summarizes personas and focused deliverables according to development lifecycle:

Driving for effective security reviews

Ideally all these activities should be conducted throughout the whole development lifecycle. In the real world projects this happens rarely. Nevertheless, effective security inspection techniques prove that security bar can be constantly raised. One thing to keep in mind that security bugs can be revealed at any development phase but the cost of fixture climbs exponentially as the projects approaches production environment. It is all about risk management.

This post is made with PracticeThis.com plugin for Windows Live Writer