Privacy Best Practices Guide

Summary

This guide is based on a conversation among members of the Rootconf community about the compliance process for change management in Fintech companies that had done one VAPT (Vulnerability Assessment & Penetration Testing) for security validation assessment pre launch.

Suggestions that have been made here are:

1. Each change in application should go through a security assessment.
2. All requirements in any standard compliance policy would need to be met.
3. Cybersecurity team should provide guidance on approvals for upgrades and patches to systems which require software sourced from a third party.
4. Quarterly security assessments and yearly internal audits are preferred.
5. Twelve-Factor Apps made with configuration management is advisable.
6. A complete SIEM solution or FIM tools also helps in change management.

Terms/Glossary

• PCI DSS: Payment Card Industry Data Security Standard
• CDE: Cardholder Data Environment
• VAPT: Vulnerability Assessment & Penetration Testing
• SAST: Static Application Security Testing
• SBOM: Software Bill of Materials
• SIEM: Security Information and Event Management
• FIM: File Integrity Monitoring
• Github PRs: Github pull requests

Detailed study

The compliance process for change management in Fintech companies has been discussed in detail in this article. The company in question had done one VAPT (Vulnerability Assessment & Penetration Testing) for security validation assessment pre launch.

In such cases, each change in application goes through the security assessment. The assessment exercise can be skipped for those components of the application or codepaths which have seen no change since a previous assessment. This approach results in requiring to scope very precisely the exact nature of the change and determine the next steps. Not all changes require or mandate that the assessment be conducted by a 3rd party contracted by the organization. However, all changes have to keep in mind regulatory compliance and thus any future external audits..

Some recommendations to follow are as given below:

1. All the requirements in any standard compliance policy and SAST (Static Application Security Testing) would need to be met for the changes to an existing section of code which is the intellectual property of the organization.
2. The Cybersecurity team provides guidance on approvals for upgrades and patches to systems (eg. operating system upgrades, updates to dependent packages etc) which require software sourced from a third party. Most organizations have a playbook which includes automated security scans; approved patch list or vendor certifications which are recognised.

Quarterly security assessments are preferable. Fintech companies that have a CDE (cardholder data environment) should be PCI-DSS compliant. CDE infra / services should be isolated from others. One should speak to audit agencies such as ControlCase for a yearly internal audit and ensure audit logs are everywhere. The completion of audit requires code access and infra/AWS access. Application logs should also have checks via a card number detection tool for accidental leaks, and one can use something like TokenEx to reduce CDE liability.

Another suggestion here is to make Twelve-Factor Apps. However, Twelve-Factor Apps require configuration in environment variables, which leads to the following issues:

1. Environment variables are strings, while configuration often requires other data types. This adds a data type parser that one’s app must provide, for variables likely used in a dependency. This is unnecessary overhead.
2. Secrets in environment variables will be copied into sub-process environments. Pruning them becomes another overhead.

Using a ConfigMap instead of a file leads to sub-process vulnerabilities and the attacker does not necessarily have control of one’s PID 1 by the time they can attack a subprocess. Sandboxing is critical here, and that includes environment sandboxing. Twelve-factor apps should have restrained itself to avoiding file-based configuration, and not specifying environment-based configuration. To avoid such risks, one should use a configuration manager.

If one has written infrastructure as code, that should become their SBOM and one can implement change management on top of that via GitHub PRs. It doesn’t matter whether one is using Dockerfiles or Ansible, as long as they are tracking installed software and auditing each PR, and reviews contain explanations. Immutable infrastructure essentially makes change management a breeze, one can show them per release tag of a Dockerfile or PRs and track each via an issue tracker.

One can use a complete SIEM solution or FIM tools for the following:

1. Taking screenshots of the change management process
2. Plotting it out as a workflow in Miro and giving actual examples
3. Walking them through a few tracked and audited issues and PRs
4. Doubling down on immutable infra
5. Having sufficient proof that only a minimal set of people can login to the servers and change any .pkg configuration, and if they do, it’ll get caught in an alert or logging system.

Tech stack/Tech solutions:
Twelve-Factor Apps
ConfigMap
Github PRs
Dockerfiles
Ansible
Complete SIEM solution
FIM tools
Miro