PCI-DSS (Payment Card Industry Data Security Standard) is a norm, a standard for any organization involved with card transactions and storing card data. I won’t be going to rudiments of PCI-DSS as these are well covered in many articles across the Internet. The whole idea of this post is to understand the key considerations for implementing PCI-DSS in public cloud.
Here are top five recommendations from my experience with implementing cloud ecosystems for financial institutions. These are based on PCI-DSS v3.2
Recommendation 1: Restrict Access – Just IAM isn’t enough, segmentation is the key.
PCI compliance requirements entail that the access to key data and data storage systems is limited. The access can be limited/restricted by using IAM. As leading practice. segment your production and test, QA, or development environments. Prevention is the key and by segmentation you can ensure that no unintended audience gets access when segmentation (VPC or VNET based) is augmented by the IAM controls. It’s really important to make sure that your IAM user policies allow users in your environment only to do what they need to do.
Recommendation 2: Leverage more than Native Cloud Security – Multiple VPC/VNET based segmentation complemented by ISVs for advanced security controls.
PCI-DSS requires that card holder data is secured. The best way is to have this data in your private subnet(s) that isn’t directly accessible from the Internet. The combination of security group policies and network access control list is an effective way to ensure only traffic that’s intended to get in or out, get’s in or out. Additionally, leveraging advance security controls is beneficial to get more visibility inside the cloud. For example, deploying ISV firewalls at perimeter of VPCs/VNETs can give a lot of threat and DLP protection that cloud native security doesn’t offer. Moreover, the logs from ISV offered firewalls can be used for threat monitoring as well as incident response.
Recommendation 3: Encrypt Data in Transit – Data security is paramount, even more so in transit.
Data in transit is most susceptible to attacks from within and outside an organization. An absolute requirement is to encrypt your data using VPN (site-to-site) or with SSL/TLS. Make sure that the cipher suite only allows secure ciphers for example – do not allow SSLv1.0 in the list of ciphers. Also, it is important to understand where to terminate the incoming SSL streams i.e. at ELB or at web servers. While it depends on environment to environment on where the SSL/TLS would be decrypted, a nominal schema could be if you have a large setup sitting behind external/elastic load-balancers, you can terminate your SSL at the elastic load balancer. For a small subset of servers you can terminate it on servers. Again, the question of being able to look into encrypted streams by firewalls or threat-prevention systems would lead to one or the other decision.
Recommendation 4: Patching and Vulnerability Management – Both go hand in hand
Making changes first in staging environment and testing patches on a regular cadence helps avoid usual issues and pitfalls pertinent to vulnerability management. Patching doesn’t end up at operating system layer however, application patches also matter. Once, testing is completed, you can roll out patches to production during a maintenance window. For example, you come across a new POS software that needs to be patched and the application at the back end also needs patching. You won’t wait forever to patch these as, PCI-DSS 3.2 mandates the patches to be deployed outside of usual vulnerability management cycle as soon as an exploit is discovered; within a month. This is better known as prioritized approach. Besides patching, there’s vulnerability scanning of your web servers and other applications, which must be done on regular basis – to be more precise at least every six months unless there’s a change in any network configuration.
Recommendation 5: Secure Your System and Apps – Secure Development is Key, Let’s not forget Logging
While developing applications in a PCI environment, it is common to follow top 10 project and guidelines from Open Web Application Security Project (OWASP). Secure development of code and deployment leveraging OWASP is a key not to get hacked (easily). Besides secure development, there are some nifty logging services offered by AWS and Azure to help secure your applications. For AWS, logging services for example – CloudTrail, ELB logging, and S3 logging helps identify the sources of changes in your cloud environment and offers audit trail. On the other hand, Activity Logs, Azure Diagnostic Logs, AAD Reporting, and Virtual Machine & Cloud Services are some of logging services offered by Azure.These services allows you to understand if and when changes are made to your environment and enable you to observe any discrepancies.
These by far, are not a comprehensive list of recommendations, security controls or services that may be used with your cloud implementation for PCI-DSS environments. This is just a small list of most viable and possibly critical services and controls that you would want to enable / deploy for your cloud setup.
Give a thumbs up if you like this article and if these recommendations are useful to you. Comments and feedback – most welcome.