forked from nmfta-repo/vcr-experiment
-
Notifications
You must be signed in to change notification settings - Fork 0
/
00_tsrm.sdoc
2332 lines (1980 loc) · 109 KB
/
00_tsrm.sdoc
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
[DOCUMENT]
TITLE: NMFTA Telematics Security Requirements Matrix
[GRAMMAR]
ELEMENTS:
- TAG: REQUIREMENT
FIELDS:
- TITLE: UID
TYPE: String
REQUIRED: False
- TITLE: LEVEL
TYPE: String
REQUIRED: False
- TITLE: STATUS
TYPE: String
REQUIRED: False
- TITLE: TAGS
TYPE: String
REQUIRED: False
- TITLE: CATEGORY
TYPE: String
REQUIRED: False
- TITLE: CRITICALITY
TYPE: String
REQUIRED: False
- TITLE: TITLE
TYPE: String
REQUIRED: False
- TITLE: STATEMENT
TYPE: String
REQUIRED: False
- TITLE: RATIONALE
TYPE: String
REQUIRED: False
- TITLE: COMMENT
TYPE: String
REQUIRED: False
- TITLE: PUB_REFS
TYPE: String
REQUIRED: False
- TITLE: VERIFICATION
TYPE: String
REQUIRED: False
RELATIONS:
- TYPE: Parent
[FREETEXT]
These recommended security requirements are intended to be informative, not directional in nature. While all reasonable steps have been taken to ensure that the recommendations are well-supported by our research and third-party verification, NMFTA and the parties contributing to these recommendations do not accept liability or responsibility for any damage or harm incurred as a result of actions taken based upon these recommendations.
[/FREETEXT]
[REQUIREMENT]
UID: AA-010
CATEGORY: >>>
Audit and Accountability
<<<
CRITICALITY: >>>
Medium
<<<
STATEMENT: >>>
The vendor's system shall record event and system logs
<<<
COMMENT: >>>
Ideally the logs are immutable, backed up, and retained for a certain period of time
<<<
PUB_REFS: >>>
NIST 800-53 r5 AU-2 – EVENT LOGGING
a. Identify the types of events that the system is capable of logging in support of the audit function: [Assignment: organization-defined event types that the system is capable of logging];
b. Coordinate the event logging function with other organizational entities requiring audit related information to guide and inform the selection criteria for events to be logged;
c. Specify the following event types for logging within the system: [Assignment: organization defined event types (subset of the event types defined in AU-2a.) along with the frequency of (or situation requiring) logging for each identified event type];
d. Provide a rationale for why the event types selected for logging are deemed to be adequate to support after-the-fact investigations of incidents; and
e. Review and update the event types selected for logging [Assignment: organization-defined frequency].
CTIA CCTPID 4.7 Audit Log
<<<
VERIFICATION: >>>
Inspection of vendor-supplied documentation detailing locations where audit logs are stored and the types of events logged.
<<<
[REQUIREMENT]
UID: AC-010
CATEGORY: >>>
Protecting Data on Devices
<<<
CRITICALITY: >>>
Medium
<<<
STATEMENT: >>>
Vendor devices will implement least privilege for the memory spaces of processes handling protected data. i.e. data in-use, of the categories of sensitive protected data above, or shall be segmented from software components which do not handle such data. Acceptable segmentations include Mandatory Filesystem Access Controls and Mandatory Volatile Memory Access Controls.
<<<
COMMENT: >>>
e.g. a Linux system with MAC configured to deny access to the processes dealing with protected data and also denying debugger access to the memory space of those processes.
<<<
PUB_REFS: >>>
NIST 800-53 r5 SI-16 - MEMORY PROTECTION
Implement the following controls to protect the system memory from unauthorized
code execution: [Assignment: organization-defined controls].
NIST 800-53 r5 AC-6 (4) - LEAST PRIVILEGE | SEPARATE PROCESSING DOMAINS
Provide separate processing domains to enable finer-grained allocation of user privileges.
NIST 800-53 r5 SC-2 – SEPARATION OF SYSTEM AND USER FUNCTIONALITY
Separate user functionality, including user interface services, from system management
functionality.
NIST 800-53 r5 SC-2 (1) - SEPARATION OF SYSTEM AND USER FUNCTIONALITY | INTERFACES FOR NON-PRIVILEGED USERS
Prevent the presentation of system management functionality at interfaces to nonprivileged users.
NIST 800-53 r5 AC-25 – REFERENCE MONITOR
Implement a reference monitor for [Assignment: organization-defined access control policies] that is tamperproof, always invoked, and small enough to be subject to analysis and testing, the completeness of which can be assured.
UL 1376 3.9 Least privilege: Systems must implement 'least privilege', or utilize hardware based features to protect sensitive code and data
<<<
VERIFICATION: >>>
Inspection of vendor-supplied design documentation detailing the privilege separation of the device. Ensure that 1) a Mandatory Access Control scheme is employed 2) there are separate domains/users/roles (whichever is applicable to the MAC) for dealing with the sensitive information (vendor defined, see SCP-030) and finally 3) accounts for running system tasks (e.g. crond, portmap, systemd) are not in the separate domains/users/roles for dealing with sensitive information.
<<<
[REQUIREMENT]
UID: AC-020
CATEGORY: >>>
Protecting Actions on Devices
<<<
CRITICALITY: >>>
High
<<<
STATEMENT: >>>
All actions taken by the vendor's telematics system that are capable of supporting access controls shall be configured such that each user account or process/service account are assigned only the minimal privileges required to perform the specific, intended, actions of the user or process/service account.
<<<
COMMENT: >>>
This principle underpins system security
<<<
PUB_REFS: >>>
NIST 800-53 r5 AC-6 – LEAST PRIVILEGE
Employ the principle of least privilege, allowing only authorized accesses for users (or processes acting on behalf of users) that are necessary to accomplish assigned organizational tasks.
NIST 800-53 r5 AC-6 (1) - LEAST PRIVILEGE | AUTHORIZE ACCESS TO SECURITY FUNCTIONS
Authorize access for [Assignment: organization-defined individuals or roles] to:
(a) [Assignment: organization-defined security functions (deployed in hardware, software, and firmware)]; and
(b) [Assignment: organization-defined security-relevant information].
CTIA CCTPID 5.17 Design-In Features “designed to isolate critical functions from less critical functions”
OWASP E5 – Identity Management
<<<
VERIFICATION: >>>
Inspection of vendor documentation or a demonstration by the vendor that details how software privileges are assigned in vendor systems. Ensure that principles of least privilege are met.
<<<
[REQUIREMENT]
UID: AC-030
CATEGORY: >>>
Access Control
<<<
CRITICALITY: >>>
High
<<<
STATEMENT: >>>
The vendor's system shall employ cryptographic authentication to prevent unauthorized access to telematics systems and data.
<<<
COMMENT: >>>
Identity management is critical
e.g. PINs, single-sign on with carrier’s identity provider (SAML or other), vendor managed identity provider (SAML or other)
<<<
PUB_REFS: >>>
NIST 800-53 r5 AC-6 – LEAST PRIVILEGE
Employ the principle of least privilege, allowing only authorized accesses for users (or processes acting on behalf of users) that are necessary to accomplish assigned organizational tasks.
NIST 800-53 r5 AC-3 – ACCESS ENFORCEMENT
Enforce approved authorizations for logical access to information and system resources in accordance with applicable access control policies.
FMCSA GDL 32 Make sure local wireless interfaces like Bluetooth or Wi-Fi don't provide admin access without authentication.
UL 1376 4.1 Sensitive services require authentication: Sensitive services must require authentication and ensure the confidentiality and integrity of data
UL 1376 6.3 Authentication for remote communications: Connections to remote services must implement cryptographic authentication
<<<
VERIFICATION: >>>
Inspection of vendor documentation detailing the methods used to authenticate users. Ensure that an acceptable method of authentication is available for all components which be interfaced-to by carrier staff and systems.
In the case of single-sign-on delegation, ensure that your (carrier) system requirements are met with respect to security assertions (e.g. SAML is supported).
<<<
[REQUIREMENT]
UID: AC-040
CATEGORY: >>>
Access Control
<<<
CRITICALITY: >>>
Medium
<<<
STATEMENT: >>>
The vendor shall identify all instances where the telematics system includes actions that cannot support access authentication and/or execute with elevated privileges
<<<
PUB_REFS: >>>
NIST 800-53 r5 AC-14 – PERMITTED ACTIONS WITHOUT IDENTIFICATION OR AUTHENTICATION
a. Identify [Assignment: organization-defined user actions] that can be performed on the system without identification or authentication consistent with organizational mission and business functions; and
b. Document and provide supporting rationale in the security plan for the system, user actions not requiring identification or authentication.
NIST 800-53 r5 AC-6 – LEAST PRIVILEGE
Employ the principle of least privilege, allowing only authorized accesses for users (or processes acting on behalf of users) that are necessary to accomplish assigned organizational tasks.
<<<
VERIFICATION: >>>
Inspection of vendor-supplied documentation listing system actions and interfaces that do not require authentication. Ensure that the list is short, that each entry in the list is acceptable to you (the carrier), and there is a justifiable reason for no-authentication on each item in the list.
<<<
[REQUIREMENT]
UID: AC-041
CATEGORY: >>>
Access Control
<<<
CRITICALITY: >>>
Medium
<<<
STATEMENT: >>>
Identifying information about the connected devices will not be made available without authentication first.
<<<
COMMENT: >>>
e.g. it should not be possible to identify the device type nor firmware version by port scanning a connected device. Also, it should not be able to determine that a vehicle is operational or not via non-authorized connections.
<<<
PUB_REFS: >>>
NIST 800-53 r5 AC-14 – PERMITTED ACTIONS WITHOUT IDENTIFICATION OR AUTHENTICATION
a. Identify [Assignment: organization-defined user actions] that can be performed on the system without identification or authentication consistent with organizational mission and business functions; and
b. Document and provide supporting rationale in the security plan for the system, user actions not requiring identification or authentication.
<<<
VERIFICATION: >>>
Inspection of vendor-supplied documentation listing system actions and interfaces that do not require authentication. Ensure that no information leaks are possible from these unauthenticated actions.
<<<
[REQUIREMENT]
UID: AC-050
CATEGORY: >>>
Access Control
<<<
CRITICALITY: >>>
Medium
<<<
STATEMENT: >>>
All remote access methods and possible remote actions to/on telematics system shall be documented.
<<<
PUB_REFS: >>>
NIST 800-53 r5 AC-17 – REMOTE ACCESS
a. Establish and document usage restrictions, configuration/connection requirements, and implementation guidance for each type of remote access allowed; and
b. Authorize each type of remote access to the system prior to allowing such connections
<<<
VERIFICATION: >>>
Inspection of vendor-supplied documentation listing the methods of remote access and the actions that can be performed. Ensure that the remote access methods and actions are justifiable and also ensure that all remote methods require authentication (i.e. ensure none of them are listed in vendor documentation for AC-040)
<<<
[REQUIREMENT]
UID: AC-060
CATEGORY: >>>
Access Control
<<<
CRITICALITY: >>>
Medium
<<<
STATEMENT: >>>
For all components of the system, the vendor shall provide a listing of all wireless communication interfaces to the system and specify how the interfaces can be configured and/or disabled.
<<<
COMMENT: >>>
e.g. Bluetooth, cellular, satellite, Wi-Fi hotspot, Wi-Fi client, infrared, NFC, RFID
<<<
PUB_REFS: >>>
NIST 800-53 r5 AC-18 – WIRELESS ACCESS
a. Establish configuration requirements, connection requirements, and implementation guidance for each type of wireless access; and
b. Authorize each type of wireless access to the system prior to allowing such connections.
<<<
VERIFICATION: >>>
Inspection of vendor-supplied documentation detailing what wireless communications hardware is present, which wireless communications methods can be disabled, and how wireless communications enablement or disablement is managed.
<<<
[REQUIREMENT]
UID: AC-061
CATEGORY: >>>
Access Control
<<<
CRITICALITY: >>>
Medium
<<<
STATEMENT: >>>
The vendor shall not use any deprecated encryption+authentication on any WiFi interface of the device. At the time of drafting this includes WEP, WPS or open/none.
<<<
PUB_REFS: >>>
FMCSA GDL 39 Only use WPA2 authentication / encryption. Never use WEP, WPS, or “open” Wi-Fi.
UL 1376 6.2 Industry standard Wi-Fi security: Device must support industry accepted wireless security defaults for any Wi-Fi connections
<<<
VERIFICATION: >>>
Test that the device will not connect to WEP, WPS or open Wi-Fi hotspots.
<<<
[REQUIREMENT]
UID: AC-062
CATEGORY: >>>
Access Control
<<<
CRITICALITY: >>>
Medium
<<<
STATEMENT: >>>
The vendor shall implement, for all bluetooth interfaces, pairing that must be specifically allowed by physical controls on the device and be time-limited. Furthermore, pairing will not use legacy pairing or passkey entry.
<<<
PUB_REFS: >>>
FMCSA GDL 44 Make sure Bluetooth devices support and use Secure Simple Pairing (SSP) rather than legacy pairing.
FMCSA GDL 45 Numeric Comparison is preferred to Passkey Entry for pairing.
<<<
VERIFICATION: >>>
Test that it is not possible to pair with the device 5 minutes after enabling pairing on the device. Test that pairing does not support SSP or passkey, only numeric comparison.
<<<
[REQUIREMENT]
UID: AC-063
CATEGORY: >>>
Access Control
<<<
CRITICALITY: >>>
Medium
<<<
STATEMENT: >>>
Any and all software or firmware implementing wireless interface encrytion+authentication (those satisfying AC-061 and AC-062 above) will be prepared for future deprecation of methods. i.e. That software/firmware is upgradable.
<<<
VERIFICATION: >>>
Inspection of vendor-supplied documentation confirming upgradability of the software implementing encryption+authentication of wireless interfaces.
<<<
[REQUIREMENT]
UID: AC-070
CATEGORY: >>>
Identification and Authentication
<<<
CRITICALITY: >>>
Medium
<<<
STATEMENT: >>>
Authentication attempts to the vendor’s devices and backends shall be rate-limited to an industry accepted rate.
<<<
PUB_REFS: >>>
NIST 800-53 r5 AC-7 - UNSUCCESSFUL LOGON ATTEMPTS
a. Enforce a limit of [Assignment: organization-defined number] consecutive invalid logon attempts by a user during a [Assignment: organization-defined time period]; and
b. Automatically [Selection (one or more): lock the account or node for an [Assignment: organization-defined time period]; lock the account or node until released by an administrator; delay next logon prompt per [Assignment: organization-defined delay algorithm]; notify system administrator; take other [Assignment: organization-defined action]] when the maximum
number of unsuccessful attempts is exceeded.
CTIA CCTPID 5.2 Password Management Test
UL 1376 2.8 Brute force protection: Implement protection against brute force attacks
<<<
VERIFICATION: >>>
Inspection of vendor-supplied documentation detailing the methods used to enforce rate limiting.
<<<
[REQUIREMENT]
UID: AC-080
CATEGORY: >>>
Device-Local Authentication
<<<
CRITICALITY: >>>
Medium
<<<
STATEMENT: >>>
All authentication offered on device-local interfaces shall expect credentials which are unique to each device instance and uncorrelated to any and all public information about the device.
<<<
COMMENT: >>>
This requirement applies to many common facilities found on devices. e.g. local management portals, local Wi-Fi access points, Bluetooth pairing codes, local ssh servers, local serial console logins
<<<
PUB_REFS: >>>
ETSI EN 303 645 V2.1.0 Provision 5.1-1 Where passwords are used and in any state other than the factory default, all consumer IoT device passwords shall be unique per device or defined by the user.
FMCSA GDL 32 Make sure local wireless interfaces like Bluetooth or Wi-Fi don't provide admin access without authentication.
FMCSA GDL 40 Always use a complex, unique password per device.
FMCSA GDL 43 Always use a complex, unique password per device.
<<<
VERIFICATION: >>>
Inspection of vendor-supplied documentation detailing the local authentication and how the unique credential is generated. Ensure that the generation of this credential cannot be guessed from public information.
<<<
[REQUIREMENT]
UID: CM-010
CATEGORY: >>>
Protecting Actions on Devices
<<<
CRITICALITY: >>>
Medium
<<<
STATEMENT: >>>
All components of the vendor's system shall be configured to utilize the principle of least functionality and use only the services necessary for secure operations of the system. Additionally, customers should have the option of disabling any features they do not want or do not need by having unnecessary services’ executables removed or at least disabled such that their execution (by even superuser) is not possible in deployed systems.
<<<
COMMENT: >>>
E.g. this is particularly true of unauthenticated or unencrypted transport services (which would not satisfy protected communication requirements above) such as File Transfer Protocol, telnet, Short Messaging Service, etc.
<<<
PUB_REFS: >>>
NIST 800-53 r5 CM-7 – LEAST FUNCTIONALITY
a. Configure the system to provide only [Assignment: organization-defined mission essential capabilities]; and
b. Prohibit or restrict the use of the following functions, ports, protocols, software, and/or services: [Assignment: organization-defined prohibited or restricted functions, system ports, protocols, software, and/or services].
CTIA CCTPID 5.17 Design-In Features “designed to deny all inbound and outbound network communications, except for those that are essential for the device to operate properly“
FMCSA GDL 20 Give applications the least privilege they need to function
FMCSA GDL 21 Where possible, remove code that isn't used
OWASP E6 – Embedded Framework and C-Based Hardening
UL 1376 3.3 Unwanted functionality can be disabled: Customer access to disable unwanted features
UL 1376 3.6 Unwanted / Unnecessary features removed: Unwanted / unnecessary features are removed
<<<
VERIFICATION: >>>
Inspection of vendor documentation asserting that unnecessary software or services are not present or disabled on the device.
<<<
[REQUIREMENT]
UID: CM-020
CATEGORY: >>>
Configuration Management
<<<
CRITICALITY: >>>
High
<<<
STATEMENT: >>>
The vendor’s devices shall have all services used for troubleshooting disabled or properly protected from unauthorized access and use.
<<<
COMMENT: >>>
Deploying with test or debug facilities enabled is egregious
<<<
PUB_REFS: >>>
NIST 800-53 r5 CM-7 – LEAST FUNCTIONALITY
a. Configure the system to provide only [Assignment: organization-defined mission essential capabilities]; and
b. Prohibit or restrict the use of the following functions, ports, protocols, software, and/or services: [Assignment: organization-defined prohibited or restricted functions, system ports, protocols, software, and/or services].
FMCSA GDL 54 Disable unnecessary debugging interfaces in production.
FMCSA GDL 55 Authenticate debugging and diagnostic interfaces.
<<<
VERIFICATION: >>>
Inspection of vendor-supplied documentation detailing all services (listening ports or outbound connections) available on deployed devices.
Ensure that none of the services available are without authentication (see AC-030) and furthermore that any troubleshooting functionality is ideally disabled, or at least the service available requires unique credentials for authorization of that feature.
<<<
[REQUIREMENT]
UID: CM-030
CATEGORY: >>>
Configuration Management
<<<
CRITICALITY: >>>
High
<<<
STATEMENT: >>>
Vendor ensures that any and all interfaces used for testing or debug are unavailable in production builds of the devices
<<<
COMMENT: >>>
Deploying with test or debug facilities enabled is egregious.
Functionality that allows for the direct execution of scripts or commands by the device or system can often be exploited by a malicious party and therefore must be disabled.
<<<
PUB_REFS: >>>
NIST 800-53 r5 CM-7 – LEAST FUNCTIONALITY
a. Configure the system to provide only [Assignment: organization-defined mission essential capabilities]; and
b. Prohibit or restrict the use of the following functions, ports, protocols, software, and/or services: [Assignment: organization-defined prohibited or restricted functions, system ports, protocols, software, and/or services].
CAIQ CCC-03.6 Are mechanisms in place to ensure that all debugging and test code elements are removed from released software versions?
FMCSA GDL 31 Make sure debugging interfaces (JTAG, serial, USB) have authentication required.
FMCSA GDL 54 Disable unnecessary debugging interfaces in production.
FMCSA GDL 55 Authenticate debugging and diagnostic interfaces.
OWASP E7 – Usage of Debug Code and Interfaces
UL 1376 3.1 Protect communication and debug ports: Communication and debug ports must be protected against misuse
UL 1376 4.4 No direct execution of commands / scripts: No direct execution of scripts / commands using system interfaces and or user-facing components
<<<
VERIFICATION: >>>
Inspection of vendor-supplied documentation detailing all service (listening ports or outbound connections) available on deployed devices.
Ensure that there are no services for test or debug active in the device. Ideally, look for assurances that any test or debug executables cannot be run on the device.
<<<
[REQUIREMENT]
UID: CM-040
CATEGORY: >>>
Configuration Management
<<<
CRITICALITY: >>>
High
<<<
STATEMENT: >>>
The vendors’ devices shall have a default system configuration that ensures security ‘out of the box’. In other words, the default configuration should be the most-secure and any additional features should be disabled by default and have their security implications communicated in documentation.
<<<
COMMENT: >>>
Sufficient customer guidance should be provided to allow for that customer to understand the risks associated with enabling any insecure features of the device.
<<<
PUB_REFS: >>>
UL 1376 3.2 Systems configured to secure defaults: Systems must be configured to secure defaults
<<<
VERIFICATION: >>>
Inspection of vendor-supplied documentation confirming that a) all device configuration options have their security tradeoffs documented and that b) the device’s default configuration is the most-secure.
<<<
[REQUIREMENT]
UID: IA-010
CATEGORY: >>>
Identification and Authentication
<<<
CRITICALITY: >>>
Medium
<<<
STATEMENT: >>>
All remote hosts of the vendor's system shall be configured to uniquely identify and authenticate all other remote hosts of the system and/or any other interfacing systems.
<<<
COMMENT: >>>
e.g. that a remote system authenticate the other remote parties by referring to the unique identifiers using mutually authenticated TLS
<<<
PUB_REFS: >>>
NIST 800-53 r5 IA-3 – DEVICE IDENTIFICATION AND AUTHENTICATION
Uniquely identify and authenticate [Assignment: organization-defined devices and/or types of devices] before establishing a [Selection (one or more): local; remote; network] connection.
<<<
VERIFICATION: >>>
Inspection of vendor-supplied documentation detailing how devices and components are uniquely identified.
Ensure that interfacing systems can query and/or inspect these unique identifiers.
<<<
[REQUIREMENT]
UID: IA-020
CATEGORY: >>>
Identification and Authentication
<<<
CRITICALITY: >>>
Medium
<<<
STATEMENT: >>>
Any authenticators (unique identification) for devices used in vendor’s systems shall be uncorrelated to any and all public information about the device, e.g. lot number, product number, serial number MAC address are all unacceptable inputs to device identifiers.
Where public information is any information that is visible (externally or internally) on the device or discoverable by searches based on that visible information.
<<<
PUB_REFS: >>>
NIST 800-53 r5 IA-3 – DEVICE IDENTIFICATION AND AUTHENTICATION
Uniquely identify and authenticate [Assignment: organization-defined devices and/or types of devices] before establishing a [Selection (one or more): local; remote; network] connection.
<<<
VERIFICATION: >>>
Inspection of vendor documentation detailing the inputs to the authenticator generation process per device. Ensure that no input is information that can be easily-guessed from simple facts about the device.
<<<
[REQUIREMENT]
UID: IA-030
CATEGORY: >>>
Identification and Authentication
<<<
CRITICALITY: >>>
Medium
<<<
STATEMENT: >>>
Cryptographic modules used in the vendors system shall be compliant with Federal Information Processing Standards (FIPS) 140-2: Level 1.
<<<
COMMENT: >>>
e.g.
• For each attempt to use the authentication mechanism, the probability shall be less than one in 1,000,000 that a random attempt will succeed, or a false acceptance will occur (e.g., guessing a password or PIN, false acceptance error rate of a biometric device, or some combination of authentication methods)
• For multiple attempts to use the authentication mechanism during a one-minute period, the probability shall be less than one in 100,000 that a random attempt will succeed, or a false acceptance will occur
• Feedback of authentication data to an operator shall be obscured during authentication (e.g., no visible display of characters when entering a password).
• Feedback provided to an operator during an attempted authentication shall not weaken the strength of the authentication mechanism
<<<
PUB_REFS: >>>
NIST 800-57 Part 3 r1 - 2.3.3 Cryptographic Modules
3. Ensure that relying party and user cryptographic modules are validated as meeting FIPS 140-2 Level 1 or higher.
UL 1376 2.4 Industry-standard cryptography: Industry standard cryptographic algorithms must be used for security services.
UL 1376 2.5 RNG with sufficient entropy: Random number generation must ensure sufficient entropy
<<<
VERIFICATION: >>>
Inspection of vendor-supplied documentation detailing their procurement requirements for cryptographic modules.
Ensure that their procurement processes require that all cryptographic modules are FIPS 140-2 compliant.
<<<
[REQUIREMENT]
UID: IR-010
CATEGORY: >>>
Incidence Response
<<<
CRITICALITY: >>>
High
<<<
STATEMENT: >>>
The vendor shall have a documented incident response plan (IRP) in place which provides the carriers with a point of contact for components used within their telematics system
<<<
COMMENT: >>>
TSPs must demonstrate this level of maturity to be trusted with business critical functions
<<<
PUB_REFS: >>>
NIST 800-53 r5 IR-8 - INCIDENT RESPONSE PLAN
a. Develop an incident response plan that:
1. Provides the organization with a roadmap for implementing its incident response capability;
2. Describes the structure and organization of the incident response capability;
3. Provides a high-level approach for how the incident response capability fits into the overall organization;
4. Meets the unique requirements of the organization, which relate to mission, size, structure, and functions;
5. Defines reportable incidents;
6. Provides metrics for measuring the incident response capability within the organization;
7. Defines the resources and management support needed to effectively maintain and mature an incident response capability;
8. Addresses the sharing of incident information;
9. Is reviewed and approved by [Assignment: organization-defined personnel or roles] [Assignment: organization-defined frequency]; and
10. Explicitly designates responsibility for incident response to [Assignment: organization defined entities, personnel, or roles].
b. Distribute copies of the incident response plan to [Assignment: organization-defined incident response personnel (identified by name and/or by role) and organizational elements];
c. Update the incident response plan to address system and organizational changes or problems encountered during plan implementation, execution, or testing;
d. Communicate incident response plan changes to [Assignment: organization-defined incident response personnel (identified by name and/or by role) and organizational elements]; and
e. Protect the incident response plan from unauthorized disclosure and modification.
FMCSA GDL 14 Employ an incident response process.
<<<
VERIFICATION: >>>
Inspection of vendor-supplied documentation detailing the vendor’s incident response process.
Ensure that it documents the methods that can be used to notify the vendor of a security incident.
<<<
[REQUIREMENT]
UID: M-010
CATEGORY: >>>
Maintenance
<<<
CRITICALITY: >>>
Medium
<<<
STATEMENT: >>>
The vendor shall have procedures in place to ensure that components outside of the carrier’s direct control are not updated or modified without prior coordination and approval by an organization-defined individual or role
<<<
PUB_REFS: >>>
NIST 800-53 r5 MA-2 – CONTROLLED MAINTENANCE
a. Schedule, document, and review records of maintenance, repair, and replacement on system components in accordance with manufacturer or vendor specifications and/or organizational requirements;
b. Approve and monitor all maintenance activities, whether performed on site or remotely and whether the system or system components are serviced on site or removed to another location;
c. Require that [Assignment: organization-defined personnel or roles] explicitly approve the removal of the system or system components from organizational facilities for off-site maintenance, repair, or replacement;
d. Sanitize equipment to remove the following information from associated media prior to removal from organizational facilities for off-site maintenance, repair, or replacement: [Assignment: organization-defined information];
e. Check all potentially impacted controls to verify that the controls are still functioning properly following maintenance, repair, or replacement actions; and
f. Include the following information in organizational maintenance records: [Assignment: organization-defined information].
<<<
VERIFICATION: >>>
Inspection of vendor-supplied documentation detailing their maintenance/release process.
Ensure that there is a process where you (the carrier) are contacted and coordinated-with before the systems upon which you rely undergo maintenance procedures.
<<<
[REQUIREMENT]
UID: M-020
CATEGORY: >>>
Maintenance
<<<
CRITICALITY: >>>
High
<<<
STATEMENT: >>>
The vendor shall have procedures in place to test backup restoration processes of their own systems and their own facilities on at least an annual basis.
<<<
COMMENT: >>>
TSPs must demonstrate this level of maturity to be trusted with business critical functions
<<<
PUB_REFS: >>>
NIST 800-53 r5 CP-4 - CONTINGENCY PLAN TESTING
a. Test the contingency plan for the system [Assignment: organization-defined frequency] using the following tests to determine the effectiveness of the plan and the readiness to execute the plan: [Assignment: organization-defined tests].
b. Review the contingency plan test results; and
c. Initiate corrective actions, if needed.
NIST 800-53 r5 CP-9 (1) - SYSTEM BACKUP | TESTING FOR RELIABILITY AND INTEGRITY
Test backup information [Assignment: organization-defined frequency] to verify media reliability and information integrity.
CAIQ BCR-11.7 Do you test your backup or redundancy mechanisms at least annually?
<<<
VERIFICATION: >>>
Inspection of vendor-supplied documentation detailing backup and restore procedures.
<<<
[REQUIREMENT]
UID: M-030
CATEGORY: >>>
Disposal of Goods
<<<
CRITICALITY: >>>
High
<<<
STATEMENT: >>>
The vendor must have a disposal of goods policy which covers the management of all computer equipment and storage media dealing with customer information including but not limited to PII and customer business operations data.
<<<
PUB_REFS: >>>
ISO 27001 A.8.3.2 Disposal of Media
NIST 800-88 R1
<<<
VERIFICATION: >>>
Inspection of vendor-supplied documentation detailing their disposal of goods procedures; confirm the presence of specific mention of handling of their customer's information.
<<<
[REQUIREMENT]
UID: M-031
CATEGORY: >>>
Disposal of Goods
<<<
CRITICALITY: >>>
Medium
<<<
STATEMENT: >>>
The vendor's disposal of goods policy must forbid disposal in skips, dumps or landfills until it has been processed to purge or clear previously stored information.
<<<
PUB_REFS: >>>
ISO 27001 A.8.3.2 Disposal of Media
NIST 800-88 R1
<<<
VERIFICATION: >>>
Inspection of vendor-supplied documentation detailing their disposal of goods procedures; confirm that disposal of systems in skips or landfills is not allowed unless the systems have been purged or cleared.
<<<
[REQUIREMENT]
UID: M-032
CATEGORY: >>>
Disposal of Goods
<<<
CRITICALITY: >>>
Low
<<<
STATEMENT: >>>
The vendor's processes to remove previously stored information must include acceptable processes for magnetic media, solid-state media, printers, scanners, laptops, smartphones, server and desktop computers.
<<<
PUB_REFS: >>>
NIST 800-88 R1 Appendix A -- Minimum Sanitization Recommendations
<<<
VERIFICATION: >>>
Inspection of vendor-supplied documentation detailing their disposal of goods procedures; confirm that there are procedures that cover all of magnetic media, solid-state media, printers, scanners, laptops, smartphones, server and desktop computers
<<<
[REQUIREMENT]
UID: M-040
CATEGORY: >>>
Maintenance
<<<
CRITICALITY: >>>
High
<<<
STATEMENT: >>>
Vendors must provide manual backup/override capabilities to their safety related services to ensure that any failure of the device does not result in a safety issue.
<<<
PUB_REFS: >>>
UL 1376 4.3 Manual back-up / override for safety critical operations: Manual backup/override must be provided for safety related services
<<<
VERIFICATION: >>>
Inspection of vendor-supplied documentation detailing the system’s safety related services and the manual backup/override associated with them. Test the manual override capabilities to confirm their functionality.
<<<
[REQUIREMENT]
UID: P-010
CATEGORY: >>>
Planning
<<<
CRITICALITY: >>>
Medium
<<<
STATEMENT: >>>
The vendor shall have a System Security Plan (SSP) which details a clear and concise understanding of authorization boundaries of the telematics system.
<<<
PUB_REFS: >>>
NIST 800-53 r5 PL-2 - SECURITY AND PRIVACY PLANS
a. Develop security and privacy plans for the system that:
1. Are consistent with the organization’s enterprise architecture;
2. Explicitly define the constituent system components;
3. Describe the operational context of the system in terms of mission and business processes;
4. Identify the individuals that fulfill system roles and responsibilities;
5. Identify the information types processed, stored, and transmitted by the system;
6. Provide the security categorization of the system, including supporting rationale;
7. Describe any specific threats to the system that are of concern to the organization;
8. Provide the results of a privacy risk assessment for systems processing personally identifiable information;
9. Describe the operational environment for the system and any dependencies on or connections to other systems or system components;
10. Provide an overview of the security and privacy requirements for the system;
11. Identify any relevant control baselines or overlays, if applicable;
12. Describe the controls in place or planned for meeting the security and privacy requirements, including a rationale for any tailoring decisions;
13. Include risk determinations for security and privacy architecture and design decisions;
14. Include security- and privacy-related activities affecting the system that require planning and coordination with [Assignment: organization-defined individuals or groups]; and
15. Are reviewed and approved by the authorizing official or designated representative prior to plan implementation.
b. Distribute copies of the plans and communicate subsequent changes to the plans to [Assignment: organization-defined personnel or roles];
c. Review the plans [Assignment: organization-defined frequency];
d. Update the plans to address changes to the system and environment of operation or problems identified during plan implementation or control assessments; and
e. Protect the plans from unauthorized disclosure and modification.
<<<
VERIFICATION: >>>
Inspection of vendor-supplied SSP document that details the authorization boundaries of telematics system.
Ensure that the document details which entity has responsibility for each component of the system, the system baseline and security posture within the boundaries.
<<<
[REQUIREMENT]
UID: P-020
CATEGORY: >>>
Planning
<<<
CRITICALITY: >>>
Medium
<<<
STATEMENT: >>>
The vendor shall have a documented Information Security Architecture (ISA) for the telematics system.
<<<
PUB_REFS: >>>
NIST 800-53 r5 PL-8 - SECURITY AND PRIVACY ARCHITECTURES
a. Develop security and privacy architectures for the system that:
1. Describe the requirements and approach to be taken for protecting the confidentiality, integrity, and availability of organizational information;
2. Describe the requirements and approach to be taken for processing personally identifiable information to minimize privacy risk to individuals;
3. Describe how the architectures are integrated into and support the enterprise architecture; and
4. Describe any assumptions about, and dependencies on, external systems and services;
b. Review and update the architectures [Assignment: organization-defined frequency] to reflect changes in the enterprise architecture; and
c. Reflect planned architecture changes in security and privacy plans, Concept of Operations (CONOPS), criticality analysis, organizational procedures, and procurements and acquisitions.
<<<
VERIFICATION: >>>
Inspection of vendor-supplied ISA documentation.
Ensure that the ISA document at a minimum includes:
Approach to confidentiality, integrity, and availability protections
How the telematics system’s security architecture supports the enterprise architecture’s security
Security assumptions and dependencies on external services
Frequency of reviews and updates to the telematics system security architecture
<<<
[REQUIREMENT]
UID: P-030
CATEGORY: >>>
Planning
<<<
CRITICALITY: >>>
High
<<<
STATEMENT: >>>
The vendor shall provide interfaces to their backend using the Open Telematics API -- enabling carriers to have failover to other providers to avoid interruptions due to single point of failure in provider telematics services.
<<<
COMMENT: >>>
Telematics is business critical to the carriers, failover is needed for this service
<<<
PUB_REFS: >>>
CAIQ BCR-01.1 Does your organization have a plan or framework for business continuity management or disaster recovery management?
CAIQ BCR-01.6 Do you provide a tenant-triggered failover option?
<<<
VERIFICATION: >>>
Inspection of vendor-supplied documentation detailing the interfaces (APIs) offered by the vendor.
Ensure that your (carrier) systems can failover to other providers with the same interfaces (APIs).
<<<
[REQUIREMENT]
UID: PS-010
CATEGORY: >>>
Personnel Security
<<<
CRITICALITY: >>>
Medium
<<<
STATEMENT: >>>
The vendor shall have personnel security policies & procedures, position risk categorization, personnel screening, personnel termination, personnel transfer, access agreements and third-party personnel security.
<<<
PUB_REFS: >>>
NIST 800-53 r5 PS-1 - POLICY AND PROCEDURES
a. Develop, document, and disseminate to [Assignment: organization-defined personnel or roles]:
1. [Selection (one or more): Organization-level; Mission/business process-level; System level] personnel security policy that:
(a) Addresses purpose, scope, roles, responsibilities, management commitment, coordination among organizational entities, and compliance; and
(b) Is consistent with applicable laws, executive orders, directives, regulations, policies, standards, and guidelines; and
2. Procedures to facilitate the implementation of the personnel security policy and the associated personnel security controls;
b. Designate an [Assignment: organization-defined official] to manage the development, documentation, and dissemination of the personnel security policy and procedures; and
c. Review and update the current personnel security:
1. Policy [Assignment: organization-defined frequency] and following [Assignment: organization-defined events]; and
2. Procedures [Assignment: organization-defined frequency] and following [Assignment: organization-defined events].
NIST 800-53 r5 PS-7 - EXTERNAL PERSONNEL SECURITY
a. Establish personnel security requirements, including security roles and responsibilities for external providers;
b. Require external providers to comply with personnel security policies and procedures established by the organization;
c. Document personnel security requirements;
d. Require external providers to notify [Assignment: organization-defined personnel or roles] of any personnel transfers or terminations of external personnel who possess organizational credentials and/or badges, or who have system privileges within [Assignment: organization defined time period]; and
e. Monitor provider compliance with personnel security requirements.
<<<
VERIFICATION: >>>
Inspection of vendor-supplied documents detailing their personal security policies & procedures.
<<<
[REQUIREMENT]
UID: RA-010
CATEGORY: >>>
Risk Assessment
<<<
CRITICALITY: >>>
Medium
<<<
STATEMENT: >>>
Vendor shall have risk assessments conducted at an industry accepted rate. Resulting risk assessment documentation should include all components and the overall system that is within the vendor's control. The rate suggested is twice per product release; both at product design and at integration phases
<<<
PUB_REFS: >>>
NIST 800-53 r5 RA-3 – RISK ASSESSMENT
a. Conduct a risk assessment, including:
1. Identifying threats to and vulnerabilities in the system;
2. Determining the likelihood and magnitude of harm from unauthorized access, use, disclosure, disruption, modification, or destruction of the system, the information it processes, stores, or transmits, and any related information; and
3. Determining the likelihood and impact of adverse effects on individuals arising from the processing of personally identifiable information;
b. Integrate risk assessment results and risk management decisions from the organization and mission or business process perspectives with system-level risk assessments;
c. Document risk assessment results in [Selection: security and privacy plans; risk assessment report; [Assignment: organization-defined document]];
d. Review risk assessment results [Assignment: organization-defined frequency];
e. Disseminate risk assessment results to [Assignment: organization-defined personnel or roles]; and
f. Update the risk assessment [Assignment: organization-defined frequency] or when there are significant changes to the system, its environment of operation, or other conditions that may impact the security or privacy state of the system.
FMCSA GDL 1 Conduct architectural analysis and/or threat modeling during system design
<<<
VERIFICATION: >>>
Inspection of vendor-supplied documentation stating their previous and planned risk assessment dates and detailing the documentation requirements of their risk assessments.
<<<
[REQUIREMENT]
UID: RA-020
CATEGORY: >>>
Risk Assessment
<<<
CRITICALITY: >>>
Medium
<<<
STATEMENT: >>>
The vendor shall use the results of risk assessments to influence systems development and processes.
<<<
PUB_REFS: >>>
NIST 800-53 r5 RA-3 – RISK ASSESSMENT
a. Conduct a risk assessment, including:
1. Identifying threats to and vulnerabilities in the system;
2. Determining the likelihood and magnitude of harm from unauthorized access, use, disclosure, disruption, modification, or destruction of the system, the information it processes, stores, or transmits, and any related information; and
3. Determining the likelihood and impact of adverse effects on individuals arising from the processing of personally identifiable information;
b. Integrate risk assessment results and risk management decisions from the organization and mission or business process perspectives with system-level risk assessments;
c. Document risk assessment results in [Selection: security and privacy plans; risk assessment report; [Assignment: organization-defined document]];
d. Review risk assessment results [Assignment: organization-defined frequency];
e. Disseminate risk assessment results to [Assignment: organization-defined personnel or roles]; and
f. Update the risk assessment [Assignment: organization-defined frequency] or when there are significant changes to the system, its environment of operation, or other conditions that may impact the security or privacy state of the system.
CAIQ GRM-08.1 Do risk assessment results include updates to security policies, procedures, standards, and controls to ensure they remain relevant and effective?
FMCSA GDL 1 Conduct architectural analysis and/or threat modeling during system design
<<<
VERIFICATION: >>>
Inspection of vendor-supplied statement of the use of risk assessments in influencing the ongoing development of their products.
<<<
[REQUIREMENT]
UID: SAA-010
CATEGORY: >>>
Security Management
<<<
CRITICALITY: >>>
High
<<<
STATEMENT: >>>
The vendor shall have an Information Security Management Plan (ISMP).
<<<
COMMENT: >>>
Sometimes referred to as ISMS as in ISO/IEC 2700.
May include any of the following:
System interconnections, System monitoring plan,
Vulnerability management plan, Incident response plan (see IR-010 for authoritative requirement), System Security Plan (SSP) or System Security , Authorization Agreement (SSAA), Contingency Plan, Contingency Plan Test Results, Federal Information Processing Standards (FIPS) 199 Categorization, Privacy Threshold Analysis (PTA), E-Authentication, Security Test and Evaluation (ST&E) Plan, Plan of Action and Milestones (POAM), Annual Self-Assessments
<<<
PUB_REFS: >>>
NIST 800-53 r5 CA-2 - CONTROL ASSESSMENTS
a. Select the appropriate assessor or assessment team for the type of assessment to be conducted;
b. Develop a control assessment plan that describes the scope of the assessment including:
1. Controls and control enhancements under assessment;
2. Assessment procedures to be used to determine control effectiveness; and
3. Assessment environment, assessment team, and assessment roles and responsibilities;
c. Ensure the control assessment plan is reviewed and approved by the authorizing official or designated representative prior to conducting the assessment;
d. Assess the controls in the system and its environment of operation [Assignment: organization-defined frequency] to determine the extent to which the controls are implemented correctly, operating as intended, and producing the desired outcome with respect to meeting established security and privacy requirements;
e. Produce a control assessment report that document the results of the assessment; and
f. Provide the results of the control assessment to [Assignment: organization-defined individuals or roles].
NIST 800-53 r5 CA-5 - PLAN OF ACTION AND MILESTONES
a. Develop a plan of action and milestones for the system to document the planned remediation actions of the organization to correct weaknesses or deficiencies noted during the assessment of the controls and to reduce or eliminate known vulnerabilities in the system; and
b. Update existing plan of action and milestones [Assignment: organization-defined frequency] based on the findings from control assessments, independent audits or reviews, and continuous monitoring activities.
NIST 800-53 r5 CA-6 - AUTHORIZATION