risk-master.com

I’m sincerely grateful to UK Financial Conduct Authority (FCA) for introducing and pursuing the concept of RegTech.

Although currently this effort may seem focused exclusively on the financial market and its regulatory environment, I’m positive RegTech will soon become a one word synonym for “automating compliance monitoring and reporting to boost its efficiency, significantly reducing cost and overhead” in all other industries as well. This task has been a challenge throughout my career, but since 2006 became my priority and primary ambition.

I have served as a head of security for highly regulated payment card processing companies, where our team had to host numerous annual audits, the outcomes of which determined certifications required to stay in the business. Most of our efforts have been dedicated to monitoring and reporting on mandated processes and controls. As both the complexity and scale were overwhelming, we grasped and held firmly to any ideas, options, tools or solutions to automate or script some of those tasks to free scarce resources. Processing millions of payment cards and payments for billions of dollars, one of primary regulations we had to comply with has been the PCI DSS.

PCI DSS has been designed around a specific data subset – cardholder data. The standard is quite specific and requires defined security measures, unlike more generic frameworks like ISO 27001, where we have much more flexibility over the controls we implement. On the other hand, PCI DSS is deemed as a mature and somehow complete set of coherent best practices, which may serve as a benchmark to give the organisation’s stakeholders adequate confidence in its security management maturity. It is a common opinion that adopting PCI DSS is a very attractive path to address current GDPR challenges (searching for “pci dss gdpr” returns numerous links). By replacing the expression cardholder data with PI (personally identifiable) data in the contents of PCI DSS, we receive a set of controls, that has been globally verified in practice during the last 12 years, efficiently reducing payment card fraud.

In my humble opinion, having this mature, invested, nourished and proven standard at hand, creating a new GDPR specific should be seen as reinventing the wheel. I hope the regulators will soon confirm PCI DSS likely “ensures a level of security appropriate to the risk” in common market scenarios, since I also believe GDPR’s requirement of “Encryption and pseudonymisation of personal data” has been inspired directly by the encryption and tokenisation practice of PCI DSS.

Few years ago I had the opportunity to lead the design of an information security management system for a card processor from scratch. With PCI DSS in my mind, I found a system called Alienvault Unified Security Management (USM). Alienvault USM has been designed to integrate several security functionalities under one database and management console, please refer to the following presentation for details:

PCI DSS Compliance Software | AlienVault

In my humble opinion, to this date Alienvault USM offers quite a head start for a PCI DSS oriented environment and remains an attractive option – in our scenario it replaced and integrated several solitary systems. Implementing out of the box functionalities addressed approximately one fifth of PCI’s almost 300 controls in areas of asset / data discovery, FIM, HIDS, log retention and correlation, IDS/IPS, vulnerability scanning, threat management, etc. Great start, but just a foundation, as we are aiming much, much higher, towards a TOTAL security and compliance management system.

Dreaming of automating virtually ALL compliance related tasks, on top of above capabilities we have designed, prototyped, piloted, tested and in numerous cases implemented in the production environment the following value added functionalities (numbers in parenthesis relate to PCI DSS requirements):

Creating automated queries - health checks to ensure, either in real-time or periodically, that:
- all network appliances are configured according to their baselines (hardening/configuration standards), rulesets conform to standard’s requirements (1.2 – 1.4, 8.7, 6.6),
- all systems and subsystems are configured according to baselines (hardening/configuration standards) (2.1 – 2.4, technical requirements of Chapter 8., 4.1 – 4.1.1),
- antivirus and antimalware protection operates effectively for all systems (5.1 – 5.3),
- all systems and subsystems generate audit trails as required, all security functionalities like HIDS or FIM operate effectively (Chapter 10, 9.1, 9.1.1, etc.),
- data retention controls operate as intended, records stored do not exceed their retention period (3.1),
- sensitive data has not been detected in locations other than authorised (3.2, 3.4, 4.2 + DLP).
Automating the baselining or whitelisting process, to ensure network and host IDS and monitoring systems alert in case of detecting a: network protocol, service, cryptographic solutions, technology or functionality that is not specified as authorised. (1.1.6, 1.3.1, 2.2.2, 2.2.5, 2.3, 4.1, 12.3.5, .12.3.6, 11.1.1, etc.)
Integrating and correlating the change management system with monitoring and alerting capabilities of the USM. Every change, be it on a network appliance, operating system, subsystem or application, should be cross referenced and correlated against open change tickets. Change tickets should be only closed based on the anticipated log records from the systems’ components (11.5, 2.4, 1.1.1, 1.1.3)
Incorporating the controls of key management (3.5-3.6.8), development and change management (Chapter 6) into the change management system.
Automating user rights management and integrating it with monitoring and alerting capabilities of the USM. As futuristic as it may sound, user rights should be configured automatically based on acceptance paths defined in the user access rights management system (Chapter 7, 8.1.1, 9.3). This is to ensure any changes in user rights originate only from the system designed to enforce required governance and acceptance paths, while manual and ad-hoc user rights changes should remain exceptional and controlled.
Integrating user account management with HR processes to ensure system rights are always consistent with HR records and all users receive adequate training (9.9.3, 12.6 – 12.7, 8.4, 8.1.3, 4.2). Integrating vendor monitoring with third party management processes to ensure vendor governance requirements are met (12.8 – 12.8.5, 8.1.5)
Integrating media management processes with monitoring and alerting capabilities of the USM to ensure that media actually used on the systems are the ones authorised by the management to move or store sensitive information (9.5- 9.8.2)
Integrating the exception management system with monitoring and alerting capabilities of the USM. Every non-compliance should either be classified as an exception and handled according to policies or be treated as an incident.
Scheduling and automatically reporting on all periodic obligations mandated by the standard (12.1.1, 12.2, 12.10.2, 11.2, 11.3, 1.1.7) – utilising the ticketing / change management system.

Having implemented the functionalities above, how far would we be from the utopia, where compliance management and reporting is about ensuring all lights blink GREEN on the dashboard, being able to click on “Generate one complete and global GDPR (in this example) compliance report in minutes” button any time we like to? Quite close. Let the dream go on: could we find an auditor professional enough to emphasise on validating our controls, to later rely on them, instead of following dreadful and ineffective manual auditing practices like collecting screenshots? Let’s hope FCA’s effort around RegTech will help to turn that vision into reality soon.

Real-time, on demand or retrospective compliance reporting would bring unprecedented comfort and confidence both to the management and the organisation’s stakeholders. If the assurance levels were to be quantified, they should rise by orders of magnitude when compared to manual, time-limited, sample based, point in time audits. Having the ability to prove systems were compliant at the time of a serious incident or breach would be invaluably beneficial during a crisis. All functionalities described above are not only possible, but also quite feasible. What do you need to get there? A large dose of determination, and perhaps some help from very experienced professionals, who already know what does and what does not work in practice. Please get in touch if you’d like to know more.

RegTech, PCI DSS and GDPR - how they fit together