Tuesday, 12 July 2011

How Digital Detectives Deciphered Stuxnet, the Most Menacing Malware in History

Wired[1,2] has a really nice long write up on Stuxnet and how it was deciphered. It's a long and detailed article and makes for quite nice reading.

Bruce Schneier has also commented on it[3] as has Slashdot[4]. Sans also has coverage in their newsletter[5] along with some useful links[6,7].

Here's a blurb from the Wired article:

It was January 2010, and investigators with the International Atomic Energy Agency had just completed an inspection at the uranium enrichment plant outside Natanz in central Iran, when they realized that something was off within the cascade rooms where thousands of centrifuges were enriching uranium. Natanz technicians in white lab coats, gloves and blue booties were scurrying in and out of the “clean” cascade rooms, hauling out unwieldy centrifuges one by one, each sheathed in shiny silver cylindrical casings.

Any time workers at the plant decommissioned damaged or otherwise unusable centrifuges, they were required to line them up for IAEA inspection to verify that no radioactive material was being smuggled out in the devices before they were removed. The technicians had been doing so now for more than a month.

“We were not immune to the fact that there was a bigger geopolitical picture going on. We were definitely thinking … do I really want my name to be put on this?” – Eric Chien

Normally Iran replaced up to 10 percent of its centrifuges a year, due to material defects and other issues. With about 8,700 centrifuges installed at Natanz at the time, it would have been normal to decommission about 800 over the course of the year.

But when the IAEA later reviewed footage from surveillance cameras installed outside the cascade rooms to monitor Iran’s enrichment program, they were stunned as they counted the numbers. The workers had been replacing the units at an incredible rate — later estimates would indicate between 1,000 and 2,000 centrifuges were swapped out over a few months.

The question was, why?

To find the answers, read on... [1].

URL[1]: http://www.wired.com/threatlevel/2011/07/how-digital-detectives-deciphered-stuxnet/all/1
URL[2]: http://www.wired.com/threatlevel/2011/07/stuxnet-timeline/
URL[3]: http://www.schneier.com/blog/archives/2011/07/history_of_stux.html
URL[4]: http://news.slashdot.org/story/11/07/11/1958249/How-Investigators-Deciphered-Stuxnet
URL[5]: http://www.sans.org/newsletters/newsbites/newsbites.php?vol=13&issue=55#sID300
URL[6]: Long Link [www.win32virusremoval.com]
URL[7]: Long Link [www.telegraph.co.uk]

[/technology] permanent link

Saturday, 09 July 2011

Microsoft’s Android Shakedown - Timothy Lee - Disruptive Economics - Forbes

Forbes has a take[1] on the Patent system - nothing new here except that it's probably a lot more eye catching than the usual rants on Slashdot, considering the audience Forbes enjoys.

There's also this[2] from Ars Technica, a book review that is related to the same issue but a "Timothy B Lee" who could probably be the same person.

Will anything come of it? Keep hoping... Meanwhile here are a few snippets from [1]:

This story sheds light on the recent string of stories about Microsoft demanding royalty payments from various companies that produce smart phones built on Google‘s Android operating system. Intuitively, this doesn’t make much sense. Most people would say that Google has been more innovative than Microsoft in recent years—especially in the mobile phone market—so why is Microsoft the one collecting royalties?

The reason is that Microsoft has more patents than Google. A lot more. The patent office has awarded Google about 700 patents in its 13-year lifetime. Microsoft has received 700 patents in the last four months. Microsoft’s total portfolio is around 18,000 patents, and most of those were granted within the last decade.

Even if you think Microsoft is more innovative than Google, the engineers in Redmond obviously haven’t been 25 times as innovative as those in Mountain View. So why the huge discrepancy?

Getting software patents takes a lot of work, but it’s not primarily engineering effort. The complexity of software and low standards for patent eligibility mean that software engineers produce potentially patentable ideas all the time. But most engineers don’t think of these relatively trivial ideas as “inventions” worthy of a patent.

Creating such a bureaucracy has a high opportunity cost for small, rapidly growing companies. Most obviously, it requires spending scarce capital on patent lawyers. But it also means pulling engineers away from doing useful work to help lawyers translate their “inventions” into legal jargon. And that, in turn requires a shift in corporate culture. Startups are innovative precisely because they avoid getting bogged down in paperwork. Convincing engineers to pay more attention to patent applications necessarily means that they spend less time doing useful work, and that can be fatal to a young startup.

The opportunity costs to getting patents is much lower for mature software companies like Microsoft or IBM. They tend to have more money and engineers than they know what to do with. And their software development processes are already slow and bureaucratic. So it’s much easier to add a “fill out patent applications” step to the official software development process, and the negative effect on engineers’ productivity is much smaller.

URL[1]: http://blogs.forbes.com/timothylee/2011/07/07/microsofts-android-shakedown/
URL[2]: http://arstechnica.com/old/content/2008/07/book-review-7-08.ars

[/technology] permanent link

Friday, 08 July 2011

CWE - 2011 CWE/SANS Top 25 Most Dangerous Software Errors

A nice detailed list on the top security issues related primarily to software most of which can and should be addressed during development. With some good security practices and education, most developers and processes should be able to handle these kinds of issues as part of their development cycle.

Here's a brief excerpt from the site[1]:

The 2011 CWE/SANS Top 25 Most Dangerous Software Errors is a list of the most widespread and critical errors that can lead to serious vulnerabilities in software. They are often easy to find, and easy to exploit. They are dangerous because they will frequently allow attackers to completely take over the software, steal data, or prevent the software from working at all.

The Top 25 list is a tool for education and awareness to help programmers to prevent the kinds of vulnerabilities that plague the software industry, by identifying and avoiding all-too-common mistakes that occur before software is even shipped.

URL[1]: http://cwe.mitre.org/top25/index.html

[/technology] permanent link

Thursday, 07 July 2011

How to Design a Hot Product

A nice essay by the creator of the Flip (via Pogue's column on the NYT).

Here's a snippet from Pogue's Blog:

When Cisco killed the beloved Flip camcorder a few months ago, a lot of people were shocked and upset—including me. It just seemed like such a ham-handed, thoughtless way to terminate an iconic, very popular gadget.

I continue to read, online and in newspapers, that Cisco killed the Flip camcorder because the writing was on the wall: smartphones now have video capability, so nobody needs a standalone gadget.

I’ve written before on the topic of single-purpose versus multipurpose gadgets. But today, here’s an especially articulate essay on this subject. It’s a guest post from Nasahn Sheppard, director of industrial design at Smart Design, the company that designed the Flip camcorder itself.

Read it fully on Pogue's Posts (the comments are interesting as well) [1].

URL[1]: http://pogue.blogs.nytimes.com/2011/07/07/how-to-design-a-hot-product/

[/technology] permanent link

Wednesday, 06 July 2011

Writing a C library, intro, conclusion and errata

This is a series of blog-posts about best practices for writing C libraries. See below for each part and the topics covered.

Table of contents

The entire series about best practices for writing C libraries covered 15 topics and was written over five parts posted over the course of approximately one week.

An interesting series of articles on the nuances of writing a C library. There's a whole section of topics that are not discussed in detail but they too have some very interesting links and thoughts. Definitely a good and worthy read.

URL: http://davidz25.blogspot.com/2011/07/writing-c-library-intro-conclusion-and.html

[/technology] permanent link