Clarity, Technology, and Solving Problems | PracticeThis.com
WP7 App with Key Windows Azure resources – Slides, Videos, How-To’s, and T-shooting – for quick consumption on the go.
Security reviews are a respected methodology. People know about them, and probably use them semi-regularly. Ask anyone if security reviews are important, and they would all say yes. Ask them if they do it regularly, and most would say no.
Related Materials
This post discusses the obstacles to implementing security reviews and the secrets to holding effective and successful regular security reviews.
Suppose a large enterprise, Contoso Banking, is building its next generation Internet facing web site. Who’s involved and what motivates them?
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.
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:
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.
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
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.
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.
If you speak common a language, you get everyone to buy in. It is show time, time to deliver.
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.
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:
Use Guidance Explorer to quickly build guidance and inspection documents.
Bookmark ASP.NET 2.0 FAQs to address security question during the development
Conduct effective Security Code Review asking questions from Security Question List: ASP.NET 2.0
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
Related Resources:
Gemba Kaizen can be distilled to three keys - Housekeeping, Cutting Muda (waste), Standardization.
Agile Method gives a very clean view of the process, activities, and deliverables thus eliminating noise throughout the process of building the solution architecture. It seems like it's been build with Housekeeping in mind - Sort, Straighten, Scrub, Systemize, Standardize.
Muda (waste) is anything that does not add value. JD has been writing on it in his Get Lean, Eliminate Waste.
More Kaizen to Agile Method!
The third key of Gemba Kaizen encourages to follow clear process in iterative manner. One picture worth a thousand words. JD shares the following chart that gives an overview of the Agile Method:
Toyota does Kaizen and succeeds. Apply Agile Method and succeed too.
Agile Development Kaizen style!
As part of my quest to become a better consultant I am reading Gerald M. Weinberg's book Secrets of Consulting: A Guide to Giving and Getting Advice Successfully . It is quite controversial and provocative book. At the same time Weinberg shares real world practices that help folks in the field like myself coping with tough situations. It helps to avoid being eaten alive.It also entertaining and sometimes cynical which only teaches you to not take life too seriously, otherwise you will never get alive out of it. Weinberg shares his story in form of laws. Here are three first laws of consulting by Gerald M. Weinberg.
Weinberg Writes:
"In spite of what your client may tell you, there's always a problem."
This must be a daily mantra for any consultant. Problems are consultant's bread. I think one of the greatest skills consultant should possess is seeing problems everywhere (read "opportunities"). Sometimes these problems ("opportunities") are latent. Consultant's job is to discover it and present it to the stakeholder in such manner so there is no way other than hiring you to solve it. If the consultant discovered fake latent problem she won't be hired again. If the consultant discovered real latent problem and even showed the way to solve it then the consultant's brand gets stronger and she gets more gigs.
Consultant, search for real latent problems.
"No Matter how it looks at first, it's always a people problem."
This reminds me a story, my colleague consultant told me yesterday. He was involved with a 6 months project. The project's only goal was improving performance of a software. After few quick researches he solved the problem presenting the whole management and engineering team with the solution. Success? Far from it. He became a center of cross fire:
It is always people problem...
"Never forget they're paying you by the hour, not by the solution".
Mister Weinberg, you are absolutely right! But I am on my quest to break this law. I truly believe that the better option is productized service. Why? Here is why:
I witness more and more customers are willing to pay for end result vs. consultant hours.