Supply Chain Update

Tobias Whitney, Principal - Critical Infrastructure Protection, NERC Small Group Advisory Session- Supply Chain WebinarMarch 14, 2018

RELIABILITY | ACCOUNTABILITY2

• Participants are reminded that this meeting is public. Notice of the meeting was posted on the NERC website and widely distributed. Participants should keep in mind that the audience may include members of the press and representatives of various governmental authorities, in addition to the expected participation by industry stakeholders.

• It is NERC’s policy and practice to obey the antitrust laws and to avoid all conduct that unreasonably restrains competition. This policy requires the avoidance of any conduct that violates, or that might appear to violate, the antitrust laws. Among other things, the antitrust laws forbid any agreement between or among competitors regarding prices, availability of service, product design, terms of sale, division of markets, allocation of customers or any other activity that unreasonably restrains competition.

Public Meeting Disclaimer

RELIABILITY | ACCOUNTABILITY3

• Overview of Supply Chain Standards & Board Resolution Tobias Whitney, Principal - Critical Infrastructure Protection, NERC

• NATF Overview of Supply Chain Activities Corey Sellers, Transmission Policy Manager, Southern Company

• Supply Chain Vendor Perspectives Joe Doetzl, Head of Cyber Security, ABB

• Supply Chain Vendor Perspectives Kate Scarcella, Security Solution Tiger Team, IBM

• Supply Chain Vendor Perspectives Ryan Socal, Senior Program Manager, Microsoft

Agenda

RELIABILITY | ACCOUNTABILITY4

Purpose of the Program

Industry Outreach and Technical Guides

Address Supply Chain Compliance Issues

Vendor Coordination & Input

Identify Risks and Assess Standard

Effectiveness

“Support all entities in their timely, effective, and efficient transition to the supply chain standards”

RELIABILITY | ACCOUNTABILITY5

• Background FERC issued Order No. 829 on July 21, 2016 NERC Board Approved the Standard in August 2017 Standard filed in September 2017

• Status Final ballot ended July 20, 2017o CIP-013-1 – 84.2%o CIP-005-6 – 88.8%o CIP-010-3 – 81.4%

Cyber Security Supply Chain Standard

RELIABILITY | ACCOUNTABILITY6

CIP-013-1

RELIABILITY | ACCOUNTABILITY7

CIP-013-1

RELIABILITY | ACCOUNTABILITY8

CIP-010-3

RELIABILITY | ACCOUNTABILITY9

CIP-005-6

RELIABILITY | ACCOUNTABILITY10

CIP-005-6

RELIABILITY | ACCOUNTABILITY11

• CIP-013-1-R1-R2-R3 Implementation Guidance

• CIP-010-3 R1.6 Software Integrity and Authenticity

Approved Implementation Guides

RELIABILITY | ACCOUNTABILITY12

• Support effective and efficient implementation (e.g. CIP V5 transition)

• Supply chain risk study• Communicate supply chain risks to industry • Forum and Association white papers• Plan to evaluate effectiveness of supply chain standards

Board Resolution

RELIABILITY | ACCOUNTABILITY13

• NERC created a supply chain standard webpage• Critical Infrastructure Protection Committee (CIPC) to establish

advisory task force Advise on activities to support standard implementation Develop schedule for webinars, workshops, and technical conferences in

coordination with NERC and the Regional Entities Document existing risks and develop security guidelines

• NERC and Regions to conduct small group advisory sessions• NERC and Regions to offer outreach and readiness evaluations

Effective and Efficient Implementation

RELIABILITY | ACCOUNTABILITY14

• NERC to use contracted services to conduct risk study Assessment of product/manufacturer types used on the BES Analysis & applicability to BES Cyber Assets Analysis of best practices and standards in other industries to mitigate

supply chain risks Analysis of generalized vendor practices and approaches used to mitigate

supply chain risks

• NERC to recruit industry experts and vendors to participate in supply chain risk study

• E-ISAC to engage Department of Energy and Department of Homeland Security to explore information sharing opportunities and future supply chain risk assessment activities

Supply chain risk study

RELIABILITY | ACCOUNTABILITY15

• NERC and E-ISAC to continue utilizing NERC Alerts to communicate supply chain risks

• E-ISAC including supply chain risk topic in GridEx IV• NERC to capture supply chain standard resources on webpage• NERC and Regions to include supply chain topic at planned

workshops and seminars in 2018 NERC to conduct additional webinars and technical conferences

• CIPC to develop supply chain security guidelines• NERC and CIPC to partner with National Laboratory group to

conduct current equipment supply chain risk evaluation

Communicate supply chain risks

RELIABILITY | ACCOUNTABILITY16

• Forums and Associations developing white papers First drafts completed Q1 2018 Final review and publish Q2 2018

• NERC to post white papers on supply chain standard webpage• NERC, Forums and Associations to jointly present papers to

industry

Forums and Associations

RELIABILITY | ACCOUNTABILITY17

• NERC and Regions to develop effectiveness evaluation plan in Q4 2018 Evaluation plan dependent on FERC approval Plan to consider standard effective date and associated implementation

plan

• CIPC advisory task force to provide feedback to ERO Enterprise and industry on supply chain standard effectiveness

• NERC and Regions to continue small group advisory sessions throughout supply chain implementation to obtain feedback on outcomes and standard effectiveness

• ERO Enterprise auditor observations and feedback on standard effectiveness

Plan to evaluate standard effectiveness

RELIABILITY | ACCOUNTABILITY18

NATF Update – Cyber Security Supply Chain Risk Management

March 14, 2018Corey Sellers (Southern Company)

Copyright © 2018 North American Transmission Forum. Not for sale or commercial use. All rights reserved.

Community Confidentiality Candor Commitment

Open Distribution

NATF Work on Supply Chain Cybersecurity Risk Management

• Risk Management Framework• Coordination and Collaboration• Common Approach and Criteria for Independent Verification

of Supplier Cybersecurity Controls• Roadmap/Next Steps

Open Distribution 2

DRAFT NATF Supply Chain Cyber Security Risk Management Approach

Open Distribution

ID Common Supply Chain Cyber Security Controls

Step 1

Determine Nature of Review

Step 2

Review Report and Make Decision

Step 3

Assessing Vendor Adherence to Cyber Security Supply Chain Principles

Specify Cyber Security Criteria

Assess Vendor Capability

Review Vendor Response / Independent Assessment

Open Distribution

Specify Vendor Requirements: Review Established Cyber Security Criteria

Vendors implementing one or

more frameworks include:

GE

CISCOABB

Schneider Electric

Westinghouse

Open Distribution

CIP-013 Mapped to Commonly Known Cyber Risk Frameworks

Critical Security Control

NIST Cybersecurity

Framework

AICPA SOC 2 &

SOC3 TSPC

Link to NERC CIP v7

1.2.1/1.2.2 Notification by the vendor of, and coorindation of responses to, vendor-identified incidents related to

the products or services provided to the

Responsible Entity that pose cybersecurity risk to the Responsible Entity

Critical Security Control #19: Incident Response and Management

PR.IP-9PR.IP-10DE.AE-2DE.AE-4DE.AE-5

DE.CM-1-7RS.RP-1

RS.CO-1-5RS.AN-1-4RS.MI-1-2RS.IM-1-2RC.RP-1

RC.IM-1-2RC.CO-1-3

CC 6.2CC 2.3

CC 7.2-7.4CC 9.2

CIP-008-5 R1CIP-008-5 R2CIP-008-5 R3

1.2.3. Notification by vendors when remote or onsite access should no

longerbe granted to vendor representatives

Critical Security Control #5: Controlled Use of Administrative PrivilegesCritical Security Control #14: Controlled Access Based on the Need to Know

PR.AC-4PR.AC-5PR.AT-2PR.DS-1PR.DS-2PR.IP-8

PR.MA-2PR.PT-2PR.PT-3

CC 5.1 - CC 5.6CC 5.7

CC 6.2-6.3C 1.2 - C 1.3

CIP-004-6 R4CIP-004-6 R5CIP-005-5 R1CIP-005-5 R2CIP-007-6 R4CIP-007-6 R5CIP-011-2 R1

1.2.4. Disclosure by vendors of known vulnerabilities related to the products or

services provided to the Responsible Entity

Critical Security Control #4: Continuous Vulnerability Assessment and Remediation

ID.RA-1ID.RA-2ID.RA-3ID.RA-4ID.RA-5ID.RA-6PR.IP-12DE.CM-8RS.MI-3

CC 6.1CC 7.1

CIP-007-6 R2CIP-010-3 R3

1.2.5. Verification of software integrity and authenticity of all software and

patches provided by the vendor for use in the BES Cyber System

Critical Security Control #18: Application Software Security

PR.DS-6PR.DS-7

PR.IP-1PR.IP-2PR.IP-3

PR.MA-1

CC 6.1CC 6.7

CIP-010-3 R1

1.2.6. Coordination of controls for (i) vendor-initiated Interactive Remote

Access, and (ii) system-to-system remote access with a vendor(s)

Critical Security Control #16: Account Monitoring and Control

PR.AC-1PR.AC-3PR.AC-4PR.PT-3

CC 5.1 - CC 5.6CC 6.1 -6.3

CIP-005-5 R1CIP-005-5 R2CIP-007-6 R4

Cyber S

ecurity

Frame

work Co

mparis

on

Procurement and Implementation

Software Integrity and Authenticity

Information System Development

Vendor Remote Access

Open Distribution

Roadmap: NATF Supply Chain Risk Management Guidance

February 2018 – Complete DraftFinalize draft with project team

• NERC CIPC Meeting• NERC Small Group Advisory Session• NATF Board and Members• SERC CIPC

March 2018 – Report Progress

Circulate draft with EEI, APPA, NRECA, ISO/RTO, NAGF

April 2018 –Partner Sharing

May 2018 – NERC Sharing• NERC BOT

June 2018 –Industry Posting• TBD

Open Distribution

Discussion

Open Distribution

—

NERC WEBINAR, MARCH 14, 2018

Supply Chain SecurityVendor Perspective

Joe Doetzl, Cyber Security Practice Leader, Grid Automation

—

A word from ABB’s CEO

ABB Cyber Security

March 13, 2018 Slide 2

“ABB recognizes the importance of cyber security incontrol-based systems and solutions for infrastructureand industry, and is working closely with our customers

to address the new challenges.”

Ulrich Spiesshofer, CEO ABB

—

Full lifecycle coverage

ABB Cyber Security Approach

March 13, 2018 Slide 3

ABB requires the same of our suppliers

DesignImplementationVerificationReleaseSupport

Product

OperationMaintenanceReviewUpgrade

DesignEngineeringFATCommissioningSAT

Project

Service Delivery

—ABB Cyber Security Requirements

March 13, 2018 Slide 4

Product Security Requirements

Minimum cyber security requirements that must be fulfilled by all ABB products, e.g.

– Device Security Assurance Center Testing (robustness testing++)

– Removal of backdoor accounts and hardcoded credentials

– Malware prevention

– Hardening

– End-user documentation

– Vulnerability Handling

– Patch Management

Project Deployment Requirements

Minimum cyber security requirements that must be fulfilled by all ABB projects, e.g.

– Project security plan

– Training for project employees

– Malware prevention

– Hardening

– Removal of temporary accounts and services

– Patch Management

Service Delivery RequirementsMinimum cyber security requirements that must be fulfilled by all ABB services, e.g.– Training for service employees– Protection of user accounts– Change management– Malware prevention– Service infrastructure controls• Patch management• Access control• Data protection• Logging• Vulnerability monitoring• Patch management• Asset management• EOL management• Incident management• Secure connectivity

Robust minimum requirements

—

People – Pre-employment screening (PES)

Mitigating cyber security risks

March 13, 2018 Slide 5

Should entail as a minimum

– Open sources search

– Reference checks

– Criminal background checks

Risk assessment to determine type of screening

Basic screening

PESLevel 1 PES Level 2

All external candidates

üSensitivePosition** ü

Upper management

üSensitivePosition** ü

** Annually updated list provided by Country HR Manager

—

People – ABB Code of Conduct

Mitigating cyber security risks

March 13, 2018 Slide 6

The ABB Code of Conduct is the framework that explains the behavior ABB expects of every

employee and stakeholder around the world.

It is based on ABB's business principles:

responsibility, respect and determination.

ABB Code of Conduct

—

People – Cyber Security Training – General awareness program

Mitigating cyber security risks

March 13, 2018 Slide 7

—

Processes – Software Development Improvement Program

Mitigating cyber security risks

March 13, 2018 Slide 8

– SDIP was launched in 2008 as an ABB Group initiative and chartered to transform the way ABB develops software

– For the benefit of ABB’s overall business objectives, SDIP aims to bring our software R&D above and beyond industry average to achieve speed, quality and predictability in ABB's software product development.

Transform Software Development in ABB

Practices

Technology

Processes

People

—

Processes – SDIP Practices: Basic and Advanced

Mitigating cyber security risks

March 13, 2018 Slide 9

– Introduction of Configuration

– Introduction of Requirements

– Introduction of Architecture

– Introduction of SDIP Tools

– Static Code Analysis

– Code Review (Peer reviews)

– Coding Standards

– Unit Testing with Automation

– Project and Product Metrics

– Software Estimation

– Nightly Builds

– R&D Self-Assessment

– Define and Control Interfaces

– Continuous Integration

– Introduction of an IDE

– Organizational Metrics

– Product Visions and Roadmaps

– Introduction of Software Design

– Introduction of Software Testing

– Higher Quality Themes

– Portfolio Planning with Themes

– Improved Productivity Themes

– Predictable Schedules Themes

Basic Practices Advanced Practices

—

Processes – Security Development Lifecycle

Mitigating cyber security risks

March 13, 2018 Slide 10

– Introduce a Security Development Lifecycle

– Common Code Base for Security Features (CSA)

– Patch & Obsolescence Management

– Handling of Digital Certificates

– Pre-DSAC Testing

– DSAC Testing

– Protection from Malware Propagation

– Introduce Vulnerability Handling

– Authenticity and Integrity of Deliveries (e.g. Code Signing)

– Attack Surface Analysis and Review

– Static Binary Analysis for Security

– Security for Critical Components

– Design Guidelines and Patterns for Security

– Security Assessments & Threat Modeling

Basic Practices Advanced Practices

—

Introduction

Mitigating supply chain risks

March 13, 2018 Slide 11

– ABB has identified cyber security as a key requirement and is committed to providing customers with products, systems, and services that clearly address cyber security

– Several internal ABB initiatives focuses on cyber security for our products, as well as in our project deployments and services provided to ABB customers

– Cyber security requires a comprehensive and holistic approach: one single unsecure component can compromise the security of the overall system or solution

– 3rd-party products may be that unsecure component

– Risks related to 3rd-party products can be found over the entire product lifecycle and logistics:

• Products not having an adequate level of security quality (non-functional requirements, i.e., Secure Development Lifecycle practices)

• Products altered in transit and fake products

• Deployment-related security issues

• Post-deployment vulnerabilities and security issues

– In addition, suppliers’ sub-suppliers & sub-contractors may pose similar security risks

– Both suppliers of 3rd-party products and ABB shall engage in mitigating those risks

– Such engagement should be complementary and address both technological and process-related aspects

Introduction Risks and Mitigation Actors

—

ABB Suppliers

Mitigating supply chain risks

March 13, 2018

1. Software-related: any product or system that uses any type of software, is partly based on any type of software, or is in itself a type of software. Here, software shall be used in its broadest sense and include for instance firmware, drivers, applications, etc.

2. A software-related product that is supplied to an ABB entity from a non-ABB party, i.e., an entity outside the ABB group. Here, product is used as a blanket terms to describe a product, good, component, or system.

Slide 12

– Our suppliers shall support and complement ABB’s efforts to follow a comprehensive and holistic approach to cyber security

– More specifically, we want our suppliers to comply with the ABB Cyber Security Requirements for Suppliers

– Cyber security requirements that are considered fundamental to protect ABB and ABB customers

– Applicability: Software-related1 products supplied to ABB2

– Guiding principle: only ask from suppliers what we do ourselves and are willing to commit to our customers (in line with the internal policies)

– Resources, information, and guideline: http://www.abb.com/supplying/cybersecurity

Cyber Security Requirements for Suppliers Covered Areas and Requirements

Implementation Verification

Release Processes & documentation

– Removal of backdoors

– Quality of crypto and security functionality

– Robustness testing, vulnerability scanning, code analysis

– Malware prevention

– Vulnerability handling

– Patch management

– Software integrity and authenticity

– Secure development lifecycle– Handling of digital

certificates– Product documentation– Data collection– Sub-supplier & sub-

contractors

—ABB Cyber Security

March 13, 2018 Slide 13

Joe Doetzl, Cyber Security Practice Leader– Joe.Doetzl@us.abb.com– Atlanta, GeorgiaABB Global Cyber Security– cybersecurity@ch.abb.com

Contact Information

Overview

Kate Scarcella CISSPMS Information Security CyberSecurity Architect

March 14 2018

IBM Secure Engineering

Please Note:

2

IBM’s statements regarding its plans, directions, and intent are subject to change or withdrawal without notice at IBM’s sole discretion.

Information regarding potential future products is intended to outline our general product direction and it should not be relied on in making a purchasing decision.

The information mentioned regarding potential future products is not a commitment, promise, or legal obligation to deliver any material, code or functionality. Information about potential future products may not be incorporated into any contract.

The development, release, and timing of any future features or functionality described for our products remains at our sole discretion.

Performance is based on measurements and projections using standard IBM benchmarks in a controlled environment. The actual throughput or performance that any user will experience will vary depending upon many factors, including considerations such as the amount of multiprogramming in the user’s job stream, the I/O configuration, the storage configuration, and the workload processed. Therefore, no assurance can be given that an individual user will achieve results similar to those stated here.

IBM X-Force Data illustrates the continuing concern for the effectiveness of Security

3

IBM X-Force Threat Intelligence Reports

* https://www.ibm.com/security/xforce/research.html

Factoids & Insights from IBM Xforce 2017*~ 50% of the total: undisclosed causes~ 29% of disclosed: Web App related~ 50% of disclosed: Software defect related

2016: Year of the Mega Breach2016: Record number of “old” breaches disclosed2016: Focus shift to unstructured data (such as emails + email archives, documents, source code, intellectual property, etc)2016: DNC hacked using phishing & SQLi2016: DDoS attacks more sophisticated

2016: Improved hashing techniques make stolen encoded passwords less valuable

IBM Secure Development has evolved over more than 40 years from internally defined practices with Product focus to externally aligned practices with Cloud focus.

4

z/OS Statement of Integrity 1973

Secure EngineeringFramework2010

O-TTPS AccreditationIBM Middleware2014

Compliance & Certification to

External Standards2015 & 2016

ISO/IEC 20243:2015 Information Technology -- Open Trusted Technology Provider Standard (O-TTPS)

ISO/IEC 27002:2013 Information technology Security techniques — Code of practice for information security controls

NIST SP800-53R4 (FedRAMP)Security and Privacy ControlsFor Federal Information Systemsand Organizations

CIO Cloud Security Policy and Implementation Standard (ISO27002)

Cloud SaaSSoftLayerBlueMix

STG

Acquisitions

SWGSTG

Proactively identify, investigate and resolve vulnerabilities in IBM products, solutions and services, and new threats that are discovered.

5

IBM Principles for Secure Development

Enable products, solutions and services to provide a reasonable and adequate level of security prior to release, and to maintain and to improve security from release to release.

1. Provide security out of the box

2. Proactively respond to vulnerabilities & threats

Enable teams to design, build and deliver products, solutions and services that reflect the features and assurance criteria defined by international, governmental and industry recognized security standards.

Establish controls to manage access to source code, and monitor and analyze patterns of behaviors in order to minimize the risk of loss or contamination of source code and development artifacts.

3. Protect Source Code & Intellectual Property

4. Align Function & Practices w/ Security Standards

6

IBM Secure Development & DevOps = Secure DevOps

IBM Confidential

https://developer.ibm.com/cloudarchitecture/docs/security/securing-workloads-ibm-cloud/devops/

Separation of Duties

Dev Ops

Tools

Practices

Skills

Knowledge

Availability & Continuity

Secure Deployment

Evaluation & Learning

Education & Awareness

Offering Planning & Management

Secure Engineering

Risk & Threat

Modeling

SecureCoding &

Integration

Security Testing

IncidentResponse

SecurityReqmts

Dev’t Planning & Tracking

Analysis & Improvement

Offering LifecycleSecure Engineering

IBM Secure Development is supported by key tools

7

Development Tool Chain & Guidance Vulnerability Mgmt & Analytics (PSIRT)

Instrumented Devt Servers with Analytics Standards Assessment Advisors & Prep Tooling

8

Executive Dashboard is necessary for Evaluation & Learning Secure Development Tracking ActivityRisk Management Dashboard

In ComplianceOut-of-Compliance

Workload Vulnerability History & Trends

Comparison ofIssues among Workloads

Vulnerability Mgmt & Analytics (PSIRT)

9

Examples of Risk Management Dashboard views

Vulnerability Remediation tracking

Threat Model StatisticsSecure Engineering Performance

10

We are investing in tools and approaches with the goal of developing Cognitive Solutions for Secure EngineeringOne of the major challenges in building an environment for Secure Development is to be able to analyze past history and applythe lessons learned to avoid revisiting past defects. This is particularly difficult to do for security defects because there are so many variations to account for.

We have been working to apply cognitive techniques, in particular, natural language processing to help map instances of securitydefects (vulnerabilities) to the available catalogs of security knowledge that can drive improvements.

“how do I prevent SQL Injection?

“an attacker inserts escape characters and commands into HTML form to query database ”

IBM Product Security Incident Response Team (PSIRT) – Vulnerability Management

11

Mission

The IBM Product Security Incident Response Team (PSIRT) is a global team that sets policies and provides guidance for IBM product teams in the receipt, investigation, communication and analytics of security vulnerability information related to IBM product offerings.

IBM PSIRT is a focal point for clients, security researchers, industry groups, government organizations and vendors to report potential IBM product security vulnerabilities. PSIRT provides guidance for IBM product teams in developing an appropriate response.

IBM Confidential

PSIRT overview Product Security Incident Response Team (PSIRT) is part of

the Secure Engineering Framework (SEF)

Governs handling and communication for ALL security vulnerabilities known by IBM to exist in supported code

1,500+ products, components, and cloud offerings tracked via PSIRT Tool, managed by 2700+ users

12

ALL known security vulnerabilities documented in PSIRT Tool. This includes issues reported by:

– Customer– Internally discovered– Third party reporters– Third party vendors

Satisfies ISO27002 12.6.1 - Management of technical vulnerabilities

– Participate in PSIRT – Receive vulnerability reports– Register, track and resolve vulnerabilities

Basic PSIRT Process Flow

• 3rd party reporters and OSS• IBMers (internally discovered)• Customers

Document Remediation Plan

Resolve Vulnerability

Publish Fix and Vulnerability Information

Report Security Vulnerability

Research Vulnerability

PSIRT communication IBM does not publically disclose or confirm security vulnerabilities until IBM has

conducted an analysis and issued fixes and/or mitigations

Methods to communicate security vulnerability information– Public communication via Security Bulletin

IBM Support Portal IBM PSIRT Blog Subscription or push notifications My Notifications

– Targeted communication such as z Systems Security Portal and cloud offerings

Security Bulletins similar to Common Vulnerability Reporting Framework (CVRF)– Common Vulnerabilities and Exposures (CVE) common identifier– Common Vulnerability Scoring System (CVSS) for communicating the impact

Industry open standard for assessing the severity or impact Numeric measure that represents how much concern or attention the vulnerability warrants

13

Simple scenario PSIRT process workflow

14

CreateAdvisory

Create ProductRecord(s)

ResponderResearchesvulnerabilities and requests scoring

Tool sends email that a task was created

ResponderDocumentsRemediation and Communication Plan

Remediation Plan Reviewers● Remediation Plan Reviewer● Reviewing Attorney*● PSIRT Leadership*

Bulletin Reviewers● Security Bulletin Reviewer● Reviewing Attorney*● PSIRT Operations

● Responder● PSIRT Ops for Open Sourceand 3rd party reported

Review Plan

Publish Fix and Bulletin

*Reviews by Legal and PSIRTLeadership may not be needed

X-Force updates advisory with CVE and CVSS Details

Draft Security Bulletin

Fix is developed

Review Security Bulletin

Advisory – representation of the security vulnerability

Product Record – unique representation for a product/offering/component potentially affected

Brand Lead, Pillar Lead or Responder

PSIRT Ops• Open Source• 3rd party

reporter

X-Force monitors Open Source and 3rd

Party software feeds

Responder documents internally and customer found vulnerabilities

15

Business Guidelines: Each operating unit (divisional or geographical) is responsible for ensuring that its activities comply with the cross IBM Open Source Review Process.

Business & Strategic:OSS Use or Standards ParticipationReview group (OSSC or STSC) --• Assesses strategic alignment with business

and technical direction• Recommend approval or actions required for

approval• Identify – License, package, control

preferences

Business & Strategic:OSS Contribution or Standards InitiationReview group (OSSC or STSC) + VP Open Tech •Assesses strategic alignment with solutions and technical direction•Recommend approval or redirection •Identify Business / Strategic issues and required additional reviews

Legal (OSS & Standards)• Review participation documents for legal risks• Advise OSSC or SAR leadership regarding

acceptability of terms• Lead or support Agreemnt s or change s• Ensure IBM participants understand terms• Identify education needs

Open Source Core Team and IP Licensing staff• Process owners• Review proposals for revenue or

license/strategy/code impacts• Guide / consult identified changes• Provide check and balance between legal

and business• Recommend approval / disapproval OSSC

BusinessObjective

The process ensures business, technical, legal and licensing objectives

The IBM open technology approval process

All Open Source Package must be approved before use in IBM Products and Services. The review process considers Licensing and other Issues

16

Secure Engineering Guidance for Open SourceFor each Open Source component used:

1. Select an approved version for which no vulnerabilities are reported, or minimally, one with no issues that affect the product or introduce a vulnerability into customer environment.– Check OSS project site and release notes– Search vulnerability sites (XForce, OSVDB, CVEdetails, NIST NVD, Security Focus)– Scan with appropriate scanner (OWASP Dependency Checker, etc.)

2. Obtain files only from approved internal locations.

3. Include the component in the product’s threat modeling and system verification testing.

4. Subscribe to each relevant security notification list. Check project site frequently for issues and notify PSIRT if any are reported.

5. Ensure each package is included in Cert. of Originality (including version info).

6. Update bundling and/or usage dependency info as appropriate (including version info).

17

Notices and DisclaimersCopyright © 2018 by International Business Machines Corporation (IBM). No part of this document may be reproduced or transmitted in any form without written permission from IBM.

U.S. Government Users Restricted Rights - Use, duplication or disclosure restricted by GSA ADP Schedule Contract with IBM.

Information in these presentations (including information relating to products that have not yet been announced by IBM) has been reviewed for accuracy as of the date of initial publication and could include unintentional technical or typographical errors. IBM shall have no responsibility to update this information. THIS DOCUMENT IS DISTRIBUTED "AS IS" WITHOUT ANY WARRANTY, EITHER EXPRESS OR IMPLIED. IN NO EVENT SHALL IBM BE LIABLE FOR ANY DAMAGE ARISING FROM THE USE OF THIS INFORMATION, INCLUDING BUT NOT LIMITED TO, LOSS OF DATA, BUSINESS INTERRUPTION, LOSS OF PROFIT OR LOSS OF OPPORTUNITY. IBM products and services are warranted according to the terms and conditions of the agreements under which they are provided.

Any statements regarding IBM's future direction, intent or product plans are subject to change or withdrawal without notice.

Performance data contained herein was generally obtained in a controlled, isolated environments. Customer examples are presented as illustrations of how those customers have used IBM products and the results they may have achieved. Actual performance, cost, savings or other results in other operating environments may vary.

References in this document to IBM products, programs, or services does not imply that IBM intends to make such products, programs or services available in all countries in which IBM operates or does business.

Workshops, sessions and associated materials may have been prepared by independent session speakers, and do not necessarily reflect the views of IBM. All materials and discussions are provided for informational purposes only, and are neither intended to, nor shall constitute legal or other guidance or advice to any individual participant or their specific situation.

It is the customer’s responsibility to insure its own compliance with legal requirements and to obtain advice of competent legal counsel as to the identification and interpretation of any relevant laws and regulatory requirements that may affect the customer’s business and any actions the customer may need to take to comply with such laws. IBM does not provide legal advice or represent or warrant that its services or products will ensure that the customer is in compliance with any law

18

Notices and Disclaimers Con’t. Information concerning non-IBM products was obtained from the suppliers of those products, their published announcements or other publicly available sources. IBM has not tested those products in connection with this publication and cannot confirm the accuracy of performance, compatibility or any other claims related to non-IBM products. Questions on the capabilities of non-IBM products should be addressed to the suppliers of those products. IBM does not warrant the quality of any third-party products, or the ability of any such third-party products to interoperate with IBM’s products. IBM EXPRESSLY DISCLAIMS ALL WARRANTIES, EXPRESSED OR IMPLIED, INCLUDING BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE.

The provision of the information contained herein is not intended to, and does not, grant any right or license under any IBM patents, copyrights, trademarks or other intellectual property right.

IBM, the IBM logo, ibm.com, Aspera®, Bluemix, Blueworks Live, CICS, Clearcase, Cognos®, DOORS®, Emptoris®, Enterprise Document Management System™, FASP®, FileNet®, Global Business Services ®, Global Technology Services ®, IBM ExperienceOne™, IBM SmartCloud®, IBM Social Business®, Information on Demand, ILOG, Maximo®, MQIntegrator®, MQSeries®, Netcool®, OMEGAMON, OpenPower, PureAnalytics™, PureApplication®, pureCluster™, PureCoverage®, PureData®, PureExperience®, PureFlex®, pureQuery®, pureScale®, PureSystems®, QRadar®, Rational®, Rhapsody®, Smarter Commerce®, SoDA, SPSS, Sterling Commerce®, StoredIQ, Tealeaf®, Tivoli®, Trusteer®, Unica®, urban{code}®, Watson, WebSphere®, Worklight®, X-Force® and System z® Z/OS, are trademarks of International Business Machines Corporation, registered in many jurisdictions worldwide. Other product and service names might be trademarks of IBM or other companies. A current list of IBM trademarks is available on the Web at "Copyright and trademark information" at: www.ibm.com/legal/copytrade.shtml.

19

Ryan SocalSenior Program ManagerAzure Globalryansoc@microsoft.com

1. Our Approach

2. Assurance Focused

3. Countermeasures Overview

4. Additional Resources

Assurance is…• The process of building trust with customers

• Understanding their risks/threats

• Providing mitigations

• Showing evidence

Requires not only the correct things being done, but also that they are seen being done

1. Threat - Scenario - specific threats mapped to high level threat scenarios

2. Mitigation - Threat - mitigations mapped to specific threats

3. Transparency - Mitigation - transparency artifacts mapped to mitigations

4. Sub-scenario - mappings of high level threat scenarios to sub-scenarios (within each phase)

5. Commissioning, Onboarding, Day to day operation and Offboarding

1. Purchasing model options

2. Specific Contacting with MSFT supplier policies and training in place • Supplier Requirements, Benefits, Code of Conduct, & Guidelines

3. Specific supplier security procedures & records inspection/audit details contained in contracts• System access, system & application development & maintenance, change management, asset

classification & control, incident response, physical & environmental security, disaster

recovery/business continuity, & employee training

4. Components shipped from specific geography directly to Microsoft DCs using highly secure

methods• Multiple layered packaging, tamper resistant tape, product seals

5. Detailed Receiving, Handing & Installation, Logistics Warranty, & Destruction procedures

Identity & Access Management Controls

Contacting with MSFT

Microsoft Master Vendor Agreement

Detailed Receiving, Handing & Installation, Logistics Warranty,

& Destruction, policies & procedures

Security Development Lifecycle

Microsoft Government Security Program

© 2015 Microsoft Corporation. All rights reserved. The information herein is for informational purposes only and represents the current view of Microsoft Corporation as of the date of this presentation. Because Microsoft

must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information provided after the date of this

presentation.

MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS PRESENTATION.