3 Rules of Incident Response for Public Affairs
There are three basic rules that every public affairs official, marketing officer, or other type of spokesperson should really follow when addressing any sort of computer security incident.
The First Cardinal Rule of Incident Response is a simple one: Don't Deny It or Make Assurances
The Second Cardinal Rule of Incident Response is equally simple: Know Who You're Dealing With.
The State Government of Rhode Island learned these rules the hard way after it was alledged that their state website (http://www.RI.gov) was cracked and leaked credit cards. Their PR spokesperson - probably not the best person to be making public statements following an IA incident - publicly stated that the cards were encrypted and that they had always been PCI compliant. Witness there the failure of Rule Number ONE. Unfortunately for her, a few days later a Russian university student posted his/her screenshots, clearing showing multiple PCI violations and finally resulting in - ta dah ! - plain text credit card numbers. Rule number two: know thy enemy. If you're a state government then the odds of you outsmarting a Russian cracker are very slim indeed.
Now, behaviour like that could almost be expected from state governments; they're subject to the same bureaucracy and limitations as the Federal government, yet with even less funding. But when it comes from within the industry, it gets entertaining.
I bring forth to you, my loyal readers, the most recent violation of the First and Second Cardinal Rules of Incident Response, this time presented by two web application security software manufacturers. It all starts with a guy named RSnake on a site with a funny domain name that most people don't understand. RSnake, as it turns out, happens to be pretty darned skilled in that willy little bug they call Cross-Site-Scripting. Pretty much anyone who's been in the industry more than, say 6 minutes, realizes that. He's been on a bit of a rampage with it recently as well, and in the not-too-distant-past created a public message board for the general public to post their XSS gripes. F5 and Acunetix made that board.
You may know F5 for their networking products, but approximately a year ago they acquired the IP to the defunct AppShield and started integrating it into their products. That move made them a hopeful in the world of web application firewalls, though NetContinuum still seems to outshine them in that space. I doubt F5 is really ramped up yet though, and when they do it will tough to beat them in the WAF space.
Acunetix makes a toy web application scanner called, uhm, well I guess called Acunetix. I can't remember the name because I've never seen it anywhere or heard of anyone using it. But it's out there somewhere I suppose or they wouldn't have a website with which to host XSS vulns.
In response to the listings on the website they publicly denied having the vulnerabilities in an online article, thereby breaking the first cardinal rule. Read the full PR here:
http://www.darkreading.com/document.asp?doc_id=104739&f_src=darkreading_section_296
You can just count the gems in there. My favorite is Tamara Borg (Acunetix Marketing Cyb) stating that "We are developers of a Web application security software tool which detects such vulnerabilities," she says. "Our Website is scanned on a daily basis to ensure that no such vulnerabilities exist."
Ahhh dear Tamara, unlike your ruthlessly efficient sister Seven, you have miscalculated, and now the keystone of your argument lies in the midst of the ruins of your failed assertion. Your scanner sucks.
F5 was a little bit smarter about things. They admitted to a problem, but attempted to mitigate the PR damage by implying vulnerabillity mitigation: "
The First Cardinal Rule of Incident Response is a simple one: Don't Deny It or Make Assurances
The Second Cardinal Rule of Incident Response is equally simple: Know Who You're Dealing With.
The State Government of Rhode Island learned these rules the hard way after it was alledged that their state website (http://www.RI.gov) was cracked and leaked credit cards. Their PR spokesperson - probably not the best person to be making public statements following an IA incident - publicly stated that the cards were encrypted and that they had always been PCI compliant. Witness there the failure of Rule Number ONE. Unfortunately for her, a few days later a Russian university student posted his/her screenshots, clearing showing multiple PCI violations and finally resulting in - ta dah ! - plain text credit card numbers. Rule number two: know thy enemy. If you're a state government then the odds of you outsmarting a Russian cracker are very slim indeed.
Now, behaviour like that could almost be expected from state governments; they're subject to the same bureaucracy and limitations as the Federal government, yet with even less funding. But when it comes from within the industry, it gets entertaining.
I bring forth to you, my loyal readers, the most recent violation of the First and Second Cardinal Rules of Incident Response, this time presented by two web application security software manufacturers. It all starts with a guy named RSnake on a site with a funny domain name that most people don't understand. RSnake, as it turns out, happens to be pretty darned skilled in that willy little bug they call Cross-Site-Scripting. Pretty much anyone who's been in the industry more than, say 6 minutes, realizes that. He's been on a bit of a rampage with it recently as well, and in the not-too-distant-past created a public message board for the general public to post their XSS gripes. F5 and Acunetix made that board.
You may know F5 for their networking products, but approximately a year ago they acquired the IP to the defunct AppShield and started integrating it into their products. That move made them a hopeful in the world of web application firewalls, though NetContinuum still seems to outshine them in that space. I doubt F5 is really ramped up yet though, and when they do it will tough to beat them in the WAF space.
Acunetix makes a toy web application scanner called, uhm, well I guess called Acunetix. I can't remember the name because I've never seen it anywhere or heard of anyone using it. But it's out there somewhere I suppose or they wouldn't have a website with which to host XSS vulns.
In response to the listings on the website they publicly denied having the vulnerabilities in an online article, thereby breaking the first cardinal rule. Read the full PR here:
http://www.darkreading.com/document.asp?doc_id=104739&f_src=darkreading_section_296
You can just count the gems in there. My favorite is Tamara Borg (Acunetix Marketing Cyb) stating that "We are developers of a Web application security software tool which detects such vulnerabilities," she says. "Our Website is scanned on a daily basis to ensure that no such vulnerabilities exist."
Ahhh dear Tamara, unlike your ruthlessly efficient sister Seven, you have miscalculated, and now the keystone of your argument lies in the midst of the ruins of your failed assertion. Your scanner sucks.
F5 was a little bit smarter about things. They admitted to a problem, but attempted to mitigate the PR damage by implying vulnerabillity mitigation: "
F5 says its site did have a vulnerability, but it was an HTML injection issue, not XSS. "With the vulnerability on our site, a specially crafted URL could cause an error page," says Ken Salchow, product marketing manager for F5. "But it would not run the code" like an XSS exploit would do, he says."
The problem is, there's a really fine line between HTML and XSS; one that's easily crossed. I'm not going to bother typing up the rest of this article; I believe these screenshots say it all. These are not mine, by the way, but unfortunately I can't properly attribute them as I have no idea where they came from. But the great thing about XSS is; you can go make your own screenshots ! Doh !
posted by N074H4x0r at 5:46 PM
0 Comments:
Post a Comment
<< Home