Category Archives: Security

EFF: Higher Stakes Brings Worse Security

A blog post by the EFF has a curious phrase towards the end:

…the higher the stakes, the worse the security…

Sample size? The author clarifies that “worse” means “easily resolved”. This seems to assert a shade of negligence — a decision to not fix security even when it is easy. He tries to explain why this would happen:

I suspect the reason for this pattern is that organizations that handle life, health, and money do not think of themselves as software engineering organizations, and so seek to minimize engineering costs. Additionally, engineering-driven companies tend to be disruptive newbies who have not yet made a big enough impact on the market to control much important information.

I find his analysis lacking for at least a couple reasons:

  1. Organizations that handle life, health and money do in fact think of themselves as innovators, not to mention software engineering organizations. Investment firms, for example, or research hospitals often have talented staff dedicated to inventing and building software and hardware.
  2. Engineering-driven companies are not all “newbies”. They have been around for decades and they too have grown old.

My personal experience does not resonate with the EFF. Perhaps what the author is trying to say is more in line with what President Clinton described in his keynote speech at the RSA Conference today: “it is easier to think about solutions in developing nations than developed ones.” I resonate more with that.

Higher stakes (higher asset value) do not automatically bring worse security, in my experience. I have found environments that embrace change are easier to secure because they welcome regulation and will pay for innovative solutions. Conversely, those that resist regulation and fear change fall behind on some forms of security fixes. They tend to demand extensive risk-based analysis and cost predictions before they are willing to agree to apply even “easy” security fixes.

A developed environment, if I can borrow the term, is unlikely to allow a Windows XP-based system to be upgraded to Windows 7 when the system is critical (to life, health, money, etc.). The FDA may not allow any “easy” resolution of a security issue unless they have thoroughly tested for other potential harm. That is why “better security” is not typically measured only on whether a problem is “easily resolved” — resolution can introduce other unforeseen and greater problems that threaten the valuable assets.

The delays may drive an IT security professional mad because it seems incredibly slow compared to an easy fix for the problem they see. Yet, this is an opportunity in security to reflect upon greater principles and exercise caution: will an expedient change always bring “better security”?

Libya Internet Link Cut

At the RSA conference I ran into a Renesys speaker and he introduced himself to me as “we’re the company that broke the Egypt story on the Internet cut”. I asked whether Bahrain would go the same way. He skipped right past the prediction and instead said “It’s not the same right now, not at all. All their routes remain online and stable despite traffic fluctuation.” Of course I can respect this — it is much safer to report current events than predict new ones. Libya, for example

Renesys confirms that the 13 globally routed Libyan network prefixes were withdrawn at 23:18 GMT (Friday night, just after midnight Saturday local time), and Libya is off the Internet. […] We wondered whether anyone would repeat Egypt’s strategy. Tonight, it appears that we have our answer.

Yes, we do. Bahrain still is able to directly upload video.

Stuxnet Failed to Stop or Delay LEU

Three days ago an updated report by the Institute for Science and International Security (ISIS) was published with the following conclusion:

While it has delayed the Iranian centrifuge program at the Natanz plant in 2010 and contributed to slowing its expansion, it did not stop it or even delay the continued buildup of LEU [low enriched uranium]. […] At the time of the attack, the Natanz FEP contained a total of almost 9,000 IR-1 centrifuges. The destruction of 1,000 out of 9,000 centrifuges may not appear significant, particularly since Iran took steps to maintain and increase its LEU production rates during this same period. […] One observation is that it may be harder to destroy centrifuges by use of cyber attacks than often believed.

They suggest that the malware was injected into systems in the supply-chain for Natanz.

Because of sanctions and trade controls, Iran operates international smuggling rings to obtain industrial control equipment, including the Siemens 315 and 417 PLCs. Although foreign intelligence agencies could infect or sabotage these PLCs abroad, they would have far greater chance of ultimately infecting Natanz by inserting Stuxnet in the core of Iran’s supply chain for the centrifuge program’s control systems.

This points strongly to an outsider cut-off from direct site access yet influential, which echoes a CIA method claimed to have caused the trans-Siberian pipeline disaster in 1982. On the other hand, it is said the attackers monitored and continued to modify Stuxnet, almost as if they had inside access and knowledge of their progress:

Symantec has established that Stuxnet first infected four Iranian organizations in June and July 2009. After the 2009/2010 attack, and before Stuxnet’s public discovery, the malware’s operators tried to attack again. Symantec found that in March, April, and May 2010, two of the original organizations were again infected. In May, a new Iranian organization was also infected. Were the Stuxnet operators dissatisfied with destroying only 1,000 centrifuges, or were they encouraged by their success? In any case, they were improving the code’s ability to spread by the spring of 2010, according to Symantec. These improvements undoubtedly sought to enable the program to again breech Iran’s security on its gas centrifuge program and destroy more centrifuges.

The report points out that the level of knowledge required for the attack had to come from a plant insider, but that the attack vector is more likely to have been from an outsider. The blended approach of Stuxnet emphasizes a loss of secrecy in their program, which may significantly affect Iran’s management of their nuclear effort far more than damage to controllers and centrifuges. The objective may have not been destruction but rather to demonstrate the sophisticated level of information leakage.

Cloud SMaaS (Sloppy Meat as a Service)

I just noticed that a reporter had contacted the company in Beijing cited by McAfee as a source of attacks in their Night Dragon report. It was sometimes called Sloppy Night Dragon because the attacks were not well concealed. I started to call it Operation Sloppy Joe because McAfee said the perpetrators were “company men”.

The Associated Press really has the scoop on why it could have been anyone on hosted servers rather than company men:

Song said hackers using his company’s services had an estimated 10,000 “meat computers” controlled remotely without the owners’ knowledge. He said “yes” when asked whether such activities might be improper but he said Chinese authorities never have contacted him about them. He hung up the phone when a reporter asked for other details.

He’s a service provider of meat computers used in Operation Sloppy Joe?

If only I had known sooner…the world is being attacked by “sloppy meat as a service”.

But seriously, that could be a really bad translation.

肉 (pronounced “zh-rou“)

noun
1. meat
2. flesh
3. beef

Maybe he said something like I provide “beefy” computers, or “meat” is Chinese slang for big and powerful if less literally translated. I doubt he said he has fleshy computers, although even that has a plausible translation — easily commandeered.

I bet the provider in Beijing even offers sub-levels of Chinese SMaaS:
1) Rare – infrastructure (RSMaaS)
2) Medium – platform (MSMaaS)
3) Well-done – software (WSMaaS)

Rumor has it that #3 is available with BROCCOLI (Binary Rootkits and Computational Compromise of Logical Information)