Purchasing a new application for your organisation can be fun and also stressful. I wrote this article to share my tips on what to look out for - please feel free to add to these with comments below.
- Firstly, have a very clear idea about what problem needs to be solved and/or the specific business requirements. It's easy to get excited about a new application that has a lot of features and sounds like "just the ticket". However, IT vendors won't necessarily understand your specific business environment and processes. Sometimes business processes may need to adapt to a new application, however it's important for the non-technical requirements to be clearly understood, documented and agreed so everyone is on the same page with what it is meant to achieve once it's implemented.
- Think about how this application fits in with the overall enterprise architecture and consider what and how other IT systems need to interface with this app (e.g., via an API) and possible security implications such as elevated privileges, vulnerabilities, whether it is public facing and/or whether this could be used as a "pivot point" for an attacker to move laterally in your environment.
- The STRIDE threat model can be a useful way to identify possible security threats which can then form security requirements to be tested against during configuration and implementation. STRIDE stands for Spoofing, Tampering, Repudiation, Information leak, Denial of service, Elevation of privilege. This threat model should be applied across the entire end-to-end process, so it's not just looking at the new application in isolation.
- Check whether the IT vendor has ISO 27001, SOC 1/2/3, and/or other certifications and if so, request for a copy of the certificate or reports. SOC 1/2/3 reports provide a lot of details about specific security controls, and although these certificates won't mean the IT vendor will be perfect or never suffer a major cyber-attack, it's a way of demonstrating you've done due diligence.
- Check the IT vendor's website for details on specific security controls - they might be included in the Privacy Policy, user Terms & Conditions and/or other policies they publish on-line. As above, it won't mean the IT vendor will be perfect or never suffer a major cyber-attack, but when comparing a number of IT vendors, you'll start to see the ones that provide a lot of information and seem to "say the right things" versus IT vendors who lack transparency and gloss over even the basics. Security controls worth checking for include how they manage their own staff access, how vulnerabilities are managed, where the data is located, business continuity / disaster recovery plans, SLAs, how user vs administration access is set up, including multi-factor authentication and logging.
- Check the National Vulnerability Database https://nvd.nist.gov/ for published vulnerabilities and identify / plan how the app will get patched in the future - not everything can be updated by automated patching software. Where an app needs to be installed on a laptop / desktop, make sure the latest version of the app will be getting installed.
- Also check for news articles about any data leaks and how / whether they have been remediated. In the event of a data leak, it would be difficult to explain to a client why your organisation decided to use a particular app that had recently suffered major data leak and they had not provided the public much confidence that the exploited vulnerabilities had been adequately resolved.
- Reading contracts can feel overwhelming if you don't have a legal background, as everything is written in "legalese". However, lawyers will not necessarily understand the business requirements, and just flicking the contract over to a lawyer without first reading through it, could cause lots of headaches later on. Things to look out for include clauses around how the fees are calculated, auto-renewals, termination notice periods, how changes in the number of users will be calculated (including ensuring that fees will drop if the number of users go down), how data can be retrieved upon termination, exchange rates, who is responsible for what, and liabilities (possibly the most debated clauses).
- Consider what might happen if the app goes off-line - does the data need to be backed up, can the system be easily re-configured once it comes back online and is it possible to implement workarounds during the "disaster recovery" period.
- Lastly, if the app will be collecting, storing and/or processing EU / UK personal data you must comply with GDPR / UK Data Protection Act. The IT vendor stating on their website they are "GDPR compliant" is not sufficient. A Data Processing Agreement MUST be in place between your organisation and the IT vendor, whether or not your organisation is the "Data Controller" or "Data Processor". Data Processing Agreements are generally generic and difficult to negotiate. However, the important things to check for include how the rights of the "Data Subject" will be managed, and the transparency around what sub-contracting arrangements are in place, including "third country" locations.
I hope you find these useful whenever you ever need to navigate through purchasing a new app for your organisation.
