Make security a critical IT requirement, not an afterthought
- Posted on December 4, 2017
- Estimated reading time 3 minutes
When IT projects are being drawn up, requirements end up in two broad segments: one list may have a set of requirements that are absolutely critical to the functioning of the software. The other list may have another set of requirements, which fall under the nice-to-have options such as availability, support, service level agreements, etc. Security, as a requirement, usually ends up in the second list.
If you try to draw a parallel between buying a car and building requirements for a technology project, the critical requirements may be seating capacity, body type, transmission type, etc. However, sometimes you may also want to look at not-so-critical requirements, like the colour of the car, or a third-party service such as rust-proofing, an alarm system or another type of after-sales item. The non-critical requirements of a car purchase may be something you may be able to live without, but usually the critical requirements are things people rarely compromise on.
In the IT world, patching cycles and the availability of support all fall under the non-critical list. Something that is out of sync with IT’s reality is that security is relegated to the non-critical list, too. That means security may be negotiated – or even compromised – as part of an IT project.
The reality of IT projects is that they can be delivered without any security oversight. In April 2016, a bank in Bangladesh was hacked as it was running its services without any firewalls. In such cases, security is viewed as the non-critical, or in car terms, an expensive after-sales support option. Security should be the critical component of the functioning of a car, like its engine size or power requirement. Fundamentally, security requirements should be embedded as critical requirements and be developed along with the core functionalities of the IT project.
Let’s look at the users’ viewpoint of using a piece of software. When critical parts of a component fail, management views this as a function of lost productivity and assigns a revenue loss figure to this shortcoming. However, when security is low or weak, a breach may happen – and the software may continue to function – but real monetary loss happens further down the line with either reputational loss and/or lawsuits and penalties. Overlooking a security concern and treating it as a non-critical requirement can still cause a monetary loss.
Adding security requirements within any project after the fact is a very hard problem to solve. Imagine a requirement that all software components use the latest, stable patched versions as a non-functional security requirement. This requirement may be overlooked if it is non-critical. If such a requirement is introduced as mandatory after a subsequent breach, there may be interoperability issues.
The good news is that many vendors and cloud service providers are recognizing the value of security and embedding security-related features into their products. The next step is to turn them on and make use of them. There are many standards and guidance lists being published, which can be used to include security as a critical requirement instead of adding it as an afterthought.
I recommend that your next IT project include the following specifications:
- Alignment to an international secure methodology aligned to either OWASP Top 10 or SANS Top 25
- Strong encryption of critical data when being stored in a database or a storage account
- Inclusion of Web Application Firewalls for internet facing servers
- Enforcement of segregated development environments into Dev/Test and Production
- Extending the authentication rules to such development environments
- Ongoing patching and fixing of compatibility issues to ensure all packages are up to date
While the above list is not exhaustive, it should provide you with a good start. Please make sure that security moves into the set of critical requirements in your next IT project.