Supply Chain Security

The trend for leveraging weaknesses within the supply chain to attack the better protected, more lucrative targets further up the chain shows no sign of diminishing. Recent research by ENISA expects a four-fold increase in supply chain attacks compared with last year.

The rise of supply chain attacks is down to the increased interdependencies and complexities of digitised supply processes that necessitate linking systems to implement the end to end supply chain forecasting, planning, ordering and shipping needed for minimum cost just in time supply processes. Integration between systems is a logical conclusion to the adoption of Industry 4.0, predicated on data sharing for business processes.

If anything, the sophistication of attacks is growing, and the willingness of attackers to devote time and resources carefully infiltrating supply chains and moving across boundaries is increasing. Indeed, the scope of organisations affected by the SolarWinds incident demonstrates how patience and persistence can deliver impressive results for well-resourced and sophisticated attackers.

Supply Chain Interdependencies

The most commonly employed attack vector injects malware into a targeted supplier for lateral movement through trusted relationships with business partners. The latest trend is attacking suppliers of software-based services, targeting their code-based products to propagate malware. The commonly held attitude of installing and utilising third-party software products without validating the integrity of the code to ensure it is not compromised, manipulated or otherwise tampered with has facilitated this approach. The issue is that this is not a simple process.

Studies of the SolarWinds attack methodology by the Linux Foundation highlighted the challenges. The infected software was delivered as an official software update, digitally signed by the supplier. In the initial attack phases, the software exhibited no unexpected behaviour. Even if the source code were available for audit, detection of compromised functions was unlikely. Traditional advice for preventing compromised software from passing up the supply chain would not have worked, so we need a completely different approach.

Protecting your supply chain with a software bill of materials

In order to prevent supply chain attacks, organizations should look at software bill of materials (SBOM). SBOM’s are a written record of the key components of a software product, an open source and proprietary code provided to anyone building software, buying or operating software. 

Modern-day software solutions have a rapidly growing dependency on open source software (OSS). You can’t comply with an open-source component license unless you know what components exist. In your software supply chain, knowing what’s in your code will help minimize the risk.

Mitigating risk around your use of open source software encourages customer trust in the safety and compliance of your product, while simultaneously contributing to your value proposition.

Creating the concept, implementing data standards and best practices for SBOM can be a challenge but these hurdles can be overcome when network systems from all different vendors operate together in a coordinated way.

Zero Trust Philosophy

White House recently announced an intention to migrate critical government systems over towards a Zero Trust Architecture. This will help combat increasingly advanced and persistent security threats. This move from simply bolstering existing security controls to adopting a zero-trust philosophy is a step change in protective measures.

The zero trust philosophy is a significant shift in approach when it comes to implementing and managing security controls. It goes beyond a simple change to network design to a fundamental rethinking of how to implement security.

Traditional network architecture imposes security controls at the external boundaries and between segregated systems. Their purpose is to block unauthorised access attempts to penetrate the perimeter. However, security moves from active preventative controls to more passive monitoring for erroneous behaviour once authenticated and inside the boundary. As a result, any malicious process that crosses the border can search out and exploit further weaknesses to escalated privileges while hiding its presence.

The principle of a Zero Trust Architecture is there is no automatic assumption of authenticated trust anywhere in the network. Instead, all processes are assumed suspect until they prove themselves to be legitimate. The basis of proof is a set of rules that consider the nature of the process, its history of behaviour, and relevant intelligence. This complex trust algorithm has intelligence, and it adapts to current situations and changes. A trusted process can lose that trust and further access if it violates a rule. This ensures that even once inside the system, it is a challenge for attackers to access critical systems.

Implementing Zero Trust

Zero Trust Policies

Implementing a zero trust architecture first requires developing an enterprise-wide security plan that establishes the operational policies for all parties that form the supply chain. Defining who can access specific services and data under particular circumstances is critical to determining effective policies.

Policies govern the flow of information across the chain. Here, information can be any digital commodity shared between parties-application software, data relating to orders, financial transactions, product specifications, and intellectual property.

Robust authentication techniques and a complete and comprehensive ruleset with no errors, omissions, contradictions or inconsistencies predicate the effectiveness.

Zero Trust Rulesets

Establishing trust comes from building confidence a process behaviour, be that a system service or an authenticated user. Monitoring and inspecting transactions allow the system to build up a picture of the trustworthiness of each operation. In addition, threat intelligence can help highlight known attack vectors that masquerade as legitimate processes to focus monitoring.

Data transmission requires securing across the entire supply chain, with the elimination of all weak points. The issue with traditional security methodologies is that securing end to end transmission is dependant on all participants in the chain implementing and maintaining adequate security controls. This dependency is critically important for all participants but outside their power to ensure appropriate rules.

Traditionally organisations have a contractual right to audit supplier’s security. They can demand certification to appropriate standards, but these measures do not guarantee security. A move to zero trust takes away this dependency and the burden of monitoring supplier controls. Furthermore, any supply with insecure systems will find that they cannot collaborate within the zero trust systems, their actions blocked.

Establishing trust is on a case-by-case basis for every interaction across the entire network. Boundary protections such as firewalls will still exist in the network architecture, there is significantly less reliance on their effectiveness. Instead, the focus is on continuous monitoring of processes and the actions taken to detect potential security issues, ranging from suspect activities, unintended user actions or operational health problems.

Zero Trust Tenets

The fundamental tenets of a zero trust supply chain are:

• All participants in the chain are treated equally and subject to the same controls, irrespective of size, standing or relationship.
• All information flows, data, code, materials, financial transactions are equally subject to zero trust controls regardless of where they originate and terminate. Likewise, internal data flow and data coming to or from third-party sources have the same treatment.
• Access requests to processes or data are approved on a per-session basis. This is regardless of whether they originate from internal or external users or services. They do not automatically imply trust to separate related access requests.
• Access requests must meet criteria set by rulesets before authentication and authorisation is applied. Access is denied by default and granted only when they meet strict standards.
• Access request approvals follow rulesets that dynamically adjust to monitored behavioural attributes and observable states of the supply chain, cognizant of threat intelligence information.
• Rulesets enforce the principles of least privileges and the highest security state for processes. Active monitoring is used to maintain this state.
• Comprehensive monitoring and logging are necessary to record the secure state of all users and services. This establishishes behavioural history and trends, feeding results back into the dynamic rulesets.

System Migration

The key to implementing zero trust architecture is remembering that it is a philosophy rather than a technology. Existing architectures provide a starting point for transition, but not all processes can adapt to a zero trust philosophy. The migration process will vary by business but may require revolution rather than evolution to effect.

The starting point is integrating zero trust into future planning processes and decisions to achieve the final solution. It may be possible for to migrate individual processes on an opportunity basis to implement an interim hybrid solution where existing enterprise-wide perimeter security controls are supplemented with zero-trust processes for specific data flows. Once all functions have moved to a zero-trust philosophy, the historic controls can be reviewed and removed where necessary.

Conclusions

Zero Trust Architecture is the assumption you can trust no one in the supply chain. Therefore, you should deny access to every user and device until proven trustworthy. Access to services are data limited to the minimum necessary.

For global businesses, the integration and digitisation of the supply chain bring positive competitive advantages at the expense of exposure to risks directly due to security vulnerabilities in third-party supply chain members that are outside of their control. Zero trust architectures offer a solution that resolves the adverse effects by eliminating dependencies on third-party security while providing a step-change improvement to their internal security in the face of ever more capable and sophisticated security attacks.

The question should not be if a business should move to a zero trust architecture but when will they complete the migration.

Smarttech247