Cybersecurity Organization
Introduction
Now that we have covered the cybersecurity regulatory requirements that must be met for the automotive industry let’s look at what it takes to achieve it.
This first lesson will cover the organizational structure we commonly see implemented to be able to carry out the work required to meet the regulation. Of course, there is no one-size-fits-all solution that works for everyone. Like how organizations differ in Big Tech, every company comes up with its solution to this challenge. We offer some suggestions based on our experience, but organizations should tailor these to fit their people and approach.
Hilarious comic on Org structures
Standard Requirements
The cybersecurity maturity, responsibility, and structure may vary significantly between OEMs. At each organization, there should be a team that is responsible for cybersecurity, with a reporting structure accountable to the CEO. Companies must also support a cybersecurity culture, where individuals are empowered to make crucial decisions about cybersecurity and given support throughout all levels of leadership at the company.
What is required of a company from a regulatory perspective?
The definition of the CSMS from UN R155 implies that an organization is in place within the company to perform processes, responsibilities, and governance required to achieve a reasonable cybersecurity posture based on the product risks defined during the engineering development lifecycle. To achieve this, many OEMs and Suppliers have chosen to utilize ISO/SAE 21434: Road Vehicles — Cybersecurity Engineering as the standardized guidance on establishing an effective CSMS. Examples of requirements that relate to organizational structure from section 5.4.1 “Cybersecurity Governance”:
[RQ-05-01] The organization shall define a cybersecurity policy that includes the following:
- acknowledgment of road vehicle cybersecurity risks; and
- the executive management’s commitment to managing the corresponding cybersecurity risks.
[RQ-05-02] The organization shall establish and maintain rules and processes to:
- enable the implementation of the requirements of this document; and
- support the execution of the corresponding activities
[RQ-05-03] The organization shall assign and communicate the responsibilities and corresponding organizational authority to achieve and maintain cybersecurity.
[RQ-05-04] The organization shall provide the resources to address cybersecurity.
- NOTE Resources include those responsible for cybersecurity risk management, development, and incident management.
The above requirements can be accommodated through multiple organizational approaches.
For example, a large company may accommodate the above by first building a new Vehicle focused cybersecurity team. These teams would work independently from prior existing IT cybersecurity organizations that do not necessarily have the expertise to manage vehicle-specific cybersecurity risks.
Another example of an organization could be a smaller company that is newer to the market. In this case, the organization may not have the resources to set up separate teams and therefore chooses to be lean and product-centric, integrating cybersecurity processes and requirements across the organization.
Enterprise Cybersecurity
Some companies combine traditional IT security and back-office security as one organization, while others separate them into two individual organizations.
Everyone should be clear about what the enterprise IT security team does. For example, they are responsible for securing enterprise servers, implementing company network firewalls, phishing email filters, virus scanners, and educating employees on good office security practices.
The back-office security team, sometimes called the offboard or OT security team, focuses more on the systems and applications that support vehicle security but are not physically present within the vehicle. Examples include:
- Mobile applications, such as customer-facing applications used to interface with the vehicle remotely.
- Back-end infrastructure that supports all connected services. Examples include Firmware Over The Air (FOTA), connected Diagnostics Authentication, Remote Operations, Product Data Collection, High Definition Maps.
- Supporting Cyber Operational Capabilities (Product Security Operations Center, Product Cryptographic Platform, Software Development Environment and tools (DevSecOps.)
- Supporting manufacturing plants with initial identity or key provisioning, key negotiation, and other vehicle security manufacturing processes.
Product (Vehicle) Cybersecurity
This organization focuses on the security of on-vehicle products. This organization may be called vehicle, product, or onboard security. This team may also be divided into two sub-teams specializing in vehicle security areas. A team focused on embedded vehicle security (which focuses on the controller area network (CAN) bus and electronic control units (ECUs)) is sometimes referred to as core or embedded vehicle security. And a team for connected ECU security (which focuses on telematics, gateway, and infotainment modules with long-range connectivity) can be called the connected or wireless security team.
Diving into the Product / Vehicle security teams and organizations in more depth, Vehicle security organizations at automakers, depending on their security maturity level, typically have a list of Cybersecurity Specifications. The specifications give detailed requirements for each technology domain they expect suppliers to implement. Security engineers on this team will work closely with suppliers to ensure the security posture of ECUs, vehicle systems, and the entire vehicle meets the expected outcomes.
Technical leaders should set direction on the specifications necessary for the company’s products, or automakers can consult third-party experts to develop appropriate coverage with their technical specifications. Senior leadership should set direction on overall cybersecurity goals and policies at the company level.
Organizational Challenges
In large companies, there is often a lack of collaboration and conflicting goals between the enterprise and product-focused organizations due to siloed organizations. These organizations may have conflicting goals, with the traditional IT and enterprise organizations focusing on protecting data assets and maintaining the availability of cloud services. Enterprise security goals are concerned with compliance with regulations such as GDPR and ensuring that cloud systems do not experience unplanned downtime or data breaches.
The main goal of the product security or vehicle security teams is the safety and security of products on the road. This goal may sometimes take precedence over the goals of the enterprise organization because cyber threats to vehicles can have serious physical consequences for human lives. Misalignment of the two separate organizations’ goals (protect the product versus compliance and cost savings) adds to the difficulty of collaborating effectively.
Both organizations have compliance requirements but different standards, regulations, and compliance targets to meet. The product and vehicle security teams focus on maturing the cybersecurity processes and capabilities that allow an OEM to comply with WP.29 UN R 155 Regulations on Cybersecurity for Road Vehicles based on the ISO/SAE 21434 Cybersecurity Standard for Road Vehicles guidance.
An additional corporate organization complexity is a separate Corporate Compliance Department may exist, which is separately responsible for interfacing with both groups to ensure the company meets regulatory compliance obligations.
The collaboration between disparate organizations at traditional OEMs can be slow and create ambiguity in responsibility ownership of cybersecurity capabilities (who is doing what). Separating these teams and using third parties limits the scope of penetration testing that excludes cloud, back-end infrastructure, or web applications from vehicle telematics Pentesting. It is complicated to conduct penetration testing with a broad scope that tests the vehicle product like attackers in the real world would experience these products. Many individuals and private researchers are finding vulnerabilities in the responsibility gaps between these organizations and third parties. (Recent Examples, https://samcurry.net/web-hackers-vs-the-auto-industry/ or https://medium.com/@david_colombo/how-i-got-access-to-25-teslas-around-the-world-by-accident-and-curiosity-8b9ef040a028)
The example diagram below depicts a generic vehicle, cloud, mobile app, vehicle systems, and third-party features as a design topology. This diagram illustrates that the separation between vehicle cybersecurity teams and enterprise security is blurred. There is additional complexity with using third parties, web providers, and mobile applications.
Current Industry Trend to Address the Challenge
It made sense to have a separation between enterprise and vehicle product cybersecurity organizations in the past because there was little overlap between them. However, automotive companies continue transforming to meet customer and regulatory expectations rapidly. This includes the creation of new EV-based platforms and capitalizing on the opportunity to create new revenue-based software-defined services to maintain market share and achieve desired profits. Because of this active transformation, the distinction between the two prior cybersecurity teams (Enterprise and Product) continues to blur.
Additionally, technology trends are adding to the ambiguity challenge in adopting modern technology stacks and implementing them into the physical onboard perimeter of the vehicle. For example, using Android operating systems now creates a dependency on OEMs implementing DevSecOps practices to deploy and manage the ongoing lifecycle of apps deployed directly on the onboard vehicle components. Previously, the focus of apps resided within off-board apps used by the customers to interface with the product and available services.
Consolidating Teams
Centralized Product Development Focused Teams To achieve the new goals to meet the transformation objectives of their respective companies, many corporate OEM organizations are merging the Product Development and Connected Features Development departments that previously resided in separate corporate departments (Engineering, IT, and Connected Services) within a single Product Software Development Organization which establishes a single set of goals and targets. These organizations are built with a focus on rapidly delivering and deploying iterative new customer capabilities to remain competitive in the market and create new revenue-generating business opportunities. Unique H/W and S/W, Product or Engineering teams, are no longer the differentiating factor in delivering customer-facing and revenue-generating products and capabilities. Many automotive products are moving to a software-defined feature set, in which OEMs can sell additional services and capabilities to the customer without modifying H/W.
Centralized Product Operations Teams To achieve corporate efficiency (cost and resources), many OEMs are leveraging existing enterprise IT teams that centrally manage enterprise cloud infrastructure and also manage connected vehicle cloud infrastructure. OEMs who operate this way aim to create clear responsibility for ownership of Connected Product and Feature Operations.
Centralized Product Cybersecurity Teams This trend of convergence of organizations may or may not consider the convergence of a single Product Cybersecurity Management System (CSMS). This convergence of cybersecurity processes must be planned and executed to succeed, like converging the respective development teams into a single organization. Because of this, we see some organizations maintain a separation of Product cybersecurity responsibilities but also see trends in which the Product cybersecurity organizations are merged under the Centralized Product Development Team Organization and structure.