What the Government of Barbados Needs to Do to Get Fintech Right

There’s a common misconception that IT governance, risk and control (GRC) professionals like myself impose unreasonable demands on those trying to innovate and deliver human, social and economic benefits to society. But this is the furthest thing from the truth – our role is to ensure that those who are delivering technological solutions understand the risks and impacts associated with their IT platforms, and mitigate them in an adequate, effective, and sustainable manner.

The aforementioned point is key as I will go on to explore the privacy, security, and socio-economic implications of two recent announcements by the Government of Barbados pertaining to the implementation of Blockchain-related technology in the country. In a September 19th article titled ‘E-currency pilot coming’, it was stated that Prime Minister Mia Mottley “did not give details of the planned mobile wallet pilot project or when it would begin but gave the assurance that it would not be done in a reckless manner.” Barbados Today published an article on September 25th which stated ‘BSE to begin crypto-trading’, essentially heralding the decision of the Barbados Stock Exchange to trade in security tokens or crypto assets.

Given my intimate knowledge of privacy and security weaknesses in both the public and private sectors, the PM’s words do not instill in me any great confidence around the robustness of the security controls that will accompany these projects. The implementation of e-currency is a complex undertaking, that if not done correctly, can have a material impact on the country’s already weakened economic position. Security tokens are an extremely nascent solution with a lot of potential, but that doesn’t exempt them from security and privacy deficiencies. As such, I want to delve into some of the key areas that must be addressed before these solutions are widely deployed across our beloved nation.

Contract management and due diligence

Before any contracts are signed to commence these projects, the government must understand where personal data of Barbadian citizens will be stored. To provision users onto these platforms, personal data will need to be collected for AML and KYC purposes such as name, address, phone number, driver’s license, passport details, etc.

If the data is stored outside of Barbados, the privacy of Bajans may not be safeguarded as it will be subject to the laws and regulations of the jurisdiction in which the data resides (meaning that the legislation of a foreign country could permit them access to any and all data kept on Barbadian citizens). This is particularly concerning given the absence of data protection legislation in Barbados that would force any fintech company to ensure that transnational data flows must only occur where the destination country has an adequate legal framework in place to protect the rights of data subjects.

The lack of data protection legislation presents another problem in terms of imposing strict obligations on fintech providers to uphold the rights of data subjects. This includes setting requirements and fines for both data controllers and data processors as it pertains to protecting personal and sensitive data, obtaining consent to share personal/sensitive data, reporting data breaches to government and data subjects, among other rules. Hence, it would be in the best interests of Barbados citizens and foreign nationals if the 2018 Data Protection Bill was enacted into law before the launch of the new platforms.

In an ideal situation, the government should obtain 2-3 references from previous instances where the contracted parties have deployed solutions of this kind for other customers. However, it appears that Barbados will be the first country where the vendor will be deploying a ‘true’ e-currency platform, thus making the need for strong controls even more critical. As it pertains to tokenized securities, similar due diligence must be undertaken to protect our citizens.

The government must ensure that a qualified and independent security professional conducts a site visit to the vendors’ IT facilities to undertake a thorough assessment of their security controls. If this cannot be done, the vendor should be required to furnish government with a signed attestation from an independent and qualified third party that the IT facilities meet all the necessary best practice security requirements (e.g. physical security, grounding and lightning protection, environment monitoring, generators, etc.). Additionally, there should be a “right to audit” clause in the contract that allows the government to turn up at the vendors’ IT facilities at any time to conduct a security assessment.

The vendors’ financial statements should be reviewed by an independent auditing firm such as PwC, EY or Deloitte to ensure that they are in good standing and that they are able to remain going concerns for the foreseeable future. The viability of their business models should also be assessed as ‘feasible’. This would protect the country and its citizens from being left at the mercy of fintech service providers whose platforms enjoy massive uptake and integration into the socio-economic fabric of the country, and then they are quickly no longer in business.

With regards to PwC, EY, Deloitte, and other accounting firms (or any qualified professional services firm as a matter of fact), government should enlist one of them to have experienced IT auditors assigned full-time to both projects. This would ensure that IT governance, risk and control processes are embedded throughout the project lifecycles and don’t become an afterthought.

Another area of due diligence is assessment of the team who will be delivering and supporting the solutions. The government must obtain assurance that the right mix of skills is available to deliver and provide ongoing support for high performance, scalable and secure fintech platforms. Along with the technical positions, key roles that should be in place are Internal Audit (assurance), Privacy (compliance) and Information Security (availability, integrity and confidentiality).

Finally, a software escrow agreement that allows government access to the vendor’s proprietary code in the event they go out of business should be put into place.

Technical architecture

Undertaking a technical architecture assessment is critical to implementing both these projects. Once again, independent and qualified 3rd parties need to look at how the different elements of these platforms will integrate with each other and how they will be secured against cyber-attacks. A number of the questions that the selected fintech service providers need to answer and verify are as follows:

  • How will web and application servers be hardened against attacks?
  • How will database systems be hardened against malicious actors?
  • How will operating systems be hardened and secured from hackers?
  • How will Blockchain nodes be hardened and secured from hackers?
  • How will identity and access management (IAM) be delivered to manage privileged access to these platforms?
  • Will middleware and APIs have built-in authentication mechanisms?
  • Will all data transmitted over public networks be encrypted?
  • What encryption schemes will be used to protect sensitive data in storage?
  • Will network devices such as routers and switches be hardened and utilize strong authentication mechanisms?
  • Will there be separate firewall tiers to isolate and protect servers with higher risk profiles?
  • How will administrators and developers securely access the platforms remotely?
  • How strong will the controls be around disaster recovery/business continuity?
  • Will online or offline wallets be used and how will they be secured (e.g. passwords, passphrases, two-factor authentication, biometrics, etc.)?
  • How are mobile applications designed with security in mind (e.g. storage, communication, authentication, cryptography, etc.)?
  • How are web applications designed with security in mind (e.g. input/data validation, authentication, authorization, storage, communication, cryptography, etc.)?
  • Will private or public Blockchains be used? How will the Blockchain, smart contracts and related elements be secured?
  • If fintech companies are using cloud services, how are issues like multi-tenancy, distributed denial of service (DDoS) attacks, breach notification, malicious insiders, etc. being addressed?
  • How will integration with external systems be secured?

These questions and others need to be satisfactorily answered before these fintech solutions become live. A technical architecture review should be conducted to set a baseline of expectations with regards to the final solution. Bringing trusted, independent cybersecurity experts to the table will ensure that they are no controls gaps in the end-state architecture.

Testing

Testing is one of the best phases in software development to flesh out security issues. Hence, this is where government needs to double down on its due diligence. Below are a couple of questions that government should be asking and receiving answers/evidence for:

  • How are code repositories being used and secured?
  • What processes and tools are used to manage version control and to promote code from testing to live environments? Are these tools fit for purpose?
  • What secure coding standards are being used by developers and what tools are being used to force adherence to these standards?
  • How are static application security testing (SAST) and dynamic application security testing (DAST) being employed?
  • How are source code analyzers being used to detect security weaknesses in both non-compiled and compiled code?
  • Will stress testing be conducted to ensure the system design and resources can support transaction volumes?
  • Are dynamic scanners being used to simulate attacks during the quality assurance (QA) cycle?
  • Have threat modeling and risk assessment been conducted on the end-to-end solutions? Has an independent party verified the results?
  • Does the test environment mimic the production environment as much as possible?
  • Will an independent security architecture review be performed on the system before it goes live? Will all the material weaknesses found be remediated before the solutions go live?
  • Will independent penetration tests (externally looking inwards) and vulnerability scans (internally looking outward) be performed on the system before it goes live? Will all the material weaknesses found be remediated before the solutions go live?
  • What security-related scenarios will be included in user acceptance testing (UAT) or closed user group (CUG) testing (e.g. input/data validation, password quality rules, repudiation, roles-based access controls, path traversal, missing authorization, error handling, privilege elevation, etc.)?
  • What levels of audit logs are generated by the systems? Are audit logs properly secured?

The testing phase provides an opportunity to iron out most of the security issues before the live solution is released to the public. The importance of this stage should not be underestimated, and government must ensure that they are fully engaged and involved throughout.

Deployment and ongoing support

Deployment and ongoing support will be integral to delivering a truly disruptive fintech solution to the citizens of Barbados. Of course, the first step is deploying the exact system configuration that was thoroughly assessed and remediated during the architecture and testing phases. This can’t be emphasized enough – You don’t want to deploy a system full of security vulnerabilities. That being said, there are a number of questions relevant to supporting the environment on an ongoing basis:

  • What processes will be in place for identity and access management? How will day-to-day access for normal users and super users of the systems be managed (e.g. granting, revoking, and updating access)?
  • How will secure configurations be maintained throughout the system lifecycles (e.g. mobile security, desktop hardening, server hardening, switch and router hardening, etc.)?
  • What processes/solutions will be in place for managing system vulnerabilities?
  • What processes/solutions will be in place for managing system upgrades and patches?
  • What processes/solutions will be in place for making changes to production systems?
  • How will production systems be monitored for performance issues, normal and privileged account usage, network intrusions, unauthorized file changes, access to restricted systems, etc.?
  • How will malware be addressed on production systems (e.g. cloud services, virtual machines, nodes, clients, mobiles, etc.)?
  • How will security awareness for end-users of the systems be addressed (especially given that the intention is for the mobile wallet to be deployed widely to the public)?
  • What processes and systems will be in place for disaster recovery/business continuity?
  • How will government ensure that the right legal framework is in place to protect the country and its citizens (e.g. anti-money laundering, taxation, consumer protection, privacy, critical infrastructure protection, etc.)?
  • Who will be supporting the production systems on an ongoing basis – government or the fintech companies? Will there be sufficient knowledge transfer to government personnel if they are tasked with ongoing support and maintenance?
  • Has there been detailed assessment of ongoing costs? Will these costs be borne by the fintech provider or government? If by the fintech provider, what’s the business model that will be in place to sustain their operation in a profitable manner? If by the government, are the right staff in place to support and maintain the platform? Will the overall cost burden undertaken by government be sustainable (especially given the country’s existing financial situation)?

Monitoring and evaluation

For any system implementation to be truly successful, there must be a plan for realization of the benefits articulated at the beginning of the project. Here are some of the key questions to be answered:

  • What does success look like?
  • How will success be measured?
  • Will success metrics be shared with the public (they should be when taking into consideration the levels of risk and investment in these projects)?
  • Are the projects delivered on time and within budget?
  • Have technical objectives been achieved?
  • Have financial objectives been achieved?
  • Are socio-economic benefits being realized by the population?
  • Have human behaviors changed in terms of the use of mobile payments?
  • Has the Barbados Stock Exchange (BSE) become more liquid? Has there been a significant uptick in foreign direct investment (FDI) via the BSE? Are we seeing more security tokens being traded on the BSE?
  • Are there less underbanked or unbanked individuals in the country? Have financial inclusion statistics improved? Is the common man less burdened by the cost of banking? Is it now easier to send money overseas (money transfers) or send money back to Barbados (remittances)?
  • Has government reduced the costs of funding the fiat monetary system?
  • Have the substantial risks associated with correspondent bank de-risking been mitigated?

These questions and more need to be answered once the systems go live. More importantly, a benefits realization/monitoring & evaluation (M&E) plan needs to be in place up front. The government and its fintech partner should not be deciding what needs to be achieved and measured once the systems go live – these benefits should be stated up front to convey the value proposition and return on investment (ROI) for the systems, and to support the level of investment and risks undertaken.

Conclusion

These projects represent significant benefits for the country. Conversely, they also represent significant risks. I am not against technology; I have spent the last 10 years of my life committed to facilitating the use of ICTs for development (ICT4D) in emerging economies. However, I am of the firm belief that citizens have a right to know exactly what their leaders are getting them into (i.e. openness and transparency are of utmost importance). It is my hope that government will engage in a more transparent process as it pertains to the planned implementations of Blockchain and distributed ledger technologies (DLT). Moreover, if fintech is being done, it needs to be done RIGHT. One of the most basic, yet important, tenets of information systems auditing is “TRUST, BUT VERIFY”. All of the questions I have posed deserve answers. Not only answers, but verifiable evidence. Government is not known for strong expertise in IT law, policy and regulation; systems development; and cybersecurity. This is why the citizenry of Barbados cannot be expected to abide by only trust as it pertains to the implementation of Blockchain technologies across the country. The potential benefits, and the risks, are way too high!

The Impact of the GDPR on the Hospitality Sector

Today I held a General Data Protection Regulations (GDPR) awareness seminar for members of the Barbados Hotel and Tourism Association (BHTA).

With regards to data security, there are few sectors more vulnerable to data-related threats than the hospitality sector. The volume of processed personal and credit card information being handed over to hotels, restaurants, etc. on a daily basis makes the sector extremely vulnerable. With the enforcement deadline having passed on 25 May, several companies in the sector have not updated their data protection processes, and are at risk for large financial penalties.

The seminar touched on key areas such as the following:

  1. Major Differences between the Data Protection Directive 95/46/EC and the GDPR
  2. Overall readiness across the hospitality sector
  3. Capturing and using personal data going forward
  4. Consent and contextual use of personal data
  5. How the GDPR affects repeat business and email marketing
  6. How the GDPR affects third-party data processors
  7. The rights of data subjects under the GDPR
  8. The difference between ‘personal data’ and ‘sensitive data’, and how they should be treated
  9. Other key aspects of the GDPR such as the Data Protection Officer (DPO), Data Protection Impact Assessments (DPIA) and ‘privacy by design’
  10. How to update strategies for websites, data governance, and marketing to become GDPR compliant

My takeaway from this session was that many businesses — small to large — have not made any steps to align their operations and processes with the requirements of the GDPR. Several others are defiantly refusing to address privacy and data protection within their organizations. However, what was gratifying is that I received a torrent of emails in the hours and days after from hoteliers, many of them eager to engage subject matter experts (SMEs) to assist in improving their control framework to meet the rigorous demands of the GDPR. Hopefully, this interest and willingness to improve is sustainable. There’s a lot of work to be done!