20
Supply Chain and Software Acquisition
In this chapter you will
• Learn about supplier risk assessment and how it pertains to the software development lifecycle (SDLC)
• Learn about supplier sourcing using the SDLC as a criterion
• Examine the options for using software and development criteria in software acquisition
• Examine the options for using software delivery, operations, and maintenance criteria in software acquisition
• Explore issues associated with transitioning between suppliers
In this day and age, it is probably more appropriate to say that software is “integrated” rather than “built.” That is, the major suppliers of software build most of their products by combining parts from a range of different sources into a complete deliverable. In actual terms, this practice means that the majority of software, and particularly major applications, is purchased rather than built by a single supplier. The implications of this approach ought to be obvious. If components in a product are purchased from external sources, then it is critical to ensure that all of those sources can be trusted. Supply chain risk management is the process that ensures a sufficient level of trust among all external contributors to a product or service.
Typically, supply chains are hierarchical, with the primary supplier forming the root of a number of levels of parent-child relationships. There are usually four levels in a conventional supply chain, but there can be more or fewer. From a risk assessment standpoint, these multiple levels demand that every individual product passing between each individual node in the hierarchy be correct in order to ensure product integrity. In addition to individual product correctness, it is necessary that each product be properly integrated with all the other components up and down the production ladder in order to ensure the integrity of the overall product. Because the supply chain itself is usually distributed across multiple organizations, maintaining a sufficient level of integrity of all of the products that are moving within that process is a very difficult task indeed. The weak-link analogy is obvious in this equation, so the various threats that might affect that product’s supply chain have to be precisely identified and their mitigations carefully coordinated and controlled. As a result, formal risk assessments are at the heart of the supply chain risk management process.
Supplier Risk Assessment
The overall purpose of supplier risk assessment is to identify and maintain an appropriate set of risk controls within the overall supply chain. Given the threats implicit in the supply chain process, supplier risk assessments are a particularly critical part of the effort to maintain effective supplier control. Supplier risk assessments identify specific threats to the organization’s supply chain and then evaluate how likely those threats are to occur, as well as the consequences of each threat should it happen. In that respect, supplier risk assessments underwrite the development of the specific strategy that will be used to ensure trust up and down the overall supply chain.
According to the General Accounting Office (GAO), threats to supply chains fall into five generic categories. Each category has distinctly different implications for product integrity. These categories are
• Installation of malicious logic in hardware or software
• Installation of counterfeit hardware or software
• Failure or disruption in the production or distribution of a critical product or service
• Reliance on a malicious or unqualified service provider for the performance of a technical service
• Installation of unintentional vulnerabilities in software or hardware
Supplier risk assessment lessens all of these concerns by providing assurance that the supplier employs a consistent, disciplined process that ensures measurable product integrity. Supplier risk assessments identify what could go wrong in the development process, determine which risks to address, set mitigation priorities, implement actions to address high-priority risks, and bring those risks “to within acceptable levels.” Supplier risk assessments let managers deploy the necessary proactive and reactive controls to respond to threats as they arise in the supply chain. This process also monitors the effectiveness of those controls once they have been put in place. The general aim of supplier risk assessment is to ensure up-to-date knowledge about the supply chain’s overall threat situation. Systematic supplier risk assessments explicitly guide the prioritization of the steps that the organization will take to ensure the security and integrity of its products.
What Is Supplier Risk Assessment?
In its general form, supplier risk assessment is an information-gathering function that focuses on understanding the consequences of all feasible risks. The risk assessment process identifies and evaluates each identified threat, determines that threat’s potential impact, and itemizes the controls that will be needed to respond properly should the threat occur. In that respect, risk assessments should always answer two distinct but highly related questions. The first question is: “What is the certainty of a given risk for any given supplier?” The answer to that question is typically expressed as likelihood of occurrence. The second is: “What is the anticipated impact should that risk occur?” The answer to that question is normally expressed as an estimate of the loss, harm, failure, or danger, usually in economic or human safety terms. Ideally, both of these questions can be answered in terms that decision makers can understand and take action on.
 | EXAM TIP A supplier risk assessment is used to identify specific threats to the organization’s supply chain, evaluate how likely those threats are to occur, and determine the potential consequences of each threat should it materialize. |
The ability to make decisions about the requisite mitigations implies the need for an explicit management control framework to guide the decision-making process. Authoritative models that dictate how to impose the necessary management control already exist. These models dictate a practical basis for identifying and characterizing threats that might impact a given supply chain. Once those threats have been identified, these models also suggest standard mitigations that can be tailored to address each priority threat. The requirement for systematic execution of the mitigations in any given risk management process is what provides the justification for the adoption of a well-defined set of real-world risk assessment practices to inform and guide the process. And in that respect, it is also important for the organization to be able to improve its standard risk assessment process as the business model changes.
A standardized and organization-wide process provides a stable baseline to assess the specific risks that each potential supplier represents. A common assessment process also provides the basis that will allow all of the development project’s stakeholders to stay on the same page with each other when it comes to actually performing the project work. The aim of the assessment framework is to factor the identified risks and their mitigations into a “who, what, when” structure of necessary practices, as well as identify the required interrelationships.
Risk Assessment for Code Reuse
As a manufacturing paradigm, the overall concept of reusability has probably been around since the time of Julius Caesar. But the concept of code reuse has only gained traction in the software industry in the past 20 years. At the machine level, code reuse has been a fundamental principle of compilers since the 1950s. In fact, reusing fundamental machine functions instead of individually writing a machine language program each time an operation had to be performed was the innovation that essentially ushered in modern high-level programming languages. Moreover, in that respect, standard template libraries (STLs) are still a fundamental part of compiler languages like C++.
In simple terms, at the application level, code reuse is nothing more than the construction of new software from existing components. Those components might have been created for another project, or they might have been common functions that were created and stuck in a library with the intention of reusing them in a range of products. From a cost-benefit standpoint, reuse is a very logical way to approach the problem of producing code. Having standard, already written functions, templates, or procedures available saves time, and thereby reduces cost. It also ensures quality control and a standard level of capability for the code that is produced from reusable parts. The problem, however, is that a single reused module that has been compromised can introduce risks into a wide range of subsequent applications. Therefore, in the conventional supply chain risk management sense, it is absolutely critical to be able to define the specific situations and uses where a given reusable module or reuse process can be safely and legitimately applied.
Creating a Practical Reuse Plan
The general aim of the reuse process is to develop a secure library of reusable components, much like a physical parts inventory, which will both leverage production and assure quality. The reused code modules have to be assured correct in order to avoid duplicating prior errors in logic and syntax. That is the reason why reuse is supported by basic software design principles such as modularity, information hiding, and decoupling. Those principles ensure that the code can be validated to be both properly functioning and secure. However, in order to guarantee that security, a range of practical risk management activities have to be adopted and followed.
Because reusable code usually originates from other, sometimes unknown sources, utilizing it can be risky. Therefore, the terms of its use have to be clearly stated in any contract involving reuse, along with a basis for negotiated liability for loss or damage should problems arise. The strategy and decision criteria are normally laid out as a result of a strategic planning activity. That activity guides code reuse for the project. It is usually a part of the overall risk management plan. The strategy ensures that the types of reuse that will be utilized are well defined and that reuse planning is conducted accordingly. Planning stipulations typically include a requirement to state whether the reuse process will involve open-source code, other reusable code, and/or value-added products or services. The reuse planning process supports decision makers by helping them to evaluate the advantages of reusable code as well as how to ensure any reusable software against risk.
Once risks within the project space and to the reusable objects are laid out, prioritized, and documented, the organization conducts a risk management security testing process with all relevant stakeholders. That includes software developers, asset managers, domain experts, and users. The aim of this process is to validate the strategy that will effectively guide the reuse process. Once the security testing is complete and the results accepted, the description of all identified risks and their proposed mitigations is passed along to the appropriate development managers for application to the reuse process. Moreover, since risks appear constantly, this is an iterative process that is conducted in a cycle suitable to the risk environment.
Intellectual Property
Products moving within a supply chain can always fall prey to intellectual property theft. That is mainly because most of those products are abstract entities that can be easily stolen. Software and all of its artifacts fall into the realm of intangible intellectual property. As a result of that intangibility, software is difficult to ensure against intellectual property theft. The problems of intangibility are exacerbated if the software item is part of a supply chain, since most commercial systems are integrated up from a very large collection of small, easy-to-steal software items. Any one of the items in a supply chain could be at risk of intellectual property theft. Nevertheless, a number of concrete steps might be taken to address the problem of intellectual property violations within a supply chain.
Theft of intellectual property can involve everything from plagiarism to outright pilfering of other people’s products or ideas. The legal issue revolves around the concept of “tangibility.” Tangible property has substance and obvious worth. It can be seen and counted and so it is harder to steal. It is possible to assign a clear value in a court of law if the theft takes place. However, intellectual property is abstract, so its value is strictly in the eye of the beholder.
Software is difficult to visualize as a separate component and hard to value. Therefore, its legal protection is complicated. For instance, it would be hard to attach a great deal of monetary value to a software program if the courts were to only consider the actual resources that went into making the product. There might be enormous creativity and inspiration involved in its design, but the actual value of the time spent will not represent its real worth, nor will the material investment, which usually amounts to nothing more than the price of the disk and packaging. So the problem that the legal system faces is assigning penalties if the item is stolen or misappropriated. Given these roadblocks, the question is, “What can be done to protect intellectual property rights within a complex environment of systems?”
 | NOTE Software can contain intellectual property in many forms: processes, algorithms, or coding; thus, the intellectual property can represent business value and hence requires appropriate protections. |
The best hope for preventing the theft of intellectual property is to perform rigorous audits and inspections of items as they move up the integration ladder and then enforce penalties for infringements. So the most important step in addressing identified and documented thefts of intellectual property involves nothing more than increasing awareness in the minds of suppliers and developers that intangible products have tangible value. More importantly, there has to be a mechanism to guarantee and enforce the right of possession up and down the supply chain.
Two specific federal regulations address intellectual property rights enforcement directly. These are the Computer Software Rental Amendments Act of 1990, which stipulates that rental, lease, or lending of copyrighted software without the authorization of the copyright owner is expressly forbidden. Likewise, the general Copyright Law (Title 17 of the U.S. Code) has been interpreted in such a way that the creation or distribution of copies of software without authorization is illegal. That is the case even if there is no express copyright given to the owner. The only exception to this law is the allowance for the user to make backup copies for archival purposes. Under this law, the unauthorized duplication of copyrighted material, including software, can lead to fines of up to $100,000 and jail terms of up to five years per incident.
Legal Compliance
All software items moving within a supply chain have to comply with existing laws and regulations. Compliance simply describes a condition or state in which the component elements of the system satisfy a wide range of legal and regulatory requirements. Those requirements can come from a variety of sources, including government, industry, and contracts. Compliance is a very important consideration in the supply chain risk management universe, since the failure to comply with a legal requirement or regulation can bring significant legal penalties, not just financially but also in terms of loss of reputation and even criminal consequences.
Compliance situations usually have extensive reporting requirements associated with them. As a result, the issue with compliance is not so much ensuring that controls are in place to make certain that the legal and regulatory obligations of the organization are met. Instead, the challenge is to develop objective, auditable evidence that those requirements have been satisfied and then report that evidence to the appropriate legal and regulatory entities. Those entities are varied. Each of them might have overlapping and sometimes conflicting compliance requirements. As a result, it is normally considered correct practice to establish a single, unified compliance process to coordinate the diverse number of compliance obligations that the organization will face.
Supplier Prequalification
It goes without saying that software is hard to buy. That is because the buyer is essentially purchasing an invisible set of underlying functions without any direct control over how they are built. Thus, the best practical way to ensure that a quality like security is built into the final deliverable is to utilize procedures that are specifically aimed at increasing the acquirer’s understanding and control over the supply chain provisioning process. Those procedures must guarantee that security considerations are a central part of the routine management of the supply chain. The aim of these considerations is to ensure information and communications technology (ICT) product integrity and reliability.
The overall product assurance problem is exacerbated by the fact that the business model for most organizations is heavily leveraged by commercial off-the-shelf (COTS) software products. Many COTS products are created in multi-tiered, multivendor environments, which could involve a range of cultures and norms as well as simple barriers of language. Given the difficulty of vetting a global system, it is a lot to expect a software product to come back from external supply chains without defects and free of exploitable vulnerabilities, or even worse, malicious elements that have been intentionally inserted.
Since supplier capability is at the center of any outsourcing decision, it is important to find out in advance if the contractors that comprise the supply chain possess all of the capabilities required to do the work. Specifically, suppliers have to prove that they are capable of developing and integrating a secure product. Overall capability is usually demonstrated by the supplier’s past history with similar projects as well as their documented ability to adopt good software engineering practices. That includes the ability to ensure that the subcontractors a prime contractor employs are trustworthy.
Assuring a Black Box: COTS
Assuring the integrity and security of a COTS product is particularly difficult because that kind of software is essentially a “black box” to the purchaser in that there is no source code to analyze. As a consequence, it is impossible to say exactly what is in a COTS product, or even who developed it and what process was used. Black boxes can be tested to determine whether the desired functionality has been provided and works properly. But without an intimate knowledge of the structure of the code, it is impossible to tell whether there are unused features or “hidden” objects and any undesirable effects that the actual behavior of the product might induce.
The inability to enforce practical oversight and control over a business environment that is essentially worldwide poses a significant challenge to assuring product integrity. Therefore, it is essential to have a means of identifying the vendors that can be trusted. That need implies the adoption of a mutually agreed-upon approach between the customer and supplier to certify both the trustworthiness and the capability of the organizations in a given supply chain.
In order to do business in the global marketplace, it is necessary to be able to trust a logical set of suppliers, who are typically distributed worldwide. That is the reason why the ability to prequalify a supplier’s security competence through some objective means represents a real business asset. Specifically, if it is possible for an acquirer to utilize a common certification process to designate which suppliers are trustworthy and competent to deliver products with sufficient integrity, this makes the purchasing process much more secure. Implementing some form of prequalification process, whether based on prior audits or reviews of supplier capability, requires resources and planning. However, if a supplier can then be prequalified through that examination, the perils of buying COTS products or assuring sources in a supply chain are greatly reduced. Prequalification requires the customer to objectively understand the precise form of each supplier’s development process. This is not a new idea. A similar concept has been used for years in the manufacturing universe in the form of the ISO 9000 quality system registries. So there is no reason why registrations of security engineering capability cannot be kept. The only issue is which trusted third party provides the prequalification.
ISO 15408: The Common Criteria
A type of third-party registry system is already in place for certifications under ISO 15408, colloquially known as the Common Criteria. This system is called the National Information Assurance Program (NIAP) in the United States, and it is built around the Common Criteria evaluation process. This process builds trust and assurance around the construction of customized program protection profiles for each target of evaluation (TOE) based on the security functional requirements specified in the standard.
From a business standpoint, a financially justifiable and generally accepted certification would accomplish two valuable aims. First, the acquisition community would have objective, independent assurance that they could trust a supplier, even if that supplier were in another country 3,000 miles away. Second, suppliers would be able to gauge their exact level of capability and then determine how to improve it.
Those twin advantages would reduce uncertainties in the acquisition process by identifying the risks associated with a given contractor. Moreover, by identifying the inherent risks, standard certification of capability would also provide an objective basis for trading off business requirements and project cost against each vendor’s areas of weakness when contract time rolls around. Finally, given the interdependence between process capability and the quality of the product, certification would also represent the best means of putting appropriate risk controls in place for whoever was eventually selected.
Supplier Sourcing
Supplier sourcing considerations represent one of the most important issues in the supply chain risk management process. Obviously, each node in the supply chain represents a source, and every one of those sources has to be vetted and shown to be trustworthy. So supplier sourcing generally amounts to nothing more than doing all of the analysis that is needed to understand every aspect of the supplier’s operation while making any sourcing decision. It is important that the decision be thought through prior to making the decision to contract out the work.
Given the variability among subcontractors, the acquirer should explicitly understand which elements of the proposed work the subcontractors will be allowed to perform. And for the sake of ensuring a consistent outsourcing process, it is also just as important to be able to state which activities the subcontractor will not be allowed to perform. That understanding is necessary so that the acquirer and the prime contractor can make specific determinations about how to apportion the work and how subcontractors will then be managed and supported throughout the process. The assignment of work elements to subcontractors is usually explicitly stipulated in the contract, and all additional outsourcing decisions are guided by the criteria that are embedded in the contractual language.
In addition to outsourcing, a strategic security concern should also be addressed—the determination of the degree of foreign influence and control that might be exercised over the product. Influence and control by organizations or nation-states that are not necessarily friendly to the United States will directly impact the trustworthiness of that product. Therefore, the degree of foreign influence, control, or ownership of a given contracting organization has to be determined and ensured before additional steps can be taken to manage risk.
The nature of software development results in final products that have a wide range of sources of included components. From included libraries, to subroutines, to modules, the sources of individual elements of software can come from a wide range of subsuppliers, both foreign and domestic. Elements of programs can be outsourced to third parties for development, with integration being handled by other parties. Figure 20-1 illustrates the relationships between the wide array of supplier relationships common in software development today.
Figure 20-1 Layered security
Source: Walker, Ellen. “Software Development Security: A Risk Management Perspective.” The DoD Software Tech. Secure Software Engineering 8, no. 2 (2005): 15–18.
This article was originally printed in the DoD Software Tech News, Vol. 8, No. 2. Requests for copies of the referenced newsletter may be submitted to the following address: Philip King, Editor, Data & Analysis Center for Software P.O. Box 1400 Rome, NY 13442-1400 Phone: 800-214-7921 Fax: 315-334-4964 E-mail: [email protected]. An archive of past newsletters is available at www.SoftwareTech¬News.com.
A number of commonly accepted industry models can be utilized to source suppliers up and down the supply chain. One of the most common approaches is to rank bids based on a risk-versus-return score. Higher scores are given to projects that meet or exceed expectations for criteria like technical soundness, contribution to the business goal, and overall resource constraints. Tradeoffs from a security standpoint include
• Strategic improvements vs. maintenance of current operations A supplier’s efforts to modernize their operation can actually increase the risk of a security breach. Therefore, there has to be an assessment of the value of changing a supplier’s operation, no matter how beneficial the change might seem based on other criteria, such as cost or market share. In general, changing a successful operation’s configuration is always a security risk unless the improvement can be justified.
• High versus low risk If the only goal is to minimize risk, then the general performance of the suppliers might be constrained. High-risk, high-return approaches can enhance the value of a product, provided the risks are capably and carefully managed. Most organizations, however, can only handle a limited number of such projects. As a result, management must always balance the amount of risk they can afford against the ability to manage it.
• Impact of one supplier on another Every new supplier is likely to affect, or be affected by, the suppliers in the current supply chain. Management must recognize the context in which the new supplier will operate and make decisions accordingly—particularly when it comes to the complexity of the current supplier base and the interface with a new supplier. Adding a supplier at higher levels in a supply chain can often translate to downstream ripples that can adversely affect the safety and security of the overall structure.
• Opportunity costs Management must always consider the impact on longrange investment. For instance, will large current investment in suppliers and their operating costs preclude or delay better future opportunities in the supply chain? Will large current capital expenditures create even larger risks in the future?
The outcome of these comparisons is a set of concrete points of reference that will allow managers to perform the rational trade-offs necessary to reach an optimal sourcing decision. Nevertheless, a range of requisite controls have to be put in place in order to ensure that any end product of the supply chain risk management process will meet all of the necessary criteria for integrity and trustworthiness. One of the most important of these is contractual integrity control.
Contractual Integrity Controls
Contracts are legal agreements to perform a specified action or deliver a specified product. Contracts are legal and binding, and they essentially control a given development process and all of its actions up and down the supply chain. As a consequence, conditions for stipulating and then ensuring contractual integrity have to be built into the supply chain management process. Those conditions include such things as the initial specification of the criteria by which maintenance of contract integrity will be judged and the specification of the standard evaluation criteria that will be utilized to ensure product integrity.
Controls can be developed from those criteria to ensure that the appropriate product assurance security testing and audits are carried out as the contract specifies. Specifically, the controls to oversee the supplier’s delivery of product assurance have to be established, and the monitoring processes have to be installed to ensure that those controls remain effective. Because monitoring will occasionally lead to the issuance of nonconcurrence, there also have to be controls in the contract to ensure an explicit issue resolution process. Moreover, there is also the attendant requirement that corrective actions are implemented and monitored to resolve these issues.
On the administrative side, contractual controls can be put in place to ensure that the terms of the contract are maintained under strict configuration management. If outsourcing is involved, there can be a number of different contracts in a large project, particularly if that project involves a supply chain. All of these contracts have to be maintained in alignment in order to ensure control over product integrity. As a result, the provisions of all relevant project contracts have to be carefully coordinated and controlled up and down the supply chain through a well-defined and formal configuration management process.
Vendor Technical Integrity Controls for Third-party Suppliers
Vendor integrity controls ensure the correctness of the technical process of the subcontractors within a particular supply chain. Their overall aim is to ensure that all contractual requirements are passed to subcontractors in a timely and suitable fashion and that all products of the subcontractors within the supply chain are properly validated. To achieve this purpose, those controls administer the requisite verification, validation, or test agents, as well as communicate with other parties as specified in the contract and project plans.
Vendor technical controls ensure the fundamental integrity of all software artifacts moving within the supply chain. These technical controls ensure the integrity of all product baselines throughout the development and sustainment processes, including all product baselines and repositories. The specific aim of technical controls is to ensure the completeness, consistency, and correctness of a formal set of components that comprise a given product. The objective is to ensure that the organization knows the state of those components at all times. As we have frequently pointed out, software is an abstract entity and so the only way it can be reliably managed is through the consistent and reliable execution of a formal and well-defined set of technical control activities.
The controls themselves are references to an identified set of technical items that are normally maintained in a formal baseline. In practical terms, that baseline identifies, defines, and assures the integrity of a given software product or service. All modifications and releases of the software or product are controlled and made available through that baseline, and any changes to the baseline are formally recorded and reported to management. Consequently, the modification and release of any technical item has to be properly instituted and then inspected for correctness. The records and reports on the status of each of these items is then maintained as part of the permanent product baseline.
The controls frequently comprise test- and audit-based behaviors. Their aim is to coordinate contract security testing activities between the various interfaces. In particular, the technical security controls ensure joint security assurance in accordance with contractual specifications. Security assurance tests should ensure that sufficient verification and validation have been done to support a conclusion that requirements are properly met at each level in the supply chain. In addition, those controls should generate reports and make them available to all parties as specified in the contract.
A range of technical controls might be deployed to guide the technical phases of the project at each level in the supply chain. The overall aim of these approaches is to ensure that all of the participants in the supply chain follow proper practices in producing the technical work. Examples of what might be considered a control include assurance of proper resource management, proper use of data structures, proper reuse of testing practices, and general software engineering best practices. The latter might include such specifications as proper commenting, variable naming conventions, and code structure. These techniques are almost always stipulated in the internal standards and guidelines of the customer organization and passed through to each of the third-party organizations in the supply chain.
Ensuring the correctness of technical processes normally involves three types of general assurance activities, all of which usually occur during the coding and integration process: unit testing, integration testing, and qualification testing. Unit testing is handled as part of the coding process, and it normally involves customer-supplier joint security testing throughout the construction phase. Integration testing is part of joint security testing during the software integration process as the product moves up the supply chain. Qualification testing takes place once major deliverables pass through acceptance checkpoints. All three forms are typically based on product requirements and are supported by Institute of Electrical and Electronics Engineers (IEEE) standards that dictate the proper way to plan and execute each testing activity.
Managed Services
In most respects, managed services have the same general set of control requirements as the technical deliverables that we just discussed. The overall aim of the supply chain risk management process is to ensure that the customer gets what they contracted for. However, rather than a systematic inspection of deliverables, managed services require continuous assurance of a persistent set of behavioral requirements that are specified in the contract. That is because managed services involve continuous customer-supplier interaction. The key to getting the assurance correct is to provide a clear and unambiguous description of the services that are to be delivered to the prospective customer. Thus, it is possible to properly manage the delivery of software services with a correct and complete specification of functions required.
The artifact that underpins that description is a written and highly detailed specification of service requirements, which spells out in formal and contractual terms the exact set of functions that the service provider will perform. A good specification will fully itemize two kinds of things: the functions that must be performed by the supplier and the criteria that will be used to evaluate whether these functions were actually provided. In effect, the statement of functions required is a list of the externally observable behaviors that must be exhibited at the time of contract performance, while the criteria for evaluation itemize how the customer will confirm that the desired functionality was actually provided and is correct.
In order to ensure reliable execution, the functions and their criteria for evaluation have to be captured in a service level contract. The contract will spell out all known requirements of the acquisition project, including cost and schedule. The contract normally addresses such legal issues as usage, ownership, warranty, and licensing rights associated with the service. Then the legal form of the contract itself is monitored and controlled through a formal change control.
Service Level Agreements
Service level agreements (SLAs) essentially set the requisite level of performance of a given contractual service between a customer and supplier. Once entered into, the SLA becomes a legally binding document. Typically, a good SLA will satisfy two simple rules. First, it will describe the entire set of product or service functions in sufficient detail that their requirement will be unambiguous. Second, the SLA will provide a clear means of determining whether a specified function or service has been provided at the agreed-upon level of performance.
The contract, which is the central document in enforcing an SLA, substantiates both of these conditions. It is the mechanism used to express the required levels of performance. As a result, those behaviors have to be described as externally observable behaviors. Along with the behaviors to be observed, the contract should specify a process and an accompanying set of objective criteria that will be used to judge whether those behaviors have been correctly implemented in the deliverable. In addition, the contract would normally address such legal issues as usage, ownership, warranty, and licensing rights associated with the product or service. In that respect, the contract must legally define all of the requirements for performance for all parties.
Normally, because technology, and software in particular, is complex, the presence and execution of desired levels of performance from a provider can only be evaluated based on a proxy. Consequently, objective, behavioral criteria that are specifically associated with the desired actions that they represent must be placed in the contract. These criteria provide the mechanism for evaluating an essentially invisible and typically complex set of activities based on observable outcomes.
Alterations to an SLA may take place in the course of events. However, if alterations are required, these changes must be accomplished within the legal structure. It should be noted that the responsibility for ongoing maintenance of changes to the contract agreement rests with the acquiring organization. Consequently, if there is any alteration to the contract, the new form of the agreement is kept by the acquirer within its contract change control system.
Software Development and Testing
Software development is the place where the organization comes to grips with the difficult world of building the product. Software is an intangible entity, and its construction can be a chaotic process unless structured software engineering practices are followed. This is particularly true for organizations in a supply chain. In many respects, software validation and verification activities are the bedrock of the supply chain risk assessment process, since they produce the objective proof of product correctness and compliance with customer requirements. The purpose of validation and verification in a supply chain is to confirm that each of the software products and/or services that are passing through the system reflect their specified requirements.
If a given artifact is sufficiently consistent, complete, and correct, it can proceed downstream to another phase in the lifecycle. The customer organization calls on validation and verification when it needs to determine whether a particular deliverable, which is exiting a checkpoint in the delivery process, meets the requirements that were initially specified for it. Therefore, validation and verification is almost always performed in an iterative fashion. That is, the product is continuously verified as its deliverables are refined and move downstream in the development process.
Along with this primary mission, validation and verification serves to warrant the quality of the individual products moving within the supply chain. Finally, validation and verification determines whether all of the risks and feasibility issues associated with those products and services have been addressed and satisfied. This type of assessment can involve security testing, inspecting, checking, auditing, or otherwise establishing and documenting whether or not a set of components, processes, services, or documents conform to the specified requirements of a supply chain management process.
The validation and verification process is formalized by a management plan for testing and inspection. This plan should be defined at the beginning of the development process and then refined as the project moves downstream. As the real-world testing activity rolls out, intermediate issues and approaches will emerge that reflect an enhanced understanding of the project. However, these transitional changes must always be adapted to the overall testing scheme and reflected in the modified plan in order to ensure that they actually confirm the requisite correctness of a given deliverable.
Determining where and when to employ validation and verification processes should be a formal management decision that is based on evidence and supported by facts. The validation and verification processes themselves can range from highly informal unit tests to very formal acceptance audit activities. Any evaluation process will only be as good as the degree of freedom that is granted to it by the organization, so the most powerful of these testing processes normally involves a third party to do the actual assessment. Because acceptance is a customer activity, validation and verification frequently involve the use of external consultants.
Code Testing
The overall purpose of the testing process is to ensure that the code is implemented properly and complies with all relevant requirements. This determines whether the eventual code product has met the testing criteria expressed in the testing plan. Testing must be a rigorous process, in the sense that the functioning of each of the components must be fully tested and documented.
Every code artifact within the system should be tested in order to determine whether it functions properly and meets its specific requirements. Accordingly, a set of tests and test procedures have to be developed and documented, and the developer has to ensure that the code as built is ready for integration up and down the supply chain. For each code module being tested, the developer prepares and documents a set of tests, test cases (inputs, outputs, test criteria), and test procedures that will be employed to conduct product testing. That includes the development of a regression strategy that will be applied if any retesting is required.
The developer then ensures that the code is ready for testing. The prospective testing process is generally judged based on the degree of test coverage, appropriateness of test methods and standards, conformance to expected results, feasibility of the proposed testing, and preparation and maintenance of the testbed.
In doing the testing, the developer is required to evaluate the design, code, tests, test results, and user documentation using traceability, external and internal consistency, appropriateness of the methodology and standards employed, and feasibility as the criteria for evaluation. As a result, a set of criteria for confirming compliance with all testing requirements should be developed, and each code module must then be tested using those defined criteria. The test results are then recorded, and the readiness of the code to move upstream is assured. In conjunction with this, the developer is required to support and document any and all tests that might be required later in the process.
The point of code testing is to make sure that the eventual realization of the system embodies a trustworthy set of components. Therefore, each component of the code is evaluated to assess whether it complies with qualification criteria. Along with satisfactory execution, that judgment is generally based on traceability, external and internal consistency of the code, and appropriateness of the methodology and standards employed to produce it.
| | EXAM TIP The fact that software is procured via a supply chain does not eliminate the need to understand and verify the necessary testing regimens employed as part of the development process. These aspects are best handled via process validation vice product testing. |
Testing results have to be documented for all stakeholders. The success of the code-testing process is generally judged based on the degree of test coverage of code performance requirements, conformance to expected results, and the general feasibility of operation and maintenance, including readiness for integration. In addition, the developer must audit the testing process itself in order to confirm that it was performed correctly.
Security Testing Controls
It is critical to embed a set of security testing controls into any overall supply chain risk management process. Those controls must ensure that every base is covered in assuring the supply chain product and process integrity. Within the supply chain process, one specific aspect of security testing is likely to need management’s full attention: the identification and characterization of prospective risk. Risk assessments should identify and evaluate all of the potential process, technical, and resourcing risks that reside within a particular supply chain. The aim is to identify and manage existing risks, as well as address any new or emerging risks. That strategy directly maps to the organization’s policies with respect to risk acceptance, as well as any formal procedures for reporting and addressing emerging risks. In order to ensure uniform risk management, the strategic approach to risk has to be standardized across all procurement projects up and down the supply chain.
When ensuring the integrity of the product, the organization is responsible for specifying an explicit process to assure that security outcomes specified in the contract have been achieved. This assurance is actually based on the overall risk management approach that is documented in the contract. The developer generally meets this requirement by installing a comprehensive assurance process, which is aimed at evaluating all identified risks for likelihood and impact. Once this assessment is complete and decisions have been made about what risks will be mitigated and how that mitigation will take place, the supplying organization creates the actual plan for assuring the product and the process elements of the project.
Eight steps are required to create a formal set of security testing controls. The first step is to initiate the process. That step requires the organization to define the key security testing leadership and operational roles. The next step requires identifying the relevant security testing issues for each level and component in the supply chain process. This is usually done in conjunction with acquisition and line project managers. In order to fulfill this goal, the security testing manager and staff must identify and prioritize the key testing issues. Then, in the next step, the organization creates a generic security testing plan. All pertinent audit and control activities are defined in that plan, required standards and practices are identified, and the security testing plan is integrated with the project management plan. Once the security testing plan has been developed, the organization implements the procedures that are necessary to guide the security testing and testing process. The actual implementation process normally involves training the relevant testers and security managers. After the testing personnel are prepared, the organization has implemented the actual security testing process. The implementer assigns specific roles and responsibilities, develops a schedule, defines and performs the monitoring activities and reports, and resolves any identified security problems. Finally, in order to ensure its continuing viability, the testing program itself must be periodically evaluated to determine whether it is performing effectively and as intended.
Security testing must be able to provide sufficient, documented proof that all of the products and services that are part of a supply chain conform to the security stipulations of a given contract. In addition, the testing must warrant that the outcomes of those processes comply with established requirements and adhere to plans. If problems or noncompliances are identified during the testing process, they must be documented and resolved before the security testing moves forward.
Software Requirements Testing and Validation
The software requirements testing and validation process focuses on reconciling the requirements set with the eventual product. Since this is primarily a management function, the initial goal of the requirements testing and validation process is to confirm that all forms of the product moving within the supply chain comply with contractual requirements. In addition, the product must be regularly assessed to confirm that it has satisfied all functional and nonfunctional requirements specified in that particular vendor’s contract. In that respect, the requirements that underwrite the production of the product must be assured to be compliant with all formal specifications of requirements, contracts, standards, and plans. Also, contractually defined performance assessment metrics and evaluation criteria have to be proven to be satisfied. The testing must confirm that both the product and the process comply with all relevant standards.
Software Requirements Testing and Validation for Subcontractors
Requirements testing and validation enforces rigorous control over the practices that are part of developing the product. Every aspect of development must be assured to comply with the requirements of the contract. This includes the testing and validation and test environment, and all associated practices related to process assessment. In addition, because subcontractors are often involved in production, the assurance process has to ensure that all applicable prime contract requirements are passed down to the subcontractor and that the deliverables that are produced by the subcontractor satisfy prime contract requirements.
In addition to overseeing its own project work, the supplier is accountable for strict oversight and control over all subcontractors who might be involved in a particular project. That oversight and control is always done in accordance with the stipulations for subcontractor management that have been placed in the contract for that specific product. The acquiring organization is responsible for ensuring that the stipulations for proper subcontractor management are captured in the contract. The supplying organization is responsible for ensuring that all applicable contract requirements and conditions are clearly understood by any subcontractors.
Subcontractor responsibility specifically involves ensuring that all aspects of the product that are delivered by subcontractors, including hardware, systems, software, or service requirements, fully comply with the specifications of the contract. In order to make certain that this happens, the supplier is responsible for conducting all contractually required verifications, validations, or tests of subcontractor work.
Software Delivery, Operations, and Maintenance
Supply chains deliver software and services. The products of supply chains come out of a development lifecycle, but that lifecycle is only a small part of the actual period that the product will be in use. During the extended period of operation of the product, it has to be maintained in a stable and reliable state, and many risks to both the customer and supplier lurk in that process.
The operations and maintenance activity that follows delivery of the product is normally lumped into a single term: “sustainment.” The aim of sustainment is to properly operate and maintain the delivered software product within its intended environment, as well as provide support to the customers of the software product after delivery. The risks during the sustainment period center on the failure to continue to securely operate or maintain the product. In general, that failure is a consequence of changes in the environment, new or emerging threats, or a poorly executed change process.
Post-development sustainment activities are generally defined by an operational plan. That plan lays out the conditions and criteria for correct operation of the product in its intended environment. Those activities normally involve executing a specific set of operational tests that are administered at defined points in the sustainment process. In addition, the execution of the operational plan might include contracted assistance and consultation provided by the supplier once the product has been moved over to the customer’s system.
Because of its post-delivery focus, sustainment is generally considered to be outside of the supply chain. Where it is included, however, is in updating the security of the product, which usually takes place when a new threat or vulnerability is detected. The process of updating and threat response falls under the generic heading of “patch management.” Patch management obtains, validates, and installs changes to the affected program’s code. These changes are called “patches.” In order to conduct patch management properly, the system’s manager has to continuously monitor available patches and from the results of that monitoring decide which patches apply to their system. Once a decision is made, the manager installs and verifies patches and makes the appropriate documentation entries into the organization’s configuration management system. In that respect, it is easy to view patch management as an extension of the change management process.
The overall goal of patch management is to prepare and then distribute effective responses to security threats in such a way that the given system, software product, or software service can be effectively assured, operated, and maintained. Patch management rarely implies construction; thus, the patches themselves come from an external source. The supplier generally prepares the patch for customer installation, and arrangements have to be made to transfer the new patch from the supplier to the acquirer. This transfer is typically done through a distribution scheme that is often stipulated in the terms of the initial contract. If that is not the case, the patch management plan is prepared as part of the final acceptance of the product.
The supplier might also be contractually responsible for providing advice and support to the end users of the product. Each user request for support and the subsequent actions taken to meet that request must be carefully recorded and maintained as part of configuration management. The supplier, who may also fulfill the role of configuration manager, distributes these user requests, which are often called change requests or CRs, to the appropriate parties for resolution. It should be noted that the sustainment process is highly dependent on configuration management.
However, product upgrades are implemented in the customer’s environment, and modifications are communicated to affected parties through the maintenance process. The goal of maintenance is to change an existing software product while preserving its integrity. Maintenance normally comes into play when it is necessary to modify the code or associated documentation for a project. This is usually a customer activity, but it can be contractually required of the supplier. Change usually originates from a user-generated request to change, modify, or enhance an existing system, software product, or service. The goal of maintenance is to control changes to products in a way that both preserves their integrity and provides a basis for measuring quality. In practice, the process itself is primarily concerned with the consistent labeling and tracking of information about the artifact. In conjunction with the routine practices of upkeep, the maintainer may also be required to perform activities that would normally be associated with development.
Chain of Custody
Because software is complex, the effects of any change or modification to it may not be readily apparent. Therefore, the organization must have the capacity to know about and control the evolution of its products up and down the supply chain. Generally, this is done through some form of configuration management process. Configuration management defines and enforces integral management control over the handling of the software assets of the entire organization. Configuration management is meant to be a formal process for the rational management of software and related artifacts. Software configuration management, or SCM, is an essential technique in the assurance of a chain of custody in that it assures that the state of all product baselines is known at all times. SCM also provides methods for easy monitoring and error and cost reduction, which are applied throughout the lifecycle of the product.
In concept, configuration management refers to the organization and maintenance of software objects. Its objective is to try to control the evolution of software in a way that preserves the integrity of the system. Configuration management provides two primary advantages. First, it maintains the integrity of configuration items. Second, it allows for the rational evaluation and performance of change. SCM also gives the company’s top-level managers and policymakers direct input into the evolution of a company’s information and communication technology (ICT) assets. Configuration management does this by involving the appropriate person to make a concrete decision about the form of the product. Also, SCM provides a basis to measure quality, improve the entire software development and maintenance cycle, make testing and quality assurance (QA) easier, remove error-prone steps from product release management, provide traceability of related components, and dramatically ease change management and problem-tracking challenges.
Configuration management requires the involvement of three major elements in the software lifecycle process: development, which supports the identification process; configuration management itself, which supports authorization and configuration control; and software quality assurance (SQA), which supports verification. The latter two functions are the cornerstones of the process because they define the structure that assures that the configuration of the product is accurately known at a given time.
Publishing and Dissemination Controls
Like any other product moving within a conventional supply chain, software components have to be transported from place to place. Whether the activity involves disseminating the completed product to a number of customers, or simply moving a component up the supply chain ladder for integration, the challenge lies in executing that transfer in a safe and secure fashion. Since software is both intangible and abstract, it is difficult to ensure its integrity. Thus, specific publication and dissemination controls have to be created in order to specifically ensure that software products and components move from one supply chain entity to another in an “as built” state. That includes the utilization of specific integrity controls to ensure that the software was not modified in transition from supplier to acquirer. In addition, the receiving party has to have assurance that the product or component is not a counterfeit.
The most obvious control to assure a trusted relationship is the product license. Licenses certify that the product is authentic. They protect the supplier in that they brand the product as theirs. Licenses protect the acquirer in that they underwrite trust based on the supplier’s reputation for security. However, since most of the actual product transfer in the industry takes place electronically, a license alone is not sufficient to ensure trust. Nonrepudiation of origin controls has to be built into the dissemination process to ensure that all of the endpoints in the transfer are authenticated and that the artifact itself was not altered by a “man-in-the-middle” style exploit. Encryption is the most common solution to that challenge. However, fundamental authentication and access control technologies are also an important part of the dissemination process. Digitally signed components public key transfer, checksums, or other nonrepudiation techniques are the most common approach to assuring package correctness. The encrypted package can be further protected by attaching contextual metadata such as sender location and timestamps. The overall aim in all of this is to ensure that the dissemination is authentic using nonrepudiation methods.
System-of-systems Integration
Large systems are composed of a highly complex set of integrated components. These components can be integrated into a system-of-systems arrangement to perform some particular dedicated function, such as theater control for the military or high-performance computing in a research lab. In all cases, the aim of system-of-systems integration is to produce synergy from the linkage of all of the components. Obviously, the linkage of a distributed set of concurrent processing systems into a single synergistic system-of-systems arrangement requires a high degree of coordinated engineering and management effort.
System-of-systems arrays are not specifically supply chain issues, in that they do not involve classic movement up and down a supply chain ladder. However, the component systems of that array are integrated from smaller components, and the system of systems itself involves a complex interoperability concern. So it is in the integration itself that the rules for proper supply chain risk management become relevant. And in that respect, the issues of assurance of integrity in the upward integration and assurance of concurrent processing effectiveness are the same for systems of systems as they are for products that evolve from a simple supply chain.
Since ensuring concurrent interoperability is at the heart of system-of-systems assurance, the primary responsibility for achieving the necessary synergy falls within the domain of system engineering. That domain is primarily concerned with methods for identifying and characterizing, conceptualizing, and analyzing system-of-systems applications. That analysis is supported by abstract modeling techniques such as continuous system modeling, agent-based modeling, and Unified Modeling Language (UML). The practical outcome of that conceptual modeling is then guided by the standard principles for proper design of any system, such as abstraction, modularity, and information hiding. These principles apply to system-of-systems integration control from the component level all the way up to architectural and data-based design.
Software Authenticity and Integrity
In many respects, the issues that apply to software authenticity and integrity assurance are the same as those for publishing and dissemination. As the components of a product move through the supply chain, they have to be authenticated at the interface between the different supply chain elements and their integrity assured. Although integrity checking is probably a continuous process throughout the production of any given artifact, the authentication normally takes place at the interface between two levels or organizations in the supply chain process.
Authentication follows the same standard principles for nonrepudiation of origin as any other access control activity. At the physical level, the endpoints have to authenticate to each other and man-in-the-middle possibilities have to be eliminated. Endpoint authentication is a classic issue that has been addressed by numerous conventional software protocols, such as Kerberos. At the electronic level, the authenticity of the package is confirmed by any number of digital signing organizations (certificate authorities), such as a public key infrastructure (PKI) certificate authority, or specialized checksums, hashes, and other mathematical tools for obtaining irrefutable proof of authenticity.
Determining the level of integrity of a component is always a problem since there are so many ways that integrity can be threatened. Generally, all of the common secure software assurance methods apply to integrity checking, such as targeted bench checks, static and dynamic tests, audits, and reviews. However, there is a special case with counterfeiting. Counterfeits passed up a supply chain from unscrupulous suppliers can threaten the integrity of the entire system, and since those components are meant to emulate the legitimate part, they are hard to spot by conventional means. Anticounterfeiting methods include trusted foundry vetting and other forms of direct supplier control. However, all of these approaches are in their infancy.
Product Deployment and Sustainment Controls
Product deployment and sustainment controls fall into the general domain of the configuration management process. In concept, configuration management refers to the organization and maintenance of software objects. Its objective is to try to control changes made to the software in a way that preserves the integrity of the system. Configuration management provides two primary advantages. First, it maintains the integrity of configuration items. Second, it allows for the rational evaluation and performance of change. Also, SCM provides a basis to measure quality, improve the entire software development and maintenance cycle, make testing and QA easier, remove error-prone steps from product release management, provide traceability of related components, and dramatically ease change management and problem-tracking challenges.
Configuration management incorporates two processes: configuration control and verification control. These are implemented through three interdependent management activities that are fitted to the needs of each project: change process management, which is made up of change authorization, verification control, and release processing; baseline control, which is composed of change accounting and library management; and configuration verification, which includes status accounting to verify compliance with specifications.
Configuration management is a strategic process. The cornerstone of configuration management is the configuration identification scheme. This scheme is a prerequisite for configuration management because it sets up the “day one” baseline. As such, it is usually established during the requirements analysis phase of the specification process. All components are identified and uniquely labeled. These are arrayed based on their interrelationships and dependencies, and represent the basic structure (configuration) of the software. It must be noted here that the decisions that determine this configuration are made outside configuration management, usually in development. However, precisely defined baselines are absolute prerequisites, since once established, the identification scheme is maintained throughout the lifecycle. Change occurs when new baselines are created through the promotion or release process. If the items in the evolving structure represent a new baseline, the identification labeling is modified to reflect this.
Monitoring and Incident Management
An incident is any event that disrupts normal operating conditions. Incidents can range from user errors, to power disruptions, to malicious activity. The role of incident management is to maintain the incident response capability of the organization over time. The general incident response process encompasses a set of logical monitoring, analysis, and response activities. The incident response management function integrates these activities into a substantive and appropriate response to each adverse event as it happens. Incident response management ensures that any potentially harmful occurrence is first identified and then reported and the response fully managed.
An incident response is initiated by the detection of an event that the organization deems harmful. The incident response process is then set in motion through a formal incident reporting process. Incident reporting ensures that every potentially harmful event gets an organizationally sanctioned response. In that respect then, effective incident reporting relies on the presence of a well-established monitoring function that provides the most timely incident identification possible. In a supply chain, the goal of incident identification is to distinguish the presence of a potential violation, such as a software defect, or even a breakdown in functioning, such as a service breakdown in a supplier. The monitoring techniques that are used to ensure timeliness can range from reviews and inspections of supply chain components all the way through the use of automated intrusion detection systems (IDSs) or intrusion prevention systems (IPSs) that function similar to malware and virus-checking scans.
The incident response management process applies to both foreseen and unforeseen events. The only difference in the execution of the process is in whether the actual steps to mitigate the incident were planned in advance. For example, most supply chains have specific procedures in place to respond to common types of breakdowns. The actual substantive response is deployed based on the type of incident. For instance, the detection of a piece of malicious code in a component will merit a different response than if the component was unavailable due to a breakdown in the supply chain. Because there are only so many ways that a supply chain disruption can occur, it is possible to anticipate critical points in the process and have an effective response waiting in the wings. In that respect, the presence of a predefined work-around will ensure a timely and generally appropriate response to any number of common occurrences.
However, since malicious code is, by definition, unanticipated, the response will depend on the form of the attack, and that cannot be specifically foreseen. Proper practice requires the actual reporting of any new occurrence be submitted to a single central coordinating entity for action. Central coordination is necessary because new attacks do not usually present themselves in a single neat package. Instead, a series of suspicious occurrences take place that represent the signature of an impending incident. Thus, a single organizational role that is responsible for analysis has to be established to ensure that the incident is effectively analyzed. Once the nature of the incident is understood, the coordinator ensures that the right people are notified, who can then make a decision about how to respond.
Vulnerability Management, Tracking, and Resolution
Vulnerability management has two parts to it. The first part involves the actual identification and repair of flaws in a supply chain component, such as a code module. In this case, the process is leveraged by the inspections, tests, and audits that are part of the overall software assurance process. These can take place at any point in the process, and they are usually called out in the contract for the work. From a supply chain perspective, inspections, tests, and audits should always be done at the point where the artifact transitions from one organization or level to the next within the supply chain hierarchy.
The second part of vulnerability management involves the patching of vulnerabilities once they have been identified. As we said in an earlier section, this patching normally occurs after the product has transitioned from the supplier to the customer. Patching is necessary because software products are incredibly complex and so flaws are bound to be present in any deliverable. A well-organized and disciplined patching process can help prevent exploits against known vulnerabilities. However, the key lies in the term “disciplined.” Patches have to be issued in a timely fashion, and they have to be applied when received. If this is not done, it is possible to have incidents like the SQL Slammer virus, where the patch had been issued but many users had not gotten around to applying it.
All patching and repair solutions have to be planned and tracked. A well-defined level of control is necessary in order to ensure timely and effective management of the resolution process. Because supply chains function at multiple levels, the ability to identify the exact point in the supply chain where a fix has to be applied is not as simple as it seems. All of the appropriate places up and down the supply chain ladder have to be targeted, and all of the components within those places altered or repaired. Therefore, all vulnerability management activity within a supply chain has to be placed under some form of coordinated, usually single, supervision.
Supplier Transitioning
As mentioned, the components of a supply chain transition from supplier to supplier. In the transition process, small components move up the integration ladder from developer to integrator as the product moves from a low level of preparation to its final form. That transitioning raises a wide range of concerns that have to be addressed in a transitioning plan. First and foremost is the issue of assuring component integrity at the interface between organizations or levels.
The only place where this assurance can be addressed is in a detailed transitioning plan, which is normally captured as part of the contract. Without a detailed and comprehensive plan, errors and malicious objects likely will transition through the cracks in an ad hoc inspection process into major product vulnerabilities at the point of delivery.
Another point of concern that has to be addressed in detail in the contract is the issue of intellectual property rights. Because small parts are integrated into large systems through the supply chain process, it is possible for the intellectual property of smaller suppliers to get lost in the products of larger integrators further up the ladder. Worse, it is also possible for components that would represent a copyright violation, or even outright piracy, to transition into a product from lower levels in the supply chain.
The management controls that are embedded in a formal transition plan have to account for every one of the things that could potentially go wrong in moving from one entity or level to another. Thus, transition plans include how to label and baseline individual components and how to maintain them in escrow in a project archive in order to protect ownership rights. Plans also include the testing, review, and audit methods that will be employed to ensure that the components that move from one entity or level to another transition as built and maintain contractual requirements for integrity. Finally, transition plans describe the process by which certification of correctness and authenticity will be underwritten and granted for each individual component in the overall product baseline.
Chapter Review
In this chapter, you were acquainted with the role of supply chain risk management and the activities of its many facets. You learned that supply chain risk management is a set of well-defined activities that ensure the requisite level of integrity of a given product or service. You learned that there have to be activities in place to ensure that every individual product passing between each individual node in the supply chain hierarchy is correct and properly integrated with all other components up and down the supply chain production ladder.
You learned that assuring correctness and integrity requires formal risk assessments at every stage in the process. Those risk assessments identify specific threats to the supply chain and underwrite specific strategies to ensure trust up and down the overall supply chain. Supply chain threats fall into five generic categories and each category has distinctly different implications for product integrity: installation of malicious logic in hardware or software, installation of counterfeit hardware or software, failure or disruption in the production or distribution of a critical product or service, reliance on a malicious or unqualified service provider for the performance of a technical service, and installation of unintentional vulnerabilities in software or hardware.
You also learned that supplier risk assessments support supplier sourcing decisions. Supplier sourcing decisions involve all of the analysis that is needed to understand every aspect of the supplier’s operation while making any sourcing decision. That analysis can embrace decisions about everything from code reuse to intellectual property protection and regulatory compliance. All of these factors, and many others, can potentially impact the integrity of the product as it moves from development to long-term sustainment. The processes and practices for each of these areas were discussed in the remainder of this chapter, and they currently define proper practice in assuring integrity in outsourced and purchase situations.
Quick Tips
• Perform a supplier risk assessment for all potential suppliers prior to engaging in any contractual relationship for a product.
• Ensure that common coding errors are mitigated, but also check for functions that you don’t expect to be there, such as malicious code, when performing a risk management exercise.
• Ensure desired practices by locking them into a contract. Every desired consideration and response has to be stipulated in the contract in order to ensure their performance.
• Don’t forget post-delivery assurance, particularly patch management. The process of retrospectively assuring product integrity through patches and fixes is a critical part of good supply chain risk management practice.
• Configuration management is perhaps the most important conventional process in the assurance of continuing supply chain integrity. That is because configuration management establishes product baselines and ensures rational change as the product evolves over time.
Questions
To further help you prepare for the CSSLP exam, and to provide you with a feel for your level of preparedness, answer the following questions and then check your answers against the list of correct answers found at the end of the chapter.
1. The general aim of software reuse is to:
A. Control change
B. Assure product integrity
C. Leverage production and quality
D. Ensure a secure configuration through reuse
2. Supplier prequalification is built on:
A. Performance of prior work
B. Performance criteria that are established in advance by the customer
C. Testing supplier knowledge
D. The capability maturity model
3. Intellectual property protection is a problem for software because:
A. Software is very complex
B. Software is property that can’t be described
C. Software is property that can’t be valued
D. Software is intangible property
4. Code-level tests in a supply chain are always assured by:
A. A contract-based plan
B. Dynamic black-box tests
C. Random audits
D. Separation of duties
5. The steps in the security testing process should map to and reflect:
A. The principles of Saltzer and Schroeder
B. Organizational policies
C. Defense in depth
D. Legal compliance requirements established by the government
6. Vulnerability management has a post-delivery focus that is called:
A. Patching
B. Certification
C. Authentication
D. Validation and verification
7. Security testing controls should evaluate all of the technical, process, and:
A. Cybersecurity risks
B. Nonrepudiation risks
C. Confidentiality, inspection, and authentication risks
D. Resourcing risks
8. Supplier transitioning concerns focus on the:
A. Code level
B. Interface level
C. Design level
D. Acceptance level
9. Incidents are of two types:
A. Active and passive
B. Foreseen and unforeseen
C. Planned and tracked
D. Destructive and nondestructive
10. Product deployment and post-release assurance requires:
A. Secure coding
B. Object-oriented management
C. Problem resolution
D. Configuration management
11. Software authenticity requires controls to ensure:
A. Hashing and checksums
B. Good coding practice
C. Nonrepudiation of origin
D. Denial of service
12. Vendor integrity control is built around ensuring that all subcontractors know:
A. Who is boss
B. All of the other participants up and down the supply chain
C. Their own precise contractual requirements
D. Mutual authentication procedures
13. Testing requires a set of contractual criteria to judge:
A. Successful execution of the test
B. Whether the vendor can be trusted
C. The focus and scope of the testing
D. Successful completion of the acceptance audit
14. In terms of risk, all outsourcing decisions should be based on:
A. Price and performance
B. The known capability of the supplier
C. Where the supplier is located
D. The timing of the delivery process
15. It should be possible to state in advance what actions a subcontractor will:
A. Be paid for and which are optional
B. Be forced to test and review
C. Do and alternatively not do
D. Underwrite through audits
Answers
1. C. This is the defined purpose of the reuse process.
2. B. Supplies must satisfy assessment criteria derived from a predetermined profile.
3. D. Software is intangible property, so it must be labeled and deemed to have tangible value.
4. A. All code-level tests have to be defined and enforced in a contract.
5. B. All project testing should reflect and underwrite organizational policies.
6. A. Patching normally occurs after the product has transitioned from the supplier to the customer.
7. D. Although technical and process risks are important, the level of assurance is almost always dictated by available resources.
8. B. Because it controls passing from one entity to another, transitioning almost always involves an interface concern.
9. B. Foreseen incidents can be planned for; unforeseen incidents require a defined response.
10. D. Configuration management is the cornerstone of post-release management.
11. C. Software can only be authenticated if its origin can be confirmed.
12. C. Subcontractor control is built around all parties in the supply chain understanding their precise contractual requirements.
13. A. Criteria to judge the successful execution of the test have to be made explicit.
14. B. Supplier capability is one of the primary factors that govern risk.
15. C. It is almost more important to define in advance what actions a supplier is not permitted to perform.
..................Content has been hidden....................
You can't read the all page of ebook, please click here login for view all page.