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.

Best of all, they reached back into ancient history, and asked me to moderate a panel Friday, September 9th, from 10:15 – 11:15, entitled Moving Into the Cloud – Practical Experience.

We will four great panel members:

• Fred Whiteside, NIST; who will focus on the Government policy issues
• Wolf Tombe, Customs and Border Protection, DHS; who will take the perspective of the Government implementor
• Bob Hansmann, Blue Coat; who will discuss what it is like to be a commercial provider supporting cloud initiatives
• Dmitry Sokolowski, BAH; who will talk about the issues in providing support as an internal to Government consultant

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.

A few people asked me to post my presentation, but I have found that my current job as the COO at Powertek Corporation has caused me to miss many of my self-imposed deadlines for doing many things, including updating my blog.

However, has now been overcome, at least for a few moments, and here it is.

UMUC Slides 

My talk was divided into four parts:

• Context where I discussed what I call First Principals, what I feel are the underlying causes of much of the technological disruptions happening these days
• Some thoughts on security trends, after all this was a Cybersecurity Symposium
• Comments about the demand for security professionals, after all this also was a Job Fair
• Ending with some thoughts on the goals for security and some general advice

I think the slides are pretty self-explanatory though I keep hoping to turn some of them into individual blog entries.

I had two key pieces of advice.

First, I related an old joke by Steve Martin that talked about how to make a million dollars and not pay taxes. The first step was to ‘find a million dollars’. I find that many proposed solutions to security, well, actually to almost anything hard is the functional equivalent of that first step.

Second, I told them to remember that the primary mission of almost every organization they will work for is NOT security. Because of that fact, one of the primary jobs of a senior security professional is to learn how to articulate the reasons for security investments in the context of the actual mission goal. Otherwise, organizational senior management will not make the right decisions.

In the Pentagon that joke morphed. Whenever someone wanted to get additional budget, the reason was to ‘Deal With China’. Well, in fact, maybe that is still true.

In technology today, the current budget justification phrase is ‘Cloud Computing’. Except in this case, exactly what Cloud Computing is or what it can do is even less clear than normal. On the other hand, that lack of clarity means there are lots and lots of meetings, seminars, and conferences that deal with trying to define Cloud Computing and provide advice on what to do about it.

In that context, I was on a panel Monday, May 3, that discussed Cloud Computing and the kinds of new skills that would be needed to support Cloud initiatives, http://events.1105govinfo.com/Events/Cloud-Computing-Summit-2010/Sessions/Monday/CC4.aspx.

I had three major themes.

My first theme was that people tended to mean one of a number of radically different concepts under the general topic of Cloud Computing.

Many actually were talking about consolidating multiple applications on a fewer number of servers – virtualization. It was this step that accomplished much of the savings, if there were to be any, from Cloud Computing. In fact, it was certainly possible to do server consolidation and application virtualization without actually implementing anything that actually was ‘in the Cloud’.

Others used the term Cloud Computing to putting applications on the Internet; in the web. This approach is also often described as Service Oriented Architecture, SOA. I am probably not capturing all of the nuances of SOA but to me this basically means taking a program which traditionally was self-contained and isolated and treating it like a service which others could access or integrate into a larger set of combined services. Doing so efficiently requires writing programs a bit differently, adding the ability for a service to be discovered, that is found by others, and adding the capability to expose aspects of the service to others.

SOA in the end requires not just technology change but also cultural change. To be most effective it requires an organization to be much more collegial and standards based in how it designs and develops software.

Finally, some people meant having applications, or aspects of an application such as the platform it runs on, provided externally; that is, through a cloud. The big challenge here is that when using only internal resources it is possible, though in my opinion unwise, to get by without taking the time or applying the necessary rigor to develop service level agreements (SLA’s) for all of the aspects of your system.

You can tell if people are working hard by peering over their shoulders. You can measure performance by users calling and yelling at you, and dynamically reallocate resources by yelling at someone down the hall.

However, when you move a resource out of your internal operation it becomes absolutely critical to develop robust SLA’s to manage your provider’s performance and define your expectations. It turns out that this is very hard to do especially in areas that historically have not been defined in very precise terms such as security or privacy. This is, again in my opinion, one of the major underlying reasons why there is such resistance to moving applications to the cloud.

My second theme is derived from that last point. It was always useful to create business architecture’s to drive technology development. While it might be inefficient, it was historically possible when everything was accomplish internally to ignore that benefit and instead do what was in effect the opposite approach, develop technology solutions that ended up impacting the business.

However if an organization wants to move to the not-well-defined cloud, it becomes necessary to define the business architecture’s and business goals associated with the applications. Without that definition, the likelihood of achieving the promised benefits associated with Cloud Computing are highly unlikely to be achieved.

My third theme was that the major human capital impacts were:

• Technical and operational IT assets were likely over time to move to external service providers and away from user organizations
• The demands on procurement and legal professionals were going to change as their responsibilities became more and more ‘horizontal’ between organizations and their providers of service and less ‘vertical’ supporting internal hierarchical organizations
• The importance of technical staff who also were comfortable with business issues would dramatically increase.

Federal Computer Week, http://fcw.com/Articles/2010/05/04/cloud-computing-implications.aspx, covered the panel.

“Welcome to the first Upstate CIO Conference, where CIOs from Upstate New York will connect, discuss industry trends and emerging technologies, and inform course content for information executives.

The Upstate CIO Conference is a one-day conference, held on Friday, April 16, 2010, at the School of Information Studies (iSchool) on the Syracuse University campus. The conference brings together Upstate CIOs and information technology professors to explore how academic research and professional experience come together to create innovative solutions to industry challenges, create industry trends, and educate professionals who can meet the needs of the 21st century global workplace.”

I was invited to give the keynote for the conference and to serve on a panel focusing on IT Governance. My keynote will discuss my thoughts regarding governance and how it differs between the private and public sectors. I’ll also cover what I call First Principals which are some of the key trends that are underneath some of the current technology trends.

I have included a copy of the slides below. In the interests of full disclosure, I also serve as an adjunct professor at the iSchool teaching graduate distance learning classes related to CIO Management and Cyber-security Policy.

Upstate CIO Conference Slides

The link to the conference site is: http://ischool.syr.edu/newsroom/cio/conference.aspx.

I discussed two topics under the topic of Bringing Governance, Performance Management, and IT Together.

Here is the presentation:

My Potomac Forum Presentation

The presentation is divided into parts.

The first part discusses my thoughts about what should we are trying to do with the Open Government initiative. I am a very enthusiastic supporter of these initiatives.

My major point, however, was that much of what has gotten public attention such as Transparency or externally published data sets are not the goal, it is what they are intended to accomplish that is the goal. Specifically, we want to cause something to happen that would not have happened if they were not performed.

As one of the other speakers noted, if this only became a compliance exercise then we would not be accomplishing enough.

The second part of the presentation dealt  with how I attempted to use transparency and a status dashboard at the US Department of Transportation during my last year at the Department to improve oversight of cyber-security status. The approach turned out to be partially effective.

Our ability to see into the various networks, most of which were independently managed, improved a great deal. However, I was unsuccessful in setting up a process that carried over across the chasm of the change in Administration. I indicated some of the lessons learned and how I would have improved our approach.

My focus, as usual, will be on the strategic reasons behind the movement to SCADA. Oops, perhaps I should back up. SCADA is an abbreviation for Supervisory Control and Data Acquisition. It usually is used as a catch-all term dealing with computer controlled equipment or machinery (or plants or smart grids or, well you get the idea).

Many of these systems were controlled individually by locally provised systems and thus security, while relevant, wasn’t the most critical factor when designing such solutions. Now that many of these systems are managed over the Internet and an increasing percentage of what most would consider our/US economic critical infrastructure touches these systems, cyber issue have become a very hot topic.

So my presentation will focus on why this is happening and also touch a bit on some of the issues the Government is facing in this space. The second presenter from CSC is an industry expert in the utility, chemical and natural resource market and will provide some more detailed oversight and advice.

I adapted some of my past talks on this issue starting with my standard discussion about transaction cost economics and the internet and then push on to cloud computing.

I have started to try and generalize the concept of cloud computing and wanted to get some feedback from anyone who cared to give it regarding what I wrote up. This does NOT include the second part of the presentation which I mention above.

Dan’s SCADA Presentation

My thought is that in a sense every computer and in fact in a broader sense every aspect of an organization could be looked at as being part of a private, community, or public cloud. Your desktop could be considered a small, generally unoptimized private cloud for example.

For the purposes of this presentation, each ‘thing’ has a governance question relating to how decisions are made and a security question relating to how security is provisioned or at least who is responsible for the provisioning of it.

The purpose of this thought experiment ties back to my premise as to why cloud computing has taken off, transactional cost economics + some technological developments, and the difficulty in avoiding these implications.

The whole thing needs work but I think the direction I am heading is increasingly clear.  All feedback welcome either as comments to this post or as emails directly to me.