Table of Links Abstract and 1 Introduction Abstract and 1 Introduction 2. Current Security Testing Platforms 2. Current Security Testing Platforms 2.1. Recent progress 2.1. Recent progress 3. A New Testing Platform and 3.1. Testing platform roles 3. A New Testing Platform and 3.1. Testing platform roles 3.2. Web-based remote access 3.2. Web-based remote access 3.3. Testbed setup 3.3. Testbed setup 4. Enabled Testing Methodologies 4.1. Secure Development Lifecycle (SDL) testing and 4.2. Penetration testing 4.1. Secure Development Lifecycle (SDL) testing and 4.2. Penetration testing 4.3. Research testing 4.3. Research testing 5. Conclusion & Outlook, and References 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. Penetration testers: 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. Researchers: 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. Engineers: 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. Lab technicians: This paper is available on arxiv under CC BY 4.0 DEED. This paper is available on arxiv under CC BY 4.0 DEED. available on arxiv 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. Authors: 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.