Cyber Disruption Response Planning Framework
for State, Local, and Regional Entities

Adam Wehrenberg
Project Director
Regional Catastrophic Preparedness Grant Program (RCPGP)
Mayor's Office of Emergency Management (OEM)
City of Boston

Kevin O'Shea
Information Security Lead
URS Corporation

This transcript contains references to slides which can be downloaded from
A video recording of the live session is available at
MP3 format at
or in MP4format at

[Welcome / Introduction]

Amy Sebring: Good morning/afternoon everyone and welcome to I am Amy Sebring and will serve as your Host and Moderator today and we are very glad you could join us.

We have wanted to do a program on cyber response planning for quite some time, but we wanted to approach the topic from a comprehensive emergency management perspective, not just system security.  We understand that the folks in New England have been pioneers in this area, and we are grateful that they are here today to share their experience.

[Slide 1]

Now it is my pleasure to introduce Adam Wehrenberg, Regional Catastrophic Preparedness Grant Program (RCPGP) Project Director for the City of Boston Mayor's Office of Emergency Management (OEM). Mr. Wehrenberg is responsible for the oversight of catastrophic planning activities within the New England Regional Catastrophic Preparedness Initiative (NERCPI), which includes the Commonwealth of Massachusetts, the states of New Hampshire and Rhode Island, as well as the Boston and Providence UASI Regions.

We are also pleased to introduce Kevin O’Shea, Information Security Lead for URS Corporation who worked on this multi-year effort to regionalize the state and local response to a catastrophic loss of information infrastructure and communications.

Welcome to you both and thank you very much for taking the time to be with us today. I now turn the floor over to Adam to start us off please.


Adam Wehrenberg:  Good afternoon and thank you very much.  As Amy mentioned, I am Adam Wehrenberg and I am the project director for the Regional Catastrophic Preparedness Grant Program up here in New England.  Back in 2008 our executive committee identified cyber as one of the critical hazards that could severely impact government operations and the lives of our citizens.

We set out with this program to establish a framework for incorporating the physical effects of a cyber disruption with emergency management and public safety folks with the technical expertise required to understand these issues.  The resulting framework is what we’ll present about today.

I will take a few minutes to talk about the genesis of the project, the way we went about it and what our end state has been. Then I’ll turn it over to Kevin and he will talk about some of the specific lessons learned from the project management standpoint.  Kevin and the URS project team assisted us with technical expertise throughout the development of this framework so he will be able to provide some insight from that perspective.

[Slide 2]

We recognize this is an evolving concept and as reliance on cyber infrastructure increases in all aspects of society our cyber disruptions will evolve from mere inconveniences into major incidents with significant public safety ramifications. 

No longer is it just an aggravation that your email is not working but there is potential in a fully interconnected world that the SCADA systems or your control systems or simple things the public relies on to get by on a day to day basis may be unavailable and have some cascading effects with regards to their reactions.

Our cyber disruption planning project incorporates IT, emergency management and public safety operations to ensure a consistent approach to terminology as well as incident command structure and a common understanding of expectations and dependence.  As I said from the top we started thinking about this in 2008 with our executive committee identifying cyber as a critical hazard.

Originally we talked about cyber attacks as the hazard we wanted to work on.  The emphasis gradually shifted toward a cyber disruption response focus.  The primary reason for that is that the private sector owns and operates a majority of the critical cyber assets and the services on which the government relies and this project was focused on how to mitigate the effects of a cyber disruption.

From a government standpoint and continuity standpoint we are going to be required to manage response and the physical effects of that response regardless of what limited responsibility we may or may not have to secure those assets pre-event. 

That is how we ended up where we are.  There was some foresight that cyber was going to be potentially an issue to tackle and frankly from an emergency management standpoint we didn’t have the knowledge base to understand what we did not know.

[Slide 3]

From the emergency management standpoint, more than just email and file-sharing, our networks and systems are really important to our operation and the operation of our citizens.  Whether we are talking about traffic lights or power infrastructure, criminal history systems, communications—all of this stuff is routed through the majority of our IT infrastructure.

To maintain the continuity and operations therein we needed to understand what our reliance was on IT as well as what we would be facing if something were to go down.  It is a lot more than email and files.

[Slide 4]

For our planning process what we started out by doing was identifying our assets.  We all maintained critical infrastructure key resource lists—the basic most critical infrastructure we have in our jurisdictions.  We quickly realized our critical cyber assets were not necessarily aligned with the CIKR list.

What I mean by that is that the facilities that meant the most to us in terms of maintaining cyber infrastructure didn’t necessarily appear on those lists.  They may not have been known.  They may have been hidden in plain sight.  Specifically those assets which had critical functions for public safety functions were not necessarily on those lists.

After we set out determining what those assets were and prioritize them, we had to figure out what the risk was to those facilities.  We set out on a comprehensive risk and capabilities assessment program.  We identified what the current state was in terms of our ability to respond to anything that would occur at those assets.  Then we began integrating this information into our regional plan.

[Slide 5]

In order to pull people together and complete that integration we created what we are calling a cyber disruption team.  For lack of a better term it is the people you would want as an incident commander or an elected official at your right hand to tell you everything you would possibly need to know about your reliance and expectations for restoration surrounding IT.

We pulled together for their technical expertise, IT personnel, for forensics and intelligence information sharing purposes, law enforcement and for a structured incident response standpoint, emergency management.  This is really the core but a full developed cyber disruption team includes other people at the fringes, the private sector, federal assets, service providers and power companies.

The framework we created allows people to set up this basic framework and gives them a roadmap for integrating future asset owners or future capability owners.

[Slide 6]

To make this scalable the National Response Framework back in 2008 identified cyber as one component of ESF-2.  Sticking with that national model we decided that the CDT would be best incorporated within or alongside ESF-2.  Since we created a framework and not necessarily a specific operational plan we left it up to the end jurisdiction or end user to determine how they integrate it into their processes.

For some jurisdictions that was as an ESF-2A, if you will.  For some others it was a component within ESF-2.  We didn’t want to specifically spell that out and dictate that but that is the direction we gave it.  In addition to completing within an ICS structure, depending on the incident and depending on scope it could either fall under planning or an operations section but we wanted this structure to exist within the existing structure that people are already using.

We didn’t want to create an additional layer for response.  We wanted to merely put it into something that is already known and understood by the partners that would enact it.

[Slide 7]

What are we left with at the end?  We have created cyber disruption teams within each jurisdiction.  We have created this cadre of individuals within each jurisdiction.  It was adapted differently in each jurisdiction. 

In Rhode Island they have taken it probably the furthest of any of our jurisdictions.  They have emergency management IT law enforcement, higher education and private sector—all very actively engaging with one another to share this information and to train and exercise on this structure to make sure they are prepared.

Massachusetts and New Hampshire are also doing the same thing.  Those are our other two states. I still think Rhode Island has built this out the most clearly. 

We developed a regional cyber disruption response annex which is a high level document which sits on top of each of the cyber disruption team jurisdiction specific plans. It serves very basically to coordinate that function.  What we didn’t want was a very lengthy plan that would be difficult to use or implement.  The plan is very brief.  If you have read it or have had an opportunity to see it in another venue the plan is very basic.  It identifies the roles and responsibilities for regional coordination and identifies how these people are going to share information and provides a series of templated documents for facilitating conference calls and other types of coordination structures. It is very brief and to the point. 

We also created a training strategy.  If you were to take three years of your life to do online training you could probably get through the majority of it.  It is a very extensive list.  We identified throughout this process that there was a need to have IT terminology understood by emergency management.

The reliance they had on IT as well had to be understood by the emergency management and public safety folks.  Additionally the emergency management structures and public safety structure with ESF-2 and under the ICS structure—that basic ICS information had to be known by the IT folks. 

There were numerous opportunities for cross training that we identified in our training strategy and we called a lot of those out.  As a cyber disruption team matures you want to provide certain training to your IT folks about public safety and you want to provide certain training to your public safety folks about IT.

There is certainly plenty where they are both receiving the same delivery.  The last document we are left with is a resiliency annex.  This document really serves two functions.  One, it memorializes our processes.  If you developed the cyber disruption team in your jurisdiction you can understand or be reminded of the methodologies that we employed for assessing our databases or assessing our assets.

It will provide a start to finish process for understanding how we got to where we are.  For people who have already established the cyber disruption team and already gone through the process it is a reminder, a punch list for the future, in terms of refining your plans and procedures.

For jurisdictions that have not been involved in this one of our goals it to expand this as far as we can and provide this type of framework to as many people as possible.  The resiliency annex is a tool for them as well in that it helps to identify the step by step process we took and we were kind enough to leave out the rabbit holes we fell down.

Hopefully it will streamline the process a little easier for anyone new approaching this as opposed to some of the heartache we may have felt in development.  Hopefully it will save some time and aggravation on the back end for anybody new.

[Slide 8]

To call this project completed would be somewhat of a misnomer.  We look at this project as constantly evolving with goals at various timeline points from here on out.  After about a year, and we are just about at that point and maybe a little beyond it, memorializing gains has been completed through the completion of that resiliency annex.

As we continue to grow and as we continue to progress we want our cyber disruption teams to continue to mature, to identify additional members and incorporate them into their trainings or exercises, as well as provide this framework to additional states and jurisdictions.  It is scalable that anybody could adopt it.

After about five years what we see as a future success is if I can call on a cyber disruption team in the same way I can call on a tactical team or bomb squad.  FEMA has been working to create a typing mechanism for cyber assets.  When we started there was no typing structure from the federal level.

Where you could request a type two fire engine you would know the water capacity you were going to get—you can’t have the same classification on a cyber asset.  It did not exist.  From our standpoint if we can create a structure that enables that kind of sharing, be it of personnel or resources, that is the direction we would really like to go.

Additionally as our grant has ended and the ability to fund further improvements go away we look to centers for excellence that are popping up to help us continue this effort.  In Massachusetts, for instance, there is a group called the Advanced Cyber Security Center.  They have done a great job of incorporating public and private assets, higher education and federally funded research and development centers.

They have people looking at this from different perspectives and sharing information about threats in real time.  The more people we can get on board to understand the ramifications of a critical cyber disruption, the more buy-in we get over time.  It is really incumbent on cyber disruption teams and centers for excellence to help us continue the process.

[Slide 9]

I’m going to turn it over to Kevin to talk about some of the specific lessons learned from the project that we found at various points in the process.

[Slide 10]

Kevin O'Shea:  Thank you, Adam.  On lessons learned we are going to start here that one of the big questions we needed to answer is—what is catastrophic?  It is easy when looking at a Hurricane Andrew or Hurricane Sandy or Northridge Earthquake—it’s catastrophic.  It is immediately apparent.

When we talk about what a catastrophic cyber attack or disruption, that was a bit different.  We understand that if, for instance, you take the internet away for a month that would be catastrophic on a number of different levels.  What is the threshold?  Is it an hour, a week or a month?  In trying to determine that level it was difficult.

We worked around with our stakeholders and came down to a number of criteria.  One was sustained impairment to a critical business process—your inability to pay people or inability to write prescriptions in a hospital or something like that.  If that critical business function was impaired for a long period of time that would likely lead to being disastrous if not catastrophic.

It was also interesting that it was hard to map these secondary and tertiary dependencies and impacts.  We know that IT is heavily reliant on power and power is heavily reliant on IT.  We know that transportation is heavily reliant on IT, particularly rail.  We also know that power is heavily reliant on transportation.

When we look at these dependencies between sectors it became a little bit more difficult to map how an IT outage would be catastrophic because it may affect other sectors.  That was something that was complicating but it was an interesting thought exercise to work through.

[Slide 11]

It was easy to conceptualize events, incidents and disasters.  As an aside this was one area that the language barrier between IT and emergency management became obvious.  In IT an event is something that just happens on a network or machine—a login or logout and so on.  We only get to where we are mapping incidents would be something that requires intervention.

In the emergency management world we know that events are things that need to be managed.  Right there getting a room full of people from IT and emergency management together we already had a bit of a language divide.   But we were all in agreement on what a disaster was but looking at when does a disaster become a catastrophe? 

[Slide 12]

If we have a large hurricane or sustained denial of service or a worm or virus infection where you need to be rebuilding hundreds of desktops—sustained power outage—how long does the power need to be out before it becomes catastrophic?  With generators, maybe seventy-two hours—if we were without power for two weeks we would start to feel the pain and that would start to lean towards a regionally catastrophic event.

[Slide 13]

In looking at these low probability high impact events—what we would typically call the “black swan” events in emergency management—it was an interesting exercise for us  to work through what is a “black swan” event in the IT world or what is a “black swan” event in communications world.  What we found was if we did take away the internet infrastructure or communications infrastructure the impact was so great that even though it was low probability, it ends up being something that on a risk management level so large it really should be considered in a comprehensive risk management plan.

In attempting to look at what is catastrophic I would say that as a planning team including Adam we were overwhelmed with all the different situations and scenarios that can cause a catastrophic events.

[Slide 14]

What we looked at are all the different threats that can cause an outage.  When we looked at all these different threats and gamed out—a hurricane can lead to destruction of power lines which can lead to a power outage.  A hurricane can also lead to the physical damage of say a data center and that can lead to loss of availability to your local network.

[Slide 15]

When we start to map these out we found out that an infinite number of threats and scenarios led to a fairly finite list of effects.  This led to our next lesson learned which was the benefits of using something like effect-based planning rather than scenario or threat based planning.  So here are scenarios—loss of power, internet, and local equipment and so on—they really provided a finite number of planning scenarios that we could begin to address at a catastrophic level.

[Slide 16]

One of the benefits of effects-based planning was that it seemed to have the effect of bringing people to the table willing to talk.  We found when we used more mundane type of events and extrapolated a mundane event out to be a large event we got a lot of resistance to the idea.  If there was a large virus infection say, “We had a virus infection the other day and we took care of it—it wasn’t a problem.”

When we went to effects-based planning and we said, “I don’t care how you get there but let’s say you don’t have access to your desktops or you don’t have access to your server room.  What do you do?”  It seemed that the effects-based planning got people focused on action steps that could be taken in preparation and action steps that could be taken during response and during recovery and our meetings were more productive.

This is a lesson learned out to you in the community here if you are having trouble getting traction on difficult topics this is one approach that worked well for us.

[Slide 17]

One of the next topics was reliance on IT systems.  It was interesting moving through our stakeholders meetings how little the emergency management and law enforcement and even to some extent some private sector groups, how little they were aware of their reliance on the IT and cyber infrastructure.  By cyber I mean colloquially the collection of networks, servers and desktops that allow you to connect and operate on the internet.

We found that people had little knowledge of the actual reliance on these systems—the interconnectedness of these systems and how much that other sectors and critical infrastructures would rely on the internet.  This was a good wake-up call for all involved that your operations would likely be affected if IT went away.

It is worth having that conversation with IT to really get a good understanding about exactly what your reliance is.  For instance the radio systems—we kept hearing law enforcement say they had radio systems and they would be fine.  Many times on further investigation we would learn the radio systems at some point went on leased lines or the internet as part of a trunked radio system and that if there was some sort of large scale outage their radio systems might be affected.  That was something they didn’t know but throughout this process they became more aware of the reliance.

[Slide 18]

That is our lesson learned number three—it is really hard to conceptual, map and somehow articulate all the interdependencies we have within IT and communications across all our sectors and critical business processes.  Believe it or not, “I don’t know” can be a very real answer when you are looking at examining the interconnectedness in the effect of if we lose system A, what is the effect across systems B through Z?

Often times we don’t know.  It is not predictable.  That is why referring back to this effects-based planning because we weren’t able to adequately predict all the interdependencies one of our only solution is to say that at some point we have to plan for this system being down or disrupted in some way and then really focus on the effects—not always being able to map all the threats and vulnerabilities of systems and how they are interconnected.

[Slide 19]

The next lesson learned was on managing large incidents.  Emergency management does a very good job about managing chaos.  It is what they do.  Conversely we did not see across the IT community that they had good policies and procedures to manage very large events or incidents.  That being said IT does a good job of help desk—taking tickets, calls for services, working through that in the work of the day, of being able to take things in, prioritize and get things out.

[Slide 20]

If we look at incidents that might last a week or more, or even several days, we saw breakdowns in IT’s ability to manage that incident and be able to have a command structure, be able to have operational periods where people might be able to be relieved out and to really be aware of all resources that might be available to them to help manage and survive the incident. Things like public information officers, people that might do outreach to other affected communities, people handling logistics of bringing food, water, medicine and sleeping arrangements if your technical staff was going to be stuck onsite for a long period of time.

I think in the evolution of IT within our incident response and disaster recovery I still see there is room to grow regarding the management of a larger incident.  Emergency management principals can serve that community very well.

[Slide 21]

The final lesson learned is that the halo benefits regarding planning for a catastrophic event far exceeded our expectations.  What I mean by that is we went into a room preparing for Godzilla to come out of the ocean and destroy everything and what we ended up with was better policies and procedures to handle everyday events.

Planning for the very unlikely ended up having immediate benefits to day to day operations well beyond what we were expecting.  It would have been interesting on a sociological level to find out why but our quick hypothesis is that planning for events that are very rare ended up kind of having people checking their egos at the door and they were able to cooperate and participate in the process more willingly than trying to work on a mundane day to day process and analyzing that process where people might have more ownership or pride of ownership over a process.

Planning for a pie in the sky or never going to happen event seemed to get people thinking more broadly and they were a little more open to ideas of how they might change to address something of that nature.

[Slide 22]

That, as we like to say, is the last three years of our lives and we hope that some of our pain and learning points can help you moving forward.  I am going to turn this back to Amy to see if there are any questions for us.  We hope you enjoyed it.

[Slide 23]

Amy Sebring: Thank you very much. That was an excellent overview.  We will move to the Q&A portion.

[Audience Questions & Answers]

Amy Sebring:  Are links to the resiliency annex and the regional plan available anywhere or can people request copies from you?

Adam Wehrenberg:  We haven’t posted them publicly but I am willing to share them with any constituents who wants it.  My contact information is there so drop me a line or send me an email and I’ll send you our suite of documents.  I’m sure they will spark more questions than answers so I’m happy to work with anybody through it and answer anything I can.

Amy Sebring:  Do you have any conferences or other in-person presentations on your schedule?

Adam Wehrenberg:  There are none that I’m aware of.  In each of our states there may be ongoing activities as each CDT takes it on their own but none currently scheduled.

Amy Sebring:  Can you tell us about any exercises held by the perhaps one of the state cyber disruption teams? Have they gotten that far to exercise some?

Adam Wehrenberg:  When we finished the first iteration of the cyber disruption response annex back in 2011—it was a framework at that point more than an actionable regional plan—we wanted to test our base regional catastrophic coordination plan as well as this annex and another we had drafted.  As part of that we pulled together each state’s cyber disruption team for a series of drills.

There was an executive exercise first and then we went into state specific drills to test that people understood the necessity of pulling this team together—not necessarily testing the technical skills and not striving to embarrass anybody for awareness of the plan or not, but just to justify the existence of the plan and test that people knew how to activate it.

When we came together in April of 2011 that is when we had our big exercise on the regional catastrophic plan.  It was probably three or four months of lead-up time in a series of drills and executive level seminars—getting to that point.  We did a series of drills like that.  Kevin has worked with the Rhode Island cyber disruption team specifically.

Kevin O’Shea:  Following the executive drill, we did the three state level drills and one large combined exercise with the cyber plan and the IED plan and I have been supporting the Rhode Island cyber disruption team for the last year and a half on a series of table top and moving up to a quasi-functional exercise.

Even during the NLE-12 the cyber disruption response annex was used and there was a cyber disruption team regional call during NLE-12.

Adam Wehrenberg:  Last week I attended the National Lessons Learned forum we had in Boston organized by FEMA and I was also at the one on the West Coast in Santa Clara the week prior talking about this framework as one possible solution to getting people together in the same room to talk.

NLE-12 was a great opportunity to test a lot of what we have.  As far as the regional catastrophic program at large—for those of you unfamiliar with the grant program, it only existed for four federal fiscal years.  The first one we were supposed to plan, the second one keep planning, the third one train and the fourth one exercise.

We are still setting the strategy for how to implement the program in the fourth year but it will likely include training at least at the discussion level if not the operations level for all the plans, this one included.

Avagene Moore: Thanks for your fine presentation, gentlemen.  Are there a number of similar projects or efforts underway around the country?  I ask because of one or more hearings before Congress warning that the US is woefully unprepared for cyber attacks.

Adam Wehrenberg:  There are and one of the reasons I was invited to the West Coast Lessons Learned forum a couple of weeks back was the state of California is starting the process of pulling together a task force to deal with this.  There are a number of other states we have talked to in the process.

One that comes specifically to mind is Washington, and Michigan as well. We’ve have worked with Washington a little bit.  We spoke with them at a conference on a panel together to talk about the similarities of our approach.  It is definitely something people are looking at.  I have spent time on the phone with a number of states as they have gotten word of this plan and I have distributed it to them.

It usually sparks more questions than answers so I have spent time talking to some people.  It appears this effort is something that is going to take shape in one form or another across all fifty states in the near future.  It is exciting to see the differences and we are hoping we can create something positive for people to adapt to.

Amy Sebring:  Have you been in touch with the folks at DHS that are responsible for the cyber security area?

Adam Wehrenberg:  One thing we learned quickly was that there were a lot of federal partners with a lot of responsibilities for cyber.  There are a lot of resources out there.  I mentioned during my portion of the presentation there is a typing effort underway now—at least the first draft is complete—that FEMA is undertaking.

We also have a cyber security advisor here in Region I.  I believe there are three or four across the country at the moment with the goal of there being ten to map the same type of regions as FEMA regions.  In Region I we have one up here.  There are a lot of assessments and training that can be provided.

We have been in talks with a number of other federal agencies like the NCCIC [National Cybersecurity & Communications Integration Center] over the past few years.  We had some of their folks come up and talk at a cyber summit we hosted.  We have been talking to anyone that will listen but at the same time trying to always put in into the scope of what assets we can provide to our folks to ensure they can continue this effort after the life of this grant.  It always comes down to money in one way or another, right?

Kevin O’Shea:  I want to build on Avagene’s question.  I ask because “one or more of the hearings before Congress warn that the U.S. is woefully unprepared for a cyber attack”.  That is a two issue question.  One is what is our cyber security posture?  Are we ready to defend against attacks?  And the second part is: How resilient is our infrastructure—meaning that if we are getting attacked how well are we able to absorb and/or recover from an attack?

Where the cyber disruption team concept here really is looking at those as effects we are making the conclusion that if you look at the risk equation on this—the chance of attack is one hundred percent.  If you start running the math on that at some point they will be successful.

What success is for the bad guy may be getting on your network and sitting there or shutting down a power plant.  We just haven’t seen the latter yet.  Knowing that we do not have a tremendous amount of control over the private sector’s control of critical infrastructure, that we are downstream too much of both power and ITs/comms.   

What is under our control is our ability to have resilience and multiple ways to communicate and what have you but also to mitigate and manage the disruption should it or when it occurs.

Adam Wehrenberg:  The purpose of our project from the outset was to make sure the government could continue to provide critical functions and understand the necessary order of operations.  If the system goes down and the prioritization is out of whack such that someone can get a driver’s license but our police officers can’t talk on their radios because we just didn’t understand what the appropriate prioritization should have been then we would have missed the boat.

Our focus was on the continuity of government.  But in order for this to be successful there has to be the next step of integration with the asset owners, the private sector and people who can help make us resilient so that we’re not just responding.

Amy Sebring: I would like to follow up with a general question about the halo effects, the benefits, which may extend even beyond the cyber sphere. My general question is how was it working with the private sector?  How involved were they and how cooperative were they?

Kevin O’Shea:  The original focus of this project was mainly government systems.  For the vast majority of the project we were focused on government.  IN all honesty the reason we wanted to do that was that we wanted to bring the government up a few levels so they’d be kind of talking as a peer with folks in the private sector as opposed to starting the project and have the government folks be a couple of steps behind.

We wanted to make sure we brought the government folks up a few levels and then give them some good footing to engage the private sector.  The second part of your question: When we did engage the private sector, it has been mixed.  At times the communications providers have been cool to participate.  What we are trying to build is for government agencies, and to some extent these private companies, to have some transparency as to how resilient their systems are.

That resilience is going to look back at those dependencies on power and communications, IT and water and so on.  There is not a whole lot of transparency into how resilient those providers are.  The providers for security reasons or trade secret reasons keep that information pretty close to the vest.

We are making risk based decisions without all the information we really need to make an educated risk based decisions.  But other companies that we are working with, even the IT providers are feeling the same way about the energy providers.  We are all facing that same issue.  The more we work together we can make better decisions and also be better prepared and have those contacts ahead of time should something bad happen.

Adam Wehrenberg:  Seeking out organizations like the one I mentioned—the Advanced Cyber Security Center—in Rhode Island, they are trying to formally establish something being called a Cyber Center of Excellence.  These folks have taken, really, competitors and through no shortage of non-disclosure language gotten them to sit in the same room and share the vulnerabilities of the threat vectors they are seeing as a means of strengthening their entire sector.

Those types of organizations are great to have.  Oftentimes they need to be spearheaded from outside of the government.  If you can seek one of those out in your jurisdiction those are a great type of organization to be a part of and receive information from or give it to.

Ray Pena: Describe, in general terms, how the community would respond to an unexpected cyber-related multi-state power outage. Focus on resolving cause and how immediate effects would be handled.

Kevin O’Shea:  As a purely theoretical—and I’ll take Rhode Island as an example just because I have been working with their team most extensively.  The cyber disruption team is led by law enforcement.  It has participation across academia and a number of private sector companies including Raytheon, RBS Citizens and Dell SecureWorks.  They have team members that have pledged time and energy should some large disruption happen.

We have actually done this very similar question in exercise where the power company has a cyber related event and it is beyond their ability to figure out what is going on and they are calling in for help from the cyber disruption team.  In reality that company might be calling an incident response company, like a Mandiant or Dell SecureWorks, to come in. But in this case let’s sat the cyber disruption team also gets the call.

They would be forming up and moving out and helping manage the incident as much as providing technical support.  They might be providing logistical support and planning support and things of that nature.  We are not really sure how much the power company would let outside people be on their networks and let people meddle around on their networks. 

That is why the Rhode Island State Police is there and if they were coming in as a law enforcement function they may get more headway than just if the team was made up of a bunch of volunteer folks from corporations.  That is kind of how we see it happening. Power is probably not the best example.  We have used examples from state run hospitals or something like that where they might be turning to state resources to help out.

We do see the cyber disruption team concept expanding.  We are mainly focused on how they manage the incident and helping pull in the right technical resources over what might be a response period that would last 24, 36, or 96 hours.

Amy Sebring:  In the scenario of a multi-state, the regional plan annex would coordinate, correct?

Adam Wehrenberg:  As we develop this regional cyber disruption response annex—and it is really focused on information sharing first and foremost.  We would hope that as the typing becomes more applicable to what we are working on, whether it is physical assets or more likely personnel, that we could leverage the existing interstate authorities like an EMAC to send personnel over across borders and have them assist one another and understand that a type I cyber disruption team comprises X capability and you guys can come in and assist.

One thing we found is ‘every IT network is completely different and unique from every other IT network.  Nobody could possibly work on mine.’  We’re hoping that capability and the typing mechanism comes into play and there is some established consistency we can break down some of those barriers as well.

R. Bostick: Were scenarios explored where cyber support may be requested from out of region/state?  In what types of scenarios?  Thanks. 

Kevin O’Shea:  You are right on with where some of the original concepts for the cyber disruption team were headed.  We believed that as Adam was joking that the networks were so unique and whatnot.  Really when you look at it objectively we have two or three manufacturers of large switches.  We all use IP.  We are pretty much settled on using an Exchange back end a Windows or Linux backend. 

The amount of variability across one network to the next is not that much.  The idea that you could have a network tech or someone like that be loaned from another jurisdiction I think is very reasonable.  We are a likely a generation or two away from that concept being accepted within the IT community.  Just as mutual aid for law enforcement and fire took a couple of generations to get through, like “My fire truck is unique.  No one could find out where the halogen bar is on my fire truck.”

That is all standardized now and you get mutual aid all the time.  It is completely accepted.  I think that the cyber disruption team lays out that framework but I think we are a little ahead of our time when it comes to actually sharing personnel or resources.  I think that is coming.  We were the fine line between genius and crazy and I think for the moment we sound crazy.  Maybe in a year we will be geniuses.  Who knows?

Amy Sebring:  Adam, you mentioned the resource typing for these teams.  You think a draft has been done. Do you have more information about the status of that?

Adam Wehrenberg:  I don’t.  The last I saw was a month or two ago.  It is coming and FEMA is working on it in earnest.  I think we will see it evolve.  Based on the rate of change of cyber infrastructure it may be a little dated by the time it comes out of the box but from a principle standpoint it is something we will see in the near term and derive some benefit from it.

Kevin O’Shea:  I hope the typing is at the intelligent level where it is not immediately obsolete.  I’m hoping they put it at the appropriate level to where you can order through IMAC or Stafford Act and order a switch with this general capability with this general speed—that is where we’re going to see more resource sharing when that resource typing is accepted in as at the level where people are not immediately suspicious of it or disregarding of it because it is too specific or because it is, gasp, three months old and we could never use that.

Amy Sebring:  How awareness from non-IT type of folks—how much all kinds of systems rely on this infrastructure and how they might be impacted—I liked your effects planning but I almost think the effects may need to be spelled out more.  You may be looking at terrible traffic—all these cascading effects. 

I understand you cannot map all of these—loss of potable water and all these various systems.  I think anything that could be done to bring awareness to folks—and you obviously did that throughout your effort. It seemed that you were struck by that as well—how folks were not aware of how much they rely on this infrastructure?

Adam Wehrenberg:  Absolutely and getting the effects-based planning came in handy in getting both sides to the table.  You get rid of the help desk mentality of “I can solve this immediately and it’s not a problem” and from the emergency management and public safety side “I don’t know about a spoofing attack or a denial or service attack is and I don’t really care but the end result is I can’t distribute my information to the public in the way I am used to.”

Something gets defaced on the city’s website.  I need to deal with the physical ramifications of that.  For us the scenarios became irrelevant and that really made a lot of people change the way they thought about this, or the way they thought they had to think about it in a way.  As we further mature these cyber disruption teams you’ll see these folks delve a little deeper into the specifics of the cascading effects but for us just getting people in the room was a huge victory.  That certainly helped us do it.

Kevin O’Shea:  I’d add on one item to that where you are talking about dependencies.  Throughout the process—again it is oftentimes in the planning that the process is more valuable than the deliverable itself.  We have found in several occasions where the process of going through this that certain critical infrastructure like data centers were not on their critical infrastructure list.

Folks were not aware of how reliant, for example, power was on IT.  Being able to make those connections—like you are saying how potable water might be affected—it allowed people to make better risk decisions because they were making assumptions that everything would be okay and that an IT outage wouldn’t affect water.

All of a sudden when they learn that they start changing some of their own risk equations to account for that—and I think that had a very broad effect well beyond this project.


Amy Sebring:  On behalf of Avagene, myself, and all our participants, thank you very much to both of you for being with us today and sharing this information with us. 

Thanks to everyone for participating today and have a great afternoon! Have a safe and happy Fourth of July! We are adjourned.