Security Think Tank: Good procurement practices pave the way to app security

Making and keeping a company’s IT infrastructure safe and secure from unauthorised intrusions or malicious actions has always been challenging. With the increased use of cloud computing, coupled with a need to keep developing new functions at an ever-increasing pace through the use of agile technologies, maintaining good security has become even more complex. 

In buying software and software services from third parties, what the buyer needs is a checklist of key requirements developed from an understanding of the business, technical and operational needs that will drive research of potential products and services.

Once a list of potential suppliers and products/services has been developed, a request for information (RFI) or equivalent can be issued and based on the key identified company requirements.

The answers to that RFI will help refine the list of suppliers and products or services down to a few suitable candidates, so that a request for quotation based on a detailed set of requirements can be issued.

The endgame is contract letting to the selected supplier where the contract itself articulates the company’s requirements in detail. Those requirements would likely be addressees as annexes to the main contract, thus allowing for future changes without the need to renegotiate the main contract. This process might seem long-winded and unwieldly, but ultimately you are aiming for security and you might be betting your company’s future if you don’t cover all the bases. 

The broad principles outlined here can be applied within a large organisation where there is an internal development group or groups. In essence, it would be a contract between the business area and the development and operational groups.  

Back in the early to mid-1990s, I was doing internal IT audit in Europe for a major international bank and I found that audit was not brought in to a project until it went live or, often, after it went live. 

The IT security group was a small two-person group located in a head office many thousands of miles away. I had come from a network and IT background and was able to pull together various security, audit and software practice-related documents to create a small and concise document for the development groups in Europe.

Initial resistance soon evaporated and audit started being welcomed into software projects during the development cycle, opening the door to early and meaningful feedback.

It was a win-win outcome, as both development and audit saved time and less resource was wasted. Of course, today we have DevSecOps, an extension of DevOps, and this ensures that security requirements, together with regular testing and feedback, is built into the software development cycle, leading to less wasted resource.  

Although DevSecOps can be seen as a major factor in improving the overall security stance of a company’s IT infrastructure, it doesn’t mean that the basics, such as patching and well-thought-out access and authentication mechanisms, can be paid less attention.

 Of course, not all companies have their own in-house development teams, preferring to buy off-the-shelf applications or services. 

Where services are bought in, the security processes are not under the direct control of the purchasing company – that is, the purchasing company is reliant on the product or service being secure.

This reliance is primarily predicated on what the purchasing contract covers, and here the devil is definitely in the detail.

For example, you might think that requiring ISO27001 certification and annual testing would cover your needs, but unless you have specified what clauses are required and to what specification level (scope and statement of applicability), you cannot be assured of the level of security.

When you are buying software, consider whether the contract covers code analysis by security experts, whether your company’s security requirements are stated and whether they are comprehensive.

In a fast-moving environment, you will need access to people skilled in defining security requirements where cloud computing and third-party software development is encountered. These people will need risk and threat analysis skills, including a good understanding of business risks because these articulate what is key to protect in a company.

Contract annexes are the best way to handle these contractual needs as they can be updated as required without having to undergo a full contract renegotiation.