NIST 800-16 Uncovered

I received an email indicating that I needed to take some training as a result of the publication, NIST 800-16. This is actually one of the oldest NIST IT security publications. But when I went back and read it again, it really does lay out some very concrete and specific training requirements for different roles within an organization. Since I'm a Program Manager, I'll cover the training objectives for that profession, but know that similar programs exist for Auditors, CIOs, Contracting Officers, CORs, DBAs, System Owners (business), FOIA Officer, HR, Network Admin, etc. Almost every role-type in a large IT organization has a Training Matrix. You can find the matrix for your job-type in Appendix E.

For Program Managers, here is ours:

So there are 15 different IT security-related competencies that we are supposed to master as Program Managers. Let me take a moment to go through each of these cells and pull out the behavioral outcome.

1C - Individuals responsible for the design and development of automated information systems are able to translate IT laws and regulations into technical specifications which provide adequate and appropriate levels of protection.

2.1A - Individuals involved in the management of IT security programs are able to understand principles and processes of program planning and can organize resources to develop a security program that meets organizational needs.

2.2A - Individuals involved in IT security program management understand and are able to implement a security program that meets their organization’s needs.

2.2D - Individuals who are responsible for the implementation and daily operations of an IT security program have a sufficient understanding of the appropriate program elements and requirements to be able to apply them in a manner which provides adequate and appropriate levels of protection for the organization’s IT resources.

3.1A - Individuals with management responsibilities are able to identify steps in the system development life cycle where security requirements and concerns (e.g., confidentiality, integrity, and availability) need to be considered and to define the processes to be used to resolve those concerns.

3.1C - Individuals responsible for the design and development of IT systems are able to translate IT security requirements into system level security specifications.

3.2E - Individuals responsible for review and evaluation are able to examine development efforts at specified milestones to ensure that approved safeguards are in place and documented.

3.4A - Individuals with management responsibilities are able to oversee the implementation and deployment of an IT system in a manner that does not compromise in-place and tested security safeguards.

3.4B - Individuals with acquisition responsibilities are able to ensure that the system, as implemented, meets all contractual requirements related to the security and privacy of IT resources.

3.4C - Individuals responsible for system design and/or modification are able to participate in the development of procedures which ensure that safeguards are not compromised as they are incorporated into the production environment.

3.4E - Individuals responsible for review and evaluation are able to analyze system and test documentation to determine whether the system provides adequate and appropriate IT security to support certification and accreditation.

3.5A - Individuals with management responsibilities are able to monitor operations to ensure that safeguards are effective and have the intended effect of balancing efficiency with minimized risk.

3.5B - Individuals with acquisition responsibilities are able to understand the IT security concerns associated with system operations and to identify and use the appropriate contract vehicle to meet current needs in a timely manner.

3.6A - Individuals with management responsibilities are able to understand the special IT security considerations and measures required during the shutdown of a system, and effectively plan and direct these activities.

3.6D - Individuals responsible for IT system operation are able to develop and implement the system termination plan, including security requirements for archiving/disposing of resources.

Each of those cells is further broken down into Beginning, Intermediate and Advanced competencies. When you review these, none of them seems excessive, or out of control. In fact, most of these seem consistent with what we need to do every day, well, except for the last one, it is very rare that we terminate a system. But for the rest of them, yes, these should be part of the baseline competencies that we expect when you are performing in that role. It is not appropriate to expect everyone to be in the Advanced category for each competency, but I would expect that at the full performance level in the job, you probably should be close. When you go to refine your Individual Development Plan, you should establish a baseline for your mastery of these competencies and measure your progress over time.

Technical Reference Model

A conversation from a couple weeks ago has been festering in the back of my mind. I was speaking with someone about Technical Reference Models (TRM). The TRM is the most detailed aspect of the Federal Enterprise Architecture (FEA). The conversation I had was to compare the current TRM that I currently work under with the TRM from another Agency like HUD.

My current TRM provides very specific visibility into the various technologies that are utilized for systems and applications in the Agency. The HUD TRM is not tied to any particular system or application. But it is not generic, it is exhaustively specific.

My point in the discussion was that the HUD TRM is more useful, but I couldn't articulate why I found it to be more useful until today. The HUD TRM is prescriptive. In the HUD TRM, if you want to do something, it prescribes the technical parameters in which you are able to operate. The Agency TRM that I use today is descriptive. It reflects what we are using, but it does not constrain what technologies we could consider to do the job.

I like the HUD model better because I can come up with an endless supply of solutions to meet a technical challenge. But the solution that serves the Agency BEST is the one that is sustainable within the organization. We increase the opportunity for sustainability by leveraging the technology stack that is used to meet other needs as well.

A Man of Many Hats

Sometimes the corniest things are the best. I have an application that we're deploying for one office this weekend and we began the development for the second office this week. The second office naturally wanted to see what the first group did and the trajectory of their baseline application. Let me say that I was very reluctant in doing this because the first second I show it to them, their ideas will be shaped by what they see. Thus in my utopia, I would have been able to work with them on requirements and generate a design independent of what anyone else has done. But I wasn't going to win that argument so I relented and had a little fun along the way.

The application is essentially a workflow system built on SharePoint. My first demo was with the stakeholders and it went fairly well, but I saw that I had to keep pointing out to them the instances in which I was performing in a different role. There are 5 main roles and it is easy to get confused about which actor is performing because it was just me doing it all. Thus, for the demo that I had to deliver to all of their bosses on the second day, I went to the party store and bought a bunch of hats.

As you can see, when I switched from one role to the next in this meeting we had a completely different experience. Not only that, it was fun. The Directors all appreciated the experience and I think they came away from the meeting with a good understanding of the capabilities that we have already built, I hope they also understand that their solution could also be radically different depending on their needs.

Federal Procurement Not Ready for Web 2.0??

I regret that one news source seems to be the victim of my criticism more than others, but I have an issue with their reporting. I read an article today from Federal Computer Week contending that Federal Procurement is Not Ready for Web 2.0. I will take exception to this article on two fronts. First, I think that procurement is indeed embracing aspects of Web 2.0 and second, I think the author of the article doesn't understand what Web 2.0 actually is.

FCW has reported about GSA using a Wiki and their Better Buy experience. I know some of my peers are doing some interesting things, but I'll argue with this point strenuously. First, I'm using a Wiki to achieve consensus with a big work statement that my team is currently developing. This has been a great experience to get people to read and shape how they want to have the work performed. Second, I personally used LinkedIn to advertise an acquisition that I was in charge of. I can't take full credit, but I know that we had more offerors for this solicitation because of my marketing. We received 20 good proposals for the work and it was a difficult process to identify the best. So, yes, I think the federal sector is embracing Web 2.0 concepts to help acquisition and procurement.

However Web 2.0 is not just citizen involvement. That can be one audience that leverages Web 2.0 technology, but Web 2.0 is more centered around the people who are concerned with something having the ability to shape it and change it. Opening the doors to the public may not be the best scenario. A lot of the work we perform is not visible to the public, so I wonder how much utility can be gained from including a public input into my types of acquisitions. The author of the FCW article seems to think that Web 2.0 equates to citizen involvement. That is not correct. Web 2.0 uses technology to allow transparency and to build consensus. The stakeholders on these activities may or may not be the general public, it depends on the purpose and the content.

Awesome Use of a 2.0 Tool

I stumbled across this and am compelled to write about it because it is a perfect use of a Web 2.0 tool. Each system or application must be updated with releases over time. Notifying the user community of upcoming releases and the content of those releases is a burden. Granted, it isn't an incredibly difficult burden, but it is something that must be done.

For this reason, I have to say, hats off to the team over a Grants.gov for figuring out that a Blog is an excellent mechanism for communicating with the user community. Seriously, they use the same type of blog that you are reading right now. Check out their blog for the Grants.gov system at http://grants-gov.blogspot.com/

You can read it for yourself, but the operational status, user documentation, and scheduled downtime and release history is available for perusal.

Market Analysis

A friend of mine recently wrote a blog post about performing a market analysis for the business she is starting up. It got me thinking about a struggle I've had for a long time. This is one of the barriers that prevents the same type of lean efficiency that the commercial sector can drive. What would a market analysis for a government agency really look like?

Mind you, government agencies are very good at putting together mission and vision statements as well as strategic plans. But we lack competition that is the engine of efficiency. Think about it like this. Any company, like Google or Apple has their unique competencies and resources. The profitability they earn is from how they take some of those unique competencies and turn them into core competencies and leverage them differently than other businesses. Google does this different from Apple, who also does it different from Microsoft who also does it different from Sony and so on.

Each of these companies must be disciplined in that they focus on building up competencies that are core to the organization and don't waste energy on building up competencies that are outside of the core. To bring this discussion around, the Market Analysis is about winning in a zero sum contest (for someone to win, someone else must lose). The market analysis should tell you how many organizations are delivering that product or service, how they compete with each other (value vs. price).

But here is the problem with a government agency, we're not competing with anyone. Don't misunderstand, I'm not promoting A-76, but I think that some areas of specialization would help us to identify those aspects that should represent our core competencies and we should focus on building up those competencies while off-loading things that aren't core. Those trade-offs will differ from one agency to another.