By Mike S
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.
By Mike S
I think I’m going to put this on a T-Shirt:
It always amuses me when companies pretend the obvious isnt true in their press releases. “Someone completely broke our system.” “Say that we have a lot of security.” “But it didnt work.” “Say it anyway; the press will just blindly report it.”
By Mike S
Interesting, but not surprising:
Conducted by Unisphere Research on behalf of Application Security Inc., the survey questioned 214 Sybase administrators belonging to the International Sybase User Group (ISUG) about their database security practices. The prevalent theme running throughout the survey was that most organizations lacked controls to keep database information protected across the enterprise.
“A majority of respondents admit that there are multiple copies of their production data, but many do not have direct control over the security of this information,” the survey report stated. “Only one out of five take proactive measures to mask or shield this data from prying eyes.”
There have been a number of high-profile incidents where production data wound up where the public could access it, without anyone in the organization realizing it. Make sure you know where your data goes!
One of the biggest problems is a lack of understanding of change management and patch management, according to the research. The survey found that 37 percent of respondents didn’t know or weren’t sure how long it takes to detect and correct unauthorized changes to the database.
About 35 percent of those surveyed said that they rarely apply security patches across their database portfolio or didn’t know how often patches were applied. Just under two-thirds of organizations do not have any kind of automated database configuration management or patch management tools employed.
PCI DSS requires patching of production systems monthly — what are these guys doing?
And this is is only the first step, experts say. A lot of organizations fail to properly audit their data to ensure that the policies and controls put in place are actually working. According to McKendrick, the recent survey found that only 16 percent of organizations perform regular database audits once a month. Another 32 percent say they don’t know how often audits are performed — or never do them at all.
By Mike S
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.”
By Mike S
Here we are again – our fourth installment of the DBIR series (sixth if you count the ’08 and ’09 mid-year supplementals). To our readers, it may seem like the 2010 DBIR published ages ago. To us, it feels more like yesterday. The expanding scope and increasing depth of the report makes it almost one continuous effort throughout the year. It is, however, a labor of love and we’re very glad to be sharing our research into the world of data breaches with you once again.
By Mike S
An interesting post, with interesting comments:
Security is hard enough when you have control of the hardware, operating system and software. Lose control of any of those things, and the difficulty goes through the roof. How do you ensure that the employee devices are secure, and have up-to-date security patches? How do you control what goes on them? How do you deal with the tech support issues when they fail? How do you even begin to manage this logistical nightmare? Better to dig your heels in and say “no.”
But security is on the losing end of this argument, and the sooner it realizes that, the better.
By Mike S
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.
By Mike S
Some years ago, I read that the next big shift in web development would be from hand-coding HTML (and everything that goes with webpages) to WYSIWYG editors doing all the coding behind the scenes.
Although that hasn’t fully been realized, can WYSIWYG-easy log analysis tools be on the horizon?
Further, yesterday I was trying to explain the state of the art of log analysis to a client (who looks to use his cool new technology for log analysis and SIEM), and I felt embarrassed to admit that, yes, “search” and “rules” are indeed the state of the art.
In other words, most of the analysis burden is on the tool USER BRAIN, not on the TOOL. They looked at me like I just wasted 10 years of my life, writing regexes and otherwise being a stupid monkey. Even things like profiling/baselining (example) or simple – and I mean SIMPLE – data mining (example, details) mostly stay on research drawing boards for ages.
By Mike S
It’s easy to forget, or be ignorant that, anything posted to the Internet will probably be publicly available forever after.
A program written by Ron Bowes, a security consultant at Skull Security, scanned all the listings in Facebook’s open-access directory and then compiled a text file that lists the information he uncovered. That data potentially exposes some Facebook users’ birthdays, addresses, phone numbers and more — but only because they chose not to keep those details private.
“All I’ve done is compile public information into a nice format for statistical analysis,” Bowes told the BBC. He explained that he had simply accessed the same information that’s available to search engines like Google, Bing and Yahoo — or the countless white-pages services available online.
Facebook users should also be aware that after they have changed their privacy settings, their old profile pages may still be publicly available because they are often stored (or cached) by search engines.
By Mike S
Watch those faillogs!
“The use of stolen credentials was the number one hacking type in both the Verizon and USSS datasets, which is pretty amazing when you think about it.”“We’ve observed companies that were hell-bent on getting patch x deployed by week’s end but hadn’t even glanced at their log files in months.” [given that password guessing – seen in logs – trumps vuln exploitation by such a wide margin, this should change. Will it? – A.C.]