August, 2009

Protecting the Privacy of Social Security Numbers Act | S. 141

Congress yet again is combating the fraud issues associated with private consumer information. The “Protecting the Privacy of Social Security Numbers Ac” (S. 141) is another good example of this.

Essentially, this bill encompasses the following measures:

It prohibits any person from displaying, selling, purchasing an individual’s Social Security number without the affirmative, express consent of the individual, subject to a number of exceptions (e.g., for national security, law enforcement, or public health purposes, or if the display is required, authorized, or excepted under any Federal law). This bill would also would prohibit any federal, state, or local government from displaying Social Security numbers on public records posted on the Internet or from printing them on government checks.

What is interesting to note is a clause at the beginning of the bill where the Senate actually “acknowledges” the seriousness of these issues by stating the following:

“The inappropriate display, sale, or purchase of Social Security numbers has contributed to a growing range of illegal activities, including fraud, identity theft, and, in some cases, stalking and other violent crimes.”

Again, yet another example of how security and privacy will continue to be a formidable topic in Washington, D.C. and rightfully so.

Visit the official SAS 70 Resource Guide and the official PCI DSS Resource Guide to learn about two of the most prominent and well-known compliance issues affecting businesses today.

Data Breach Notification Act (Introduced in Senate) | S. 139

Well, Regulatory Compliance, Governance, and Security is alive and well in Washington, D.C. again. Don’t be fooled to thinking that the current laws will be the end. The ongoing push for these initiatives, along with an added emphasis on privacy and the protection of the consumer, will continue. As I have stated a number of times, compliance initiatives like PCI DSS are just the beginning.

On January 6, 2009, Senator Dianne Feinstein introduced the Data Breach Notification Act, introduced in the Senate as S. 139. Read below for some of the bills notable highlights:

“Any agency, or business entity engaged in interstate commerce, that uses, accesses, transmits, stores, disposes of or collects sensitive personally identifiable information shall, following the discovery of a security breach of such information notify any resident of the United States whose sensitive personally identifiable information has been, or is reasonably believed to have been, accessed, or acquired.”

And how about one of the provisions for enforcement of the bill, which states the following:

“Civil Actions by the Attorney General- The Attorney General may bring a civil action in the appropriate United States district court against any business entity that engages in conduct constituting a violation of this Act and, upon proof of such conduct by a preponderance of the evidence, such business entity shall be subject to a civil penalty of not more than $1,000 per day per individual whose sensitive personally identifiable information was, or is reasonably believed to have been, accessed or acquired by an unauthorized person, up to a maximum of $1,000,000 per violation, unless such conduct is found to be willful or intentional.”

To sum it up, compliance, as I stated earlier, is alive and well.

Visit the official SAS 70 Resource Guide and the official PCI DSS Resource Guide to learn more about two of the most well-known compliance initiatives currently affecting organizations in today’s business environment.

PCI DSS Compliance | Watch out for the “Road Blocks”

PCI DSS Compliance, especially on-site reviews conducted by a Qualified Security Assessor (QSA), can take an immense amount of time in completing and receiving one’s Report on Compliance (ROC).
What most merchants and service providers fail to recognize is that there are numerous issues that could potentially cause “roadblocks” on the way to achieving PCI DSS compliance.

As a QSA, I’ve listed some examples of common items that require remediation prior to achieving compliance. These items are considered major “roadblocks” because of either the time, money and investment needed to incorporate them into the cardholder data environment:

1. Two-factor authentication
2. Web application firewall and/or software code reviews.
3. Intrusion Detection Systems (IDS)
4. Documented Policies and Procedures specifically related to PCI DSS compliance.

These four items are typically what catch merchants and service organizations off-guard. Be prepared, be proactive; find a quality, competent QSA to help with all your PCI DSS compliance needs.

MasterCard SDP Program | Attention Level 2 Merchants | PCI DSS

The MasterCard SDP Program has essentially made changes that now require Level 2 Merchants to have an annual on-site review of their security controls by a Qualified Security Assessor (QSA) for purposes of complying with PCI DSS. Let me state for the record, as a QSA, this is big news. There are now scores of Level 2 Merchants that cannot “Self Assess” anymore, thus having to comply with an actual on-site assessment by a QSA. And to be fair, can you really blame MasterCard when the chatter of late has been that most merchants simply “check the box” on their self-assessment, not giving it much though or due care. Well, not any more as Level 2 Merchants will now need to be prepared to face the rigors of an annual on-site assessment.

My advice, find a competent, cost-effective QSA who really knows what he/she is doing. Second, engage with a Qualified Security Assessor Company (QSAC) to conduct a PCI DSS Readiness Assessment for determining how “ready” your organization is for actually undertaking an annual on-site assessment. They take time to complete and require resources, to say the least.

If you want to learn more about PCI DSS, visit the Official PCI DSS Resource Guide.

Will HIPAA compliance ever have any Teeth like SAS 70 and PCI DSS?

HIPAA, The Health Insurance Portability and Accountability Act, has been with us for years now. Upon reading through the vast and cumbersome documentation, one quickly realizes that HIPAA has many moving parts, enough to make you truly gaze at amazement as to what the actual explicit intent is for compliance. In regards to the security provisions of HIPAA, The Department of Health and Human Services, 45 CFR Parts 160, 162, and 164, Health Insurance Reform: Security Standards; Final Rule, there are a number of broad based requirements for ensuring HIPAA compliance.

But that’s really where it ends, because unlike a SAS 70 Type II audit and a Payment Card Industry Data Security Standards (PCI DSS) assessment, compliance is, for the most part, not actively overseen. What does it really mean to be HIPAA compliant? What part of HIPAA do organizations need to be compliant with? What are the true penalties for non-compliance, if any?

HIPAA needs to take a more aggressive approach, possibly a revision of the law along with explicit rules for what compliance is and for what part of the HIPAA legislation. Only then will HIPAA really have the bite like SAS 70 or PCI DSS.

PCI DSS Compliance | Why it is Working and Will Continue to be Enforced

PCI DSS compliance has taken a lot of shots lately, much of it unfair. Sure, there have been a number of high profile data and security breaches, such as the recent compromise of 130 million payment (credit and debit) cards.

These stories create great front page news and to be fair, they need to be covered to report on the growing security issues facing businesses today. With that said, the Payment Card Industry Data Security Standards, commonly known as PCI DSS to many, has proven to be a highly effective and sustainable compliance initiative for protecting cardholder data. I’ve probably got some critics already by making such a bold statement, but keep in mind that the number of organizations that have successfully become compliant and have NOT suffered a data breach is very impressive indeed. Sure, the bad apples always cause the problems, making front page news and questioning the validity of PCI DSS. It’s hard in today’s society to have absolutes on almost any variable, compliance being one of them.

An ounce of prevention can go a long way, and that’s exactly what many merchants and service providers have done by implementing PCI DSS standards and becoming compliant.

Visit the official PCI DSS Resource Guide to learn more.

PCI DSS Compliance for Merchants | A Self-Assessment could be a thing of the Past

PCI DSS Compliance for merchants is a hot topic indeed as witnessed by the large and ever growing number of businesses having to comply with PCI DSS. And to be fair, the vast majority can “self-assess” for compliance by answering a series of questions from a specified “Self Assessment Questionnaire” (SAQ) document obtained at www.pcisecuritystandards.org.

But lurking beneath are a number of variables, issues and hot topics possibly resulting in many more merchants having to undertake an actual dreaded on-site PCI DSS assessment by a Qualified Security Assessor (QSA) instead of simply filling out a Self-Assessment Questionnaire.

For one, the Self Assessment Questionnaires are starting to become seen as nothing more than a check the box answer, with little or no efforts taken by the merchants to truly secure their cardholder data environment. Unfortunately, many merchants have come to symbolize the phrase “self assess” as a meaningless document which is nothing more than a burden to their businesses. Merchants beware, as the major payment brands, acquirers and other interested parties (i.e., state legislative bodies) are seeking to change this. MasterCard recently made changes to their Merchant level requirements, which to say the least, could potentially impact a large number of merchants. Add to the fact the payment processors, gateways and customers alike are now starting to ask more and more about PCI compliance from organizations they do business with.

If you want to learn more about PCI DSS compliance, visit the official PCI Resource Guide.

GLBA, HIPAA, SAS 70, PCI DSS | what is next for Compliance?

The trend of late has been Payment Card Industry (PCI) Data Security Standards (DSS) compliance, along with a continued emphasis on the well known SAS 70 auditing standard. And occasionally, calls for GLBA and HIPAA compliance come calling also. As an auditor for many years, I’m often asked to look into the crystal ball of compliance and give my prescient thoughts and answers.

First and foremost, the requirements for SAS 70 Type II audit and PCI DSS assessment compliance will continue to grow larger; larger in scope regarding the actual requirements and larger in the number of companies having to comply. Data breaches are occurring at a feverish pace, causing great unrest for all participants involved. And add to the notion of the continued importance of corporate governance, regulatory compliance and security, and it becomes quite evident that SAS 70 and PCI will play a critical role for many years.

Additionally, more and more states will start to adopt various provisions of the PCI DSS requirements, turning them into an actual codification of laws for their respective states. Minnesota became that first state with the MN Plastic Card Security Act, followed by Nevada and a host of other states who are seriously looking to an adoption of PCI into law.

As for GLBA and HIPAA, they will more than likely continue to “limp” along as they simply lack the regulatory “teeth” that SAS 70 and PCI have. This may change if the SEC and The Department of Health and Human Services give HIPAA and GLBA more explicit requirements on compliance, but this is highly doubtful.

If you want to learn more about compliance, visit the SAS 70 Resource Guide and the PCI DSS Resource Guide.

SAS 70 Audits and PCI DSS Assessments | What you NEED to Know

SAS 70 audits and PCI DSS Assessments are on everybody’s radar screen today, or though it seems. Particularly, SAS 70 Type II Audits and Payment Card Industry Data Security Standards (PCI DSS) Level I assessments.

And why? Because many service organizations, merchants, and service providers are being asked to become compliant with either a SAS 70 audit, a PCI DSS Assessment or both, for purposes of today’s regulatory compliance initiatives. Take note, Nevada just passed provisions of PCI into law, joining Minnesota as another state that is taking security and privacy to a new level.

I’ve put together a comprehensive white paper on SAS 70 Type II audits and PCI DSS Level 1 assessments that is definitely good reading material if your organization has to become compliant with either of these.

Visit the official SAS 70 Resource Guide to learn more about Type I and Type II audits
Visit the official PCI DSS Resource Guide to learn more about PCI DSS Assessments.