External IT Audit of Uplata, a Ukrainian Payment System

The challenge

A payment service lives on trust. People enter their card details to pay their bills, and banks and card schemes expect every company that stores, processes or transmits card data to protect it under the Payment Card Industry Data Security Standard (PCI DSS). For a young FinTech project, preparing for PCI DSS is often the first time its code, infrastructure and processes are checked against an outside standard.

In 2015 the bar was moving. PCI DSS version 3.1, published in April 2015, removed SSL and early TLS from the list of strong cryptography, and at the time the migration deadline was 30 June 2016 (PCI SSC later extended it to June 2018). The standard also asks for custom code to be reviewed before release and for developers to follow secure coding guidelines such as OWASP (requirements 6.3.2 and 6.5).

So a useful audit has to look at more than one layer. Servers, networks, code, processes and people all decide whether card data stays safe, and a gap in any one of them can stop a certification.

My task: as an external Information Technology Auditor, assess the quality of the source code, the security of the IT infrastructure, and the suitability of internal business processes and staff qualifications, and give the team clear feedback on what to improve.

What does PCI DSS ask from a payment company?

PCI DSS is the security standard of the card industry, managed by the PCI Security Standards Council. Its twelve requirements are grouped under six goals: build and maintain a secure network, protect cardholder data, manage vulnerabilities (including secure software development), control access, monitor and test networks, and keep an information security policy that covers people and processes.

Before a formal assessment by a Qualified Security Assessor (QSA), companies usually run a readiness or gap assessment to find what is missing and fix it in time. The PCI SSC’s Prioritized Approach helps to order this work so that the biggest risks are reduced first. My audit played this role for Uplata’s infrastructure, and it also looked at the code, the processes and the people behind it.

What I did

1. Reviewed the quality of the source code

   I analysed the quality of the source code, written in PHP with jQuery and HTML on the front end. I gave the team clear feedback on how to improve its structure, remove redundancy and fix repeated error patterns. Cleaner code is easier to review before each release, and in a payment system that review is also a security control.

   Technical details

   • Structure: how the code is organised into modules and layers, and where it is hard to change safely.
   • Redundancy: duplicated logic that has to be fixed in several places at once.
   • Error patterns: repeated mistakes in error handling and input processing, checked against common web vulnerabilities.

2. Assessed IT infrastructure security for PCI DSS readiness

   I assessed the security of the IT infrastructure against what PCI DSS expects from a company that handles card payments. The findings and recommendations contributed to Uplata’s successful readiness for PCI DSS certification.

   Technical details

   • Network: separation of the systems that handle card data, firewall rules and remote access.
   • Access and encryption: who can reach what, and how data is protected in transit, including the move away from SSL and early TLS.
   • Operations: patching, logging and monitoring of the systems in scope.

3. Interviewed managers and technical specialists

   I conducted interviews with managers and technical specialists to understand how the work was really done. Based on them, I gave the management team critical insights on improving internal business processes and on growing the qualifications of the staff. A security standard is kept by people, so these recommendations mattered as much as the technical ones.

4. Reported findings with clear priorities

   At the end of the on-site assessment I brought the findings from code, infrastructure, processes and people together in one picture, with clear recommendations ordered by risk. This gave the management team a plan they could act on, both for the PCI DSS certification and for the growth of the product.

Results

In October and November 2015, the audit delivered:

• Clear feedback on the source code: its structure, redundancy and error patterns.
• An assessment of IT infrastructure security that contributed to Uplata’s successful readiness for PCI DSS certification.
• Critical insights on improving internal business processes and on enhancing staff qualifications.
• One independent picture of technology, processes and people, with recommendations ordered by risk.

What I learned

A payment system is as secure as the way its team works.

PCI DSS readiness is often treated as an infrastructure project. In this audit the code and the people mattered just as much: code that is reviewed before release, clear processes and skilled specialists are what keep a payment system secure after the certificate is issued. An independent audit is most useful when it looks at all of these together and turns them into one plan.

Evidence and further reading

• Client · uplata.uaUplataThe Ukrainian payment project I audited.
• Related projectInterim CTO for a Forex and crypto trading company in DubaiA recent assessment of teams, infrastructure and security against compliance requirements.
• Related projectDORA compliance: benchmarking data center resilienceTechnology-risk rules for regulated financial companies in practice.
• Related projectCTO and co-founder of a privacy startupSecurity by design in a product of the same years.

The SSL and early TLS dates are from the PCI Security Standards Council; the code review requirements are quoted in the OWASP Code Review Guide.

Skills and technologies

• IT audit
• Information security
• PCI DSS
• Compliance readiness
• Code review
• PHP
• jQuery
• Secure coding
• OWASP
• Infrastructure security
• Network security
• Process assessment
• Staff qualification assessment
• Stakeholder interviews
• Risk-based recommendations
• FinTech
• Payments

← All projects