The Top 25 Vulnerabilities

David Letterman has his nightly top 10 list, and it seems that MITRE now has their top 25 list. I am still digesting the ton of content that came out yesterday from their partnership with Homeland Security, but the Top 25 List of Dangerous Software Errors is pretty good. A lot of our old favorites are there, like SQL Injection and Cross-Site Scripting. But I read about a new one; the use of One Way Hash without Salt.

This list is very approachable, to the super-geek and geek alike. It isn't intended for the non-programmer. You will notice that each of these weaknesses has been assigned an objective score between 0 and 100. They derived those numbers using their new Common Weakness Scoring System. Yes, now there are objective (or nearly so) measures to run your weaknesses through to identify the relative significance from Technical Impact to Access Vector.

Finally there is the Common Weakness Risk Analysis Framework. This framework describes a process by which you run your application code through an analysis tool, I'm assuming like IBM's Ap Scan, and it will regurgitate a bunch of weaknesses. You then take those weaknesses and push them through this risk analysis framework to help you identify which of those weaknesses are the most important to your organization. That helps you to prioritize what you are working on and to address the highest value weaknesses first.

My hat is off to the MITRE team for putting this together. My head is still spinning because it is so much.

Management Plans

I will be the first to admit that I have a very specific method by which I approach a project. I like to do things my way. I'm sure many Project Managers are the same; they have a style that suits them and they use that method when they manage their projects. Mine is likely to be different from other Project Managers, and that is fine. The last time I checked there were many ways to achieve project success. However it is important that the Project Manager takes the time to share his or her approach with the team, and that is where Management Plans come it.

Anyone can read the PMBOK and walk away with a half dozen management plans. They will walk you through Communications Management, to Scope Management, Risk Management, Schedule Management, Cost Management and so on... All of these plans have value and are important in communicating how the project will run. In the case of the Communications Management Plan, I always include an escalation section identifying how decisions will be made when the stakeholders can't reach consensus. This is a good example of how a little bit of planning up-front can help to save a lot of time. It is very easy to write down and commit to this process when a project is just starting up because nobody has any disagreements, and people aren't dug into their factions. Trying to identify how a decision will be made when people are already dug-in to opposing side is much more complicated and difficult.

But you won't find what I consider to be the most important Management Plan in the PMBOK. This plan is critical for me when I am working with new teams of people who aren't familiar with my approach. I am talking about the Requirements Management Plan. This plan provides the model by which the project team goes from a position of having zero knowledge about something to a finished project. For me, this framework begins with Requirements Sessions in which we focus on the baseline business process. We work to diagram it and the key use cases of that process. Then we use this information to begin our discussions of what the benchmark business process should look like. This approach forces us to examine the differences between these two processes. We generate a set of use cases from this benchmark process and those use cases are really important to downstream activities.

The first branch of work from the use cases is to develop the Requirements Specification then the Data Requirements Document. These two products then drive the development of the System Design Document and the Database Specification. The System Design Document and DB Spec are in turn used to generate the System Security Plan and functional software.

The second branch from the use cases is to drive the development of the Unit Test Plan. This is the building block for testing and verification of the functionality. The Unit Test is a part of the Integration Test Plan as well as the Acceptance Test Plan.

Thus as functionality changes over time and the use case changes, it is somewhat easier to mature that change through the documentation when it is clear how each piece if related to the others. By taking the time to document these relationships and how we go from zero to working functionality people who want to understand why they are participating in a requirements session or a design session can see how their work builds momentum to the finished product.

Anyway, for my money, the Requirements Management Plan is the most important and valuable Management Plan in a project.

Organizational Conflict

I could go online and pull a thousand articles about government transparency in about 10 minutes. Everyone talks about transparency but getting to the actual intent is somewhat squishy. I think the best way to describe transparency in government is to say that it is a culture of openness. It is a recognition that "I don't know everything, and if I present other people with an opportunity to review and comment, then, maybe together we don't get something that is perfect, but it is definitely going to be better."

Transparency is like wiki-consensus, getting enough eyeballs on something will eventually get us to a consensus truth that we can all live with.

But the title of this post is Organizational Conflict. When this new transparency-oriented government worker has to interact with the old style brand of government worker, that is where we see friction as an organization. The government is in the process of transitioning from the bureaucratic directive-oriented, "I say an order and you carry it out" style, to the more transparent consensus building one. When these two parts of the organization collide, there is sure to be a conflict.

Personally, there are lots of things that are frustrating about government work, but I do love it. However this one point has continually frustrated me over the years. And please understand that the directive-style is not necessarily perpetuated but people who have been in the government for decades. In fact, a lot of the people I am seeing with this mindset have less than 5 years under their belt.

The thing that is supremely frustrating for me is the fact that I know that their decision-making process is flawed. The problem is that they don't realize that. They don't know what they don't know, and therein lies the problem. I see the bad decisions, and I have to live with those bad decisions, but I feel powerless to fix it. I wish that I could finish this post with the idea that there is some kind of potion, or magic trick that fixes the problem. There isn't. This is an issue of culture.

The Program Manager

Yea, my job finally exists. To absolutely no fanfare, except from me, The Office of Personnel Management released a new classification of IT worker, the Program Manager. It is

Work that involves managing one or more major multi-year IT initiatives of such magnitude they must be carried out through multiple related IT projects. The IT Program Manager leads, coordinates, communicates, integrates and is accountable for the overall success of the program, ensuring alignment with critical agency priorities. They are responsible for ensuring the work efforts achieve the outcome specified within the agency’s business strategy, including appropriate strategic, life cycle management and capital IT investment plans. Work includes project selection, prioritization, evaluation and monitoring, cost schedule management, risk management, quality management and resource allocations

This is in support of the 25 point plan from OMB. Here is the announcement and the entire, revised 2210 classification is here.

My opinion is that they are still missing a great deal of of the bleeding over into the acquisition field, but that is a discussion for another day. For now, I'll just be happy that there is now a difference between Project Managers and Program Managers.

Xtranormal Follow-up

So a few weeks ago I was excited to try out some new software. I'm still very jazzed for this capability, but it is tempered a bit. I was definitely under the impression that if you are doing real government work that this Software as a Service (SaaS) would be free. It looks like I was wrong about that. No, government people get charged the exact same amount as everyone else. It works out to be:

1,200xp -$10

5,000xp - $25

15,000xp - $50

40,000xp - $100

80,000xp - $150

The only difference between a government user and a regular user seems to be the terms of service, but it isn't that different, hence my enthusiasm is contained.

You spend the points on the characters, the sets and rendering the presentation, and that is each time you render it, so if you need to do re-work, then there is a cost to that. Each movie I would estimate to be between 350 and 550 points. So it isn't a dump truck of money, but if you are trying to do something innovative where there is no budget it becomes difficult. Anyway, my initial goal was to prove my concept. I wanted to take a snippet of content that I had already created and rendered using my Camtasia method and repackage it with Xtranormal. I definitely proved that there is value here. I picked something short and sweet.

Go to the second Case Study (11:57) in Module 4. Now compare that against this one from Xtranormal. It is the exact same content, just delivered in a different way. I am certain that if we used the Camtasia method to develop most of the training or instruction and then came to Xtranormal for thinks like case studies and break-outs it would be a much stronger product overall. Anyway, I hope to work a deal in which I can really get in and develop some cool stuff.