Tag Archives: risk management

Creating IoT Systems Manageability – A Risk-Managed Set of Networked Things

To achieve IoT Systems ROI and to ensure non-degradation of an institution’s existing cyber-risk profile, IoT Systems must be manageable. In turn, in order to build IoT Systems manageability, institutions will need to manage their IoT Systems risk with non- traditional approaches that includes assigning IoT endpoints (the ‘things’ in IoT) to risk categories that can be independent of the underlying technologies and vendors.

IoT Systems are increasingly complex to implement, manage, and to establish system ownership in institutions, whether cities, Higher Education institutions, or corporate campuses. In turn, an institution’s IoT Systems Portfolio – a systems of systems – rapidly deepens the complexity. We will need to tackle the problems and challenges in new ways and with new organizational concepts if we are to have an opportunity for well-managed and reasonably risk-mitigated systems. This includes thoughtful inter-organizational planning, partnerships, and development of a more common language between central IT, distributed operational organizations and departments, and vendors. Further, this will be required to establish system ownership and management plans between organizations such as facilities organizations, central IT, research groups, vendors, and others. One step toward this objective is identifying things to be managed independently of the technologies and vendors implementing them — a Risk-Managed Set of Networked Things.

Central IT won’t own all of the IoT Systems

Traditional enterprise network and system management tools, staffing models, and even language are ill-equipped to address this rapidly changing technology. Historically, network and system management tools have all been within the purview of central IT. Central IT will not be able to keep up with the accelerating growth of IoT Systems across an institution. Just like central IT organizations cannot manage every user/academic/business application on their networks (or even many of them), central IT will not be able to support all of the IoT Systems either. Business owners — operational (academic in the Higher Ed case) and administrative — will have to share that load. That’s better for them too — they are closer to the problem and have a truer understanding of desired outcomes from the system. Implementing this coordination across two or more organizations in the institution is new work though. There are not great precedents for this. Institutions, particularly Higher Education institutions, are known for their bureaucracies within bureaucracies, entrenched ways, and “cylinders of excellence..” (aka silos) .

system of system of systems ...

system of system of systems …

In a similar fashion facilities management organizations have substantial skill sets in building in and integrating equipment into built environments whether they are buildings or spaces. However, facilities management organizations don’t have network design, implementation, network management, and traditional server management skill sets. Finally, while operational departments, whether acting independently or in collective partnerships with other operational departments, know what they want systems to do and comment on performance, they do not have the required skill sets that facilities management and central IT groups bring to the table.

This organizational-spanning nature of IoT Systems in institutions make establishing ownership and a post-implementation management plan particularly challenging.

Designing for & building IoT System manageability

The growth in institutional system count, system complexity, and system interdependency makes for rapidly evolving systems management and owner environments for Higher Ed institutions. We have to take definitive steps to make things more manageable. That is, we have to design for system manageability. Applying historical and traditional tools and organizational approaches to this rapidly changing environment will no longer be sufficient.

A core component of any framework to facilitate manageability is a language, or at least shared concepts, that support it. In turn, a substantial objective of that shared language development (shared, for example, between central IT, facilities, and operational users) is to develop structures that make the systems more manageable. This sounds obvious, but in our complex environments and with our dwindling availability of time and cognitive bandwidth, it is easy to lose sight of this objective.

Agreeing on what is being managed

Before different organizations within an institution can establish those manageability- facilitating-structures and figure out how to partner, establish ownership, and mitigate risk to institutional systems, they have to be able to mutually identify and agree upon what is being managed. What is the set of things — devices, systems, spaces, buildings, infrastructure, etc — that we care about managing, from both operational and risk mitigation standpoints?

In days of relatively simpler systems, sets of networked things/devices to be managed were often defined by the network itself and/or systems on the network and/or the particular brand of technology supporting the network. Further, these networked things/devices were typically run by central IT organizations and these organizations were comfortable with using locally understood network terminology and concepts to define that set of things. Examples include — devices/things on a particular subnet or set of subnets, devices/things behind a particular firewall, on a particular VLAN or VRF, etc.

These examples above don’t mean much to potential system owners that are business organizations and/or academic organizations. The terms used are way too abstract, jargon-y, and/or colloquial. The cross-organizational planning and coordination needed for IoT Systems implementations and subsequent management cannot occur if participating groups can’t mutually identify what is to be managed.

Also problematic in trying to apply these old approaches of identifying things and systems to be owned, operationally managed, and risk-managed is that it is easy to slip into the high-granularity/high-entropy of technical details when the initial conversation is simply identifying and agreeing upon what is to be managed. Because these new and rapidly evolving technologies are increasingly complex, requiring increasingly deep technical skill sets, conversations in technical detail can be challenging even for technical professionals and effectively useless for potential academic and business partners and systems owners.

Finally, sets of things/devices to be managed might involve multiple technologies — eg maybe partially wired, partially wireless/near-field, on a VRF, behind a firewall, etc. So using a technology as a defining mechanism is further unhelpful. While a particular technology or network might happen to align well with a business need for defining a group of assets to be managed, we don’t want to start with that assumption.

IoT System Manageability Groups – A Risk-Managed Set of Networked Things

To address these shortcomings, we can consider a Risk-Managed Set of Networked Things (RMSONT). In this approach, we work to establish sets of networked things based on what best enhances manageability of the system. This is independent of underlying implementing technologies, particular vendors, and existing organizational charts.

What constitutes IoT System manageability?

A managed IoT System will have at least these attributes:

  • the IoT System was selected methodically and with purpose
  • the IoT System is named & known
    • the system has a common name that is known, shared, & published to participating parties (eg central IT, facilities management, operational departments, etc)
  • devices/things of the IoT System are enumerable
  • that is, via network process the device can be known and named
  • IoT System owners identified
  • IoT System component owners identified
  • satisfactory system performance is defined
  • system performance is measured
  • system performance is reviewed by business owners and systems support providers
  • estimates of total costs are established and shared — includes IT and Operational Technology (OT) costs
  • other

What are the qualities/attributes of a thing/device?

Things/devices in IoT Systems have at least these qualities or attributes —

  • a location
  • a function (what is it supposed to do)
  • an IP address; a MAC address
  • a power requirement
  • an associated data aggregator or controller
  • supports a user, users, or population (department, organization, constituency, etc)
  • rate of failure (estimated or known)
  • other

Creating a Risk-Managed Set of Networked Things

The #1 goal is to build and enhance IoT Systems manageability. A risk-managed set of networked things is established to create a manageable group. This could be a group managed by the business consumer or an institutional service organization such as facilities management or central IT — whatever best facilitates system ownership and management.

Multiple sets of risk-managed things can be created to facilitate overall system manageability. One example of a set of risk-managed sets might be:

  • law enforcement/security office owns and manages a set of networked video cameras (possibly with support from central IT, facilities management, local IT, vendor, etc)
  • in an academic setting, a researcher that uses a specialized HVAC IoT System with sensors, actuators, and data aggregation to provide tight environmental control of their research environment might be a logical choice to own that system
  • a metering system might best be managed by the institution’s energy management office
  • a building manager might have a risk-managed set of networked things local to their particular building, but of different types of things— surveillance cameras, energy management system, etc

In general, getting those most familiar with the IoT System’s performance expectations and actual performance into a system management role is probably a good idea.

As we talk about sets of things, and particular kinds of sets of things, we can borrow lightly from the mathematical idea of groups.

As I understand it, mathematical groups are:

  1. Sets of things
  2. These things abide by or participate in some set of rules

A selected set of things abiding by a certain set of conditions & operations …

Similarly, a Risk-Managed Set of Networked Things, can be:

1. A set of networked and computing things/devices (that interact with the environment)

2. These things/devices participate in or are governed by some sort of network management processes and human management processes — eg automated network device enumeration/inventory, device health/responsiveness, etc


RMSONT – A Risk-Managed Set of Networked Things


You gotta keep ‘em separated (or not)

To borrow from Offspring’s social commentary (and popular song) on gang membership, colors, and violence in Come Out and Play, the theme of IoT Systems and network segmentation seems to be, “you gotta keep ‘em separated.” The problem is that that is not as easy as it seems.


tie your own rope, tie your own rope, tie your own rope (hey!)

Network segmentation has been all the rage as an answer to IoT Security and risk mitigation. However, as we’ve seen, network segmentation alone is not sufficient. Risk-managed sets of things need to be thoughtfully chosen, the rules and operations supporting that set of things needs to be thorough, and systems owners thoughtfully coupled with systems in order to achieve manageability.

We can manage IoT Systems within our institutions. And we can manage portfolios of IoT Systems within our institutions. However, we need to acknowledge that these are different kinds of systems and that our existing traditional IT systems operational and risk management approaches are likely insufficient. From that point we can sculpt and evolve new management approaches that facilitate successful, well-managed IoT Systems portfolios.

Socializing Internet of Things risk


adding risk from IoT doesn’t mean the existing risk to an organization conveniently disappeared …

There is a lot of conversation regarding security, privacy, safety and other issues regarding the ongoing proliferation of the Internet of Things (IoT). While IoT promises many helpful and useful things, concern about how it might (and will) be misused are valid. However, there are more than a couple of challenges to addressing this new source of risk to an organization.

Lions and Tigers and Bears

It’s easy for anyone to call out things that could happen with the IoT growth. Medical devices can be hacked , SmartMeters can be compromised and steal privacy information, the utility grid is widening its attack surface, drone video is intercepted and hacked , and countless others . Long live fear, uncertainty, and doubt, right?  While highlighting examples of IoT issues is important, the larger and more difficult thing for an organization to do is to communicate risk around IoT in a way that allows it to be managed.

Communicating IoT risk in an organization

Within an organization that already manages risk in some form, communicating and socializing the idea of IoT risk can be a challenge. There are at least two broad components to that challenge:

  • IoT defies traditional classification/categorization and is still little understood. It’s hard for people to wrap their heads around it
  • the other risks that the organization faces are still there. They haven’t gone away and IoT risk only adds to that

In order to begin to manage IoT risk, management must have some vocabulary for it. IoT is still new, its effects largely unknown and likely emergent, and precedents and analogies are few. We need to surface some language and concepts for it so that it can be discussed.

Another significant aspect of communicating IoT risk issues is that the other risks that an organization already faces — safety, liability, financial loss, reputation damage, technology challenges, business competition, and many more have not gone away. These risks are still there. We are asking senior management to make room in their list of existing risks that they are wrestling with to add yet more risk.  And possibly substantially more risk. Nobody wants to hear this.

Because of this, how we communicate these security, privacy, and risk issues is important. We are competing for a small slice of available cognitive bandwidth, so we must use this opportunity to communicate as well as we can.

Lather, Rinse, Repeat

If you either want to or are tasked with communicating IoT risk in your organization, I would suggest starting here:

  • find out what other risk the organization is already working with. Is there an annual report? Is there someone in the know in your network?
  • identify places where IoT is already in your organization or where you expect it
  • use the language of managing existing risk in your organization to begin to talk about IoT risk. If you have existing IoT risk examples, describe them in traditional risk language for your organization
  • repeat

A key to this communication is to get some IoT risk concepts out early. Give management some language to use to reflect on IoT risk and to discuss with their peers. It’s also important not to be heavy-handed in the approach. Yes, IoT risk is important, the impacts potentially very high, and the opportunities for abuse many, but the other existing risks that an organization faces haven’t gone away and they still must be managed too.

Wherefore art thou, cybersecurity insurance?

Uncertain coverage (image: commons.wikimedia.org/wiki/File%3AForgotten_umbrella.jpg)

Uncertain coverage

Developing a market for cybersecurity insurance is more difficult than it may seem.  With a rise in business losses stemming from malicious activities and adverse events in the cyber world, creating a market for cybersecurity insurance where losses could be mitigated would seem to be a no brainer.  However, developing, maturing, and establishing trust in a cybersecurity insurance market is slow in coming.

What it’s supposed to do

Ostensibly, implementation of a mature cybersecurity insurance market can provide protection and mitigation for such events as:

  • data breach
  • network damage
  • cyber extortion
  • brand damage
  • financial loss
  • other

The Department of Homeland Security quotes the Department of Commerce  in describing cybersecurity insurance as an “effective, market-driven way of increasing cybersecurity.”  The idea is that cybersecurity provides mitigation to damages suffered from a cyber event and also enhances cybersecurity in general by motivating better information risk management and security via premium discounts for good practices.

Implementation and chicken and egg challenges

Despite the seemingly obvious benefits, cybersecurity insurance has yet to undergo wholesale adoption.  DHS and the May 2013 Cyber Risk Culture Roundtable Readout Report hosted by the National Protection & Programs Directorate (NPPD) offer some reasons for lack of adoption to date:

  • Cost — An added cost that companies must deal with plus the perception of cybersecurity insurance as a luxury item
  • Uncertainty — potential customers wonder whether carriers will actually payout on cyber event claims.  There is little current precedent for such claims and payouts, hence the chicken and egg problem
  • High risk appetites — Particularly in technology fields where there is a lot of entrepreneurship, the tolerance for risk is high
  • Market/services maturity — Awareness and incentives structures within the cybersecurity insurance industry are not ubiquitous
  • Lack of clarity/precedence/data on likelihood of an adverse cyber event
  • Confusion/misunderstanding on exactly what is covered with cybersecurity insurance

At the cybersecurity framework hearing held by the Senate Commerce, Science, and Transportation Committee  on July 25, 2013, Patrick Gallagher, Director of U.S. Department of Commerce’s National Institute of Standards and Technology (NIST) also suggested that the cybersecurity insurance market was not yet sufficiently mature to handle large-scale, catastrophic cyber events.  Dr. Gallagher stated that there was not yet a robust actuarial and monetized basis for such large-scale coverage.

Further, at the same hearing, CEO of RSA, Art Coviello suggested that developing an actuarial basis for adverse cyber events was particularly difficult because the computing environment is changing so rapidly and because of the vast amount of data being generated that needs some form of analysis in order to determine appropriate coverage.

As much as I want to encourage and contribute to the rapid development of a mature cybersecurity insurance market, I too have concerns about how policies are written, how cyber events are described, and how much work is required to get an actual payout on a claim.  To get consumer buy-in in the short term, insurance providers might have to ‘go long’ with claims and payouts to establish trust and confidence amongst consumers.


Would you purchase cybersecurity insurance? What sorts of events would you like protection from? Data breach? Data loss or theft? What changes/implementations would make purchasing cybersecurity insurance more appealing to you?


[image: commons.wikimedia.org/wiki/File%3AForgotten_umbrella.jpg]

Force Protection & SMB Information Risk Management

chestypullerThe term “force protection” entered the American military vernacular in the late 70’s and 80’s in response to several events.  One of the key drivers, though not the only driver,  was the activities of the Red Army Faction or “Baader Meinhof Group”.  This group was responsible for several bombings, assassinations, & kidnappings over three decades.  As US bases and US military personnel were frequently the targets of these attacks (as well as attacks from other groups), the need to develop specific plans to protect ‘the rear’ began to be articulated. In effect, ‘the rear’ was no longer the rear.

Military organizations have always been aware of the concept of ‘protecting the rear’ or ‘covering your flank.’  However, the asymmetric, unpredictable aspects of these attacks put the military in the position of having to explicitly define a process for protection of assets that were not traditionally in harm’s way. Further, by naming and mandating the process, it was clear that some percentage of resources originally intended for forward operations would need to be diverted to support force protection. This was a shift in thinking.

I believe a similar thing could be occurring with managing information risk and security in small to medium-sized businesses (SMB’s).  Relatively suddenly, these businesses are finding themselves in hostile territory and if they want to stay in business, then they must dedicate some operational resources — whether marketing, production, R&D, revenue, etc — to support these protective and risk-lowering activities.

Early Marine Corps doctrine on force protection

I found a Marine Corps publication, “AntiTerrorism/Force Protection Campaign Plan” from 1998 that presents some operational concepts that could be helpful analogies to the issue of information risk and security for SMB’s.

The publication provides some definition of force protection:

In its purest sense, force protection is an overarching concept. It includes those procedural, training, equipment and leadership principles necessary to ensure … safety and well-being … In essence, force protection is an inherent function of [leadership] and as such should be an integral part of the way we do business on a daily basis.

Similarity in threat analysis

It goes on to describe analysis of the threat as considering a stool with three legs — Does the enemy have

  • motivation
  • means
  • opportunity

We can apply similar analysis to SMB information risk.

  • Does ‘the enemy’ (criminals or nation-state actors) have motivation to attack or compromise an SMB’s information assets?  Yes, certainly.  A successful attack provides, 1) potential revenue, 2) an attack point for attacks on other, possibly larger, more lucrative businesses
  • Do they have the means? Yes. They have readily available computers, pre-built networks for attacks, often anonymity, and sometimes protection from their parent state (country)
  • Do they have the opportunity? Yes. There are many poorly protected and non-resilient SMB computer networks available for attack.
Marine Corps operational doctrine on force protection (from 1998) Potential analogies in SMB information risk management
“Force protection is an operational aspect of every mission …” For example, resources are shifted away from marketing, R&D, production, etc to support SMB’s information infrastructure
Work to “eliminate the belief [by the enemy] that opportunity [for attack] exists” Employ basic measures such as anti-virus, firewalls, managed/standardized computers, and awareness education to create an unappealing risk/value proposition for potential attackers
“The value of alarms and drills…[Leaders] at every level should develop recognizable alarms for potential emergencies and critical incidents.” Rehearse disaster recovery and business continuity plans. Practice activities such as data recovery tests.

The US military found itself in a position of having to develop and evolve a practice to address a fairly sudden new threat that was also evolving, as well as unconventional, and unpredictable. Similarly, to remain relevant and to maximize their respective opportunities for success, I believe that SMB’s need to, in some manner, introduce information risk and security management into their daily activities as well.

Do you think there is currently motivation, means, and opportunity to attack your business?

IT Risk Management Lessons Learned

From Tom Scholtz’s presentation at Gartner Security & Risk Summit 2013 on lessons learned in IT Risk Management:

  • Understand that there is a limited appetite for risk management as a topic by business users (ie, don’t overdo it)
  • Ideally, risk assessment is performed on business processes (vs IT assets or services)
  • Risk interpretation is personal — there is no correct answer
  • Don’t try to use only one risk assessment method for all assessment scenarios — one size does not fit all
  • Don’t use security & risk operational metrics when communicating risk to leadership — convert them to business objectives
  • Risk affinity for individuals and organizations changes over time
  • In many IT risk cases, quantitative risk analysis is impossible (because of lack of relevant actuarial data)
  • In the quest to simplify, don’t try to roll up multiple independent risks into one metric
  • Always link risk management activities to business objectives
  • Focus on risks that we can do something about

Finally, while possibly an unpopular sentiment amongst some practitioners, risk should be treated more like an art than science, where the focus is on gaining and documenting experience* and continuous improvement.  *(See my post Inverting Sun Tzu).

Meet the New Boss … Reincarnated malware returns to SMB’s

Same as the old boss …

A popular form of malware called ZeuS/Zbot has made a comeback and SMB’s are particularly at risk.  Initially identified in 2007,  the malware typically steals user credentials for banking activity.  SMB’s have higher risk exposure because they typically don’t have the resources for risk and security programs.  One SMB, a Maine construction company, was robbed of almost $600,000 in 2009.

ZeuS/Zbot source code is known to be readily available on underground informal networks as well as, apparently, even available for sale.

Back because it works

Once thought to be largely eradicated, ZeuS/ZBot is back because of market analysis and software upgrades.  SMB’s typically have a richer target (bigger accounts) than individuals and are also generally less protected than larger businesses.  Facebook is also providing a new and effective ‘attack vector’ for getting the malware onto user computers to steal data.

How does it work ?

ZeuS/Zbot uses a ‘Man-In-The-Browser’ (MITB) attack. Once a machine is infected, Zbot is able to monitor web activity and watch for particular banking sites.  User credentials are copied and replicated on a database maintained by the attacker. With this information, attackers or their proxies (‘mules’) can login and transfer money wherever they’d like.  By downloading a configuration file established by the attacker, the list of banking sites can be updated.

Prevention/due care activity for SMB’s includes:

  • Move banking activity to dedicated machines used for no other purpose than banking
  • Educate employees on threats, risks, and behavior
  • Review high risk accounts (eg big balances) and access/authorization to them
  • Keep antivirus/antimalware software current
  • Implement a simple information risk management plan (Shocking!)

What percentage of your computers have current antivirus scanning? How do you know?

FIS Spends Over $100 million in Breach Response

Fidelity National Information Services (FIS), a large banking services company, was hacked in 2011 and information from that breach was used in a $13 million ATM theft.  Initial reports said damage was limited to a small portion of its organization.  Subsequent audit reveals a much larger breach plus apparently poor management of its incident response.

  • More than $100 million spent in response to breach
  • An FDIC audit showed that since the breach & response that many machines still have default, no, or poor passwords
  • An FDIC vulnerability scan found over 10,000 instances of default passwords in use
  • FDIC report in November 2012 shows 18,747 network vulnerabilities and 291 application vulnerabilities presented as past due

More here


Poorly Defended & Under Attack — SMB’s in the Spotlight

Cyberattacks on Small and Medium-sized Businesses (SMB) continue to grow, causing damage to the individual SMB’s as well as the international business network infrastructure itself.

Why attack SMB’s ?

SMB’s are under increasing attack for several reasons:

  • They are often poorly defended because of resource constraints
  • The are typically connected to other SMB’s and larger organizations, providing an attack path (or ‘attack vector’) to other businesses
  • There are a lot of them

Simply because of their size, SMB’s are typically poorly defended because they are resource constrained and don’t have the IT and/or security expertise on staff.

A recent UK survey showed only 14% of SMBs thought that cyber security threats were of highest priority and felt that they had sufficient skills and resources in place to manage the threat.  In another study commissioned by Microsoft, AMI-Partners found that of Involuntary IT Managers (non-technical staff assuming technical duties) surveyed:   

  • 30% thought IT management was a nuisance
  • 26% did not feel qualified to manage IT
  • 60% wanted to simplify their organizations IT systems to make their management more feasible
SMBs are easy and lucrative for attack

SMBs are easy and lucrative for attack

The AMI-Partners survey was of 538 Involuntary IT Managers across 5 countries in companies of 100 employees or less.  The survey also found an aggregate loss of over $24 billion due to inefficiencies stemming from the Involuntary IT Manager not performing their primary job duty.

Another reason for targeting SMB’s is that their interconnectivity with other businesses can provide an attack path to larger businesses.

Finally, there are a lot of SMB’s  .  In industrialized countries, a few very large companies live side by side with many small and medium-sized companies.

 What to do about information security and risk management in SMB’s ?

That, then, is the question.  The resource constraints that SMB’s face aren’t going to magically disappear anytime soon.  Should the government assist? Or conversely, should that security and risk management be a cost of doing business for the SMB?  Should SMB’s face penalties for insecure environments or poor infrastructure support practices? Will that stifle innovation?

I lean towards a hybrid solution where the SMB is responsible for knowledge and awareness of itself and its information risks, but I would like to see the government make resources available to SMB’s (or support industry groups to do the same).  These resources could include:

  • simple guidelines and minimum configuration standards.  (Some of the current policies and directives are so convoluted and difficult to read as to be impossible to implement.)
  • simple asset inventory tools
  • network mapping tools that assist SMB’s with self-documentation
  • simple penetration test tools coupled with results analysis tools
  • simple risk management tools

SMB’s themselves, professional organizations/networks, or governments must find a way to better educate and prepare SMB’s.

  • How do you think SMB’s should manage their IT & Information Management systems?
  • What do you do to protect your business?  
  • Do you actively manage information risk?
  • Do you turn it over to someone else?
  • How well do you understand your exposure to cyber attack and compromise?
  • Do you avoid altogether because it’s simply overwhelming?