How much is an Easter Egg worth?

The New York Times is reporting on the results of a class action lawsuit against Take Two Interactive over a hidden sex scene in Grand Theft Auto: San Andreas. The issue is that the lawyers fees are about $1.3 million, vs. about $30,000 paid to the alleged plaintiffs (because only a tiny fraction of a percent of buyers were upset enough about the hidden scene, which can only be accessed using third party software, to participate in the settlement).

Easter Eggs in software have a long history. Based on my experience with commercial software in several companies, I'd guess that a large fraction of commercial products have easter eggs. Unless software vendors do a thorough scrub (which is pretty rare), it's a given that something put in by a developer will make it into the product, unless it causes some QA failure.

So given the settlement cost, how much would it be worthwhile for vendors to invest in ensuring that there are no obscene Easter Eggs in their software? Unless it's game software, where looking for hidden features is a well-established practice, it's probably not worth anywhere close to a million dollars. That's unfortunate, since looking for Easter Eggs might well help find security flaws, which are a bigger real threat.

Maybe we should encourage Congress to impose huge fines for software that contains Easter Eggs - and use that leverage to improve the security of our products?

A wake-up call to banks on application security

The Office of the Comptroller of the Currency is part of the US Treasury Department, and is one of the regulatory bodies for US national banks. So when they speak, banks listen (to paraphrase an old E.F. Hutton advertisement).

In early May, the OCC released guidance to banks that they have to pay attention to application security. Kudos to C. Warren Axelrod who blogged about it last week.

Here's a few quotes from the OCC letter, which is addressed to "Chief Executive Officers of All National Banks, Federal Branches and Agencies, Technology Service Providers, Department and Division Heads, and All Examining Personnel":

Banks that purchase applications typically rely upon the vendors to provide secure applications. However, bank management remains responsible for ensuring that the application meets the bank’s security requirements at acquisition and thereafter. As needed for purchased software, banks should expand their vendor management program to include application security considerations in their request for information (RFI) or request for proposal (RFP) process. An attestation from the vendor that their software development process follows secure development practices and is periodically tested may suffice for some applications. For applications that present higher risks, banks may require vendor evidence of adherence to sound processes and validation through third-party testing and/or audits. All applications purchased should be supported by appropriate vulnerability identification and remediation processes, including appropriate vendor support. Additionally, banks should ensure that their ongoing testing process (e.g., penetration, vulnerability assessment) includes purchased and contracted applications.

Among the questions they recommend asking for in an RFI/RFP:

• What are the vendor’s risk-based processes for development and validation of the application security before, during, and after it is purchased?

• What are the vendor’s notification processes whenever security vulnerabilities are identified by the vendor, reported by customers, or others?

• Will the vendor provide timely mitigation or remediation solutions to identified security vulnerabilities?
• Does the vendor have an industry-recognized third party who conducts application vulnerability assessments on the application (including security)? If so, obtain the third party’s name and determine how often the assessment is conducted, and:

• The date of the last time an application vulnerability assessment was conducted for the application;
• Whether the vendor is willing to share the results before the bank selects it as the chosen vendor;
• Whether the application has any known open vulnerabilities (including security) at the time of responding to the RFI/RFP. If so, is the vendor willing to share the nature of those vulnerabilities with the bank before selection of the product; and
• Whether the vendor is willing to share its secure coding processes and practices with the bank before execution of a contract.

• If the vendor does not have a third party who conducts application vulnerability assessments (including security), can the vendor describe their internal methodology?
• Is the vendor willing to conduct, or contract for, an assessment to provide assurance to the bank regarding the security of the application?

Where appropriate, the bank should include in the contract language about the need for current and ongoing application vulnerability assessments (including security) and who will conduct the assessments. Depending on the risk profile of the application, bank management may request the full vulnerability assessment report or a summary.

Their recommendations include "incorporating appropriate attack models [which they define as being equivalent to a threat model] in risk assessments" and using "Static, dynamic, and functional evaluations, depending on the type and criticality of the application. Automated evaluations using commercial or freeware tools, as well as manual interaction to supplement application tools. Authenticated and non-authenticated user scenarios. Comprehensive testing in a simulated production environment including appropriate operating systems and associated databases. The weakest link in several connected components may expose the entire system to compromise." They also recommend looking at open source applications from a security perspective.

Now if banks really do what the OCC is recommending, this may be a truly meaningful kick-in-the-pants to everyone to start paying attention to application security. I never thought I'd say it, but hooray for government bureaucracies!

[Edited 02 Jul to correct the link to the OCC page, which had moved.]

A new favorite quote

I don't often quote evangelical ministers (at least not positively), but I ran across this today: "Tony Campolo [a progressive Evangelical] once said that mixing politics and religion is like mixing horse manure and ice cream. You don’t hurt the manure, but the ice cream gets pretty messed up. No matter how much ice cream you toss into the mixture, the manure wins." [There are a number of slight variations I found on this quote, but everyone seems to attribute it to Tony Campolo.]

Its one of those great quotes that can be modified in so many ways - in fact, substituting almost any word in place of "religion" works quite well. "Mixing politics and economics", "mixing politics and science", etc.

How did Citbank lose customers' money?

Wired is reporting that "a computer intrusion into a Citibank server that processes ATM withdrawals led to two Brooklyn men making hundreds of fraudulent withdrawals from New York City cash machines in February, pocketing at least $750,000 in cash, according to federal prosecutors".

But the explanation of how they did it is a bit confusing - did someone steal PINs by hacking into a server, as is suggested by the article? It's possible, but my guess (backed up by someone I spoke to who knows a lot more about this subject than I do) is that someone actually installed software on the server that approves the transactions. If you do that, you don't need to know anybody's PIN - if you can create duplicate cards, you can get the system to allow withdrawals. Of course, you wouldn't want the approval to automatically say "yes" to any withdrawal, because then it would be too obvious, and the "free money" machines would be reported by customers and stopped before long. A clever attacker would insert code that would be highly unlikely to trigger by accident, but easy to trigger on purpose. For example, a PIN that matches the current month and day, or a PIN that matches some function of the account number - either would be incredibly unlikely to be triggered except by someone who knew the approval hack was present. Once the code is inserted into the approval system, the attacker can make unlimited withdrawals from an account, regardless of the account balance.

Regardless of the mechanism, the attack demonstrates that banks can't simply pass the buck (so to speak) to their customers for protecting PINs - it's up to the banks themselves to monitor their servers, and ensure that they're hardened.

Can TSA employees spot irony?

As I went through "security" at Dulles yesterday, I noticed a book sitting on top of the X-ray machine. George Orwell's 1984, to be precise. I wanted to take a picture, or to ask the TSA folks about it, but was late for my flight and didn't feel like missing it by being branded a terrorist.

Was it put there by a TSA employee? If so, did they recognize the irony?