If you have been at a recent Washington Capitals hockey game when the opponent scores a goal, you know the crowd routinely shouts out “Who cares!”

Last week, Steven VanRoekel, Federal CIO, released the long awaited OMB plan for the Federal Risk and Authorization Management Program, or FedRAMP; which reminds me to be thankful for pronounceable acronyms. The purpose of FedRAMP per the implementing OMB memorandum, is to “provide a cost-effective, risk-based approach for the adoption and use of cloud services”.

So were I a federal CIO, which I was, or an executive working for a provider to the Federal Government, which I am, what are the short- and long-term implications?

First, and most important, I think there are short- and long-term implications, which is not always the case with long awaited announcements and OMB produced memoranda.

However, I suggest the longer term implications tie more to the general topic of infrastructure rationalization than focusing specifically on the ever popular and impossible to avoid ongoing cloud frenzy.

It has long been my contention that while the IT focus in commercial organizations should be top-down to be most effective, in federal government it is the opposite: better off focused on a bottoms-up approach.

This difference reflects how funding, or revenue, is achieved.

In a commercial company revenue comes in from customers, is filtered through a sales organization and the decisions are controlled by executive leadership. IT leadership focuses on using the defined strategic goals to drive derived IT goals down into the rest of the organization.

In a government entity, funding comes through the appropriations process, and except in very rare circumstances, such as the Veterans Administration, is associated with the individual components that make up larger agencies or department, rather than with the overall mission of the department.

The real value of initial cloud implementations is they represent the next big step in allowing federal CIOs to get a handle on what IT provisioning is going on within the organizations.”

Because of this, the first hurdle for government CIOs is overall situation awareness; discovering what IT assets exist and figuring out how to put in place configuration management to keep track of those IT assets.

To just take one example, when OMB started pushing to consolidate data centers, it took months or longer to get an accurate inventory of how many data centers there were, let alone put together a plan to consolidate them.

Reducing costs is a reasonable goal to associate with cloud computing. Be warned that recent articles question whether cost savings will be large as some are articulating. See, for example, the discussion I participated in this last Friday on the Federal News Radio Countdown, hosted by Francis Rose.

The real value of initial cloud implementations is that they represent the next big step in allowing federal CIOs to get a handle on what IT provisioning is going on within the organizations. Every application that is moved to the cloud is one that now is visible to and can be managed and measured by the CIO. Consistent security approaches can be taken. And it is the inconsistencies, not whether an application is internally hosted or externally hosted, that lead to security weaknesses.

There are a few additional specifics from the OMB memorandum that I wanted to note.

First, the process still has some time before it will be put into place. The goal is to have the FedRAMP PMO, to be run by GSA, operational no later than 180 days from issuance. This follows interim steps including establishing formally the list of security controls, creating a Concept of Operations, and creating a charter for the Joint Authorization Board (run by DoD, DHS, and GSA) dealing with governance.

Second, it will interesting to see how robustly the effort will be funded over the next few years. Congress has not been consistently supportive of shared service implementations. From my stint at DOT, I remember the difficulties that OMB had keeping the various eGovernment initiatives sufficiently funded.

While outside the scope of this write-up, I contend that one reason that DoD continues to make progress in this area is because of the existence of a home, what I refer to as a “center of gravity”, for managing the resulting shared infrastructure, namely DISA. While I have nothing but the greatest admiration for Richard Spires and Casey Coleman, running shared services is not currently the primary mission of either DHS or GSA respectively.

Third, I found it interesting that both the CIO and the chief financial officer need to certify together the list of all cloud services that cannot meet FedRAMP security authorization requirements within their agency. The dividing line between what is expected from CIO’s and CFOs regarding program management is not always clear cut, and is made even less clear when the CIO has been folded underneath the CFO.

In April, 2009, I asked the question “Why are 42 or so different procurements now looking at clouds?” I was quoted as saying that I thought that instead cloud computing could be offered in a way … in which any federal agency can access a handful of major … contracts.”

And now a little over 2 ½ years later, we are only six months away from saying “You can.”

Daniel Mintz is chief operating officer of Powertek Corp. He served as CIO of the Department of Transportation from 2006-2009.

The opening night keynote speaker Scott Klososky, presented some interesting points but I felt left out some key issues; probably a bit of an unfair feeling since he only had an hour to cover a lot of material.

I wrote up my summary of what I thought was missing at AOL Government where I am a contributing blogger:

http://gov.aol.com/2011/10/25/reflections-at-elc-why-klososkys-keynote-missed-the-mark/

The first, and as of now only, comment came from Scott Klososky himself who graciously said he agreed with most of my points.

It occurs to me that a lot of my writing starts with that phrase. I haven’t yet decided if I use it because I learned a lot there or because I think people will be more likely to listen if I start a discussion with it.

Regardless, when I was at the Department of Transportation we would do emergency training. What if there was another 9/11 attack, what if there was a cybersecurity attack, and so forth. Some of us got to go to semi-secret locations and stay underground, walk down long corridors with lights along the top casting shadows, lots of clacking of shoes on the floor, eating together in the cafeteria, periodically getting messages of incident updates, doing reports, watching the pretend (or real) Secretary, talking to the (always) pretend President, and so on. It was pretty cool, like getting to go back to camp for a day. Some of the exercises were pretty extensive involving multiple Government agencies including in some cases State and Local governments.

I was reminded of that recently when the great Washington Earthquake of 2011 hit. Many Federal agencies and departments practice implementing their COOP training. For the uninitiated, COOP stands for Continuity of Operations. COOP planning is actually pretty serious stuff dealing with how to ensure an organization can keep its essential functions running in an emergency. When the organization is one that many citizens depend on, COOP planning is very important.

In any event, at one Government agency, when the actual emergency happened, the earthquake, everyone scattered to leave their building.

On a side note it was only when some of us were outside, like me, that we learned that we had done exactly the wrong thing according to FEMA. Evidently I was to fling myself under a heavy table or find a load bearing door or something similar and stand there, so as the ceiling fell in, it would not fall on me. My instinctive reaction of getting off the second floor before the building collapsed was completely wrong, thus proving once again that no one should pay attention to me when an earthquake occurs.

Back to the agency in question, when all of the IT staff involved in COOP support tried to get to their COOP places, the building guards, who evidently weren’t involved in the emergency practices, and also evidently were not staying under a table, would not let them do so. After some argument, the IT staff gave up and left. So much for COOP training.

So what are the lessons to be learned here. I have two (of course).

First, in my opinion, emergency training is, as are most things, upside down. We spend all our time practicing the procedures we have set up to deal with an emergency. While this is useful and should continue to be part of emergency training, in a real emergency it is the unexpected that happens. It is, in fact, because of the almost certainty of unexpected circumstances that an event becomes an emergency.

Instead in my opinion, the major focus of emergency training should be to help people figure out what to do when they do not know what to do.

In true emergencies, everything breaks down. The expected leadership doesn’t show up and/or isn’t able to communicate effectively to the people who need advice and leadership. The congregation point where people are to meet becomes inaccessible. Something happens that is not in the plan at all. Chains of command fall apart because many of the links are gone.

In all of these cases, actions still need to be taken; collective behavior implemented; goals defined; and problems solved. People who are not prepared to deal with what to do when they do not know what to do, panic or take what often in retrospect are irrational paths of action. It is these issues that emergency training needs to focus on more than it does currently.

My second lesson is that much of this training requires some kind of virtual environment. One of the biggest problems when an emergency hits is problems with communications. However with almost all emergency training if you kill the communications, the training exercise would just stop. The training participants, and the people providing direction for the exercise, would not be able to interact.

In a virtual environment on the other hand you can do almost anything. If a major part of such training is to get individuals used to situations where they have to improvise as a stated goal, virtual environments become a much more plausible way to accomplish this.

George Washington University Slides on Cyber-Security

In the last post I returned as I often do to the question “How to be secure when each component of your solution is itself insecure?”. I find that most practitioners, and in particular their management, are in denial on this issue. While my first suggested step which is to practice security hygiene is useful it does not help against a determined attacker.

While I am not sure if anything short of not connecting to anyone will work all the time, two possible approaches seem promising.

First, is the concept of an OODA loop. OODA stands for Observe, Orient, Decide, Act. It was developed by a US Air Force Colonel John Boyd who has since passed away, there is a rich set of literature on the topic for those interested in reading more. My slide 19 has an illustration of how this approach works at a conceptual level.

My simple interpretation is to be able to change faster than the bad guys are able to penetrate.  It was Boyd’s contention that in modern warfare the adversary who has the faster OODA loop would generally win. With cybersecurity, as with all security, the attacker generally has an inherent advantage of motion over the defender. Thus it requires serious planning to have an architecture that is agile enough to change and adapt and still remain operational.

A second approach is to use a biological construct. For example, your body has many viruses wandering around inside it at any point in time, yet in general people are healthy and the body defends itself well against these viruses – though with some help from time to time from a doctor.

The concept of having loosely coupled systems working together, like the cells in your body do, is called being Stigmergic systems, described in my slide 20.

In the class I described ants as an example of a Stigmergic system. An ant which finds food leaves a trail that other ants then follow. While none of them ‘talk’ directly to each other, they work together indirectly. This kind of swarm intelligence is characterized by fast adaptation, living OODA loops.

Once again, this kind of capability would have to be built into systems in order to work, it would require a completely different approach to system design.

I considered each of these merely thought exercises, I do not have much personal experience with either. However, earlier today when I was working on this post, I ran across an article about a Wake Forest University professor who is working on digital ants to check networks for viruses, so perhaps Stigmergic systems are one serious way to go:

http://www.tgdaily.com/security-features/56255-digital-ants-check-networks-for-viruses

Quoting Professor Errin Fulp: “As they move about the network, they leave digital trails modeled after the scent trails ants in nature use to guide other ants. Each time a digital ant identifies some evidence, it is programmed to leave behind a stronger scent. Stronger scent trails attract more ants, producing the swarm that marks a potential computer infection.”

And anyway, who wouldn’t want to be able to use the word Stigmergic in casual conversation at a cocktail party. Of course, that would imply that a Stigmergic designer would get invited to one.

George Washington University Slides on Cyber-Security

I wanted in this entry to talk about my thoughts on what organizations should consider when dealing with cyber-security issues. My discussion here is based on slide 18 – Thoughts On What To Do (duh). I will cover the final slides in a following entry.

I believe a lot of people start with the wrong premise. They assume that the goal of cyber-security implementation is to end-up with a secure systems architecture. In fact, at least in my opinion, that goal is unrealistic and planning with that objective in mind can lead to negative results.

Money is wasted playing what I refer to as whack-a-mole security, chasing after incidents that have already happened, and spending too much of an organization’s limited resources defending everywhere when the bad guys only need to find one vulnerability.

As I write “The fundamental question is how to be secure when every component is insecure.” I suggest two parts to the response, the first of which I discuss here.

As step one, practice security hygiene. Make sure that you have not made it easy for your systems to be penetrated. The reason we put locks on the doors of houses is not because this makes it impossible to break in, but at least we make it hard for the casual intruder and we slow them down to increase the chance of apprehension.

Much of what I talked about while I was at the Department of Transportation is in fact being accomplished, better than I did for that matter, currently in the Federal Government. There is an increasing movement away from the static oversight of FISMA report creation to the dynamic oversight of real-time situational awareness.

You cannot defend something when you do not know what is happening. Integrating sensors into your network or even better developing systems that themselves provide situation status are a big plus.

Second, it is important to build security into the budget process. My not well-formed thoughts at DOT were that depending on the categorization of software projects, low/medium/high, from a criticality (or some other kind of measurement) there should be a percentage range of the total budget that was required to be associated with security explicitly with a separate plan as to how the money would be spent. I found that when I went back and looked at systems that had been developed at DOT before I joined, the security investments were often not documented and when documented, the percentage of the total expense varied very dramatically.

The key point here is that security dealt with after development generally has little value and even then costs much more than when designed into the system development process.

Third, it is important to be as transparent as possible. There is a tendency to try and hide security status with the excuse that this makes a system more vulnerable by exposing weaknesses that would otherwise not be known.

This premise is generally wrong for at least two reasons. Bad guys will eventually find all of these weaknesses anyway; they spend more focused time doing so then most of us have in protecting. Most important, it is only with transparent exposure of status that we are likely to focus on fixing problems.

It is just as likely that resistance to transparent exposure of status is fear of oversight more than security protection. Management visibility is the biggest cure for problems.

This last issue is representative of the broad issue of information sharing versus information protection, a topic I have discussed many times. I remain convinced that while both have to be paid attention to, organizations that want to be successful in accomplishing their mission need to lean to the information sharing side of the argument.

Next will be my wrap-up of the presentation continuing the conversation about what to do about security while having inherently insecure systems.

Since the classes I teach at the University of Maryland and Syracuse University are on-line distance learning, it is always a treat for me to have actual live students in the same classroom as I am to interact with. This year the exchange of information was really great, Dr. McCreight has a wonderful class. For all of these activities, I deal with what I call the “avoidance of appearing like an idiot in front of people syndrome”, which forces me to at least to scan and keep up with the literature before the class is held.

While I am one of those people who learn best by doing, being able to talk to and/or discuss with bright students is still very helpful and fun to do.

I have posted my presentation below and during the next few weeks hope to write a few columns based on the later slides, of course I have still not written my last two posts I promised on cloud computing, as as usual what I plan to do with this blog and what actually happens continues to diverge.

GWU Cybersecurity Presentation

On slide 13, I put a quote from Professor John Mueller, who is the Woody Hayes Chair of National Security Studies at Ohio State University, parenthetically a title which gives one pause for a number of reasons. I really like to read Professor Mueller’s papers not because I agree with all of them but because he is a contrarian. It is from those people who do not follow the crowd, that much can be learned.

Professor Mueller basically claims that the ability to predict what a terrorist would do is so small and the cost of protecting everywhere so high that we need to rethink our entire approach to national security. He has written a number of papers on this subject including doing mathematical analysis of the value of the lives saved or lost, which I expect makes some readers uncomfortable, but in the end makes a pretty strong case that we are throwing a lot of money down a bottomless well and not achieving very much with the investment.

I do not have enough expertise to figure out if he is right or wrong, but wanted to mention the related issue which his premise touches on which is prioritization.

The lesson from Professor Mueller is that prioritization in order to work has consequences. That is, when one decides what is a high priority and what is a low priority, then more attention and resources need to be invested in the high priority items – this is the easy part – and less attention and resources need to be invested in the low priority items – AND THIS is the actual hard part.

Interestingly to me, there is lots and lots of attention in the Government in how to create and implement performance based measurements. Doing so in the Government has difficulties not present in commercial situations in large part due to the less clear goals or at least less agreed to goals that a Government program may have. But as hard as creating a performance based approach is, in reality in the end it is the easy step. Much, much harder is acting on the results.

Taking ownership for NOT dealing with a low priority item is not a goal for most Government managers. If you do so and something goes wrong unexpectedly with the area you didn’t get to, you will own the negative results which is not so hot in our blame-first, analyze-second culture. Thus regardless of how we prioritize and how we measure performance there is a tendency to peanut-butter the investments, spreading them around so everything gets at least some attention and none, including the potentially identified high-priority items, get solved.

The lesson from this to me is that it is as or more important to focus on getting agreement from all stakeholders, and their management, as to how to prioritize and the implications of prioritization as it is to create the measurement systems. If the implications are not agreed to up front in a public fashion, then even after performance is measured, you will still end up not acting on the results.

My conclusion is that I do not and therefore wanted to reuse a few old ones.

While there will be a lot of closing the barn door after this particular horse has left action steps, in my opinion the bigger message is to reinforce the premise that the battle between information protection and information sharing is over and done with. Information protection has lost. I remain convinced that security planning focused purely on protection, in particular focusing on periphery protection, is a waste of time and money.

The underlying reason remains that the value of sharing information, or conversely the penalty of not sharing information, is so great for any organization of any type today that this need will drive decision making. Unless an organization is prepared to make the kind of investments that the Government does in setting up a structured set of security levels, e.g. confidential, secret, top secret, and so on, then it not possible to cause corporate culture to both share and protect very well at the same time. And even the Government security apparatus with its enormous associated investments leaks information, WikiLeaks being only the most recent example.

If I ran the security world I would focus on the following:

• Security hygiene
  • Achieving situational awareness
  • Implementing security policies associated with situational awareness, see my post http://www.ourownlittlecorner.com/2010/12/18/brief-thoughts-on-security-and-other-it-policies/
  • Identify the data I really want to protect and focus only on that limited data, if more than ‘limited’ rethink what you want to protect
  • Create a strategy that takes into account that no individual component of your system is impenetrable
    • If concerned about availability – consider a biological construct with multiple copies of your applications and data available; e.g. the human body works fine, mostly, even with viruses all over the place
    • If concerned about penetration – consider increasing your OODA loop speed, observe-orient-decide-act, http://en.wikipedia.org/wiki/OODA_loop

Each semester I find I learn a great deal from reading the papers and interacting with the students about them.

I have drawn three conclusions about policy creation from my past experience at the Department of Transportation, modified slightly from the current set of papers:

(1) Policies whose impact cannot be measured cannot be enforced.

(2) Measurements which are not created in some kind of automated fashion will not persist.

(3) Measurements which are not made visible don’t exist.

I have been part of a number of panels over the last few months which focused on the subject of Cloud Computing, the current state of the’art’, and as usual what barriers exist that need to be dealt with to make it easier to utilize. There certainly has been much written about it both pro and con and it remains a high-priority focus for the current Administrator and, in particular, Vivek Kundra, the Federal CIO.

For one of the graduate classes I am teaching this semester at the University of Maryland University College, the subject is touched upon as part of a broad look at technology changes and implications. The topic generated much comment by my students.

It seems to me that the subject starts from the wrong side of the discussion, the technology side. When the discussion turns to the impact, it starts at an important but not the most important concern, that of return-on-investment (ROI).

Today and in a number of future blog entries, I will talk about what I think are the current important issues associated with cloud computing. Today I start with what I perceive as a foundational issue, cost, but later in the week will move to what I believe are more important considerations and goals.

Note: I do not plan to rehash what cloud computing is, or is not, there are too many other write-ups that do this. Look at the National Institutes of Standards work on such definitions, I think it is pretty good.

SAVING MONEY. To me the least important, though I hasten to say not unimportant, goal of cloud computing is to reduce costs.

In the simplest sense, the provisioning of IT services costs money because of an overhead cost associated with buying computers and putting them somewhere as well as the operating costs of running them. When you spread that cost over more users then the cost per application usage goes down.

With cloud computing you have the potential, emphasis on the word potential, to achieve these savings by running multiple applications on the same computing equipment. This can be achieved when you use techniques to allow more than one application to run at the same time on the same computer increasing its utilization or when the peak levels of demand are different for each application, or both.

This much can be achieved by using what is called a private cloud, that is one that you run yourself. For organizations that have not centralized the provisioning of IT services, this one change can have a significant cost savings. The barriers to doing this are to some extent technical, it is necessary to gain experience in how to do this; but in large part cultural and organizational, it requires different groups within an organization to plan and work together.

Historically, computer usage in data centers is amazingly low, on average between 5 and 15 percent of capacity. By running multiple applications at once, using techniques such as virtualization, this capacity usage can usually be brought up to over 50% and often higher. This reduces the need for additional computing resources and cuts down on environmental costs such as cooling and power.

Moving to a more public cloud, which is one provided outside the organization, has the potential to achieve greater cost savings (maybe). Again looking at this in the simplest fashion, it spreads the overhead cost across still more users, with a public cloud perhaps in the thousands or more.

The other added advantage is that those organizations who have recognized that running data centers is not actually their core competency can out-source, currently a politically complex word, data center operations. On the other hand, organizations that do so need to develop a core competency of working with outside providers, which many organizations do not do.

It is interesting also to realize how many organizations want to move to externally provided IT resources because they feel they are too disorganized internally. This hope generally is not realized. There is an old saying that IT cannot organize a disorganized situation. I can promise you that outsourcing IT will not bring management controls to a situation where none currently exist. You first have to organize internally and only then look for outside provisioning. Electric power providers do not untangle the wiring in your house.

This last step, moving from an internally provided centralized IT provisioning process, private cloud, to an externally provisioned process, public cloud, is made still more complicated for Government due to security and privacy issues as well as fear of embarrassment issues; who needs to read in the Washington Post that your personnel system was hacked while sitting on some public provider; I speak from personal experience that testifying on the Hill about security issues is not why most people go into public service.

Having said that the first step, centralized provisioning, achieves a large percentage of the gain, and is worth working toward.

The other challenge associated with saving money is that many organizations do not do such a great job of tracking the costs which they are trying to reduce. Government organizations in particular often have in place rudimentary, or non-existent, cost accounting systems which keep track of all of the overhead associated with doing such work in-house. Thus the cost comparisons relate lower than actual internal costs against actual external costs. It is not a surprise that different organizations produce different conclusions.

I used to joke when I was at the US Department of Transportation that if you wanted to achieve a certain ROI I could help do so with 10 minutes and Excel.

To be continued …

First when I woke up I checked my emails for the two classes I am teaching through distance learning, at the University of Maryland University College, a capstone class for an IT Master’s program, and at Syracuse University, about Cyber-Security Policy.

One of my students at Syracuse University was taking the class for a second time because he was unable to finish it the first time. The reason he could not the first time was because he had been stationed in Afghanistan and he wasn’t able to juggle the time he had to spend out in the field with the time necessary to complete the class assignments. This, coupled, by the intermittent Internet access meant he was unable to finish the work. As a result I arranged with Syracuse University for him to take it again this year without additional cost and with no negative grade consequences (small things for a large sacrifice on his part).

This morning his email confirmed that he will have to redeploy back to Afghanistan this coming week. Since he will be based in Bagram, he is much more confident that he will have sufficient Internet access and thus will be able to finish the final weeks this time. His role is to provide IT support for Forward Operating Bases, which doesn’t sound like something most of us would want to do.

He thanked me for being so flexible. I thanked him for his service, I told him it was a continuing honor to have him in my classes.

After reading his email, I went and voted.

All of us should, people like my student are the reason we can.