Monthly Archives: February 2015

Just When You Thought You Had A Handle On PCI-DSS 3.0

As I mentioned in a previous post, PCI-DSS 3.0 (Payment Card Industry Data Security Standard) came into effect on January 1.

PCI-DSS 3.1 is on now its way, thanks to vulnerabilities like P.O.O.D.L.E.Shellshock, and Heartbleed.

The PCI SSC (Payment Card Industry Security Standards Council) continuously monitors threats and vulnerabilities in order to keep the security standard up to date.

The National Institute of Standards and Technology has identified SSL (Secure Sockets Layer) – a protocol meant to establish encrypted communication between a server and a client – as no longer acceptable for data protection.

Due to the inherent weaknesses of this security protocol, there are currently no versions of SSL with the ability to provide strong cryptography. This is why an updated version of the PCI Data Security Standard (PCI DSS) and the Payment Application Data Security Standard (PA DSS) is necessary.

According to NIST, “The proper management of cryptographic keys is essential to the effective use of cryptography for security. Keys are analogous to the combination of a safe. If a safe combination is known to an adversary, the strongest safe provides no security against penetration.”

The problem lies in the way the information is encrypted when being transmitted from a client to a server.

The solution is the dropping of SSL in favor of the TLS 1.2 protocol. SSL and the Transport Layer Security (TLS) are both mechanisms to protect sensitive data during electronic dissemination across networks. TLS 1.3 is currently being developed; the goal is to add extra measures to avoid exploitation and mitigate encryption-related issues.

To ensure the continuity across the payment card industry, the PCI Council expects that the PCI DSS 3.1, once published, will be effective immediately. That being said, the new requirements will need some time to be implemented and the PCI SSC will give some time to allow organizations to look into the new requirement and implement the changes.

Considering that there is no known way to address the weaknesses discovered in the SSL protocol, it is strongly recommended that all organizations that handle cardholder data look into the possibility of switching to a strong cryptographic protocol, such as TLS, as soon as possible. There are a number of ways to do this for WindowsLinux, and FreeBSD servers and clients.

This post was written as part of the Dell Insight Partners program, which provides news and analysis about the evolving world of tech. To learn more about tech news and analysis visit Tech Page One. Dell sponsored this article, but the opinions are my own and don’t necessarily represent Dell’s positions or strategies.

Threat modeling at a moment’s notice

If information security professionals want to stay current, they need to be on top of the latest trends and technology in their field. They also need to be open to acquiring new skills and methodologies at a moment’s notice.

To make a long story short, today I was assigned a security architecture review project by my boss. It calls for application threat modelling using a risk assessment model.

I have no experience with application threat modeling.

Research Powers Engage!

What is threat modelling?

Threat modeling is an approach for analyzing the security of an application. It’s a structured approach that enables you to identify, quantify, and address the security risks associated with an application. Threat modelling is not an approach to reviewing code, but it does complement the security code review process. The inclusion of threat modelling in the SDLC can help to ensure that applications are being developed with security built-in from the very beginning. This, combined with the documentation produced as part of the threat modelling process, can give the reviewer a greater understanding of the system. This allows the reviewer to see where the entry points to the application are and the associated threats with each entry point.

I’m also looking at two risk assessment models. STRIDE and DREAD.

STRIDE is a system developed by Microsoft for thinking about computer security threats. It provides a mnemonic for security threats in six categories.

The threat categories are:

DREAD is part of a system for risk-assessing computer security threats previously used at Microsoft. It provides a mnemonic for risk rating security threats using five categories.

The categories are:

  • Damage – how bad would an attack be?
  • Reproducibility – how easy is it to reproduce the attack?
  • Exploitability – how much work is it to launch the attack?
  • Affected users – how many people will be impacted?
  • Discoverability – how easy is it to discover the threat?

In the end it doesn’t matter what model I choose… as long as the engagement comes to a satisfying end for both the client and myself.

The client will be happy and I will have gained a new skill set for future engagements.

What have you learned today?

This post was written as part of the Dell Insight Partners program, which provides news and analysis about the evolving world of tech. To learn more about tech news and analysis visit TechPageOne. Dell sponsored this article, but the opinions are my own and don’t necessarily represent Dell’s positions or strategies.