Stuxnet, Duqu Date Back To 2007, Researcher Says

Two pieces of malware likely were developed by the same team on the same platform along with similar variants, according to Kaspersky Lab.

By Elizabeth Montalbano InformationWeek
December 29, 2011 01:22 PM

The origins of the dangerous Stuxnet computer virus that targeted Iran's nuclear power program last year could date back as far as 2007, according to new research. Researchers have dubbed the platform "Tilded" because its authors tend to use file names which start with "~d," said Alexander Gostav, head of Kapersky's Global Research and Analysis Team, in a blog post

Stuxnet and the related Duqu virus discovered earlier this year share a similar architecture and may have been developed by the same team of developers--along with other pieces of malware--several years ago, according to a security researcher at Kapersky Lab.

"There were a number of projects involving programs based on the 'Tilded' platform throughout the period 2007-2011," Gostav said. "Stuxnet and Duqu are two of them--there could have been others, which for now remain unknown."

Researchers discovered the connections between the pieces of malware and their origins by examining their drivers, he said.

Gostav warned that the Tilded platform is continuing to develop and more modifications of the viruses are likely to be a threat in the future.

Stuxnet was first discovered in June 2010 when it attacked software and equipment used by various organizations facilitating and overseeing Iran's nuclear program.

The virus was especially worrisome for researchers because of its unprecedented complexity; it contains more than 4,000 functions, which is comparable to the code in some commercial software.

Researchers at the Budapest University of Technology and Economics' CrySyS lab discovered Duqu this past September, saying the malware appears to have been designed to steal industrial control design documents.

After examining Duqu, researchers at Symantec said it was nearly identical to Stuxnet. Both viruses attack Microsoft Windows systems using a zero-day vulnerability, which tries to exploit application vulnerabilities that haven't been discovered yet.

Superworms like Stuxnet and Duqu--which seem to have been created to target the critical infrastructure and control systems of particular countries--are of great concern for federal cybersecurity officials who are working to prevent such dangerous threats to the U.S. power grid and other essential facilities.

Role-based access control based on least user privilege is one of the most effective ways to prevent the compromise of corporate data. Our new report explains why proper provisioning is a growing challenge, due to the proliferation of "big data," NoSQL databases, and cloud-based data storage. Download the report now. (Free registration required.)

(Source - http://informationweek.com)

Richard Stallman Was Right All Along

by Thom Holwerda on Mon 2nd Jan 2012 19:12 UTC

Late last year, president Obama signed a law that makes it possible to indefinitely detain terrorist suspects without any form of trial or due process. Peaceful protesters in Occupy movements all over the world have been labelled as terrorists by the authorities. Initiatives like SOPA promote diligent monitoring of communication channels. Thirty years ago, when Richard Stallman launched the GNU project, and during the three decades that followed, his sometimes extreme views and peculiar antics were ridiculed and disregarded as paranoia - but here we are, 2012, and his once paranoid what-ifs have become reality.

Up until relatively recently, it's been easy to dismiss Richard Stallman as a paranoid fanatic, someone who lost touch with reality long ago. A sort of perpetual computer hippie, the perfect personification of the archetype of the unworldly basement-dwelling computer nerd. His beard, his hair, his outfits - in our visual world, it's simply too easy to dismiss him.

His views have always been extreme. His only computer is a Lemote Yeelong netbook, because it's the only computer which uses only Free software - no firmware blobs, no proprietary BIOS; it's all Free. He also refuses to own a mobile phone, because they're too easy to track; until there's a mobile phone equivalent of the Yeelong, Stallman doesn't want one. Generally, all software should be Free. Or, as the Free Software Foundation puts it:

As our society grows more dependent on computers, the software we run is of critical importance to securing the future of a free society. Free software is about having control over the technology we use in our homes, schools and businesses, where computers work for our individual and communal benefit, not for proprietary software companies or governments who might seek to restrict and monitor us.

I, too, disregarded Stallman as way too extreme. Free software to combat controlling and spying governments? Evil corporations out to take over the world? Software as a tool to monitor private communication channels? Right. Surely, Free and open source software is important, and I choose it whenever functional equivalence with proprietary solutions is reached, but that Stallman/FSF nonsense is way out there.

But here we are, at the start of 2012. Obama signed the NDAA for 2012, making it possible for American citizens to be detained indefinitely without any form of trial or due process, only because they are terrorist suspects. At the same time, we have SOPA, which, if passed, would enact a system in which websites can be taken off the web, again without any form of trial or due process, while also enabling the monitoring of internet traffic. Combine this with how the authorities labelled the Occupy movements - namely, as terrorists - and you can see where this is going.

In case all this reminds you of China and similarly totalitarian regimes, you're not alone. Even the Motion Picture Association of America, the MPAA, proudly proclaims that what works for China, Syria, Iran, and others, should work for the US. China's Great Firewall and similar filtering systems are glorified as workable solutions in what is supposed to be the free world.

The crux of the matter here is that unlike the days of yore, where repressive regimes needed elaborate networks of secret police and informants to monitor communication, all they need now is control over the software and hardware we use. Our desktops, laptops, tablets, smartphones, and all manner of devices play a role in virtually all of our communication. Think you're in the clear when communicating face-to-face? Think again. How did you arrange the meet-up? Over the phone? The web? And what do you have in your pocket or bag, always connected to the network?

This is what Stallman has been warning us about all these years - and most of us, including myself, never really took him seriously. However, as the world changes, the importance of the ability to check what the code in your devices is doing - by someone else in case you lack the skills - becomes increasingly apparent. If we lose the ability to check what our own computers are doing, we're boned.

That's the very core of the Free Software Foundation's and Stallman's beliefs: that proprietary software takes control away from the user, which can lead to disastrous consequences, especially now that we rely on computers for virtually everything we do. The fact that Stallman foresaw this almost three decades ago is remarkable, and vindicates his activism. It justifies 30 years of Free Software Foundation.

And, in 2012, we're probably going to need Free and open source software more than ever before. At the Chaos Computer Congress in Berlin late last year, Cory Doctorow held a presentation titled "The Coming War on General Purpose Computation". In it, Doctorow warns that the general purpose computer, and more specifically, user control over general purpose computers, is perceived as a threat to the establishment. The copyright wars? Nothing but a prelude to the real war.

"As a member of the Walkman generation, I have made peace with the fact that I will require a hearing aid long before I die, and of course, it won't be a hearing aid, it will be a computer I put in my body," Doctorow explains, "So when I get into a car - a computer I put my body into - with my hearing aid - a computer I put inside my body - I want to know that these technologies are not designed to keep secrets from me, and to prevent me from terminating processes on them that work against my interests."

And this is really the gist of it all. With computers taking care of things like hearing, driving, and more, we really can't afford to be locked out of them. We need to be able to peek inside of them and see what they're doing, to ensure we're not being monitored, filtered, or whatever. Only a short while ago I would've declared this as pure paranoia - but with all that's been going on recently, it's no longer paranoia. It's reality.

"Freedom in the future will require us to have the capacity to monitor our devices and set meaningful policy on them, to examine and terminate the processes that run on them, to maintain them as honest servants to our will, and not as traitors and spies working for criminals, thugs, and control freaks," Doctorow warns, "And we haven't lost yet, but we have to win the copyright wars to keep the Internet and the PC free and open. Because these are the materiel in the wars that are to come, we won't be able to fight on without them."

This is why you should support Android (not Google, but Android), even if you prefer the iPhone. This is why you should support Linux, even if you use Windows. This is why you should support Apache, even if you run IIS. There's going to be a point where being Free/open is no longer a fun perk, but a necessity.

And that point is approaching fast.

(Source - http://www.osnews.com)

An Agile Approach to Change Management

Enterprise Change Management (ECM) provides a framework that addresses a variety of factors responsible for large-scale IT initiative failures. Dr. Myles Bogner and David Elfanbaum discuss how organizations can leverage ECM practices in conjunction with their Agile development teams to foster IT delivery adoption. - by Dr. Myles Bogner & David Elfanbaum.

CIO — Agile software development is designed to thrive within even the most dynamic business and technical environments. In fact, according to an article on the Web site of Martin Fowler, a well-known Agile industry leader, the name "Agile" was chosen because its founders viewed "adaptiveness and response to change" as the most essential concept of the methodology.

Figure 1 The Domains of Agile Methodology and Enterprise Change Management

All Agile methodologies include integrated practices and processes that manage evolving requirements to efficiently develop a continuous stream of new software capabilities. However, what Agile does not address are changes related to enterprise support of the Agile process or tasks that fall outside the scope of the project work, including:

• How to effectively manage an organization's internal personnel so that the appropriate stakeholders are available throughout the course of a project.
• How to gather and prioritize the most important features desired by the organization throughout the ongoing development cycle.
• How to adjust the notion of needing training in a continuous release environment.
• How to ensure customer team members are informed by the full breadth of stakeholders required for enterprise acceptance.
• How to secure timely approval of new technologies that a team would like to leverage.
• How to address stakeholder discomfort with cultural, business, social or other non-technical changes related to software implementation.

Each of these challenges is compounded when organizations operate multiple Agile projects simultaneously. Such unaddressed issues can cause IT projects to ultimately fail, even if executed perfectly within the scope of the development teams and meeting all project acceptance tests. On his blog, Jim Markowsky, an expert in change management, noted that the vast majority of large-scale IT initiative failures are actually caused by factors other than technology.

Enterprise Change Management (ECM) provides a framework that addresses many of these missing factors. This article focuses on how organizations can leverage ECM practices in conjunction with their Agile development teams to foster IT delivery adoption.

Enterprise Change Management (ECM)

Figure 2 Typical Stakeholder Gut Reactions to Change Initiatives

In their book titled: "The Heart of Change," John P. Kotter, a world-renowned speaker on leadership and the Konosuke Matsushita Professor of Leadership, Emeritus at the Harvard Business School, and co-author and consultant Dan S. Cohen, view the core pattern associated with successful change as "See-Feel-Change." To move stakeholders from the type of negative thoughts and feelings depicted in the image above, an ECM program must communicate a vision of the change that is compelling enough to not simply overcome negative preconceptions but also motivate positive participation.

Project and executive managers tend to treat those who will be impacted by software initiatives as if they were Vulcans, not humans. Of course, stakeholders are more like Kirk than Spock. Humans don't coldly and rationally evaluate information and form impressions based solely upon logic. Instead of withholding judgment on an impending change such as a new software initiative, people tend to make gut-level intuitive leaps that are often negative in nature, and resistant to new evidence to the contrary. This assumes, of course, that those impacted are even cognizant of upcoming changes. In "Switch: How To Change Things When Change is Hard," authors Chip and Dan Heath use the metaphor of "Rider, Elephant and Path" to describe three primary areas that must be addressed in change management.

The Rider is our inner Spock. A stakeholder cannot support a change until he or she can understand its purpose and the concrete changes that will likely occur. The type of 50-page technical documents and 100-element flowcharts that developers often create under a "waterfall" approach must be translated into clear, high-level infographics for non-technical stakeholders.

The Elephant represents our subconscious and emotional levels. ECM influences the elephant through communication that creates positive feelings and mitigates negative emotions such as mistrust, anxiety and anger. For instance, messaging may focus on how the change will solve an existing problem that vexes stakeholders.

The Path addresses the environment within which the change occurs, including changes to the physical environment such as the arrangement of office space, and processes or procedures such as kanban.

There are a number of formalized ECM models that have been developed to standardize change management within organizations, with processes and practices that support the entire lifecycle of a change initiative. The principles and activities described in this article can be adapted to any existing corporate ECM infrastructure. They can also be applied within organizations that do not yet have an established ECM process in place.

The Unique Enterprise Change Management Demands of Agile Software Development

Ironically, the more successful an Agile project is in rapidly developing new capabilities, the greater the ECM challenge may be. Although Agile's customer-led iterative approach significantly reduces the magnitude of changes related to each software release, it greatly increases theirfrequency. Instead of being asked to adapt to a single release that institutes a significant number of changes created within "waterfall's" typical multi-year release cycles, stakeholders must accustom themselves to an ongoing series of small, incremental releases every month or two.

Having an ECM program is especially important for enterprises transitioning to Agile from a phase-based development methodology. Corporate cultures that are accustomed to traditional development release cycles can be strained by a shift to more frequent releases and the ongoing interaction required by participation in the iterative process. There is a higher level of stakeholder involvement required throughout the development process. The impact of a new Agile implementation cuts across technology and functional groups, from top management down to the frontline worker. An ECM effort can help break down the organizational sensation of feeling burdened caused by the insistence of Agile teams for day-to-day customer involvement.

Introducing ECM to the Agile Team

Simply introducing basic ECM concepts to an Agile team can actualize the potential of existing Agile practices to foster positive change. For instance, customer-focused user stories and acceptance tests can be informed by ECM considerations. This new perspective can tangibly improve the way IT and business sides of an organization work together. The resulting synergies build a heightened level of trust and provide a means to measure and track success of not only the technical quality of software, but its acceptance by end-users .

If the customer already has an institutionalized change management practice, bringing ECM personnel into the Agile team's release planning process is a good first step. They will be able to anticipate potential change management issues related to a release and work with the team to synchronize their efforts. For customers who are transitioning to Agile from a traditional waterfall methodology, ECM involvement is a good tool to foster participation by business stakeholders.

When an organization is ready to integrate ECM tasks into an Agile software development project, securing an ECM subject matter expert for the team is the first challenge usually faced. If the organization has existing ECM expertise, personnel can be shifted onto an Agile team. If there are no available resources, it may be necessary to hire an ECM subject matter expert or send an existing team member through an ECM training program. Once staffed, a basic approach is to integrate ECM into the Agile development process by simply having ECM requirements progress through the same processes as technical requirements, including user stories, acceptance tests and the iterative development of deliverables. ECM team member and developers participate in the same customer planning meetings and stand-ups.

Take for example the implementation of a portion of a typical change management plan. In conjunction with an upcoming Agile software release, change management requirements might include:
• Create a stakeholder list.
• Create a series of surveys on stakeholder attitudes.
• Contact these stakeholders, and socialize the survey results.

Tasks required for the delivery of iteration can then be broken down into stories, for example:
• Make a list of stakeholders in a certain business group.
• Create a survey covering these specific questions.
• Create an analysis spreadsheet.

Creating ECM stories in the same manner as their development tasks deeply integrates change management into the Agile process. In fact, these stories can be created in a test-driven development manner. For the above story examples, a test could be written proving that:
• A stakeholder from the business group is included in the stakeholder list.
• A survey covers a specific required content item.
• The analysis spreadsheet has a correct column.

At the start of each iteration, these tests would initially fail and would begin to pass as these change management stories are fulfilled. ECM tests and their pass/fail state can be illustrated on the Agile teams' continuous integration dashboards. Making these dashboards available organization-wide provides all stakeholders maximum insight into teams' overall progress to heighten project awareness across the enterprise.

By integrating ECM into Agile development, the development team can escape the project stovepipe and extend its vision to the greater enterprise. Every veteran Agile manager has watched hopelessly as a project that met every customer requirement failed due to external factors beyond their control. Although ECM does not give the project team absolute control over its destiny, it can substantively expand the domain of its influence.

Dr. Myles Bogner is the Vice President of Research and Development for Asynchrony Solutions, Inc. He is an advocate and practitioner of Agile processes and continually guides teams to apply Agile techniques. David Elfanbaum is cofounder of Asynchrony Solutions, the "Geek Interpreter Guy" (aka Vice President of Marketing). For more information, visitasolutions.com and blog.asolutions.com

(Source - http://www.cio.com)