Segurança por design e proteção em profundidade

Sibros follows an approach of security designed from the ground up and built into the DNA of the product. This includes in-vehicle secure communications and secure storage / HSM integrations.

All access needs authorization and is granted on a need-to-know basis. All employees are background checked as part of their onboarding process.

Our solution is assessed to TISAX, SSAE 16/18 SOC 2 Type 2, ISO 26262 (ASIL-D) in place with ISO 27001, ISO 21434, and ISO 24089 in progress. Sibros also addresses and supports security regulations such as UNECE WP.29 R155 and R156, with AIS 189, AIS 190 under review; as well as privacy regulations such as GDPR and CCPA, with Indian DPDP under review.

Sibros has a very well defined incident management process, and security incident management and breach response processes.

Sibros Armor includes the following checks and failsafes: 

• 2-way authentication of communication between vehicle and cloud
• Device provisioning framework incorporating secure integrations with manufacturing 
• DeviceID and Vehicle Identification (VIN) with a data abstraction framework that incorporates Privacy by Design
• Role-based Access Control (RBAC)
• Approval workflow for deployments and changes for systems
• SSO and MFA for user authentication
• In-vehicle secure communications
• Secure storage / HSM integrations

Support for 0x27 and key exchange, secure storage and symmetric key handling to be determined by target ECU.

Sibros acts as a data processor. The OEM is the data controller.

The following are used: 

• MQTT(s) over Mutual TLS 
• HTTPS over TLS

All changes for cloud and firmware are reviewed.

With the following reviews and assessments: 

• Components vulnerability review (firmware and cloud software)
• Cloud infrastructure vulnerability review (cloud software)
• OWASP IOT ASVS assessment (firmware)
• Cloud posture assessments
• AWS GuardDuty, GCP SCC, and other cloud threat assessment tooling

Sibros primarily uses a Globally Unique Identifier (GUID) to create a link between device identification information such as Vehicle Identification Number (VIN) / Electronic Serial Number (ESN) and the data collected by Deep Logger, Deep Updater, and Deep Commander.

Security is designed into the solution. Additionally, it is assessed to TISAX, SSAE 16/18 SOC 2 Type 2, ISO 26262 in place with ISO 27001, ISO 21434, and ISO 24089 in progress.

Log files are archived and optionally compressed. They are also handled securely and not directly uploaded into the system. The only reference information is in the system, and the S3 bucket is only used for storage of files that are uploaded as GUID’s (Globally Unique Identifiers).

• Drop request: Attacks that block network traffic (in-vehicle or outside) to prevent vehicles from updating software
• Eavesdrop: Attacks that listen to network traffic to reverse-engineer ECU firmware.
• Freeze attack: Indefinitely sends an ECU the last known update, even if there may be newer updates on the repository.
• Mixed-bundles: Attackers force ECUs to install incompatible software updates to cause ECU interoperability failure.
• Slow-retrieval: Slows down delivery of ECU updates so that a known security vulnerability can be exploited.
• Partial-bundle: Causes some ECUs to not install the latest updates by dropping traffic to these ECUs.
• Rollback: Causes an ECU to install outdated software with known vulnerabilities. 
• Arbitrary software: Attackers use compromised repository keys to release an arbitrary combination of new images to cause ECUs to fail.
• Mix-and-match: Most severe of all attacks installing arbitrary software on ECU to modify vehicle performance.

Uptane is the first security framework for automotive OTA updates that provides serious compromise resilience, meaning that it can withstand attacks on servers, networks, keys, or devices. The differences are as follows:

• A single server that is compromised cannot compromise more of the system.
• It is possible to recover from a single key compromise.
• The complete vehicle IP address is not readily accessible.
• Network security is not the only security control.
• Delivery authenticity is validated separately from firmware authenticity.
• Vehicle manifest and vehicle component authenticity are validated.
• Component and ECU rollback and replacement attacks are easily detected and remediated.

The following measures are taken:

• Device provisioning
• HSM integration
• In-vehicle secure communications 
• Provisioning of EOL integrations and device provisioning 
• Uptane keys and component replacements