For security teams in the automotive industry, 2021 was an extremely busy year. Cybersecurity became a requirement for market access and compliance, so the entire industry faced a challenging timetable.
- The United Nations Regulation WP.29 R155 states, “In the European Union, the new regulation on cyber security will be mandatory for all new vehicle types from July 2022 and will become mandatory for all new vehicles produced from July 2024.”
- On August 31, 2021, the official version of ISO/SAE 21434 "Road vehicles - Cybersecurity engineering" was released. This document defines a framework for cybersecurity process requirements and cybersecurity risk management for the entire life cycle of vehicle products.
- In China (the world’s largest automotive market), on September 14, 2021, the Equipment Industry Development Center of the Ministry of Industry and Information Technology issued the "Opinions on Strengthening the Management of Intelligent Networked Automotive Manufacturers and Product Access." This requires automotive original equipment manufacturers (OEMs) to conduct self-assessments for vehicle data security, cybersecurity, software over-the-air (OTA) upgrades, and driving assistance functions. The results were required to be reported before October 12, 2021.
The security groups in automotive companies are experiencing "forced growth" brought about by rigorous cybersecurity compliance requirements. Although each standard specifies detailed and clear requirements, security groups must sort through these complicated checklists to formulate a work action plan that can be implemented within the limitations of each organization’s abilities.
On the one hand, individual security activities have been transformed into a process-based cybersecurity management system (CSMS). On the other hand, automotive firms must focus limited resources quickly to efficiently establish enterprise security capabilities that meet compliance requirements. That these are two very different approaches (single-point vs. landscape, depth vs. breadth) is the crux of the issue facing automotive OEM security teams. How other companies solved this problem is a very valuable reference.
About BSIMM
In 2008, consultant, research, and data experts from what is now the Synopsys Software Integrity Group set out to gather data on the different paths that organizations take to address the challenges of securing software. Their goal was to examine organizations that had highly effective software security initiatives, to conduct in-person interviews on those organizations’ activities, and to publish their findings. Those findings became the first "Building Security in Maturity Model” (BSIMM) report.
eBook
BSIMM14 Report
Since then, BSIMM has continued to grow and develop from the original 9 companies to 128 participating companies in 2021, involving nearly 3,000 software security group members and more than 6,000 satellite (security champion) members.
The BSIMM report provides a unique perspective based on data collected from real-world observations. It provides CISOs and other security leaders with a model and framework to test, measure, and benchmark their own software security programs against, including key activities, practices, and tools to consider for implementation.
Unlike prescriptive models such as regulations, standards, or secure software development life cycle (SSDL) process models, BSIMM is a descriptive model. It uses a "just the facts" approach that focuses on documenting observations, rationalizing data from those observations, and creating a common language to describe and communicate the software security initiatives.
For companies, comparing the specific security activities in BSIMM against their own corresponding implementation status does not result in a good or bad judgement. Rather, the analysis can become the cornerstone of enterprise software security initiative improvement. BSIMM is the measuring stick for the security group, not a rulebook.
Most of the current cybersecurity issues in the automotive industry are related to vehicle networking and intelligence. In addition, the popularity of software-defined vehicle technology has made software security and the software development process in the automotive industry specifically important enough to be discussed as a distinct category. Although BSIMM focuses on software security, it has also been used by product manufacturers in high tech industries to measure product-related security activities rather than just software or application security.
BSIMM uses a framework of 12 software security practices organized under four domains—governance, intelligence, SSDL touchpoints, and deployment—currently encompassing 122 activities. BSIMM activities can be viewed as controls implemented in a software security risk management framework. The implemented activities might function as preventive, detective, corrective, or compensating controls in a software security initiative. Positioning the activities as controls allows for easier understanding of BSIMM’s value by governance, risk, and compliance teams, and by legal, audit, and other risk management groups.
Let’s take some specific security practices as examples to gain a better understanding of the value BSIMM offers the automotive industry, especially for building the software security system.
Governance-led efforts
UN R155 stipulates that vehicle OEMs need to first prove the basic capabilities of their cybersecurity systems and processes. Each model produced requires a type approval to prove that specific products have specific implementations that were made in accordance with the requirements of the certified cybersecurity system and process. However, many vehicle OEMs have adopted the opposite approach. The regulations and standards themselves are used as the cybersecurity requirements of the project. That makes it possible for the work products to serve as evidence of compliance across the whole enterprise.
The BSIMM12 report notes that companies have two paths to achieve a mature security system. One is to construct a security system from top to bottom through compliance requirements. The other is to improve security capabilities through the engineering team.
Because BSIMM is a descriptive model, it describes and compares these two approaches but it doesn’t evaluate the pros and cons of them. Organizations that choose a governance-led approach usually start by defining a software security initiative, which is an organization-wide program to instill, measure, manage, and evolve software security activities in a coordinated fashion. The leader of such an initiative first establishes a centralized team structure. This might not involve immediately hiring employees, but it may be necessary to form a full-time team to implement key activities to support the further definition and institutionalization of software security-related policies, standards, and procedures at the organizational level.
The BSIMM12 report defines three key security activities.
- Policy: Create policy
- Standards: Create security standards
- Process: Publish process and evolve as necessary
However, in the current organizational structure of many automotive OEMs, security teams often come from engineering research and development teams, and they are not sufficiently empowered to implement security-related policies, standards, and procedures at the enterprise level. Further, it’s often the case that security groups don’t have adequate support and budget. Therefore, security teams should limit the focus of these key activities to a specific project, using the project budget.
BSIMM also observed that governance-led and emerging engineering-led approaches to software security improvement embody different perspectives on risk management that might not correlate. Governance-led groups often focus on rules, gates, and compliance, while emerging engineering-led efforts usually focus on feature velocity, error avoidance through automation, and software resilience.
Success does not require identical viewpoints, but collectively the viewpoints need to converge in order to keep the firm safe. That means the teams must collaborate on risk management concerns to build on their strengths and minimize their weaknesses. Although many automotive OEMs construct their cybersecurity systems through engineering projects, this approach still requires the security group to understand the overall framework. So it’s vital that the security team gets sufficient support within the enterprise, not just limited to specific projects.
Assess risks with the TARA method
In the official release of ISO/SAE 21434, an entire chapter was dedicated to threat analysis and risk assessment (TARA) activities and related requirements. This reflects the importance of TARA activities in the automotive industry.
Some regard TARA merely as a prework for developing product security requirements, and many automotive OEMs and component suppliers still implement TARA by hiring external security experts and consultants. Of course, it is now necessary to implement TARA in accordance with the detailed requirements defined in ISO/SAE 21434. Although security teams have a good understanding of the security protection mechanism (cybersecurity controls), the challenge is communicating the cybersecurity requirements to the engineering team.
TARA activities rationalize and optimize cybersecurity requirements by identifying potential threats and assessing the risks posed by these threats. Another important purpose of these activities is tracing the relationship between external threats and risks and security countermeasures, so organizations can determine the priority of subsequent cybersecurity developing and testing activities based on different risk levels. This will enable security teams to focus on responding to high-risk threats. If we refer to ISO/SAE 21434, Cybersecurity Assurance Level (CAL) is used for such traceability. A successful TARA activity should help the security group understand where to put the (very limited) budget to improve security in important areas.
BSIMM's security framework also emphasizes the practice of attack models in the domain of intelligence. These attack models help the security team think about security issues from the perspective of an attacker, so they can collect threat modeling inputs, abuse cases, data classification, and technology-specific attack patterns. BSIMM12 notes 11 observed security activities related to attack modeling that can be used as references to help the security group fill in any shortcomings in this area.
Detect security issues with penetration testing
Before security functions and the SSDL became standard, penetration testing was the most commonly used security activity in automotive OEMs security groups. Pen testing allowed security teams to discover and expose product vulnerabilities, thereby promoting the need for security requirements. BSIMM12 noted that 87% of the participating companies use external penetration testing services to find problems. Penetration tests clearly prove to the organization that they are not immune to security issues. At the same time, it can also bring adversarial thinking to the organization and avoid blind spots.
For an effective penetration attack, the tester needs to find system vulnerabilities and also effective methods of exploiting them. Penetration testing projects generally have a fixed test timeline, and often provide test environments and targets to testers in an “opaque-box” manner. Therefore, testers often spend the bulk of their time discovering system vulnerabilities rather than exploiting them, as it is difficult to dig deeper into unknown vulnerabilities or expand the scope of the search within the project time limit.
To address this, security groups can turn the opaque-box test into a gray-box test by providing penetration testers with more technical information, whether internal or external. The testers should be able to use the available source code, design documents, architecture analysis results, abuse cases, code review results, and cloud environment deployment configurations to do more in-depth analysis and find more interesting problems. For example, the penetration tests can include:
- A TARA report in the concept design phase and the identified threat scenarios, attack methods, and constructed attack trees. Penetration testers can be required to perform corresponding verifications during testing to recommend corresponding security protection measures and details about whether the implementation of the system is effective, whether the residual risk is acceptable, and so on.
- Static analysis and security scanning on the implemented code, so the penetration tester can target and improve the relevance of the penetration work.
- Tests on interfaces that have already been opened so that testers can directly invade the internals of the system. Opening the interface in this way mimics how real-world attackers would take a step-by-step approach instead of directly landing on the target asset. This method can also be used to verify whether the defense-in-depth design has been well-implemented.
In the BSIMM12 report, there are three levels of testing composed of seven security activities related to penetration testing. They can be used as a reference to help security groups improve the security of their products.
Level 1
- Use external penetration testers to find problems
- Feed results to the defect management and mitigation system
- Use penetration testing tools internally
Level 2
- Penetration testers use all available information
- Schedule periodic penetration tests for application coverage
Level 3
- Use external penetration testers to perform deep-dive analysis
- Customize penetration testing tools
Create an incident response plan
There is no 100% secure system or product, so the main goals of security are to respond to security incidents in a timely and effective manner and to perform risk management well. The software security framework in BSIMM12 specifically defines configuration management and vulnerability management as important security practices, and details 12 related security activities. For example, 84% of BSIMM12 participants have their software security team work closely with the organization’s incident response team to keep critical security information flowing in both directions. Opening communication channels with infrastructure and software vendors is also a very important task for software security groups. Furthermore, BSIMM also includes security activities that illustrate how to use a security incident response to improve existing security processes.
The road to success
In cybersecurity, the challenge is constantly evolving external threats. In many cases, even if the organization has a compliance certificate, it only covers the basic security capabilities. The security team of an enterprise needs continuous improvement to drive its work. The annual BSIMM report is a living document that changes and evolves based on real-world observations and analysis. As development methodologies advance, new threats emerge, and security methods adapt, the BSIMM data evolves in step. The insight and analysis of new trends in the software security field as detailed in the BSIMM report can provide corporate security teams with a reference for keeping up with the times. The BSIMM community of participating companies exchanges information and learns from each other. The BSIMM report is completely public and can be obtained online. You are also welcome to contact Synopsys experts to obtain more in-depth analysis and interpretation and learn about scheduling a detailed evaluation.
eBook
BSIMM14 Report
Continue Reading
