Ebert RE PenTesting EN 2019.pptx - Schreibgeschützt)

V1.0 | 2019-10-12

@VectorVCS

PenTestingMedconf 2019

© 2019. Vector Consulting Services GmbH. All rights reserved. Any distribution or copying is subject to prior written approval by Vector. V1.0 | 2019-10-12

� Medical Security 3

Risk-Oriented Security 9

Systematic Security Engineering 19

Grey-Box Penetration Test 21

Summary and Discussion 28

Agenda

2/31


Why Vector Consulting Services?

Medical Security

Transport

Automotive

Aerospace

Medical

Digital Transformation

IT & Finance

� Vector Group is global market leader in automotive software and engineering toolchain with almost 3,000 employees

� Vector Consulting Services is supporting clients worldwide

� Transformation > Agile Transformation, Efficiency> Automotive SPICE

� Trust> Safety and Cybersecurity> Test Methods, PenTest, Supplier Audits

� Technology> E/E Design, AUTOSAR services> ALM/PLM, PREEvision introduction

� Training> Training, Coaching, Certification> Corporate Competence Programs

www.vector.com/consulting - @VectorVCS

3/31


Vector Client Survey 2019

Medical Security

Safety and Security are Biggest Challenge – Today and Tomorrow

Mid

-term

ch

allen

ges

Short-term challenges

Source: Vector Client Survey 2019. www.vector.com/trends. Horizontal axis shows short-term challenges; vertical axis shows mid-term challenges. Sum > 300% due to 5 answers per question. Strong validity with 4% response rate of 2000 recipients from different industries worldwide.

Innovation

Competences

Efficiency

Flexibility

Distributed teamsConnectivity

Quality

Complexity

Digital

transformation

Compliance

Others

0%

10%

20%

30%

40%

50%

60%

0% 10% 20% 30% 40% 50% 60% 70%

Competitiveness

Innovation

: The Fight of the Two Forces

Safety / Security

4/31


Medical Security

Vulnerabilities Increase with Complexity and Connectivity – across Industries

Devices

1980 2000 2020

Demand: Harden systems against cybersecurity threats

InfrastructureSystems

5/31


� Security of medical devices is of prime importance as these devices are dealing with the health and data of people.

� Safety of patients is of prime importance.

� Security must be addressed throughout the life-cycle of these devices from the initial design to services running.

� Sensitive data must be encrypted while transmitting.

Safety of Medical Devices Depends on Cybersecurity

Medical Security

� Most of the devices have limited size and hardware to fit those on to the patient’s skin. Example – IMDs (Implantable Medical Devices)

� It leads to low level encryptions of data giving easy attack potential to the adversaries.

� Moderate risks (such as ransomware campaigns that could disrupt clinical operations and delay patient care)

� Major risks (such as exploiting a vulnerability that enables a remote, multi-patient, catastrophic attack).

6/31


The data stored are used for both health monitoring and medical research. Tampering the data alters the diagnosis and research details.

Examples of cyberattacks on medical devices:

� Eavesdropping

� Data leakage

� Data corruption

� Password attacks

� Sensor confusion

� Vulnerabilities in application

� Deceiving forensic examiners (Repudiation)

Attack Vectors

Medical Security

7/31


Medical Security 3

� Risk-Oriented Security 9




Agenda

8/31


Example: Heartbleed Bug

Risk-Oriented Security

OpenSSL ServerMemory

beep

I am still there, send me back the following 4 bytes.

Let’s start a session and exchange a secret key for the following communication.

Exchange some sensitive data.

I am also still there. Here are the 4 bytes you requested.

badbeep

I am still there, send me back the following 400000 bytes.

I am also still there. Here are the 400000 bytes you requested.

…beep

…

400000 bytes

Private key of server

Session key

Sensitive data

Let’s start a session and exchange a secret key for the following communication.

badbeep Priv. key

4 bytes

Sensitive data

badbeep

beep

Attacker

User

Session key

Heartbeat

Heartbeat

Heartbleed

Security is about identification of the attack surface starting with security requirements and risk mitigation across the life-cycle.

9/31


Security Engineering


Most security attacks are process and implementation related.They rarely lie within the cryptographic protocols and algorithms.

Assets, Threats and Risk

Assessment

Security Mgmt in Production,

Operation, Service

Security Goals and

Requirements

Technical Security Concept

Security Implementation

Security Validation

Security Case, Assessment, Compliance

Security Verification

SWHW SRV

10/31


Secure by Design AND Secure by Life-Cycle


Security by Design

- Promoted by Safety-driven development

- Critical systems should by „secure by design“

- Frontloading with requirements, bottom-up protection and security engineering

„Would you use a medical device which will be secured solely by pulled software updates?“

Security by Life-Cycle

- Promoted by experiences in IT and SW-intensive Systems

- Add-on to traditional „security-by-design“ approach

- Counters dynamic changes and evolution of threats and security mechanisms

„Would you use a medical device with a weak design that has already been hacked?“

Combine thoughtful and risk-oriented “Security by Design” with fast agile “Security by Life-Cycle”.

11/31


Security Requirements Engineering


Asset Attack Threat

Attack Potential Security Goal

is performed

against risk is reduced byrequires

causes

has value for

Threat Agent(e.g. hacker)

Stakeholders(e.g., owner, driver, OEM)

has

Security Engineering

is achieved by

12/31


Determine Necessary Security Level with TARA Results


Ass

et ID Asset /

Vehicle

Function

CIAAG Attack vector Potential effect of

attack

Thre

at ID Threat

Exp

ertis

e

Exp

ertis

e

num

eric

al

Win

dow

of

Opp

ortu

nity

WoO

num

eric

al

Equ

ipm

ent /

Effo

rt

Effo

rt

num

eric

al

Thr

eat

num

eric

al

Thre

at le

vel

(hig

h=4;

low

=1)

Saf

ety

Fina

ncia

l

Ope

ratio

nal

Priv

acy

Impa

ct L

evel SGID

Ast 01 Safety-

Mechanisms

Avail Availability: Attacker floods

CAN-Bus and thereby tries

to disable vehicle primary

functions.

Attacker disables engine

control during an

overtaking maneuver if

system can impact safety-

critical functions.

Tht-1 Not further considered on advice of

client because the HU is rated QM

with respect to ISO 26262.

Layman 0 Critical 0 Standar

d

0 0 4 No

injury

No

impact

No

impact

No

effect

No

impact

n/a

13/31


Integrated Safety and Security Engineering


Analyze safety and security individually.Periodically evaluate dependencies for each process step including trade-off analysis.

?

Hazard and Risk

Assessment

Safety Goals

Functional Safety-Concept

Features and Operation Scenarios

Technical Safety-Concept

Implement. of Safety

Mechanisms

Verify Safety Mechanisms

Test Safety Mechanisms

Validate Safety

Assumptions

Safety Case

Safety ActivitySafety

Verification on Unit Level

Assets and Attack

Potentials

Threat and Risk

Assessment

Security Goals

Security Architecture

Technical Security Concept

Implement. of Security Mechanisms

Verify Security

Mechanisms

Test Security

Mechanisms, Pen Tests

Validate Security

Assumptions

Security Case

Security Activity

Security Verification

on Unit Level

Safe / Secure Implementation of Nominal Functions

Safety Operations

Security Operations

14/31


From TARA to Requirements, Design, Test, and Traceability


TestArchitectureRequirements

Functional security requirements

Assets, TARA,Security Goals

Technical security requirements

Grey-Box Penetration Test, Robustness Tests, Fuzzing

Functional Tests, Security Testing

Unit Test, Static Code Analysis

Seed/Key

Transmi t

Abstract memory

operation

Indications

Diagnostics

Seed/Key

IndicationsTransmi t

TaskAbstract memory

operation

IndicationsVeri fication Data Processing

Abstract memory

operationStream Output Memory I/O

Memory Handling Library

Veri fication Data Processing

Abstract memory

operationStream Output Memory I/O

Memory block

operation

Abstract memory

operation

Task

Indications

Memory I/O

Multiple Memory I/O

Manager

Memory I/O

Memory I/O

Decompression

Decompression

Memory block

operation

Delta Download

Library

Stream OutputMemory block

operation

Decryption Decompression

Data Processing

Decryption Decompression

Data Processing

Memory Drivers

Memory I/O

Indications

Communication Stack

IndicationsTransmitTask

Timer

Timer

Com Task Diag TaskTrigger Mem TaskTimer

Task Handling

Com Task Diag TaskTrigger Mem TaskTimer

Interprocessor

Communication

Stack

Abstract

memory

operation Memory I/O

Watchdog

Trigger

Security Module

Seed/Key Verification Decryption

System

Functional

SW/HW

15/31


Glucose sensor and insulin pump

Examples of threats and attacks analysis

Case Study: Glucose Sensor (1/2)


No. Attack Scenario Threat EffectAttack Type

(STRIDE)

Violated Security

(CIAANA) Risk

1Man in the middle attack on

communication

Tampering of data sent to

device from the monitoring

system/app

Changing the frequency of

pumping the insulinTampering Integrity High

2Man in the middle attack on

communication

Unauthorized access to

transmitted data Making patient's data public

Information

disclosureConfidentiality Medium

3Exploit vulnerabilities of OS

remotelyGetting access to the software

Taking control of the device

functionality

Elevation of

privilegeAuthorization High

4Exploit vulnerabilities of OS

remotelyDelete software component Reduce functionality of the device

Denial of

serviceAvailability High

16/31


Depending on analysis, security goals are defined

By taking Security Risk Analysis result as input we can focus our pen testing goal on to any particular security goal.

For example: We can test the remote communication channel between medical device and the application controlling it.

1. Eavesdropping strategies to find out whether data being communicated is encrypted.

2. Trying to elevate the privileges to modify the data.

Case Study: Glucose Sensor (2/2)


Security Goals

SG1 Any access to the communication data should be authenticated

SG2 Software should be protected from vulnerabilities like buffer overflow

SG3 All the data should be encrypted before commincating

SG4 Freshness of the data should be checked before acting on it

17/31


� Design

� Defensive coding, e.g. memory allocation, avoid injectable code, least privileges

� Programming rules such as MISRA-C, SEI CERT

� High cryptographic strength in line with performance needs

� Key management and HW-based security

� Awareness and governance towards social engineering

� V&V Methods and Tools

� Static / dynamic code analyzer

� Unit test with focused coverage, e.g. MCDC

� Interface scanner, layered fuzzing tester, encryption cracker, vulnerability scanner

� Risk-based penetration testing

Security Implementation, Verification and Validation


Classic coverage test is not sufficient anymore. Test for the known – and for the unknown.Ensure automatic regression tests are running with each delivery.

18/31


� PSIRT Collaboration (Product Security Incident Response Team)

� Handover, task assignments and distribution

� OTA Updates: Ensure that each deployment satisfies security requirements

� Data encryption: Protection of intellectual property by encryption

� Authorization: Protection against unauthorized access

� Validation: Safeguarding of data integrity

� Authentication: Verification of authenticity through signature methods

� Governance: Safety/security documentation is continuously updated

� Pen Testing

� Connect with misuse, abuse and confuse cases

� Vector Grey-Box PenTest based on TARA and risks

� DoS, Replay, Mutant/Generated Messages

� Fuzz Testing

� Brute-force CAN Fuzzer for fuzzing the Application SW

� Code Analysis

� CQA, Coverage (e.g., VectorCAST)

� Design, architecture, (opt) defect analysis

Security by Lifecycle: Verification, Validation and Life-Cycle Management

Systematic Security Engineering

Fuzz Testing

Pen Testing

Code Analysis

Processes and competences

TARA d

riven g

rey-b

ox

appro

ach

PSIRT

19/31


Medical Security 3



� Grey-Box Penetration Test 21


Agenda

20/31


White box pen testing. Difficult due to complex supply chain

In Black box pen testing, tester will have zero knowledge about the system. It is very difficult to design test strategy. Therefore, it needs more time and resources to conduct the test.

Grey-box pen test follows the black box testing approach. However, it takes results of Security Analysis into account to form attack strategy.

� It enables higher detection effectiveness

� Much lower effort and time compared to other testing methods.

� Cost effective

� Quality results and findings

Advantages of Grey-Box PenTesting

Grey-Box Penetration Test

21/31



Security Validation: Penetration Testing Approach

1. Overview:

� Penetration Testing is an offensive approach for security

� Highly automated tools because a high and growing number of potential threads has to be systematically validated.

� Example: Metasploit (Open Source Framework)

2. Basic Approach:

� Scan the target system concerning vulnerabilities.

� Select one of the proposed Exploits, which make the weakness applicable.

� Select and apply a payload (e.g. meterpreter backdoor) to get access to target ressources.

Permission of the target owner makes the difference between penetration testing and hacking.

Metasploit

Target System

Host

Network

API: Ethernet, CAN

22/31


At Vector we have developed a grey-box security testing method for more efficiency and effectiveness

� We follow the black-box security testing approach, while considering specific risks due to attacks and implementation.

Case study: Medical IT

� Assets and TARA with COMPASS

� PenTesting based on identified assets and risks

� Quality results and findings

� Cost and time effective

Practical Grey-Box PenTesting


Rather than brute force PenTest, we deploy with clients the grey-box PenTesting based on TARA, abuse/misuse cases and architecture know-how

Security

ProtocolDesign

Specification

Test Cases

Simulation / Test

Test Results

23/31


Grey-Box PenTesting Approach (1/3)


As a first step we identify the assets in the scope of the PenTesting using expert knowledge and our COMPASS tool

24/31


� On this basis we conduct a mini-TARA and identify the attack vectors and scenarios for each asset.

� We refine these security goals into negative requirements (e.g. misuse, abuse, confuse cases), functional and technical security requirements which help to achieve them

� This allows setting priorities to subsequent PenTesting steps to connect with security risk, i.e. window of opportunity and attack consequences



25/31




By taking our TARA as input, We put our focus on the flash asset and with physical access to the board we initiate an attack to read the contents of the flash during runtime

After analyzing the data dump we got from the flash we can read in clear text:

� The root certificate at address 0x06F2A0(i.e. while it is ok to read it, it must be ensured to be not replaced)

� Specific key at address 0x06F6A0

Grey-box PenTest yields higher detection effectiveness with much lower effort and time.

26/31


Medical Security 3




� Summary and Discussion 28

Agenda

27/31


Vector SecurityCheck with COMPASS for TARA and Continuous Documentation

Summary and Discussion

Vector SecurityCheck facilitates� Systematic risk assessment and mitigation � Traceability and Governance with auditable risk and measure list� Heuristic checklists with continuously updated threats and mitigation

COMPASS information: www.vector.com/compass

28/31


Vector SecurityCheck with COMPASS for TARA and Continuous Documentation


Activity Benefit

Adapt mature development

processes to factor in

security engineering.

§Security engineering activities are known,

scheduled, and executed within “normal” development.

§Security is not treated as add-on.

§Synergies can be exploited.

Elicit security requirements

in the beginning of the

project.

§Assets to be protected are clearly identified.

§Basis for realization of security.

§Test cases for security validation can be deduced.

Review or test every

security relevant artifact,

use analysis and test tools.

§ Identification of issues at the earliest possible time.

§Automated tools increase confidence and reduce effort.

Manage embedded security

competencies.

§Specific embedded security expertise available when

necessary.

29/31


Trainings

� Open trainings: www.vector.com/consulting-training

� Worldwide in-house trainings

Webinars and Podcasts

� Webinars and recordingswww.vector.com/webinar-securitywww.vector.com/webinar-safety

Free white papers etc.

� www.vector.com/media-consulting

COMPASS for SecurityCheck, SafetyCheck and TARA: www.vector.com/compass

Grow Your Competences in Risk-Oriented Development


30/31


Thank you for your attention.Please contact us for consulting support.

Passion. Partner. Value.

Vector Consulting Services

@VectorVCS

www.vector.com/[email protected]: +49-711-80670-1520

Date post:	24-Feb-2022
Category:	Documents
Upload:	others
View:	3 times
Download:	0 times

Ebert RE PenTesting EN 2019.pptx - Schreibgeschützt)

Documents