+91 9594449393
+1 4847906355
+63 9208320598
+44 1519470017
+84 908370948
+7 9639173485
+62 81808037776
+90 5441016383
+66 993367171
+254 725235855
+256 707194495
+46 700548490
The Payment Card Industry Software Security Framework, introduced by PCI SSC, is a relatively new framework that will go into effect in October 2022. The PCI SSF is a collection of various codes and tools created to safeguard payment software. It's a framework that was created to take the position of the Payment Application Data Security Standard (PA-DSS) with more up-to-date standards that support various payment software types, technologies, and development techniques.
1. The PCI SSS does not contain any “prescriptive" requirements.
There are strict guidelines under PA-DSS that spell out in detail the prerequisites that the payment application must satisfy for both you and them:
- This made it simpler for your engineers to build your product around a set of fixed controls, with your assessor only checking to see if they were implemented.
- If they weren't, the payment application didn't satisfy the condition. It was either in place, it wasn't in place, or it wasn't applicable. The outcome was categorical.
The SSF for the PCI is unique. The standard gives vendors the freedom to choose their own specific security objectives, and your assessor will only verify the effectiveness of those controls.
- More flexibility is desirable but has potential drawbacks.
- Such flexibility means you'll need to pay closer attention to your controls and win the support of your software stakeholders if you're interested in implementing the new framework.
Unlike the PA-DSS, which always offered a binary result and did not allow compensating controls, the PCI SSS's new objective-based methodology allows any control that reduces risk to be considered compliant.
How does that affect you? When the time for your evaluation comes, you should be prepared to back up your controls with a strong risk assessment based on their threat analysis and have a thorough grasp of how you are meeting each control target.
2. The PCI SSS's security objective testing will be based on other goals.
If the PCI SSF gives you the option to choose your own security goals, you must make sure they are completely implemented for your assessment to be successful. It should be obvious, therefore let's provide an example:
- You must determine your important assets in order to conduct your assessment.
- If certain associated objectives are not specified, it becomes an issue because the pertinent security objectives will need to be tested by your assessor using the essential assets that you specify.
- Your assessors won't be able to test a significant portion of your programme without each security objective in place, which is terrible for your compliance.
3. Under PCI SSS, there will be source code review.
Despite the fact that PA-DSS did not specifically mandate that assessors must conduct source code reviews, PCI SSS does.
Your assessor will conduct a source code assessment of your software, which is especially pertinent to Control Objective 5.2, to confirm the ways in which you previously specified key assets may be accessed. If you anticipate being subject to PCI SSS, you should be ready to participate in the review manually or automatically in addition to being ready for a source code review.
4. The Random Number Generator (RNG) entropy testing is part of the PCI SSS.
Your assessor will be expected to gather information from the software vendor and conduct testing to determine the robustness of the RNGs that your programme use in order to comply with the new PCI SSS.
The test specifications demand that the assessor get at least 128 MB of output data from each random number generator used in the system.
If you already know it's difficult to access your RNG data or you've never given it any thought, start planning ahead and consult with your assessor to determine the best course of action.
5. There’s been a shift in language regarding documentation.
The idea of an implementation guide was first introduced by PA-DSS validation, and the PCI SSS is supposed to preserve it.
However, the semantics have changed.
The PCI SSS standards now refer to the materials you can give to achieve the goals that were once covered by a single implementation guide as "guidance documents" in order to be more inclusive.
This modification gives you the choice of providing a single implementation guide or a number of papers to fulfil the purpose during testing.
6. The PCI SSS mandates "transient sensitive data" and more thorough forensic testing.
Anyone who has undergone PA-DSS validation is familiar with forensic examinations. (Or, at the very least, it shouldn't.)
However, the PCI SSS assessment now covers both persistent and temporary sensitive data. Your assessors will also assess potential exposure points for data:
- Be prepared to discuss these sites where you store sensitive data, both persistent and temporary.
- Additionally, you should be prepared to help with the setup of forensic tools in the testing environment so that your assessor can watch you securely delete sensitive data and monitor data retention.
.jpg "How Integrated Audits Strengthen Data Security and Privacy in REs")
