What is PCI-SSC?
After a series of security problems and credit card information leaks in the early 2000s, several companies came together in a Council to work on a possible solution.
Therefore, in 2006, the largest companies in the credit card industry came together and formed the PCI-SSC (Payment Card Industry – Security Standards Council). This is a set of security requirements and procedures aimed at protecting the personal information of cardholders and thus reducing the risk of fraud. In other words, PCI-SSC is based on the creation of a solid basis for increasing security throughout the entire cycle of card use.
Since then, we have evolved the practices and documentation that support this ecosystem. All this documentation can be downloaded from the website for free.
It is currently in version 3.2.1, which was released in May 2018, and has 12 requirements that are validated for companies wishing to display the “PCI-DSS Compliance” label.
As described in the PCI-DSS document itself, the standard’s ultimate goal is to become a means that can help increase the security of financial transaction data from credit cards.
The goal is to create and maintain a foundation of best practices that can help maintain an acceptable level of security.
What is PCI-DSS objective?
Many still believe that PCI-DSS security definitions only apply to financial operations. However, there are many other settings that must be applied to other areas of the credit card use chain, from online payment to the production and registration of encrypted keys on sales equipment – so-called POS – or card machines.
According to the official PCI-DSS document, this objective is clearly placed as an attempt to create a global standard of best practices to be applied.
“The Payment Card Industry Data Security Standard (PCI DSS) was developed to encourage and enhance cardholder data security and facilitate the broad adoption of consistent data security measures globally. PCI DSS provides a baseline of technical and operational requirements designed to protect account data”.
There are a total of 12 requirements in PCI-DSS, and of these, Conviso, as a software security specialist, has the expertise and know how to act in 2 of these requirements.
In the following paragraphs we will talk a little more about these two requirements in which we act upon and how we can help in each one of them.
Requirement 6
PCI-DSS Requirement 6 goes directly to developing and maintaining secure applications and systems.
This is our focus, it is what we do best!
When we look at the overall goal of Requirement 6, we see that at this point the creators of the standard have tried to show that all applications and systems, both those developed internally and externally, need to receive the same level of attention.
Requirement 6 will present us with needs and activities that must be performed for all agents involved with the card data process, and in addition, these agents must ensure that all systems and applications comply with the recommendations of Requirement 6.
Requirement 6 consists of several sub-items ranging from item 6.1 to item 6.7, and is one of the best known items of Requirement 6, which addresses the need for the treatment of best known vulnerabilities, starting with item 6.5.
For this particular item, in case the reader wants to go deeper into the content and concepts, a reading of materials referring to OWASP TOP 10 and SANS TOP 25 may be a great way into looking for some adequacy.
This is the item that requires the continuous execution of training in order to keep everyone involved in the application development process updated, which will support the operations that will handle, store and even transmit credit card data.
How can Conviso help PCI-DSS
At Conviso, we strongly believe that education and continuous knowledge acquisition is a key factor for growth and continuous improvement in many aspects of a professional and, consequently, a product or service.
In this sense, we have made several articles in our blog that seek to show the importance of training, and how it should not be seen as a cost but rather as an investment.
Directly related to this training subject, we have already helped many of our clients to train their teams, keeping the knowledge always updated with the latest types of vulnerabilities, attacks and ways of correction.
Investing in training is the safest and simplest way to maintain and ensure that all necessary efforts for application protection are being employed in the development process.
For those who want more information and details on how application security is impacted, the suggestion is to check out the material regarding the PCI Software Security Framework.
Check our articles about the importance of training
Requirement 11
Requirement 11 is where PCI-DSS makes clear the need for structure and application validation to ensure that everything that supports the storage, retrieval and processing of card data is actually in line with best practice.
So it is in Requirement 11 that there is an obligation to test the security of both processes and systems. And it goes from item 11.1 to item 11.6.
These items describe the requirements for testing support applications as well as for testing support structures such as ethernet and wifi logical networks.
One of the best known parts of this phase is the execution of a Pentest. This test was mentioned in our blog, the reading of such a content can help in the understanding process.
What is the best alternative?
The execution of Pentests is one of the specialties of our analysts, who have great experience in this type of test.
Today we execute tests for large companies in the market and help to adapt and adjust the needs of these customers to what is required by PCI-DSS.
We must not and can not forget that new vulnerabilities are discovered every day and we must have periodic planning for testing that may guarantee the security of our applications and support structure.
We can’t imagine that by performing annual tests, we will be safe.
We need to understand that the execution of more periodic tests, and also the execution of a structured development process with implemented security thinking is what can really bring more security to the whole process.
