Seccode Pages

Tuesday, March 10, 2015

UML Journey 1: Use Cases

As most project managers will tell you, software projects are hard. Recently one of the significant challenges that I've been examining is how to make it easier for requirements to come from the business and go to the development of a technical specification.

UML seems like a tried and true candidate for building artifacts that can transition between teams and provide standard understanding with little interpretation. Being mindful that UML is built into the Visual Studio Ultimate IDE, and can integrate with Team Foundation Server (TFS), it becomes a very compelling candidate for system modeling (including requirements modeling). Especially for people using the Microsoft development stack.

When building out UML documentation, Use Cases document and model the requirements of the project. Use Cases are composed of three components:
  • Actors: Who (or what) is doing the use case.
  • Sub Systems: Where the use case happens.
  • Use Case: What is being done by the actors within a subsystem.

An example project: Use Case Generator

Imagine we have a development process where the Business Analyst writes the Use Case descriptions. Use Case descriptions define the above components as narratives. A core component of the imagined development process is TFS. So I want to have traceability for use cases to the project's requirements. Visual Studio Ultimate can build UML Use Case documents but as a small IT shop, I don't have the money to buy every BA the most expensive Visual Studio. Instead, we will build a Use Case Generator web app that will produce Use Case descriptions to be consumed by Visual Studio.

So we are going to build a little web app that will allow a BA to write a use case following a template (see below). To learn about Use Cases, let's build the Use Cases for our Use Case Generator web app. Let's get started:

Step 1: Listing the Actors

Start by listing out the Actors. The critical question her is who or what is interacting with the use cases. I usually start with people as they are easiest to determine for me:
- Business Analyst: this actor is the main user of the Use Case generator system.
- Architect: this actor will receive the Use Case from the generator to import into Visual Studio

Now, list out the "what" actors, those that are not people but that the system will interact with. For this system we will have only one:
- Data Store: I will need somewhere to save data. This actor is a system component that I'll use to save data.

Notice, we do not define "how" we are saving data just that we need to have some actor that saves data. Use Cases don't necessarily deal with the details of the how. Build out your list of actors and re-examine - are you missing anything? Did you identify everything or too much? How do you know? We'll come back to this in a moment. For now, give yourself a time limit of 10 minutes to define all the actors. Don't get bogged down into paralysis through analysis.

If you are starting with requirements or user stories, they review those for nouns. Nouns are a sure give away of an Actor. For instance in the following user story: "As an Architect I must be able to export a PNG image from the UML diagram so that I can embed the diagrams in a web page." In this high level and fairly ambiguous user story we have a clear Actor, the Architect. Use Cases can easily be distilled from User Stories due to the format of User Stories. Try it out for yourself. Review your product backlog and build a list of all the Actors from your User Stories.

Step 2: Use Case Listing

With Actors listed, now create a list of what you want your system to be able to do. Try to keep your Use Cases to Verb-Noun pairs that are clear to you. For our system, here is our list:
  • Add Actor
  • Edit Actor
  • Delete Actor
  • List Actors
  • View Actor
  • Add Use Case
  • Edit Use Case
  • Delete Use Case
  • List Use Cases
  • View Use Case
  • Export Model (export the Actors and Use Cases)
  • Save Model
  • Clear Model
  • Load Model
Notice that I start with a simple idea...CRUD actions for Actors and Use Cases and then overall system actions such as save, load, export and clear. When it comes to use cases, I like to list out everything like a brain dump and then go back and make sense of it. Also, notice earlier I said "verb-noun pairs that are clear to you". This "you" is critical. For now you are sketching, rough draft, preliminary ideation, whatever you want to call it. You are just throwing ideas on the table.

Step 3: Use Case Descriptions

Now for each Use Case we listed we need to build out a description for it (this is where the use case becomes clear to others and not just "you"). Russ Miles & Kim Hamilton's Learning UML 2.0 provides a great template for Use Case descriptions (as a side note, this book is excellent to learning UML). The template is great for capturing what a use case actually means.

Fill out the following items for each use case listed.
  • Use case description: why is this use case useful for the Actor(s) engaged
  • Related Use Cases: what other use cases are used in this use case? Perhaps there is a common use case shared among many uses cases (also known as an "included" use case. List out all the related use cases here.
  • Goal in Context: what is the goal of this use case? Where do you want the Actor to end up?
  • Pre-Conditions: what needs to happen before this use case can happen? For example, for "load model" use case to work, we need to first "Save Model" so that we have a model to load.
  • Successful End Condition: what happens when everything works as expected? This is a great data point for QA as they can use it to identify what the expected end result is.
  • Failed End Conditions: what are some expected failure conditions. As an example, what happens when load model is called but there are not any models saved? List out as many failure scenarios that you can think of.
  • Primary Actor(s): who is the key players in this use case? Normally this is an initial mover for the use case.
  • Secondary Actor(s): who are the supporting cast in the use case. This could be a database or web service call.
  • Trigger: what is the action(s) that start the use case? Normally an Actor triggers the trigger. List here what happens that starts the next item (main flow).
  • Main Flow: if everything works as expected, how does the use case flow from start to end? This shows the steps of execution for the use case.
  • Extensions: when things don't follow the Main Flow, what happens? Extensions show alternative routes that the use case could take and how to handle them. Use Extensions for things like error handling and recovery.
Okay, so let's build a description for one of our use cases.
Use Case Name: Add Actor
Use Case Description: this use case allows users to create a new actor for the model.
Related Use Case: no related use cases
Goal in Context: After adding an actor, the actor will appear in the Actor list and viewable from the model.
Preconditions: Business Analyst must have "Add Actor" permission
Successful End Condition: the Actor is added to the Actor List, a success message is displayed to the end user and the Actor details form is cleared.
Failure End Condition: Actor is not added to the Actor list. Success message does not display. Actor details form shows actor's details after clicking Save.
Primary Actors: Business Analyst
Secondary Actors: None
Main Flow:
  1. Business Analyst clicks on the "Add New Actor" button.
  2. A new Actor is added to the Actor list showing the Actor name: "New Actor"
  3. The Actor Details form appears with the new Actor loaded
    1. Name: New Actor
    2. Description: Blank
    3. Location: Blank
  4. Business Analyst updates the Actor's details with the following fields:
    1. Name (Required)
    2. Description (Required)
    3. Location
  5. Business Analyst clicks the Save button
  6. The Actor is updated in the Actor list
  7. A success message is displayed saying: "The Actor was saved successfully"
  8. The Actor Details form clears it's values
4.1 If the Business Analyst does not provide data in the fields, a validation message will appear letting the Business Analyst know what fields need to be populated.
5.1 If the Business Analyst tries to save without providing the necessary fields a validation error displays.
5.2 Save is aborted

This is a simple example but illustrates how to use each element. Give it a try for another Use Case listed above. Leave your attempt in the comments section. Community review is a great way to refine your Use Case descriptions and all readers please remember, this is a place of learning not of ideal perfection :) .

Wait! Where were subsystems? Well, good question but for now, we'll wait on that. Remember, the BA is writing this for the Architect. When the diagrams are built by the Architect - the subsystems will be identified. If the BA knows them that is great but subsystems in our example process are the realm of the Architect.

Step 4: Use Case Diagram

You have your use cases described, you have your actors listed, now you need to put the big picture together. We will do this later in a future posting. For now work on your narratives.

Step 5: Enjoy a drink for your good work!

Go enjoy a drink now and try to write up some of your own use case descriptions. Next we will build out a small web app that puts all these use cases together.

Was this a helpful introduction to Use Cases? Let me know your thoughts below.

Sunday, November 11, 2012

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!

Wednesday, October 31, 2012

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.

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

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!

Thursday, October 18, 2012

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.

Sunday, September 2, 2012

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?

Friday, August 24, 2012

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.

Sunday, March 25, 2012

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.