What If?

Here is a thought provoking question that was posed to me recently by a former accomplice in the PCI world.

What if PCI DSS assessments were only required until a merchant proved they were PCI compliant or if a merchant had been breached?

The premise behind this idea is simple.  There are going to be merchants that get information security and there are those merchants that are never going to get information security no matter the carrots or sticks employed.  Not that merchants that get information security cannot be breached, but the likelihood is significantly lower than merchants that do not get information security.

Merchants would go through the PCI DSS assessment process, clean up their act and ensure they are compliant and then they would only have to go back through the process if they were breached.  As a best practice, merchants could chose to periodically assess themselves after significant changes to their cardholder data environments to make sure no new security issues had been created or at annual intervals of say three to five years.

In the event that a merchant were breached, the PCI assessment process would be required annually for the next three years or until all of the card brands involved agreed to drop the reporting requirement, whichever comes first.  For Level 1 merchants, they would go through the Report On Compliance (ROC) process performed by a QSA or an ISA.  For all other merchant levels, they could use the appropriate self-assessment questionnaire (SAQ) but that SAQ would have to be reviewed and signed off by a QSA.

For high risk organizations that process, store or transmit large volumes of cardholder data such as processors or service providers that do transaction reporting, statement rendering or other similar services, they would still have to go through the ROC or SAQ D as they do today based on the levels defined by the card brands.

For service providers such as managed security service providers (MSSP) or cloud service providers (CSP), they would be required to go through an annual SAQ D, at a minimum, or a ROC, if they desired, for all services that are required to be PCI compliant.  The ROC would have to be prepared by a QSA or ISA and the SAQ D would have to be reviewed and signed off by a QSA.

As with merchants, if a service provider suffers a breach, all bets are off and they must do a ROC by a QSA or ISA for the next three years or until the card brands tell you to stop.

Visa and MasterCard currently maintain lists of PCI compliant service providers.  Service providers pay to be listed on those lists and the qualifications to get on those lists would also not change.

Regardless of whether an organization is a merchant or service provider, the quarterly external and internal vulnerability scanning and annual external and internal penetration testing requirements would remain the same.  Merchants would be required to file their results with the merchants’ acquiring bank or processor(s).  For service providers, their scanning and penetration testing results would be filed with the relevant card brands.  The scanning and penetration testing just help to keep everyone honest in their efforts to maintain their security.

I have to say, it sounds like a rational process to me if you accept the original premise that organizations will either do what it takes to be secure or will not.  Thoughts?

What To Focus On In 2013

It is the end of the year and, like all other pundits, here is another idea on what 2013 will bring in the way of security issues.  After reading a lot of the other predictions out there, I tend to agree with those from Verizon Business Services’ Data Breach Investigation Report researchers.  While everyone else is predicting cyber-Armageddon as the biggest threat, the researchers at Verizon Business Services see a lot more of the same for 2013.

The biggest threat Verizon identifies is more attacks on authentication systems.  This is most likely because your vendor or your developers talked you into storing authentication information in your database that is Internet facing.  We see this all of the time with eCommerce and Internet banking solutions.  The external user credentials end up being stored in the database along with order entry, inventory and pricing data.  This is typically done because using a directory system for such purposes is difficult and, at times, not as functional as when authentication data is stored in and used from a database.  Given the prevalence of SQL attacks, all of that information results in being available for the taking through a SQL injection attack.  As a result, the attackers compromise the authentication system, gain access to everyone’s credentials, including administrators, and it is likely ‘game over’ regarding the rest of your security measures.

I want to touch next on social engineering because it is typically directly related to compromising authentication systems even though the second place attack method most concerning Verizon researchers is application attacks.  Social engineering is all about tricking your end users into giving up key information so that an attacker can compromise your environment.  The most common piece of information an attacker tries to obtain is an end user’s credentials for logging onto the network.  Hence the reason why I wanted to discuss this after the authentication system attacks.  Social engineering is the most insidious of attack methods because it does not involve any of an organization’s security technology.  And worst of all, if social engineering is successful, all or most of your organization’s security technology is effectively neutralized as a result.  That is because most organizations have little or no security once someone is on the inside.

Now let us look at the second most concerning attack to Verizon which is application attacks.  Verizon is saying that application attacks are more of a threat to governments and large applications.  Regardless of the target, any organization with an application presence on the Internet is a potential target such as with eCommerce or Internet banking.  A lot of these applications are based on on-line frameworks such as IBM’s Websphere or Oracle’s Application Framework.  It is not that these frameworks are insecure, it is that they still require development effort and it is those custom development efforts that do not guarantee a secure application.  The problem comes from the fact that a lot of people believe that using a framework means that little to no security testing even though the amount of custom development done in these frameworks can be more extensive than starting from scratch.  As a result, we see a lot of organizations tossing Internet applications into production with little or no security testing and then ending up with breaches as a result.

In addition, there are third party applications served up by application service providers (ASP).  A lot of small and mid-sized businesses (SMB) use these sorts of applications to have an online presence.  As a result, a lot of SMBs believe that these solutions do not require any security testing because the vendor and the ASP do that for them.  However, we are encountering more and more attacks on SMBs, particularly those that have wealthy clientele such as country clubs and exclusive financial institutions because their applications are notorious for not being secure.  SMBs are constantly amazed that; (1) they were targeted and, (2) the application was not bettered secured.  Yet attackers know that while the take out of SMBs could be significantly less than a large organization, an SMB is usually easier to compromise because they do not have the security and monitoring resources of a large organization.  As a result, SMBs are becoming a larger and larger target for attackers.

Finally, something that concerns me as the previously discussed threats is mobile devices and devices not under the organization’s control, also known as ‘bring your own device’ or BYOD.  I think these devices will surpass the other three threats over the next few years because most organizations have difficulty maintaining security on their servers, desktops and notebooks, let alone something like an iPhone or an Android tablet.  The worst thing about mobile devices is that they are so easily lost and it fascinates me how many people lose their mobile devices.  The bottom line about mobile devices and BYOD is that you must be very, very careful as to what you allow these devices to access and how you grant that access.  And you must make sure that these devices are not allowed to download information, even if encrypted, as that information is highly likely to be lost.

So what should you be doing regarding these threats?  Here are my top things organizations should be doing to minimize the risks presented by these threats.

• Trust no one.  This is particularly true of mobile devices or BYODs, but it also applies to your own internal systems.  Forrester has promoted this in their ‘Zero Trust Model’ as well as me in the ‘Fort Knox Approach’.  This is not as easy as one might think, but the approach makes sense in these days of attacks on authentication systems and social engineering approaches.
• Classify your data.  This is usually a difficult project, but they pay dividends at the end because everyone understands why certain information cannot be allowed out of the control of the organization.  It also allows people to justify to others why data cannot be allowed to be accessed by people that do not need access as well as via mobile or BYOD.
• Require encryption on mobile devices and BYOD.  Even if you do not allow data to end up on these devices, you do not even want the memory or other information that might be inadvertently stored on these devices out of your control.  As a result, if you encrypt these devices, there is a high likelihood that, if they are lost, the person finding them will just wipe them and start over.
• When possible, use a directory system for authentication.  This is always painful for systems that operate outside of the traditional control environment of internal users.  Directory systems are usually designed to be more secure than any sort of database authentication system because they are assumed to be at risk from the start.  However, just because they are designed to be secure does not mean they cannot be implemented in an insecure manner.  Windows Active Directory takes a lot of heat for being insecure; however a lot of that heat is due to silly implementations to support insecure authentication methods for compatibility.
• Conduct security awareness training.  The only thing that minimizes social engineering is consistent and regular security awareness training.  However, do not kid yourself or management.  Everyone has their ‘moments’ and does something they should not.  That said there are always those that just never seem to get it which is why you need other controls and monitoring to ensure you maintain your security.  However, to just throw up your hands and say it is pointless is also not a position to take.
• Secure your applications.  This means conducting application code reviews and testing applications before they are put into production not after the fact.  Unlike networks where you need to put them into production before testing them, applications can be tested before going into production.  It amazes me how many organizations put their applications into production and, by the time they finally get around to testing them, they have already been compromised.  And while automated application code testing solutions are all of the rage, we still find that the best results come from the more traditional human code review not automated tools.
• Monitor your network and applications.  This is a double edge sword.  You know what to look for, however, you have so many ports open that it is near to impossible to recognize bad traffic from good traffic.  And it is not necessarily the fault of your IT department as most packaged applications require an inordinate amount of ports open to function properly.  However, the key thing to monitor, more than anything, is any traffic going outside of your network to an unknown location.  When you see traffic going to Eastern Europe, China or any unexpected IP address, your monitoring system should generate an alert as that is typically a key indicator that you have been compromised.

Have a happy holiday season and I will “see” you all next year.

PCI SSC Updates The ASV Program and Issues New Information Supplement

March 2011 has been a busy month thus far for the PCI SSC.  On Thursday, March 10, they announced a new ASV training program and on Friday, March 18, they released an Information Supplement on protecting telephone-based cardholder data.

The ASV training program has blindsided the ASV community as it was a total surprise.  Yes, there has been talk over the years at the Community Meetings and in other venues regarding ASV qualifications and training, but nothing ever seemed to come from those discussions.

According to the press release, the ASV training program, “… is a direct response to the feedback we’ve received from the merchant community …”  One can only assume that the complaints that have been voiced about ASVs from merchants and service providers as well as the comments in the media have finally caught the attention of the PCI SSC and they are going to address the problem with training.

The consistent complaint I have heard from clients over the years was in regards to the fact that no two ASVs ever scoped their network the same for vulnerability scanning.  The next most common complaint was always about the different results of the vulnerability scanning which was most often voiced after a company changed ASVs.  While there are always some bad apples in the bunch, I do believe that most ASVs know what they are doing.

As a result of all of this, I am sure this new training requirement is to address the complaints and make the program better.  This training is in addition to the network security test ASV companies already had to pass.  For those of you that did not know, ASVs have to conduct network security scanning against a test network with predefined vulnerabilities operated and configured by the PCI SSC.  ASVs are expected to produce a sample ASV report and document all of the predefined vulnerabilities.

The ASV training is comprised of an eight hour online course and an examination.  A minimum of two employees are required to take the course and pass the examination.  Once this has been accomplished, the organization is designated as having Qualified ASV employees.  As with a lot of PCI requirements, there are some important dates involved.  ASVs that are renewing their status prior to June 1, 2011 need to get two personnel trained and passed the examination by June 15, 2011.  ASVs that will certify after June 1, 2011 need to have two staff trained and passed the examination by their renewal date.

Given the additional cost of this new training plus the requirement to have a minimum of two people trained, it will be interesting to see if any of the existing 130 ASVs drop out because of this new requirement.

Telephony Cardholder Data

The other issuance of interest this month was in regards to telephone conversation recordings that contain cardholder data.  While this is a longer dissertation on FAQ 5362, there is really nothing new presented in this information supplement.  The bottom line still is that if you have call recordings that contain cardholder data you are required to either; (a) do not record it in the first place, (b) if recorded, redact it if possible, or (c) make sure that it cannot be searched, is encrypted and access is restricted.  The best thing about this information supplement is the flowchart that was created for this situation.

The “Magic” Vulnerability – Revised

What started this post is that I have recently received a number of calls and messages from clients and colleagues.  The conversations have all gone basically the same.  They were calling me and telling me that their ASV had failed their vulnerability scan because the OS detected was unsupported and they are wondering whether or not I have encountered this before.

My first question usually was along the lines of; “So, what vulnerabilities did they detect?”

“None,” was the confused answer at the other end of the line.

“What?  They must have detected at least one high, severe or critical vulnerability?  That is the only way you can fail,” I would ask, now also confused.

“Nope.  Nothing.  Just the fact that the OS is unsupported,” I was told.

Do not get me wrong.  I am not advocating the use of unsupported operating systems, particularly unsupported versions of Windows.  The risk of course is that one or more vulnerabilities show up that the vendor will not fix because the OS is no longer supported.  So there is good reason to avoid this situation.  However, there are also situations when you just get no other choice either due to your own organization’s issues and politics or software vendor issues.

This situation got me thinking and doing some research since I did not remember ever seeing or being told that an unsupported OS was an automatic vulnerability scan failure.  I no longer do external vulnerability scanning, so my recollections of training and working on the ASV side of our business is a bit fuzzy and very rusty.  However, I had never failed a client for an unsupported OS.  So when this issue came up, my only action was to determine what had changed.

The first thing I did was review the latest version of the PCI ASV Scanning Procedures, v1.1.  I searched for terms such as ‘old’, ‘unsupported’, ‘out of date’, ‘OS’ and ‘operating system’.  No matches.  So there is nothing in the ASV scanning procedures that fail an organization for running an unsupported OS.  Even the PCI DSS does not call out unsupported software, so procedurally; I am thinking there is nothing explicit regarding unsupported OSes causing a failed vulnerability scan.

So when I made the original posting, I got a comment from one of my readers pointing me to the ASV Program Guide.  Low and behold on the top of page 16 is the following:

“The ASV scan solution must be able to verify that the operating system is patched for these known exploits. The ASV scanning solution must also be able to determine the version of the operating system and whether it is an older version no longer supported by the vendor, in which case it must be marked as an automatic failure by the ASV. “

So there is no “magic” vulnerability I was missing as the PCI SSC does specify that a scan automatically fails if the OS is unsupported.

But that is not the entire story.  The key to this whole process is that the vulnerability scanner used must be able to verify the operating system.  While all vulnerability scanners attempt to identify the operating system, the reliability of this identification process is suspect at best.  I am not aware of any vendor of security testing tools that makes a claim that they will identify an operating system 100% of the time.  This is because of the fact that there are many, many things that can influence the OS signature that the tools cannot control and therefore can greatly affect the ability of the tool to identify the OS, particularly when talking about external scanning.  And if an organization follows the OS security hardening guidelines, a lot of unsupported OSes will not be properly or reliably identified by vulnerability scanners.  As a result, I find it hard to believe that the PCI SSC intended to have ASVs only rely on the results of a vulnerability scanner, but that seems to be the case.

So with this clarification, I contacted our ASV personnel and they have told me that they too have been failing vulnerability scans if they run across unsupported operating systems.  I ask if the OS signature is inconclusive, then there is not a failure?  Yes, if the scan comes back and does not identify the OS, then they have nothing to go on to fail the scan and the scan passes.  Given the difficulties vulnerability scanners can have identifying the target operating systems such as when scanning through network firewalls, Web application firewalls, load balancers and the like, I now ask if they feel that these identifications are reliable enough to fail a scan.  I am told this is why they confirm the information with the client before issuing the report so that the report is accurate.  So if a client is not honest, they could influence the results of their scan?  I am reluctantly told that is probably true.

Then there is the issue that not all operating systems are created equal.  Operating systems such as MVS, VMS and MCP are nowhere as risky, if they are even risky to begin with, as Windows and Linux.  A lot of ASVs would argue that they never come across these operating systems running Web services.  However, all of them have the capability of running Web services and I personally know of a number of organizations that run their Web services from such environments.  Organizations are running these older versions of operating systems mostly because of the financial considerations of migrating to something else.  However, I can guarantee that none of the dozens of vulnerability scanners that I have used in the last 10 years would accurately identify any of these operating systems, let alone tell you the version unless some service message header information was retrieved by these tools.  And even then, most tools do not parse the header to determine the OS so it would take human intervention to make that determination.

Regardless of the failure, most ASVs do have a review or appeal process that allows organizations to dispute findings and to submit compensating controls to address any failures.  So for organizations that cannot get rid of unsupported OSes, they can use a compensating control.  Like compensating controls for the PCI DSS, the organization is responsible for writing the compensating control and the ASV needs to assess the compensating control to ensure that it will address the issues identified by the vulnerability scan.

So, if you can fail an organization over an unsupported OS, why is it that you do not automatically fail on unsupported application software?  I went through the Program Guide and there are all sorts of other criteria for applications but nothing regarding the fact of what to do if they too are unsupported.  Applications such as IBM Websphere and Oracle Commerce can become unsupported just as easily as their OS brethren.  And in my experience, use of unsupported application software is even more prevalent than unsupported OSes under the idea that if it is not broken and does not have vulnerabilities, why upgrade?  When I asked our ASV group if they fail organizations on unsupported applications I got silence and then the response that they will fail an application if the vulnerability scanner provides a high, severe or critical vulnerability.  To tell you the truth, while vulnerability scanners regularly return text header information for a lot of applications, I would be hard pressed without doing a lot of research to find out if the version being reported was unsupported.  However, scanners could provide this feedback if they were programmed to provide it.

Then there are all of the conspiracy theories out there that say the PCI SSC and technology companies are working together to drive software sales by forcing organizations to upgrade and there would appear to be a lot of anecdotal evidence that would seem to support this argument.  In reality it is not that the software companies are working together with regulators such as the PCI SSC so much as software companies operate this way in order to focus development and support resources on fewer, more current versions.  As a result, it is just happenstance that regulations cause organizations to have to update their software.

The bottom line in all of this is that you have options to avoid a failing vulnerability scan because of an unsupported OS.  The best method, and the one I most recommend, is do not use unsupported operating systems in the first place.  However, as a former CIO, I do understand the real world and the issues IT departments face.  As a result, I recommend all of the following which may or may not require you to develop a compensating control.

• Implement not only a network firewall, but also a Web application firewall (WAF) and make sure that the rules are extremely restrictive for servers running unsupported operating systems.
• Configure your firewalls to block the broadcasting of any OS signature information.  Masking the OS signature will provide the benefit of not advertising to the world that the OS running whatever application is unsupported.  This is not a perfect solution as, 9 times out of 10, the application itself will likely advertise the fact that the underlying OS is unsupported.  It is very important to note that this is only a stop gap measure and you should still be actively in the process of migrating to a supported OS.
• Implement real-time monitoring of firewalls, servers and applications.  Define very specific alerting criteria to ensure that any suspicious activity is immediately reported and operations personnel immediately follow up on any alerts to determine whether they are a false positive.
• Implement a host-based intrusion detection/prevention solution on any servers that run the unsupported OS.  If using a HIPS solution, you may also want to consider using its preventative capabilities for certain critical incidents.
• Implement real-time log analysis for firewall, servers and applications.  Define very specific alerting criteria to ensure that any suspicious activity is immediately reported and operations personnel immediately follow up on any alerts to determine whether they are a false positive.
• Actively use your incident response procedures to address any incidents that are identified with any unsupported OS.

Intent Of Requirements – 11.2

As I discussed in my earlier post on the intent to requirement 6.1, requirement 11.2 is another requirement where there is a hard and fast metric of four “clean” quarterly vulnerability scans.  Nice idea, but tough to execute.

To remind everyone, the intent of vulnerability scanning is to; (a) ensure that if a patch has been applied, it is in fact in place and the vulnerability has been addressed and, (b) identify any new vulnerabilities.  11.2 is in response to at least two issues.  The first is that organizations that do not vulnerability scan have no way to assess the larger risk their technology infrastructure poses to the potential loss of data.  The second is to ensure that updates and patches are in fact truly correcting vulnerabilities.  I have personally seen situations where patches have removed other patches thus leaving a system at risk of compromise.  Granted these situations are rare, but without vulnerability scanning, the removal of these patches would have never been known.

Requirement 11.2 requires that vulnerability scanning is performed at least quarterly.  However, given the 30 day patching rule, the fact that most vendors have a monthly release of patches and the fact that scanning must be performed after all “significant” changes, an organization really needs to conduct monthly vulnerability scanning at a minimum just to stay compliant.  As a result, if you have an organization doing anything less than monthly scanning, you really need to question if they understand the vulnerability scanning requirement.  However, from a ROC reporting perspective, you really only need to report the results of four quarterly scans even though 12 or more scans are available.

Then there is the problem of the definition of a “clean” scan.  According to the PCI SSC, a “clean” scan is one that contains no severe, high or critical vulnerabilities.  You hear complaints about this time and again from organizations, “How do you ever get a ‘clean’ scan when new vulnerabilities are introduced almost every day?”  This is a very fair question when most security professionals know that the odds for obtaining a “clean” scan are against them because 94% of all vulnerabilities are rated severe, high or critical.  Let alone the fact that tests for vulnerabilities can show up in scanning engines long before the vendor has a patch just exacerbates this situation.  Is it any wonder security professionals are frustrated with this requirement?

This is an area that the PCI SSC has really failed to address and bring some reality to the requirement.  For a lot of large organizations, vulnerability scans that have no severe, high or critical vulnerabilities documented cannot physically be achieved without some rare alignment of the planets, stars and moons.  They could be scanning 24×7 and still could not have a complete, truly “clean” scan of their environment.  As a result, a “clean” scan is usually all in the eye of the beholder.

But that is not the entire problem.  A lot of organizations run packages such as Oracle Commerce, IBM Websphere or MICROS Simphony.  Oracle, IBM and MICROS typically have issues with some OS or system software vendor patches such as those for Windows, Linux or Apache.  They usually issue advisories to their customers indicating that these patches cannot be installed.  In these cases, severe, high or critical vulnerabilities may not get patched for months as these vendors develop an update to their solution as well as packaging the other vendors’ patches.  As a result, organizations with these solutions can have severe, critical or high vulnerabilities in their scans for quite a while.  In these cases, a QSA needs to determine if the organization has followed the vendors’ recommendations or used any other recommendations for mitigating the risks of having these vulnerabilities.  QSAs also need to see proof that once Oracle, IBM or MICROS issue their fixes for these situations, that these organizations implement them in a timely manner.

As a result of these constraints, I have developed my own definition of a “clean” scan.  Again, I am not advocating that vulnerability scanning does not have to result in “clean” results.  I am advocating that QSAs bring reality to the process.  In my world, a “clean” scan is a scan that results in severe, critical or high vulnerabilities that were not documented in any of the previous scans.  If there are repeated severe, critical or high vulnerabilities, those vulnerabilities should only be the result of vendor patching issues and the organization must have documentation that proves that management understands that they exist, what measures the organization has taken to mitigate their existence and when the vendor anticipates to have the vulnerabilities addressed.

Here is my rationale for this definition.  There are just too many factors that go against getting what the PCI SSC defines as a “clean” vulnerability scan.  Real world experience says that getting a “clean” scan is near to impossible, particularly in large environments.  I can count on one hand the number of organizations that I have worked with that have truly four quarters of “clean” scans and none of them are very large.  Therefore, as long as I can prove that severe, high or critical vulnerabilities are being addressed in a reliable and as timely a manner as possible, then the scans are clean.

All of you anal-retentive types I am sure are going to flame me as not following the standard.  However, what is a standard worth if it cannot be applied equitably to all?

Why Stuxnet Matters To PCI Compliance

There is an article in the Sunday, January 16, 2011, New York Times that says the American and Israeli governments were behind Stuxnet, confirming a rumor that has been running around ever since Stuxnet was identified.  The consensus of the experts is that Stuxnet is to cyber warfare what the airplane was to conventional warfare, a radical game changer.

So why does Stuxnet matter to merchants, processors, acquiring banks and the card brands?  A whole lot if you think about it.

First, Stuxnet proves beyond a shadow of a doubt that governments are investing in cyber war and that in cyber war anything on the Internet is fair game.  While Stuxnet was built to target Iran’s centrifuges that are used in refining Uranium, there were a number of incidents of “collateral damage.”  This “collateral damage” was the result of Stuxnet attacking anything that used the same Siemens SCADA controllers.  Granted, Stuxnet was not as nasty to devices that were not centrifuges, but it still caused problems.  Imagine if an entity wrote an attack for a common device or protocol hoping to actually target another particular entity.  Do you think your organization could become “collateral damage” in such an attack?  I would say it is highly likely.

Second, imagine then the damage that could be done if a terrorist group or a government decided to go after another country’s financial systems using a Stuxnet type of attack.  Does such an attack sound unrealistic?  It should not given that the quickest way to bring any country to its knees is through its financial systems.  And what makes things doubly worse is that, thanks to outsourcing, most banks use a very limited number of application solutions thus making such an attack all that much easier.  Given the reliance of countries on their economic capabilities, such an attack would likely only be carried out by a rogue nation such as North Korea that has nothing to lose or even any other country if it is provoked long and hard enough.

But what if the attack was directed against credit card terminals?  While a lot of people would say that would be farfetched, it also is not as wild as it might seem.  All you need is someone on the inside at Ingenico, Verifone and the like to doctor the card terminals’ software to do whatever you want it to do.  Even large merchants do not necessarily monitor their card terminals, so such an attack could go on for quite a while before it was noticed, if it even ever was noticed.  Criminal gangs have been producing limited numbers of doctored terminals for the last four to five years.  Imagine this done on a large scale and you start to understand how nasty a threat this could be.  If introduced from the manufacturers into the distribution stream, there would be no way of knowing that you had been compromised unless you were monitoring your network properly which most organizations do not do.

Finally, there is the doctoring of integrated point of sale (POS) solutions or similar applications.  Again, not as farfetched as you might think.  There have been a number of instances over the years where software was written to provide backdoors or other openings in systems that allowed information to be leaked.  This is why certain governments have gone into the software business.  This is also why there are now valid concerns about how you confirm that your software is only doing what it is supposed to be doing.

The bottom line in all of this is that these concerns are no longer the ramblings of the paranoid among us.  These once imaginary seeming scenarios have actually come to pass and we need to address what to do to mitigate them.  So from a PCI perspective, what should an organization be doing?  While all of the PCI DSS provides methods to protect an organization, the following are what I consider the most important regarding inside attacks.

• Monitor your internal network – This is the single, most important way to protect your network from doctored devices and applications.  A doctored device or application must transfer the information it has collected either in real time or in a batch process.  Transmission may be outbound or via an inbound process.  Outbound monitoring should be the easiest because most organizations know what external IP addresses to allow.  Inbound communications are always disputed by most organizations.  But if you remind people of how GoToMyPC and others of its ilk operate, they begin to understand how their networks could be easily compromised from the outside.
• Analyze your logs – This is probably the next area where a lot of organizations are not doing a good enough job.  Most organizations do a good job collecting log data, but then do a mediocre or poor job analyzing that data to find exceptions.  The reason for this poor performance is a lack of defining criteria for attacks.  While the initial implementation did a good job creating initial definitions, as time goes on, the log analyses are not enhanced or updated to reflect changes in attacks and new attacks.
• Tighten internal controls – Once inside most organization’s security perimeters, security gets pretty loose and free, if it even exists at all beyond a logon.  Unfortunately, attackers understand this fact, hence why they focus on getting inside.  Because once an attacker is inside, it is pretty much a cake walk to get whatever they want.  This is why locking down ports, reviewing firewall and ACL rules, disabling or removing unused services and disabling or removing unused user accounts become so important.  The fewer attack points you provide on your internal network, the more resilient it will be should an attacker get inside.

Remember, while the City of Troy was protected by insurmountable walls, Troy fell because they were attacked from the inside; an attack vector that Troy felt was not realistic or possible.  Troy’s short sidedness was the result of their arrogance and a failure to understand that an enemy determined to defeat you will find a way to overcome the insurmountable.  Learn from Troy’s mistake.

Interesting Announcements From The PCI SSC

For those of you that are not QSAs, the PCI SSC over the last year has tried to keep QSAs in the loop by issuing a monthly Assessor Update newsletter via email.  These usually are not noteworthy, but the November 2010 issue contains a number of items that need to be shared just in case you miss your edition or you are not a QSA.

PCI DSS Timeline Clarification

The Council apparently got the message that they did not communicate the sunset date for the PCI DSS v1.2.1 and the start date for PCI DSS v2.0 very well.  As a result, they issued a clarification in the November 2010 newsletter.  To quote the Council:

“Entities needing to comply with the PCI DSS are strongly encouraged to begin using the new standard immediately. However, version 1.2.1 will remain effective until December 31st, 2011 to allow everyone time to adopt any changes they may need to in order to maintain their PCI DSS compliance. This means that organizations assessing and reporting compliance during 2011 may validate to either version 1.2.1 or 2.0. However, the Council urges all organizations to complete their transition to the new standard as quickly as possible, especially where any new controls may enhance the protection of cardholder data.”

Since QSAs will not have the scoring template until sometime in January 2011, it makes planning and executing any assessments difficult until the scoring template is issued.  As a result, the earliest I can see any v2.0 assessments getting started is March 2011.

PCI DSS and PA-DSS v2.0 Scoring Templates

And speaking of those scoring templates, the scoring templates for v2.0 of the PCI DSS and PA-DSS should be published sometime in January 2011.  It would be nice to have these a bit earlier, but better late than never.

Expiration Of PABP v1.4 Extended 90 Days

The PABP v1.4 standard that was expected to expire tomorrow, December 2, 2010, has been extended to March 2, 2011.  To quote the Council:

“This updated deadline recognizes the challenges many merchants and Payment Application end users have in implementing system changes over the busy holiday period, and allows the Payment Application vendor community to consider submitting new versions of their products for assessment against the new PA-DSS 2.0 standard.

The Council is committed to reviewing all submissions for the updated versions of expiring PABP v1.4 applications, and this new March 2nd 2011 deadline will allow the review process to be completed before previous versions of these applications expire.  This extension will also provide more time for PA-QSAs to complete reviews of those Payment Applications that are currently in process.  Finally, this extension will allow Payment Application vendors, should they choose to hold off on assessment of expiring Payment Applications and instead submit (after January 1st, 2011) their Payment Applications for assessment against the new PA-DSS v2.0 standard.”

ASV Sampling And Scanning Do Not Mix

While sampling of devices is allowed under the PCI DSS, it is not allowed for ASV scans.  To quote the Council:

“Within a given quarter, all Internet accessible systems must pass an ASV scan. It is not necessary that they all be scanned at the same time, but they all must be scanned quarterly.”

Apparently, some ASVs were only scanning a sampling of PCI in-scope devices each quarter.  I am sure this will lead to consolidation of a lot of organization’s external network presence.

2011 PCI SSC Training Schedule

The training schedule for next year should be posted to the PCI SSC’s Web site by mid-December.

Telecom Private Circuit FAQ Issued

See the end of my post on MPLS for the text of the FAQ.

The Threat Landscape Is Changing – Cloud Cracking

There was an article published on Threat Post this past week regarding a German security researcher that used a new feature of the Amazon.com EC2 cloud computing environment to crack SHA1 password hashes.   I am sure a lot of you are asking yourselves, “So what?  This is just another Chicken Little warning that come out all of the time.”  I would agree with you that publications use highly threatening headlines to hype these sorts of articles to attract readers.  But if you read these articles closely, ignoring the hype factor and think through the concepts that they are discussing, you can understand the threat they might bring to your environment.

The thing that caught my eye about this threat is that it cost the researcher less than an hour of their time and a whole $2.10 to crack six character length 160-bit SHA1 hashes.  Even more disconcerting was that all of the necessary hardware and software was readily available through the EC2 service.  And if the researcher had desired, they could have used even more GPUs to shorten the time to crack these hashes.  Granted, the researcher only cracked 14 of these hashes, but what if those hashes were to one or more administrator accounts?

I am sure a lot of you are now saying, “Yeah, but, this is all theory and not a ‘real’ threat.”  No doubt about it.  I too have been known to toss out my famous, “In theory, theory works,” at this point.  But the only way to determine if the research really is a real threat is to read the article or research paper and then determine if the threat can truly be applied in the real world.  Based on what I have read about this threat, I would say that there is a great potential for misuse of this EC2 service for all sorts of encryption attacks, not just SHA1 hashes.

A lot of you are now probably pointing to the fact that these were all six character long items that were hashed.  I would agree but then also point out that they were 160-bit hashes, not less than 128-bit.  A lot of security professionals mistakenly believe that if they get hashes or encryption above 128-bit, that everything is secure.  However, the number of bits is not the only factor; there is also the strength of the key used.  If the key is not very long or is easy to guess, then it does not matter how many bits are used by the algorithm.

A lot of security professionals blow off threats because they just assume that if they are scanning regularly that any new threat will be caught by their scanning.  Unfortunately, scanning only looks for vulnerabilities to devices based on known attack vectors, not a threat like this one.  This threat comes into play with any encrypted data or transmissions that an attacker can come across and may or may not have a lot to do with vulnerabilities.

You can argue that because you scan and you comply with the PCI DSS and do not have any vulnerabilities of CVE 4 or higher, you are therefore secure.  However, as any network security professional that conducts penetration testing will attest, vulnerabilities with a CVE of less than 4 can be put together and used to compromise a network.  So, just because you do not have any vulnerabilities of CVE 4 or higher, does not necessarily mean that you are secure.

The real threat here is that should an attacker be able to get a hold of your encrypted data or data flows, they can just load it up and use Amazon.com’s EC2 cloud to attempt to break the encryption.  As a result, all of those claims over the years by security pundits that attackers would have to have access to supercomputers have apparently been realized with the advent of cloud computing.

But again, this is all theory, right?  You wish.  Even more shocking was a tidbit tucked away in the article.  There is a site entitled WPACracker.com that offers a 400 CPU cluster of computers and 284 million word dictionary and promises to crack WPA passwords on an average of 20 minutes for $17.  As a result, all of you relying on WPA to secure your wireless should be considering upgrading to WPA2 as soon as you can.

The next thing that rolled through my mind is what if some enterprising individual decided to conduct some “research” for themselves by using the Berkley Open Infrastructure for Network Computing (BOINC) platform?  This is the platform that runs SETI@home, Einstein@home and other worthwhile scientific research projects that need lots of computing power.  Based on the BOINC home page, that would put the potential of over 4,000 teraflops at the command of our “researcher.”  However, like all things technology based, our enterprising researcher would need to find a potential vulnerability in BOINC and leverage that to gain access to all of that computing power.  Either that or make their research project look enticing to the BOINC user population so that they add that workload to their systems.  But given that BOINC is open source, it is also possible that attackers could create their own BOINC network for the purposes of cracking encryption.  I could imagine botnets being put to this purpose.

This whole threat plays out best when the attacker has inside access to an organization’s network and data.  Reading the latest reports from Verizon Business Services and Trustwave, the majority of breaches have an inside component, so it is not too farfetched that an insider would have access.  So, if you are not monitoring your network and sensitive data and not strictly controlling access to your data, then it is anyone’s guess as to whether or not someone has taken your data and is now attempting to decrypt it.

If you learned anything at all from this post is the fact that attackers are leveraging cloud computing just like the rest of us.  The unfortunate aspect is that attackers are leveraging the cloud to continue their questionable and sometimes illegal activities.  And in so leverage this new technology, the potential that they are successful is only going to go up.

Secure Coding And Application Vulnerability Scanning

Based on some of the mail I am getting these days, there is a lot of confusion regarding secure coding standards and application vulnerability scanning, that is, requirements 6.5 and 6.6.

First, let us talk about the intent of these requirements.  The overall intent of both of these standards is to stop insecure applications from being placed in production.  The intent of requirement 6.5 is to ensure that secure coding techniques are part of the system development lifecycle (SDLC) and that the most obvious errors, at the moment those are the OWASP Top 10, have been addressed during development.  The intent of requirement 6.6 is to ensure that either code reviews are conducted or an application firewall is used to protect applications.

The most common question I get regarding requirement 6.6 is that since it does not specify what should be tested, does that imply that only the OWASP Top 10 needs to be looked for when conducting the code review?

When will you people learn?  When the PCI DSS does not specify something, you always assume that you need to test everything.  In the case of requirement 6.6, you need to conduct application vulnerability scanning for all potential vulnerabilities, not just the OWASP Top 10.  This will become more important under PCI DSS v2.0 when they add other application vulnerability standards into the mix.  The bottom line is that if all you are testing for is the OWASP Top 10, you are not doing enough testing.

Another area where people get things wrong is that they conduct application vulnerability testing just like they do network vulnerability testing, which is after the application is in production.  Wrong!  Unfortunately, the PCI SSC has only trained the QSAs to understand this fact and only merchants and service providers that have been through ISA training likely know about this requirement.  Because of this, QSAs get beat up all of the time by merchants and service providers when they mandate application vulnerability testing and remediation before an application goes into production.  However, if you think about it, it has always been implicit in these requirements.  Remember, the intent of these requirements is to avoid putting vulnerable applications in production.  That is why you need to conduct your scanning as part of your QA processes before the application goes into production.  If any high, critical or severe vulnerabilities are discovered as part of the testing, those need to be either remediated or compensated for before the application is placed into production.

The final issue we consistently see is that secure coding techniques and code reviews are nowhere to be found in the SDLC.  A lot of organizations point QSAs to various coding Web sites for their SDLC.  They assume that these sites have already embedded secure coding techniques in their SDLC and that may or may not be the case.  A lot of SDLCs document how to create application security, but say little or nothing regarding secure coding techniques.  As a result, they are shocked when the QSA comes back and says that secure coding techniques are not in place.  But what this points out is that the organization does not use the SDLC because had they used it, they would have known that the SDLC did not address secure coding and code reviews.

The lessons you should have learned are as follows.

• While requirement 6.5 only calls out the OWASP Top10, you need to also be worrying about all the other application vulnerabilities that could exist.
• SDLCs are meant to be used, not just offered as a way to meet a requirement.
• Secure coding techniques need to be documented as part of the SDLC and need to be followed.
• Requirement 6.6 requires you to scan for all application vulnerabilities, not just the OWASP Top 10.
• Application vulnerability scanning is performed before an application goes into production.
• If high, critical or severe application vulnerabilities are identified by scanning, those vulnerabilities must be fixed before the application goes into production.

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.