Vulnerabilities / Threats
8/18/2011
08:55 AM
Connect Directly
RSS
E-Mail
50%
50%

3 Security Lessons From BART's Anonymous Breach

As BART continues to face attacks from the hacker group Anonymous, its security weak points have become painfully obvious. Here's what your IT staff can learn from BART's mistakes.

10 Massive Security Breaches
(click image for larger view)
Slideshow: 10 Massive Security Breaches
An attack on Bay Area Rapid Transit websites by the hacker collective Anonymous this week drew international attention for political reasons. But these intrusions are catching the interest of IT pros for professional reasons, since the weaknesses in BART's IT security are by no means unique to the transit authority.

On Sunday, Anonymous appeared to have attempted a denial of service attack on BART.gov, the agency's primary site, to little effect, but did manage to breach a secondary site, myBART.org, and released the private information of BART customers on an Anonymous website. On Wednesday, the group compromised the BART Police Officers Association site, again publishing private information from the database of BART police officers.

So what can IT admins learn from looking at BART's security crisis? Plenty. Here are the three biggest lessons from BART's ordeal.

1. Use Strong Passwords

This one's so basic that every enterprise IT worker who reads it might feel inclined to roll his or her eyes right now, but face it: Too many of us aren't doing the job. If the Wednesday hack on BARTpoa.org demonstrated anything, it's that far too many users are allowed to jeopardize the organization's security with flimsy passwords that any 9-year-old could break via a crude dictionary attack.

Yes, users gripe loudly when you enforce sound password security policy, but holding the line on strong passwords eliminates one of the most basic security threats any network faces. Standard rules apply: at least eight characters, at least one number, a capital, and a punctuation mark.

2. Reign In Outside Sites

After the latest breach, BART officials demonstrated an appalling lack of authority over the weakness of the compromised sites. In an interview with NPR, BART police chief Daniel O. Hartwig repeatedly passed the buck, emphasizing that the hacked sites were not operated by BART.

"When you have a site that's not controlled by the BART district and/or owned and operated by the BART district, that would fall back on the administrators and operators," Hartwig said.

While it's far from clear that Hartwig's comments reflect BART's overall IT security policy, his words betray a lack of concern for security of the organization's data, wherever it may reside. By allowing so much of its customers' and employees' data to reside outside the control of its own IT organization, BART abdicated responsibility for the security of that data.

Enterprise IT organizations know this story all too well, and diligent IT pros constantly fight the good fight to keep data assets securely within the company's control, even when working with third parties. BART failed to protect its workers by vetting the security of its third-party sites, and now it's reaping the consequences.

3. Respond Swiftly And Proactively

As of this writing, BART and its affiliates have sustained nearly a week of threats attacks from Anonymous, and the transit district's passengers and workers have taken the brunt of the attack thanks to repeated security failures.

It's unclear whether BART's IT staffers could have intervened quickly enough to prevent any data from leaking out, but the agency could almost certainly have shored up its defenses by moving quickly to lock down its security gaps (and those of its affiliated sites) when it first got word of the threat. Had BART issued a demand that all workers and members of its third-party sites take a moment to examine and beef up their security last Friday, the press would likely be telling a somewhat less depressing story about them today.

Ultimately, as they say, hindsight is 20/20. There's a lot BART could've done differently to protect the privacy of its employees and customers, and it won't help them to dwell on what could've been. But for the rest of us, watching these events mindfully can be a very helpful lesson in IT security best practices.

At a full-day virtual event, InformationWeek and Dark Reading editors will talk with security experts about the causes and mistakes that lead to security breaches, both from the technology perspective and from the people perspective. It happens Aug. 25. Register now.

Comment  | 
Print  | 
More Insights
Register for Dark Reading Newsletters
White Papers
Cartoon
Current Issue
Dark Reading Must Reads - September 25, 2014
Dark Reading's new Must Reads is a compendium of our best recent coverage of identity and access management. Learn about access control in the age of HTML5, how to improve authentication, why Active Directory is dead, and more.
Flash Poll
Video
Slideshows
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2012-5485
Published: 2014-09-30
registerConfiglet.py in Plone before 4.2.3 and 4.3 before beta 1 allows remote attackers to execute Python code via unspecified vectors, related to the admin interface.

CVE-2012-5486
Published: 2014-09-30
ZPublisher.HTTPRequest._scrubHeader in Zope 2 before 2.13.19, as used in Plone before 4.3 beta 1, allows remote attackers to inject arbitrary HTTP headers via a linefeed (LF) character.

CVE-2012-5487
Published: 2014-09-30
The sandbox whitelisting function (allowmodule.py) in Plone before 4.2.3 and 4.3 before beta 1 allows remote authenticated users with certain privileges to bypass the Python sandbox restriction and execute arbitrary Python code via vectors related to importing.

CVE-2012-5488
Published: 2014-09-30
python_scripts.py in Plone before 4.2.3 and 4.3 before beta 1 allows remote attackers to execute Python code via a crafted URL, related to createObject.

CVE-2012-5489
Published: 2014-09-30
The App.Undo.UndoSupport.get_request_var_or_attr function in Zope before 2.12.21 and 3.13.x before 2.13.11, as used in Plone before 4.2.3 and 4.3 before beta 1, allows remote authenticated users to gain access to restricted attributes via unspecified vectors.

Best of the Web
Dark Reading Radio
Archived Dark Reading Radio
In our next Dark Reading Radio broadcast, we’ll take a close look at some of the latest research and practices in application security.