Here are four important security requirements to include in your RFI process:
Identity management can make or break the integrity of your architecture. If a core banking system allows you to bring your identity management system, that means you have full control of the authentication rules that apply. You control how, what, where, and when your users can and cannot access.
If it doesn't have support, that means you need to deal with separate logins for your core systems. This results in a lot of overhead in managing these logins. If there is no BYO identity supported there is, after all, also no Single Sign-On capability. You should realize that means that it is also questionable whether the application can support Multi-Factor Authentication or conditional access.
Access of service provider to your data
The first question here is: does the service provider need access in the first place? It's important to define, before issuing the RFI, when and under which circumstances they would need it. Is it permanent or just in case of trouble? And do these situations require instant access or can they receive access based or does it include a management approval step? Whatever the answer: if your service provider has permanent access, this means there is no strong sense of the level of security required in banking.
- Is the company using infra as code and a single code base?
Using a single code base and treating infrastructure as code enables a Service Provider to quickly and thoroughly fix a security vulnerability. Without using these principles, fixing a security vulnerability will ensure additional lead time to identify what to fix and where. Due to the number of manual activities involved, there is also a greater risk of missing things, and consequentially remaining vulnerable.
- Historical public track record
It's not so much a question to include in your RFI, but definitely, part of the initial inquiry before you send out your RFI: make sure to check the public track record with regards to security breaches. What you are looking for is not so much the presence or absence of security breaches. Hackers learn new skills every day so a breach is always possible. What you should look for is the response to breaches or apparent vulnerabilities. It tells a lot about how a company perceives risk. How do they deal with it? Are they hanging the person bringing the leak to light? Or are they fixing the issue?
- Finally, make sure to cover basics in security requirements like
- Key management
- Data encryption
- Privileged account management
- Exit strategy
- Data ownership
- Escrow services
- Logging and auditing
- Regulatory compliance
- Business continuity
- Vulnerability management
- Secure Software Development Life Cycle
All these elements are vital to making sure hackers are kept out the door as much as possible. But it's an illusion to think you can always keep them out. So it is just as important if not more important to notice the intruders if they do manage to get their foot in the door.
