This post results from the project “CARSec” within the Munich Cyber Security Program (MCSP) The MCSP is a cooperation project between Champlain College and ComCode (Germany). This project focuses on Cybersecurity topics for connected / self-driving cars.
A new week has come and gone, meaning that my research into automotive security has continued. While I’ve continued to look into the rules and regulations, I’ve also begun to look into the aspects of cybersecurity that organizations can be proactive about. Specifically, I’ve looked into secure software development, supply chain security, and penetration testing regarding automotive security. Organizations that continuously work towards these aspects would certainly be better set than an organization that doesn’t.
When talking about supply chain security, it seems fairly self-explanatory, however, there’s a lot of aspects to this topic that need to be researched thoroughly. The goal of supply chain security is to identify, analyze, and mitigate the risks inherent in working with other organizations as part of a supply chain. While supply chain security can certainly relate to physical developmental items. It is always very prevalent in terms of software and hardware used within an organization. Those who pay attention to cybersecurity relevant news will certainly have heard of Kaseya and SolarWinds, those are direct examples of the threat that a weak supply chain can pose to not just one, but possibly thousands of organizations.
One of the other topics that I focused on was secure software development and its processes. This is a common practice for many organizations. It is the process of building security into software from the beginning of development. By doing this, drastically decreases the risk that cybersecurity attacks and breaches pose. The Software Development Life Cycle, (SDLC), is a process to design, develop, and test high-quality software. This framework doesn’t touch on cybersecurity aspects, so it should most likely be supplemented with another framework. There are two very popular choices that organizations can choose to follow, the first being the Secure Software Development Framework, (SSDF), developed by NIST. The other main framework found was developed and published by CISA, and focuses on many of the same areas that the SSDF focuses on. Following these practices allow organizations to get a head start on cybersecurity and not being forced to play catch up.
Finally, the last topic that I focussed on was penetration testing. For anyone not familiar with penetration testing, it is usually attempting to evaluate the security of an IT infrastructure by trying to exploit vulnerabilities safely. In cybersecurity in general, these tests will be run against internal and external networks, looking for flaws in authentication or encryption, trying to run common injection attacks, as well as even social engineering tactics in some cases. Within terms of automotive security, a penetration test should validate the security of a vehicle’s ECU/TCU structure, subcomponents, and the entire vehicle eco-system against cybersecurity vulnerabilities. With any penetration test, the basic steps to follow include preparation, information gathering, risk analysis, active testing, and a final analysis.
Throughout this posting, I have indicated that these three things are common and easily implemented ways that an organization can institute security measures into its infrastructure from the ground up.
Follow us for more updates on this project! For further questions about Munich Cyber Security Program, or this project please feel free to contact mcsp@comcode.de
Written By: William Alber ’22 // Computer & Digital Forensics