Archive Page 2

26
Jun
15

QSAs Need More Certifications

Branden Williams has a great posting out on this topic that everyone that is a QSA needs to read. He brings up a number of good points that need to be discussed.

That said, I wanted to take on one of his discussion points and go a bit deeper. And that is the coming requirement that multiple certifications will be required as of July 1, 2016.

Note: The requirement to possess at least one industry-recognized certification is effective as of January 1, 2016 for new QSA Employees. For QSA Employees qualified and added to the search tool prior to January 1, 2016, this requirement is effective July 1, 2016 (for example, upon annual requalification after June 30, 2016).”

The document lists two types of certifications; “Information Security” and “Audit”. Under Information Security list you have the Certified Information Systems Security Professional (CISSP) and the Certified Information Security Manager (CISM).

Under the Audit list you have the Certified Information Systems Auditor (CISA), GIAC Systems and Network Auditor (GSNA), Certified ISO 27001, Lead Auditor, Internal Auditor, International Register of Certificated Auditors (IRCA), Information Security Management System (ISMS) Auditor, Certified Internal Auditor (CIA). How the Council developed this list of qualified certifications is beyond me as there are some others that I would think should be listed here.

I too face the issue that Branden faces. While I have multiple certifications, I no longer hold the CISA certification that I would need to remain a QSA after June 30, 2016. As a result, I would have to go back and obtain my CISA again after letting it lapse years ago. Why my Certified in Governance of Enterprise Information Technology (CGEIT) would not be acceptable and qualify me I have no idea.

But there is a larger issue here that I think needs to be discussed. Given how the Council has broken these certifications out, one would assume that they are looking to make QSAs better assessors by improving their auditing skills. I am also assuming that they are preparing QSAs for the onslaught of conducting true audits under the coming integration of business as usual (BAU) standards that will be introduced into the PCI DSS v4.

Based on those assumptions, I would argue that only the IRCA and CIA certifications have anything to do with certifying someone as capable of conducting a proper audit in addition to being a CPA. All of the other certifications they specify under the “Audit” category are focused on a particular auditing standard such as CoBIT, ISO 27K or similar and have nothing to do with improving a QSA’s auditing skills or preparing QSAs to become true auditors.

But that brings up an even more interesting question to ponder. Is the PCI SCC going to adopt the AICPA’s Statements on Standards for Attestation Engagements AT-101? This standard is what tells CPAs how to properly conduct audits. AT-101 lays out an extensive list of requirements for conducting an audit from planning, execution, work papers, client representations, report creation, report publication and everything in between.

A number of years ago when I worked at an accounting firm, we were approached by a few clients interested in conducting their PCI assessments to the AT-101 auditing standard. As we investigated what it would take, we and our clients quickly came to the realization that conducting a PCI assessment to AT-101 standards was going to be very costly and time consuming. The reason was that AT-101 has specific and rigorous evidence gathering and sampling requirements that go an exponential level beyond what any QSA does today for a PCI assessment.

With the introduction of BAU into the mix, QSAs are going to have to test compliance with certain requirements over the assessment period. Based on my analysis of v3, I am estimating that there are at least 213 requirements that could have testing over some period of time. As a result, AT-101 auditing standards could easily be applied to those requirements. Such an application would lend much more credence to a PCI assessment and better prove that organizations are complying with the PCI DSS.

Most departments in organizations have never been through an actual audit other than possibly their finance and accounting areas. As a result, the rigor involved with an audit will be a very new and frustrating experience for IT and the other areas involved with PCI compliance. If you think the PCI assessment process is annoying and painful now, wait until you see what you have to look forward to in the future if this is where I would bet the Council is headed.

Regardless, the PCI haters will really have something to complain about if this comes to pass.

My recommendation? Move as quickly as possible to reduce your PCI scope now.

18
Jun
15

What Drives Your QSA

David Froud has a great blog post out on LinkedIn titled ‘Why All QSAs Must Lie’. While the title is a bit misleading, it explains a lot as to why your QSA (accountant, auditor, etc.) act the way they do.

David provides some good things to keep in mind when you are wondering why your advisors are acting the way they do.

01
Jun
15

Supplemental Validation Procedures Coming

In the April 2015 Assessor Newsletter (received just last week) from the PCI SSC was the following announcement.

Coming Soon – Supplemental Validation procedures for Designated Entities

The analysis of PCI DSS compliance trends as well as the recent data breaches involving cardholder data has revealed that many organizations continue to view PCI DSS compliance as a periodic exercise only, and fail to implement processes to ensure that their PCI DSS controls are continuously enforced. This approach has been shown to result in a lapse in security controls between validation assessments. Organizations must remember that security is an ongoing process that must be incorporated into an entity’s overall strategy and PCI DSS security controls must be maintained on a continual basis.

In response to these trends, the PCI SSC is planning to issue additional validation procedures that are designed to help organizations illustrate how they are maintaining PCI DSS security controls on an ongoing basis. These supplemental validation procedures are due to be published in the upcoming weeks, along with guidance for understanding how and to whom these procedures may apply. Stay tuned!

Could it be that business as usual (BAU) is coming before v4 of the PCI DSS is released?

Who are these “designated entities”?

As the newsletter says, “Stay Tuned!”

UPDATE: On Friday, June 5, the Council issued the ‘PCI DSS Designated Entities Supplemental Validation’ standard. It can be downloaded from the Council’s Web site.  The document gives the following as examples where these supplemental procedures apply as entities that: (1) store, process, and/or transmit large volumes of cardholder data, (2) provide aggregation points for cardholder data, (3) have suffered significant or repeated breaches of cardholder data, or (4) anyone the card brands determine should go through this process.

25
May
15

SSL and TLS Update

At the beginning of March, a new vulnerability to SSL and TLS was announced called FREAK. This compounded the announcement last fall of POODLE that caused the PCI SSC to abruptly call SSL and “early” TLS (i.e., TLS versions 1.0 and 1.1) as no longer acceptable as secure communication encryption.

In April, the PCI SSC issued v3.1 of the PCI DSS and gave us their take on how to address POODLE. Their plan is to have organizations remediate SSL and “early” TLS as soon as possible but definitely by June 30, 2016. While remediating SSL and “early” TLS, organizations are required to have developed mitigation programs for these protocols until they are remediated. There are some exceptions to the June 30, 2016 deadline for devices such as points of interaction (POI) but those exceptions are few and far between and still require some form of mitigation.

Reading the explanations for the POODLE and FREAK vulnerabilities, while they are technically possible over the Internet, they are much more realistic to be performed successfully internally. As such, these vulnerabilities are more likely to be used as part of an attacker’s toolkit when compromising a network from the inside. This is not good news as an organization’s internal network is much more vulnerable since a lot of appliances and software have SSL and TLS baked into their operation and will not be quickly remediated by vendors, if they are remediated at all (i.e., you will need to buy a new, upgraded appliance). As a result, organizations need to focus on their internal usage of SSL and “early” TLS as well as external usage.

The remediation of these vulnerabilities on the Internet facing side of your network should be quick. Stop supporting SSL and TLS versions 1.0 and 1.1 for secure communications. While I do know of a few rare situations where taking such action cannot be taken, most organizations can simply turn off SSL and TLS v1.0/1.1 and be done with the remediation.

As I pointed out earlier, it is the internal remediation that is the problem. That is because of all of the appliances and software solutions that use SSL/TLS and vendors are not necessarily addressing those issues as quickly. As a result the only approach is to mitigate the issues with appliances that are at risk. Mitigation can be as simple as monitoring the appliances for any SSL or TLS v1.0/1.1 connections through log data or using proxies to proxy those connections.

The answer to SSL and TLS vulnerabilities are to remediate as soon as possible. If you are unable to remediate, then you need to mitigate the risk until you can remediate.

15
May
15

Whole Disk Encryption Explained

There are a lot of security professionals and lay people that seem to believe that encryption is encryption and that is simply not the case. Worse yet, vendors play into this misconception and obfuscate the issue with lots of words and phrases discussing seemingly complicated encryption key management procedures and the like that are actually meaningless when it comes to protecting data on running systems. As a result, it is time to clarify all of this misunderstanding.

First things first, we need to discuss how whole disk encryption works. As its name implies, whole disk encryption encrypts an entire disk drive. When a file on the whole disk encrypted drive is accessed, the encryption solution decrypts the file necessary using the decryption key provided at system startup and the rest of the drive remains encrypted. That way if a system failure occurs or the system is shutdown deliberately, the drive is always protected.

That is the key concept of whole disk encryption. The drive is technically only encrypted when the system is shutdown. If the system is running, the encryption is technically not in place because the operating system has the decryption key to access the disk at will. This is why whole disk encryption is great for devices like notebooks and the like that are shutdown at some point.

This is also why whole disk encryption is meaningless when applied to a server. When is a server shut down? Never. When using whole disk encryption on a running server, the only control that protects data is access controls, not encryption.

So using this definition, let us examine requirement 3.4.1 in the PCI DSS. That requirement states:

“If disk encryption is used (rather than file- or column-level database encryption), logical access must be managed separately and independently of native operating system authentication and access control mechanisms (for example, by not using local user account databases or general network login credentials). Decryption keys must not be associated with user accounts.”

The first statement that throws people is “logical access must be managed separately and independently of native operating system authentication and access control mechanisms”. In short, whole disk encryption cannot rely only on the operating system’s authentication process.

The best example of this is Microsoft BitLocker. BitLocker has a number of modes under which it can operate. It can integrate with Active Directory (AD), it can rely on a trusted platform module (TPM) chip in the computer or it can operate stand-alone.

In stand-alone mode, BitLocker requires the user to provide the BitLocker key by either manually keying it in or providing it on a USB device that stores the BitLocker key in order to boot the system. If that key is not provided, the system will not even offer the user to logon. This form of BitLocker meets the requirements set forth in requirement 3.4.1.

But then the requirement goes on and say, “Decryption keys must not be associated with user accounts”.

In stand-alone mode, the BitLocker key is not associated with the user’s credentials so it also meets this part of 3.4.1.

However, in the AD or TPM modes, BitLocker operates behind the scenes and the end user never knows that their disk is encrypted and the user still logs onto the system as always using their Windows credentials. These modes do not meet the independence requirement in 3.4.1 because all that is protecting the data is the user’s Windows credentials. And in the case of AD mode, BitLocker also does not meet the user credential disassociation requirement because the BitLocker decryption key is tied to the user’s Windows credentials.

But if people would fully read the Guidance column for requirement 3.4.1 they would read the following at the end of the guidance for 3.4.1 where the Council states:

“Full disk encryption helps to protect data in the event of physical loss of a disk and therefore may be appropriate for portable devices that store cardholder data.”

BINGO!

Whole disk encryption helps protect data in the event of physical loss of a disk. Period.

So with a server that never shuts down, if a drive in a SAN or NAS fails, the failed disk with whole disk encryption will be encrypted when it is pulled from the array. But if things are running just fine, whole disk encryption does nothing to protect the data.

So do not be baffled by the statements from those vendors trying to convince you that whole disk encryption on your server is going to protect your data while the server is running. That is not true.

Now you know.

03
May
15

By All Means, Do As Little As Possible

I write this because I have had enough of arguing over the lowest common denominator when it comes to securing networks, servers and applications. Reading the articles in the various media and trade journals, one would get the distinct impression that putting forth any sort of effort is beyond a lot of peoples’ capacity.

Do you people complaining about the difficulty of achieving compliance with a security framework ever listen to yourselves? I would say the answer is “No” because if you did, you would understand where I am going.

Do you realize that you are arguing over doing the bare minimum? I would guess that would be a resounding “No” because, again, you would understand where I am going.

If none of this rings a bell, then maybe this does. When was the last time anyone told you that only doing the minimum was acceptable? If they did, then they are people I would not want to associate with because they are likely on their way out the door as you will be shortly once that breach occurs.

All security frameworks are a bare minimum. They do not guarantee security of anything. What they do is define the “best practices” or “common knowledge” of what it takes to have a reasonable chance of being secure. But it gets worse. Security frameworks require perfect execution, i.e., being compliant 24x7x365, in order to succeed. And as those of you complaining are rudely finding out, that just does not happen when people are involved.

In order to address the shortcomings of people, security frameworks are layered. You must have heard the phrase “layered approach” time and again during security discussions. The layers are there so that when people fail, their failure does not result in a total failure of an organization’s security posture. Where things go wrong is when there are multiple failures. It does not matter that things are layered when the vast majority of those layers are circumvented by multiple failures.

Oh, you do not think that is how a breach happens? Read the Verizon DBIR or PCI reports on breaches and it lists out the multiple processes that failed that led to the breach, not just a spear fishing email or the breach of a firewall. Those were the start of it all, but it was a lot of other things that ultimately led to the success of the breach.

Another rude awakening for management and security professionals alike is how easily all of that security technology they have invested in does nothing once a phishing email corrupts an insider’s account. That is because a lot of organizations’ security posture is like an M&M candy – hard on the outside with that soft chocolate center on the inside. If you go back to the Verizon reports, read the details of how many attacks came to fruition over insider accounts being corrupted. They may not necessarily be categorized as insider attacks, but an insider was compromised as part of the successful attack.

Which brings me to security awareness training and the fact that people consistently complain that it is worthless. Did you people really believe that one session, once a year is really going to change peoples’ bad habits? If you did, I have some property I would like to sell you. You must harp on this topic constantly and consistently. I know that is not what you want to hear, but people only learn by being told repeatedly to stop their bad habits. Even though a lot of people approach this subject by making it annoying and painful, it does not have to be that way. But it is the only way to have an effect and it will not happen overnight and not everyone will learn the lessons. Security awareness takes years and lots of patience, but it does eventually pay off.

The bottom line is security is a war between you and the people that want your organization’s intellectual property, card data, medical records, financial information, whatever information you are trying to protect. Wars are won or lost on the strategy used and the battle intensity of the soldiers involved. Wars and battles are not won with mediocrity which is the approach upon which you are arguing. Mediocrity in war is how people die, not how they survive.

Let me know how that mediocre approach works out. That is, if you are even around to let me know.

25
Apr
15

PCI Survey

A gentleman working on his Masters Thesis at the University of East London approached me a month ago for my take on PCI and his questions resulted in the post PCI SWOT Analysis.

Now this gentleman is looking for further feedback via a Survey he has constructed. I would like to encourage my readers to take his survey to further his research as well as provide all of us with feedback on PCI.

The survey can be taken here.  (https://docs.google.com/forms/d/1ua_KAPvBu0Ziu1GQ18vZj6qq1selSMMnLtVD-D1NBJo/viewform)

Thank you.




Announcements

FishNet Security is looking for experienced QSAs for their PCI practice. If you are an experienced QSA and are looking for a change, go to the Web site (http://www.fishnetsecurity.com/company/careers), search for 'PCI' and apply.

If you are posting a comment, be patient, as the comments will not be published until they are approved.

If your organization has a PCI opportunity, is in need of assistance with a PCI issue or if you would like the PCI Guru to speak at your meeting, you can contact the PCI Guru at pciguru AT gmail DOT com.

I do allow vendors to post potential solutions in response to issues that I bring up in posts. However, the PCI Guru does not endorse any specific products, so "Caveat Emptor" - let the buyer beware. Also, if I feel that the response is too "sales-ee", I reserve the right to edit or not even authorize the response.

Calendar

August 2015
M T W T F S S
« Jul    
 12
3456789
10111213141516
17181920212223
24252627282930
31  

Enter your email address to subscribe to the PCI Guru blog and receive notifications of new posts by email.

Join 1,318 other followers


Follow

Get every new post delivered to your Inbox.

Join 1,318 other followers