Validate input

“Validate input from all untrusted data sources. Proper input validation can eliminate the vast majority of software vulnerabilities. Be suspicious of most external data sources, including command line arguments, network interfaces, environmental variables, and user controlled files” As Figure 1 suggests, there are many potential sources of untrusted data in today’s connected car, and that situation can only intensify as there is a move towards autonomy. This “validate inputs” practice clearly applies to each of those data sources, but perhaps less obviously it is also important that data from other domains is also considered as untrusted. In particular, if those domains are hosting applications of differing ASIL or security levels, then data validation plays a key role in ensuring that communication paths offer aggressors no “back door” access to a critical domain.

Figure 1: Automotive Attack Surfaces and Untrusted Data Source

Heed compiler warnings

“Compile code using the highest warning level available for your compiler and eliminate warnings by modifying the code. Use static and dynamic analysis tools to detect and eliminate additional security flaws” Many developers have a tendency to attend only to compiler errors during development, and ignore the warnings. CERT’s recommendation is to setting the warnings at the highest level available and ensure that all of them are attended to. SAST (Static Application/Analysis Software Test) tools are designed to identify additional and more subtle concerns, with “lightweight” tools or analysis settings likely to provide a quick check, but miss some of the more subtle issues.

White box DAST (Dynamic Application/Analysis Software Test) tools provide unit, integration, and system tests used to reveal vulnerabilities in application source code, and black box DAST tools complete the picture with fuzz and penetration tests.

Typical uses for SAST and white box DAST tools in a security focused analysis include:

Static analysis of code with reference to secure coding standards such as CWE, CERT C and MISRA C, to minimize the use of constructs and techniques likely to introduce vulnerabilities into the system;
Data and Control Coupling analysis, providing a means to recognize how data injection could potentially infiltrate a system, and to ensure that it is defended accordingly (Figure 2);
Unit test to show that defensive mechanisms have been implemented and are traceable back to security requirements;
Automatically generated robustness test cases, ensuring that such as boundary conditions, null pointers, and default conditions are handled adequately and hence introduce no vulnerabilities.

Figure 2: Illustration of Data Coupling Coverage analysis using the TBvision component of the LDRA tool suite

CERT top 10 practices: #1 and #2