In this article, I would like to address the application of security standards requirements in the software development process. In general, it has been prepared and compiled according to the requirements of the PCI DSS standard. These requirements can also be applied to the processing and storage of personal data in order to meet the requirements of the GDPR. There are different assessments and analyzes in different parts of the world. Let’s try to detail and explain these requirements.
PCI DSS Requirements
1. Minimize storage space and time of critical data.
In the context of this publication, sensitive data is data (such as card and personal data) whose security is regulated by PCI DSS + GDPR requirements. Is such data necessary in principle or can it be anonymized? Is it really necessary to store critical data in this volume? Can duplicate data be avoided and how can it be minimized? It is necessary to find answers to questions such as:
2. It is recommended to store critical data in databases in encrypted form.
Critical data should be stored encrypted. Encryption via a database (or file system) is sufficient. However, it is much safer to use additional encryption as part of the data transfer and then place it in the database in encrypted form.
In this case, it is necessary to specify a strong encryption algorithm, to ensure the possibility of data re-encryption when the key is changed, and also to provide a secure method for storing or generating a key.
3. Client network data streams must be encrypted.
Critical data must be transmitted over an encrypted channel. Critical network data must be transmitted over an encrypted channel. Officially, it is enough to use the TLS security protocol, but it is better to ensure that the transmitted information is encrypted at the software level. It is recommended that the application connects to databases in an encrypted manner.
4. If photos of payment cards are taken, they must comply with security requirements.
The collection of user data for verification processes usually includes the collection of graphic materials showing payment cards on which card data (PAN, CVV) can be displayed. A simple solution is to delete such data from the systems and ask the customer to re-supply the photographic copies of the required format on their own. The next option is to delete the critical data yourself and save the photo without it. An even more interesting option is self-written or purchased services for recognizing and blurring CVV and card numbers on graphic images.
5. Databases must be on a separate subnet from the application subnet.
To reduce the risk of critical data leakage, databases should be located separately from the subnet where the applications are located. Given the ubiquitous virtualization, it is also recommended to consider the possibility of additional separation of database and applications.
6. All test parameters must be cleared during the run-in process.
Credentials are often used as part of the integration. This brings some risks. It is recommended to use test data when exporting to the production environment, such data should be changed or deleted.
7. It requires the use of secure technologies and strong encryption algorithms.
Not all encryption algorithms are considered strong. Also, keep in mind which country ordered this or that algorithm and whether there are surprises in the algorithm itself or its implementation.
8. It is forbidden to store user passwords (except hash format only)
Due to the nature of this business, this may sound like an ordinary suggestion. However, it should be noted that sources with full user passwords still leak data. These passwords can be hashed, but again, this is not strictly necessary. Better to dilute the hash itself.
9. Checking for OWASP TOP 10
It is necessary to validate the solution for major vulnerabilities before committing it. Different vulnerabilities can be tried, but it is recommended to check at least OWASP TOP 10 for a start.
10. Use of personalized accounts.
It is necessary to be careful in the use of group accounts in the software, both during the testing phase and when transferring the system to production. This greatly complicates investigative processes and also ensures separation of powers.
11. Log actions with the ability to redirect to external systems.
The system should provide a feature to log user actions and access card data. The logging should be arranged in such a way that it is possible to export in a suitable format. Subsequently, checking and correlating the integrity of the logs and their storage will likely make it easier to implement using a third-party system. Logs should not contain critical data.
12. A system of separation of powers with minimum necessary rights.
The system must have a system for defining authorizations. Such a system can be role-based or based on a mixed access model (matrix can also be used, but is very complex when there is support and a significant number of users). The separation of roles must be built on the basis of the separation of powers matrix.
13. Encryption with secure keys.
Switches should be changed at least once a year. Key transmission must be done through secure channels. Key storage should be provided in a way that minimizes the potential for compromise (secure key storage solutions, shared key storage, data-driven key generation processes).
14. Requirements for password strength.
Passwords that do not allow brute force attacks should be selected. The storage and transmission of passwords should be provided in a way that minimizes the possibility of being compromised (password storage, segregation, etc.).
