Alik Levin's

Clarity, Technology, and Solving Problems | 

November, 2008

  • Alik Levin's

    Consulting And Security Reviews - How To Get Everyone Onboard


     Alik Levin    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.

    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 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:

    Phase Key Persona Activity Deliverable
    Envision and requirements
    Project Sponsor Security requirements discussed 

    Helpful resources:
    - STRIDE Explained
    - Visualizing – use Hello Secure World
    - Use Guidance Explorer to effectively build more technical requirements.
    Key stake holders buy in for Security. Best result achieved when key project member send out an email to the whole team
    Architecture and Design Architect, Development Leads Compile Security Design Guidance. Conduct Threat Modeling using Threat Modeling Template

    Use Guidance Explorer to quickly build guidance and inspection documents.

    Threats identified and prioritized.
    Coding/Building Developers Cannibalize ASP.NET 2.0 Internet Security Reference Implementation to effectively write more secure code – it is endless source of proven Security Code nuggets

    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

    Security bug list including priorities and how-to’s for fixtures.
    Deployment, Stabilizing IT System Administrators Stream line security deployment inspection using this step-by-step guide Security deployment bug list including priorities and how-to’s for fixtures.

    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 plugin for Windows Live Writer

  • Alik Levin's

    Agile Method And Gemba Kaizen

     Alik Levin    JD Meier published recently great post covering Agile Method. After reading it I could clearly see the lines connecting the method JD described with the Japanese Gemba Kaizen - common sense, low cost approach of managing workplace effectively.

    Related Resources:

    Gemba Kaizen can be distilled to three keys - Housekeeping, Cutting Muda (waste), Standardization.

    Key #1 - Housekeeping
    1. Sort – Separate everything unnecessary and get rid of it. Put a red tag on unnecessary items (for example, unused machines), then remove them.
    2. Straighten – Put key items in order so they can be found readily. Straighten logically, so items can be located with a minimum of wasted effort.
    3. Scrub – Tools and workplaces should be clean. Dirt and foreign particles can cause machinery to malfunction.
    4. Systematize – Make a schedule for cleaning and for checking that all is in order. This ensures that housekeeping is maintained constantly.
    5. Standardize – Make the preceding steps part of a regular process.

    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.

    Key #2 - Cutting Muda

    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!

    Key #3 - Standardization

    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!


    submit to reddit

    This post is made with plugin for Windows Live Writer

  • Alik Levin's

    Three Laws Of Consulting By Gerald M. Weinberg


    Alik Levin    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.

    The First Law Of Consulting

    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.

    The Second Law Of Consulting

    Weinberg Writes:

    "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:

    • The engineering team was mad at him - "Now what we are going to do for the last 5 months? They surely going to fire us all".
    • The management was mad at him too - "We have the budget for 6 months. What are we going to do with it? It sourly going to be taken back now...".

    It is always people problem...

    The Third Law Of Consulting

    Weinberg Writes:

    "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:

    • It is easy to sell (eliminate time for sales ceremonies).
    • It is easy to buy (the customer buys end result, not consultant's hours).
    • It is easy to deliver (doing same thing is easier than making up new thing each time).

    I witness more and more customers are willing to pay for end result vs. consultant hours.

    Related Materials

    This post is made with plugin for Windows Live Writer

Page 1 of 3 (9 items) 123