I always invite feedback and comments about my articles and books. I like to know what people have found useful as well as hear how I can improve upon my writing and see if there is any more information I could have added or expanded upon.
So, I was interested to see that Dr. Anton Chuvakin read one of my recent PCI DSS logging compliance papers and posted to his blog about it.
However, he made a significant misquote and provided misinformation, which provide good topics for discussion…
Dr. Anton wrote,
“However, she makes one snafu that makes me cringe (and also think negative thoughts 🙂 about this whole thing): she mentioned a “PCI-compliant log management system.” This is clearly an absurd concept: PCI DSS does not certify log management system as “PCI -compliant.” “
Huh? Hmm…what? There are two things wrong with Dr. Anton’s erroneous statement…
1) The first is an incorrect quotation; I don’t have the phrase “”PCI-compliant log management system” anywhere in my PCI DSS log management papers. So,
I’m not sure where this came from.
Over the years I have written many times, in many blog postings, many papers, many book chapters, and within many of my 10, going on 12 (yes, I’m working on two books concurrently), along with my many presentations and training discussions, about how technology alone cannot bring organizations into compliance with applicable laws, regulations and industry standards.
The bulk of compliance must be met through policies, procedures, operations, administration, and all other human issues that must occur with safeguarding information and meeting the requirements of the vast numbers of laws, regulations and standards.
I’ve even had a couple of large vendors become quite upset with me years ago when HIPAA was around a year away from going into effect; one had me speak at one of their 1-day sessions in front of a large group of their current and potential customers about HIPAA compliance, and my 1-hour talk came right after a few hours of their vendor reps talking. A couple of their reps even made statements that their technology would make the businesses completely compliant with HIPAA, which is, of course, hogwash! When my turn came to talk, I started out by saying something like, “No matter what anyone tells you, technology alone will NOT bring any organization into complete compliance with HIPAA, or any other law or regulation…” I think I actually saw smoke coming out of the ears of the vendor reps’ red and shaking faces as I continued my talk. A similar experience happened a few months later at an event for GLBA compliance, but for a different vendor.
Organizations CAN create a information security program, which includes a log management program subset, that is based on risk to the organization in addition to supporting compliance with a number of laws, regulations and standards. These programs can also help to improve the business by reducing risks and, as a result, lessening the numbers of incidents. This is what my series of papers about creating log management programs that are also in compliance with PCI DSS, or to put it another way, PCI DSS compliant log management programs, are all about.
No where do I state, nor would I ever try to claim, that implementing a log management system alone would make a company PCI DSS compliant. Besides the log technology issue, there are many other security requirements within PCI DSS beyond log management.
BTW, a system is generally considered a type or set of technologies that can be useful tools for business. The PCI DSS definition is, “System components are defined as anynetwork component, server, or application that is included in or connected to the cardholder data environment.”
Information assurance programs cannot be in compliance with applicable laws, regulations and standards solely through the use of technology systems.
Likewise, log management programs cannot be in compliance with applicable laws, regulations and standards solely through the use of technology systems.
What I *did* write as the titles to my PCI DSS log management papers are
- “Using PCI DSS-Compliant Log Management to Identify Insider Access Abuse”
- “Using PCI DSS-Compliant Log Management to Identify Attacks from Outside the Enterprise”
- “Addressing Application Vulnerabilities with PCI Log Management Compliance”
2) I do not use the word “certify” in any of the articles.
“Certify” is far from being synonomous with “compliance” or being “compliant.”
Most, if not all, IT auditors understand this. Most information security practitioners also understand the difference.
A company should strive to create a program that is in compliance with their applicable laws, regulations and required standards. But of course trying to meet compliance, and being compliant, is not the same as being certified.
Only a Qualified Security Assessor (QSA) can certify an organization with regard to PCI DSS compliance. I discuss this within the articles and provide the viewpoints and experiences of a PCI DSS QSA within them.
As another example, covered entities (CEs) under the U.S. Health Insurance Portability and Accountability Act (HIPAA) try to build information security and privacy programs that are HIPAA compliant. However, this does not mean that they have been HIPAA certified; indeed there is no such thing as a “HIPAA Cerfitication” or a “HIPAA Certified Compliant” organization, program or system. The U.S. Department of Health and Human Services (HHS) does not offer or endorse any such certification. They even warn about vendors making such claims to make organizations “HIPAA Certified Compliant.”
Building a regulations-compliant program, based upon risk to the organization, is generally a smart idea. Done right it will support, and even help to improve, business.
Organizations may then choose, or need, to go the next step to have an independent qualified auditor/assessor to validate and certify that their program is indeed compliant.
Being certified is different than being compliant.
The certification process is performed by an independent entity appropriately qualified to perform the specific activities necessary to certify.
The process of becoming compliant with requirements is performed by organizations that are responsible for meeting compliance themselves to meet legal, regulatory and contractual requirements.
The target audience for these papers are business leaders and managers who want to understand how their resources investments in PCI DSS compliance will actually help their business. They don’t want to know how to technically implement the requirements, but they do want to know the business value for the investments necessary for compliance.
I have been pleased to have already gotten good feedback from some folks about the papers. In fact, one told me he gave the paper to his director and was happy to have something that showed to his director not only multiple perspectives about PCI DSS compliance, but also the business benefits in terms that were easy to understand. Technology heavy pieces often do not resonate with most business leaders.
I hold Dr. Anton in high regard; he is a very smart log management technology expert. However, I cringed when I saw he made misquoted remarks and mistatements about my paper.
I hope that those of you who are interested in these topics will read what I actually wrote and let me know what you think.
Tags: Anton Chuvakin, awareness and training, certify, compliant, HIPAA, Information Security, IT compliance, log management, PCI DSS, policies and procedures, QSA, risk management, security awareness, security training