NVIDIA Tegra
NVIDIA DRIVE OS 5.1 Linux SDK

Developer Guide
5.1.12.0 Release

 
Security Service
 
Threat Detection
Threat Management
Example of Escalation for Denial of Service Detection and Prevention
System Exceptions
The Security Service inspects traffic between the Communication Service and the guest VM. The encrypted and signed configuration file configures the detection and policies for the traffic. When an attack is detected, the Security Service enacts the configuration policy for that attack.
Each guest VM has a security policy associated with each communication interface. These security policies are independent of each other; consequently, two guest VMs can have different security policies for the same physical interface.
The Security Service manages the logging of incidents, if required by the associated policy, according to common criteria principles.
The Common Criteria for Information Technology Security Evaluation, referred to as Common Criteria or CC, is an international standard ISO/IEC 15408 for computer security certification. CC and the companion Common Methodology for Information Technology Security Evaluation (CEM) are the technical basis for an international agreement, the Common Criteria Recognition Arrangement (CCRA), which ensures that:
• Products can be evaluated by competent and independent licensed laboratories to determine the fulfilment of particular security properties, to a certain extent or assurance.
The Security Service functions in two phases:
• Detection phase: detects potential threats
• Threat management phase: executes the associated policy when a threat is detected
Threat Detection
The threat management detection types are as follows:
Detection Type
Description
Hard Policy Threat
By default, all threats of this type are blocked. However, the system can be configured to allow very specific cases that are not blocked.
For example, incoming traffic is blocked unless the source of that traffic is already communicated to by a guest VM, which effectively becomes an incoming packet filter of unsolicited traffic. However, it is possible to open a specific IP:Port address to always be open in the configuration file.
Normal Threat
Can be configured for different policies depending on the type of threat detected. The policies can include:
• No Action
• Let Through
Temporary Threat
Includes attacks that occur for a period of time, such as Denial of Service attacks. A mechanism is provided to detect if the attack is still occurring.
The detection methods and level of configurability of each level is as follows:
Detection Level
Configurable Items
IP Stateful Firewall with NAT
Topology
• DHCP option: uses DHCP or not in Communications.
• Assigns static IP addresses and subnet masks to build the internal private network of virtual machines.
• Specifies DNS servers are required.
• Internal inter-VM (Guest OSS) IP traffic: Enables or disables per each couple of guest OSS. By default, all inter-VM links for inter-guest OSS IP communications are disabled.
Feature Status
Enables or disables firewall security.
Detection Capabilities
Inbound and outbound traffic with broadcast/
multicast address
These events can be enabled/disabled for each VM or guest OS:
• Inbound Source IP Type Broadcast
• Inbound Destination IP Type Broadcast
• Inbound Source IP Type Multicast
• Inbound Destination IP Type Multicast
 
• Outbound Source IP Type Broadcast
• Outbound Destination IP Type Broadcast
• Outbound Source IP Type Multicast
• Outbound Destination IP Type Multicast
 
• Inbound Source IP Address is Zero
• Inbound Destination IP Address is Zero
 
• Outbound Source IP Address is Zero
• Outbound Destination IP Address is Zero
Traffic from blacklisted IP or MAC Address
Each event can be enabled or disabled for each VM or guest OS:
• Outbound packet with a source IP not recognized
• Packet with a blacklisted source or destination hardware address
• Packet with a blacklisted source or destination IP Address
Malformed Packets including verifications for:
• Frame Length
• IP Header Length
• Payload Lengths
• Ethernet Frame Type
• Checksum
• Protocol Type
Each event can be enabled or disabled for each VM or guest OS:
• Frame length is lower than the minimum size
• Frame length is higher than the maximum allowed size
• IP header length is lower than the minimum size
• IP packet length is lower than the length value carried within its header
• Ethernet frame type is not supported
IPV4 is supported
• IP packet with protocol is not allowed
• TCP payload length is lower than the minimum length or its header length
• UDP payload length is lower than the minimum length
Verification of source and destination ports for persistent port scan defense
Each event can be enabled or disabled for each VM or guest OS:
• Inbound TCP packet with source or destination port is not allowed
• Inbound UDP packet with source or destination port is not allowed
• Received TCP packet does not match any tracked connection
• TCP packet triggered a failure during the connection establishment procedure
Denial of Service detections
For each guest OS interface, DoS detection can be enabled or disabled for these attacks:
• Local Area Network Denial
• Ping of death
• Ping flood
• SYN flood
• UDP flood
• Smurf attack
• Port scan
Fine tuning is possible using the configuration escalation behavior to define the Escalate and Wait periods.
CAN Firewall
Configurable Items
Feature Status
Enable or disable for specific guest OS and specific interfaces.
For example: SPI, AURIX, ALL, or NONE.
Detection Capabilities
CAN message IDs for inbound and outbound traffic; whitelisted IDs.
Each event can be enabled or disabled for each VM or guest OS on each supported CAN interface:
• Outbound Messaged ID is not allowed
• Inbound Messaged ID is not allowed
CAN message Frame Length for inbound and outbound traffic
Each event can be enabled or disabled for each VM or guest OS on each supported CAN interface:
• Outbound Frame Length invalid
• Inbound Frame Length invalid
CAN message Frequency for inbound and outbound traffic CAN DPI
Each event can be enabled or disabled for each VM or guest OS on each supported CAN interface:
• Outbound Messaged Frequency is not allowed
• Inbound Messaged Frequency is not allowed
• Outbound Messaged Frequency is indefinite
• Inbound Messaged Frequency is indefinite
Deep Packet Inspection and Anomaly Detection with Neural Networks for Ethernet and CAN Interfaces
Configurable Items
Feature Status
Applies to Ethernet and CAN:
Enables or disables Neural Networks inspection for traffic per each guest OS interface
Anti-Malware for data transfers over Ethernet
Configurable Items
Feature Status
Applies to Ethernet:
Enables or disables Anti-Malware inspection per each guest OS interface
The configurable features used in support of detection methods is as follows:
Detection Method
Configurable Items
TLS Inspection and cryptography service
Feature Status
• TLS inspection for SSL Proxy, man in the middle:
• Enable or disable per guest OS, per Ethernet interface
• Allows specifying of the appropriate certificate to be applied
• TLS Encrypt or Decrypt for Centralized Car Computer: Enable or disable per channel
Logging and Audit
Configurable Items
Feature Status
Centralized logging server: enable or disable; enabled by default.
It is possible to specify:
• For each system component, logging must be individually configured as follows:
• Enabled or disabled
• Level of logging:
• Information
• Notice
• Warning
• Error
• Critical Major
• Type of events logged:
• Audit
• System
• Security
• Size of centralized on-board logging file
• Action for on-board logging file full:
• Rollover
• Discard
• Parameters of connection with remote audit server
• IP Address
• VPN
• Authentication credentials
• Periodic interval between uploads
Privacy and Confidentiality protection by cryptography
Configurable Items
Feature Status
• Always enabled
• No configurable items
Integrity attestation of Guest OS
Configurable Items
Feature Status
• Always enabled
• No configurable items
Backup and Restore of Security Appliance image
Configurable Items
Feature Status
• Always enabled
• No configurable items
OTA Updates and Policy Maintenance
Configurable Items
Feature Status
• Always enabled
• No configurable items
Threat Management
When an attack is detected, the configured policy for that specific VM traffic, on that specific interface, is executed.
For each of the detection methods, the Prevention System supports a broad range of remedy actions. The following remedy actions are not intended to be exhaustive, they can be combined as necessary, and relevant in reaction to each detection or a combination of detections:
• Allow packet
• Block packet
• Log event
• Verify integrity of guest OS or other parts of the system
• Reset guest OS
• Reset interface
• Block interface, blacklist interface
• Notify user
Example of Escalation for Denial of Service Detection and Prevention
For a Denial of Service detection and prevention, a typical escalation logic is as follows:
Detection of a Denial of Service is based on measurements over a Sense period, expressed as an integer number of Slot Duration. The latter is an internal parameter and defines the minimum duration for a measurement period. The DoS detection is performed at the end of the Sense period.
For a positive detection, the Escalate period is started and the recovery process is triggered for the type of attack, according to the DoS policy.
• Each Escalate period is followed by a Wait period.
• The Wait period is checked if the action taken is successful and the DoS attack is terminated.
• If the counter measures have failed, the level of escalation is raised.
• If the countermeasures are successful, but the system is still under attack, the system remains in defense mode.
• Once the DoS attack is terminated, a de-escalation moves the system to a normal state.
The available escalation levels, each involving different actions, include:
• L1: low
• L2: medium
• L3: high
System Exceptions
By default, the system is configured to apply the tightest level of security. To specifically relax security rules, configurability is provided to allow hard exceptions as required. For example:
• Inbound connections
• Any unsolicited inbound connection is blocked: inbound traffic is allowed on a connection that was previously initiated from a guest OS within the secure boundary of the SoC domain.
• Explicitly programming the firewall is possible to allow for inbound connection on a specific port and to a specific destination for a Guest OSS. For example:
• SSH for QNX VM
• SSH for Linux VM
• ADB shell for Android VM
• Security transparent traffic
• TLS inspection
• The system is configured to intercept, decrypt, and inspect all traffic from Guest OSS and SSL sessions.
• Disabling the Man in the Middle is possible for specific connections to let SSL traffic through with no outbound or inbound inspections.