Just when we thought we’d seen everything, Intel’s bombshell announcement that they are acquiring McAfee stands to shake up the security industry all over again.  Aside from the potential impact on the security vendor space (as far as all the downstream corporate customers are concerned), it’s interesting to imagine the alignment issues which will surely arise between these two massively security-conscious firms.

As a security officer, should you invest significant effort into building a set of practices and policies which somehow enable integration with a completely different set?  For example, at the easy end of the scale, you might have two different standards for how many failed logins trigger an account lockout, so you reconcile the two and come up with a new standard which everybody is meant to adopt.  Far more difficult are issues to do with internal failures and when/how they might ultimately require documentation in SEC filings. 

The security officer’s role in such negotiations is likely to be much less technical and more financial – building models to track costs, measure risk exposures, and the like – and the output from such efforts will probably end up on the desks of Legal and Accounting more so than IT or Operations.  Ultimately the decisions surrounding how to combine policies will be driven by business and risk considerations, first and foremost, but it’s a dangerous path for the acquiring firm simply to say the target firm shall inherit all the parent’s policies. 

This is primarily because the policies in place are usually a function of all sorts of local contextual issues, which are then mapped against whatever subset of industry best practices make sense for the business in question.  For example, if a development team is distributed globally while working on a single project, a firm needs to make a decision about using private WANs for data exchange, or instead, relying on local internet access at each facility and coupling that with a strong VPN.  If the immutable policy point at the acquiring firm says that no internal R&D data shall traverse the internet — and it was never written to consider whether VPNs are an acceptable carve-out — then the disruptive effect might be significant for all the IT and network teams which have to scramble to catch up. 

As with most things, there is no simple answer – the point is to ensure that M&A activities don’t simply assume “the IT stuff will sort itself out.”  The integration teams need to give an equal seat at the table to the security officer, the IT architect and whoever else is responsible for the glue that drives how the firms get things done behind the scenes.  It’s not just about operating synergies and reduced cost of sales anymore.

It is no surprise that mobile device security is becoming a growing concern for CSOs everywhere. Although mobile phones have been part of many companies’ communications strategy for quite some time, what has changed significantly in the last few years is the substantial increase in mobile device sophistication and emergence of targeted threats – both seemingly outpacing comprehensive and effective security measures.

Today’s mobile devices are exponentially more powerful and complex than those from a few years ago.  This combined with increases in inexpensive bandwidth and millions of available applications mean more people are using them for more complex tasks, which include a vast array of corporate information and application interactions. The opportunity to lose valuable data or expose corporate systems to unauthorized access has been considerably amplified.

Although there are some evolving security solutions emerging in the industry to address mobile device security, not all are comprehensive nor can they be referred to as “enterprise-ready.” Moreover, many large organizations may have as many as a dozen different mobile device platforms being used that represent a broad spectrum of diversity, further complicating meaningful security. Also, given today’s device capabilities, it is difficult to determine if a user is retrieving email, files or accessing applications from a computer or an unapproved mobile device.

Of course, all this is exacerbated by threats that specifically target mobile devices. Hackers are attracted to mobile devices because of the diversity of attack vectors and opportunity.  These fall into three basic categories:

• Access to information – There are numerous applications that promote mobile online banking, social networking, and, of course, files and e-mail stored on the device, all of which represent value to a hacker.  Moreover, many mobile devices are VPN-capable, which can open internal systems to undesirable interactions.
• Toll fraud – Hackers have produced several Trojans inserted in downloadable games and applications that surreptitiously dial international premium rate numbers that produce revenue for the hacker. Additionally, there are malware that permit eavesdropping and other forms of man-in-the-middle attacks.
• Leverage – An emerging condition is where hackers are implementing root kits and other forms of malware that are essentially creating a botnet within the mobile domain, which can be used for a number of purposes, such as DDoS and SMS spam.

Concerns about the exposure of private information and communications is very real. In fact, just in the last few weeks, the U.A.E. has sought to block Blackberry messaging and e-mail, and the German government, which has advised officials not to use Blackberry and iPhone devices due to a dramatic increase of attacks and fear of snooping, is advising civil servants to use Simko2 by T-Systems.  And unfortunately, it’s likely to get worse before it gets better.

So, what can you do?

First, focus on the basics: policy, access control, monitoring, and education. Try to minimize platform diversity within the organization, but this is far easier said than done. Seek mobile device encryption solutions — a lot of data loss can be attributed to simply users misplacing their phones. There are some good anti-virus solutions on the market that should be reviewed and tested; however, you may find you need more than one solution.

Lastly, use mobile device sophistication to your advantage!  Produce corporate applications to help employees — even something as simple as an app that provides updated mobile security policies employees can reference, or access to approved software, or something that can help identify the device as it accesses corporate systems, such as certificates, or a proxy app to route Internet traffic through dedicated security systems under your control.

Anything is better than nothing.  Use the same capabilities that are at the disposal of hackers to do harm, but do good.  You may not get ahead of the curve, but at least you can start leveling the battlefield.

In yesterday’s post, we discussed the reuse of malware. In today’s article, I want to focus on how botnet “breaking” is effectively a zero-sum gain, as most nodes previously rendered benign by DNS sinkholing have rejoined some other botnets [host recidivism].

The sophistication of the botmasters pales in comparison with the persistence of the problem.  An owner unable or unwilling to secure these hosts affords their systems to be cyber-magnetically drawn into some future botnet.  Call it magic or fate — no compromised system just sits there and serves up the connected monitor web advertisements for timeshares and Viagra, without simultaneously offering other services to a Botmaster.  Just because a host has not been engaged in a SPAM campaign or doesn’t have an active keystroke logger installed doesn’t mean that the ability is not resident within the rootkit installed.  In today’s market, ignoring bot earning potential is akin to leaving money on the table, from an organized crime point-of-view. 

A system not patched against MS09-123 is likely not going to be patched against MS10-123.  This is primarily because the decision to patch is most typically made by implementing and enforcing a policy that stipulates the process of perpetual patching for the lifecycle of that piece of software.  The merits of an individual patch and the situational risks surrounding the vulnerability at hand are less likely to come into play since so much software needs patching so frequently.  Modes of interaction of a vulnerability in a distinct piece of software cannot always be anticipated because the instantiations of that vulnerability (no matter how minor) in custom configurations and interactions with other objects are too numerous to fathom. 

End users are not typically engaged in formal policy adherence to their home systems — that is not the claim here.  However, the principle carries forward as those end users who roughly follow a best practice configuration seek out and engage offering by the specific vendors they use, most notably the automated processes allowing for silent and automatic patching of the software.  Whether the software belongs to Adobe, Microsoft or Apple, most major vendors offer means for systems online to update themselves before or shortly after vulnerable binaries are executed by the user. 

These (and formally documented) processes are made for repeatability.  So a missed patch is rarely as much as an oversight as it is another in a pattern of computer activity (really, lack thereof) that’s put into motion by actions that the responsible party made at the original installation of the software, up to and including the OS installed on that host. 

An example shown in a 2008 Computerworld article (“Update: Two-thirds of Oracle DBAs don’t apply security patches” [1/14/08]):

“The results, which come even as Oracle is scheduled to release its next batch of quarterly Critical Patch Updates tomorrow, showed that 206 out of the 305 surveyed said they had never applied any Oracle CPUs.  Just 31 said they had installed the most recent security update from the company.  In total, only one-third said they had ever installed an Oracle CPU.” 

Considering this survey deals with administrators who are skilled in technology, but may be fearful of uptime consequence by introducing the patch, it doesn’t bode well for end users who feel ambivalent towards their responsibility to update their systems.  Whether the cause of the updated state erosion is active or passive, recidivism is high for all of these hosts.

To read the full paper on Kraken, click here. 

Last month, we posted an article on the return of the Kraken botnet.  In addition to Kraken, the Storm botnets have also made a slight comeback on hosts once belonging to the recently decimated Mariposa Botnet.  Over the next several days, we will examine the technical issues surrounding the return of these botnets, with a focus on the following areas:

• The reuse of malware by persons of less technical sophistication than the original authors [lowering barriers to field entry]
• That botnet “breaking” is effectively a zero-sum gain, as most nodes previously rendered benign by DNS sinkholing have rejoined some other botnet [host recidivism]
• Pirated software is making the problem all the worse [piracy proportional to botnet size]

In this commentary, we’re covering the first area since there is plenty of evidence to support the claim that people of less technical sophistication than the original authors are reusing the malware.  Consider the attestation of Panda Security’s Pedro Bustamante:

“Our preliminary analysis indicates that the botmasters did not have advanced hacking skills.  This is very alarming because it proves how sophisticated and effective malware distribution software has become, empowering relatively unskilled cyber criminals to inflict major damage and financial loss.”

If the case were that Mariposa was a low tier botnet (say only 100,000 nodes), perhaps it could be explained away that script kiddy botmasters got lucky for a while.  They inherited well, or knew the “right people” in lieu of the “right stuff.”  However, this was not the case.  Mariposa was a 10^8 node botnet, and that, by any estimation, is a really big number. 

The position of the botmasters being N stages removed from the original authors supports the arguments that a botnet in itself is mercenarily a commodity.  To compare, entities that own the most barrels of petroleum at any given time are neither producing nor consuming petroleum.  They are “possessing it” in an assumption of risk (and hence profit) that comes from stewardship between the time it is made available and the time it is consumed by a refinery.  They don’t need to know details of either the production or distillation of the content, and they have no special skills (or at least display none) in either area.  This is similar to why these botmasters don’t need the same technical abilities that the authors of the original code exhibited.  Would a case be heard where the writer of Trojan software would sue a botmasters for financial loss or defamation??

It would be difficult to defend this position if Mariposa was not the single biggest documented botnet in the world back in January.  As skeptical as we are about actual numbers of nodes reported as participating in a single botnet — if the actual number was only 1/100 of the touted  number (which would be one hundred-thousand) — it would still be greater than the total number of computers in each of half the world’s countries.  Just consider that several people lacking technical sophistication, unaligned with any foreign government, were harnessing the power of a 3-gigawatt-per-hour computing center.*

   *  Calculations for emphasis only; assume 300W PSUs, 10 Million hosts online at a single time.

To read the full paper on Kraken, click here.

The National Security Agency recently unveiled a program to help secure the networks of crucial domestic infrastructure, including the networks of electrical companies and nuclear power plants. Called “Perfect Citizen,” the program is geared to bring attention to the possibility of grid hacking.

Interestingly, a recent Wired article asked, “…if it’s so easy to turn off the lights using your laptop, how come it doesn’t happen more often?”  According to the article (“Hacking the Electric Grid? You and What Army?” (July 13, 2010):

Your average power grid or drinking water system isn’t analogous to a PC or even to a corporate network. The complexity of such systems, and the use of proprietary operating systems and applications that are not readily available for study by your average hacker, make the development of exploits for any uncovered vulnerabilities much more difficult than using Metasploit.

To start, these systems are rarely connected directly to the public Internet. And that makes gaining access to grid-controlling networks a challenge for all but the most dedicated, motivated and skilled — nation-states, in other words.

Let’s pretend for a moment that hackers were planning to attack the U.S.  What would they need to do to gather enough information necessary to take out the electrical power in key parts of the country?  They don’t want to fiddle at the edges, mind you.  They want to have enough data to build the technical capability necessary to shut out the lights in Washington or New York or California at precisely the time and for exactly the duration they want.

For starters, they would need to know things like:  Where are the power plants?  What kind of plants are they? What sort of fuel do they use?  Who built them and when?  What sort of materials and technology were used when they were built?  Who manufactured the generators, turbines and other key equipment?  Whose SCADA software are they running?  Who runs the plants?  How does fuel, people, supplies get into or out of the plant? What sort of security do they have?  And perhaps most importantly: which plants supply power to which parts of the country?

While the Wired article included a lot of questions that are interesting, we ask: Are foreign attacks on our nation’s crucial infrastructure possible?  Our answer is absolutely. This is a real security threat and one that shouldn’t be taken lightly.

In fact, The New York Times reported last week that a new virus targets the computers used to manage large-scale industrial control systems used by manufacturing and utility companies. While the SCADA systems that run the software are not typically connected to the Internet, this specific virus spreads when an infected USB stick is inserted in the computer.

To assist these organizations, BT Managed Security Solutions Group offers a multi-layered, holistic approach to secure critical network infrastructure (CNI) and organizational monitoring. This offering enables any organization to have a view of its security posture as it relates to its critical infrastructure (substations, control centers, energy management systems) and its interconnectivity with the organization.

With a holistic approach, the footprints of an attack may be discovered across multiple systems or even across multiple operating areas.  As organizations merge to achieve economies of scale, disparate geographic operating regions become interconnected via common enterprise environments.  

In today’s regulatory-driven environment, an organization must consider its entire critical infrastructure – from the substation to the control center and out to the enterprise network – when making security monitoring decisions.

The fast and accurate detection of security-related events is an organization’s first line of defense against security intrusions.  This can only be achieved through a holistic solution that provides enterprise-wide security by aggregating and correlating information from both critical network infrastructure and enterprise networks, providing organizations transparency into their security posture.

Botnets, in general, are very dangerous and difficult to extinguish.  Within the past several weeks, we’ve learned the Kraken botnet has returned from the dead and is gaining strength yet again.

According to a recent Dark Reading article, the botnet—despite being dismantled last year — has recently compromised more than 318,000 systems.  That is nearly half the number reported at Kraken’s peak!

How does Kraken work?

Kraken came to the fore in 2008, after infecting hundreds of thousands of computers and causing them to send enormous numbers of spam emails.  While the authors of Kraken were arrested in 2009 and the network was disabled, the new Son-of-Kraken seems to be a variation which re-uses Kraken’s malicious code.  This code is propagated by a botnet framework – or butterfly framework – which is known for its efficiency in spreading such malware.  Some of you might remember another famous and large botnet, the Mariposa botnet, which also used the butterfly framework.

Detecting the “classic” Kraken

Botnets are difficult to prevent, and, once a network is infected, are even more difficult to detect.  If you are using anti-virus tools, Kraken is nearly impossible to detect.  AV defenses and anti-malware defenses are often disabled by bots during the original infection.  Therefore, IT professionals must gain network level detection applications.  Suspicious activities that can be used to detect a botnet include:

• DNS lookups to certain domains
• Traffic on unusual (typically high) port numbers
• Connections (or attempts) to IPs in a known range
• Network protocol violation in datagrams or sessions traversing firewall (e.g., encrypted traffic over port 80, or non-SSL over port 443)
• Excessive outgoing emails or other activity not usually associated with business traffic

But to assume you don’t have a botnet infection because there are no visible symptoms is a mistake.  Because bots seek to avoid detection, you need to constantly check firewall and IPS logs to unearth an infection.

Preparation is key

George Hulme said in a recent InformationWeek article, “One thing is certain: current methods of bot detection and remediation are not getting the job done.”

It’s essential that companies ensure they have maximum and continuous early-warning security measures in place to protect the integrity of their assets and mitigate risks.  For BT Managed Security Solutions Group (MSSG) customers, the good news is that a botnet detection module is a standard Managed Secure Monitoring service available to all customers.

BT MSSG has had significant success in using its customers’ firewalls to detect botnets through log analysis and event correlation.  Based on a fundamental understanding of botnet behavior, the BT team reasoned that since every botnet needs to call home at some point in order to be activated, outbound messages traversing a firewall will create detectable patterns of behavior that accurately indicate botnet activity before it has the opportunity to take over your network. 

One question remains — is your company prepared for the Son-of-Kraken?

There are a number of folks in the security industry who have downplayed the realities of cyberwar.  In some circles, the conversation of cyberwar will elicit some interesting reactions and many tend to deny its potency relative to traditional warfare and traditional weapons.

Moreover, many begin to blur the lines between cyberwar, cyberterrorism and other cyberattack scenarios, confusing the topic.  In virtually every conversation of this nature, I’m the one who stands out as the lone voice saying they’re not only wrong, but woefully underestimating the situation.

Throughout history, advances in weapon technology have dramatically changed the battlefield. Everything and anything that can be used as a weapon that offers even the slightest advantage over your enemy will be developed and deployed.

Folks… it is war.  Therefore, within this context, cyberspace has evolved from “advantage acquisition” to weaponization because the battlefield now includes the virtual domain.

Early uses of cyber assets mostly took the form of intelligence gathering to establish situational awareness and, of course, counter intelligence.  Moreover, technologies were employed to advance communications and support accurate mobilization of resources.  For example, the Joint Strike Fighter (JSF), as part of the next generation strike fighter, multi-variation platform F-35, has highly sophisticated computers and communications to align multiple forces for effective, real-time battlefield management.  Cyber has allowed for air, sea and ground assets to work together so there is a unified view of battlefield conditions and enemy activity.

The move to weaponization of cyber technologies is in full swing.  Initially, weaponization in cyberspace involved taking hacker tools and tactics and refining them to be more effective, not unlike riffling of cannon barrels.  It is converting something that is reasonably dangerous and can be generally targeted into a manageable device that can be consistently developed, effectively deployed, and accurately directed at the target.  And it produces the intended results by effectively exploiting vulnerabilities in the enemy’s defenses.

A simple example is malware, which comes in multiple forms with a wide range of impact potential.  However, much of what we experience today is indiscriminant because a common hacker’s mission is to infect any system and as many as possible to build a botnet for dishing out spam or causing havoc. Clearly, the concept is sound but is not conducive to the ultimate role of a weapon.

A meaningful aspect of weaponization is refinement so that it can be accurately targeted and its impact controlled.  Even malware in the wild has been weaponized, retaining its viral, self-propagating features; but it includes highly sophisticated methods to operate in a predictable manner and submit to in-flight commands to adjust to changes in the environment.

However, today’s weaponization has moved well into the development of completely new forms of cyberweapons.  Things that have been researched, developed, tested, and refined from scratch, creating completely new types of weapons – not unlike the hydrogen bombs of WWII – they are game changers.  These new weapons employ comprehensive targeting capabilities, have the ability to effectively navigate cyberspace, comprise a wide spectrum of impact control, and have multipurpose functionality that can change on command or autonomously, based on interpreted conditions.

Fundamentally, cyberweapons are no different from a guided missile.  But instead of traversing the physical domain, they travel across the virtual domain.  In fact, as I write this, DARPA (Defense Advanced Research Projects Agency) is developing (and have likely completed) a cyber range – an environment for test firing cyberweapons.

Make no mistake — weaponization of cyberspace is a reality.

Cyberwar is not your typical hacker attack.  The difference — cyberwar is when a cyberattack is launched or condoned by a country, as opposed to being performed by a group, such as a terrorist group or cyber-criminals performing acts of vigilantism or some skewed version of patriotism.

A cyberwar is considered a “hack” – using the term very loosely – by a nation, government, and/or military to harm other countries.  Granted, the lines are very blurry, especially when governments permit cyber-criminals to operate in their country or turn a blind eye, which can be construed as supporting the effort.  But in general, cyberwar is considered a military action funded and driven by an established government.

Cyberwar is sometimes confused with the recent advent of counties using cyberwar-like tactics for various purposes – such as espionage or general disruption.  For example, there is some evidence that the Chinese government was behind Project Aurora against Google and other companies.  Or the formation of China’s GhostNet, where more than a thousand computers in more than a hundred countries were infected, with more than 30% considered high-valued targets, such as computers in embassies, international organization, news media and ministries of foreign affairs, among others. These are examples of the escalation to cyberwar — blatant attacks against digital assets around the world.  It’s easy to see how these are examples of initial planning, testing of cyberweapons and information gathering.

Regardless, what we’re seeing today is not what I would call cyberwar, but more so cyberattacks that are testing the bounds of what is possible.  In some discussions, I’ve referred to attacks of this nature as live-fire weapons testing.

Cyberwar is scary because of a few interesting attributes that are a little different from traditional warfare as we generally understand it, making it somewhat complicated:

• There is a great deal of anonymity, generally referred to in cyberwar circles as the “attribution problem,” representing the deniability of the attacker.  Although there are technologies that help to identify the source of a cyberattack, they do not provide indisputable evidence, at least not in the eyes of the international community.  This attribute represents fundamental counterattack challenge.  In conventional war, the source point of a fired weapon or the location of a threatening weapon system is rapidly identified and quickly targeted for destruction.  In cyberwar, the attribution problem makes effective combatant identification nearly impossible.  You may be able to determine what systems are attacking and from what location, but this is not enough to attribute to the real enemy.
• Force multiplication uses resources that are not directly related to the attacking country.  For example, in conventional warfare there are tanks, planes and other assets directly associated with the attacking force and are therefore quantifiable targets.  In cyberwar, a country will likely take control of computing resources, such as hundreds of thousands or millions of personal computers around the world from which to launch an attack.  This too makes a counterattack extraordinarily complex and fraught with risk.  If not planned and executed with acute accuracy, a force could inadvertently take down a neutral country or ally.

These two simple and basic codependent features create an environment that is difficult to fully engage.  For example, assume that the United States imposes additional strict sanctions against North Korea as a result of the recent sinking of a South Korean vessel; and in retaliation, the North Korean government wages a cyberattack against the American financial system.  In doing so they utilize a vast network of commandeered computers in Brazil, Argentina, South Africa, France, Italy, Saudi Arabia, Ireland, the Netherlands, and Belarus to launch a well-planned attack through a complex web of command and control systems spread across a number of other counties.

Within minutes, the financial system begins to strain, automatic financial controls become engaged.  Within the next 24 hours the system fails.  The U.S. government has few options, if any, for an offensive.  Resources are directed to defensive tactics to stem the tide, establish protective measures to thwart the attack as much as possible and start recovery processes.  In short, the attacker is everywhere, including inside your environment.

You can’t simply start taking down systems because they may be owned by allies or may be your own systems working against you.  Meanwhile, the impact to the U. S. is not unlike if a bomb were dropped in the middle of a major city.  Therefore, in cyberwar there is a great deal of ambiguity and uncertainty, yet the level of impact is, on a very fundamental level, not all that different from an equally well-formed conventional attack.

This reality does impose a sense of fear that if truly understood and acknowledge throughout society would equal or even surpass levels of fear experienced during the cold war and the threat of nuclear annihilation.  It’s ultimately based on the feeling of helplessness and the inability to respond.  However, this is not entirely the situation that is evolving today.

In the coming weeks, we’ll continue on this topic.  In the meantime, please share your thoughts on this important topic.

For more on Jim’s thoughts on cyberwar, see: Cyberwar is a reality, but what exactly is it? 

You can’t pick up a paper, read a news article or scan a blog without something about cyberwar in there somewhere.  Moreover, there are a number of books surfacing and, conservatively speaking, a great deal of activity in the government sector concerning cyberwar.  While I’m working on a series of posts on this topic, I thought we should first try to define it.

In short, cyberwar is the use of technology to render some form of harm against an enemy.  Suffice it to say that we’re not talking about your typical hacker trying to steal credit card numbers.

Cyberwar is technically more of a statement of condition as opposed to a specific act, such as a battle or attack.  The term encompasses all the different forms of attacks, defenses and counter attacks that occur in the digital domain over time.  You hear some in the government make statements such as, “we’re in a cyberwar,” referring to the vast number of attacks against government and private networks and systems from distant entities. These forms of attacks are on the rise, and the United States is clearly making the necessary political and military adjustments to address such threats (more on this in future posts).

On the other hand, you hear a more accurate representation of a cyberwar as a future condition where cyberattacks will have devastating results that are analogous to what we would see in conventional warfare.  In many cases, experts will refer to situations where an attacking force would use “cyber weapons” to bring down the power grid, financial systems, communication networks and the like (e.g., critical infrastructure), rendering them unusable.

In this future, the difference between a cyberattack and a traditional attack is that the physical infrastructure remains generally intact.  For example, a bomb blowing up a critical power station clearly hinders the ability to distribute electricity until it is rebuilt, consuming time and resources. Conversely, a cyberattack will render the deeply integrated computing systems temporarily useless, also hindering the ability to distribute electricity.  Although the physical asset is unaffected in this scenario, the end result is very similar to a physical attack – electricity cannot be delivered to homes, businesses and other utilities for a period of time.

Of course, we have to acknowledge that a well-formed cyberattack can make computers perform dangerous acts that can manifest themselves as physical destruction.  An example would be opening waste gates on a sewer system to dump raw sewage into the environment; or redirecting trains, placing them on a collision course; or channeling electricity in a manner that overloads systems, such as lines and transformers, causing them to explode or become completely inoperable; or disrupting air and ground controls, greatly increasing the potential for a devastating accident.  

The list is very long. Think of all the computer controlled elements in our lives and about how the “logic” of their control could be manipulated to cause physical damage.

More importantly, we have to understand the condition and sensitivity of today’s major countries. During World War 2, it took a bomb to destroy an asset — such as a train, manufacturing plant, airfield, roads and bridges — to disrupt the stability of the enemy.  However, today there is far more sensitivity to disruption.

Let’s go back to the power station attack example.  If power was lost for an extended period of time, say two weeks, in key locations, such as New York, Chicago, San Francisco, Dallas, Atlanta, Boston, and the like, the United States would be brought to its knees.  Financial systems would strain to a point of failure, emergency services would rapidly become overloaded, products couldn’t be delivered, trains wouldn’t run, hospitals would be overrun, impassable traffic would form and people – many of them – would die.  Imagine if this occurred in the middle of winter or even summer – it would be a catastrophe.  Therefore, a cyberattack against the power grid doesn’t have to physically destroy the power grid to cause massive damage and disruption because there is very little resilience in how our society functions.  One critical aspect goes missing for a short period and the entire fabric begins to come apart.

This concept was demonstrated in the recent Icelandic volcano eruption that virtually halted all air traffic between the United States and Europe for weeks.  This cost airlines millions, disrupted the travel plans of hundreds of thousands of people, and stopped the delivery of perishable resources, such as donated organs.  The total cost in money and lives will never truly be known. Therefore, an attack against something like the power grid can cause mass disruption well beyond the targeted environment.

In the coming weeks, I will continue this series on cyberwar by writing about the “weaponization” of cyberspace and the cyber cold war.  And then I will elaborate on the future “theater of war,” setting the foundation for sharing views of what World War 3 could look like.

The term risk appetite is used frequently as a method to generally convey the level of criticality that must ultimately be interpreted, but rarely is this explored deeply.  There is a great deal of effort in defining risk and creating models as opposed to providing equal or greater focus on defining appetite, which is arguably the tipping point that determines the overall value of risk management to the organization.  The industry is so intensely focused on risk management theories and methods that it has virtually ignored the most important aspect – which is how the results will be digested.

For example, a risk report expresses several high, medium and low risk conditions. However, risk appetite governs which of those risks actually mean something to the company, group or person.  A low risk could be of great importance to one group and cursory at best to another.  Moreover, that condition may reverse in a short period due to business dynamics.

What I find interesting is risk acceptance — a formal confirmation from the business that the identified risk is absorbed.  But rarely are risk acceptance forms reevaluated, much less done so on a timeline that is reflective of the criticality level of the identified risk – a factor which completely ignores the importance of appetite and change in appetite over time.

A risk appetite model needs to be developed that defines a process by which appetite can be quantified relative to business conditions and deeply incorporated into the risk management paradigm.  Today, this mostly surfaces as evidence used in general discussion of appetite, such as policy statements and regulatory demands.  However, these can be seen as surrogates for appetite.

For example, how an executive interprets risk (their appetite) is “trumped” by a regulation because there are tangible impacts, such as fines or going to jail.  But not all risk results cleanly fit into these situations.  What happens today is often less focus on broad risks and stronger focus on divisional risk so that the results can be interpreted by one person that makes the final judgment call on appetite.  This process essentially avoids the problem by reducing the number of people who need to “make the call” and isolate responsibility.  In fact, this practice is typically the security group transferring political risk to a single person who actually makes a decision.

Security groups need to tackle risk appetite measurement as other industries have – specifically, the financial industry concerning risk appetite for investors, which is very interesting and has some meaningful formulas that could be used as the basis for security appetite measurement.  There have been what I would call attempts in security, such as ISACA’s case study using CobiT to define risk appetite.  

But as you can see, it’s still about measuring risk (i.e., high, medium, low), not necessarily specifically the interpretation of risk.  In other security circles it has been suggested to use Myers-Briggs, which is a very interesting starting point.  But others have suggested a litmus test using hypothetical scenarios to capture a perspective of risk relative to appetite.

While I agree with the concept, how the test is performed will determine the value of the data.  If the test candidates know they are being tested, the results will be skewed – and I’m not too sure executives want to be treated as lab rats.

Nevertheless, the point is simple — today’s risk management practices are good, but they can be a lot better if appetite is seen as important as threat, vulnerability, likelihood, and impact.  The good news is that people are thinking in these terms, but it has yet to take on legs.  

If you are aware of any models in the works, please let me know.

For more on Jim’s thoughts on risk management and risk appetite, see Part 1: What is your risk appetite? Counting security calories won’t help