According to press reports, a water utility’s SCADA network was hacked. The attacker turned a pump on and off too much, resulting in physical damage to the pump. This is an extremmely significant incident, for three reasons:
The attack actually happened.
Ordinary, off-the-shelf hacking tools were used, rather than something custom like Stuxnet
Physical damage resulted
This is the scenario that security people and the Dept of Homeland Security have been predicting for years. Sophisticated methods with 0-day vulnerabilities were not needed. When the FBI investigates, will the Curran-Gardner Public Water District (near Springfield, IL) be called out for lax security practices as was Nasdaq?
A federal investigation into last year’s cyber attack on Nasdaq OMX Group found surprisingly lax security practices that made the exchange operator an easy target for hackers, people with knowledge of the probe said. The sources did not want to be identified because the matter is classified.
The ongoing probe by the Federal Bureau of Investigation is focused on Nasdaq’s Directors Desk collaboration software for corporate boards, where the breach occurred. The Web-based software is used by directors to share confidential information and to collaborate on projects.
…investigators were surprised to find some computers with out-of-date software, misconfigured firewalls and uninstalled security patches that could have fixed known “bugs” that hackers could exploit. Versions of Microsoft Corp’s Windows 2003 Server operating system, for example, had not been properly updated.
This story is interesting on several fronts. First, we find out that when the FBI is brought into a criminal breach investigation, it evaluates the victim organization’s information security posture, i.e. is the organization following best practices? While this may be obvious, one might want to know what the FBI’s definition of best practices is.
Second, this leak could have a chilling effect on organizations’ willingness to report cybercrimes to the FBI. On the other hand, the breach laws in most states will most likely still compel organizations to report breaches.
Overall though, I believe the compounded loss of reputation from disclosing a breach and the disclosure of lax information security practices will increase organizations’ motivation to strengthen the latter to reduce the risk of the former.
While the core routers are known to the Tor team, bridges are “hidden” from the network and act as a way for users to get around Internet service providers who block access to Tor’s core network for one reason or another. A Tor bridge configured in Amazon’s EC2 environment would be available to route traffic from anyone who can reach Amazon over the Internet, concealing the true destination of a user’s Web traffic.
Tor Cloud will make it even easier for individuals within enterprises to bypass traditional internet security controls.
Branden Williams discusses applying the Chaos Monkey to information security.
We need more of the semi-controlled security events to keep our employees fresh and ready for the uncontrolled ones coming from the outside. Our version of the Chaos Monkey could do things like:
Interrupt backup routines
Phish employees
Hijack caller-id and place “trusted calls from IT” to unsuspecting users
Forward requests to common sites to look-alikes to see if employees are fooled
Pop up bad certificate errors
Offer new software packages as “security patches”
What features would you add into the chaos monkey?
The goal is improve the organization’s IT resilience. Incidents are inevitable. The question is, how will the organization respond? Practice will improve response.
Michal Zalewski presents two risks of a security metrics program – reduced adaptability and agility.
The frameworks for constructing security metrics often promise to advance one’s adaptability and agility, but that’s very seldom true. These attributes depend entirely on having bright, inquisitive security engineers thriving in a healthy corporate culture. A dysfunctional organization, or a security team with no technical insight, will not be saved by a checklist and a set of indicators; while a healthy team is unlikely to truly benefit from having them.
While I am surely no advocating against security metrics. it is worth noting the risks.