An organization’s products and services are diverse and complex. By establishing a software supply chain asset register, you can have a clear understanding of the supply chain relationships within your organization. The organization needs to create a comprehensive inventory of suppliers, software, tools, services, and upstream and downstream delivery processes to ensure that there are no omissions in the supply chain process.

Supplier Inventory

Scope: Mainly focus on direct suppliers to the organization. The decision not to inventory indirect supply chain suppliers is made considering that managing multiple levels of the supply chain could increase management costs and process complexity. From the perspective of the end customers, the organization’s direct suppliers bear the primary responsibility.

Inventory Methods: Questionnaires and interviews.

Inventory Content and Results: Suppliers are typically categorized as product suppliers, system integrators, service providers, including design firms, developers, contractors, network security product providers, information technology product providers, maintenance providers, security service providers, information security assessment providers, and other participants, etc. An inventory of suppliers is created, including information such as the company name, location, specific address, and other details, to have an overview of the organization’s suppliers.

Supply Chain Product and Service Inventory

Scope: Mainly inventory software and hardware products and services. Inventory Methods: Questionnaires and interviews.

Inventory Content and Results: This includes office automation (OA) platforms, email systems, network monitoring software, cloud storage or FTP for file sharing platforms, source code repositories, VPN products, industry-specific software, network equipment, security equipment, servers, mobile devices, and more. The inventory also captures essential information about important supply chain products, such as versions, models, manufacturers, development types, the involved operating systems, and whether there is information sent back to the manufacturer, along with the main content of that information. This creates a supply chain product inventory.

Supply Chain Asset Register Management and Visualization

The inventory of supply chain companies and supply chain products needs to be managed through a supply chain asset register platform. By establishing a supply chain asset management mechanism, such as management processes or automated technology (e.g., SCA products), this information can be continuously updated. The asset register can be used in conjunction with open-source software security risk detection and other security monitoring mechanisms to identify supply chain risks promptly. For organizations with strong software management capabilities, an asset register risk management platform can be established to evaluate risks from multiple dimensions and provide visualization capabilities, assisting software organizations in developing vulnerability alert and response plans. Additionally, with the support of a knowledge graph-based recommendation service, repair solutions or remedies can be provided for enterprise security personnel to reference and create internal security response plans.

Asset Register Management Platform for Enterprises

In the software supply chain, for cost considerations, open-source software or open-source components are often used in projects or undergo secondary development, and there are numerous service providers with varying experience and service quality. Therefore, evaluating open-source software and its service providers is an important way to ensure the security of various supply chain stages.

Open Source Software Evaluation

Scope: Applicable to the evaluation of open-source software and related open-source technologies, software, and products. It provides a reference for the quality and maturity of open-source software and helps with technical roadmapping and software selection.

Evaluation Content: The evaluation model consists of three levels: primary assessment attributes, secondary assessment attributes, and evaluation indicators. There are a total of 12 primary assessment attributes, 42 secondary assessment attributes, and 129 evaluation indicators.  It includes attributes such as open-source licenses, industry recognition, product vitality, service delivery, security, compatibility, maintainability, extensibility, functionality, reliability, usability, and performance efficiency, among others.

Based on the graded definition and graded calculation of the assessment attributes and evaluation indicators, each level has a corresponding weight system, and the quantitative score of open-source software is calculated from bottom to top.

Service Provider Evaluation

Scope: Evaluation of direct service providers for open-source software, including entire organizational entities or specific departments in specific open-source technology areas.

Evaluation Content: The evaluation model includes primary assessment attributes, secondary assessment attributes, and evaluation indicators. There are 8 primary assessment attributes, 20 secondary assessment attributes, and 118 evaluation indicators, encompassing attributes like industry experience, technical capabilities, service quality, open-source experience, enterprise qualifications, service delivery, operational support, and security guarantees, among others.

The software service provider evaluation model involves two types of evaluation indicators: qualitative evaluation and quantitative evaluation. The evaluation of service providers is conducted using an expert scoring method. First, scoring criteria are established based on the evaluation indicators of service providers. Then, a number of representative experts are hired to provide scores for each indicator based on their experience according to these scoring criteria. Finally, the indicator scores and the overall score of the service provider are calculated by aggregating the scores.

Penetration Testing

Penetration testing involves highly skilled and qualified security professionals simulating attacks on a specific network or system from different positions (e.g., internal or external) using various methods, similar to common hacker attack methods, to test and discover security vulnerabilities in a product. The goal of penetration testing services is to fully uncover and expose a system’s weaknesses, allowing management to understand the threats their systems face.

Penetration testing is a valuable supplement to vulnerability assessment. Additionally, due to the wealth of security experience and skills possessed by penetration testing personnel, their targeting and granularity in exposing threats are more precise than standard vulnerability assessments. Furthermore, the attack paths and methods used in penetration testing differ from common security products, allowing them to reveal previously unnoticed threat paths, exposing threats within the entire system or network. Importantly, the success of penetration testing is not typically due to a single issue in a single system but rather the combination of seemingly unrelated and seemingly insignificant defects. In everyday work, no manager without relevant experience and skills can arrange these defects in such a way as to trigger problems. However, penetration testing personnel at Chaitin Technology can connect these defects and display them through their rich experience and skills.

Component Vulnerability Analysis

Software composition is typically referred to as BOM (software bill of materials). Using software composition analysis (SCA) tools, a BOM list can be generated, providing detailed information about component versions and licensing, among other things. Maintaining an accurate software BOM can help companies quickly identify components susceptible to attacks.

• Typical component risks include:
• Components with known vulnerabilities;
• Components with high-risk vulnerabilities;
• Outdated components that have not been maintained for years, potentially harboring unknown risks.

To perform an analysis of open-source software components, follow these steps:

• Use SCA tools and techniques to create a BOM list of open-source software;
• Pay attention to components in the BOM list, especially those with medium to high-risk vulnerabilities, and consider upgrading or fixing them.
• Regularly update components and vulnerability databases and address newly discovered and exposed vulnerabilities promptly.

Code Auditing

Code security auditing, specifically referring to static analysis (white-box security testing) performed in static application security testing (SAST), is primarily used to identify coding defects in non-running (static) code. Static testing includes detecting code defects and evaluating code quality.

Static risks in code include:

• Developers facing pressure to deliver code under AST testing before deployment, and how to handle code risks during the coding phase;
• Security or code quality problems that may be introduced during the coding phase;
• Some post-compile code or binary code that requires analysis.

For static code audit of open-source code, follow these steps:

• Use SAST tools and techniques to audit open-source code;
• Configure appropriate detection rules or use default detection rules for different programming languages;
• For identified vulnerabilities in the code, follow repair recommendations for remediation.

Supplier risk assessment aims to promote continuous improvement of supplier services, ensure the stability of the supply chain, and protect sensitive data as its core objectives. This includes assisting in the classification of suppliers and establishing supplier risk measurement indicators for different categories of suppliers: data centers, non-resident development, certification verification, and data processing. Regular risk assessments are conducted to identify security risks and request remediation. The primary focus is on threat defense, data security, and business continuity. The ultimate goal is to discover and address security vulnerabilities, provide reference for supplier ratings, and ensure the security of the supply chain business.

Supplier Classification and Grading

Supplier classification and grading involve managing suppliers in a differentiated manner, implementing differentiated control measures for critical suppliers and general suppliers. By classifying and grading suppliers differently, special attention is given to high-risk assessment items for critical suppliers, enabling priority rectification and achieving precise and efficient supply chain security management. Critical suppliers include but are not limited to: suppliers involved in the development, testing, and operation maintenance of core business software systems, suppliers handling centralized storage of important data and customer personal sensitive information, and suppliers that directly impact the real-time business and the accuracy of financial and other critical information. Other suppliers with significant impact on the organization’s business operations are also included.

Establishing Metrics

Risk measurement indicators at various levels are used to establish service efficiency and quality monitoring indicators for suppliers, and corresponding indicator monitoring is performed. Based on indicators combined with business scenarios, an analysis of the security responsibilities that suppliers need to undertake and the required security capabilities can be accurately performed, especially data protection capabilities. Different evaluation items can be customized for different types of software suppliers, achieving standardization. Common evaluation areas include but are not limited to: basic information, system management, personnel security, business continuity management, service level continuity management, data center management requirements, physical requirements for data centers, office environment, endpoint security, system security, data security, and more.

Risk Assessment and Remediation

Current Situation Research: This is primarily done through document review, interviews, and on-site inspections. Document review primarily involves reviewing supplier management system-related documents, including supplier operation and maintenance management documents, information security management strategies, business continuity management documents, IT outsourcing management documents, system design documents, etc., to fully understand the current status of supplier management. Interviews involve interviewing relevant personnel from various departments. The purpose of the interviews is to verify the establishment, execution, supervision, and maintenance of management systems and processes and the level of understanding of management systems and processes related to their positions. On-site inspections mainly include on-site inspections of physical data centers to ensure that the physical environment can support the stable operation of various information systems.

Gap Analysis: Primarily based on international standards, combined with the content of relevant regulatory standards from industry regulatory agencies, and based on the actual situation, a checklist for evaluating supplier management capabilities and a supplier risk assessment table are formed, covering risk measurement indicators for data centers, non-resident development, certification verification, data processing. The assessment items cover basic information, system management, personnel security, business continuity management, service level continuity management, data center management requirements, physical data center requirements, office environment, endpoint security, system security, data security, and other evaluation items. This is done to analyze the compliance gap between suppliers and supplier management and compliance requirements.

Emergency Plan Preparation

To prepare an emergency plan suitable for the company, the following steps should be included:

Current Situation Research

To ensure that the emergency plan aligns with the company’s actual situation, it is essential to conduct a survey of the company’s current status before formally preparing the emergency plan. The survey includes but is not limited to information on software components, software usage, the importance of business involvement, deployment architecture, departments involved in operation and maintenance, supplier situations, and the results of software system risk assessments.

Plan Preparation

Once the information above is collected, a dedicated emergency plan preparation team can be established to begin the process of creating an emergency plan. During this process, the scenarios for the emergency plan should be determined. While preparing the plan, relevant laws and regulations, industry standards, technical specifications, and the company’s specific situation and security capabilities should be taken into account to formulate the appropriate emergency response procedures and operational specifications.

Plan Review, Publication, and Training

The completed emergency plan should be reviewed by relevant individuals, such as internal and external experts, and the departments involved in the plan. Once the review is complete, the plan should be published following the company’s document publication process, and training sessions should be held for all relevant personnel.

Specialized Emergency Drills

The main objectives of supply chain security emergency drills are to test the following capabilities:

Intelligence Gathering and Analysis Capabilities

Intelligence gathering and analysis are critical for emergency responses to supply chain security events. Traditional network attack events can often be detected based on rule matching in security devices or modeling of attack behaviors. However, supply chain security events are often caused by zero-day vulnerabilities or APT attacks, which have a high level of concealment. It is difficult to detect them using traditional monitoring methods. Information on these events often surfaces in small, specialized online communities, forums, and technical channels. Quick discovery and response to supply chain security events require strong intelligence gathering and analysis capabilities. This intelligence can be obtained from official channels and specialized security companies. Official channels refer to information provided by suppliers or reports from higher-level supervisory organizations. Security companies include specialized threat intelligence companies and professional security companies with strong expertise.

Software Component Analysis Capabilities

The severity of supply chain security events lies in the fact that many software products may use the same code packages, frameworks, or open-source code. Therefore, both customers and suppliers need to have the capability to analyze software components. The more complete the software component analysis or record, the faster the response to a supply chain security event, allowing for the quick identification of affected assets. Based on the importance of assets, appropriate response priorities can be established. An example is the Apache Log4j2 remote code execution vulnerability (CVE-2021-44228) disclosed on December 9, 2021. According to MVN Repository, nearly 7000 projects referenced Log4j2. If an enterprise lacks software component analysis capabilities or software component management, the internal search for affected software may take a significant amount of time, causing missed opportunities for optimal repair windows and the potential for incomplete fixes of all affected software.

Robust Blocking Capabilities

When a supply chain security event is discovered, temporary measures based on indicators of compromise (IoC) are often taken to block the event and gain time for fixing the vulnerabilities. If an enterprise’s blocking capabilities are inadequate, preventing related attacks or connections can be challenging, making the response process more difficult and leading to repetitive work.

Effective Communication Mechanism

A good communication mechanism is essential both in normal network security event handling and in supply chain security event handling. However, supply chains are more complex and involve not only communication between different departments within an organization but also communication and coordination among multiple suppliers. Therefore, establishing a good communication mechanism, clarifying communication procedures, and defining communication channels in advance are crucial.

Emergency Exercise Process

The basic organization process of the emergency drill work is shown in the figure below:

a) Planning for the Exercise: Based on the actual needs of emergency response work, the demand for emergency exercises is coordinated, and an emergency exercise work plan is formulated.

b) Determining the Exercise Objectives and Scope: The emergency exercise work leadership team determines the objectives and scope of the emergency exercise, as well as the participating organizations and personnel, and authorizes each participating organization and individual to participate in the emergency exercise according to their respective responsibilities.

c) Determining the Exercise Plan: The emergency exercise planning team compiles the exercise plan based on the emergency response plan. They set the exercise scenarios, involve expert consultants, and receive guidance. The emergency exercise work leadership team approves and confirms the exercise plan.

d) Allocating Exercise Resources: The emergency exercise support team allocates the necessary resources for the exercise based on the exercise plan.

e) Exercise Commencement: The emergency exercise begins, as announced by the exercise commander authorized by the emergency exercise work leadership team.

f) Exercise Execution and Handling Exceptions: The emergency exercise planning team initiates the emergency exercise conditions, and each group carries out its responsibilities according to the predetermined plan. In the event of unforeseen incidents, they follow the guidance of the exercise commander.

g) Exercise Status Recovery: After the emergency exercise concludes, the exercise restores the environment, resources, and information systems involved in the exercise to their pre-exercise status according to the plan.

h) End of Exercise: The exercise commander announces the end of the emergency exercise.

i) Exercise Conclusion and Reporting: The exercise commander organizes relevant personnel to assess and conclude the emergency exercise work, and reports the situation to the emergency exercise work leadership team.

j) Addressing Deficiencies or Issues Identified During the Exercise: The relevant initiating departments address and make improvements or adjustments based on the deficiencies or issues identified during the exercise.

Types of Exercises

Desktop Exercise

A desktop exercise, also known as tabletop exercise, involves participants using aids like maps, flowcharts, computer simulations, and video conferences to interactively discuss and simulate emergency decision-making and on-site response to predetermined exercise scenarios based on emergency plans. Desktop exercises can be conducted as discussion-based exercises or as operations-based exercises and are typically held in a conference room.

The objectives of a desktop exercise include clarifying cooperation and role assignment, honing participants’ problem-solving skills, identifying and resolving issues in plans and procedures, and generating constructive discussion results.

• Discussion-Based Desktop Exercise: Discussion-based desktop exercises primarily revolve around discussing the issues presented. The exercise commander introduces one or several issues as per the exercise plan, either verbally or in writing. Participants follow the emergency plan and relevant regulations to discuss actions to be taken and provide a written summary and improvement suggestions.
• Operations-Based Desktop Exercise: In operations-based desktop exercises, the exercise commander sends control messages according to the exercise plan. Participants, upon receiving the control information, use role-play or simulate operations to complete emergency procedures. Preparatory work for operations-based desktop exercises includes creating a flowchart for executing procedures and an exercise script.

Desktop exercises have a smaller scale and do not require the simulation of resources or personnel beyond the emergency response working group. They do not impact real systems.

Live Exercise

Live exercises can be divided into simulated operations exercises and real operations exercises.

• Simulated Operations Exercise: Typically conducted in a test environment, these exercises require simulating operations as realistically as possible. The exercise environment should closely resemble the actual production environment. This type of exercise focuses on technical operation validation, resource coordination and collaboration, issue resolution, and risk mitigation.
• Real Operations Exercise: Real operations exercises are carried out in a real environment. They are more about practical and technical operations. These exercises need to be preceded by preliminary rehearsals (e.g., desktop exercises or simulated operations exercises). Real operations exercises require the participation of all relevant personnel and resources to test the overall emergency response capabilities.

Live exercises have a larger scale and require the coordination of the emergency response working group and various departments. They can potentially affect systems or networks but yield realistic results.

Event Response and Handling

To handle information security incidents in an organized, scientific, and orderly manner, the PDCERF methodology is adopted. This methodology, first proposed in 1987 by the Software Engineering Institute at the University of Pittsburgh, segments emergency response into six stages: Preparation, Detection, Containment, Eradication, Recovery, and Follow-up. Each stage has specific objectives and defines the order and process of response.

Preparation: This stage primarily includes examples of useful tools and resources that may be used during the incident handling process. It also involves establishing security measures, creating an information security incident response plan, conducting emergency drills, and configuring and hardening systems.

Detection: The Detection stage is the most critical phase throughout the entire emergency response process. During this stage, system administrators use detection techniques or devices to determine if the system exhibits any abnormal behavior. Upon discovering abnormalities, a security incident report is generated. Security experts then become involved, conducting advanced detection to determine the root cause of the security incident, ascertain the characteristics of the incident, assess the extent of its impact, and identify changes the incident has caused in the affected systems.

Containment: In the Containment stage, actions are taken to control, halt, or mitigate the security breach. Various methods are applied to restrict and block the security breach. Targeting the characteristics identified during the Detection stage, such as ports, services, attack sources, system vulnerabilities, appropriate security remedies are deployed to prevent the incident from deepening and expanding.

Eradication: The Eradication stage ensures complete elimination of the technical cause of the security problem and rectifies the consequences of such issues. It addresses the final technical root causes of this kind of security problem, to ensure it is thoroughly removed. It also rectifies and eliminates the consequences of this type of security problem.

Recovery: The Recovery stage focuses on restoring the system to its normal operational state. After an intrusion, attackers often modify the system. Simultaneously, they attempt to hide these changes from maintenance personnel. So, the recovery stage involves reverting the system to its operational state, including recovery and elimination of changes.

Follow-up: The Follow-up stage mainly tracks and audits the effects of the Containment or Eradication. It verifies that the system or terminal is not re-invaded, and the handling situation is summarized. The experience and lessons learned are collected, and existing security protection measures and emergency response plans are improved.

However, there are subtle differences when dealing with supply chain security incidents. This is because supply chain security incidents involve two roles: suppliers and customers. Their responsibilities and objectives differ, which leads to differences in the response process.

From the supplier’s perspective, a supply chain security incident essentially means a problem with the provided product. Therefore, the emergency response process is similar to the internal change process within a company. It includes problem identification, solution development, implementation of changes, change testing, new version release, and customer notification. Thus, from the supplier’s viewpoint, the emphasis is on making changes to the relevant products.

From the customer’s perspective, the emergency response process for supply chain security incidents is similar to the PDCERF model. However, supply chain security incidents require a different approach, as they may involve service interruptions or changes in suppliers. The response process then becomes a backup and recovery process.

Previous posts on software supply chain security:

• Software Supply Chain Security: Overview
• Threats against Software Supply Chain Security
• The Increasing Trend of Software Supply Chain Attacks
• The Increasingly Complex and Varied Vectors to Attack Software Supply Chain
• Security Concept for Software Supply Chain (Part 1) — Transparency of Software Supply Chain Compositions
• Security Concept for Software Supply Chain (Part 2) — Assessable Capabilities of Software Supply Chain Compositions
• Security Concept for Software Supply Chain (Part 3) – Building Trusted Software Supply Chain
• Relationship Between Security Concept and Security Assessment for Software Supply Chain
• Technical Framework of Software Supply Chain Security
• Key Technologies for Software Supply Chain Security—Techniques for Generating and Using the List of Software Compositions (Part 1)
• Key Technologies for Software Supply Chain Security—Techniques for Generating and Using the List of Software Compositions (Part 2)
• Key Technologies for Software Supply Chain Security – Detection Techniques (Part 1) – Software Composition Analysis
• Key Technologies for Software Supply Chain Security – Detection Techniques (Part 2) – Static Application Security Testing (SAST)
• Key Technologies for Software Supply Chain Security – Detection Technique (Part 3) – Dynamic Application Security Testing (DAST)
• Key Technologies for Software Supply Chain Security—Detection Technique (Part 4)—Interactive Application Security Testing (IAST) and Fuzzing
• Key Technologies for Software Supply Chain Security – Data Security Technology
• Software Supply Chain Security Solution – Supply Chain Security Supervision (Part 1)
• Software Supply Chain Security Solution – Supply Chain Security Supervision (Part 2)

The post Software Supply Chain Security Solution – Supply Chain Security Control appeared first on NSFOCUS, Inc., a global network and cyber security leader, protects enterprises and carriers from advanced cyber attacks..

*** This is a Security Bloggers Network syndicated blog from NSFOCUS, Inc., a global network and cyber security leader, protects enterprises and carriers from advanced cyber attacks. authored by NSFOCUS. Read the original post at: https://nsfocusglobal.com/software-supply-chain-security-solution-supply-chain-security-control/