Project 4: System Development or Application Assurance Start Here It is critical that cybersecurity professionals be able to use all applicable systems, tools, and concepts to minimize risks to an org
Project 4: System Development or Application AssuranceStart Here It is critical that cybersecurity professionals be able to use all applicable systems, tools, and concepts to minimize risks to an organization’s cyberspace and prevent cybersecurity incidents. In this project, you will demonstrate your understanding of how to apply security principles, methods, and tools within the software development life cycle. You will also apply your knowledge of the cybersecurity implications related to procurement and supply chain risk management. This is the fourth and final project for this course. There are 13 steps in this project. Begin below to review your project scenario. Transcript Competencies Your work will be evaluated using the competencies listed below. 1.1: Organize document or presentation clearly in a manner that promotes understanding and meets the requirements of the assignment. 1.5: Use sentence structure appropriate to the task, message and audience. 2.4: Consider and analyze information in context to the issue or problem. 9.4: Software Security Assurance: Demonstrate secure principles, methods, and tools used in the software development life cycle. 9.5: Software Security Assurance: Describe the cybersecurity implications related to procurement and supply chain risk management. Step 1: Assess Software Vulnerabilities Project 2 outlined the steps involved to produce a final vulnerability and threat assessment, and Project 3 covered risk analysis and mitigation. Those assessments were across the entire enterprise and included numerous elements outside the realm of systems and technology. However, they did uncover opportunities for improvement in the application software processes. For this step, return to the vulnerability and threat assessment from Project 2 and focus on all areas of application software that were itemized. Give additional thought to uncover software that perhaps did not make the list or were assumed to be secure and simply overlooked. The assignment is to create a more comprehensive list of application software that could place the enterprise at risk of a breach, loss of data, loss of production, and/or loss of brand confidence. The assessment should include the application of secure principles, development models such as the maturity model or integrated product and process development (IPPD), software development methods, libraries and toolsets used in the software development life cycle or systems development life cycle. Use the Software Vulnerability Assessment Template to submit your results for feedback. Submission for Project 4: Software Vulnerability Assessment Previous submissions 0 Top of Form Drop files here, or click below. Add Files Bottom of Form In the next step, you will review your organization’s software procurement policy.  Step 2: Review Software Procurement Policy Upon completion of the software specific vulnerability assessment, conduct a review of the organization’s software procurement policies for software development methods. Note that there is no submitted assignment for this step. Your review will be used in the submission for the following steps. When the review is complete, move to the next step, where you will create a table or spreadsheet that lists recommended policies for software procurement that address certain questions or concerns. Step 3: Create a Software Procurement Policy List You’ve reviewed the organization’s policies for software development methods. Now it’s time to create a policy list for software procurement. The following are some sample questions to be included in a software procurement policy: Does the vendor provide any cybersecurity certifications with the product? Does the vendor provide access to the source code for the product? Are there other security issues in source code to be addressed? What is the guaranteed frequency of security updates to be provided for the product? What is the implementation process for software updates/upgrades? What are additional questions or concerns that should be included in the procurement process? Create a table or spreadsheet that lists recommended policies to properly address these questions or concerns. Use the Procurement Policy Template to list the cybersecurity implications related to procurement and supply chain risk management and submit your results for feedback. Submission for Project 4: Procurement Policy List Previous submissions 0 Top of Form Drop files here, or click below. Add Files Bottom of Form In the next step, you will generate assurances or controls to address each of the policy issues identified here. Step 4: Document Relevant Software Acceptance Policies Now that the procurement policies have been identified in the previous step, what assurances or controls should be established as policy that would evaluate the security implications during the software acceptance process? The objective is to provide a one-page overview of security testing that would be included in the acceptance of a vendor’s application. The next step in this project will document the actual testing and validation. This step is simply to verify the congruence between the procurement process and acceptance process. In other words, do the procurement policies establish the correct cyber security framework for software purchase and do the acceptance policies match? In considering the security implications of the in the software acceptance phase of the development cycle, use the Software Acceptance Policy Template to document recommended tests and assurances for the procurement policies identified in the previous steps. Submit your results below for feedback. Submission for Project 4: Software Acceptance Policy Previous submissions 0 Top of Form Drop files here, or click below. Add Files Bottom of Form In the next step, you will research software testing and validation. Step 5: Research Software Testing and Validation Procedures Based on the software acceptance policies created in the previous step, consider what testing and validation procedures could be used to assure compliance. Note that there is no submitted assignment for this step. You will submit the final list of recommended testing and validation procedures in the next step. Step 6: Document Software Testing and Validation Procedures You’ve completed the research, and it is now time to create testing and validation procedures that follow a specific process to assure compliance. The key to the success of this step is to document exact procedures to be followed by a testing team prior to installation. At a minimum, the procedures should address the following questions: What are potential vulnerabilities inherent in the application platform? How well does the vendor document preventive measures built into the application? Are there alternative solutions provided by the vendor or in the application in case of a breach? What additional safeguards can be added to ensure the security of the software environment? The testing and validation procedures should address each of these concerns. The executive team will want to see specific steps for the testing team to follow as the team members complete the tests and assurances you recommended in the previous step. Document your specific testing and validation recommendations from a cybersecurity policy standpoint in the Test Script Procedures Template and submit for feedback. Submission for Project 4: Test Script Procedures Previous submissions 0 Top of Form Drop files here, or click below. Add Files Bottom of Form In the next step, you will consider procedures for upgrading software. Step 7: Review Software Upgrade Procedures In the last step, you documented testing and validation requirements. In this step, it’s important to review software upgrades. Installation of a software upgrade has similar, yet unique requirements from the previous steps. In most enterprise environments, software updates and upgrades follow a specific change management routine. However, complete reliance on this procedure can lead to unintended oversight of cybersecurity issues. The change management process is generally focused on detecting errors and the auditing and logging of changes in the operational environment after the upgrade has been performed. From the cyber perspective, this is not enough. As demonstrated in previous steps, significant effort is required to ensure a secure environment, not just an operational one. The question to be answered is “when” should the upgrade be performed during an application or system change. Should it be performed multiple times during the update? Think through this issue thoroughly and make notes on your thought process. It is important that the risk analysis associated with an application or system change is conducted at the optimal time. Note that there is no submitted assignment for this step. However, the research and corresponding notes related to this step will be applicable to the final report for Maria and the other executives. When this is complete, move to the next step, where supply chain risks will be considered. Step 8: Review Supply Chain Risks Following the previous steps relative to the supply chain and previous projects, it is time to thoroughly review risk within the supply chain. Like many companies, your organization is dependent on a supply chain, so the software development process must include a supply chain risk management (SCRM) plan to minimize the impact of supply chain-related risks on business operations and the security of the infrastructures and data. Note that there is no submitted assignment for this step. The identified supply chain risks will be reported in the next step. Step 9: Document Supply Chain Risks After review, it’s time to document supply chain risks. This portion of the overall report requires a two- to three-page narrative that addresses the following supply chain concerns: Describe cybersecurity implications related to the procurement process. Provide recommendations that would address these concerns. Include appropriate supply chain risk management practices. Where appropriate, cite references to support the assertions in the recommendations and conclusion. Submit your report on supply chain concerns here for feedback. Submission for Project 4: Supply Chain Cyber Security Risk Report Previous submissions 0 Top of Form Drop files here, or click below. Add Files Bottom of Form Then, move to the next step, in which you will consider how the procedures of acquisition, procurement, and outsourcing line up in the organization. Step 10: Consider Alignment Issues Based on the review and recommendations on the supply chain described in the previous step, consider how well the policies and procedures regarding the acquisition, procurement, and outsourcing of software in your organization are aligned. Outline a strategic approach to getting all the functions in alignment. There is no submission for this step. The alignment recommendations will be submitted in the next step. Step 11: Develop an Acquisition Alignment Report Keeping the alignment issues in mind from the previous step, prepare a one-page plan to align acquisition, procurement, and outsourcing of software applications for the enterprise. This should be a strategic approach to getting all the functions in alignment. Start with a request for information, proceed through acquisition, testing, and implementation, and finish with ongoing maintenance of the application. All the work has been done in the previous steps. This step is designed to “bring it all together” in one easy-to-understand approach. The approach will be used in the final step to complete the supply chain analysis with a mitigation plan as it applies to software acquisition and maintenance. Submit your one-page plan to align acquisition, procurement, and outsourcing efforts with your organization’s information security goals here for feedback. Submission for Project 4: Acquisition Alignment Report Previous submissions 0 Top of Form Drop files here, or click below. Add Files Bottom of Form In the next step, you will consolidate all your work thus far. Step 12: Consolidate Your Work The acquisition plan alignment is complete. For this exercise, collate all the material presented in the previous steps into a cohesive presentation that describes the entire software risk analysis processes and articulates specific supply chain cybersecurity threats and the technologies and policies that can be used to mitigate them. You will use your consolidated results in your final project submission in the next step. Project 4: System Development or Application AssuranceStep 13: Write the Risk Analysis/Supply Chain Threats/Mitigation Report Management is always interested in solutions, and Maria Sosa and the other executives at your company are no exception. In the case of cybersecurity, there are no absolute solutions to an ever-changing environment. However, there are steps to mitigation that might eliminate or minimize the results of certain vulnerabilities. This final step is to describe the mitigation strategies recommended as a result of all previous steps in the project. The final report for the executive meeting should be five to seven pages, only one to two of which will have to be written in this step. The remainder is from all the previous steps in the project. Use the Supply Chain Risk Mitigation Final Report Template to submit your specific testing and validation procedures. Check Your Evaluation Criteria Before you submit your assignment, review the competencies below, which your instructor will use to evaluate your work. A good practice would be to use each competency as a self-check to confirm you have incorporated all of them. To view the complete grading rubric, click My Tools, select Assignments from the drop-down menu, and then click the project title. 1.1: Organize document or presentation clearly in a manner that promotes understanding and meets the requirements of the assignment. 1.5: Use sentence structure appropriate to the task, message and audience. 2.4: Consider and analyze information in context to the issue or problem. 9.4: Software Security Assurance: Demonstrate secure principles, methods, and tools used in the software development life cycle. 9.5: Software Security Assurance: Describe the cybersecurity implications related to procurement and supply chain risk management. Submission for Project 4: Supply Chain Risk Mitigation Final Report Previous submissions 0 Top of Form Drop files here, or click below. Bottom of Form
Project 4: System Development or Application Assurance Start Here It is critical that cybersecurity professionals be able to use all applicable systems, tools, and concepts to minimize risks to an org
The Software Environment The software environment includes processes, languages, security features, and development models that together deliver security, flexibility, and functionality. Security is paramount in software environments, as it can assure the integrity of the software, ensure that the software performs as designed, and can audit and log software modifications. Object-oriented components, processes, and systems are geared toward objects and data. “Object-oriented (OO) technology has emerged in recent years as the clear choice for developers of large, dynamic applications. OO technology allows developers to encapsulate data and operations in units called objects. Each object is independent of others, and groups of objects cooperate to solve specific problems” (Cobb & Shaw, 2000). Examples include object-oriented security, object-oriented security, and object-oriented programming. Software development environments include open source and off-the-shelf. An open-source environment involves software development conducted collaboratively by multiple independent entities. While the rights to the resultant software may be owned by a single entity, the source code continues to be made available for editing through licenses. The benefits of open source include the potential for enhanced and more diverse creativity. Security is a concern with open source; however, proponents of open source argue that with a diverse set of contributors, the likelihood of finding malicious code is increased in the open-source environment. Still, there is a strong open-source community comprised of experts and volunteers who advocate for open development and collaboration. By contrast, off-the-shelf software is generally proprietary software that is developed, owned, and controlled by one entity, which also solely develops new features and tests for security. While configuration control is generally not at issue, cost, requirements, and security remain areas that must be carefully considered. Additionally, owners/developers of proprietary software are generally limited in the resources available to address bugs or security issues, potentially delaying the development of patches and increasing the potential for vulnerabilities to be exploited. References Cobb, M., & Shaw, K. (2000). Distributed object-oriented systems. http://www.scpe.org/index.php/scpe/article/view/175 Security Issues in Source Code The security issues of source code depend on a number of factors, including the integrity of the processes used to develop the source code from a perspective of human practices as well as the development environment itself. Source code is susceptible to many of the same threats that exist for networks and operating systems, including the use of malware to corrupt and/or exploit the source code. There are controls that can be used to minimize threats to source code security. Such controls include having sufficient backup procedures so that prior versions of code are retained, and separating environments to protect the source code by isolating its development. Security controls that can be used for source code development include process isolation and memory protection, which segregate processes and storage for enhanced protection. Password protection techniques can be used to reduce the potential for the exploitation of passwords. Such techniques can include the requirements for the frequency of password changes, password length and composition, and layers of access with appropriate password controls. Sandboxing, or isolating source code development to a stand-alone environment, protects both the development of the source code itself as well as the involvement of other network assets in any security issues. Ultimately, there are a number of adequate security controls for source code. Software Development Methodologies Many organizations engage in the software development process, from manufacturers of major software packages, to companies implementing commercial off-the-shelf software (COTS), to custom, in-house development. To be successful, a company must use a standard software development methodology, especially in an environment where software security—injected in all phases of the project—is so important. These standard processes are traditionally called software development methodologies, or software development life cycles. There are numerous methods used in developing software. Waterfall, rapid application development, joint application development, and extreme programming are some of the common methodologies used today. With software security concerns, even more methodologies are advancing in this arena. Nevertheless, within these major categories, there are variations that fit a company’s needs. Many life cycle models have been built upon the traditional waterfall model framework, while some newer models differ greatly. The waterfall model is extensively used in practice, particularly in the development of large enterprise software systems. The other models vary in implementation cost, end-user involvement, and project implementation time.  The rapid application development (RAD) model and the joint application development (JAD) model have similar approaches. JAD is mainly a methodology, where system users, analysts, designers, and software developers are working together to specify the components of the new system. They use many techniques, including meetings, workshops, and retreats to define and design the system. These techniques are highly structured based on best practices in JAD processes, and the group meetings can be held over extended periods. Maturity Model Maturity models are used to standardize development to ensure consistency. In cybersecurity, a software assurance maturity model helps organizations with the development and implementation of a software security strategy. This process involves an assessment of the organization’s needs, resources, and risk tolerance as well as providing a benchmark against comparable organizations. A maturity model has a set of structured levels to describe the reliability and sustainability of the outcomes of an organization’s practices, behaviors, and processes. Thus, maturity models facilitate the assessment of an organization’s processes and methods, promote consistency, and provide an independent review. Capability Maturity Model: An Introduction In addition to using international standards to evaluate their information technology (IT) products, organizations also follow international standards to manage and improve their own performance and capabilities. The Capability Maturity Model (CMM) comprises five levels through which each organization must progress to achieve optimum performance or capability when developing secure software (International Quality Management Systems, n.d.): Level 1: Initial. Apply workforce practices without analyzing their impact. Level 2: Managed. Get managers to take responsibility for managing and developing their employees. Level 3: Defined. Develop workforce competencies and workgroups and align with business strategies. Level 4: Predictable. Empower and integrate workforce competencies. Manage progress through a defined set of metrics. Level 5: Optimizing. Continuously monitor and improve performance. CMM is the benchmark for comparing the software development processes of two or more organizations. Working Through Capability Maturity Model Levels What follows is how a typical medium-sized company might strive to accomplish the CMM Level 5 certification. Level 1: Initial At this level, the organization has not started any formalized methodology. When it decides on a formalized methodology for developing secure software, such as CMM, it moves to the second level. Level 2: Managed At this level, the organization ramps up the training, working environment, and personnel needed to begin the secure software development life cycle. For example, the organization might initiate training on secure coding practices and training for auditors to show them how to document and evaluate information assets. Managers then create working environments, in which breakout groups are asked to work on individual aspects of the formalized methodology. For example, an organization might create an auditing group, a secure coding group, a project management group, and departmental leadership groups. Level 3: Defined In this level, the organization further defines its methodology by breaking out its personnel into more focused and specific working groups, developing best practices and creating a culture in which the staff participates in the program to increase their investment in the outcome. The secure coding group, for example, could be further divided into secure coding for databases, secure coding for web servers, and secure coding for network administrators. The groups then develop best practices for how they will communicate among each other and share/report information, along with best practices for securely coding customer databases and web servers at the subgroup level. Level 4: Predictable At this level, the organization’s processes are stable and established in ensuring secure coding. Leaders mentor the staff, and the individual working groups—which now have a deep knowledge of the processes and in-depth frontline experience—are empowered to make their own decisions, such as deciding whether to use a different coding protocol on a customer database based on several small issues on the database. Performance management is also put into place. The organization identifies a benchmark and establishes metrics to measure progress toward reaching that goal. These metrics are also used to monitor the progress of all teams in the organization. Level 5: Optimizing At this level, the organization finally optimizes its process, adapting it to new challenges and continuing to monitor and improve it regularly to ensure continued excellence. Review Of the following tasks, consider what level of the Capability Maturity Model (CMM) each would be performed by an organization. monitor progress through established metrics create best practices and workgroups formalize a methodology to improve processes organize the personnel needed to establish workgroups Monitor Progress Through Established Metrics The organization puts performance management policies in place that allow it to monitor progress at CMM Level 4. Create Best Practices and Workgroups At CMM Level 3, the organization further defines its methodology by developing best practices, breaking out personnel into more focused and specific working groups, and creating a culture in which the staff participates in the program to increase investment in the outcome. Formalize a Methodology to Improve Processes The organization starts to formalize a methodology to move to Level 2 during CMM Level 1. Organize the Personnel Needed to Establish Workgroups At CMM Level 2, the organization ramps up the training, working environment, and personnel needed to begin the secure software development life cycle. References International Quality Management Systems. (n.d.). People capability maturity model (PCMM). http://www.iqmsglobal.com/people_cmm.html Integrated Product and Process Development (IPPD) Integrated Product and Process Development (IPPD) is a management process that begins with product concept development and extends through the development and fielding of a product. The focus of IPPD is optimizing both the product as well as associated processes (e.g., manufacturing and maintenance) while at the same time meeting cost and performance targets. Among the key principles of IPPD are (DoD, 1998; DRM Associates, 2016): customer focus concurrent development of products and processes early and continuous life cycle planning proactive identification and management of risk maximum flexibility for optimization and use of contractor approaches event-driven scheduling multidisciplinary teamwork empowerment integrated management tools IPPD is a widely accepted and used process including in the US Department of Defense. Advantages realized from the use of IPPD include a reduction in product delivery time, production costs, organizational risk, and increased focus on value to the customer (Management Study Guide, 2017). References Department of Defense (DoD). (1998, August). DoD integrated product and process development handbook. https://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=3&cad=rja&uact=8&ved=0ahUKEwi_v4_O1OzRAhVFTCYKHfrEDrQQFggjMAI&url=http%3A%2F%2Fwww.acq.osd.mil%2Fse%2Fdocs%2FDoD-IPPD-Handbook-Aug98.pdf&usg=AFQjCNHGyIdZBreb4VBgv9xpS5LsdaxNgw&bvm=bv.145822982,d.eWE DRM Associates. (2016). Integrated product and process development key tenets. http://www.npd-solutions.com/ippdtenets.html Management Study Guide. (2017). Integrated product and process development – meaning, advantages and key factors. http://www.managementstudyguide.com/integrated-product-and-process-development.htm Software Development Methodologies Many organizations engage in the software development process, from manufacturers of major software packages, to companies implementing commercial off-the-shelf software (COTS), to custom, in-house development. To be successful, a company must use a standard software development methodology, especially in an environment where software security—injected in all phases of the project—is so important. These standard processes are traditionally called software development methodologies, or software development life cycles. There are numerous methods used in developing software. Waterfall, rapid application development, joint application development, and extreme programming are some of the common methodologies used today. With software security concerns, even more methodologies are advancing in this arena. Nevertheless, within these major categories, there are variations that fit a company’s needs. Many life cycle models have been built upon the traditional waterfall model framework, while some newer models differ greatly. The waterfall model is extensively used in practice, particularly in the development of large enterprise software systems. The other models vary in implementation cost, end-user involvement, and project implementation time.  The rapid application development (RAD) model and the joint application development (JAD) model have similar approaches. JAD is mainly a methodology, where system users, analysts, designers, and software developers are working together to specify the components of the new system. They use many techniques, including meetings, workshops, and retreats to define and design the system. These techniques are highly structured based on best practices in JAD processes, and the group meetings can be held over extended periods. Libraries and Toolsets Libraries and toolsets are important to develop and test software programs. Software libraries are made up of suites of data and programming code that can be used to develop software programs and applications. The libraries are developed to help programmers build and execute software. An example of a library is a runtime library, which is used during the execution of a program to implement functions that are developed in a programming language. Toolsets are collections of tools available for developing, compiling, and testing software. An example of a toolset can be found in the integrated development environment (IDE), where basic tools needed by developers to write and test software are consolidated. Software Development Life Cycle The software development life cycle (SDLC) defines the steps needed to develop and maintain software through its usefulness. This process is initiated during the software design phase and focuses on quality development standards that result in timely and cost-effective delivery against requirements. Security analysis and testing is an important component of the development cycle and should be considered through every step of the SDLC, which includes the following phases: analysis, requirements document, design and prototype, implementation (coding), testing and release, and maintenance. While SDLCs historically were focused on satisfying functional requirements through software development processes, the increase in cyberattacks has resulted in adding the integration of security into each phase of the SDLC. System Development Life Cycle System development life cycle (SDLC) is a multistep process used to develop, implement, and decommission information systems, to include both hardware and software components. The purpose of using an SDLC approach is to deliver systems that meet customer requirements within the projected cost and schedule parameters.  SDLC steps include: planning requirements design development integration and testing implementation operations and maintenance decommissioning There are a number of different SDLC models that cater to different types of developments. Among the oldest models is the waterfall model, which is a structured model with phases that are followed sequentially. While this model is easy to understand and follow, it has limited flexibility, providing little opportunity to make changes once a phase is completed. In contrast, the agile model produces iterative releases which include product testing after each release. While this model relies significantly on interaction with customers, it is a flexible and realistic SDLC model.
Project 4: System Development or Application Assurance Start Here It is critical that cybersecurity professionals be able to use all applicable systems, tools, and concepts to minimize risks to an org
Supply Chain Cyber Resilience: Creating an Agenda for Future Research Resilience is all about being able to overcome the unexpected. Sustainability is about survival. The goal of resilience is to thrive. Jamais Cascio,Writer and futurist specializing in design strategies Abstract Supply chains have become more vulnerable in recent years, and high-profile cyberattacks that have crippled the supply chains of well-known companies reveal that the point of entry for hackers is often through the weakest link in the chain. Exacerbated by growing complexity and the need to be visible, these supply chains share vital streams of information every minute of the day, thereby becoming an easy and highly lucrative target for talented criminals, causing financial losses as well as damaging brand reputation and value. Companies must therefore invest in supply chain capabilities to withstand cyberattacks (i.e., cyber resilience) in order to guard against potential threats. They must also embrace the reality that this often unknown dimension of risk is the “new normal.” Although interest on this topic has grown in the business world, less has been reported by the academic community. One reason for this could be the convergence of two different disciplines, information technology and supply chains, where supply chain cyber risk and cyber resilience appear to have a natural fit. The topic of cyber resilience in supply chains is still in early stages of development, and this is one of the first journals to focus a special issue on it. Currently, the closest academic literature is within the realms of supply chain risk and resilience, where numerous models and frameworks exist. In this article, this literature is explored to identify whether these models can incorporate the dimension of cyber risk and cyber resilience. In doing so, we create a research agenda for supply chain cyber resilience and provide recommendations for both academia and practice. Introduction Supply chain management has become dependent on electronic systems; since the 2000s, we have seen the emergence of information technology solutions to support business operations, to share information, to connect businesses, and to generate greater visibility along supply chains in order to gain knowledge and control of processes. On the other hand, although supply chains have pursued aspects such as the standardization of business processes, increased communication, connectivity, and data exchange, the vulnerability of these systems to cyberattacks is nevertheless increasing. Why is this? In modern supply chains, information is shared digitally more than any other way, and supply chains are so reliant on good quality information that without it supply chain managers cannot make decisions on forecasts, production, distribution, etc. Equally importantly, poor data leads to poor decisions and performance. So even with the most efficient and responsive supply chain, performance will be greatly compromised without good quality information. For supply chains to thrive, managers must recognize that cyberattacks are becoming common occurrences and that the “new normal” operating environment is one that is increasingly affected by unknown risks. A key lesson for supply chain managers is that cyberattacks do not always “come through the front door”; a business can be greatly affected by an attack on the weakest link in their supply chain. A key difficulty with cyberattacks is that often a business will not know the types of cyber risks to which it has exposure, until it realizes that it is being attacked. Therefore, businesses must develop cyber-resilience to protect their supply chains. Cyberattacks can cause considerable economic costs to the companies that suffer these breaches, although the costs may not be noticed until after the damage is done. Estimates of the annual costs from cybercrimes range from $375 billion to $575 billion (Intel Security, 2014), with significant effects on supply chains and resulting business performance with customers. Missing or erroneous data and information in supply chains, as a result of cyberattacks, can lead to undesirable effects as diverse as intellectual property breaches, substandard or interrupted operations, sensitive data custody breaches, and decreases in service level to final customers. For example, some estimates indicate annual losses of £9.2 billion from the theft of intellectual property and a further £7.6 billion from industrial espionage. Businesses that are able to understand what data is critical, where it is, who has access to it, and who is responsible for it, as well as where potential risks are in terms of information and data in the supply chain, are those that will be able to correctly communicate these risks to the supply chain in order to implement actions to mitigate them. However, there has been a lack of managerial action to acknowledge the relevance and impact of cybercrime (Burnson, 2013; Deloitte, 2012, 2013). It has been stated that “only a few CEOs realize that the real cost of cybercrime stems from delayed or lost technological innovation” (Bailey et al., 2014) and companies have likely underestimated their risk (Intel Security, 2014). This is, either by delayed decision making or by a lack of awareness, the resulting inaction is leading to higher organizational costs from cybercrimes. This inaction is compounded by the increasing complexity of global supply chains and the speed and connectivity of operations required by companies to stay competitive. Furthermore, the growing skill of the attackers to find novel ways of accessing crucial data (Reuters, 2012), and the limited information and tools available to manage these threats, requires organizations to be more resilient to cyberattacks that can cripple their supply chains. Companies can prepare for potential attacks by applying appropriate supply chain risk-management tools and techniques both to reduce the likelihood of an intrusion and to deal with any disruption should an attack be successful. Every business that depends on a supply chain needs to build in cyber-resilience. But what exactly is cyber-resilience in the context of supply chains, and how can it be incorporated into current supply chain risk-management approaches? Cyber risk has been defined by the Institute for Risk Management (IRM, 2015) as “any risk of financial loss, disruption or damage to the reputation of an organization from some sort of failure of its information technology systems.” The ISO 27005:2008 defines information security risk as “the potential that a given threat will exploit vulnerabilities of an asset or group of assets and thereby cause harm to the organization” (BSI, 2008). Both of these terms are being widely used in industry, and this article will consider these terms as equivalent. We define supply chain cyber resilience “as the capability of a supply chain to maintain its operational performance when faced with cyber risk.” In light of the above challenges, the purpose of this article is to create an agenda for future research that could help supply chain and IT personnel to recognize and take a proactive team-based approach to supply chain cyber resilience. More specifically, the aims of this study are to: Explore current supply chain risk and resilience frameworks Analyze these frameworks and determine whether they incorporate cyber risk Create a research agenda for cyber risk and cyber resilience. The remainder of this article is structured as follows. First, the process used to find and review the key literature is explained. Next, the main findings of the literature review are discussed. Finally, a research agenda for supply chain cyber resilience is proposed, including recommendations for both academia and industry. Methodology A systematic literature review was conducted, based on documented guidelines (Tranfield et al., 2003) through which a comprehensive, explicit, and reproducible method is followed. This method consists of 10 steps that can be grouped into five main phases: 1. Planning: The planning phase focused on defining a review question to guide the search: “Do the current supply chain risk and resilience frameworks incorporate cyber risk?” 2. Searching: The searching phase was guided by the identification of the relevant databases where the search was to be done, the keywords to be used during these searches, and the appropriate timeframe for the resulting documents to be included in the research. We searched for literature using the following databases: Scopus, Web of Science, ProQuest, and Google Scholar. The search keywords were determined from a knowledge domain analysis around the concept of cyber-resilience for the supply chain (see figure below). The three main knowledge domains to be scanned were identified as “supply chain management,” “information technology management,” and “risk (and resilience) management.” 3. Screening: After the initial, broad literature search was carried out, we conducted a preliminary analysis of the document titles and abstracts, if available. This step was followed by a more detailed analysis of the document abstracts, in the case of papers, and extended content in other cases. We applied explicit inclusion and exclusion criteria (e.g., document type, themes covered, research approaches) to identify a refined selection of documents for this analysis. Finally, the references of this refined set of articles were reviewed to identify relevant documents that might not have been identified through our initial broad search. Our final list consisted of 213 documents (24 articles, 137 peer-reviewed journal papers, 51 reports by specialized agencies, and 1 thesis). The documents covered the areas of supply chain risk management (131 documents), supply chain cyber risk management (SCCRM), and information technology risk management (44 documents), ranging from the years 1998 to 2015. 4. Extracting and synthesizing: The documents were analyzed and synthesized using a spreadsheet format that allowed us to categorize the documents according to methodological approaches, contexts, outcomes, etc. 5. Reporting: In the next section, we report on our findings from the literature review. Findings Some of the earliest evidence of supply chain resilience can be found in the work of Christopher and Peck (2004), which was derived from earlier research on supply chain agility as a way of counteracting for uncertainty in the demand (Christopher & Towill, 2001). This perspective emerged after the foot-and-mouth disease event in the United Kingdom and the 9/11 terrorist attacks in United States, both of which occurred in 2001. Christopher and Peck proposed a reference model for the characterization of resilience in the supply chain, and the main aspects contributing to supply chain resilience were identified as reengineering, organizational culture, agility, and collaboration. Sheffi and Rice (2005) presented a disruption model based a proposed disruption theory for production systems (Asbjornslett, 1999), where this model was represented as a transient decrease in process performance. The Sheffi and Rice model identified eight sequential phases describing a disruption event: preparation, disruptive event, first response, initial impact, time of full impact, preparation for recovery, recovery, and long-term impact. Based on this model, Sheffi and Rice propose an enterprise “vulnerability map” through which the different disruption event probabilities and consequences are compared and ranked for prioritization. Sheffi and Rice (2005) also identified product demand as the main source of uncertainty in the supply chain and acknowledged the increase in global uncertainty due to increased customer expectations, more global competition, longer and more complex supply chains, greater product variety, and shorter product lifecycles. They considered organizational resilience as a strategic initiative to reduce vulnerability and therefore reduce the likelihood of occurrence of a disruption. Finally, they identified three important factors for building resiliency in an organization: redundancy, flexibility, and cultural change. A number of other resilience frameworks have been suggested in literature. Linkov and colleagues (2013) proposed a resilience matrix of four steps representing a process for the event management cycles of disruptions: i) plan/prepare, ii) absorb, iii) recover, and iv) adapt. Each of these steps are described for different domains within the organization (i.e., physical, information, cognitive, and social). These authors have further suggested how to measure resilience according to this matrix.Based on the framework proposed by Christopher and Peck (2004) as well as an empirical research study to identify vulnerabilities and capabilities within organizations, Pettit, Fiskel, and Croxton (2010) proposed the supply chain resiliency assessment and management (SCRAM) framework. This framework identifies an active relationship between the capabilities and the vulnerabilities in an organization, and its resulting resilience. They argue that the level of resilience that a company has to aim for is a balance between developing too many vulnerabilities (due to a lack of investment in capabilities), which could result in disruptions with undesirable economic effects, and investing in too many capabilities, which would erode profitability. Hence, they highlight an economic tradeoff between investment (capabilities) and risk (vulnerabilities). Blackhurst, Dunn, and Craighead (2011) proposed a global resiliency framework based on systems theory and the framework proposed by Sheffi and Rice (2005). They distinguish between “resilience enhancers” and “resilience reducers,” which are organizational attributes that either increase or decrease the ability of a firm to recover quickly and efficiently from a disruptive event. They identified 13 resilience enhancers and seven resilience reducers, each within three categories. Their work derives these attributes from an industrial setting and therefore can serve as basis for further research in the empirical confirmation of these or other resilience attributes. The World Economic Forum (WEF, 2013) presented a resilience framework as part of its Supply Chain Risk Initiative. This framework attempts to quantify the risk to an organization’s physical and intangible assets through a combination of effects from the existing risks to the organization and its vulnerabilities. The World Economic Forum’s (WEF, 2013) resilience report also provides four recommendations for organizations to build resilient supply chains: i) put in place strong policies for the creation and adoption of resilience standards; ii) develop agile and adaptable strategies in organizations; iii) use data-sharing platforms for risk identification and response; and iv) enter into partnerships that involve all stakeholders in the risk assessment process. Cyber Risks Within the Supply Chain Resilience Framework Our literature review did not find any supply chain resilience framework that incorporated the phenomenon of cyber risk or information risk explicitly. However, our analysis revealed that the most influential sources for the development of cyber resilience policy are the insurance industry, governmental requirements, and international organizations such as the World Economic Forum. In 2012, the World Economic Forum created an initiative called “Partnering for Cyber-Resilience,” led by Elena Kvochko, as a response to the increasing importance of cybersecurity. With more than 100 organizations involved, this initiative has created a series of reports describing principles for cybersecurity, recognizing interdependence, leadership, integrated risk management, and uptake by partners in the supply chain, as crucial aspects for resilience building. Additionally Kvochko has recently published an initial framework for the measurement of cyberthreats, through the calculation of a cyber risk value and by combining eight factors grouped in three categories: vulnerability, assets, and attacker profile (WEF, 2015). At a government level, there are several initiatives in place concerning cyber risk and cybersecurity. In 2003, the United States government published the “National Strategy to Secure Cyberspace” (White House, 2003), and as part of a wider strategy from the Department of Homeland Security as a response to the 9/11 terrorist attacks and in line with Presidential Directive 63, which provides a framework for the protection of critical infrastructure (White House, 1998). In 2005, Germany started the “National Plan for Information Infrastructure Protection,” with its main objectives being prevention, preparedness, and sustainability of the information infrastructure through the setting of international standards (German Federal Ministry of the Interior, 2005). By 2015, all EU member states except Portugal had published national cybersecurity strategies, with Estonia having been the first in 2008 (ENISA, 2015; Keegan, 2014). In 2013, the United States government released Presidential Policy 21 and Executive Order 13636 to focus national attention on cyberinfrastructure resilience. In particular, Executive Order 13636 establishes a risk-based standard to protect critical infrastructure against cyberthreats. However, standards based on risk assessment do not necessarily create resilience (Linkov et al., 2013). Conclusions and Recommendations Our systematic literature review highlights that there is limited literature and no specific frameworks for cyber resilience in the supply chain, despite the increasing importance of the topic. The main supply chain resilience theories were proposed in the early 2000s, and the main advancements to those theories have been through the empirical identification of organizational attributes that increase or decrease resilience, as well as theoretical relationships between organizational vulnerabilities and capabilities as related to resilience. Additionally, we found that the existing supply chain resilience frameworks could be extended to consider cyber risks through aspects such as cultural change (Sheffi & Rice, 2005) or collaboration and organizational culture (Christopher & Peck, 2004). Cyber resilience theory can also be advanced through the empirical quantification of the cyber resilience of an organization, through case studies and stress testing of organizations with techniques such as noninvasive games (Gerencser et al., 2003). A key contribution of this article is a definition for supply chain cyber resilience: “the capability of a supply chain to maintain its operational performance when faced with cyber risk.” Furthermore, as a result of this study, we offer the following recommendations for academia with the goal of developing a future research agenda for supply chain cyber resilience: Develop theory to demystify cyber risk and cyber resilience in supply chains: Academics should conduct in-depth (systematic) literature reviews that confirm or expand on this study to devise methods of incorporating cyber resilience with existing frameworks in supply chain resilience and indeed develop new models and frameworks. Finally, and fundamentally, they should align supply chain thinking and personnel with information technology issues and personnel to develop a team approach to supply chain cyber resilience. Develop applicable tools and techniques: There is a need for models (e.g., models of dynamic behavior, machine-learning models for real-time monitoring of performance conditions) and practitioner workbooks (e.g., to evaluate the likelihood of detection or the probability of attack) to help practitioners better manage the causes and effects of cyber-risk to the supply chain. Generate case studies: In-depth and longitudinal case studies within different industrial sectors are required to increase our understanding of the occurrence, detection, and reaction to cyberattacks. Such case studies will enable researchers to validate theory and conceptual frameworks and models. Investigate the different types of cyberattacks: Studies should examine the attack goals (e.g., data theft, data modification, data falsification), the technical nature of attacks (e.g., tools, physical or digital barriers, verification procedures, data integrity), as well as human dimensions (e.g., cyberattacker motivation, incentives). Propose strategic ways of managing cyber risks: For example, academia may suggest portfolio investment to hedge risk by diversifying the business structure, where different areas counterbalance the effect of cyberattacks. Furthermore, academia may suggest establishing appropriate key performance indicators or reviewing organizational culture and leadership, which should be empowered for proactive management of supply chain cyber resilience. For industry, we offer the following recommendations: The search for solutions to cyber risks must be approached in terms of distributed accountability, instead of centralized authority: The increasingly complex supply arrangements are creating conditions for “malevolent actors to recruit, coordinate and inflict harm across the whole network” (WEF, 2012). This challenge will require companies to adjust the current paradigm of centrally controlling risk management with routine evaluation processes (Deloitte, 2012). Rearrange resources and develop contingency plans when necessary: Organizations that thrive are those that can quickly recognize unusual operating conditions. It is no longer possible to prepare for every possible threat scenario. Instead, organizations should prepare by encouraging team members to speak up when they detect an anomaly, having strategies in place to create customized contingency plans as necessary, and using automatic detection systems (e.g., machine learning) to identify real-time suspicious variations in performance indicators. There is a need for a new level of coordination in organizations for risk management and security response. In environments with high volatility, central controls are not sufficient and”structural integration is key to addressing uncertainties” (Boyson, 2014). Include recovery costs in the cost evaluation of cyberattacks: Recovery costs can surpass the direct organizational losses from cyberattacks (Ponemon, 2014). Including recovery costs in the evaluations will highlight the real economic implications of delayed action. Create a cyber crisis team within each organization: Such teams should be empowered to work across organizational silos. Collaborate with academic institutions: Academics can assist companies through training programs in cyber resilience, by introducing new tools for the evaluation of cyber resilience, or by providing methods for the real-time monitoring of conditions (e.g., through machine-learning methods) to detect potential threats. Promote a proactive culture: Organizations should provide incentives for early-bird alerts on anomalous operating conditions, which promote flexibility and a proactive response in the face of an unforeseen threat. References Asbjornslett, B. E. (1999). Assess the vulnerability of your production system. Production Planning & Control, 10(3), 219–229. http://dx.doi.org/10.1080/095372899233181 Bailey, T., Del Miglio, A., & Richter, W. (2014). The rising strategic risks of cyberattacks. McKinsey Quarterly, 2 (2014), 17–22. Blackhurst, J., Dunn, K. S., & Craighead, C. W. (2011). An empirically derived framework of global supply resiliency. Journal of Business Logistics, 32(4), 374–391. http://dx.doi.org/10.1111/j.0000-0000.2011.01032.x Boyson, S. 2014. Cyber supply chain risk management: Revolutionizing the strategic control of critical IT systems. Technovation, 34(7), 342–353. http://dx.doi.org/10.1016/j.technovation.2014.02.001 BSI. (2008). BS ISO/IEC 27001:2008 information technology – Security techniques – Information security risk management. London, UK: British Standards Institution. Burnson, P. (2013). Supply chain cybersecurity: A team effort. Supply Chain Management Review, June (2013), 6–8. Christopher, M., & Peck, H. (2004). Building the resilient supply chain. International Journal of Logistics Management, 15(2), 1–14. http://dx.doi.org/10.1108/09574090410700275 Christopher, M., & Towill, D. (2001). An integrated model for the design of agile supply chains. International Journal of Physical Distribution & Logistics Management, 31(4), 235–246. http://dx.doi.org/10.1108/09600030110394914 Deloitte. (2012). Aftershock: Adjusting to the new world of risk management. London, UK: Deloitte Development LLC. Deloitte. (2013). The ripple effect: How manufacturing and retail executives view the growing challenge of supply chain risk. London: Deloitte Development LLC. ENISA. (2015). National cyber security strategies in the world. European Union Agency for Network and Information Security. Retrieved April 1, 2015: http://www.enisa.europa.eu/activities/Resilience-and-CIIP/national-cyber… Gerencser, M., Weinberg, J., & Vincent, D. (2003). Port security war game: Implications for U.S. supply chains. New York, NY: Booz & Company. German Federal Ministry of the Interior. (2005). National plan for information infrastructure protection. Berlin, DE: Bundesministerium des Innern. Intel Security. (2014). Net losses: estimating the global cost of cybercrime. Santa Clara, CA: Intel Security IRM. (2015). Cyber risk and management. Institute for Risk Management. Accessed April 1, 2015: https://www.theirm.org/knowledge-and-resources/thought-leadership/cyber-… Keegan, C. 2014. Cyber Security in the Supply Chain: A Perspective from the Insurance Industry. Technovation, 34(7): 380–381. http://dx.doi.org/10.1016/j.technovation.2014.02.002 Linkov, I., Eisenberg, D. A., Bates, M. E., Chang, D., Convertino, M., Allen, J. H., Flynn, S. E., & Seager, T. P. (2013). Measurable resilience for actionable policy. Environmental Science and Technology, 47(18), 10108–10110. http://dx.doi.org/10.1021/es403443n Pettit, T. J., Fiksel, J., & Croxton, K. L. (2010). Ensuring supply chain resilience: Development of a conceptual framework. Journal of Business Logistics, 31(1), 1–21. http://dx.doi.org/10.1002/j.2158-1592.2010.tb00125.x Ponemon. (2014). 2014 Global report on the cost of cyber crime. Traverse City, MI: Ponemon Institute. Reuters. (2012). Cyber crime – How can firms tackle this fast-emerging invisible menace? London, UK: Thomson Reuters. Sheffi, Y., & Rice, J. B. (2005). A supply chain view of the resilient enterprise. MIT Sloan Management Review, 47(1), 41–48. Tranfield, D., Denyer, D., & Smart, P. (2003). Towards a methodology for developing evidence-informed management knowledge by means of systematic review. British Journal of Management, 14(3), 207–222. http://dx.doi.org/10.1111/1467-8551.00375 WEF. (2012). Risk and responsibility in a hyperconnected world – Pathways to global cyber resilience. Geneva, CH: World Economic Forum. WEF. (2013). Building resilience in supply chains. Geneva, CH: World Economic Forum. WEF. (2015). Partnering for Cyber Resilience: Towards the Quantification of Cyber Threats. Geneva, CH: World Economic Forum. White House. (1998). Presidential decision directive NSC-63 on critical infrastructure protection. Washington, DC: The White House. White House. (2003). The national strategy to secure cyberspace. Washington, DC: The White House. Licenses and Attributions Supply Chain Cyber-Resilience: Creating an Agenda for Future Research by Omera Khan and Daniel A. Sepúlveda Estay from Technology Innovation Management Review is available under a Creative Commons Attribution 3.0 Unported license. © 2007-2018, Talent First Network. UMGC has modified this work and it is available under the original license. © 2021 University of Maryland Global Campus
Project 4: System Development or Application Assurance Start Here It is critical that cybersecurity professionals be able to use all applicable systems, tools, and concepts to minimize risks to an org
Supply Chain Risk Mitigation Final Report Template In this report, use applicable systems, tools, and concepts to minimize risks to an organization’s cyberspace and prevent cybersecurity incidents. Maria and the other executives at your organization will be looking for a final report that applies security principles, methods, and tools to the software development life cycle. They are also seeking your ideas and recommendations concerning any potential cybersecurity implications related to procurement and supply chain risk management. Supply Chain Risk Mitigation Final Report (five to seven pages using this template) The report should include the following components: The headings for the report are: Title Page Include: for whom you are preparing the document, the title, the date prepared, and your name as the preparer of the document Table of Contents with all sections Overview Include: introduction and purpose of the report Software Vulnerability Assessment (one-column table from Step 1) comprehensive list of application software that could present vulnerability concerns Procurement Policy List and Acceptance Procedures (two-column table from Step 3) Policies of concern and specific procedures to test them Testing and Validation Procedures (from Step 6) Include specific testing and validation recommendations Supply Chain Cyber Security Risk (two- to three-page report, Step 9) Include: identified cybersecurity risks in the procurement process of the supply chain concerns and security recommendations. Acquisition Alignment (one-page report: Step 10) Include: recommendations for alignment of the supply chain processes from start to ongoing maintenance Software Risk Mitigation Recommendations (two- to three-page report, Step 12) Include: proposed software risk mitigation recommendations
Project 4: System Development or Application Assurance Start Here It is critical that cybersecurity professionals be able to use all applicable systems, tools, and concepts to minimize risks to an org
Software Vulnerability Assessment Template Application Software that Could Present Vulnerabilities Note: You can add more rows to the bottom of the table if needed.
Project 4: System Development or Application Assurance Start Here It is critical that cybersecurity professionals be able to use all applicable systems, tools, and concepts to minimize risks to an org
Procurement Policy List Template List appropriate procurement policies to address concerns in the process of software evaluation and acquisition. Procurement Policy List Note: You can add more rows to the bottom of the table if needed.
Project 4: System Development or Application Assurance Start Here It is critical that cybersecurity professionals be able to use all applicable systems, tools, and concepts to minimize risks to an org
Software Acceptance Policy Template Copy the policy list from the previous step into the column on the right. In the column on the left, document your recommendations for specific testing steps to address each of the policy concerns. Procurement Policy List Test Script Procedures for Software Acceptance Note: You can add more rows to the bottom of the table if needed.
Project 4: System Development or Application Assurance Start Here It is critical that cybersecurity professionals be able to use all applicable systems, tools, and concepts to minimize risks to an org
Test Script Procedures Template Copy your list from Step 3 into the first column. Procurement Policy Concern Specific Testing Recommendation to Address Each Policy Concern Note: You can add more rows to the bottom of the table if needed.