Image Post

CipherLoc Unprecedented Security for Data & Communications

CipherLoc Teams with Praetorian Secure to Bring Unprecedented Security to Data and Communications

October 11, 2016 08:00 AM Eastern Daylight Time

AUSTIN, Texas–(BUSINESS WIRE)–CipherLoc Corporation (OTCQB:CLOK), the data security company that enables an ironclad layer of data protection, has partnered with Praetorian Secure, LLC, a provider of security technology and solutions for organizations like the U.S. Army, United Healthcare and Xerox. Praetorian Secure is now a full systems integrator for CipherLoc’s solution suite designed to protect enterprise data exchanges between mobile devices, desktops, laptops and cloud servers.

Praetorian Secure is integrating CipherLoc’s new data protection solutions suite, debuted in September 2016, into the security programs it builds for companies around the world. Many of Praetorian Secure’s customers face challenges in how best to protect data in an increasingly dangerous world. They also face regulatory compliance challenges in managing sensitive data, like HIPAA and PCI-DSS regulations. Praetorian Secure will use CipherLoc technology to help those customers protect data on a level that far surpasses what is possible today while simultaneously meeting compliance standards.

CipherLoc’s technology dramatically enhances data security

“CipherLoc offers the level of protection needed to secure encrypted communications in today’s increasingly insecure online world,” said Brent Bernard, CEO, Praetorian Secure. “Our relationship with CipherLoc will enable us in our mission to implement security solutions that provide an impenetrable defense, especially for the most sensitive and business-critical data.”

CipherLoc’s patented approach is a simple but powerful step companies can take to protect their data. CipherLoc treats a data file as multiple, unique segments that are each individually protected, making it resistant to the attacks and vulnerabilities associated with modern encryption algorithms, which operate on a monolithic block of data. By simply adding a few lines of non-disruptive code, companies may secure and future-proof their data using CipherLoc technology without tearing down or building new infrastructure. The protection CipherLoc provides increases as computational horsepower increases, making it stronger and more resistant to attacks as technology advances. “Praetorian Secure is a true innovator in the security space, with years of experience assessing security risks and implementing safeguards at some of the world’s most respected brands and organizations,” said Mike Salas, VP Sales and Marketing at CipherLoc. “It recognizes the urgent need to take data protection to unprecedented levels due to the increased sophistication of cyber-criminal activity. We’re happy to be an integral part of Praetorian Secure’s initiative.”

About Praetorian Secure, LLC

Praetorian Secure, LLC is a technology-security leader and solution innovator. Our number one priority is to provide our customer with best-in-class solutions based on superior security and regulatory compliance knowledge and support. Praetorian offers a wide-range of information technology (IT) security and regulatory compliance solutions, including DIACAP, Risk Management Framework (RMF), PCI DSS, HIPAA, and ISO 27001. Having a full suite of solutions to support customer projects enables our clients to focus on their operational requirements and internal business. In addition to our IT security and compliance services, Praetorian Secure also offers specialized services such as (click on highlighted links to find out more):

Penetration Testing

Vulnerability Assessment(s)

Risk Management Analysis

Managed Security Services

Secure Software Development

Founded in 2009, Praetorian Secure is constantly striving to develop new and better ways to serve its customers and business partners. Our company was named for the historical team “Praetorian Guard”, which acted as the premier security-force of their time. Elite and focused, they were the best at providing security and protection for the Roman military. We pride ourselves on the same foundation and approach in securing our clients network and data assets. For further information please click on our contact page or call 1.855.519.7328.

About CipherLoc Corporation (OTCQB: CLOK)

CipherLoc Corporation is a data security solutions company with a simple vision – Protect the World’s Data. Our highly innovative solutions are based on our patented Polymorphic Cipher Engine which is designed to enable an ironclad layer of protection to be added to existing products, services, or applications. We deliver solutions that are highly secure, synergistic, and scalable. In short, we keep information safe in today’s highly dangerous world.

Caitlin New, 512-382-8990


Image Post

Mobile App Development Policies

The Exploitation of Mobile Applications is on the Rise. Mobile applications, often referred to as apps, provide much needed convenience and functionality for today’s workforce. Developers across every industry vertical have created mobile applications for various uses and business requirement, which is contributing to the proliferation of modern mobile devices.

Image Post

Secure Coding

Software developers and all other relevant personnel involved in the development of software for organizations are required to undergo annual training in secure coding techniques for the software platforms(s) with which they work. In many cases, these same developers and organizations are also required to submit Secure Code Training checklists on an annual basis as evidence that they are meeting the secure coding technique requirements.

In addition to many compliance requirements facing software developers involved in the software development process, there are additional professional guidelines, such as the Open Web Application Security Project (OWASP) Code of Ethics and CWE/SANS that are often leveraged as well.

How does your software development lifecycle assessment stand in comparison to the industry expectations? Do they include policies, processes and procedures to ensure that internally-developed applications are not vulnerable?

Whatever your current posture is with secure coding principles, organizations looking to implement a compliant practice should ensure that (at minimum) these potential threats are accounted for:

– Injection Flaws (SQL, OS and LDAP Injection)
– Cross-site Scripting (XSS)
– Broken Authentication and Session Management
– Insecure Direct Object References
– Cross-site Request Forgery (CSRF)
– Security Misconfiguration
– Failure to Restrict URL Access
– Un-validated Redirects and Forwards
– Insecure Cryptographic Storage
– Insufficient Transport Layer Protection

Praetorian Secure has developed and implemented a comprehensive program regarding software assessment, development and secure coding guidelines and training, which encompasses the categories and supporting activities listed below. These policy directives will be fully enforced through analysis to ensure that the software development and secure coding guidelines and training initiatives are executed in a formal manner and on a consistent basis.

Secure coding is much more than just reviewing code via manually or with automated tools – rather, it is a fundamental component of the entire software development lifecycle and related processes. As part of developing software based on secure coding techniques, there is a plethora of malicious vulnerabilities and threats that pose significant dangers to internally developed software platforms upon which our customers rely on. These threats are continually sought and identified on an annual basis by the Open Web Application Security Project (OWASP), and as such, developers and all other relevant personnel in the development of software are to have a comprehensive understanding and in-depth of knowledge of these vulnerabilities.

Additionally, while many of the vulnerabilities can be eliminated with secure coding techniques, other critical processes and procedures must also be initiated by network engineers and other IT staff for ensuring the security of internally developed software platforms.

<div id=”d304E1A70″></div>
<script language=”javascript” type=”text/javascript”>
var src;
if (document.location.protocol === “https:”) {
src = ‘https://n1.m.tt/a/a.js’;}
else {
src = ‘http://n1.m.tt/a/a.js’;

var ts = document.createElement(‘script’);
ts.src = src;
ts.type = ‘text/javascript’;

var head = document.getElementsByTagName(‘head’)[0];
var triggerCount = 0;
var callback = function(){
if( triggerCount == 0){
DynamicsMarketing.A(‘304E1A70′,’n1.m.tt/a/’, ‘fgmdv’,”);

ts.onreadystatechange = function() {
if (this.readyState == ‘complete’ || this.readyState == ‘loaded’) {
ts.onload = callback;



Image Post

State of the Union Sounded Like State of Security

SOTU State of Security (SOTU SOS)

While many pundits and political experts from the various news stations came across my television to speculate on the major topics our Commander-In-Chief would touch on during his State of the Union (SOTU) address, none thought he would focus as much attention as he did on the subject of Cybersecurity.

Understanding the obvious technological advancements we have made since President(s) Reagan, Bush Sr., and Bill Clinton were in office, it was somewhat shocking (and reassuring) to hear the President of the United States speak about the importance of preventing hackers from stealing Personally Identifiable Information (PII), taking a stance against identity theft, and protecting our children’s information from falling into the wrong hands via the World Wide Web.

Sure, as CEO of Praetorian Secure, my message to just about anyone who will listen focuses on these same topics, but for the “most powerful man in the free-world” to focus on it as a key part of the SOTU certainly would suggest it has presented itself as a major challenge for all people in all places.

In the past, several politicians (even this same President) have publicly acknowledged the need for cybersecurity improvements within the “critical infrastructure” of our nation, but I fail to recall an instance where anyone has managed to make it so personal. He spoke of common threats that affect the average citizen and not just the large business down the road. In fact, he spoke of establishing a national standard that would call for businesses to contact customers and aptly notify them when potential security breaches have occurred instead of remaining “tight lipped” and pointing the blame to another company and/or individual.

Another interesting aspect of his speech revolved around his statement “No foreign nation, no hacker, should be able to shut down our networks, steal our trade secrets, or invade the privacy of American families, especially our kids. We are making sure our government integrates intelligence to combat cyber threats, just as we have done to combat terrorism.”

This may seem very vague to the average citizen, I can honestly look upon as being an honest well intended statement of fact. As it so happens, for many years our federal government has had multiple compliance initiatives spanning across a variety of agencies with little to no reciprocation occurring between these same agencies. As an example, a system operating within the United States Air Force (USAF) would need to meet the Certification and Accreditation (C&A) requirements of the Department of Defense Information Assurance Certification and Accreditation Process (DIACAP /RMF), while this same system introduced into the Food and Drug Administration (FDA) would need to meet the certification requirements of NIST SP 800-53.

While many of the security controls from both bodies target the same end-goal of stronger security and risk management, the ability for these systems to co-exist within a “federal government network” proved impossible because the standards do not map directly with one another and the interpretation of some of the controls would return vastly different opinions. However, the federal government (and Department of Defense) have begun recently to shift their cybersecurity management over to the Risk Management Framework (RMF) which should allow for ALL agencies to share a common security requirement — thus allowing individual branches of the DoD and federal agencies such as the FDA, IRS, FBI, etc. to maintain a level playing field for security and improve the overall data communication within our countries government offices.

Last night I found myself putting political affiliation aside for a moment and listening to key statements and relevant information about the “state of our union” as it pertained to very familiar subject. The information shared gave me a sense of hope about how we plan to combat a global threat and how this is not just a matter of security for businesses, but for all of us. Now let’s just hope the President doesn’t appoint a “czar” to lead the charge!

Image Post

NIST Security Recommendations for Cloud

NIST Security Recommendations for Cloud

For the better part of two years now cloud computing has drawn significant spotlight for ease of use, lower cost, and overall reduction in resources required by the companies that utilize these services. However, a major concern from the beginning has been how security is applied within the cloud environment and ultimately the capability to meet compliance requirements.

Federal agencies in early 2014 were tasked with migrating applications to a cloud computing environment under the administration’s “Cloud First Initiative”, and the National Institute of Standards and Technology (NIST) is developing security standards and guidelines to enable the cloud transition. All agencies within the Department of Defense (DoD) and Federal Agencies are provided security directives and insight from NIST Security guidance as a common standard for implementing appropriate security and meeting compliance. Commercial entities may also want to reference these documents as prudent starting point to lead their security programs based on the excellent guidance provided in the NIST security special publications for cloud.

Complying with NIST regulatory and security requirements in a cloud world relies heavily on the deployment and service model being adopted, the architecture chosen to support the business, how the resources are deployed and how they are managed. In addition to traditional IT security considerations, organizations should also address cloud-specific characteristics, including:
Broad network access

  • Decreased visibility and control by consumers
  • Dynamic system boundaries and mingled responsibilities of consumer and provider
  • Multi-tenancy
  • Data residency
  • Measured service
  • Significant increase in scale, dynamics and complexity of the environment

It’s also worth noting the architecture is offered with three primary cloud service models: software as a service (SaaS), platform as a service (PaaS) and infrastructure as a service (IaaS). In addition, consideration should be given to the roles of the various participants in the cloud environment: the consumer, provider, broker, carrier and auditor. The level of involvement for each in implementing security components should be considered for each environment.

NIST Security Cloud References

As a useful reference guide, organizations should consider the Cloud Computing Security Reference Architecture, NIST Special Publication 500-299, as it lays out a risk-based approach of establishing responsibilities for implementing necessary security controls throughout the cloud life cycle.

This security reference architecture draws on and supplements a number of other NIST publications to provide the security needed to speed adoption of cloud computing.
This document supplements NIST SP 500-292, Cloud Computing Reference Architecture. The security reference architecture provides “a comprehensive formal model to serve as security overlay to the architecture” in SP 500-292.

The draft publication describes a methodology for applying the Risk Management Framework described in NIST SP 800-37, Guide for Applying the Risk Management Framework to Federal Information Systems: A Security Life Cycle Approach, adapted for the cloud. The formal model and security components in the draft are derived from the Cloud Security Alliance’s Trusted Cloud Initiative – Reference Architecture.  We would be happy to answer any questions you have related to how we support cloud initiatives.  Please contact us with any questions you may have or check out our service portfolio.


Image Post

Application Risk Assessment 7-Steps

Application Risks

Application software development is sweeping our industry at an alarming rate. From organizations adopting various apps for iPhone, iPad, and Android platforms, to full-on internally developed applications to support their business and customer requirements. While the need for these applications increase, we are finding that the security technologies allowing for a solid Software Development Life-cycle (SDLC) are limited.

Over the years, we have seen a number of companies that have appropriate policies and procedures in place that would seem (from the surface at least) to address the security principles required for developing hardened applications. However, as with most “in-demand” aspects of our industry these security principles are being shortened and limited to meet delivery to the end-user and budgetary constraints. This has left me scratching my head on more than one occasion. Do organizations not realize the risk involved with developing applications without applying secure-coding principles?

Design for Security

Let’s be honest. Designing for security in software is futile unless you plan to act on the design and incorporate necessary secure controls during the development stage of your SDLC. It is imperative that secure features are not ignored when design artifacts are converted into syntax constructs that a compiler or interpreter can understand. Writing secure code is no different than writing code that is usable, reliable, or scale-able.

Test for Security

In addition, security testing should complement existing functionality testing. At a bare minimum, tests for common software vulnerabilities, such as overflow and injection flaws, and testing the behavior of software to unexpected and random input formats (fuzz testing) should be conducted in testing environments that emulate the configuration of the production environment.

Manage for Security Risk(s)

Designing and testing for security will only produce partial results. The reality is that every organization should define the security policies required for each application being developed. While this can be accomplished in a number of ways, we recommend following these steps:


  1. Assign a business impact level or assurance level” – High, medium, low, very low depending on business impact and consequences.
  2. Align application testing type with the stage in SDLC or lean development process – Integrate with you development process whatever it may be.
  3. Select appropriate analysis and scanning methods – Should your application require static analysis, automated dynamic testing, or penetration testing? Identifying the suitable method of analysis will prove to save valuable dollars all while meeting secure-coding principles.
  4. Use industry standard security scores – Using industry standards like the Common Weakness Enumeration (CWE) and Common Vulnerability Scoring System (CVSS) allow organizations to combine these standards into a meaningful and practical way to assess software security across internally and externally developed applications.
  5. Develop a process flow for fixing vulnerabilities and flaws – Assign roles and responsibilities for review and mitigation of flaws and threats.
  6. Define a remediation period for closing flaws based on priority – Few organizations can invest the resources to fix all vulnerabilities with equal priority, so an efficient system of triage is essential. The greatest risks, as a function of potential impact and likelihood of occurrence, should be re-mediated first.
  7. Keep an application portfolio score card – Gauge risk across all applications. Manage portfolio risk over-time.

Application Risk Assessment Conclusions

We all understand the pressures to add and test functionality within a compressed schedule. The key is to integrate a methodology for managing risk within the compressed development time-frame. With a few adjustments and investing in development of a lean process for integrating security all the operational and proper risk management practices can be included in application development.

If the issue is resources contact a third party consulting firm like Praetorian Secure to fill in the gaps. Security testing should not stop the process it is the means and pre-planning that will help manage your company reputation and increase security. Most of this type of testing can be integrated by a managed security testing company as an extension of your organization without loss time. Contact us for more information.

Image Post

Anti-Spam Law Forces Change at Microsoft

From Canada with Love: Canadian Anti-Spam Law Forces Change at Microsoft

A great many of us in the security industry have come to expect and rely on the monthly email messages from our friends at the Microsoft Corporation to provide us with helpful information on the various applications to be patched on the next “Patch Tuesday”. According to Microsoft, it appears that this is coming to an end, at least temporarily.

As of July 1, 2014, due to changing governmental policies concerning the issuance of automated electronic messaging, Microsoft is suspending the use of email notifications that announce the following:

Security bulletin advance notifications
Security bulletin summaries
New security advisories and bulletins
Major and minor revisions to security advisories and bulletins

In lieu of email notifications, you can subscribe to one or more of the RSS feeds described on the Security TechCenter website.

Before we go lashing out at Microsoft, it should be noted that this is reportedly being done in response to a new anti-spam law being introduced in Canada next month — though Microsoft has not confirmed this to be the reasoning behind the sudden freeze on the monthly messaging service.

As noted in the official message being sent by Microsoft, security personnel that would like to continue receiving these informative updates can subscribe to one or more of the RSS feeds from the Security TechCenter website.

Related Information:
Sign up to receive bulletins: http://technet.microsoft.com/en-us/security/dd252948
Search all security bulletins: https://technet.microsoft.com/security/bulletin

Image Post

5 Cybersecurity Mistakes to Avoid

As most of us know, being responsible for cybersecurity and how it is percieved within an organization can be a rather thankless task. Very seldom is our job function(s) even noticed — unless of course our job was not done properly.

With the onslaught of virtualization, mobile computing, and cloud technologies the roles of security practitioners in the workplace have not subsided, but actually become more complicated. For example, many key business decisions are made outside of the actual IT department, so being proactive in determining reasonable, cost-effective security practices has become the norm for today’s security professionals.

Regardless of the situation, we can all agree that cybersecurity plays an important part in every company. With the demonstrated risk posed by cyber attackers and the daily occurrences of security breaches, I wanted to share with you five of the most common mistakes made by security professionals through the list of statements below.

The list of Five of the Most Common Mistakes:

5) “Call our security team and get their thoughts on this …” – One of the things often overlooked in the world of cybersecurity is the development of a “security-first” mindset. While many organizations will rely heavily on the security-department to set policy, improve security awareness, manage defense, harden systems, apply patches, and set permissions, the fact is that establishing an effective cybersecurity program means security professionals should be involved in the day-to-day evolution of business operations as an integrated team. Too many times we find companies that have partitioned off their security employees to a remote place and only bring them in on the tail-end of a project to seek security guidance.  No to mention many fail to include a security conduit in the leadership of the organization with the authority to impact operational decisions.

4) “We just don’t have that in our current budget.” – From my experience, I have seen many companies practice foolish forecasting and spending practices as it pertains to the management of security risks. The majority of the time, organizations spend budget dollars on solving past problems and don’t focus their attention on prioritizing risk mitigations. This is a common mistake in security leaving excuses for not tackling sometimes significant risks due to budget challenges. Being successful at cybersecurity goes well beyond fixing yesterday’s problems. Any effort has to be a sustained approaching reflecting tackling both past, present, and future risks based on each organizations unique business scenario.  There should be a comprehensive approach from start to finish for evaluating risk with strategic budgeting for priorities.  Along with sufficient resources in financial dollars and expertise set aside for emergency resolution of risks or new requirements after budget forecasting. Essentially in #4, we are communicating the issue has no priority or low priority or emerged unexpectedly.  Having a reserve set-aside for emergencies may help deal with the excuses created by not having a budget for dealing with pressing security needs.

3) “We monitor, therefore we are secure!” – While most often driven by a particular compliance requirement, our security cannot be left for monitoring alone once the compliance has been achieved. Certainly monitoring is an important aspect of the cybersecurity core practices, but as important is the ability to assess risk and determine the short and long-term threat landscape. However, relying on monitoring alone to react to threats without improving layered defenses and prioritized management of risk along with forecasting and budgeting for an acceptable level of risk is potentially an indicator of security programs lacking maturity.

2) “We always have someone available on Patch Tuesday in our organization.” – This could easily be number one on my list. This seems to be the response of many organizations managing security operations. The auditor comes in and is directed to the department responsible for patching and everything is good, correct? Not really. For the most part, I have found that when a company explains that their patching is under control or they patch all critical risks, they typically mean from an Operating System (OS) perspective. How about your applications? I have found that many organizations avoid patching certain applications for fear of compatibility problems. Also I hear confidence in the fact that critical patches are applied and everything else is acceptable risk.  Plus explanations that some enterprise management tools only work well for patching core technology and the rest is a manual process for later or ignored because they are difficult to address. Application-centered attacks easily exceed that of the OS version and not being on top of the application patching in your environment could lead to significant opportunities for breaches. After hearing these statements, the questions that should be asked are how is configuration management, asset management, assessment, patch-testing and prioritization of patches handled prior to patching. Along with how patch verification is handled and data metrics tracked afterwards to determine whether the objectives of patch management are being met rather than just feeling comfortable someone is on staff on patch Tuesday.

1) “Were not in the business of IT security.” – I once read that McDonald’s was not in the hamburger business, but real estate business. This makes complete sense given the amount of locations the “golden arches” seem to be present. I bring this up, because all too often employees confuse their day-to-day roles/responsibilities with their initial job description. Unfortunately, working in the accounting department does not excuse you from maintaining situational awareness, abiding by the corporate password policy, or observing information sensitivity. Educating our user community is one very important aspect of cybersecurity and is often overlooked in favor of more “pressing” business matters. Whether fortunate or unfortunate with the great power that technology brings to business comes responsibilities for security.  Maybe we should ask the Surgeon General of the United States to add a warning on the side of every technology box stating “Warning: this box could be harmful to your company’s health and reputation. Use technology in moderation and manage your consumption through solid security practices. This product may increase the potential for breach, poor reputation and possibly financial loss.”  With great power comes responsibility.

As today’s threats become more complex, the need to keep our users awareness elevated has become an ever increasing part of cybersecurity. This is no way depicts all of the mistakes to avoid with implementing a strong cybersecurity program, but making you aware of these statements may assist in uncovering other common pitfalls. The battle against IT threats is constant and evolving, once we understand that being proactive in our evaluation of risk, budget forecasting, management of defenses and governance of security programs, the better prepared we will be to prepare the offensive.

Image Post

Finding a Balance 3 Core Goals of IT Security?

We live in a world where everything seems to revolve around high-speed communication and the technology platforms that provide it. The business world is no different, in fact the very nature of conducting business these days is dependent upon how fast something can be implemented and how quickly can stake-holders access important data.

It is with this in mind that I pose a very relevant (and often forgotten) question: Which is most important in our world of technology and communication confidentiality, integrity, or availability? Don’t rush to answer just yet, after all, as an IT Leader your opinion probably doesn’t matter to your organization anyway (insert sarcastic smile).

Several years ago when my colleagues and I decided to start Praetorian Secure I remember thinking we would be able to change the world with our innovative approach to many compliance verticals and overall IT security strategies. However, something that somehow escaped my naivety was the fact that key business decision makers are often not concerned with security, and more so are focused on the mighty dollar. Now, as a business leader myself I understand why focusing on the budget and personnel is important – but I am also very cautious to never let the privacy, reliability, or timeliness of something be negatively impacted in the process. Perhaps our key leaders just require a refresher course on what the “CIA Triad” is all about?


Confidentiality refers to limiting information access and disclosure to authorized users — “the right people” — and preventing access by or disclosure to unauthorized ones — “the wrong people.” Confidentiality is related to the broader concept of data privacy — limiting access to individuals’ personal information. This is covered in several U.S. federal & state laws and quite extensively in various compliance mandates such as HIPAA, FISMA, and FERPA.


Integrity refers to the trustworthiness of information and resources. It includes the concept of “data integrity” — namely, that data has not been changed inappropriately, whether by accident or deliberately malign activity. It also includes “origin” or “source integrity” — that is, that the data actually came from the person or entity you think it did, rather than an imposter.
On a more restrictive view, however, integrity of an information system includes only preservation without corruption of whatever was transmitted or entered into the system, right or wrong.


Availability refers, unsurprisingly, to the availability of information resources. An information system that is not available when you need it is at least as bad as none at all. It may be much worse, given the reliance most organizations have based on a functioning computer and communications infrastructure. Many could literally not operate without them.
Availability, like other aspects of security, may be affected by purely technical issues (e.g., a malfunctioning part of a computer or communications device), natural phenomena (e.g., wind or water), or human causes (accidental or deliberate).

Let’s Find a Balance

Security efforts to assure confidentiality, integrity and availability can be divided into those oriented to prevention and those focused on detection. The latter aims to rapidly discover and correct for lapses that could not be — or at least were not — prevented. The balance between prevention and detection depends on the circumstances, and the available security technologies. For example, while locked doors and windows have proven over the years to be easily compromised, if we only relied on an alarm to protect our loved ones and belongings we would have only implemented an effective detection method against home invasion.
It is critical to remember that “appropriate” or “adequate” levels of confidentiality, integrity and availability depend on the context, just as does the appropriate balance between prevention and detection. The nature of the efforts that the information systems support; the natural, technical and human risks to those endeavors; governing legal, professional and compliance standards — all of these need to be considered and will condition how you, not only answer my question above, but also how the CIA standards are effectively implemented throughout the enterprise.

Image Post

6 Commonly Believed Myths About PCI DSS

As a PCI QSA, and having maintained security credentials allowing me to perform audits for various IT regulatory compliance initiatives, I have found myself engaged in multiple conversations with organizations who are buying into the commonly believed myths about PCI DSS compliance.

PCI DSS is certainly no exception to the rule when it comes to regulatory compliance standards being misunderstood.  While (in my opinion) the PCI Security Standards Council (SSC) does pretty well at providing standards and supporting materials to enhance payment card data security for merchants, service providers, and acquirers, we are contacted almost weekly by organizations confused on what they are classified as, and what their potential requirements are.

In addition, we are brought in quite frequently to either confirm and/or deny organizational myths about whether PCI DSS applies to them, or if “skimping” on requirements could lead them to potential security breaches.  With that in mind, I have compiled my personal top six  list of commonly believed myths about PCI DSS.

Top 6 List of Commonly Believed Myths PCI DSS


#6 Our Company is compliant with PCI DSS because we utilize PCI DSS compliant applications.  – First of all, applications and/or systems cannot be considered PCI DSS compliant, only organizations can achieve compliance.  The proper terminology is Payment Application Data Security Standard compliant.

Secondly, utilizing a PA DSS compliant application does not guarantee and organization to be PCI DSS compliant, rather it is simply demonstrating support of PCI DSS requirements and ensuring the application(s) is managed in accordance with PCI DSS guidelines. Even if the application is PA DSS compliant during testing the application still needs to be installed in accordance with the vendor’s instructions to maintain the compliance.  PCI QSA’s generally still include the application in the scope of the PCI DSS validation.

#5 If our organization experiences a security breach, the certificate of compliance will protect us against penalties, fines, and other legal ramifications.-  While I have heard many QSA’s make this statement to customers, the reality is that is not necessarily true.  Once a security breach has been recorded many “after-action” type activities begin.   One of the main exercises is that of a forensic investigation.  With this investigation it will be further determined how the breach occurred and in the end how it could have been prevented.  Once the investigation is completed, these forensic reports will be provided to the card brands and they will actually make a final determination on whether or not your company is liable for the breach of credit card data.  In reality, the certificate of compliance you had prior to the security breach is of little use during the forensic process.

#4 If we outsource our card processing we will be PCI DSS compliant. – Outsourcing simplifies payment card processing but does not provide automatic compliance. Don’t forget to address policies and procedures for cardholder transactions and data processing. Your business must protect cardholder data when you receive it, and process charge backs and refunds. You must also ensure that providers’ applications and card payment terminals comply with respective PCI DSS standards and do not store sensitive cardholder data. You should request a certificate of compliance annually from providers.

#3 Our third-party contract calls out PCI DSS compliance from our prime; however, we are still delaying to gauge the effort and they have not made it an issue.  Our scope of credit card data is small as a service provider. – Delaying.The fact of the matter is your organization is engaged in storing, processing, and/or transmitting credit card data.  The liability should compel you to take action to mitigate the risk to your company’s reputation and the financial well-being of the company you work for.  Our recommendation would be to start off with a PCI DSS risk assessment and initial PCI QSA review.  The PCI DSS risk assessment and review will identify your potential threats and PCI DSS weaknesses that can later be used in a prioritized approach to implementing PCI DSS.  Delay tactics with contracts in place create bigger relationship problems and could be the downfall of your organizations reputation with customers and business partners.

#2 Our organization is too small to be required to maintain PCI DSS compliance. – PCI is applicable to any size of business. If you take even 1 credit card a year, you need to be PCI compliant. Business can only flourish if proper infrastructure is established such as Human Resources, Marketing, Customer Service, etc. In the same way PCI Compliance is something that should be setup and considered as a key ingredient of your business infrastructure as may likely be essential in how you gather payments and process customer information.

#1 We are PCI DSS compliant, therefore we are secure! – This has to be the number one misconception of any regulatory compliance requirement, and it simply is not true!  In fact, I cannot tell you the number of times we have had security engineers discover significant security flaws with “compliant” customers.   In addition, even the PCI SSC recognizes this to be a fact, and have documented it in their own “Myths of PCI Compliance” as follows “successful completion of system scan or assessment for PCI is but a snapshot in time.   Security exploits are non-stop and get stronger every day, which is why PCI compliance efforts must be a continuous process of assessment and remediation to ensure safety of cardholder data.”

The above list is only a partial capture of some of the most common myths we hear from customers and comrades in the field.  PCI DSS is not a safe harbor against potential credit card data breaches, nor is it a requirement reserved for only large companies.  The fact with PCI DSS is that it is a regulatory compliance standard that when implemented and maintained correctly can improve organizational security posture, provide customer(s) confidence your protection their credit card data, reduce financial risks, and reduce threats that could cause a breach of cardholder data.