The QSA who performed their last PCI audit should not have passed them because this vulnerability is in violation of Requirement 6.5.6. The requirement states:

Prevent common coding vulnerabilities in software development processes, to include all “High” vulnerabilities identified in the vulnerability identification process (as defined in PCI DSS Requirement 6.2).

Please note, according to PCI Requirement 6.2, a CVSS score of 4 and above is considered to be a “High” risk vulnerability.

Because of this vulnerability and because the company has not fixed it, they could be fined by their bank. Furthermore, this vulnerability could pose financial liability and reputation risk for the company. If customers find out about this vulnerability, they may question the company’s ability as a trusted vendor.

So why did the previous QSA pass them? Without discussing this with the QSA, one can assume that since the issue was closed, it was fixed. You have to remember that when the auditor is performing the audit, they are presented with a lot of information. This is a lot like trying to drink from a fire hose.  Things like this vulnerability could have been missed; it was one finding out of many or possibly the auditor assumed that since the finding was closed, that it had been remediated.  Another reason may be the way an auditor interprets the PCI Requirements. This person may not have understood the requirement and made the wrong interpretation.  In many cases, one auditor’s interpretation may be different from another auditor.

It does not really matter now, why the company passed their audit, even though they did not fix the vulnerability.  The issue now is that they need to fix it before moving forward.

Virtual artifacts run the gamut from computer generated artwork, photographs of family, and other critical files denoting and cataloging our (virtual) lives. However, they also include forgotten or discarded files that were never deleted (of course the true digital archaeologist knows how to dig even deeper to get files not securely deleted). As such, virtual artifacts provide keen insight into a system and the system’s owner. Including such files that we probably would have preferred never to see the light of day again.

So why should we concern ourselves with these little remnants in our organization’s computer systems? The obvious concern is that of hackers (both internal and external). Virtual artifacts can affect your compliance efforts even without hackers as part of the equation. Depending upon the quantity of information stored in the files (such as data dumps from databases, debug logs, etc.) you may face some potential breach notification issues with significant consequences. These may also undermine all the scoping efforts performed to date, specifically relating to PCI. If those files remain on a file server that is discovered during an assessment, your cardholder data just ballooned beyond the comfort level.

During ISO reviews, these artifacts may be as helpful as a hostile witness to your (re)certification case. Alongside these are internal policy violations which may compromise sensitive internal information (employee information such as payroll, etc.).

So how do we combat these virtual artifacts within our organization? In essence, where do we start to dig within our virtual landscape? As unfavorable as it may seem, you start at the system most likely to contain such files and just keep going. There are tools that can help automate this process.

First think like an attacker; NetSPI’s Assessment Team does just that during penetration tests. They look for unprotected and residual data (the files that are just “left out there”); this includes sensitive data (PII, PHI, cardholder data, passwords, etc.) through generic file system searches. While not overly glamorous, sometimes the simplest method is the best. Then they scour multiple systems at once through spider or crawler tools, and even look at databases and their output. Speaking of, Scott Sutherland has a new blog post that includes finding potentially sensitive information within SQL databases. They find where programmers are leaving their specific output files, debug logs, etc. Sometimes the most nondescript system can have that file you don’t want to see the light of day.

So how often should you be performing these internal reviews? It partly depends on your organization’s propensity to leave virtual golden idols lying around and how effective your defenses / controls are. If movies have taught us anything is that the truly daring individual can overcome most controls if the gains are substantial enough.

The best defense is to have guidelines for employees (especially those in positions that generate, or even have the ability to generate) to securely delete files no longer needed (i.e., don’t store the golden idols on pedestals where the sunlight gleams off them like a beacon). For a more realistic example, an application owner or custodian should ensure that their application’s logs that include sensitive information are properly secured behind active access controls, temporary logs are immediately deleted when no longer needed, and the passwords to the system are secured (encrypted), etc.

Some may respond and say that the Data Loss Prevention (DLP) tool will catch these, so we are good to go. However some organizations implement a DLP tool focusing on one aspect only (Network, Storage, or End-Point). Each of these components can be overcome through various means. Blowguns (Storage controls), weight-monitoring pedestals (End-Point controls), and giant boulders closing the opening (Network controls) can be all be bypassed by careful and skilled virtual archaeologists.

It’s not uncommon for a found stray file to compromise an organization’s compliance efforts. By reviewing your environment proactively you also help make the case that your organization is performed the necessary due diligence should an incident occur. But then the point is to find those files first, leaving nothing for the tomb raiders.

Obtain and review software development processes for payment applications (internal and external, and including web-administrative access to product). Verify the process includes training in secure coding techniques for developers, based on industry best practices and guidance.

The PCI-Council is working with SANS for a set of courses that PA-DSS vendors can use. These courses include fundamental courses for developers and security staff as well as development language specific courses. There are also courses for senior level developers, tester and managers.
 
An example of one of the courses is Secure Coding for PCI Compliance. This is a two-day course on the OWASP top ten issues and is for a developer with experience in one of the following languages: Perl, PHP, C, C++, Java or Ruby.

If you are a payment application vendor needing to start of enhance your training, look at the SANS web site – http://www.sans.org/visatop10/. These should help you get through requirement 5.2.a.

Please note, NetSPI is not associated with SANS in any way.

Now I understand that this certification program is not going to solve everything, but having integrators and resellers that are trained similar to PA-QSA’s and QSA’s just helps everyone involved in the process to be on the same playing field. This results with the merchants and service providers reaping the largest slice of Benefit Pie.

Questions will come up whether this program will be worth it or if it is going to last since all indications lean towards this program being voluntary. While I get that the PCI Council’s official list of certified integrators and resellers may not be the first place the merchant or service providers go when selecting their next Point of Sale (POS) system (application features versus QIR certified reseller), they can insist that the POS vendor use QIR certified integrators, since in the end it is the merchant or service provider’s compliance status on the line.

While still a little scarce since it has not been rolled out just yet, more information on the QIR Program can be found on the PCI Council’s QIR program site at https://www.pcisecuritystandards.org/training/qir_training.php

The Council will also be having a webinar August 16 and again on August 29. Additional information can be found at the PCI Council’s Training Webinar page.

Specifically the requirement’s reporting detail reads:

If risk ranking is assigned to new vulnerabilities, briefly describe the observed process for assigning a risk ranking, including how critical, highest risk vulnerabilities are ranked as “High”*

(Note: the ranking of vulnerabilities is considered a best practice until June 30, 2012, after which it becomes a requirement.)

* The reporting detail for “Observe process, action state” is not required until June 30, 2012

Personally, I think this is a good idea as it actually gets you thinking about the impacts of the vulnerabilities specific to your organization.  It also allows you to downgrade the vendor supplied criticality should you have existing controls in place to lessen the vulnerability realization.  A common example is having to apply a patch to a web server on a very restricted network (full Access Control Lists, etc.) because the vendor rated it critical (the patch fixed an exploit for remote code execution).  The critical rating is perfectly valid for public facing websites but not as severe for servers that don’t interact with the Internet.

For those that don’t currently have an established risk assessment process in place (or those that could use some tweaking), the following blog posts might be helpful; “The Annual Struggle with Assess Risk” and “Measuring Security Risks Consistently.”  Seems like we planned those other blogs, doesn’t it?

Friendly reminder: after June 30 of this year, all Level 2 MasterCard merchants performing their annual self assessment must ensure that their internal resource has attended ISA (Internal Security Auditor) training.  Alternately, Level 2 merchants can hire a Qualified Security Assessor to perform the assessment and sign off on their Level 2 self assessment Attestation of Compliance.  This is a change from the current requirements, which allow for any internal staff to perform the Level 2 assessment.

The ISA program is maintained by the PCI Security Standards Council; training consists of four one-hour online courses followed by two days of onsite instructor-led training.  At the end of the course you even get a certificate that you can use to win friends and influence people!

Based on feedback received from current ISAs working for my clients, it sounds like the training is valuable even to those with a deep PCI background.  As ISAs receive (essentially) the same training as a Qualified Security Assessor, there are multiple benefits to keep an ISA on staff:

• By attending SSC-approved training, the ISA is getting the most current and relevant interpretations of the DSS.
• An ISA is an “internal QSA” and also an employee; therefore the ISA may have the advantage of a deeper familiarity with the organization’s people, environment, and processes compared to an external consultant/auditor.
• For a variety of reasons, most organizations still choose to use an external QSA firm for audits; however, ISAs tend to be an excellent interface to an external QSA, and can be useful as a second opinion if the QSA firm sends Cousin Eddie to do your audit.
• An ISA can provide an enhanced understanding of the Data Security Standards (DSS) requirements as they relate specifically to your organization, and can keep you apprised of current and emerging trends in the payment card sphere.
• Having an ISA on staff is the modern version of having a Royal Wizard in your court.  Though I am not supposed to speak of this, part of the advanced QSA/ISA training involves learning all manner of arcane magic.  The ISA may be able to teach you some tricks or perform at your company holiday party.

If the changes to the MasterCard Level 2 merchant requirements affect your organization there is still time to sign up for training (ISA training schedule is here).  You’ll want to become an ISA yourself when you see the locations – London in April, anyone?

However, social media can also hurt organizations, and while the cases tend to be somewhat cut-and-dry, “you posted a patient’s personal information on Facebook, so you are fired” it’s the organizational response which I find most interesting.

Searches on the internet can find many organization’s social media policies posted online (I don’t understand this; but that’s for another day). Perusing these policies you get the gamut from ‘gentle guidance’ to Orwellian 1984-esque policies. So why such a spectrum? Organizational culture aside, they are mostly indicative to where breaches have occurred. While I understand that healthcare breaches are (starting to be) a big thing, I believe the over-handed policies go too far and will never make the changes they strive for.

Some of these policies read like they are taking away an employee’s right to express themselves via any social media outlet without the oversight and approval of management, even if it’s their own personal account written during non-business hours. This is also usually followed up with web filtering to remove the ability to gain access to Facebook, Twitter, or other popular social media sites (sorry again MySpace). Ironically enough, I’ve seen this happen and then the company emails all employees saying to “like” the company’s Facebook page and/or follow their Twitter feed.

This tactic will never work for a few main reasons. Human are social and companies can’t filter all channels to social media, even during business hours (i.e., smartphones). Remember when Egypt attempted to block Twitter during the protests? Short of the having the ‘Thought Police’ and ‘Ministry of Love’, people will always share their thoughts, some more than others. With the many technological advances it’s become easier and easier, now people can take a photo and upload it to their medium of choice in seconds.

This can lead to some fairly significant issues for organizations, especially healthcare. So how does an entity prevent these breaches? By setting expectations with reasonable limitations. What I mean by this is educate everyone what is acceptable and what is not. Telling employees that they can’t say anything bad about their job isn’t going to work. Telling them that they can’t use copyrighted materials (logos) or act as a company agent on a personal blog is acceptable. Informing them of libel and how far is too far is key for when employees become disgruntled (hopefully this never happens to you). Understanding that filtering social media sites is not going to be a control that prevents material from getting online and that it will be a time management control at best (assuming smartphones aren’t prevalent).

The successful policy both defines the acceptable boundaries of personal social media as it relates to the organization and educating employees on what to self-scrutinize before posting; pictures from work with a patient walking in the background, posts that may read like an organization-sanctioned post, etc. This ensures that the “what” comes across but also the “why.” This balanced approach is at least easier for organizations that don’t yet have their own Thought Police.

The DSS does little to protect your cardholder data and systems if you think of it as something that you only have to do once a year.  Maintaining your program should be like maintaining your house: don’t wait to fix that leaky pipe, repair the broken window, fix the lock on the door, and take out all of the trash right before your mother-in-law shows up – you don’t want to deal with it all at once, and neglect can lead to increased effort, expense, security gaps, and non-compliance.  Similarly, following a scheduled maintenance routine can help you purge unnecessary accounts and data, provide visibility into your processes, train personnel, and ensure that different business units are aware of and performing their expected duties.

The cheat sheet in the following whitepaper was developed to help you prioritize, schedule, and assign responsibility for the tasks that must be performed on a periodic basis to meet DSS 2.0 requirements.  Throw this in a spreadsheet, update your group calendar, or transfer this to your GRC tool, and then off to the beach for a Mai-Tai!

Care and Feeding of your PCI DSS Compliance Program

With the announcement that KPMG really is going to start performing HIPAA Privacy Audits in the New Year, we’ve had numerous conversations with healthcare providers around getting their privacy and security programs up to scratch. 

It’s a well-known secret in the healthcare industry that HIPAA compliance does not receive the attention (or the funding) that it should.  There are of course exceptions and I should note that most security and privacy professionals in the healthcare industry take their jobs very seriously and honestly do consider the protection of patient data to be their number one priority.  But, it’s often difficult to do your job if you don’t have the funding or resources needed to do it properly.

The federal government hasn’t helped – creating a mandatory requirement, but not putting in place any mechanism for testing compliance with that requirement rapidly creates a sense of non-urgency.  What’s the point of REALLY making sure that we’re HIPAA compliant if no one’s going to check?  It costs a lot of money, it’s annoying to doctors, it’s not even the slightest bit sexy, and it’s going to impact options to the organization.

And, if none of your competitors are limiting themselves and spending extra money on ensuring HIPAA compliance, a healthcare executive is going to see true HIPAA compliance as a competitive disadvantage.  Now it looks like everything is going to have to change.  Don’t believe me?  Think the audits are going to be ‘no big deal?’  Let’s draw a parallel with another compliance requirement – PCI DSS.

For those of you not familiar with PCI, you should be – you probably have to comply with this as well.  In any case, it’s the data security standard inflicted on merchants and service providers (companies that facilitate credit card payments) by the large credit card brands (VISA, MasterCard, etc.)  Anyone that takes (or processes) a credit card for payment needs to be PCI compliant.

Although the card brands catch a lot of flak for ‘inflicting’ PCI on the world, the truth of the matter is, something needed to be done.  Credit card data was not being protected and it was costing the card brands a LOT of money in fraudulent charges and impacting consumer credit ratings.  If they hadn’t created their own standard the government most likely would have.

When PCI was first rolled out to the community there were a lot of merchants that thought it was no big deal, but they didn’t plan on three things:

1. The card brands were perfectly willing to let non-compliant merchants make ‘examples’ of themselves (link, link)
2. The legal community quickly learned what ‘PCI-compliant’ meant and how not being PCI-compliant could be used in things like multi-million dollar class-action lawsuits
3. The PCI standard gave consumers a benchmark against which to judge the merchant’s brand.

These points have been effective because the card brands maintain a unified front when it comes to PCI (they all agree to the codified requirements as the baseline required by merchants to transact credit cards securely) and because they have a mandatory audit mechanism in place that gives them the power to take action if the merchant or service provider isn’t complying with PCI.

I think that we have the same dynamic going on now with HIPAA.

1. KPMG is going to be looking to justify their million dollar contract with the government – they will find issues with compliance during their audits.
2. The legal community is already very aware of privacy breaches in healthcare and what that means for things like multi-million (and multi-BILLION) dollar class-action lawsuits (link, link, link)
3. Everyone now has a benchmark against which to judge how much a healthcare provider cares about their patients’ data

I think that it’s time to figure out a plan on how to really address HIPAA – both in the short-run (i.e. achieving an initial compliant state) and long-run (maintaining compliance moving forward.)  If you aren’t familiar with the recent announcement involving the upcoming audits here’s a link on the HHS site which includes a sample of the letter that will be sent out to organizations.  Also note – the first round of audits is going to focus on Covered Entities, but future rounds will also include Business Associates.

For some additional information on how to put together a workable approach to really achieving HIPAA compliance please see material on the NetSPI blog and NetSPI services pages.  Also – NetSPI will be putting together whitepapers, additional blog posts, and (possibly) a webinar on this topic over the next couple of months.  Please check back here for more information, make a comment, or send me an email (link below) if you would like to discuss.

The problem is that individuals have found that they can recover the silver found within the film. While it isn’t a lot of silver (roughly 2% of the film’s weight) a few hundred pounds could make it a lucrative venture. That’s why it’s not surprising that thieves have begun stealing them. Let’s be honest here, when was the last time you checked the credentials of the crew coming to take away what you would consider to be garbage?

The issue here isn’t that these films will be used for identity theft purposes, it’s that you are now forced to go through breach notification procedures at your cost… for what is technically considered refuse! Three organizations in Pennsylvania already had to go through this as they’d fallen victim to thieves stealing the films from unsecured areas, and in one instance posing as a radiological film destruction company.

What can you do? Start securing X-rays and make sure they aren’t accessible to unauthorized parties, regardless whether the file is useful or scheduled for destruction. Many organizations store the X-rays near the equipment in semi-open rooms. If the rooms aren’t used 24×7 then you should either secure the room when not in use using your normal physical security system (key, badges, dragons, etc.) and monitoring equipment. If you don’t want to go to such extreme measures (I hear dragons eat a lot) then you may consider digitizing your x-rays and then securely dispose of the physical copies. Otherwise you may want to start recovering the silver yourself to help pay for the breach notification efforts you might find yourself facing.

Further reading:

http://www.ehow.com/how_4501375_extract-silver.html

http://www.ehow.com/facts_7786835_xray-silver-recovery.html

http://philadelphia.cbslocal.com/2011/10/17/thieves-seeking-quick-steal-x-ray-film-from-area-hospitals/

http://www.jeffersonhospital.org/Patients/scrap-x-ray-film-theft.aspx