Pillars of Cyber Risk as Competitive Advantage: Enabling Enterprise Resilience & Cyber Security Assurance through Software Supply Chain Management

Transcription

1 Pillars of Cyber Risk as Competitive Advantage: Enabling Enterprise Resilience & Cyber Security Assurance through Software Supply Chain Management OMG Cyber Risk Summit

2 Pillars of Cyber Risk as Competitive Advantage: Enabling Enterprise Resilience & Cyber Security Assurance through Software Supply Chain Management Cyber Risk Governance Analytics & Accuracy Transparency Real Value of Assets Speed & Flexibility Culture Leadership Alignment Structure & Systems

3 Top 20 Global Software Companies 1 Microsoft 2 Oracle 3 SAP 4 Symantec 5 VMware 6 Salesforce 7 Intuit 8 CA Technologies 9 Adobe 10 Teradata 11 Amdocs 12 Cerner 13 Citrix 14 Autodesk 15 Sage Group 16 Synopsys 17 Akamai Technologies 18 Nuance 19 Open Text 20 F5 Networks $2,000 $1,500 $1,000 $500 $- Synopsys Financial Snapshot 2015 Revenue: $2.242B Global Reach #1 global market leader in Electronic Design Automation (EDA) #2 in Semiconductor IP Engineering Culture Total Employees: ~10,000 Engineers: 50% Software Integrity Group: ~500 From Silicon to Software

4 Gaining confidence in ICT/software-based technologies Dependencies on software-reliant Information Communications Technology (ICT) are greater then ever Possibility of disruption is greater than ever because software is vulnerable and exploitable Loss of confidence alone can lead to stakeholder actions that disrupt critical business activities Railway Systems Transportation Vehicles Highway Bridges Pipelines Ports Cable and Fiber Control Systems SCADA PCS DCS Services Managed Security Information Services Agriculture and Food Energy Transportation Chemical Industry Postal and Shipping Software Life-essential Systems Business Systems Financial Systems Human Resources.. Cyber Infrastructure Water Public Health Telecommunications Banking and Finance Key Assets Critical Infrastructure / Key Resources Reservoirs Treatment plants Farms Food Processing Plants Hospitals Power Plants Production Sites Physical Infrastructure Logic-baring Hardware Database Servers Networking Equipment Internet Domain Name System Web Hosting Financial Institutions Chemical Plants Delivery Sites Nuclear power plants Government Facilities Dams Cyber Infrastructure is enable and controlled by software

5 Physical and Cyber Security Are Fundamentally Different Vulnerabilities Are Deeply Hidden Very hard to find even with sophisticated tools and methods Small change of code or configuration can open new security holes Anytime Persistent Risk Attacks Can Be Done Remotely Network access sufficient to attack from anywhere in the world Very difficult to trace Impossible to prosecute Anyone Lone Wolf or Nation State Attacks Can Be Automated Single vulnerability in widely shared software can be exploited everywhere at the same time by automation Example All traffic lights in a city disabled at the same time Massive Largescale Attack 5

6 An ever-more connected world... Goods & Services Track materials Speed distribution Product feedback People Wellness monitoring Medical case management Social needs Communities Traffic status Pollution alerts Infrastructure checks Environment Pollution checks Resource status Water monitoring Homes Utilities control Security monitoring Structure integrity

7 Cyber Risks and Consequences in IoT Solutions Edge Devices (including Applications, Sensors, Actuators, Gateways & Aggregation) Device Impersonation and Counterfeiting Device Hacking Snooping, Tampering, Disruption, Damage IoT Platform (Data Ingestion/Analytics, Policy/Orchestration, Device/Platform Mgmt) Platform Hacking Data Snooping & Tampering Sabotaging Automation & Devices Enterprise (Business/Mission Applications, Business Processes, etc) Business/Mission Disruption Espionage & Fraud Financial Waste

8 Growing Concern with Internet of Things (IoT) Lax security for the growing number of IoT embedded devices in appliances, industrial applications, vehicles, TVs, smart homes, smart cities, healthcare, me dical devices, etc. Sloppy manufacturing hygiene is compromising privacy, safety and security incurring risks for faster time to market IoT risks provide more source vectors for financial exploitation IoT risks evolving from virtual harm to physical harm Cyber exploitation with physical consequences; Increased risk of bodily harm from hacked devices

9 Safety/Security Risks with IOT embedded systems Engineering Community concerns: Poorly designed embedded devices can kill; Security is not taken seriously enough; Proactive techniques for increasing safety and security are used less often than they should be. Barr Group: Industry is not taking safety & security seriously enough Based on results of survey of more than 2400 engineers worldwide to better understand the state of safety- and security-aware embedded systems design around the world (Feb 2016).

10 Shifting Business Concerns: Increased Software Liability 1980 s 1990 s 2000 s 2010 s Standalone Software Apps Internet & WWW Software Controlled Devices Quality Quality / Security Quality / Security / Safety & Privacy Financial Liability

11 Software Integrity / Supply Chain Risk Management Imperative Increased risk from supply chain due to: Increasing dependence on commercial ICT for enterprise business/mission critical systems Increasing reliance on globally-sourced ICT/software & services Varying levels of development/outsourcing controls Lack of transparency in process chain of custody Varying levels of acquisition due-diligence Residual risk passed to end-user enterprise Defective and Unauthentic/Counterfeit products Tainted products with malware, exploitable weaknesses and vulnerabilities ICT services lacking adequate security controls Growing technological sophistication among our adversaries Internet enables adversaries to probe, penetrate, and attack remotely Supply chain attacks can exploit products and processes throughout the lifecycle

12 Risk Management (Enterprise Shared Processes & Practices Project): Different Focuses Enterprise-Level: Regulatory compliance Changing threat environment Business Case Program/Project-Level: Cost Schedule Performance Who makes risk decisions? Who determines fitness for use for technically acceptable criteria? Who owns residual risk from tainted/counterfeit products? * Tainted products are those that are corrupted with malware, or exploitable weaknesses & vulnerabilities

13 Office of Management and Budget (OMB) Circular A-130, Revised July 28, 2016, specifies six specific requirements directly related to improving agencies supply chain risk management (SCRM) capabilities 1. Consider supply chain security issues for all resource planning and management activities throughout the system development life cycle; 2. Analyze risks (including supply chain risks) associated with potential contractors and the products and services they provide, for all IT acquisitions; and 3. Allocate risk responsibility between Government and contractor when acquiring IT. 4. Develop, implement, document, maintain, and oversee agency-wide information security and privacy programs; 5. Implement supply chain risk management principles to protect against the insertion of counterfeits, unauthorized production, tampering, theft, insertion of malicious software, as well as poor manufacturing and development practices throughout the system development life cycle; 6. Develop supply chain risk management plans as described in NIST SP (SCRM Practices) to ensure the integrity, security, resilience, and quality of information systems.

14 NIST SP SCRM Plan Flow Chart (Acquisition)

15 Blind spot: Emerging Threat from Cyber Supply Chains 19% of CIOs are not concerned about supply-chain risks Only 42% of respondents consider supplier risks 23% do not evaluate third parties at all Most companies do not have a process for assessing security of third-party partner capabilities before they do business with them 2015 US State of Cybercrime Survey

16 Assurance Required for Gaining Confidence and Trust Managing Effects of Unintentional Defects in Component or System Integrity Managing Consequences of Unintentional Defects Quality TRUST Safety Security Managing Effects and Consequences of Attempted/Intentional Actions Targeting Exploitable Constructs, Processes & Behaviors

17 Enterprises Have Used Reactive Technologies to Defend They are good; designed for known threats. What about broader risks to enterprises and users? Enterprises cannot stop the threats; yet can control their attack vectors/surfaces

18 Security Feature Cross-site Scripting (XSS) Attack (CAPEC-86) Improper Neutralization of Input During Web Page Generation (CWE-79) SQL Injection Attack (CAPEC-66) Improper Neutralization of Special Elements used in an SQL Command (CWE-89) Exploitable Software Weaknesses (CWEs) are exploit targets/vectors for future Zero-Day Attacks 19

19 Software-related Expectations for 2016 Major breaches will be enabled by unpatched known vulnerabilities over 2 years old; Chained attacks and attacks via third-party websites will grow; Vulnerable web applications will remain easiest way to compromise companies; SQL Injection and XSS will constitute more frequent and dangerous vector of attacks; Third-party code and plug-ins will remain the Achilles heel of web applications; Server misconfigurations will continue to be a top source of vulnerability; Many vulnerabilities will be exploited in devices and systems that cannot be patched; Most software will be composed third party & open source (often unchecked) components; o Primary causes of exploited vulnerabilities will be software defects, bugs, & logic flaws; o Application logic errors will become more frequent and critical; Mobile apps will constitute a growing source of attack vectors, especially since many (in rush to release) won t be adequately tested for known vulnerabilities prior to use; More network-connectable devices in the Internet of Things will have exploitable weaknesses and vulnerabilities publicly reported because of consumer risk exposures.

20 US DHS CIO Enterprise Services reported: 21 92% of vulnerabilities are in application layer not in networks (NIST) Over 70 % of security breaches happen at the Application (Gartner) Insufficient Application Security testing Often only done at the end of all development; security is often, at best, bolted on not built in Most developers lack sufficient security training If only 50% of software vulnerabilities were removed prior to production, costs would be reduced by 75 % (Gartner) 90% of a typical application is comprised of open source components 58.1 million components with known vulnerabilities were downloaded from (maven) repository 71 % of applications have a critical or severe vulnerability in their open source components This causes a Software Supply Chain Issue Data breaches exploit vulnerabilities in applications with root causes in unsecure software Source: US Department of Homeland Security CARWASH program presentation to interagency Software & Supply Chain Assurance Forum, Dec 2014

21 90% of all reported security incidents result from exploits against defects in software

22 Software Supply Chain Assurance Focus on Components Mitigating risks attributable to tainted, exploitable non-conforming constructs in ICT software Tainted products are corrupted with malware, and/or exploitable weaknesses & vulnerabilities that put enterprises and users at risk Enable scalable detection, reporting and mitigation of tainted ICT/software components Leverage related existing standardization efforts Leverage taxonomies, schema & structured representations with defined observables & indicators for conveying information: o Tainted constructs: Malicious logic/malware (MAEC), Exploitable Weaknesses (CWE); Vulnerabilities (CVE) o Attack Patterns (CAPEC) Leverage catalogued diagnostic methods, controls, countermeasures, & mitigation practices Use publicly reported weaknesses and vulnerabilities with patches accessible via National Vulnerability Database (NVD) sponsored by DHS; hosted by NIST UNAUTHENTIC / COUNTERFEIT Exploitable weakness TAINTED [exploitable weakness, vulnerability, or malicious construct] Unpatched Vulnerability Malware Exploitable weakness Unpatched Vulnerability AUTHENTIC Malware DEFECTIVE Components can become tainted intentionally or unintentionally throughout the supply chain, SDLC, and in Ops & sustainment *Text demonstrates examples of overlap International uptake in security automation standards via ITU-T CYBEX 1500 series

23 Exploitable Weaknesses, Vulnerabilities & Exposures Weakness: mistake or flaw condition in ICT architecture, design, code, or process that, if left unaddressed, could under the proper conditions contribute to a cyber-enabled capability being vulnerable to exploitation; represents potential source vectors for zero-day exploits -- Common Weakness Enumeration (CWE) Vulnerability: mistake in software that can be directly used by a hacker to gain access to a system or network; Exposure: configuration issue of a mistake in logic that allows unauthorized access or exploitation Common Vulnerability and Exposure (CVE) Exploit: take advantage of a weakness (or multiple weaknesses) to achieve a negative technical impact -- attack approaches from the set of known exploits are used in the Common Attack Pattern Enumeration and Classification (CAPEC) The existence (even if only theoretical) of an exploit designed to take advantage of a weakness (or multiple weaknesses) and achieve a negative technical impact is what makes a weakness a vulnerability. VULNERABILITIES CVEs (reported, publicly known vulnerabilities and exposures) WEAKNESSES Unreported or undiscovered Vulnerabilities Zero-Day Vulnerabilities (previously unmitigated weaknesses that are exploited with little or no warning) Uncharacterized Weaknesses CWEs (characterized, discoverable, possibly exploitable weaknesses with mitigations) CVE, CWE, & CAPEC are part of the ITU-T CYBEX 1500 series & USG SCAP

24 ITU-T X.1500 series: structured cybersecurity information exchange techniques X.1500 Overview of cybersecurity information exchange X.1520 Common vulnerabilities and exposures (CVE) X.1521 Common vulnerability scoring system (CVSS) X.1524 Common weakness enumeration (CWE) X.1525 Common weakness scoring system (CWSS) X.1526 Language for open definition of vulnerabilities and for assessment of a system state X.1528 Common platform enumeration (CPE) X CPE naming /.2 CPE name matching /.3 CPE dictionary /.4 CPE applicability language X.1541 Incident object description exchange format X.1544 Common attack pattern enumeration and classification (CAPEC) X.1546 Malware attribute enumeration and characterization (MAEC) X.1570 Discovery mechanisms in the exchange of cybersecurity information X.1580 Real-time inter-network defence X.1581 Transport of real-time inter-network defence messages X.1582 Transport protocols supporting cybersecurity information exchange

25 Security Automation Pipework Making Security Measureable measurablesecurity.mitre.org CVE enabling reporting and patching of vulnerabilities CWE identifying and mitigating root cause exploitable weaknesses CybOX cyber observables and supply chain exploit indicators CAPEC schema attack patterns and software exploits

26 CVE & CWE Can Be Used to Assess Software Maturity Are the commercial and open source applications being used as part of the system, the development environment, the test environment, and the maintenance environment to detect CWEs/CVEs and patched for known CVEs? Are any components/libraries incorporated in the system that have CVEs? Have pen testing tools/teams found any CVEs? Does the project team monitor for Advisories? Do projects utilize CVSS/CWSS scores to prioritize remediation efforts? Is the use of CWE and CVE Identifiers and public advisories a consideration when selecting commercial and open source applications? CVE & CWE are some of the means for sharing information about risk exposures in software supply chain management

27

28 Assurance: Mitigating Attacks That Impact Operations Known Threat Actors Attack Patterns (CAPECs) Weaknesses (CWEs) Controls* System & System Security Engineering Trades Technical Impacts Operational Impacts Attack Weakness Item Impact Asset Attack Weakness Item Impact Function Attack Weakness Asset Impact Weakness Item * Controls include architecture choices, design choices, added security functions, activities & processes, physical decomposition choices, code assessments, design reviews, dynamic testing, and pen testing See NIST SP Systems Security Engineering, Appendix J Software Security and Assurance (2 nd draft released May 2016

29 Software Today Is Assembled Software Development Supply Chain SW development process Part Original Part Third Party SW components

30

31

32

33 Compilation date for the oldest 3rd party component is Apr, /2/2008 7/2/ /2/2008 1/2/2009 4/2/2009 7/2/ /2/2009 1/2/2010 4/2/2010 7/2/ /2/2010 1/2/2011 4/2/2011 7/2/ /2/2011 1/2/2012 4/2/2012 7/2/ /2/2012 1/2/2013 4/2/2013 7/2/ /2/2013 1/2/2014 4/2/2014 7/2/ /2/2014 1/2/2015 4/2/2015 7/2/ /2/2015 Unique known vulnerabilities ( CVEs ) Software decays over time without patches Software released circa Aug Total of 22 unique CVEs affecting total of 2 unique 3 rd party components when the software was released. None of these had CVSS score of 10. Same software in Feb Total of 582 unique CVEs affecting total of 60 unique 3 rd party components. 74 of these had CVSS score of Commercial product Released in Feb 2010 Leverages total of 81 3 rd party components Near clean bill of health on release New vulnerability affects one of products components on average every 5 days 7 years later product should no longer be considered safe to use Challenge: Many products are delivered with unpatched, known vulnerabilities

34 Implications for Leading Network Equipment Manufacturer 400 new products a year 99% of all the products use Open Source 60% of all the code is Open Source 69% of all security defects are from Open Source (post release) Average defect age: 441 days 10% of high visibility vulnerabilities originate from open source

35 Taking Action Software and applications have to ship. That is the bottom line. Organizations need software to do things, often unaware of the risk; sometimes regardless of the risk. Organizations need to signoff on security, and will do so regardless of the veracity of their information. True cybersecurity assurance means having a signoff process that enables advancement in technologies and ultimately product features, rather than expending too many cycles reacting to big security challenges.

36 Addressing Security of 3rd Party Software SDLC App Testing Protocol and policy testing Software Composition Analysis Procurement language Source: FS-ISAC 3 rd Party Software Security Working Group

37 Growing Challenges in Software Development Agile & Faster Speed Development Continuous integration and deployment Increased agility Fast response to malfunction and security incidences Operate at high velocity Multiple Sources Combined Code is more assembled than developed Outsourced development Use of open source components Reuse of older code Track disparate sources Organizational Inertia Lack of knowledge of modern tools/languages/frameworks Opposition to limit development freedom" Legacy flows and tools - NIH ("Not Invented Here ) Change culture and process

38 Who Should Be Testing and Why? Who: All Stakeholders In The Supply Chain Why: Because all stakeholders are affected by failures in cyber security (but in different ways). At some point someone (usually the end user) has to validate and verify. However, not all links in the chain are as well-suited to perform testing.

39 Some Prioritized Lists To Consider Not Exhaustive But A Good Start SANS CWE Top 25 A list of top 25 most commonly encountered Cyber Weakness Enumerators (CWEs), found in ( Object Management Group (OMG) Automated Source Code Security Measure (ASCSM) TM v1.0, 2016 at January-2016.pdf -- A list of top-22 code-level CWEs OWASP Top 10 Vulnerabilities A list of Most Critical Web Application Security Risks compiled by OWASP ( includes CVEs & CWEs Verizon Report Top 10 CVEs List of most commonly encountered Common Vulnerabilities & Exposures (CVEs) used in exploits ( )

40 Take Advantage of the Multiple Detection Methods Different assessment methods are effective at finding different types of weaknesses Some are good at finding the cause and some at finding the effect Static Code Analysis Penetration Test Data Security Analysis Code Review Cross-Site Scripting (XSS) X X X SQL Injection X X X Architecture Risk Analysis Insufficient Authorization Controls X X X X Broken Authentication and Session X X X X Management Information Leakage X X X Improper Error Handling X Insecure Use of Cryptography X X X Cross Site Request Forgery (CSRF) X X Denial of Service X X X X Poor Coding Practices X X

41 Types of Automated Tools/Testing What They Find; How They Support Origin Analysis & Risk Management Dynamic Runtime Analysis Finds security issues during runtime, which can be categorized as CWE s Malformed input testing (fuzz testing, DoS testing) Finds zero-days and robustness issues through negative testing. Behavioral analysis Finds exploitable weaknesses by analyzing how the code behaves during normal runtime. Software Composition Analysis Finds known vulnerabilities and categorizes them as CVE s and other issues. Static Code Analysis Finds defects in source code and categorizes them as CWE s. Known Malware Testing Finds known malware (e.g. viruses and other rogue code). These tests can be used to enumerate CVE s, CWE s, and malware which can be further categorized into prioritized lists.

42 Synopsys Software Integrity Group Built Through Acquired Products & Technology 5D992/G157185* 5D992/G161908* 5D002/G161908* 5D992/G161908* 5D992/G166851* 5D992/G164231* Code Adviso r Quality & Security Issues AppCheck Bill of Materials Vulnerability AbuseSA Situation Analysis Defensics Protocol Fuzzing Seeker Dynamic Security Testing Protecode 3rd Party License Compliance March 2014 June 2015 July 2015 November 2015 ACQUISITION TIMELINE * ECCN / CCATS#

43 Synopsys Software Integrity Platform Signoff for Software Development Signoff for Supply Chain Management PRODUCTS Coverity Defensics Protecode Seeker Abuse SA Static Analysis Protocol Fuzzing Software Composition Analysis Interactive Application Security Testing Threat Situational Awareness PLATFORM Reporting Bug tracking integration Workflow integration IDE plugins & Test Advisory SCM integration

44 Structured Threat Information expression (STIX)

45 AbuseSA Seeker Defensics Coverity Protecode

46 Kill Chain Exploit Targets Courses of Action Using Structured Threat Information expression (STIX) Why were they doing it? Why should you care about it? What exactly were they doing? What you are looking for Where was it seen? Who was doing it? What were they looking to exploit? What should you do about it?

47 Kill Chain Exploit Targets Courses of Action Using Structured Threat Information expression (STIX) Why were they doing it? Why should you care about it? What exactly were they doing? What you are looking for What could/should have been done to harden the attack surface/vector Where to was prevent it seen? the target from being exploitable? Who was doing it? What were they looking to exploit? What should you do about it?

48 Developers and consumers of software and systems falsely assume security is an upstream responsibility, bearing the risk of an unchecked cyber supply chain - Tamulyn Takamura, Marketing analyst

49 Software Composition Analysis is Needed Because Code Travels Free Open Source Software (FOSS) under GPL, AGPL, MPL, Apache and other licenses Out-dated, vulnerable code Commercial off the shelf (COTS) 3 rd party code Outsourced code development Copy - paste code Unauthorized, potentially malicious and counterfeit code First party code Floodgate Software Signoff Sea of downstream businesses that use software from upstream

50 What Software Composition Analysis Finds Looks at compiled code and determines what third-party (or proprietary) components it is built from. Queries databases of known vulnerabilities for identified components and lists them out. Finds CVEs. Can automatically track vulnerabilities in a software package over time. Leverage CVSS to prioritize mitigation since not all identified vulnerabilities are necessarily exposed. CVSS v3 now available.

51 What Software Composition Analysis (SCA) Provides: Components of Software Composition Analysis (SCA) solution: Securing Software Through Software Composition Analysis (SCA): Vulnerability assessment and tracking [FOSS] license management and export compliance Software Bill of Materials (BOM) identification and management

52 Software Ingredient List (Bill of Materials) Simply knowing software ingredients or code genetics arms a user with an enormous resource for determining risk.

53 Comprehensive Software Composition Analysis (SCA) Scan and Report Components with Known Security Vulnerabilities Development Teams Detect and manage 3rd party and open source components or portions thereof Software Composition Analysis (SCA) Solution Ensure Licensing, IP, and Export Control Compliance The versatility and breadth of this solution makes it viable for many use cases and appealing to many personas IT

54 Supply Chain Cyber Assurance Procurement Requirements Source: Financial Services Sector Coordinating Council for Critical Infrastructure Protection and Homeland Security Product Development Specification and Policy Security Program System Protection and Access Control Product Testing and Verification Communication Robustness Testing Software Composition Analysis Static Source Code Analysis Dynamic Runtime Analysis Known Malware Analysis Bill of Materials Validation of Security Measures Deployment and Maintenance

55 Strengthening Our Nation s Cybersecurity The Department of Homeland Security is collaborating with UL and other industry partners to develop a Cybersecurity Assurance Program to test and certify networked devices within the Internet of Things, so that when you buy a new product, you can be sure that it has been certified to meet security standards. Issued February 9 th, 2016

56 UL Cybersecurity Assurance Program UL Cybersecurity Assurance Program (UL CAP) will be Product Oriented & Industry Specific with these goals: Reduce software vulnerabilities Reduce weaknesses, minimize exploitation Address known malware Increase security awareness Product service offerings apply to: Connectable Products Products Eco-Systems Products System Integration UL : Organizational Process UL , -2-2: Industry Specific Requirements UL : CAP General Requirements/ Critical IT Infrastructure Integration

57 Signoff for Software Development Software Signoff Signoff for Supply Chain Management Product Release Feature Readiness Compile & Build Code Check-in Introducing test gates in the SW development process Release criteria Agile feature acceptance Required for successful build Required for code check-in Introducing test gates in the SW delivery process Legal compliance Regulatory compliance Industry compliance Best practices compliance

58 Ingredients of Software Signoff Technologies Static Code Analysis Software Composition Analysis Malformed Input Testing IAST Automated Test Optimization Best-in-class solutions Methodology SDLC Integration Workflow automation Third party certification Internal policy enforcement International standards compliance Fully integrated into existing workflows People Training Engineering Security assessment Vulnerability remediation SSDLC Tailored solutions

59 The Benefits of Software Signoff CEO Risk Management Accountability Competitive Advantage Security VP Risk Management Compliance Accountability R&D VP/Manager Predictability Quality Cost Management Developer Efficiency Quality Predictability Purchasing Cost Management Compliance Quality Legal Compliance Risk Management Accountability

60 Software Supply Chain Management Software is no longer written, it is being assembled. Testing is required to understand risk exposures attributable to tainted components in software. Enterprises look for vulnerabilities at the time they build and deploy their software; yet most security vulnerabilities emerge, enabling exploitation at a later point in time as software decays. Software Composition Analysis (SCA) provides a high level impact in security, liability and risk mitigation almost instantly for its adopters; it reduces the risk introduced by inclusion of third-party and open source software and components. Software Signoff at various phases of software lifecycle provides a secure, safe and risk-free experience.

61 Pillars of Cyber Risk as Competitive Advantage: Enabling Enterprise Resilience & Cyber Security Assurance through Software Supply Chain Management Cyber Risk Governance Analytics & Accuracy Transparency Real Value of Assets Speed & Flexibility Culture Leadership Alignment Structure & Systems

62 Pillars of Cyber Risk as Competitive Advantage: Enabling Enterprise Resilience & Cyber Security Assurance through Software Supply Chain Management OMG Cyber Risk Summit