Published 01 May 2022

Abstract

Since the COVID-19 pandemic changed the world as we know it in early 2020, the topic of supply chains has become elevated. Supply chain issues have led to empty store shelves, component scarcity and global efforts to figure how to address the multiple layers of these shortages. While we won’t look to solve all supply chain issues here (we’ll save that for a later report), we’ll focus on two primary supply chain security areas in this report:

1. Access control for all participants across the supply chain lifecycle
2. Software supply chain models for everything in the CI/CD pipeline

Enterprises face major challenges in maintaining a comprehensive set of protection capabilities across a diverse supply chain environment. We’ll focus of developing a flexible and improved supply chain security posture through the combination of:

1. Access controls that are sufficiently granular and contextual in nature,
2. Access governance that ensures proper separation of duties (SoD), least privilege access and active monitoring/modulation,
3. Privileged access management (PAM) that extends into multi-cloud environments for securing administrative access to all supply chain applications and services including MFA, session management, credential security and application secrets management,
4. A security-centric CI/CD pipeline that incorporates all aspects of the cybersecurity policies across the Agile Development methodology, including code review, security testing and vulnerability management.

We’ll also include our Reference Architecture for protection of both supply chains within the enterprise, and share recommendations critical to creating a secure, sustainable and transparent supply chain environment.

 

Authors:

Doug Simmons Principal Consulting Analyst [email protected]

Gary Rowe CEO/ Principal Consulting Analyst [email protected]

 

Executive Summary

Since the COVID-19 pandemic was thrust upon the world in early 2020, the topic of supply chains has become a topic regularly in the news. There have been innumerable reports of supply chain issues that have dogged the global economy in ways that haven’t been seen in the modern era. These issues have led to empty store shelves, building supply shortages, high prices and debates about what to do about this.

The Oxford Dictionary defines a supply chain as “the sequence of processes involved in the production and distribution of a commodity”. In a simple world, we can picture a typical manufacturing plant ordering raw materials to build its widgets, and then shipping those much-sought-after widgets to various customer sites across directly or through distribution channels to the ultimate customers. On the front-end, there is the acquisition of the raw materials necessary for production – all of which exist within their own “supply chain bubble”.  This model also applies to software development which we will explore in greater detail throughout this report. From a cybersecurity perspective there are effectively two primary vectors of supply chain security that directly involve Information Technology (IT). They are:

1. Access control of the multiple stakeholders that interact with the supply chain IT environment during the cycle including ERP to order, manage and deliver goods and services.
2. Software supply chain models that identify everything that goes into the Continuous Integration/Continuous Delivery (CI/CD) pipeline. This refers to the internally developed source code, open-source libraries, pre-compiled binaries, 3^rd party code, and so forth.

Investigating these two supply chain vectors through the lens of cybersecurity yields a comprehensive set of protection capabilities designed to improve the supply chain security posture through the combination of:

• Access controls that are sufficiently granular and contextual in nature,
• Access governance that ensures proper separation of duties (SoD), least privilege access and active monitoring/modulation,
• Privileged access management (PAM) that extends into multi-cloud environments for securing administrative access to all supply chain applications and services including MFA, session management, credential security and application secrets management (e.g., rotation, storage and monitoring),
• A security-centric CI/CD pipeline that incorporates all aspects of the cybersecurity policies across the Agile Development methodology, including code review, security testing and vulnerability management.

These controls lend themselves to the establishment of a Zero Trust Architecture or at least moving towards this goal. Zero Trust requires the incorporation a wide range of cybersecurity capabilities – many of which are IAM centric, to be able to identify users and things, determine access privileges, identify and remediate vulnerabilities and monitor all activities. This needs to be persistently applied regardless of whether the participants in the supply chain are in-house or 3^rd parties. In your effort to improve software supply chain management, we further recommend:

1. Educate your organization on software supply chain security. Identify where security threats can enter your processes and tools.
2. Establish a working group to develop best practices and a plan for your organization to improve cybersecurity and in many cases your IAM capabilities.
3. Begin with the Software Bill-Of-Materials (SBOM) as a prerequisite for software supply chain security best practices. Require SBOMs in standard formats from your software vendors and produce SBOMs for the software you build.
4. Identify tools to generate, store, and manage SBOMs. Use SBOMs to identify vulnerabilities, including those that arise post-deployment.
5. Consciously embed cybersecurity at each step in your DevOps process. Implement continuous scanning and security checks in code repositories, CI/CD pipelines, container registries, staging environments, pre-deployment, and post-deployment.
6. Don’t limit your security checks to vulnerabilities. Use tools that have policies that can uncover secrets, malicious code, and other checks needed to meet your compliance requirements.

In this report, we will describe both supply chain cybersecurity and software supply chain security, provide a Reference Architecture for protection of both supply chains within the enterprise, and share recommendations critical to creating a secure, sustainable and transparent supply chain environment. In summary, IAM is the foundation of Zero Trust Architecture, and a Zero Trust Architecture is necessary to effectively secure your IT-centric supply chain.

The Supply Chain and Cybersecurity

Oxford Dictionary defines a supply chain as “the sequence of processes involved in the production and distribution of a commodity”. In a simple world, we can picture a typical manufacturing plant ordering raw materials to build its widgets, and then shipping those much-sought-after widgets to various customer sites across whatever region(s) they sell to. On the front-end, there is the acquisition of the raw materials necessary for production – all of which exist within their own “supply chain bubble”.

Supply chains are essential for the proper functioning of industrial systems and critical infrastructure. However, they’re also quite messy, in terms of security. Supply chains invariably connect users and systems from multiple entities, often in different countries. This setup exposes every company in the supply chain to cyber risk.

In my personal experience of working as a “planner” in a large manufacturing plant that required massive quantities and diverse types of raw materials to maintain the inventory for production runs, I can attest that supply chain order and delivery processes can be very complex. There is a very specific level of synchronicity involved in the procurement, storage and consumption of myriad materials in a constantly evolving manufacturing and shipping ecosystem. This complicated ecosystem has been turned on its head during the pandemic opening up opportunities for hackers to infiltrate at many levels.

Adding to this basic but still daunting set of processes is the fact that Information Technology (IT) plays a massive role in the entire functioning of almost all supply chains. The ordering processes, shipping and receiving, inventory control, manufacturing scheduling and much more are all conducted online. The web of third-party interfaces is increasingly complicated, with you (the planner) interfacing with multiple and varied supplier online systems to do your job, and with the third-party suppliers interfacing with your IT systems to update information necessary to support the manufacturing or distribution processes.

Within this arbitrarily simple example, it should be seen that there is real, inherent risk across supply chains as pertains to IT in general and Identity and Access Management (IAM) in particular.

But this isn’t the only area enterprise supply chains are in danger of attack. The software supply chain, which is the phrase used to characterize today’s Continuous Integration/Continuous Delivery (CI/CD) pipeline supporting agile development – is also at great risk. Within the pipeline, internally developed code, open-source libraries, binaries and so forth provide myriad opportunities for bad actors and careless developers to inflict significant damage to the software itself.

This topic has gained importance over the past few years on the heels of significant, highly visible and damaging code breaches that have affected millions of systems, such as the SolarWinds breach of 2020 that allowed Russian hackers to insert malicious code into the company’s IT resource management solution that was then distributed to tens of thousands of its enterprise customers. While certainly not an isolated means of attack, the depth and breadth of the damage caused by the code was enormous and brought further insight into the precariousness of the world’s ever-growing codebase. Such software supply chain attacks highlight the need for controls that can help validate the integrity of software and its components through the development, deployment, and adoption lifecycle.

While many organizations have been able to elevate their software supply chain with the help of software development methodologies like DevOps and through substantial automation of the software development life cycle (SDLC), securing the SDLC pipeline has sometimes (and increasingly during the pandemic) been an afterthought.

We’ll now investigate each of these two supply chain threats and recommended protection/risk mitigation approaches.

Physical Supply Chain Threat Landscape and Protections

As global supply chain issues rose to the forefront in 2021 – and continue today, a great deal of research has been conducted to determine what threats and associated risks exist within the modern supply chain landscape. Here, we are investigating various IT-related elements of the physical supply chain, where multiple online systems are used by people and things from many different internal and external (3^rd party) organization to fulfill ordering, supplying, shipping, and managing goods and services. At the top level, our research has identified three key physical supply chain security concerns we’ll summarized here:

1. Data protection:Business transactions generate and use data, which must be secured and controlled at rest, in motion and in use to prevent tampering or theft. To protect data, you have to know who (or what) can or cannot access the data, under what circumstances and from what locations, as well as any privacy considerations – to identify just a few of the contextual pieces of information necessary to appropriately protect data. To protect data, there must be appropriate governance processes in place to continuously monitor and adjust the level of protection and access controls across the workforce, business partners, suppliers and so forth.
2. Fraud prevention:Because the supply chains inherently contain multiple levels of interaction from multiple parties on an ongoing basis, the opportunity to insert a fraudulent transaction is pervasive. In a well-designed supply chain process, there are consistent audits at each step, to shrink (or virtually eliminate) the attack surface associated with the process.
3. Third-party risk: With most technologies today, there are myriad vendors and subcontractors providing small pieces of the whole “product”, which are assembled to create a laptop, table, mobile phone, automobile and so forth. In every case, each individual component brings a level of inherent risk to the end-product. If vulnerabilities exist within any of the subcomponents, the entire product is at risk. While a “trust but verify” approach to assembly is generally accepted, the emphasis on “verify” is usually not as strong as it could be.

TechVision’s Reference Architectures for IAM, Endpoint Security and Cybersecurity contain a comprehensive set of architecture patterns and best practices to guide enterprises in improving their access control capabilities across varied, multi-cloud and federated 3^rd party systems. Before we jump to that, however, let’s look at the other side of the supply chain security coin: software development.

Software Supply Chain Threat Landscape and Protections

This section focuses on the supply chain threats affecting the software development and delivery lifecycle cycle (i.e., SDLC). In this modern era, individual, related code libraries or microservices are typically ‘packaged’ using a container structure or an API gateway.  These containers become the glue across almost all application development, supporting the integration of cloud-native, mobile, enterprise, line of business and consumer applications. Done right, today’s Development teams support a well-managed Digital Enterprise and enables rapid delivery of scalable, integrated, flexible applications. Done right, secure SDLC allows your enterprise to offer internal and external developers, partners, suppliers, customers, in fact anyone in your “value chain” to have rapid and secure access to your digital capabilities.

What do we mean by “done right”? Well, in general a secure software supply chain should automatically enforce policy requirements for developer and administrator access control, testing, vulnerability detection and remediation and instrumentation. Thus, development and deployment become secure, repeatable, and reliable. Development teams can be confident that the software complies with quality and security requirements, such as not allowing code into production before it has been validated with static code analysis and security scanning tools.

In essence, however, the elephant in the room is that software supply chain cybersecurity begins and ends with Identity and Access Management. The TechVision team understands this as we have worked deeply within the IAM technical and architectural landscape for so many years; while this may appear as though we are hammers and everything is an IAM nail, IAM is so critical. As illustrated below, the weakest link in a less-than-secure SDLC processes is often directly related to IAM.

Figure 1: Typical Software Supply Chain Attack Vector (Source: Channel Futures)

You will eventually come to the realization – if you haven’t already, that the Bad Actor illustrated above is an “identity” with malicious intent that should have been prevented from entering the SDLC. Taking this one step further, Figure 2 below shows in more detail what the multiple vulnerabilities exist that are directly attributable to the “Developer/DevOps Admin”.

Figure 2: Typical Software Supply Chain Attack Vector (Source: CyberArk)

We can see how the software supply chain is ripe for compromise. Not surprisingly, the cybersecurity and software development communities have been working to bring these vulnerabilities to the forefront and attempting to address them through the promulgation of Zero Trust Architecture strategies. This applies throughout most government agencies, security standards bodies and generally regarded best practices including the US Government.

U.S. Executive Order on Cybersecurity 2021

To help drive this point home and provide definitive guidance on how to achieve improved software supply chain security, the U.S. Office of the President in May 2021 issued the U.S. Executive Order on Cybersecurity and the CISA Directive on Known Exploited Vulnerabilities[1].

While these both provide substantial insight and guidance for measurably improving the organizational cybersecurity posture, for the purposes of this research report, we’ll focus on specific elements that address the software supply chain. Notably, the Executive Order includes the establishment of the software bill-of-materials (SBOM), designed to provide visibility into software code and is a foundation for understanding software vulnerabilities and risks. Before diving into that, though, let’s look at some of the overarching tenets within the Directive:

Sec. 3.  Modernizing Federal Government Cybersecurity.

(a) To keep pace with today’s dynamic and increasingly sophisticated cyber threat environment, the Federal Government must take decisive steps to modernize its approach to cybersecurity, including by increasing the Federal Government’s visibility into threats, while protecting privacy and civil liberties.  The Federal Government must adopt security best practices; advance toward Zero Trust Architecture; accelerate movement to secure cloud services, including Software as a Service (SaaS), Infrastructure as a Service (IaaS), and Platform as a Service (PaaS); centralize and streamline access to cybersecurity data to drive analytics for identifying and managing cybersecurity risks; and invest in both technology and personnel to match these modernization goals.

And…

(ii)   develop a plan to implement Zero Trust Architecture, which shall incorporate, as appropriate, the migration steps that the National Institute of Standards and Technology (NIST) within the Department of Commerce has outlined in standards and guidance, describe any such steps that have already been completed, identify activities that will have the most immediate security impact, and include a schedule to implement them.

We can see that the U.S. Fed Gov stated direction is plainly on Zero Trust Architecture, which we know has become an aspirational (if not actionable) direction of many non-government organizations around the world. With this guidance, however, comes more focused insight on how to improve the cybersecurity of the software supply chain:

Sec. 4.  Enhancing Software Supply Chain Security.

 (a)  The security of software used by the Federal Government is vital to the Federal Government’s ability to perform its critical functions.  The development of commercial software often lacks transparency, sufficient focus on the ability of the software to resist attack, and adequate controls to prevent tampering by malicious actors.  There is a pressing need to implement more rigorous and predictable mechanisms for ensuring that products function securely, and as intended.  The security and integrity of “critical software” — software that performs functions critical to trust (such as affording or requiring elevated system privileges or direct access to networking and computing resources) — is a particular concern.  Accordingly, the Federal Government must take action to rapidly improve the security and integrity of the software supply chain, with a priority on addressing critical software.

Such guidance shall include standards, procedures, or criteria regarding:
(i)     secure software development environments, including such actions as:
(A)  using administratively separate build environments;
(B)  auditing trust relationships;
(C)  establishing multi-factor, risk-based authentication and conditional access across the enterprise;
(D)  documenting and minimizing dependencies on enterprise products that are part of the environments used to develop, build, and edit software;
(E)  employing encryption for data; and
(F)  monitoring operations and alerts and responding to attempted and actual cyber incidents;
(ii)    generating and, when requested by a purchaser, providing artifacts that demonstrate conformance to the processes set forth in subsection (e)(i) of this section;
(iii)   employing automated tools, or comparable processes, to maintain trusted source code supply chains, thereby ensuring the integrity of the code;
(iv)    employing automated tools, or comparable processes, that check for known and potential vulnerabilities and remediate them, which shall operate regularly, or at a minimum prior to product, version, or update release;
(v)     providing, when requested by a purchaser, artifacts of the execution of the tools and processes described in subsection (e)(iii) and (iv) of this section, and making publicly available summary information on completion of these actions, to include a summary description of the risks assessed and mitigated;
(vi)    maintaining accurate and up-to-date data, provenance (i.e., origin) of software code or components, and controls on internal and third-party software components, tools, and services present in software development processes, and performing audits and enforcement of these controls on a recurring basis;
(vii)   providing a purchaser a Software Bill of Materials (SBOM) for each product directly or by publishing it on a public website;
(viii)  participating in a vulnerability disclosure program that includes a reporting and disclosure process;
(ix)    attesting to conformity with secure software development practices; and
(x)     ensuring and attesting, to the extent practicable, to the integrity and provenance of open source software used within any portion of a product.

While this is a lot to digest within a summarization, we’ve italicized some of the recommendations that are more germane to this report, and in some cases very IAM-centric. Notably, the improvement of Privileged Access Management (PAM), effective deployment of multi-factor authentication (MFA), credential store security and conditional access controls are key areas enterprises should address. There is also a very important focus on endpoint management and security, specifically as it relates to Developer workstations.

Granted, these are technical positions we have been recommending to our own customers for several years. However, the recent widespread attacks such as SolarWinds, MIMECAST, HAFNIUM, as well as exploits of the recent Log4Shell vulnerability have made the risks associated with software supply chains top-of-mind. As a result, organizations (not just governmental agencies) are quickly mobilizing to understand and reduce software supply chain security risk.

And while open-source software risk might appropriately appear to be the top priority, it is closely followed by concerns about 3rd party libraries and commercial software as well as internally developed software. Thus, the entire software supply chain is at potentially grave risk.

In the following sections, we’ll identify how an IAM-focused Reference Architecture, once deployed can dramatically improve these two primary foci of supply chain cybersecurity.  As we describe in the TechVision report titled “IAM Reference Architecture”, we provide guidance for how to develop and use a Reference Architecture to:

• Organize business requirements
• Tie the requirements to capabilities
• Identify strengths and gaps
• Measure progress

In summary, Reference Architectures are standardized frameworks that provide a model for a domain, sector, or field of interest. Reference models or architectures provide a common vocabulary, reusable designs and industry best practices. They are not solution designs and as such are not meant to be implemented directly. Rather, they are used to guide more concrete efforts.

Typically, a Reference Architecture includes common architecture principles, patterns, building blocks and standards. Once a Reference Architecture that defines common architecture principles, patterns, building blocks and standards is developed, your organization can better evaluate vendor solutions and their ability to address the critical needs of your organization.

Much of the following is consistent with our IAM Reference Architecture we have published in several other reports and this is a good thing; consistency and careful management of your IAM foundation will support improved security, governance, management, audit, user experience and so many other areas across and outside of your enterprise. That said, there are specific areas we’ll call out that are unique to supply chain security.

Before we dig into the specifics of developing a Reference Architecture for supply chain cybersecurity, let’s quickly review the IAM-centric functional and technical landscape.

Reference Architecture Supporting Supply Chain Security

The TechVision Research Reference Architecture for IAM is a master template that identifies the IAM capabilities (rather than technologies) that can be improved or enabled, allowing business stakeholders and technical architects to achieve a common language for IAM functions, which can then be refined over time. ­­­This high-level template starts the journey.

Figure 3: IAM Reference Architecture master template

For a quick review, these IAM capabilities are described at the highest level as:

Interact: Interact is a layer of user interaction (UI) and application programming interfaces (API) that simplify consumer and application developer interaction with the rest of the IAM infrastructure. In this way, non-experts can follow the best practices of IAM without having to be experts in the field.

This allows the enterprise to:

• Incorporate new security capabilities without having to reengineer applications.
• Increase speed to market by removing security from the critical path of service development.
• Enhance security through the automatic adoption of best of breed security and privacy components.
• Decrease on-boarding friction by isolating complex security infrastructure through intuitive user interfaces.

Access: Access is the layer that answers the “Who has access to what?” question. It ensures customers can confidently exchange information and get the services they need to buy and use your products. It ensures employees and partners have all the digital resources they need to get the job done, nothing less and nothing more.

This allows the enterprise to:

• Ensure the right people have the right access to the right resources at the right time.
• Protect the assets of the company and its customers.
• Reduce productivity drains and costs caused when people can’t access the resources they need.

Change: Change manages the relationships between all the moving parts within the digital environment. Change establishes the connections between people, devices, applications, and data when they enter the environment, manages the connections while the relationship exists, and disconnects when access is no longer necessary.

This allows the enterprise to:

• Establish and maintain the proper rights, entitlements, and restrictions in order to reduce your attack surface, because Users and their identities are the most vulnerable link in a network.
• Orchestrate identity across device, network, and application boundaries because in the absence of the traditional security perimeter, identity is the common denominator across the entire digital environment.
• Prevent toxic combinations through transparency of entitlements across business processes.

Manage: Manage is where the administrators of the IAM platform upgrade, configure, tune, troubleshoot, document, and audit the platform and its components.

This allows the enterprise to:

• Incorporate new security capabilities without having to reengineer applications.
• Increase speed to market by removing security from the critical path of service development.
• Enhance security through the adoption of best of breed security and privacy components.
• Increase agility through isolating security software releases and patches to the underlying infrastructure components.

Measure: Measure is the lens into the digital environment. It allows live behavior observation, anomaly detection, platform health checks, and deeper analysis of usage and threats. It also provides the audit and reporting capabilities necessary to prove you are performing your duty to protect.

This allows the enterprise to:

• Understand behavior to improve the customer experience.
• Detect vulnerabilities before they are crises. The costs of prevention are much less than the costs of a breach.
• Prove compliance as required by law.

Store: Store is the shared place where the identity profiles, attributes, and relationships are kept and maintained. It may be physically centralized or distributed and contains the map which defines “who has access to what?”, often in the form of an entitlements catalog or database.

This allows the enterprise to support two important groups:

• For customers, it becomes the backbone for the entire customer experience; the customer data layer where all your interactions are captured.
• For employees, it becomes a user-centric view of entitlements across the entire digital environment.

The capabilities we describe above are present in all IAM systems (to varying degrees) and, in each of these areas, there are decisions to be made and many layers of supporting capabilities. The essence of the IAM Reference Architecture is to continue to build on and further refine the decisions that are being made. This is an important process because these decisions pertain directly to supply chain cybersecurity.

For example, in Time of Change operations there are capabilities associated with the management of entitlements such as periodic access reviews, access “recertifications”, separation of duties (SoD) analysis and management of entitlement catalogs. IAM also provides identity lifecycle management and identity orchestration capabilities that helps to better connect and normalize the overall set of identity services and sources of data. In essence, this is how an organization navigates towards Zero Trust which will ultimately support stronger supply chain security. In the next section, we’ll dive into the specific supply chain cybersecurity capabilities in more detail in order to help you understand exactly what you need, and why.

IAM Capabilities of the Supply Chain Functional and Technical Landscape

Now, let’s look at the next level of the architecture, which we subtly tailor to identify the functional capabilities that are the foundation for a best-in-class IAM Reference Architecture supporting supply chain cybersecurity. Each category is broken up into multiple capabilities at a level of greater detail. For example, interfaces can be for applications / developers (APIs, messaging services), lines of business/LOBs, self-service, or even robotic processes. This applies to each category and, based on stakeholder input, use cases and priorities can be further developed into Reference Architecture patterns or templates for specific services.

Remember, at this level the Reference Architecture is not focused on the actual implementation of things that carry out these controls. Rather it is a model of what the controls are, how they work, and how they interact to assure the utility of content.

It is important to understand that these functional capabilities consider all type of objects and use cases within the IAM foundation. As ultimately implemented, different enterprises enable different IAM capabilities in different ways to meet different protection needs. And they do so differently for different content and business functions because of the different risks and potential consequences associated with failures and costs associated with protection. And they do so with solutions that simultaneously run on-premises and in the cloud. One size does not fit all.

The next layer of the TechVision Research Reference Architecture for IAM (Figure 4) allows us to identify the IAM capabilities that are to be supported in the hybrid IAM infrastructure.

Figure 4: IAM Capabilities Within Reference Architecture

Again, it is important to acknowledge that the IAM Reference Architecture needs to reflect the business requirements associated with its supply chain (whether physical or software) – so the components and descriptions that follow are items we’ve seen within our clients but may not represent your specific situation. Use them to guide your thinking as you explore and build out your own IAM architecture for supply chain cybersecurity. Please note that these are short summaries of IAM capabilities that are described in more detail in several TechVision Research reports and, ultimately IAM needs to support and co-exist and work in harmony with other key cybersecurity and SDLC capabilities. Short descriptions of these capabilities are as follows:

Interact Layer Capabilities

1. Self-Service UI – an intuitive interface providing access to all the functionality required by end-users and administrators. The Self-Service UI is accessed by end users to administer some of their own user-specific attributes and preferences, and to request access. Administrators can use the UI to review and approve access requests and to set specific user settings as policy allows. From a supply chain standpoint, this is typically a very important capability to allow end users to request access to specific supply chain system or software development resources.
2. API – an Application Programming Interface is a set of routines, protocols, and tools for building software applications. An IAM API is used to embed specific IAM functions, such as register, login, etc. within applications in a consistent manner, and is used for programming graphical user interface (GUI) components that access IAM functions, including the Self-Service UI.
3. ETL – Extract/Transform/Load is a mechanism for batch file processing, such as when a number of users or things must be registered or deregistered with the IAM/IGA system. It typically refers to extracting data from a database, putting into a file format (e.g., csv) that can be read by the target system (IAM) and running the file in the IAM batch process. Often, this is the preliminary way the IAM entitlements catalog is initialized so that supply chain systems and development tools can be accessed.

Access Layer Capabilities

Adaptive Authentication

Adaptive / step up authentication – enables the enforcement of additional authentication steps based on risk factors associated with the resource the entity is attempting to access, which may include the entity’s current geo-location, device, sensitivity of the information being accessed, etc. As we have discussed previously, this area of discipline is exceedingly important to both system /application and software supply chain cybersecurity, and includes the following processing elements:

1. Multi Factor authentication (MFA) – requires end user or endpoint to provide 1. Something they know (e.g., PIN or password); 2. Something they have (e.g., registered mobile device); 3. And possibly something they are (e.g., fingerprint, voiceprint, iris scan…) when authenticating to applications, networks or services.
2. Password-less authentication – a form of authentication that replaces the password with a more secure and manageable alternative, such as multi-factor authentication, biometrics or secure verifiable claims within the decentralized identity model.
3. Biometrics – typically fingerprint, iris scan, facial recognition, voice recognition that can be used to better ensure the end users are who they claim to be.
4. Single Sign On – the ability to authenticate to multiple applications and systems with a single authentication event.
5. Remote Access Authentication – provides the ability to access a network, computer or device from any remote location, either using a Virtual Private Network (VPN) client or other VPN-less security protocols.
6. Password management – the ability to reset user passwords and change/update user passwords via self-service interfaces.
7. Access token management – access tokens are used in token-based authentication to allow an application to access specific APIs wrapped within the SDLC environment. The application receives an Access Token after a user successfully authenticates and authorizes access, then passes the Access Token as a credential when it calls the target API.
8. Access key management – involves the monitoring and recording of each key’s access, use and context.
9. Certificate management – the capability to manage digital certificates that can be propagated to devices, workstations, network devices and so forth. Includes ability to revoke certificates when necessary.
10. App secrets management – refers to the tools and methods for managing digital authentication credentials (i.e., “secrets”), including passwords, keys, APIs, and tokens for use in applications, services, privileged accounts and other sensitive parts of the IT ecosystem.

Adaptive Authorization

Adaptive authorization matches risk with request by evaluating additional environmental conditions, using risk score as a factor in dynamically determining authorization decisions. The following processing elements:

1. App Dashboard – the user interface that is similar to the ‘portal’ (i.e., logically centralized) method of providing the applications a user can access on a single screen.
2. Fine-grained authorization – enables object level Indeed, this is where the rubber meets the road in the Zero Trust sense. This capability often relies primarily on an attribute-based access control system (ABAC), also known as a policy-based access control (PBAC) system, where attributes associated with a user, action or resource are inputs into the decision of whether a given user may access a given resource in a particular way. Note that role-based access control (RBAC) can also be implemented as a specialization of ABAC. Fine-grained authorization systems typically involve a PEP and PDP. The PEP (Policy Enforcement Point intercepts a user’s, application’s, or device’s access request to a resource, makes a decision request to the PDP to obtain the access decision (i.e., access to the resource is approved or rejected), and acts on the received decision. The PDP (Policy Decision Point) therefore evaluates access requests against authorization policies before issuing access decisions. The PDP often interfaces with the entitlements catalog, sometimes referred to as the Policy Information Point (PIP) to access information about the user or device in question in order to inform its decision-making process.
3. Coarse-grained Authorization – only allows one level of access. This, too, is key to the IAM entitlements catalog, indicating what resources the end user (or thing) has broader access to in conjunction with fine-grained entitlements described above.
4. JIT (Just-In-Time) Access – the ability to grant privileged access on-demand, subject to policy and for a specific set of purposes and time period, using the entity’s enterprise ID. Often integrated with MFA to enforce stronger authentication for administrative tasks. The JIT Privileged Access Management (PAM) is a strategy that aligns real time requests for usage of privileged accounts directly with entitlements, workflow, and appropriate access policies. Companies use this strategy to secure privileged accounts from continuous, always-on access by enforcing restrictions based on behavioral and contextual parameters. Many organizations are currently in the process of integrating their PAM environments within their cybersecurity programs, resulting in a much more comprehensive view of what any end user has access to, whether a “super sysadmin” or just a plain old knowledge worker.
5. Remote Access Authorization – evaluates whether access should be granted over a remote network connection, such as via VPN.

Federation

Federation occurs when a proxy acts as a broker and authentication protocol translator for applications and other resources, enabling single sign-on (SSO) to applications across multiple internal and external domains. Federation is crucial to the system and software supply chain ecosystem as it enables many parties to securely collaborate within the supply chain environment. The following processing elements are involved in supporting these capabilities.

1. Federated SSO – established when a user is successfully authenticated to their domain / Identity Provider (IDP) and then is able to access applications in other domains by virtue of a header token that contains assertion information about the authenticated user, typically in the form of OpenID Connect (OIDC), OAuth 2 or Secure Assertion Markup Language (SAML) protocols.
2. Federated Cross-Domain Authorization – established with trust between multiple organizations (inter-organizational) to authorize each other’s users. Again, this is typically accomplished via federation protocols such as OIDC, OAuth2 or SAML. Note this approach can also be practiced inside an organization (intra-organizational) so that the user can access resources (different web properties and applications) within an organization. This method can be useful in very large, geographically dispersed organizations.

Privileged Access

As highlighted within the segment of the May 21 Cybersecurity Presidential Directive, controlling access to highly sensitive, privileged users (or things) is critical. Privileged Access Management is used to control access to privileged accounts by controlling the administrative session; facilitates session isolation, session recording and command filtering.The following process elements are included when PAM is required.

1. Session Management – privileged session management refers to the monitoring, recording and control over privileged sessions.
2. App Secrets Management – refers to the tools and methods for managing digital authentication credentials (secrets), including passwords, keys, APIs, and tokens for use in applications, services, privileged accounts and other sensitive parts of the IT ecosystem.
3. Password Vaulting – a password vault is a system that stores passwords for various privileged accounts in a privileged account management system. Passwords are ‘checked out’ at the start of a privileged administration session and not able to be shared among multiple administrators. When the privileged session is completed, the passwords are rotated within the vault so that the next time an administrator requests access, a different password is provided for the new session.

Change Layer Capabilities

Lifecycle Management

Identity Lifecycle Management is the process of managing identities through their lifecycle (i.e., Join, Move, Leave) and relationship with the organization. Often referred to as “provisioning”, this set of capabilities is critical to the IAM function because of the level and veracity of identity information it entails. These capabilities are central to all resultant access controls and privileges related to the supply chain. Key capabilities include:

1. Join, Move, Leave – events that indicate that a person (or thing) has joined the organization (Join) or changed jobs/functions/roles/locations, etc. (Move) or has left the organization (Leave). Such events can be detected on authoritative source systems such as HR, Contractor Management systems and so forth, and the events can trigger workflows, notifications, access right changes, entitlement updates, account disablement, and more depending on the rules associated with the IAM provisioning service listening for these events.
2. Identity Proofing – various forms of required proof that someone is who they say they are that are reviewed and verified before an account can be created/provisioned across the IAM-connected systems and applications.
3. Profile Management – the ability to manage one’s set of attributes associated with his/her/its digital identity.
4. Social Login – allows an end user to authenticate using their social media identification, such as Facebook or Google. Because social logins are often much less reliable (i.e., lack proper identity proofing), they are not recommended for authentication to any business-critical supply chain systems or software development environments.
5. Decentralized Identity – also known as Self-Sovereign Identity (SSI) represent Identity systems and services that are controlled, managed by the individual on a decentralized basis and generally built on blockchain/distributed ledgers. They often integrate a verifiable claims infrastructure to support the exchange of trusted credentials associated with the decentralized identifier. While this form of identification is still very much in its infancy, it bears watching because of the possible impact it could have on identity and credential proofing.
6. Federated Identity – authentication protocol for applications and other resources, enabling single sign-on (SSO) to applications across multiple internal and external domains.

Access Administration

Account administration contains the capabilities associated with creating, modifying and deleting/disabling computer/network/application user (or device) accounts. Again, these capabilities are critical to the entire supply chain cybersecurity function, resulting in updates to the entitlements catalog based on:

1. Access Request and Approval – workflows that facilitate any approval processes that may need to be enacted as part of an access request fulfillment. Access requests may be initiated through a self-service identity registration process, a delegated administrator request or an event trigger listening for changes on an authoritative source system such as HR. In most modern supply chains, this functionality includes 3^rd party access requests/approvals, and if not conducted properly, can leave gaping cybersecurity holes.
2. Access Provisioning – automates the steps required to set up the required accounts and entitlements and fulfill any required changes on one or more connected systems or applications, such as the ERP, supply chain management and software development lifecycle management platforms – again, including 3^rd party access provisioning.
3. Birthright Access – the set of entitlements someone (or something) can be granted immediately, without requiring workflows and approvals.
4. Time-bound Access – policy that grants access for a specific period.
5. Group Management – the ability to create and manage static and dynamic groups of accounts that are associated with runtime access control decisions.
6. Policy-based Access – using policies, based on a set of rules, to decide on authorization.
7. Self-Service Administration – the capability to manage one’s own profile or request access to specific resources, typically through the Self-Service UI.
8. Delegated Administration – the capability for an administrator to manage a user’s or thing’s profile, request access or based on policy, approve access. This is performed typically through a version of the Self-Service UI that is tailored to the administrator view.
9. RBAC, ABAC – Role Based Access Control (RBAC) associates one or more enterprise roles with an account, while Attribute Based Access Control (ABAC) associates one or more attributes within an account’s profile – in both cases this information is used during runtime authorization decisions.

Identity Governance and Administration

While this set of capabilities is specific to the IGA function, it should be clear to the reader that there is a good deal of reliance on several other IAM capabilities, as we have just described. In particular, IGA supports the following capabilities:

1. Access Review and Re-Certification – a process by which an organization reviews and verifies the appropriateness of access privileges.
2. Entitlement Catalog – a method for organizing and entitlement definitions and mappings, listing what is assignable, describing what these entitlements actually do; facilitates entitlement ownership and accountability.
3. Access Risk Management – the overall management of access risk and actions or permissions that, when available to a single user (or single role, profile, or HR Object), creates the potential for fraud or unintentional errors.
4. Predictive / Autonomous Governance – uses artificial intelligence (AI) and machine learning (ML) to recognize and act on access rights and entitlements in relation to policy.
5. Access Policy Violation and Remediation – like predictive/autonomous governance, acts on existingentitlements that appear to violate policy by fixing the issue without direct human interaction.
6. Segregation of Duties – an internal control to mitigate risk by having different individuals handle different tasks.
7. Closed-loop Remediation – direct revocation of roles/entitlements from the provisioning system.
8. Dormant Access Discovery and Suspension – uses a crawling mechanism to discover accounts and access privileges that have not been used in a specified period of time and based on policy, suspend the access privileges until further admin or user intervention.

Privileged Access Governance

1. Privilege Definition – the aspect of defining what systems require administrator access and what the specific privileges are, based on specific criteria regarding a number of variables, including who, what, when, where, and why.
2. JIT Privileged Access Granting – a least-privilege security model that requires users, processes, applications, and systems to have just enough rights and access—and for no longer than required—to perform a necessary action or task. Eliminating persistent privileged access for privileged user accounts—and activating it only for the duration it is needed to perform an activity is the objective of JIT PAM.
3. Privileged Access Discovery and Reduction – uses a crawling mechanism to discover admin accounts and access privileges that are in violation of policy and removes the access privileges until further intervention.

Identity Repositories Layer Capabilities

1. Directory Management – maintaining a persistent, scalable view of the common identity information that is easily referenceable from other components within the IAM architecture; manages the identity object and attribute stores (i.e., directories), manages the directory database schema and hierarchy. Whether housed in a relational database or a hierarchical LDAP directory, this is where the entitlements catalog typically resides.
2. Directory Virtualization – a method for instantiating identity correlation and aggregation in lieu of persistent data synchronization between source and target systems; is the cornerstone of an Identity Data Service.
3. Identity Correlation and Aggregation – the ability to automatically match and associate multiple identities across multiple, disparate, connected systems; allows for a single logical view of these associated identities spanning all connected systems.
4. Identity Profile Propagation – maintaining a persistent, scalable view of the common identity information; easily referenceable from other components within the IAM architecture.
5. Identity Data Customized View – the ability to control or limit what a user or application sees when querying the IAM directory infrastructure; may also support data transformation to tailor the view to the specific application’s requirements.
6. Authoritative Identity Data Source Enrichment – refers to a bi-directional data integration mechanism that allows certain IAM attributes to be identified as the authoritative source for the data, that can then be synchronized back to the original authoritative source database.

Identity Analytics Layer Capabilities

Many of the identity analytics capabilities described below support the supply chain cybersecurity functions via integration with the entitlements catalog:

1. Access Monitoring and Reporting – on-going surveillance and reporting to ensure that inappropriate access is not occurring and that the results are logged.
2. Access Policy Analysis and Recommendations – reviewing, analyzing and making recommendations with respect to access policies.
3. Trust Scoring – a trust engine establishes a trust score for an actor (e.g., user, device) based on many factors. An example might include having a user or devices trust score adjusted negatively because the actor is exhibiting behaviors that are well outside of an established baseline.
4. Risk Scoring – dynamically evaluates risk of a given operation based on current environmental factors and filters access to operations if the risk level exceeds the accepted threshold. The risk engine incorporates elements of the risk management framework and threat intelligence to calculate a risk score for each asset on the network. Factors that are taken into account include data classification, vulnerabilities found, and the controls that are applied to an asset. Together an actor’s trust and risk score determine if the authorization request is within defined tolerances for the organization. The policy repository is where baseline policies are managed and stored. The policy repository can also serve as a historical record of baseline policy changes and the policy changes made for each entity.
5. User Entity Behavior Analysis – (UEBA) uses machine learning and deep learning to learn how users and other entities on the corporate network typically behave, detect abnormal behavior, outlier access attempts (e.g., outside the ‘norm’) and figure out if this behavior has security implications. This information is fed in real-time to the PDP to provide relevant information to the runtime access decision. The goal is to identify abnormal behavior, determine if it has security implications, and alert security teams.
6. Insider Threat Access Detection and Remediation – reviews access entitlements in concert with segregation of duties (SoD) requirements to uncover SoD violations and recommend remediation via workflow or autonomously remediate. It focuses on perpetual analysis of the organizational entities’ access permissions in concert with the lifecycle of the entitlement assignments and policy definitions. This process will also help reduce the attack surface by removing unused entitlements from entities’ profiles; and can assist in identifying entity logins that do not have an entitlement to go further into the application. This will provide more access granularity to prevent entities from being able to view anything that doesn’t pertain specifically to their current assigned entitlements – which is key from the security and compliance perspective.
7. Approval Review and Recommendations – reviews workflow approvals for access requests – whether initiated by self, administrator or authoritative source system and evaluates risk of approval in conjunction with SoD policy. If deemed risky, recommends alternatives to Approver and application owner.
8. Access Recommendations – a method of governance decision making that leverages AI, ML and predictive data to make recommendations regarding appropriate access for a specific user, device, role, etc. – typically during runtime.
9. App Access Trend Analysis – monitors the access privileges being granted to users and devices, based on specific criteria, and provides trend reports to help with IAM access policy refinement.
10. IAM QoS Trend Analysis – measures the Quality of Service being provided by the entire IAM system to determine how well IAM meets Key Performance Indicators (KPIs).

Manage Layer Capabilities

The supply chain system and development environment provisioning capabilities rely extensively on the fine-tuned underlying IAM infrastructure in order to enable:

1. Configuration Management – the ability to record changes to the configuration of your Identity and Access Management (IAM) users, groups, and roles (collectively referred to as IAM entities) and the policies associated with them.
2. Process Optimization – the configuration of processes such as workflows and data integration flows, which are key to the IGA function.
3. Access Policy Management – the configuration of access policies.
4. App Onboarding Self-Service – the mechanism that app owners can make available / publish their IAM-enabled applications.
5. Data Governance – pertains to how long to archive IAM log data in support of regulatory, legal and privacy compliance, legal.
6. Monitoring and Reporting – the ability to monitor all aspects of the IAM system and report on performance.
7. Auditing and Logging – the ability to log specific activities, such as login, access requests, approvals and so forth in support of audits.
8. Archiving / Purging – the mechanism used to save (archive) specific identity data and IAM activities for a specific period of time, and the subsequent ability to permanently delete such information – usually in accordance with data governance and privacy regulations.
9. Disaster Recovery – the configuration of key IAM/IGA subsystems to enable operability in the case of a disaster.

With this information, technical architects can rapidly zero-in on the current options (technology and process) their IAM architecture should encompass to achieve the required capabilities securing the system and software development supply chains. In the form of architecture considerations, each of the options available is then described in more detail to help identify the right approach for an optimal IAM architecture and deployment strategy. In the subsequent section, we’ll look at sample IAM Reference Architecture patterns that relate to supply chain cybersecurity. Note that these typically incorporate both on-prem and in-cloud services and capabilities.

Sample Supply Chain Security Reference Architecture Patterns

With this comprehensive understanding of the overall IAM Reference Architecture, we now look at some examples where our customers have deployed various AM services and capabilities in the cloud using solutions offered by some key IAM vendors.

Supply Chain Security Service Pattern

Typically, end users, devices/things, application service accounts and network services all need to be provisioned – so they can be authenticated and authorized to perform functions enabled by IT. Supply chain systems and development environments require discrete capabilities within the IAM infrastructure that will facilitate a low friction but appropriately secure experience.

In the template below, we’ve illustrated the IAM capabilities required for a hypothetical physical Supply Chain Application Service – such as an ERP inventory control system interacted with by 3^rd parties and enterprise staff. Note that we have removed all other IAM capabilities that are not directly supporting the Supply Chain Application Service.

At this point, we are not focused on whether each capability is enabled via on-prem or in-cloud services. That will come later.

Figure 5: Sample IGA Service Capabilities Map Supporting Supply Chain Systems

The IAM capabilities necessary to support the Supply Chain Application Service have been color-coded as follows:

• Rose – requires significant investment over next 2 years. The hypothetical enterprise currently does not support these IAM capabilities.
• Orange – requires investment over next 2 years. The enterprise either currently does not support these IAM capabilities or they may require additional investment and deployment to achieve a requisite level of functionality.
• Grey – indicates capabilities that the enterprise IAM has in place in some capacity, although it could be likely that some augmentation may be required to improve functionality and ubiquity to fully meet its requirements.

 

Generically, the IAM capabilities are used as input to the development of the Reference Architecture pattern illustrated below.

Figure 6: Typical IAM Service Pattern Supporting Supply Chain Applications

The “big, yellow arrow” points to the brains of the IAM environment, which we described previously. Continue to note, however, that much of the overall IAM infrastructure supports or consumes the IAM processing output. For example, the “login service” in the upper left corner relies on the IAM policies, birthright access provisioning, privileged access management, workflow and approvals and so on to be able to function appropriately and securely through the “App Dashboard” (PEP) – which interacts during runtime with the access policy repository (PDP), the enterprise Directory and the entitlements catalog. Remember, the Supply Chain Application Service is reliant on all of these capabilities.

Software Supply Chain Reference Architecture

The rise of application programming interfaces (APIs) and their usage across the business landscape had been accelerated over the last decade as cloud-based deployments, mobile applications, microservices and easier consumption of external services have become more standard – usually growing alongside migrations to the digital enterprise and hybrid IT architectures. APIs are certainly not new to most software developers, being the way in which most capabilities within systems are accessed. With the global pandemic shifting typical workforce and customer interactions to almost 100% online, APIs are increasingly used to access data or business functions directly from applications used across the business. The rate at which this is occurring means that software supply chain security needs to be an ongoing effort on behalf of your organization.

TechVision has produced detailed reports on SDLC, API management, microservices and DevOps, including “State of Application Programming Interfaces (API) Management and Security”, “How Microservices Can Improve Your IAM Strategy”, “A Practical Guide to DevOps”, “Microservices Enterprise Level-Set” and many more. In essence, we report that the rapid rise of cloud architectures supporting the Digital Enterprise has had a profound impact on most organizations’ development strategy, security posture and operations focus – increasingly encapsulated under the banner of DevSecOps – short for Development, Security and Operations.

These distributed architectures and the dispersion of security and logical control and monitoring points can create unpredictable dynamics and unanticipated points of failure. This can be a challenge for organizations operating primarily in a command-and-control manner, and even still dealing with the implications of DevOps itself. Simply, these new points of access, controls, real-time metrics, and rapid feedback loops are just a few of the requirements security teams face in cloud-native and hybrid environments.

Product, Service and Capability Patterns

As TechVision Research has been emphasizing for the past several years, a combination of loose-coupling, virtualization and federation are not only critical elements in ‘the future of identity management’ – but also for enterprise IT as a whole.  APIs are what enable access to code libraries, open-source routines, microservices and myriad other callable procedures via an ‘abstraction layer’ that can dramatically simplify application development, integration and operational support. In this model, IT services and functions that are enabled in a secure, easy-to-consume manner.

But how does an organization enable business with a cavalcade of API-enabled services, routines, and libraries? That is something that takes a bit of structure regarding how actual business-supporting products can be created in such a way as to fully leverage an Agile Development ecosystem while not sacrificing cybersecurity. This becomes even more challenging when we consider that many business applications are developed via software supply chains that are accessible to multiple 3^rd parties who participate in the distributed, Agile Development processes.

To secure the software supply chain then, requires that a host of both independent and integrated cybersecurity capabilities be carefully inserted into the complete of development processes. As an example, the enterprise’s Information Security group can develop and maintain Products that insert identity and access management, threat and vulnerability management, application security, and so forth directly into the Agile Development process.

When developing their applications, the business units incorporate aspects of such “group supported cybersecurity Products” into their own business critical Products. This approach will reflect a more general building-block CI/CD strategy to development that facilitates Agile principals and bakes cybersecurity right into the entire process.

Below is an example of a hypothetical organization’s Information Security Product, Service and Capability portfolio.

Figure 6: Sample Information Security Capabilities Supporting Agile Development

As illustrated above, within Products are specific cybersecurity Services that are used by the business units Developers to create the desired applications, or Products. From an Information Security perspective, the Services they include within their applications are enterprise standard security routines for user authentication, authorization, boundary defense, malware detection, etc. This will preclude the need for multiple, ineffective, uncoordinated, or even rogue security routines that create significant vulnerabilities.

Once the Services are identified that will comprise the Products, the granularity increases in the establishment of specific Capabilities necessary to support each Service. In essence, Capabilities are the lowest kernel of functionality that is to be provided by Services, to support Products. From an Information Security viewpoint, Capabilities might include multi-factor authentication (MFA), single sign-on (SSO) and user self-service credential management within the Authentication Service, within the Identity and Access Management Product.

From this level of detail, the serious work of identifying APIs that will be enabled and secured across the enterprise Application Development ecosystem so that Capabilities can be embedded within Services, which can then be embedded within Products, which may then be embedded within business unit Products. Typically, this exercise requires the enterprise to take stock of their existing capabilities across the Information Security spectrum to determine whether the capabilities are mature enough – or even exist, so that the creation of Services and Products can commence. A sample of this type of exercise is illustrated below in Figure 7.

Figure 7: Sample Information Security Capabilities Maturity

• Rose– requires significant investment over next 2 years. The hypothetical enterprise currently does not support these cybersecurity capabilities.
• Orange– requires investment over next 2 years. The enterprise either currently does not support these cybersecurity capabilities or they may require additional investment and deployment to achieve a requisite level of functionality.
• Green– indicates cybersecurity capabilities that the enterprise has in place in some capacity, although it could be likely that some augmentation may be required to improve functionality and ubiquity to fully meet its requirements

This exercise is extremely important because it quickly tells you where you need to invest resources to bring the level of Capabilities up to where they can be incorporated into robust Services.

Following a model similar to this, an enterprise can better secure the software supply chain because the cybersecurity capabilities are well-defined, accessible and auditable.

Put Them Together

And what do you get? A comprehensive set of cybersecurity capabilities that are rooted in Zero Trust Architecture and improve the security posture of your IT-related supply chain through the combination of:

• Access controls that are sufficiently granular and contextual in nature,
• Access governance that ensures proper separation of duties (SoD), least privilege access and active monitoring/modulation,
• Privileged access management (PAM) that extends into multi-cloud environments for securing administrative access to all supply chain applications and services including MFA, session management, credential security and application secrets management (e.g., rotation, storage and monitoring),
• A security-centric CI/CD pipeline that incorporates all aspects of the cybersecurity policies across the Agile Development methodology, including code review, security testing and vulnerability management.

In summary, Zero Trust requires the incorporation of all of these cybersecurity capabilities – many of which are IAM centric, to be able to identify users and things, determine access privileges, and monitor all activities. This regardless of whether the supply chain participants are in-house or 3^rd parties. In your effort to improve software supply chainmanagement, we further recommend:

1. Educate your organization on software supply chain security. Identify where security threats can enter your processes and tools.
2. Establish a working group to develop best practices and a plan for your organization to improve cybersecurity and in many cases your IAM capabilities.
3. Begin with the software bill-of-materials as a prerequisite for software supply chain security best practices. Require SBOMs in standard formats from your software vendors and produce SBOMs for the software you build.
4. Identify tools to generate, store, and manage SBOMs. Use SBOMs to identify vulnerabilities, including those that arise post-deployment. Open-source tools such as Syft are a great starting point to give you visibility into the software containers you use.
5. Consciously embed cybersecurity at each step in your DevOps process. Implement continuous scanning and security checks in code repositories, CI/CD pipelines, container registries, staging environments, pre-deployment, and post-deployment.
6. Don’t limit your security checks to vulnerabilities. Use tools that have policies that can uncover secrets, malicious code, and other checks needed to meet your compliance requirements.

Summary

We hope you have found this report useful as the Supply Chain is being elevated significantly in discussions enterprises are having about their information security postures. Even though discussion about Supply Chains can mean different things to different people, it is important to establish a common vernacular for IT-centric aspects of modern supply chains.

In that light, thinking in terms of physical supply chains managed by distributed IT environments on one end of the spectrum, and software supply chains managed by Agile Development teams on the other end should help you identify the specific capabilities needed to better secure your supply chain.

Our examples of Reference Architecture coupled with the detailed capabilities matrices that support the architecture should help. Within this aspect of the discussion, we have shared with you the complete set of capabilities and services you need to consider within your own organization. We have found over the years that having “templates” to help identify and evaluate your own enterprise’s journey is immeasurably valuable. Such templates imply “good practices” and shine light on the areas that need attention.

In summary, we leave you with this food for thought:

IAM is the foundation of Zero Trust Architecture, and a Zero Trust Architecture is necessary to effectively secure your IT-centric supply chain.

About TechVision

World-class research requires world-class consulting analysts, and our team is just that. Gaining value from research also means having access to research. All TechVision Research licenses are enterprise licenses; this means everyone that needs access to content can have access to content. We know major technology initiatives involve many different skillsets across an organization and limiting content to a few can compromise the effectiveness of the team and the success of the initiative. Our research leverages our team’s in-depth knowledge as well as their real-world consulting experience. We combine great analyst skills with real world client experiences to provide a deep and balanced perspective.

TechVision Consulting builds off our research with specific projects to help organizations better understand, architect, select, build, and deploy infrastructure technologies. Our well-rounded experience and strong analytical skills help us separate the “hype” from the reality. This provides organizations with a deeper understanding of the full scope of vendor capabilities, product life cycles, and a basis for making more informed decisions. We also support vendors in areas such as product and strategy reviews and assessments, requirement analysis, target market assessment, technology trend analysis, go-to-market plan assessment, and gap analysis.

TechVision Updates will provide regular updates on the latest developments with respect to the issues addressed in this report.

About the Authors

Gary Rowe is a seasoned technology analyst, consultant, advisor, executive and entrepreneur. Mr. Rowe helped architect, build and sell two companies and has been on the forefront the standardization and business application of core infrastructure technologies over the past 35 years. Core areas of focus include:

Identity and Access Management, business/technology trends, cloud computing, security/risk management, privacy, innovation, AI, new IT/business models and organizational strategies.

Prior to starting TechVision Research he was President of Burton Group from 1999 to 2010, the leading technologyinfrastructure research and consulting firm. Mr. Rowe grew Burton to over $30+ million in revenue on a self-funded basis, sold Burton to Gartner in 2010 and supported the acquisition as Burton President (now Gartner for Technical Professionals) at Gartner.

Doug Simmons brings more than 25 years of experience in IT security, risk management and identity and access management (IAM). He focuses on IT security, risk management and IAM. Doug holds a double major in Computer Science and Business Administration.

While leading consulting at Burton Group for 10 years and security, and leading global identity management/security consulting at Gartner for 5 years, Doug has performed hundreds of engagements for large enterprise clients in multiple vertical industries including financial services, health care, higher education, federal and state government, manufacturing, aerospace, energy, utilities and critical infrastructure.

[1] https://www.whitehouse.gov/briefing-room/presidential-actions/2021/05/12/executive-order-on-improving-the-nations-cybersecurity/