Archive for the 'Uncategorized' Category

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.

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.

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.

06
Oct
14

PCI Compliance Certificates Rear Their Ugly Head Again

Apparently, a bad practice started a number of years ago is appearing in other parts of the world.  That practice is PCI Compliance Certificates.

I wrote a post a number of years ago about this practice and provided the direct quote from the PCI SSC’s FAQ on the subject.  If you need more proof, go to the PCI SSC Web site and click on FAQ and search for ‘PCI DSS Compliance Certificate’.

This is a marketing ploy and it needs to stop.

These certificates are not worth the paper they are printed on and anyone purporting them to have meaning is uninformed, or worse, lying.

I would highly recommend that if you encounter anyone that tells you such nonsense, they should be immediately reported to the PCI SSC –  qsa AT pcisecuritystandards DOT org. Include their name and the name of their organization in your message.

UPDATE: Only a few minutes after I put up this post I received just such a certificate from a major bank as proof that their business partner was PCI compliant. Unbelievable.

05
Feb
14

Celebrating Five Years

Wow! Time really does fly when you are having fun.

Believe it or not, the PCI Guru has been doing this for five years.

Thank you to my readers for continuing to support the blog and I look forward to serving you with even more blog entries in the future.

27
Oct
13

Atom AMPD And PCI Compliance

Here is a relatively new player in network security space for small and mid-sized businesses (SMBs).  A friend of mine that does a lot of work with SMBs is encountering this solution more and more.  And is there any wonder why when it is portrayed as a God send for SMBs.  On the Atom AMPD Web site, they explain their Kwick Key solution.

“Kwick Key™, a USB flash drive, is the delivery device behind the AtomOS.  The Kwick Key is bootable and plugs into nearly all servers.  Kwick Key users experience a significant savings achieved with a high quality “one key” solution for their networking needs.

Simply install the Kwick Key into an internet-connected server, display the web interface, configure the features and you’re done.  The server is transformed into a multi-functional networking and communication device.

The underlying operating system behind the Kwick Key AtomOS is Linux. The content stored on the server is also backed up on the Kwick Key.  Once configured, the Kwick Key can be transferred to new equipment while maintaining its configuration, providing portability in the event of equipment failure.  A redundant option is also available.”

What is wrong with this picture?

If you said, “Too good to be true,” you would be correct.  There are no silver bullet solutions to security.  However these sorts of “all in one” security solutions are being marketed to SMBs all of the time as a cost saving way to be secure.  And since SMBs do not typically have any significant IT personnel, they are always looking for ways to reduce IT workload and save money.  However, if you need to be PCI compliant, this is not a solution for your organization.  Why?

If you read the Savings page on their Web site, they state:

“Your current IT infrastructure is likely requiring multiple boxes to serve your network and communication needs.  This likely includes multiple boxes supporting firewalls, content filters, routing and VoIP applications; each requiring individual training, maintenance, and ongoing licensing fees.  The AtomOS provides just one platform, one interface, one operating system. It brings to bear the BEST practices via a convergent technology.  All modules are tied together by our proprietary user interface.”

That “all in one” solution approach violates PCI DSS requirement 2.2.1 which states:

“Implement only one primary function per server to prevent functions that require different security levels from co-existing on the same server. (For example, web servers, database servers, and DNS should be implemented on separate servers.)”

The reason for requirement 2.2.1 is to leverage the concept of “defense in depth”.  Defense in depth relies on multiple layers of defense such that if one layer develops vulnerability, the other layers still can provide some security and mitigate for the vulnerability until the vulnerability is fixed.  Under the Atom solution, vulnerability anywhere potentially creates a situation where the whole solution is at risk because of one part’s failure.

As a result, in order to be PCI compliant, it will require you to purchase multiple Kwick Keys.  I would assume that multiple keys will result in costs that negate Atom’s cost advantage over other PCI compliant solutions.

Then go to the solution’s product page for Kwick Key.  Take a look at all of the firewall features that are available.  Looks pretty good until you realize there is one notable feature missing – stateful packet inspection (SPI).  Basically, Atom has implemented port filtering which comes standard on Linux distributions.  Not that this is not secure, but it does not comply with requirement 1.3.6 which explicitly requires that SPI be implemented.

There are ways to add SPI to this solution.  However, that will mean you will have to support it yourself and the whole point of the Atom solution is to get out from under supporting such a solution for your organization.

My assumption is that with an appropriate wireless adapter in the system running Kwick Key that the solution will serve as a wireless access point.  Under requirement 1.2.3, wireless is required to be segregated from an organization’s cardholder data environment (CDE) by a firewall.  Given that the wireless is operating on the same device, it is questionable if compliance with this requirement could be truly accomplished.

The same concerns with wireless would exist with the virtual private network (VPN) solution.  Having the remote access to the internal network also running on the same system is not a best practice.  And how secure such a situation would be on this device is questionable.

You need to remember, this is not a purpose built networking device, this is a repurposed computer running Linux.  It is potentially susceptible to any number of Linux-based attacks and vulnerabilities depending on the services running.  And the more services you pile onto this device, the more potential for vulnerabilities.

Then there is the ability to add a voice over IP (VoIP) call manager solution.  Seriously?  What a silly and very dangerous idea.  Why?  VoIP protocols are primarily stateless (i.e., UDP) which means that they cannot be protected by today’s firewall technology which only work with stateful protocols (i.e., TCP).  I have actually had vendors correct me on this because VoIP call set up (pick up the handset) and tear down (hang up the handset) are conducted using TCP.  What these folks always miss is that the actual conversation is conducted over UDP so that the conversation can be streamed between the phones in use which is the bulk of the activity with a telephone call.  And it is not just one or a few UDP ports that can be open; it is typically a range of thousands of UDP ports that are open to support telephony.  Talk about a target rich environment.

Adding a VoIP call manager on top of your firewall is probably the most dangerous thing an organization could do because VoIP is so easy to attack due to the stateless nature of its protocols.  By implementing VoIP on a firewall you are essentially negating the firewall.  Running VoIP on anything but its own dedicated server on its own dedicated network is the only way VoIP should be configured for security, regardless of a need to be PCI compliant.

Finally, there is no pricing provided for the USB “key”.  I always get concerned about “wonder” solutions that do not provide pricing without contacting the vendor’s sales operation.  Nine times out of ten, all this does is force potential customers to then be contacted relentlessly by sales people until they purchase the solution which is likely overpriced.

This post is not to say that this solution is not appropriate for other organizations.  However, if you need to be PCI compliant, this solution is not for your organization if it is implemented as the vendor describes.




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,295 other followers


Follow

Get every new post delivered to your Inbox.

Join 1,295 other followers