Following the recent news of The UK’s National Cyber Security Centre (NCSC) warning businesses not to become ‘seduced’ by the attractiveness of issuing phishing tests to staff while also publishing new guidance to encourage organisations to work in tandem with others in their supply chains to identify and address security issues, following a marked rise in incidents. Duane Nicol from Mimecast has commented on many important issues, including the importance of keeping users engaging in awareness training.
While a business may have the right security controls in place, it doesn’t mean their vendors across the supply chain do. This is particularly important when a business relies on third-party software or API dependencies. The NCSC’s new guidance will be helpful for organisations that are trying to navigate this complex risk.
The expanding software supply chain — along with the complexity of modern applications — means vulnerabilities will be introduced at a greater velocity. To help address the growing scale of attacks within the software development lifecycle, organisations need to adopt a threat model that includes all parts of the supply chain, including Nth-party code. The approach should focus on protecting the data and all paths to it, recognizing the intractable problem of third-party software applications and libraries that have direct access to sensitive data.
Organisations must also think differently about protection. Modern applications are powered by a complex ecosystem of APIs, microservices, and serverless functions. Defense starts by identifying run-time application behavior and blocking unexpected behaviors that can lead to a novel attack.
Further, having visibility into specific APIs – and the data they’re accessing – is fundamental. API ecosystems are growing rapidly to enable applications and databases to seamlessly work together to exchange data. Without the right protection, an API is a critical part of the software supply chain that can be compromised as a pathway for hackers to access an organization’s sensitive data.
A supply chain attack as more than just a security issue; it’s an operational threat that can impact the physical supply chain and the wider economy. For example, software security issues targeted at an order fulfilment application could cause downstream disruption to the physical supply chain, such as stopping orders from leaving the warehouse and leaving customers without their goods. This represents a complex issue that impacts both businesses and consumers.
The guidance from NCSC on securing software supply chains is a positive step towards raising awareness of the issue in the wake of damaging attacks, such as SolarWinds and the Log4J vulnerability. However, it offers the security industry very little in the way of actionable, technical information as it mainly focusses on issues such as supplier and stakeholder communication and “identifying your crown jewels”. With this information being aimed at security professionals – among others – it lacks a bit of depth and can only take organisations so far in the journey to securing software supply chains. We must have more sophisticated, technical guidance on issues such as the provenance of open source software if we’re to counter this complex problem.
The government should be recommending specific tools and guidance from trusted sources that will help organisations to evaluate their software supply chain’s security posture and prioritise critical tasks. This can seem like an overwhelming mission for already stretched teams, but there are tools, such as Jetstack’s Software Supply Chain Toolkit, which draw on advice from the likes of CNCF, and help developer and security teams to assess their supply chain security posture. From here they can prioritise how to move forward and identify which aspects are quick wins, and others that are longer term projects. Without this kind of fastidious approach and collaboration between governments and the industry, we will continue to leave supply chains vulnerable.
The NCSC warning of businesses needing to be careful about embracing phishing tests is correct. Tests can be subjective as IT teams running phishing simulations do not give users enough context as to why they are running these tests, failing to show why this training is of value to the business. As a result, users do not know why they are being asked to participate, further disengaging them from the whole process. Disengagement can lead to real life mistakes with real life consequences.
Last year was one of the worst years on record for cybersecurity according to our State of Email Security research. Data breaches through phishing was revealed to be the biggest culprit, with 36% of data breaches due to employee credentials stolen through a phishing attack. 96% of these attacks occur through email, this just reiterates how pivotal it is to keep users engaged in training programmes and create a culture of always reporting suspicious emails.
Holistic awareness training is far more suitable for keeping users engaged as it provides more context as to why employees are having to do this and how it contributes their organisation’s overall cyber resilience. Including it in performance reviews and setting clear expectations from the outset that good cyber hygiene practices are required as part of their job, and not just a compliance exercise, also helps get employees engaged in the program.
This approach is more likely to gain interest and better engagement from users, especially if the training is kept short, regular, and entertaining. With a multi-layered training approach, users are more likely to be engaged in training which would breed a culture of it becoming a norm to report suspicious emails within the workplace and to be more vigilant outside of it too, for example on social media and in their daily lives.