The first rule of cybersecurity at Basiq…
Is to talk about cybersecurity. Security is top of mind for all fintechs but can be a daunting subject. Our CTO, Jim Basey, shared some helpful hot tips at AWS’s FinTrust event. Missed it? Don’t worry – we’ve got you covered!
Cybersecurity is something we talk about a lot because it’s embedded in practically everything we do – this isn’t Fight Club.
It’s top of mind for all fintechs, now more than ever, but for many it is a daunting and overwhelming subject. If you are a fintech in this position, you might be asking yourself, ‘where do I start?’ or ‘how do I know if my cybersecurity is up to scratch?’.
We hear you! That feeling is totally understandable and the questions are common.
Recently Basiq joined forces with AWS to run a session on what startups need to know about cybersecurity based on the AWS Global FinTrust program. This is the first article in a series sharing golden nuggets of security info including answers to the questions above.
First up are some thoughts from our Chief Technology Officer, Jim Basey, on Basiq’s approach to cybersecurity and the rules and principles we live and work by, as well as recommendations for what fintechs could be doing to increase their own security posture.
Basiq’s cybersecurity guiding principles
Everyone is becoming aware, your data is just as important as your money. This is why we at Basiq adopt a “bank grade” security posture. This mindset has served us well for our recent platform expansion to include Payment APIs and services. Below is a view into that mindset:
Security is everyone’s responsibility
We don’t rely on one team to be the security team within the organisation. We do have security specialists however it’s expected that all staff have a good base level of security competence.
Security is part of the tech team’s processes and practices
Security is baked into our product delivery process, getting new features from ideation to being supported in production. We define security requirements along with product requirements when creating or expanding a new product or feature. It’s an embedded part of the process, not an afterthought.
Here are some of the practices and processes we have in place:
Peer review processes
If one engineer has written some code we have another member if the team review the code for basic security compliance to frameworks like the Open Worldwide Application Security Project (OWASP) Top 10. This framework is a set of the ten most common vulnerabilities seen in digital implementations that we use to check for vulnerabilities.
Best practice tools
Such as GitHub Actions for CI/CD. We incorporate automated continuous security checks that enable us to plug in things like secure code scanning and linting.
Maintaining best practice development and design processes
With development and design, AWS Secrets Manager is used to manage, retrieve, and rotate things like database credentials and API keys.
We have strict practices around access control, making sure every action is traceable. We also control what can be changed in production via infrastructure as code (IaC), meaning an engineer can’t just make a click ops or manual change to infrastructure, it has to be implemented as code and deployed along the same pipeline as product feature code.
A zero trust policy
This is another security principle we follow at Basiq, but it’s worth singling out because at a practical level it covers a lot of different areas. So, what does this actually mean?
Jim says it’s basically security paranoia;
“I had a boss once that said only the paranoid survive and in our line of work and in large organisations it’s often true. For us security paranoia is a must.”
Below are some examples of how we implement it on a day to day basis:
Devices are a data free zone
All members of the Basiq team are encouraged to store any data in the cloud and not on their devices. This means it’s easier to monitor and implement obvious security measures like restricting access to certain areas.
We don’t have a network in the office, just an internet connection.
It also means security tools like one time passwords or Multi Factor Authentication can be mandated when it comes to accessing certain data.
Access is on a need to know basis
Zero trust means access is defined at a granular level– employees only have access to the data they need. Regular reviews are also conducted to make sure that if someone’s role has changed and they no longer need access to certain areas, that access is removed.
A well defined offboarding policy
Including making sure all offboarding steps are auditable, automating as much as possible and ensuring there is a checklist for any manual steps.
It’s the little things
Simple rules that are sometimes forgotten like employees locking their devices when they aren’t being used.
Jim suggests implementing something like a three strike policy;
“I used to work for a Swiss bank in London and they had a policy that if you were caught three times leaving your computer unlocked you were walked out of the building and that was the end of your job. I’m not suggesting something as hardcore as that, but maybe something like buying a round of coffees on the third strike. Can be a good way to get people to think about security.”
Assume you are always under attack
Lastly, and back to security paranoia, we treat the Basiq platform like it’s constantly under attack. For good reason too – we have regular alerts reminding us of this.
So, the first rule of cybersecurity at Basiq…
…is to talk about cybersecurity.
Not just internally, but we also want to share our tips, tricks and knowledge with the broader fintech community who might be stressing about their security posture.
Be security aware of how data enters and leaves your systems, how it is stored and who can access it, and you are well on the way to a good security posture.
You can stay up to date on future articles about cybersecurity by following Basiq on LinkedIn or signing up to our monthly newsletter below.
About Jim Basey
With over 25 years of experience working for banks, fintechs and telcos, Jim describes himself as a security generalist. Starting as a developer then working as an solutions architect before moving to leadership, Jim has seen first-hand the most common security attack vectors and the consequences of not being aware.