Third-party product risks

Buying electronics can be expensive. Phones, tablets, smart speakers and so on are some of the most popular devices in our homes today.

Think about the last device you spent money on, where did you get it? In theory, when we buy these products, we’re buying a commercial off-the-shelf product that we trust to be secure. For example, downloading music or movies illegally might save money in the short term, however long term, you risk damaging your computer with malware, etc., quite apart from the legal and ethical considerations. Legal downloads, by contrast, cost more in the short-term but are secure and above board.

Off-the-shelf risks 

The most dangerous threat from commercial off-the-shelf applications (CoTS) is from rogue code planted to perform a malicious attack on the organisation. However, if the vendor is a trusted and reputable source, this threat decreases, a concept we explored with our music sources just now.

A more specific example could be, if, say, a new version of Microsoft Office contained rogue code, it would almost certainly be discovered by the security testing community that routinely look for bugs, so their development rigour and product offerings can be trusted. You can see how important it is to purchase from a reliable source; pirate software is unlicensed and is where you’re likely to find deliberately planted malicious code. Purchasing this kind of software, even unknowingly, can leave an organisation open to prosecution under local copyright and intellectual property protection laws, and potentially to considerable damage.

This isn’t to say CoTS can’t be trusted, but you must always use a reputable source. After all, not every digital solution can be built uniquely for the organisation, so the need for a CoTS at some point is inevitable. When sourcing the best product, it’s key to have an understanding of the vendor’s bug reporting system, and level of support. Once a decision has been taken to deploy software, it’s essential that it’s maintained, and that security patches are applied quickly.

Accreditors as risk mitigation 

Some businesses and government bodies, such as military and intelligence organisations, use Accreditors to ensure that their CoTS (and bespoke) systems meet the requirements of their security policy. Accreditation is typically granted when systems have passed all aspects of penetration and vulnerability testing and have illustrated that they meet all aspects of the security requirements. It’s important to note that accreditation is a dynamic process and should be conducted regularly through the system life cycle, this ensures that risks associated with updates and changes are kept in check.  

Some examples of Accreditors include:  

• CREST (Council of Registered Ethical Testers) provides assessments of companies providing security testing services and individual testers.   
• The NCSC (The National Cyber Security Centre) has established a scheme, the Certified Cyber Security Consultancy, which certifies competent independent consultancy companies who offer information or cyber security advice and guidance.  
• Tiger scheme is a commercial certification scheme for technical security specialists, backed by University of South Wales covering a wide range of security testing services. 
• UKAS UK Accreditation Service – ‘checking the checkers’.

The change control process 

As just mentioned, updates and modifications need to be carefully monitored to ensure no bugs or malware are inadvertently introduced into a previously secure solution. One way to achieve this is to implement a strict change control process. Let’s have a look at the steps involved now.  

• The process starts with an outline of the change request and the associated rationale being issued to the stakeholders.  
• Then, the change request including the benefits, risks and costs, are considered by the change approval board, which generally includes information assurance, security, operational and technical representatives.   
• Next, the change enters Functional Testing, which ensures usability, accessibility and requirement specs testing is done. It’s at this point you’d also see Regression Testing, which ensures that the product still works after the new changes have been made, and that the changes have not caused some other component to break.  
• Finally, a copy of the new code and documentation is lodged in a secure place to support business continuity and disaster planning.  

What’s next? 

Now you have an understanding of what CoTS’s are, and how to mitigate risk when implementing new software, it’s time to move on and think about outsourced development risks. Take note of what you might have to consider when working with those outside of your organisation, and let’s see if there’s anything you might have missed in the next article.