Apache’s incident report sets a disclosure standard

Incidents happen. What you do about it is critical. Not prone to sticking their heads in the sand, the Apache Software Foundation’s Infrastructure Team established a beacon in the disclosure darkness. With unmatched transparency, while discussing a late August breach at Apachecon.con, the team indicated that “attackers fully compromised this machine, including gaining root privileges, and destroyed most of the logs, making it difficult for us to confirm the details of everything that happened on the machine.”

The report provides details on what happened, what worked, what didn’t work, and what changes they are making. Examples include:

• “The method by which most of our public facing websites are deployed to our production servers will also change, becoming a much more automated process. We hope to have switched over to a SvnSubPub / SvnWcSub based system within the next few weeks.”
• “We will re-implement measures such as IP banning after several failed logins, on all machines.”

See open disclosure and incident reporting at its finest at https://blogs.apache.org/infra/. Nicely done, Apache.

Ameriprise fails to respond appropriately

Russ McRee, co-founder of ReportSecurityFlaws.com went public this week with a security disclosure about a vulnerability in Ameriprise Financial’s site for much of this year. Russ spoke with Dan Goodin of TheRegisterUK news site about the flaw.

Until just a few days ago when Russ brought these flaws to the attention of the security press, Ameriprise did not reply to any of the warnings that he’d sent.

Part of the Ameriprise site contained cross-site scripting hazards that made it possible for phishing attackers to insert malicious content into browser sessions, and possibly steal session cookies used to authenticate customer accounts.

Ameriprise, like most sites, does not have an easy method to contact a security aware staff member to alert the company of a potential security hazard. Russ discovered a similar flaw on an American Express site late last year; a flaw that was similarly ignored by the American Express customer service department.

Ameriprise repaired its site less than two hours after being notified by TheRegister.uk of the flaw.

Read the story at El Reg.

Welcome to Report Security Flaws

Report Security Flaws exists to increase awareness and responsiveness in Internet vendors and web site operators when they receive security-related disclosures.
It is our hope that all vendors/operators maintain an email alias that exists for the sole purpose of receiving disclosure notices from parties reporting noted security flaws on the vendor/operator’s web site.

Further, said email alias should be monitored by individuals with an understanding of web application security issues and business logic flaws, while maintaining a close working relationship with the site developers and operations engineers. This relationship should allow for the quick escalation of reported issues for mitigation and remediation.
Examples of such email alias might include:
security@domain.com
websecurity@domain.com
webreports@domain.com

Too often vendors and web site operators fail to manage the proper intake and escalation of reported security flaws, leading to lapses in web application security for days, weeks, and even months.

Report Security Flaws will provide resources and guidance for vendors and site operators facing such challenges, with the hope of improving internet security posture for vendor/operators and consumers alike.

Report Security Flaws is a joint effort maintained by:
Ira Victor, Data Security Podcast
Russ McRee, HolisticInfoSec.org