Got a problem? Build a Lab!

Do you have a business problem that is an energy-sucker? You know, one of those challenges that brings you down just thinking about it? Often I encounter people who have such problems and do not lack these problems myself. One of my old Kenpo instructors always use to refer to problems as "opportunities to learn". This always irritated everyone in the room but it was a great approach. Problems are only problematic for the duration that we permit (another saying). Translate this to business and I have a practice called Labbing (i.e. running a lab) to turn problems into opportunities to learn.

Labs begin with a challenge. Let's take a simple one:

Reducing the number of vulnerabilities in your code.

First, schedule your Lab with people who will engage in the topic. It does not matter if everyone is an expert on the question's topic. The only thing that matters is that you have a highly engaged team. You should always have at least one expert in the room but different perspectives leads to a better result, so diversify! Schedule with plenty of time in advance so the thinkers can get their gears turning. Keep the meeting to a time frame that is the absolute minimum necessary to solve the issue. In my Lab sessions I have found that many business challenges can be resolved (conceptually) with 30 minutes of focused conversation. The time crunch maintains focus and prevents distraction down rabbit holes.

So for our challenge I would setup a 30 minute meeting with a few developers and good thinkers in my company like people in Operations. 

When the Lab actually begins start by making sure everyone knows the goal. Do this by writing it on a surface that is displayed prominent during the Lab session. Do not write it before hand. Write it when the meeting starts and read it as you write. I don't know why but this seems to get people more interested in what you are writing. Maybe they are watching for you to screw up.

For our sample, the goal is: "To reduce the number of vulnerabilities produced by developers by 90% over the next six months."

Now to get the gears grinding ask a question that opens the world to the Lab participants. The question must get them thinking about the challenge in a different way. Here are three techniques I use and how I would use them in this scenario:

• Identify As-Is system: "What is the current process we use to reduce our vulnerability counts?"
• Reversing: "I want more vulnerabilities in our code! How can we do that?"
• Fantasy land: "What would it be like if we didn't have any vulnerabilities in our code?"

Your opening question will dictate the rest of the meeting. For instance if you use an As-Is system approach, then you will examine the defined system to determine how to improve it (or totally rebuild it) to be the system that you want. Reversing leads to identification of the things you don't want and through the process of atrophying of undesirable scenarios you build what you want to be doing. Fantasy land is the identification of the ideal, followed by a reality check to see the difference and then performing a basic gap analysis. 

Any way you start, the middle of the Lab is exploring. Where are you? Where do you want to go? How can you get there? What are options for arrival? Use this time to explore the world of your business challenge.

Finally, there will come a time when you need to pull the world back together and close the Lab. I always stress with the Lab that we will end "with a conceptual working prototype" that will solve our business challenge. Again, your opening will direct your closing. No matter what, your closing must achieve the following things:

1. It must bring closure to the Lab. You cannot continue the discussion because all the energy that got you here will need to be rediscovered and might be lost. Do not plan on a part two of the discussion. If something came up that is a hanging question table it for a different Lab. In the case where an issue arises that will push the Lab out of its time frame, stop the Lab. Assess the business challenge to see if you are addressing the real issue or a symptom of the issue.
2. It must define time bound follow up actions. The Lab must end with a conceptual prototype so when will you begin implementation or discuss implementation? Set a date and stick to it.
3. It must clearly define who is doing what. Make sure everyone who has a task when the Lab ends knows their task and provides an estimate on its completion.

Running your own Labs can be very fun and rewarding. I encourage everyone to try the brief exercise of Labbing at least once in their business and see where it gets them. While this is not a comprehensive guide to running Labs I will post some examples that I have run (without the details of the goal, challenge or people but still be meaningful [somehow?]) to show some examples.

Good luck and enjoy your next Lab experience!

Happy Halloween: Trick and Treat

First, something totally unrelated to this article...

I just received an email from Google stating that I am now registered for their Authorship program. Wondering what the hell authorship is I decided to check it out. Apparently it is an interesting program that allows people who write content (and have a Google+ account) to link their online persona to the content they have written. Interesting idea but I'm not sure I really get it other than it is a way to make sure that you are viewing content for who you think provided the content. I wonder if there's a way to pose as another. Evil Twin style!

Now on to our show

Today being Halloween I wanted to provide a trick and a treat for those who read my blog.

Trick
Recently I've been involved in a variety of projects focus on security auditing. One of the common themes that keeps coming up is people's lack of knowledge and motivation to learn around Information Security policies and procedures. Let's face it they are not fun and often read like a magical tome disconnected from reality then something the average corporate employee can connect to. So how do you get people wanting to learn about information security policies?

Lately I've been on a gamification kick so I thought this could be a fun experiment. Can we get people to not only learn about information security policies and procedures but want to learn as well? So here is a simple P&P game I am calling

The game is simple. Start by identifying your least understood information security P&Ps. Often Change Management (who can change what, when and how does that change get to production) is a good one. Setup a couple teams (2 or more) with each team containing one person who knows the P&P (Team Coordinator) and the rest of the team who are less familiar. The Team Coordinator tells the rest of their team about the policy and procedures. After the brief training the team meets to build a poster for the policy. The goal is to build a poster that is unique, catching and conveys a specific element of the P&P. For example, in Change Management the poster could have a tag line like: "Don't move! Your changes need to be reviewed." with a picture of a police officer. The team with the most engaging poster wins some prize (up to your budget :)) Let the audience and teams decide who wins.

Building the poster provides a learning opportunity for the teams to get a deeper understanding of the P&P. Displaying the poster(s) provides an excellent "awareness" opportunity to keep people thinking about the P&Ps.

What techniques do you use to engage your company and improve P&P knowledge? Leave your thoughts here. I'd love to see them!!!

Treat
With Disney's recent acquisition of LucasFilms I thought this was a really great video. I can't wait to see what the imagineers do with this franchise!



Happy Halloween!

JavaScript might be all you've got

How many times have you heard something along the lines of "JavaScript is on the client side so the attacker can do whatever they want to it." or "There is no point wasting time on security client side data because the attackers can just bypass it." I have heard these things myself (and said them once or twice too). In a web application the client cannot be your only line of defense, but what if JavaScript is all you've got?

Currently Script Junkie is posting some articles I wrote about Mashups and client side security. These articles provide some techniques that you can use to implement client side security in your web or HTML5 applications. The main thought I had for these articles is that in HTML5 apps and Windows Store apps, JavaScript might be the only code in your application so how to we build more secure apps? We can't always rely on a server for protection. That is why I am writing these articles to give some tools (hopefully helpful tools) that people can use to improve their apps when all the code is JavaScript.

Short post as I am working on a bunch of writing projects but this was just something on my mind.

A few things I like about VS2012

I will admit, at first I really did not like the Visual Studio 2012 design. The new look and feel didn't really thrill me. As I have used it more and more I have found things that I really love about Microsoft's new IDE that makes life as a web developer easier.

1. Debug to browser
Web developers have to check a variety of browsers to ensure their code functions as expected regardless of the platform. In VS2010, WoVS made a great plugin for this but VS2012 builds debugging to specific browsers into the debug start button. This makes it easy to jump right in to your application in whatever browser you need.

Along with your browsers you can debug in the Page Inspector which is a handy browser for reviewing blocks of HTML, styles, etc... For those familiar with the IE Developer Tools, it is similar to that but I have not really dug into Page Inspector to nail down the differences yet.

2. Code Metrics
Who doesn't like measuring things when it comes to code? Well, most people probably don't care but for me this is an exciting feature. Using the Code Metrics features you can drill into your code and determine where some attention is needed using metrics like Maintainability, Cyclomatic Complexity (how many branches does your code break in to), Lines of Code, etc... These metrics are exciting for me as a development manager because I can use them to set goals for my team. While metrics against code (like how many SLOCs a developer produces) are never a good measurement of quality, the provided metrics are goals to strive for.

3. More online templates and samples
This isn't really a VS2012 thing but it is something that I have come to enjoy in VS2012. When creating a new project there are many options for templates and samples that allow you as a developer to have a spring board into building your next application. This is great for developers like me with very little time to code on my own (outside of work) and allows me to start from a template or sample. Also, as I learn new development tools or technologies (like Windows Azure which I'm really just starting to get into) I don't have to build out a new application to test the new toys. I can just use these great starting points.

4. Built in SQL Schema Compare
I really like the Red Gate developer tools but was very happy to see SQL Schema Compare built into VS2012. This is an incredibly useful tool for me to see what the differences between test and production systems are when someone accidently forgets to document what they have done on the test system (not that this ever happens :) ).

Those are just a few new toys that I enjoy in VS2012. I am using the Premium version of 2012 and have previously used Professional 2010, so some of these features might have existed before but they are new to me. Also, now that I have been using it for a while, the interface has grown on me.

What do you like or hate about VS2012? How do you feel about the new interface?

This application says your code sucks

Recently I had the fortune of inheriting a few Fortify licenses. For those of you who do not know, Fortify is HP's static code analyzer that assesses your source code for security vulnerabilities. I say fortune because it assess application security on a code level and led to a great leadership experience for me: how to deal with pissed off developers when an application says their code is insecure.

First, what the heck is a static source code analyzer?

Source code analysis tools examine un-compiled or raw code for patterns. In more lengthy words, source code analysis tools examine the source code of an application and provide recommendations on how to improve it based on patterns the tool finds in the code.

Code analysis occurs in two ways "Static" or "Dynamic". Static analysis is examining the code without it executing while Dynamic analysis is examining the code while it is running.

So then what is Fortify?

Fortify is a static code analysis tool focused on security. This means that it analyzes your source code and digs up any security vulnerability it thinks (keyword) exists. In the world of Software Security Code Analysis/Review is the most critical component to building secure software (according to Gary McGraw in his book Secure Software [Software Security: Building Security In] which I've referenced numerous times on this blog). While you can get a lot of great ideas, feedback and improvements to code with peer reviews a tool like Fortify or FxCop is really needed to catch attack patterns that the team might not be familiar with.

Code analysis is good! People's reaction to the results, not so much.

While using Fortify is simple, people's reaction to what the tool showed was not as easy to deal with. Unlike code reviews where people could be nice about how bad something is, tools like Fortify are blunt, to the point and rate just how terrible of a developer you are (or at least, that is how people can feel about it). When code is art, people don't like hearing that it has problems. With this in mind, you have a recipe for disaster. You want to make sure that you're applications are secure using a tool like Fortify or FxCop but you want to keep your development team's frustration levels low and spirits high. How can you get your cake and eat it too?

#1. Focus on the code not the developer
Accept one cold hard fact, you are where you are and it really does not matter how you got there. Fortify is going to tell you all your problems and recommend ways to fix them. As the development manager you need to keep the team focused on the code, don't place blame but make sure everyone is aware of security goals moving forward. If you have the opportunity to do so, assign remediation of the code to the original developer. This becomes a learning experience for them and also allows them to save face so their code is not perceived poorly by others.

#2. Make it about learning not about fixing
Yes, Fortify will find security issues but these are not problems, they are learning opportunities (yes, I do feed my team that kind of fun positive thinking talk :) ). Fortify will give you tons of data in the security report of your application(s). Take that data and assess what are the top 3 security issues you have throughout your application(s). Schedule a developer training meeting that focuses on one of these items. Follow up with another training on the second item, etc... Stick to the topics and follow up often to make sure the team has a firm grasp on the security issue and how to ensure it does not creep in to future builds. Stay away from terms like:

• We need to fix this issue
• People are going to use this to hack our app
• The world is going to end because your app is insecure

Focus on how the results from the scans will lead to more secure code not how insecure your common state is. This is not saying ignore the present. No, re-mediate as quickly as possible and deploy a more secure application but do not beat up your team over where you are because they will not be able to (nor want to) see where you want them to go.

#3. Reward success, support those who need it.
Let's face it, in the software world business sponsors want product fast, cheap and do not care about security until it bites them. Developers feed off this behavior by focusing on features, schedule and sometimes chose the quick solution over the best solution. This is a learned behavior that will take time to unlearn. The best way to bring security in focus is through positive reinforcement. Celebrate successful remediation of the application(s) with some fun activity on production release. Provide incentives to team members who regularly produce vulnerability free code and training to support team members who are not quite there yet.

If you have team members who consistently have problems, ask them to lead the next training. People who have trouble grasping a concept can often find their Rosetta Stone of understanding by trying to explain it to others. Another support mechanism could be paired programming with developers who consistently produce low vulnerability free (or mostly free) code.

In the end, it is your show

When you use a static source code analyzer to assess your team's code, as the leader you are responsible for making sure the team is on board with the results and acting on those results. These are basic ideas on how to make a source code analysis tool good for your application(s) and team morale. There are many more ways to make this process more painless. Let me hear some techniques that you have used to make this process go smoothly.

Cookieless Sessions with ASP.NET

Sometimes a security issue will sneak in to your code when you do not know what to look for. One great example of this is a Session Hijack attack which in code does not look like a vulnerability. The Session Hijacking attack we will explore today starts with Cookieless Sessions. Developers use cookieless sessions to attach the session to the URL which you might want to do for a variety of reasons:

• Users might not have Cookies enabled,
• cookies can be stolen,
• etc...

Setting up the attack is fairly easy and can be done without looking like a problem to the developer. First create a new Website project in Visual Studio: File > New Website. Use the default setup for the site or customize it however you would like.

First we need to setup our interface that will capture our Session data. Copy the following standard interface code to the bottom of your Default.aspx page:

<asp:Label ID="lbl1" runat="server" Text="" BackColor="Green" ForeColor="White" />
 
    <asp:TextBox ID="txt" runat="server" />
    <asp:Button ID="btn" runat="server" OnClick="btn_Click" Text="Save Session" />

This is a simple Label that will display the value of our session variable. Now open the Default.aspx.cs code behind file and replace the Page_Load placeholder code with the following:

protected void Page_Load(object sender, EventArgs e)
    {
        if (null != Session["testing"])
            lbl1.Text = Session["testing"].ToString();
    }
 
    protected void btn_Click(object sender, EventArgs e)
    {
        Session["testing"] = txt.Text;
        lbl1.Text = Session["testing"].ToString();
    }

Notice that the code is simply checking for the Session value on load and if it exists, displaying it in a label control. We also setup an event handler for the Save button that will store the value of the text box. The final step to make the threat of Session Hijacking a vulnerability. To enable cookieless sessions we add the configuration element (in the web.config) for sessionState cookieless="true":

<sessionState cookieless="true"/>

Now, run the website in your default web browser. Enter a value in the text box and press the Save Session button. This will store the value of the text box into the Session variable called "testing". When the page reloads you will see the value load into the label.

Sessions are unique to connections and browsers so you can test this vulnerability by copying the session identifier in the URL into a new browser, you will keep your session and see the value you entered in the previous browser. This is because the Session ID is passed into the new browser will load the values on the Session to the new browser. In essence you can move your session between browsers, depending on the application deployment, between computers.

Big ideas are great, but common knowledge is not always common

Recently I read a great blog posting on the Microsoft SDL blog about Secure Credential Storage (http://blogs.msdn.com/b/sdl/archive/2012/01/16/secure-credential-storage.aspx). When I read this I kept thinking, there is going to be something really secret and great here. Each paragraph built on my expectations but at the end, I realized that the article was not expounding anything new but stating, in clear terms, something that I thought others should already know. Thinking about this further led me to realize that in my own writing I focus too much on great new ideas. This results in the dreaded analysis paralysis (as we used to say in Kenpo) also known in the writing world as Writer's Block.

So in the future I will be focusing on some common knowledge things that I have been learning are not so common such as why should you put length limits on fields in ASP.NET. The article by the SDL team is a great read and I recommend reviewing it especially if you are new to Software Security. As it turns out the lessons can be about more that software security :).