Block Harbor (BH) was established in 2014 to build great solutions in automotive cybersecurity to keep mobility safe. We’re on a mission to build great solutions for automakers and automotive suppliers to keep mobility safe, focused on their business needs; a standardized and regulated landscape. BH’s first projects were with Fiat Chrysler Automobiles (FCA) in the wake of the “Jeep Hack” that brought public attention to the need of cybersecurity in connected vehicles. BH is an industry leader in vehicle cybersecurity - everything from testing services as a part of our Vehicle Cybersecurity Labs to maintaining a 24/7/365 Vehicle Security Operation Center to monitor vehicle systems for attacks. BH has a firm understanding of the standard and regulatory landscape and how to implement vehicle cybersecurity at scale. For vehicle focused penetration testing service to threat and risk analysis, BH has you covered.
Hi thanks for the nice video series about ISO 21434 TARA. One question, aren't the examples of product security goals too generic, especially the second one? The last available video is 9/10. Will there be another video part 10/10 from you?
Any idea if CAN hardware (Ixxat USB-to-CAN V2, Peak PCAN-USB, etc) will work on a Linux VM running inside of a Windows Host? Or will the Windows driver have issues with passing data to Linux/SocketCAN?
I'm glad you like it! If you want to get hands-on and take The Plunge, we have the Hackathon 101 course for free or the Vehicle Penetration Testing course at vsec.blockharbor.io
10:48 - In the first frame of the sequence the length of the data is 0x01B which is 27 in decimal, but the length of the VIN is 24-Bytes (33 46 4D 54 4B ...... 00 00 00 00 00). Can you help me with this?
While the length of the VIN is 24 bytes, the entire message is 27 bytes of data. The length of the response includes the "62 F1 90," indicating a positive response to a service 22 requesting the VIN.
Always the length of the Response = Length of Data + Service ID + Sub Service ID + ID In the case: Length of Data = 24 Bytes Service ID = 1 Byte (0x22 + 0x40 = 0x62) Sub Service ID = 0 (No Sub Service ID in Read DID) ID = 2 Bytes (F1 90) Total = 27 Bytes
So glad I have discovered this page. I have about 4 years experience as an automotive controls engineer and I am also interested in cybersecurity. This page is the perfect confluence of interest I have been looking for.
Great tutorial. I found these instructions helpful for installing Kali Linux on an M1 Mac ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-9zdjQ9w_v_4.html
Thanks for creating and sharing the cool video. One comment - the goal you provide as an example (enforce least privilege…) is not actually a goal, it’s a requirement. And another problem of the example - achieving the goal doesn’t help as the attacker is still able to execute arbitrary code on the device which potentially means altering a vehicle function. Yes, the code is non-privileged but who cares. The asset in the example is a software and I would say the goal should be to ensure integrity of the software. To achieve the goal you potentially need to: - minimise attack surface - prevent scanning - check integrity of the software in runtime - monitor and fix known vulnerabilities - authenticate requests to the software - etc no worries, goals are one of the most annoying things in the story)
Awesome, Jonathon taught me this exact list of commands when we were prototyping telematics to upload the entire powertrain CAN traffic for engineering analysis.
If it's an EV, attack surface would also include the charging port itself. The FHWA's NEVI Plan NPRM defines OCPP as the predominant EV charging protocol to be used, where the OCPP documentation describes communication from EV charging station to car via the physical input to the vehicle.
