In May 2008, I wrote a blog about security through procurement. I wanted to make a case for it as it seemed such a logical thing to do. As it's still as relevant today as it was then – over a decade later – and as it follows on nicely from my DevSecOps blog, I thought it worth sharing.
Here's what I said.
Consider the fact: if it costs the same to install or develop a system (badly), as it does to install or develop it securely; why would you leave the choice to your supplier? The answer is you wouldn’t. Yet so many businesses actually do just that – they design and deploy systems without considering the security aspects from the outset leaving their businesses wide open to attack and unnecessary spiralling costs. This blog explores a couple of simple actions that can be taken in order to ensure that this doesn’t happen.
Typically when a business unit identifies a new venture, it creates a set of business requirements. These are passed to the IT department to interpret and a set of technical requirements are produced. Suppliers are then selected and another level of interpretation occurs. Quite often it’s pot luck as to whether the response resembles something similar to the original business requirement. By the time internal audit and information security get sight of them, they've usually been installed and functional for months. At this point, more often than not, the organisational policies and standards are found to be incompliant and significant unexpected costs are often incurred to rectify the matter.
And all this is totally needless.
Let’s start with implementation. For years, many of the world’s leading commercial software manufacturers have actually taken the time to research their products extensively – to ascertain where insecurities lie in relation to their software and also the ways in which they relate to secure design, deployment and management. Conveniently the result has lead to a widespread adoption amongst many to produce framework documentation, blueprints and system-based approaches. Cisco’s SAFE and AVVID, Apple’s Secure Coding Guide and Microsoft’s Solutions Framework (MSF) serve as useful examples.
Yet in spite of these useful tools and best practice guidelines, many businesses fail to make use of them. Unbelievably they are neither used in standardising the implementation policies nor in project specific security terms for procurement contracts and supplier service level agreements (SLAs). As a consequence many of the known issues that have already been identified by the software manufacturers, such as architectural design flaws, software integration incompatibilities, patches and so on are overlooked in the implementation process. When they are discovered (usually during the security assessment phase of the project) retrofit and reinstallations are inevitably required. So too are retests – to confirm that the vulnerabilities have (or have not) been fixed.
It’s a similar pattern for software development. Volunteer groups have collaborated to produce useful open-source documentation, standards and tools. For instance, best practice recommendations for security testing can be found within the Open Source Security Testing Methodology Manual (OSSTMM) and for web application development within the Open Web Application Security Project (OWASP).
Yet still, many businesses develop software in the knowledge that security vulnerabilities identified within applications are commonly introduced by development or design flaws . As a result many are faced with the delivery of an application with avoidable security issues. Although many will have an initial security assessment before going live, nine-times-out-of-ten it’s often followed by a costly and timely retrofit and re-assessment. Sometimes, it can even result in the total failure of the project. Sound familiar?
Anyway working like this is clearly ineffective. So, what can be done to address the problem? Well, two very simple changes can make a huge difference.
Firstly, procedures should be standardised and communicated to those involved. Whether a business is procuring something off-the-shelf or bespoke, both internal audit and information security should be involved right at the start of the project, from the strategy planning stage all the way through to the evaluation and specification of the selection criteria.
The main reason for this is because both teams help to provide a systematic, measurable assessment of how the business' security policy should be employed in a specific situation. What’s more, they review how the confidentiality, integrity and availability (CIA) of an organisation's information assets must be assured. This then enables threats and vulnerabilities to be identified and appropriate controls to be selected before any money is spent. Fundamentally, if both teams are involved from the inception, the business is able to protect the integrity of its information without incurring any unnecessary and unexpected surprises later on.
Secondly, a business should do its best to contain its costs and maximise its investment by binding the internal auditors’ and information security team’s recommendations into the procurement contract or SLA. These should make reference to the business’ own security standards, ideally both in software development and in implementation. Furthermore, these should also specify that audits and assessments be built in, with penalties incurred for inadequate service delivery – design, installation or software development.
By clearly defining the security requirements expected from the supplier in this way, not only can a business reduce its risk exposure and gain reassurance, but importantly it can transfer any cost that can be associated with reinstallation, software redevelopment and retesting onto its suppliers. Should any deviation arise thereafter, the supplier would be made legally and financially accountable – not the business. Only by taking these measures could a business be able to hand a substantial proportion of the cost relating to security back onto its supplier and ultimately deny them the choice of whether to install or develop badly or not.
Now I want to hear from you…
Tell me, in the comments below, if you're embedding security into your terms and conditions, SLAs and if your procurement (including lawyers) are involved in the process. And, if you want to book me as a paid speaker for your event, or as a strategic adviser to enable your business or department, complete this form.
