Steve Goodbarn

What do USB drives and electric meters have in common?

They can harbor malware.

Recently, attendees at a security conference received free USB drives from IBM that harbored malware.  The US military restricts the use of USB drives because of this threat potential.

There is relatively wide awareness of the risks with USB thumb drives, but electric meters?

The Last Watch Doghas a recent post about vulnerabilities in the smart grid, starting with electric meters:

At the 2009 Black Hat security conference, security consultancy IOActive reported that it was able to simulate a smart meter worm that infected about 15,000 home meters (out of 22,000 homes) and subjected the devices to the control of the worm’s designers. At the time, IOActive’s Mike Davis stated that, “the vast majority of smart meter systems use no encryption or authentication processes to prevent someone from uploading malicious software or turning meters on and off en masse.”

The smartgrid has greater risks. In 2007 the Idaho National Lab conducted the Aurora Experiment and was able to remotely control an electircal generator and force it to blow up. See the video: Staged cyber attack reveals vulnerability in power grid

Basically nothing has been done in the last three years to stop attacks like this.

Privacy vs marketing

There has been a lot of publicity lately about social networking sites using personal data for targeted marketing. See: Sites caught sharing secret data with advertisers, report says.

Google has gotten into the act in many ways, most recently with disclosures that they "mistakenly" gathered information from unprotected Wi-Fi hotspots as the gather street views for Google maps. This disclosure came to light after the German government started asking questions. See video below.
 

Adding encryption and passwords to WiFi networks is a no-brain-er, but this is just complicated enough that a great many people cannot or do not bother with it.

I think it is inevitable that we will have European-style privacy laws that restrict spying by social networking sites. We as individuals need to be sure the same restrictions apply to government and government-sponsored spying.

For the time being you should assume that anything in an email, on a web site, or on your phone is not private and act accordingly.

DNSSEC Deployment - two week delay in publishing the root zone trust anchor

Today ICANN and VeriSign announced a two week delay, from July 1 to July 15, 2010, in publishing the root zone trust anchor. See ROOT DNSSEC status update. According to the release:

The schedule change is intended to allow ICANN and VeriSign an additional two weeks for further analysis of the DURZ rollout, to finalise testing and best ensure the secure, stable and resilient implementation of the root DNSSEC production processes and systems.

This is a relatively small delay and is indicative of the cautious and meticulous approach that has been taken with the rollout. And it is less than 60 days from today. Many ISPs and other service providers appear to be still farther behind in their preparations for DNSSEC rollout.

For an easy to read primer on what is needed, see this post from Afilias on CircleID:  More Stepping Stones Before This Summer's Seminal DNSSEC Events. Note the length of time Afilias has been preparing for DNSSEC:

If you are an application provider, ISP, or a Top-Level Domain (TLD) registry thinking of DNSSEC deployment you should take this event as an actionable item and allow your technical teams time to participate in DNSSEC testing.

The next milestone will be the deployment of a validatable signed root. Signed TLDs will be able to submit their keys to the root zone after it is signed, creating a single, hierarchical, secure infrastructure, in contrast to the islands of trust we have today.

We have spent the better part of the past three years working closely with .ORG and the Public Interest Registry towards the deployment of DNSSEC in .ORG throughout the domain name system. This June, second level .ORG names will be able to submit their key information and be signed, which will propagate throughout the DNS, a first-ever in a major gTLD. We look forward to learning, sharing and helping the system become stronger across this and future DNSSEC deployments across the other TLDs we support.

Without adequate preparation for DNSSEC there are going to be problems with sites disappearing - perhaps only temporarily in most cases- from the web. For many entities even limited downtime is unacceptable and with service level agreements in place this could be very expensive for providers. But the alternative is loss of business to more secure vendors.

Federal DNSSEC deployment, or lack thereof

Richard Walker's article on SearchSecurity.com today Fed DNSSEC project going slowly highlights the lack of compliance with DNSSEC security guidelines within the Federal government.

Many federal agencies are struggling to meet Domain Name System Security Extensions (DNSSEC) security mandates, and full deployment across the government may take years, say government cybersecurity experts. Without protection, the dot.gov domain is vulnerable to attacks such as spoofing, cache poisoning or redirection of users to fake sites.

Issued in August 2008, OMB's memorandum for chief information officers required agencies to digitally sign their sub-domains by December 2009. About 80% of agencies missed that deadline, despite the fact that deployment of DNSSEC at the top-level dot.gov domain should have helped simplify lower-level domain signing.

In addition to the OMB mandate, agencies are under pressure to meet tougher DNSSEC requirements under the Federal Information Security Management Act (FISMA) in August. FISMA's DNSSEC-related rules apply "to all [dot.gov] levels and that's a lot more stringent," said Scott Rose, a computer scientist and DNSSEC project lead at NIST.

You can follow DNSSEC implementation status here. The FISMA rules referred to in the preceding paragraph apply to internal DNS and face a lack of full support by MicroSoft. It is almost certain that those requirements will also not be met .

DNSSEC is not easy but it can be very straightforward. In the context of the Federal IT budget the cost is lost in rounding. Implementation done manually is risky and without highly secure key management will introduce new security risks. But there are solutions that take most of the headache away.

The failure to implement DNSSEC is due to a lack of leadership and overall project management.

As noted above, The Office of Management and Budget, which is under Whitehouse.gov, is the author of the memo requiring DNSSEC implementation (see the 2008 memo). Yet OMB and the White House are not in compliance. Agency IT directors, who face all manner of IT budget and operational challenges, will not take these requirements seriously when the author does not follow or enforce their own rule.

A small group of network and DNSSEC consultants could carry out DNSSEC implementation government-wide in a matter of months. The benefits would include trouble shooting network issues, training IT staff, and auditing compliance with OMB and FISMA security and operating requirements. All of this could then be reported back to appropriate parties within NIST, OMB and the Cybersecurity Coordinator. It's not rocket science and it would cost less than a few hours of interest on the national debt.

DNSSEC seems to have been overlooked in the drive for Faster, Smarter Cybersecurity.

Considering the news from just a week ago that Hacked US Treasury websites serve visitors malware (see here for more detail), it would be great if citizens could know for sure that they are reaching the appropriate Federal agency website and not contaminating heir PC or smartphone with malware. This problem would be largely resolved if we had authentication in place that we will get with DNSSEC.

DNSSEC implementation goes smoothly; no Cinco de Mayo disasters

Several articles warned about potential network and firewall issues that could have been triggered by the switch over of the last of the 13 root servers to DNSSEC on May 5 (see the ICANN blog for more details on this roll-out). I had a post on this topic in April.

It appears the transition went very well, with no major reported outages or other problems.

However unlikely it could have been that DNS was a factor in yesterday's stock market fiasco, I decided to wait a day before writing this post - just to be sure. We have a lot bigger worries than the well-managed DNS.

The next milestone will be July 1, 2010 with DNSSEC entering production in the root zone and publishing the root zone trust anchor. This is less that 2 months away!