So again: Palin’s AOL account was hacked because it used publicly-known answers for password-retrieval questions, a common/known exploit exposed users on O’Reilly’s site, and password-reuse by users exposed their other personal accounts.
On September 19, 2008, hackers from the Anonymous collective attacked the website of Fox News host Bill O’Reilly. The hackers found and immediately posted e-mail addresses, passwords, and physical addresses of 205 O’Reilly site members paying $5 a month to hear Bill’s wisdom. The next day, a distributed denial of service (DDoS) attack hit the site with 5,000 packets per second. That night, another attack flooded two O’Reilly servers with 1.5GB/s of data.
The attack itself wasn’t particularly clever, but it was effective. Billoreilly.com’s administrative interface was protected by a servlet that locked down access to all back-end material, but the site administrator made one small mistake: he once created a “New premium member report” showing a list of the most recent subscribers, and he created it in such a way that it bypassed the servlet. As later FBI interview notes show, this was “just an error”—but it made the new member report available outside the secure admin structure to someone who knew the location.
The attackers took the name at the top of the list, an account registered only one hour before, and used it to log into the O’Reilly site as a check of the data’s accuracy. The information was then posted to Wikileaks and discussed on 4chan. Three O’Reilly members who had used the same password on multiple other sites experienced additional fraudulent use of that information.
The article doesn’t differentiate whether the portion of Bill’s site that was hacked contained cardholder data, so I don’t know if this will be considered a breach meriting PCI DSS penalties. But it’d be quite embarrassing for Bill if his site now has to post the “We’ve been hacked!” banner.
via Exclusive: How the FBI investigates the hacktivities of Anonymous.
According to the study, 64 percent of PCI DSS-compliant organizations reported suffering no data breaches involving credit card data over the past two years, while only 38 percent of noncompliant organizations reported suffering no breaches involving credit card data over the same period. When it comes to overall data breaches (general incident or those involving credit card data), 63 percent of compliant organizations suffered no more than a single data breach, compared with 22 percent of noncompliant organizations. Notably, 26 percent of noncompliant organizations suffered more than five breaches over the same time period.
It is fantastic that taking certain, specific, minimum steps to establish a secure environment actually decreases breaches.
Also notable is the fact that DSS is a private, voluntary initiative with noteworthy results.
“In an era where governments are struggling with the creation of vague yet complex data protection acts, the credit card industry took a bold step toward regulating itself, using plain language, clear goals and a pragmatic focus,” said University of Connecticut School of Business professor Robert Bird. “PCI isn’t perfect—but it succeeded by imposing security mandates and forcing attention on data security, all without government regulation.”
via PCI DSS-Compliant Companies Suffer Fewer Data Breaches: Report – Midmarket – News & Reviews – eWeek.com.
It is a lot more work to play catch-up-on-security every 3 – 6 months than to implement security and live by it every day.
What is the business value for an organization to become and remain compliant?
A new study conducted by the Ponemon Institute and sponsored by security solutions provider Tripwire provides some pretty enlightening – if not surprising – answers. The study, a review of security investments made over a 12-month period at 46 global companies, found that organizations that regularly review and maintain compliance with leading industry security standards and regulations spend about three times less annually than organizations that fall out of compliance. Most compliant organizations spend an average of $3.5 million annually on security while non-compliant organizations spend an average of $9.4 million.
“For those who do not do internal audits, the total cost of compliance is higher. They are likely doing manual work to get to ‘check-box’ compliance….They are doing the bare minimum and, when the external audit is over, they are back to business as usual and their systems are no longer in a compliance state, which makes them just as vulnerable as they were before the audit, so the cost of compliance is high”, Shenoy told Infosecurity. Every company, regardless of industry, is spending money for compliance, but not all are getting secure, Shenoy says. “It was the ones that invested in security practices that were reaping the benefits – those that focused on securing the business, rather than focusing on compliance alone. It does pay to be in a constant state of compliance.”
via Study: It Pays to be in Compliance with Information Security Standards and Regulations | Sword & Shield Enterprise Security, Inc..
Policies and procedures are useless if no one is aware of them. But even better than satisfying mandatory training requirements is setting up systems so that users cannot violate policy, while still being able to perform their jobs.
“Often employees think someone at a higher level is taking care of their data security when in fact the employees are really a major part of the security processes,” he said.
“While on the surface this doesn’t affect the company, the lapse in judgment shows that employees don’t even know how to secure their own information, let alone the company’s data,” Spinosa said. “It also illustrates a problem where employees may be assuming that protections are in place when they aren’t.”
via Computer security awareness training could prevent some data loss, experts say.
I like changes for clarification of existing policies.
The Payment Card Industry Security Standards Council plans to make minor changes in the next iteration of PCI DSS, making clarifications on secure coding and key management and a change that recommends merchants use data discovery tools to find cardholder data prior to a PCI assessment.
The PCI Council issued a high-level summary document reflecting nine changes to appear in PCI DSS 2.0 and three changes to the PA DSS 2.0. A detailed summary of the changes will be issued along with pre-release versions of the standards in September.
PCI Council general manager Bob Russo reiterated that the proposed changes are minor and don’t offer any new requirements for merchants. Clarifications change the wording in PCI DSS to portray the intent of a requirement, Russo said, while changes that provide additional guidance help people better understand a requirement.
via PCI Council to address secure coding, key management in PCI DSS 2.0.
The PCI Security Standards Council released a document Aug. 12 outlining proposed clarifications to be added to the future version of industry regulations.
The PCI SSC document highlights several revisions slated to appear in the 2.0 versions of PCI DSS (Payment Card Industry Data Security Standard) and PA DSS (Payment Application Data Security Standard). More detailed documentation will be issued in September, and the new versions of the regulations will be published Oct. 28. Once approved, the regulations will go into effect in January.
via PCI Council Outlines Proposed Changes – Security from eWeek.
If you’re not familiar with CloudAudit.org:
CloudAudit and the Automated Audit, Assertion, Assessment, and Assurance API (A6)
The goal of CloudAudit is to provide a common interface and namespace that allows cloud computing providers to automate the Audit, Assertion, Assessment, and Assurance (A6) of their infrastructure (IaaS), platform (PaaS), and application (SaaS) environments and allow authorized consumers of their services to do likewise via an open, extensible and secure interface and methodology.
Now, via Anton Chuvakin Blog – “Security Warrior”: CloudAudit Delivers – Cloud Compliance Maps:
CloudAudit delivers it’s first batch of cloud compliance specifications. Quoting from the announcement:
“The CompliancePacks map control objectives to specific namespace entities which are contained below and feature NIST SP800-53, PCI DSS, HIPAA, ISO27002 and COBIT compliance frameworks. Ultimately these directories are where a Cloud Provider will store and secure the assertions and supporting materials related to each compliance framework or assertion.” [<- the bold part is kinda the whole point 🙂
If you’d like to audit your cloud, give it a read.