04. November 2013 · Comments Off on Response to Stiennon’s attack on NIST Cybersecurity Framework · Categories: blog · Tags: , , , ,

In late October, NIST issued its Preliminary Cybersecurity Framework based on President Obama’s Executive Order 13636, Improving Critical Infrastructure Cybersecurity.

The NIST Cybersecurity Framework is based on one of the most basic triads of information security – Prevention, Detection, Response. In other words, start by preventing as many threats as possible. But you also must recognize that 100% prevention is not possible, so you need to invest in Detection controls. And of course, there are going to be security incidents, therefore you must invest in Response.

The NIST Framework defines a “Core” that expands on this triad. It defines five basic “Functions” of cybersecurity – Identify, Protect, Detect, Respond, and Recover. Each Function is made up of related Categories and Subcategories.

Richard Stiennon, as always provocative, rales against the NIST Framework, calling it “fatally flawed,” because it’s “poisoned with Risk Management thinking.” He goes on to say:

The problem with frameworks in general is that they are so removed from actually defining what has to be done to solve a problem. The problem with critical infrastructure, which includes oil and gas pipelines, the power grid, and city utilities, is that they are poorly protected against network and computer attacks. Is publishing a turgid high-level framework going to address that problem? Will a nuclear power plant that perfectly adopts the framework be resilient to cyber attack? Are there explicit controls that can be tested to determine if the framework is in place? Sadly, no to all of the above.

He then says:

IT security Risk Management can be summarized briefly:

1. Identify Assets

2. Rank business value of each asset

3. Discover vulnerabilities

4. Reduce the risk to acceptable value by patching and deploying defenses around the most critical assets

He then summarizes the problems with this approach as follows:

1. It is impossible to identify all assets

2. It is impossible to rank the value of each asset

3. It is impossible to determine all vulnerabilities

4. Trying to combine three impossible tasks to manage risk is impossible

Mr. Stiennon’s solution is to focus on Threats.

How many ways has Stiennon gone wrong?

First,  if your Risk Management process is as Stiennon outlines, then your process needs to be updated. Risk Management is surely not just about identifying assets and patching vulnerabilities. Threats are a critical component of Risk Management. Furthermore, while the NIST Framework surely includes identifying assets and patching vulnerabilities, they are only two Subcategories within the rich Identify and Protect Functions. The whole Detect Function is focused on detecting threats!! Therefore Stiennon is completely off-base in his criticism. I wonder if he actually read the NIST document.

Second, all organizations perform Risk Management either implicitly or explicitly. No organization has enough money to implement every administrative and technical control that is available. And that surely goes for all of the controls recommended by the NIST Framework’s Categories and Subcategories. Even the organizations that want to fully commit the NIST Framework still will need to prioritize the order in which controls are implemented. Trade-offs have to be made. Is it better to make these trade-offs implicitly and unsystematically? Or is it better to have an explicit Risk Management process that can be improved over time?

I am surely not saying that we have reached the promised land of cybersecurity risk management, just as we have not in virtually any other field to which risk management is applied. There is a lot of research going on to improve risk management and decision theory. One example is the use of Prospect Theory.

Third, if IT security teams are to communicate successfully with senior management and Boards of Directors, explain to me how else to do it? IT security risks, which are technical in nature, have to be translated into business terms. That means, how will a threat impact the business. It has to be in terms of core business processes. Is Richard saying that an organization cannot and should not expect to identify the IT assets related to a specific business process? I think not.

When we in IT security look for a model to follow, I believe it should be akin to the role of lawyers’ participation in negotiating a business transaction. At some point, the lawyers have done all the negotiating they can. They then have to explain to the business executives responsible for the transaction the risks involved in accepting a particular paragraph or sentence in the contract. In other words, lawyers advise and business executives decide.

In the same way, it is up to IT security folks to explain a particular IT security risk in business terms to the business executive, who will then decide to accept the risk or reduce it by allocating funds to implement the proposed administrative or technical control. And of course meaningful metrics that can show the value of the requested control must be included in the communication process.

Given the importance of information technology to the success of any business, cybersecurity decisions must be elevated to the business level. Risk Management is the language of business executives. While cybersecurity risk management is clearly a young field, we surely cannot give up. We have to work to improve it. I believe the NIST Cybersecurity Framework is a big step in the right direction.

 

31. July 2009 · Comments Off on Clampi malware plus exploit raises risk to extremely high · Categories: Uncategorized · Tags: , , , , , , , , , ,

The risk associated with a known three year old Trojan-type virus called Clampi has gone from low to extremely high due the sophisticated exploit created and being executed by an Eastern European cyber-crime group.

Just as businesses can differentiate themselves by applying creative processes to commodity technology, so now are cyber-criminals. Clampi has been around since 2007. Symantec as of July 23, 2009 considered the risk posed by Clampi as Risk Level 1: Very Low. I don’t mean to pick on Symantec. McAfee, which calls the virus LLomo, has the Risk Level set to Low as of July 16, 2009. TrendMicro’s ThreatInfo site was so slow, I gave up trying to find the Risk Level they chose.

The exploit process used was first reported (to my knowledge) by Brian Krebs of the Washington Post on July 20, 2009.

On July 29, 2009, Joe Stewart, Director of Malware Research for the Counter Threat Unit (CTU) of SecureWorks released a summary of his research about Clampi and how it’s being used, just prior to this week’s Black Hat Security Conference in Las Vegas.

Clampi is a Trojan-type virus which, when installed on your desktop or
laptop, can be used by this cyber-crime group to steal financial data,
apparently including User Identification and Password credentials used
for online banking and other types of online commerce. Apparently, this
Eastern European cyber-crime group controls a large number of PC’s
infected with Clampi and is stealing money from both consumers and
businesses.

Brian Krebs of the Washington Post ran a story on July 2, 2009 about a similar exploit using a different PC-based Trojan called Zeus. $415,000 was stolen from Bullitt County, KY.

Trojans like Clampi and Zeus have been around for years. What makes these exploits so high risk is the methods by which these Trojans infect us and the sophistication of the exploits’ processes for extracting money from bank accounts.

Security has always been a “cat-and-mouse” game where the bad guys develop new exploits and the good guys respond. So now I am sure we are going to see the creativity of the security vendor industry applied to reducing the risk associated with this type of exploit. At the most basic level, firewalls need to be much more application and user aware. Intrusion detection systems may already be able to detect some aspect of this type of exploit. We also need better anomaly detection capabilities.