paint-brush

This story draft by @escholar has not been reviewed by an editor, YET.

A New Testing Platform and Testing platform roles

EScholar: Electronic Academic Papers for Scholars HackerNoon profile picture
EScholar: Electronic Academic Papers for Scholars

EScholar: Electronic Academic Papers for Scholars

@escholar

We publish the best academic work (that's too often lost to peer reviews & the TA's desk) to the global tech community

undefined @escholar
LEARN MORE ABOUT @ESCHOLAR'S
EXPERTISE AND PLACE ON THE INTERNET.

Authors:

(1) Sekar Kulandaivel, Robert Bosch LLC — Research and Technology Center;

(2) Wenjuan Lu, Block Harbor Cybersecurity;

(3) Brandon Barry, Block Harbor Cybersecurity;

(4) Jorge Guajardo, Robert Bosch LLC — Research and Technology Center.

Table of Links

Abstract and 1 Introduction

2. Current Security Testing Platforms

2.1. Recent progress

3. A New Testing Platform and 3.1. Testing platform roles

3.2. Web-based remote access

3.3. Testbed setup

4. Enabled Testing Methodologies

4.1. Secure Development Lifecycle (SDL) testing and 4.2. Penetration testing

4.3. Research testing

5. Conclusion & Outlook, and References

3. A New Testing Platform

We present a flexible and configurable testing platform for automotive security by extending a cloud-based framework with additional components to support a number of testing methodologies. We focus on building a solution that is useful for many types of users, ranging from penetration testers to security researchers, and we aim to create a platform that bridges features in both software and hardware testing. We do not aim to cover all aspects of functional and safety testing, and we do not attempt to recreate a HIL system. We implement some of these testing methodologies and discuss practical benefits of our tests.

3.1. Testing platform roles

We design this testing platform with a variety of users and roles in mind:


Penetration testers: Users who need to test quickly and easily launch automated pentesting scripts, perform wireless tests while remote, access platforms without needing to ship hardware, connect a local device to a remote device (e.g., OEM dealership tool), and easily switch between different test beds from different contracts.


Researchers: Users who need to easily deploy and demonstrate novel security research on ECUs from multiple OEMs, copies of the same ECU for repeatability, and multiple model years while performing analysis with measurement tools (e.g., oscilloscopes, logic analyzers) and launching attacks from a custom ECU on the network.


Engineers: Users who needs managed access to the platform via scheduling, global remote access to test beds, quick reconfiguration of a prior project to handle new vulnerabilities, and a familiar user interface to interact with.


Lab technicians: A role that is responsible for setting up hardware in the lab, activating hardware-only features inperson, and moving probes for measurement tools if need.


This paper is available on arxiv under CC BY 4.0 DEED.


L O A D I N G
. . . comments & more!

About Author

EScholar: Electronic Academic Papers for Scholars HackerNoon profile picture
EScholar: Electronic Academic Papers for Scholars@escholar
We publish the best academic work (that's too often lost to peer reviews & the TA's desk) to the global tech community

Topics

Around The Web...

Read on Terminal Reader
Read this story in a terminal
 Terminal
Read this story w/o Javascript
Read this story w/o Javascript
 Lite
X REMOVE AD