Software Considerations in AIS 140 for Vehicle Tracking System: Is it enough?

Advances in hardware and software due to increased performance and miniaturization, combined with continuous effort to reduce costs of products and services encourage the deployment of VTS. Being an embedded device, there are already a few studies available concerning the safety and security risks of such VTS. With an intent to lead from the front, India has AIS 140 standard, envisioning to address safety and security challenges of VTS development and deployment.

Regulation in India:

Rule 125H of the Central Motor Vehicle Rules (CMVR) 1989 mandates the installation of Vehicle Location Tracking (VLT) device and emergency button for the new public service vehicle registered after 1^st January 2019. This rule is not applicable for two-wheelers, e-rickshaw, three-wheelers, and any transport vehicles for which permit is not required under the Motor Vehicle Act, 1988. VLT device manufacturers will have to get their devices tested and certified from the testing agencies referred to in rule 126 of the CMVR for compliance with the rule 125H of CMVR.

AIS-140 titled “Intelligent Transportation Systems (ITS) – Requirements for Public Transport Vehicle Operation” was published originally in October 2016. There were 2 amendments to AIS 140 i.e. dated 11^th December 2017 and 5^th December 2018 respectively. This standard applies to both individual components as well as system environments to be used in public transport vehicles.

Software Considerations:

VTS is a complex co-functioning of Hardware and software. Considering the software aspects, the following are the observations as per AIS 140.

• Need: Table 3A defines “safety & security” as a function of the VLT & emergency button.
• Maintainability: As per Clause 3.1.1.9, the device shall support over the air software and configuration update.
  • Alert ID 12 “Alert over the air parameter change”, when any parameter is changed over the air. Alert shall include the name of the parameter changed and the source of the command.
  • As per Clause 4.3, the Testing of device configuration as over the air.
  • Clause 6.2.1.5 is about updating the firmware of the system from back-end control center only.
• Control: As per Amendment 2 of AIS 140, The VLT device manufacturers shall ensure that a control mechanism is established for the secure data transfer from VLT to the backend system and that only the authorized devices transfer data to the backend system.
• ●        Security Requirements: As per Clause 3.1.1.25 for functional requirement, VLT devices shall have a provision of secured data transmission to the Backend Control Centre from the devices through a secured channel (e.g. secured dedicated APN).
• Software Change Management: As per Annexure B, Criteria for extension of type approval indicates if there is a change in software of the ITS system, then the functional verification at system integration level to be conducted.
• Liability: AIS 140 doesn’t include the liability clauses, however, it demands that Firmware of the device needs to be available for auditing to notified testing agencies

In addition to the above observations, figure 1 highlights security considerations in the AIS 140 standard.

Software Tests required as per AIS 140:

Considering the above software considerations, AIS 140 prescribes software tests that are required for a safe and secure VTS. Clause 6.3 of AIS 140 defines the device level functional tests, performance & durability tests, environmental tests and protocol tests. Apart from these device-level tests, in Amendment 2, a new clause 8.0 for Code of Practice (COP) is included for implementation of VLT device with emergency button and command & control centres. Some of the practices are mentioned below:

1. The VLT device manufacturers shall ensure that a control mechanism is established for the secure data transfer from VLT to the backend system and that only the authorized devices transfer data to the backend system.
2. Clause 8.3 (s) defines that the system shall provide >99% availability, Vulnerability Analysis & Penetration Testing (VAPT) as per guidelines issued by the Ministry of Electronics, Information & Technology, GOI. Further, Table 2 of Clause 8.5 (c) defines that the VLT device manufacturers must provide a VAPT report from a 3^rd party agency authorized by CERT-In/STQC.
3. Test Parameters for auditing of VLT Device Manufacturer’s Backend Application/System as per Table 2 of Clause 8.5 (c). Some of which are as follows:
   1. Test details for firmware over-the-air update
   2. Application availability test
   3. Testing functionality of applications

10 Best Practices for System Software Safety & Security:

Considering the need and requirement for VTS as per AIS 140, the following 10 best practices are advised for system software safety & security

1. Avoid Top 25 most dangerous software errors by CWE and follow Top 10 Secure Coding Best Practices by SEI CERT. There are 2 bonus practices additionally i.e. to model threat and to define security requirements.
2. Avoid inducing known security vulnerabilities in the code. Vulnerability dictionary like CWE and CVE can be referred to. Inferences from the coding guidelines such as MISRA, CERT can also be considered.
3. To ensure that software complexity is low, software quality characteristics (Reliability, Performance Efficiency, Security & Maintainability) by the Consortium for Information & Software Quality (CISQ) can be considered.
4. Ensuring the attack surface as low as possible should be the primary effort. Performing design review, call graphs/flow graphs are some of the best practices to achieve this.
5. Making sure of no dead code or unreachable code.
6. Establish bi-directional traceability between high-level system requirements to low-level requirements, to code, to test cases, and perform the impact analysis when there is a change in requirement.
7. Suggested Tests: Penetration Testing, Unit Testing, System & Integration Testing, Robustness Testing, Fuzz Testing, Requirements based Testing, etc. These test methods will help to make the VTS system safe & secure.
8. Focus on proactive approach rather than a reactive approach and consider Functional Safety & Cyber Security in an early stage.
9. In addition to AIS 140, Follow the software life cycle processes mentioned in functional safety standard ISO 26262 Part 6 or IEEE 12207 which is a standard for “Systems and software engineering – Software life cycle processes”.
10. The use of qualified tools in the software development lifecycle.

Conclusion:

AIS 140 considers software as an integral part of the vehicle tracking system. With Amendment 2, there is an emphasis on security & software tests such as VAPT analysis, etc. Though these tests are very important, these are not enough to make software safe & secure. There is no single bullet to ensure that software is safe & secure instead it’s an ongoing process. The observed 10 best practices above would help VTS manufacturers to be one step ahead in the competition in making world-class products.

Author:

Shreyansh Shukla is a Field Application Engineer at LDRA Technology Pvt Ltd. He holds a B.Tech. degree in ECE and a Post Graduate Diploma in Embedded System Design from CDAC, Noida. He has been associated with the embedded software industry for over 5 years. Presently, he is actively guiding customers on the usage of the LDRA tool suite for Safe & Secure Coding.

Published in Telematics Wire