What is Cyber Security Management System in AIS-189?
In the context of AIS-189, the Cybersecurity Management System (CSMS) is a mandatory framework that all automotive manufacturers (OEMs) and suppliers must implement to ensure end-to-end cybersecurity throughout the vehicle’s lifecycle.
It’s directly aligned with the concept introduced in UN Regulation R155 and referenced in ISO/SAE 21434 — and is a foundational requirement for getting type approval under AIS-189.
In Simple meaning, a Cyber Security Management System (CSMS) is a structured way for a company (like an OEM or Tier-1 supplier) to ✅ Plan ✅ Organize ✅Implement and ✅ Monitor cybersecurity measures to protect their vehicles and systems from hackers and cyber threats.
It includes:
What processes are followed to handle cyber risks
How decisions are made to ensure every ECU and connected system stays safe — from design to production to post-sale updates
It’s like a “cybersecurity rulebook + management process” that the company follows across its entire vehicle development lifecycle — not just writing secure code, but managing risk, assigning responsibilities, and ensuring every part of the vehicle is protected.
Key Objectives of CSMS
As per AIS-189, the Cyber Security Management System (CSMS) is a mandatory organizational framework that ensures cybersecurity is actively managed across the entire lifecycle of the vehicle — from concept design to post-sale updates.
Below are the four key objectives of a CSMS and what they mean in practice:
🔍 1. Identify and Assess Risks Across All Vehicle Systems
CSMS requires automakers and suppliers to perform a Threat Analysis and Risk Assessment (TARA) to proactively identify cybersecurity threats across the vehicle’s ECUs, software modules, and communication networks.
This includes analyzing:
Attack surfaces (e.g., CAN bus, OBD-II, Telematics)
Potential threat actors (remote, physical, insider)
Severity and likelihood of each threat scenario
By doing so, organizations can prioritize which components need stronger security mechanisms.
Example: Identifying that an unsecured diagnostic port could allow firmware manipulation.
🛡️ 2. Implement Protection Mechanisms (Cryptography + Secure Design)
Once risks are identified, the next objective is to implement preventive security measures. This includes both technical controls and secure architecture design:
Use of cryptographic primitives like:
AES for data confidentiality
RSA or ECDSA for firmware authenticity
CMAC for message integrity
Integration of secure-by-design practices such as:
Secure Boot
Hardware Security Modules (HSM)
Gateway-level firewalls
Secure OTA update protocols
These measures ensure the system can resist or detect unauthorized access or manipulation.
Example: Using digital signatures to verify firmware before an ECU boots.
🔁 3. Monitor and Respond to Cybersecurity Incidents
CSMS must enable an ongoing process to detect, analyze, and respond to cyber threats after vehicle deployment.
Key activities include:
Real-time logging and monitoring (e.g., Intrusion Detection Systems)
Incident response procedures
Deployment of security patches or OTA firmware updates
Reporting and escalation protocols
This objective ensures that vehicles remain secure throughout their operational life, even as new threats emerge.
Example: If a telematics unit receives abnormal OTA packets, the gateway flags it, logs it, and notifies backend servers.
📄 4. Ensure Traceability and Documentation for Compliance
To comply with AIS-189 and obtain type approval, every cybersecurity activity must be clearly documented and traceable. CSMS enforces the following:
Maintenance of cybersecurity audit logs
Traceable linkage between identified threats and applied mitigations
Documentation of software versions, keys, certificates, and test results
Defined roles and responsibilities across teams
This traceability provides transparency to approval authorities and enables organizations to demonstrate compliance during audits or post-incident analysis.
Example: Documenting that AES-CMAC was implemented on all CAN messages and tested for message spoofing resistance.
Component's of CSMS for AIS-189
A Cybersecurity Management System (CSMS) isn’t just a policy document — it’s a comprehensive framework that ensures cybersecurity is systematically embedded across an organization’s vehicle development lifecycle.
Below are the five essential components of a CSMS and what each entails in real-world automotive development:
🔎 1. Risk Assessment (TARA – Threat Analysis and Risk Assessment)
Purpose:
To proactively identify, assess, and prioritize cybersecurity risks across all vehicle systems and components.
What it involves:
Mapping out all vehicle assets (e.g., ECUs, sensors, communication channels)
Identifying possible attack surfaces and entry points (e.g., OBD-II port, telematics unit)
Performing TARA to:
Evaluate threat scenarios
Rate risks based on impact and likelihood
Define risk treatment strategies (mitigate, transfer, accept)
Why it matters:
This step ensures that security efforts are focused where they matter most — on systems where compromise could result in safety failure, data theft, or vehicle manipulation.
🛡️ 2. Security-by-Design
Purpose:
To ensure that cybersecurity is built into the vehicle’s architecture right from the concept phase, rather than being patched in later.
What it involves:
Designing systems with least privilege, fail-safe defaults, and data minimization
Integrating cryptographic primitives such as:
AES for encryption of stored or transmitted data
RSA or ECDSA for firmware signing
CMAC/HMAC for message authentication
Isolating safety-critical systems via network segmentation
Implementing Secure Boot, firewalls, and intrusion detection systems
Why it matters:
Security-by-design prevents vulnerabilities from being introduced in the first place, saving time and cost in future recalls or software patching.
🔁 3. Lifecycle Monitoring and Incident Response
Purpose:
To ensure the organization can detect, analyze, and respond to security events throughout the vehicle’s operational life — not just during development.
What it involves:
Logging and monitoring for suspicious activity on communication buses (e.g., CAN IDS)
Regular vulnerability scanning of firmware and applications
Establishing an incident response process:
Detection and classification of incident
Escalation and containment
Recovery actions (e.g., OTA patching)
Root cause analysis
Maintaining post-production support including firmware updates and security advisories
Why it matters:
Cyber threats evolve constantly — ongoing monitoring ensures that zero-day attacks and new vulnerabilities can be addressed quickly to protect vehicle safety and customer trust.
🔐 4. Access Control and Role-Based Security
Purpose:
To define and enforce who is allowed to do what in the vehicle’s development, production, and post-production environment.
What it involves:
Defining user roles and permissions across engineering, testing, diagnostics, and maintenance teams
Implementing secure authentication mechanisms:
Challenge–response access for diagnostics (UDS SecurityAccess)
Role-based command access on ECUs (e.g., only certain roles can flash firmware)
Ensuring supply chain partners and service tools follow proper access protocols
Locking down remote entry points (e.g., telematics unit, Wi-Fi/Bluetooth)
Why it matters:
Access control prevents unauthorized users or tools from modifying ECU behavior, extracting sensitive data, or injecting malicious firmware.
📄 5. Traceability and Documentation
Purpose:
To ensure transparency, accountability, and audit readiness by recording every cybersecurity-related decision and activity.
What it involves:
Keeping detailed records of:
TARA reports
Cryptographic key management procedures
Security test plans and results
Supplier compliance assessments
Version control and changelogs for:
Software updates
Security patches
Vulnerability fix deployments
Documenting the assignment of responsibilities and roles
Providing evidence for type approval under AIS-189
Why it matters:
Without documentation, an OEM cannot prove compliance with AIS-189 — and may fail to get type approval or face liabilities after a breach.
Example Activities Under CSMS
These activities represent the practical implementation of the policies and processes defined by a Cybersecurity Management System (CSMS). They ensure that cybersecurity is actively enforced at the technical and operational levels throughout the vehicle lifecycle.
🔍Performing TARA using ISO/SAE 21434
TARA = Threat Analysis and Risk Assessment
A foundational activity where potential threats to vehicle systems are identified and prioritized.
What’s done:
Identify vehicle assets (e.g., ECUs, sensors, communication channels)
Determine attack paths (e.g., through OBD-II, Bluetooth, OTA)
Evaluate:
Impact (e.g., safety, financial, reputational)
Likelihood (e.g., attack complexity, exposure)
Define risk levels (High, Medium, Low)
Recommend mitigation strategies
Tools/Methods: Data flow diagrams, STRIDE modeling, 21434 Part 8 & 9 templates
Why it matters:
It helps you focus your security investment where the risks are highest — for example, the TCU or brake ECU vs. the ambient light controller.
🔐 2. Enforcing Cryptographic Key Management Practices
Proper key management is the backbone of vehicle security — without it, cryptography is useless.
What’s done:
Generate, store, rotate, and retire encryption keys
Define who owns which key, and where it’s stored (e.g., HSM, Secure Element, OTP memory)
Set policies for:
Symmetric key usage (e.g., AES keys for message encryption/authentication)
Asymmetric key usage (e.g., RSA or ECC keys for signing/verification)
Secure provisioning during manufacturing
Ensure keys are never exposed in plain text
Why it matters:
If a vehicle’s private key is leaked or mismanaged, an attacker could spoof OTA updates, reflash ECUs, or hijack communication.
🚀 3. Implementing Secure Boot, Secure Update, TLS, CMAC in Firmware
These are technical enforcements of cybersecurity in the actual firmware code of ECUs:
Secure Boot:
Ensures that only signed, verified code runs at ECU startup
Prevents malicious firmware injection
Implemented using RSA/ECDSA signatures
Secure OTA Update:
Validates digital signature of firmware before flashing
Encrypts update payloads using AES-GCM
Includes rollback protection
TLS (Transport Layer Security):
Used in telematics, cloud, or V2X communications
Provides end-to-end encryption and mutual authentication
CMAC (Cipher-based Message Authentication Code):
Ensures integrity and authenticity of ECU-to-ECU messages over CAN or Ethernet
Used in AUTOSAR SecOC modules
Why it matters:
Without these protections, an attacker could manipulate firmware, send spoofed messages, or hijack backend communication.
🧪 4. Conducting Penetration Testing and Vulnerability Assessments
“Test like a hacker before a real hacker does.”
What’s done:
White-box and black-box testing of ECUs, firmware, and communication stacks
Fuzz testing of diagnostics interfaces (UDS)
Testing known attack vectors:
CAN flooding
Firmware spoofing
Wi-Fi/Bluetooth injection
Evaluate third-party software (e.g., AUTOSAR stacks, SDKs) for known CVEs
Tools: CANoe, Scapy, Wireshark, automotive-specific fuzzers
Why it matters:
Vulnerability assessments expose gaps before production. Pen testing proves whether those gaps can be exploited.
📋 5. Logging and Incident Reporting Protocols
You can’t fix what you don’t see.
What’s done:
Log all security-critical events:
Failed authentication attempts
Unauthorized diagnostic commands
Anomalies in communication patterns (e.g., IDS alerts)
Secure logs with HMAC or write-once memory
Define incident escalation procedures:
Who analyzes?
Who responds?
How to patch or update affected ECUs?
Report to:
Internal security team
Type approval authority (if mandated)
Backend/cloud systems (for fleet-wide monitoring)
Why it matters:
Real-time detection and response is critical — attackers don’t always announce themselves. CSMS requires that you be prepared for when, not if.
