How Do You Know That Your Software Is Secure?

There is an editorial in the June 2010 issue of Digital Transactions magazine entitled “How to Beat the Traps Hackers Set in Software” that brings up this point and suggests a way to address the problem.  If you do not think this is a potential issue, think again and read this article.  I think you will change your mind.  The biggest problem with this issue is that it is not yet viewed as an issue by most organizations.

In case you have missed it, software is everywhere these days.  Most people fail to recognize that almost everything, from flat panel televisions to furnaces, rely on some amount of software to function.  As these devices get connected to networks, the risk that backdoors or “sleeper code” are used to obtain surreptitious access to these devices becomes huge.  And do not think it is not happening, appliance manufacturers are connecting their products to the Internet; automakers are putting cellular wireless access points in vehicles so that the occupants have access to the Internet.  All of this connectivity was driven home for me last year when the Air France Airbus went down in the Atlantic and it was reported that the aircraft had issued a number of messages back to Air France’s maintenance base indicating that problems with the aircraft were occurring.  The bottom line is that all of these ”innovations” put homes and businesses at risk to attack or fraud.  But this is not a new problem.  As long as there have been computers, the issue of backdoors and sleeper code has existed.  It is just that in our networked world, the problem has larger ramifications than in the past.

For PCI, I have always had a problem with the fact that card terminals do not have to comply with PA-DSS.  When I was at ETA a year ago, I toured the exhibition floor and took in all of the sophisticated card terminals that were on display.  I spoke to a number of vendors that pointed out that their terminals were running embedded Linux or Windows and had Software Development Kits (SDK) for them to further customize their terminals.  Yet, according to the PA-DSS on page vii, the PA-DSS does not apply to hardware terminals, or as the PA-DSS states, “also called dumb POS terminals or standalone POS terminals,” if all of the following are true.

• The terminal has no connections to any of the merchant’s systems or networks;
• The terminal connects only to the acquirer or processor;
• The payment application vendor provides secure remote 1) updates, 2) troubleshooting, 3) access and 4) maintenance; and
• The following are never stored after authorization: the full contents of any track from the magnetic stripe (that is on the back of a card, in a chip, or elsewhere), card-validation code or value (three- or four-digit number printed on front or back of payment card), PIN or encrypted PIN block.

Time and again we find out that unencrypted PANs are stored on the device, typically until the end-of-day (EOD) function is run.  Granted, the terminals will not print out a list of the PANs, but anyone with the administrator code can scroll through the PANs line-by-line.  When I have approached terminal vendors with questions regarding why their terminals are not PA-DSS complaint, they throw this back at me and say they do not have to comply because it is a “dumb” device.  Because terminals have multiple models depending on application, i.e., standalone, integrated POS, etc., they all have the same software; it is just configured specifically for the application.  However, it appears that the terminal vendors use the lowest end of their product line to say that the terminal does not have to comply with the PA-DSS, even though the entire product line has the same software.  And when you bring this issue up under the PCI DSS, you are told by the terminal vendor that you are being too strict in your interpretation of the standard.

Then we have open source applications.  This is probably the most problematic situation.  If you are using open source, how do you know that the application you are using is not for example rounding numbers down and depositing the difference in the developer’s account or sending a copy of all credit card transactions to a system controlled by the developer?  For most, they will not know.  While network monitoring would likely reveal the copying of transactions to another computer, the transfer of rounding could be hidden inside a company’s normal ACH or other banking traffic making it almost impossible to find.

As software becomes even more pervasive, the integrity of that software is going to have to be proven.  How does one know that any application does not contain sleeper code or backdoors that leave any system running that application open to infiltration or fraud?  That is the problem we all face.  We can no longer just trust that software does not have backdoors or sleeper code.  We will have to extensively test and certify software to ensure that software is as “clean” as possible.  However, as the Digital Transactions editorial points out, that will still not be proof positive that the software is necessarily safe.

We are entering a very brave new world and need to be very careful until we get a handle on what we are creating.  Until we do get control, we need to be very skeptical and careful about the software we use.

Advertisement

PCI Feels Like Something Is Being Done To Me

The title of this post is from a quote from a research paper published by Forrester titled ‘PCI Unleashed’.  Some of the thoughts discussed by Forrester are so true; I thought I would share a few of them.  If you have an opportunity, this is a paper well worth its cost.

One of the key points of the Forrester paper is that PCI was the result of a failure in corporate governance.  Forrester correctly points out that had organizations focused on keeping cardholder data properly secured in the first place, the PCI DSS probably never would have existed.

I can confirm that corporate governance is a root cause from my own experiences.  We talk a lot to organizations that think PCI is someone else’s problem and that their organization is being singled out.  In a lot of these organizations, security has been given the short shrift and has been perpetually on the back burner.  In these organizations, senior management sees security, and IT as a whole, as a money pit that does nothing for the organization.  This is because senior management is ignorant to what IT and security brings to the table because they have hired security and IT leaders that are mice that are occasionally seen, but certainly never heard.

The card brands have never been shy about why they generated the PCI standards; it was to protect their brands.  After all, when a breach occurs, it is almost always reported by the media as, “X number of Visa/MasterCard/American Express/Discover credit cards were disclosed by ABC Company.”  The card brands are always called out first, followed by the company and, if the company is a franchise operation, sometimes the franchisee is named.  The problem is that the general public typically only remembers the card brand names, sometimes the company name, and usually never remembers the name of the franchisee.  Want proof of this, just look at how badly TJ Maxx, HomeGoods, Marshalls and the like suffered after their parent, TJX Companies, incurred one of the largest breaches in history two years ago – NOT!  In a public relations coup, TJX Companies got the media to use TJX as the name of the breached organization which protected the brand names of their actual retail outlets.  As a result, sales at their retail outlets were only slightly affected by the breach news.

Another point that Forrester brings up is that naysayers point to the fact that PCI compliant companies have been hacked, therefore the PCI standard must not be effective.  As I have argued time and again, PCI compliance is not a one time, annual thing.  Compliance requires consistent execution of all of the PCI DSS requirements in order to remain compliant.  Consistent execution is a struggle for even the most diligent organizations.  It requires constant commitment by employees and management to the importance of doing security right all of the time.  The problem is that we are all human and humans are fallible.  So lapses will occur in any organization.  This is why all security frameworks are built on the concept of overlapping controls so that should a control go out of compliance, the whole house of cards does not come down.  What differentiates a good organization from a bad organization is that a good organization does not have so many lapses at once that entire control structures fail.  If you read the reports from TrustWave and Verizon Business Services on breaches they have investigated, a significant portion of those breaches were the result of systemic failures of the control environment.

Related to the previous point is another good point made by Forrester that the PCI standards are just a baseline and that organizations must go beyond the PCI standards to be as secure as they can be.  The PCI DSS is just the ante to be in the game.  If you want to be certain, you need to go beyond what the PCI DSS requires.  Why?  Because new flaws are discovered in software or new techniques are developed that make prior security methods obsolete or no longer as effective.  As a result, your security systems must adapt or new security methods need to be developed to detect and circumvent these new threats.  The PCI standards may address these new threats in a future version, but it is your organization’s responsibility to deal with them first.  This is also why most security experts say that security is a journey, not a destination.

One point of contention I have with this report is that they state, “Companies that already have robust security policies, processes, and technology do not have difficulty with PCI.”  Having worked with a number of organizations that meet these criteria, I can attest that this is not necessarily the case.  A lot of them have very robust security policies, processes and technologies; however, the day-to-day consistent execution was haphazard at best.  Management believed that they were in pretty good shape for meeting the PCI standards.  As we pealed the onion on their security environment, it became obvious that all management was seeing was a facade of security.  Security people said all of the right things and their policies and procedures said all of the right things, but the actual execution was not even close to consistent.  As they like to say, “They talk the talk, but they do not walk the walk.”  As a result, these organizations have struggled to change ingrained cultural issues and “bad habits” that can be much tougher to deal with than implementing new policies or technologies.

Finally, the next time you hear someone say that they feel PCI standards are not fair or they are impossible to comply with, ask them if they think they can afford a breach?  The best tidbit offered by this Forrester report is their estimated cost per account of a breach.  Forrester estimates that a breach costs between $90 and $300 per account breached, excluding lawsuits and any remediation efforts.  A modest breach of say 100 accounts carries an estimated cost of $9,000 to $30,000, excluding:

• Legal representation – you know that your organization will be sued or threatened to be sued over a breach and that will require your lawyers to go into action.  If you think lawyers are cheap, thing again, particularly when they are fighting a lot of battles;
• Public relations – just as in politics, your organization will have to put the best face on such an incident.  If your organization does not, the media will provide that “face” without you and it likely will not be a “good face”;
• Investigation – the card brands will require a forensic examination to be performed.  If you think lawyers are expensive, the costs related to a forensic examination will make you believe your lawyers are cheap;
• Remediation – there will be changes required to better ensure security and some of those changes will likely have a cost associated with them.  Only the lucky get away with policy or procedural changes with a minimal cost; and
• Loss of sales – your organization will lose customers over this lost of trust and future sales may also be affected if you did not adequately address the public relations aspect.

There are likely other events that will result from such an incident that will also cost your organization time and money.  The bottom line is that this is something your organization should avoid at all costs because, in my experience, most organizations do not survive such an incident.

Code Review

Requirement 6.6 of the PCI DSS discusses the concept of code reviews or the implementation of an application firewall to protect Internet facing applications.  For code reviews, requirement 6.6 states:

“Reviewing public-facing web applications via manual or automated application vulnerability security assessment tools or methods, at least annually and after any changes”

The confusion regarding code reviews is exacerbated by the fact that most organizations have only read the PCI DSS and not the information supplements that further clarify the PCI DSS requirements.  In April 2008, the PCI SSC issued “Information Supplement: Requirement 6.6 Code Reviews and Application Firewalls Clarified.”  Pages 2 and 3 go into detail regarding what the PCI SSC deems as appropriate for conducting code reviews.

The first thing that organizations get wrong about meeting 6.6 is conducting their application vulnerability assessment after the application is in production.  Typically, this is done to save time and money as most organizations are already conducting vulnerability scans and penetration testing to meet requirements 11.2 and 11.3.  The supplement is very clear that this is not acceptable when it states:

“The reviews or assessments should be incorporated into the SDLC and performed prior to the application’s being deployed into the production environment. The SDLC must incorporate information security throughout, per Requirement 6.3.”

The supplement continues to state:

“… it is recommended that reviews and scans also be performed as early as possible in the development process.”

Further clarifications provided during QSA re-certification training indicates that the PCI SSC really believes that the reviews or assessments MUST be incorporated into the SDLC, not that they should be incorporated.  As a result, the PCI SSC is instructing QSAs to ensure that application vulnerability assessments are done before the application is placed into production and that any critical, high or severe vulnerabilities are addressed prior to the application entering production.  The idea being that applications should go into production

Code reviews can be done manually or using automated tools.  However, if an organization is using one or more automated tools, the code review is not all about the tool.  There must be processes in place that address the vulnerabilities identified and those vulnerabilities that are critical, high or severe must be addressed prior to the application being placed into production.  Most organizations conduct this sort of testing as part of their quality assurance process.

Tools such as IBM/Rational AppScan have the ability to integrate into the developer’s workbench and conduct vulnerability testing while the code is developed.  However, while that ensures that specific code modules are secure, it does not ensure that all of the modules that make up the application are secure as a whole.  So a vulnerability scan of the completed application should be performed to ensure that the application as a whole is secure.

The next misunderstanding is related to having an “independent organization” conduct the code review.  This has been interpreted as code reviews must be conducted by third party application assessors.  The PCI SSC did not help this interpretation by their statement in the supplement when they stated:

“While the final sign-off/approval of the review/scan results must be done by an independent organization …”

However, the PCI SSC has indicated in QSA training that independent is defined as anyone not associated with the development of the code being reviewed.  A lot of organizations have a quality assurance group separate from their developers and so the quality assurance group is responsible for conducting the code reviews.  In organizations with very small IT organizations, as long as you have a developer that was not involved in developing the code being reviewed, they can be the independent party that conducts the code review.

Finally, code reviews are only required on code developed by the organization, not PABP or PA-DSS certified purchased software.  However, if the purchased software is not PABP or PA-DSS certified, then the software must be assessed under PCI DSS requirements 6.3 through 6.6.  If the software vendor will not cooperate with such an assessment or provide a copy of their own PCI DSS assessment under requirements 6.3 through 6.6, those requirements must be judged as not in place on the organization’s PCI assessment.