Category Archives: Security

History, Poetry, Security

SMS protest language censored by phone companies in Uganda

Leave a comment

Reuters reveals an interesting African development related to protests in the Middle East and mobile communication:

Uganda has ordered phone companies to intercept text messages with words or phrases including “Egypt”, “bullet,” and “people power” ahead of Friday’s elections that some fear may turn violent.

“Messages containing such words, when encountered by the network or facility owner or operator, should be scrutinised and, if deemed to be controversial or advanced to incite the public, should be stopped or blocked,” he said.

[…]

The other English words or phrases on the list are: “Tunisia”, “Mubarak”, “dictator”, “teargas”, “army”, “police”, “gun”, “Ben Ali” and “UPDF”.

Bad idea. It will not work, not least of all because the black-list can be leaked; I see an impossible goal of staying abreast of slang and permutations already typical of SMS.

Who would type dictator when they can say tator, or tater, or tot? Who uses police when they can put cops, 5-0 or bobs? Wikipedia provides a list of euphemisms for police that covers every letter in the alphabet. I would use gas, or mace, or lach (short for lachrymatory), or pep(per), or RCA (riot control agent) instead of teargas.

I mean the obvious and historic defense is encoded language: the words gas and pepper have many meanings, and thus are hard to ban. This is a form of substitution. The key to decipher their correct (intended) meaning using message context or metadata. That easily defeats word-list censorship. How cool is that? Or should I say how radical? I’ve mentioned this before in terms of songs and poems like Kumbaya.

Security

EFF: Higher Stakes Brings Worse Security

Leave a comment

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”?

Security

Libya Internet Link Cut

Leave a comment

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.

Energy, History, Security

Stuxnet Failed to Stop or Delay LEU

3 Comments

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.