The debate persists: Should the feds supply security oversight for utilities to stop the next Stuxnet? Or can they really go it alone?
In data security circles, Stuxnet is the stuff of urban legend. It's a legend, however, that shows no signs of wearing out its welcome or relevance.
In fact, Steve Kroft's recent broadcast report on the venerable 60 Minutes news magazine about that highly sophisticated, centrifuge-specific stealth virus that briefly upset the country of Iran's nuclear apple cart (so to speak) raises important questions for both the security and power-generation industries in North America. For example, could future malware modeled on Stuxnet target other critical infrastructure, such as nuclear power plants or water systems? Also, who should be responsible for detecting it--private industry or intelligence-gathering agencies within the federal government?
I guess that all depends on where your security bias lies and how your political dispositions shake out.
Taking the latter of those questions first (and presumably ripe fodder for the politicos among us), the Network World article in CSO, "Should U.S. Intelligence Agency Have A Role In Protecting Electric Grid?" related the ongoing cybersecurity legislation debate in Congress and why it's suddenly reaching fever pitch. Turning up the heat is whether our power companies (if forced) would be able to implement new federally mandated network protections, or whether the U.S. government and National Security Agency (NSA) should step in, deploy, and enforce the requirements and monitor the results.
According to this article, a catalyzing event for this debate was how NSA director General Keith Alexander was recently taken to the Obama administration's virtual woodshed over comments that argued for more legal authority to defend the nation against cyberattack. In effect, power companies would be required to perform continuous scanning with threat data provided by NSA and turn over any evidence of cyberattacks to the government. As you'd imagine, post-Orwellian era outrage about threats to privacy deservedly abound.
In a similar vein, sentiments from panelists assembled for the recent RSA Conference in San Francisco to discuss the topic of protecting the U.S. power grid ranged from the decidedly hands-off to those that favored more of a proactive approach.
Published: 2015-04-27 Multiple cross-site request forgery (CSRF) vulnerabilities in the (1) DataMappingEditorCommands, (2) DatastoreEditorCommands, and (3) IEGEditorCommands servlets in IBM Curam Social Program Management (SPM) 5.2 SP6 before EP6, 6.0 SP2 before EP26, 6.0.3 before 22.214.171.124 iFix8, 6.0.4 before 126.96.36.199 iFix...
Published: 2015-04-27 IBM Curam Social Program Management (SPM) 5.2 before SP6 EP6, 6.0 SP2 before EP26, 6.0.4 before 188.8.131.52, and 6.0.5 before 184.108.40.206 requires failed-login handling for web-service accounts to have the same lockout policy as for standard user accounts, which makes it easier for remote attackers to cause...
Published: 2015-04-27 The Jazz help system in IBM Rational Collaborative Lifecycle Management 4.0 through 5.0.2, Rational Quality Manager 4.0 through 4.0.7 and 5.0 through 5.0.2, Rational Team Concert 4.0 through 4.0.7 and 5.0 through 5.0.2, Rational Requirements Composer 4.0 through 4.0.7, Rational DOORS Next Generation...
Published: 2015-04-27 The SNMP implementation in IBM WebSphere Application Server (WAS) 8.5 before 220.127.116.11 does not properly handle configuration data, which allows remote authenticated users to obtain sensitive information via unspecified vectors.
Published: 2015-04-27 IBM WebSphere Application Server (WAS) 8.5 Liberty Profile before 18.104.22.168 does not properly implement authData elements, which allows remote authenticated users to gain privileges via unspecified vectors.
Join security and risk expert John Pironti and Dark Reading Editor-in-Chief Tim Wilson for a live online discussion of the sea-changing shift in security strategy and the many ways it is affecting IT and business.