-
Notifications
You must be signed in to change notification settings - Fork 706
/
Copy pathpcidss_4.yml
4066 lines (3815 loc) · 160 KB
/
pcidss_4.yml
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
policy: PCI-DSS
title: Payment Card Industry - Data Security Standard (PCI-DSS)
id: pcidss_4
version: '4.0'
source: https://docs-prv.pcisecuritystandards.org/PCI%20DSS/Standard/PCI-DSS-v4_0.pdf
levels:
- id: base
reference_type: pcidss4
controls:
- id: '1.1'
title: 'Processes and mechanisms for installing and maintaining network security
controls are defined and understood.'
levels:
- base
status: manual
controls:
- id: 1.1.1
title: 'All security policies and operational procedures that are identified in
Requirement 1 are Documented, Kept up to date, In use and Known to all affected parties.'
levels:
- base
status: manual
notes: |-
Examine documentation and interview personnel to verify that security policies and
operational procedures identified in Requirement 1 are managed in accordance with all
elements specified in this requirement.
- id: 1.1.2
title: 'Roles and responsibilities for performing activities in Requirement 1 are
documented, assigned, and understood.'
levels:
- base
status: manual
notes: |-
Examine documentation and interview personnel to verify that day-to-day responsibilities
for performing all the activities in Requirement 1 are documented, assigned and understood
by the assigned personnel.
- id: '1.2'
title: 'Network Security Controls (NSCs) are configured and maintained.'
levels:
- base
status: automated
controls:
- id: 1.2.1
title: 'Configuration standards for NSC rulesets are Defined, Implemented and Maintained.'
levels:
- base
status: automated
notes: |-
Examples of NSCs covered by these configuration standards include, but are not limited to,
firewalls, routers configured with access control lists, and cloud virtual networks. The
objective of this requirement is to ensure the way that NSCs are configured and operate
are defined and consistently applied. While the tooling and standards can be automated,
the review of allowed accesses should be manual as different sites may have different
policies.
rules:
- package_nftables_installed
- package_firewalld_installed
- service_firewalld_enabled
- service_nftables_disabled
- id: 1.2.2
title: 'All changes to network connections and to configurations of NSCs are approved and
managed in accordance with the change control process defined at Requirement 6.5.1.'
levels:
- base
status: manual
notes: |-
Changes to network connections and NSCs cannot result in misconfiguration, implementation
of insecure services, or unauthorized network connections. Changes to network connections
include the addition, removal, or modification of a connection. Changes to NSC
configurations include those related to the component itself as well as those affecting
how it performs its security function. A formal change control process should be in place.
- id: 1.2.3
title: 'An accurate network diagram(s) is maintained that shows all connections between the
CDE and other networks, including any wireless networks.'
levels:
- base
status: manual
notes: |-
A representation of the boundaries between the CDE, all trusted networks, and all
untrusted networks, is maintained and available. A current network diagram(s) or other
technical or topological solution that identifies network connections and devices can be
used to meet this requirement.
- id: 1.2.4
title: 'An accurate data-flow diagram(s) is maintained'
description: |-
An accurate data-flow diagram(s) is maintained that meets the following:
- Shows all account data flows across systems and networks
- Updated as needed upon changes to the environment
levels:
- base
status: manual
- id: 1.2.5
title: 'All services, protocols, and ports allowed are identified, approved, and have a
defined business need.'
levels:
- base
status: manual
related_rules:
- configure_firewalld_ports
- id: 1.2.6
title: Security features are defined and implemented for all services, protocols, and ports
that are in use and considered to be insecure, such that the risk is mitigated.
levels:
- base
status: automated
notes: |-
The specific risks associated with the use of insecure services, protocols, and ports are
understood, assessed, and appropriately mitigated. The selected rules here basically
remove services without encryption and restricted some common services.
rules:
- grub2_enable_selinux
- package_libselinux_installed
- selinux_policytype
- var_selinux_policy_name=targeted
- selinux_state
- var_selinux_state=enforcing
- selinux_confinement_of_daemons
- id: 1.2.7
title: Configurations of NSCs are reviewed at least once every six months to confirm they
are relevant and effective.
description: |-
NSC configurations that allow or restrict access to trusted networks are verified
periodically to ensure that only authorized connections with a current business
justification are permitted.
levels:
- base
status: manual
notes: |-
Some configuration automation solution, such as Ansible could be helpful here.
- id: 1.2.8
title: Configuration files for NSCs are secured from unauthorized access and kept consistent
with active network configurations.
levels:
- base
status: automated
rules:
- file_groupowner_etc_issue_net
- file_owner_etc_issue_net
- file_permissions_etc_issue_net
- network_nmcli_permissions
- id: '1.3'
title: Network access to and from the cardholder data environment is restricted.
levels:
- base
status: partial
controls:
- id: 1.3.1
title: Inbound traffic to the CDE is restricted to only traffic that is necessary
description: |-
Inbound traffic to the CDE is restricted as follows:
- To only traffic that is necessary.
- All other traffic is specifically denied.
levels:
- base
status: automated
rules:
- configure_firewalld_ports
- ensure_firewall_rules_for_open_ports
- set_firewalld_default_zone
- nftables_ensure_default_deny_policy
- id: 1.3.2
title: Outbound traffic from the CDE is restricted to only traffic that is necessary
description: |-
Outbound traffic from the CDE is restricted as follows:
- To only traffic that is necessary.
- All other traffic is specifically denied.
levels:
- base
status: pending
notes: |-
It appears there is no rule in the project to restrict outbound traffic on the firewall.
Perhaps a rule to automates this would do more harm than good. Probably a manual
assessment is more reasonable here.
- id: 1.3.3
title: NSCs are installed between all wireless networks and the CDE, regardless of whether
the wireless network is a CDE.
description: |-
NSCs are installed between all wireless networks and the CDE, regardless of whether the
wireless network is a CDE, such that:
- All wireless traffic from wireless networks into the CDE is denied by default.
- Only wireless traffic with an authorized business purpose is allowed into the CDE.
levels:
- base
status: automated
notes: |-
Wireless interfaces are not expected in servers so they are disabled by default in this
policy.
rules:
- wireless_disable_interfaces
- id: '1.4'
title: Network connections between trusted and untrusted networks are controlled.
levels:
- base
status: partial
controls:
- id: 1.4.1
title: NSCs are implemented between trusted and untrusted networks.
description: |-
Unauthorized traffic cannot traverse network boundaries between trusted and untrusted
networks.
levels:
- base
status: automated
notes: |-
Trusted and untrusted networks are expected to be different for each environment.
But loopback traffic is assumed to be trusted and even necessary for some services.
This requirement is complements 1.2.1 and 1.3.1 requirements.
rules:
- firewalld_loopback_traffic_restricted
- firewalld_loopback_traffic_trusted
- set_ipv6_loopback_traffic
- set_ip6tables_default_rule
- set_loopback_traffic
- id: 1.4.2
title: Inbound traffic from untrusted networks to trusted networks is restricted.
description: |-
Inbound traffic from untrusted networks to trusted networks is restricted to:
- Communications with system components that are authorized to provide publicly accessible
services, protocols, and ports.
- Stateful responses to communications initiated by system components in a trusted network.
- All other traffic is denied.
levels:
- base
status: partial
notes: |-
Probably missing some relevant IPv6 related rules. Needs to be investigated.
rules:
- postfix_network_listening_disabled
- var_postfix_inet_interfaces=loopback-only
- kernel_module_sctp_disabled
- kernel_module_dccp_disabled
- sysctl_net_ipv4_icmp_echo_ignore_broadcasts
- sysctl_net_ipv4_icmp_ignore_bogus_error_responses
- sysctl_net_ipv6_conf_default_accept_source_route
- id: 1.4.3
title: Anti-spoofing measures are implemented to detect and block forged source IP
addresses from entering the trusted network.
levels:
- base
status: partial
notes: |-
Probably missing some relevant IPv6 related rules. Needs to be investigated.
rules:
- sysctl_net_ipv4_conf_all_rp_filter
- sysctl_net_ipv4_conf_all_secure_redirects
- sysctl_net_ipv4_conf_default_accept_redirects
- sysctl_net_ipv4_ip_forward
- sysctl_net_ipv4_tcp_syncookies
- id: 1.4.4
title: System components that store cardholder data are not directly accessible from
untrusted networks.
levels:
- base
status: pending
notes: |-
This requirement is not intended to apply to storage of account data in volatile memory
but does apply where memory is being treated as persistent storage (for example, RAM
disk). Account data can only be stored in volatile memory during the time necessary to
support the associated business process (for example, until completion of the related
payment card transaction).
related_rules:
- configure_firewalld_ports
- id: 1.4.5
title: The disclosure of internal IP addresses and routing information is limited to only
authorized parties.
description: |-
Internal network information is protected from unauthorized disclosure.
levels:
- base
status: automated
rules:
- sysctl_net_ipv4_conf_all_send_redirects
- sysctl_net_ipv4_conf_default_send_redirects
- network_sniffer_disabled
- id: '1.5'
title: Risks to the CDE from computing devices that are able to connect to both untrusted
networks and the CDE are mitigated.
levels:
- base
status: partial
controls:
- id: 1.5.1
title: Security controls are implemented on any computing devices, including company- and
employee-owned devices, that connect to both untrusted networks (including the Internet)
and the CDE
description: |-
Security controls are implemented on any computing devices, including company- and
employee-owned devices, that connect to both untrusted networks (including the Internet)
and the CDE as follows:
- Specific configuration settings are defined to prevent threats being introduced into the
entity's network.
- Security controls are actively running.
- Security controls are not alterable by users of the computing devices unless
specifically documented and authorized by management on a case-by-case basis for a limited
period.
levels:
- base
status: partial
notes: |-
To ensure this requirement, a manual analysis of site policy and topology is inevitable.
From the technical perspective, previous requirements should already cover this
requirement at some level.
related_rules:
# These rules are already covered by 1.3.1.
- ensure_firewall_rules_for_open_ports
- set_firewalld_default_zone
# This rule is already covered by 1.2.6
- selinux_state
- id: '2.1'
title: Processes and mechanisms for applying secure configurations to all system components
are defined and understood.
levels:
- base
status: manual
controls:
- id: 2.1.1
title: All security policies and operational procedures that are identified in Requirement 2
are Documented, Kept up to date, In use and Known to all affected parties.
levels:
- base
status: manual
notes: |-
Examine documentation and interview personnel to verify that security policies and
operational procedures identified in Requirement 2 are managed in accordance with all
elements specified in this requirement.
- id: 2.1.2
title: Roles and responsibilities for performing activities in Requirement 2 are
documented, assigned, and understood.
description: |-
Day-to-day responsibilities for performing all the activities in Requirement 2 are
allocated. Personnel are accountable for successful, continuous operation of these
requirements.
levels:
- base
status: manual
notes: |-
Examine documentation and interview personnel to verify that day-to-day responsibilities
for performing all the activities in Requirement 2 are documented, assigned and understood
by the assigned personnel.
- id: '2.2'
title: 'System components are configured and managed securely.'
levels:
- base
status: partial
controls:
- id: 2.2.1
title: Configuration standards are developed, implemented, and maintained
description: |-
Configuration standards are developed, implemented, and maintained to:
- Cover all system components.
- Address all known security vulnerabilities.
- Be consistent with industry-accepted system hardening standards or vendor hardening
recommendations.
- Be updated as new vulnerability issues are identified, as defined in Requirement 6.3.1.
- Be applied when new systems are configured and verified as in place before or
immediately after a system component is connected to a production environment.
levels:
- base
status: partial
notes: |-
Interestingly this requirement recommends other standards, such as Center for Internet
Security (CIS), International Organization for Standardization (ISO), National Institute
of Standards and Technology (NIST), Cloud Security Alliance, and product vendors. So, the
rules included here are very generic in terms of hardening.
rules:
- bios_enable_execution_restrictions
- install_PAE_kernel_on_x86-32
- id: 2.2.2
title: Vendor default accounts are managed.
description: |-
Vendor default accounts are managed as follows:
- If the vendor default account(s) will be used, the default password is changed per
Requirement 8.3.6.
- If the vendor default account(s) will not be used, the account is removed or disabled.
levels:
- base
status: automated
notes: |-
Also related to requirement 8.2.6 and 8.3.5.
rules:
- ensure_root_password_configured
- no_empty_passwords_etc_shadow
- id: 2.2.3
title: 'Primary functions requiring different security levels are managed'
levels:
- base
status: manual
- id: 2.2.4
title: Only necessary services, protocols, daemons, and functions are enabled, and all
unnecessary functionality is removed or disabled
description: |-
System components cannot be compromised by exploiting unnecessary functionality present in
the system component.
levels:
- base
status: automated
rules:
- mask_nonessential_services
- package_dhcp_removed
- package_ftp_removed
- package_net-snmp_removed
- package_rsh_removed
- package_rsh-server_removed
- package_talk_removed
- package_talk-server_removed
- package_telnet_removed
- package_telnet-server_removed
- package_tftp_removed
- package_tftp-server_removed
- package_xinetd_removed
- package_ypbind_removed
- package_ypserv_removed
- service_avahi-daemon_disabled
- service_rpcbind_disabled
- service_rsyncd_disabled
related_rules:
- package_bind_removed
- package_dnsmasq_removed
- package_httpd_removed
- package_nfs-utils_removed
- package_openldap-clients_removed
- package_openldap-servers_removed
- package_rsync_removed
- package_samba_removed
- package_squid_removed
- package_vsftpd_removed
- service_cups_disabled
- service_nfs_disabled
- id: 2.2.5
title: If any insecure services, protocols, or daemons are present, business justification
is documented and the risk is reduced.
description: |-
If any insecure services, protocols, or daemons are present:
- Business justification is documented.
- Additional security features are documented and implemented that reduce the risk of
using insecure services, protocols, or daemons.
levels:
- base
status: manual
notes: |-
Known insecure services are removed or disabled by 2.2.4
General security measures are covered by 1.2.6
This requirement is more about checking exceptions and their respective documentation.
- id: 2.2.6
title: System security parameters are configured to prevent misuse.
description: |-
System components cannot be compromised because of incorrect security parameter
configuration.
levels:
- base
status: automated
notes: |-
This requirement is not specific but also points to 2.2.1, where other policies are
referenced. Therefore, the most common rules related to system configuration in order to
prevent misuse and selected in main profiles are also selected here.
rules:
# bootloader files protection
- file_groupowner_grub2_cfg
- file_owner_grub2_cfg
- file_permissions_grub2_cfg
- file_groupowner_user_cfg
- file_owner_user_cfg
- file_permissions_user_cfg
# at files protection
- file_at_deny_not_exist
- file_groupowner_at_allow
- file_owner_at_allow
- file_permissions_at_allow
# cron files protection
- file_cron_deny_not_exist
- file_groupowner_cron_allow
- file_owner_cron_allow
- file_permissions_cron_allow
- file_groupowner_crontab
- file_owner_crontab
- file_permissions_crontab
- file_groupowner_cron_d
- file_owner_cron_d
- file_permissions_cron_d
- file_groupowner_cron_hourly
- file_owner_cron_hourly
- file_permissions_cron_hourly
- file_groupowner_cron_daily
- file_owner_cron_daily
- file_permissions_cron_daily
- file_groupowner_cron_weekly
- file_owner_cron_weekly
- file_permissions_cron_weekly
- file_groupowner_cron_monthly
- file_owner_cron_monthly
- file_permissions_cron_monthly
# ssh files protection
- file_permissions_sshd_config
- file_permissions_sshd_private_key
- file_permissions_sshd_pub_key
# users files protection
- file_groupowner_etc_group
- file_groupowner_backup_etc_group
- file_owner_etc_group
- file_owner_backup_etc_group
- file_permissions_etc_group
- file_permissions_backup_etc_group
- file_groupowner_etc_passwd
- file_groupowner_backup_etc_passwd
- file_owner_etc_passwd
- file_owner_backup_etc_passwd
- file_permissions_etc_passwd
- file_permissions_backup_etc_passwd
- file_groupowner_etc_shadow
- file_groupowner_backup_etc_shadow
- file_owner_etc_shadow
- file_owner_backup_etc_shadow
- file_permissions_etc_shadow
- file_permissions_backup_etc_shadow
# general files protection
- file_permissions_unauthorized_world_writable
- file_permissions_ungroupowned
- no_files_unowned_by_user
- dir_perms_world_writable_sticky_bits
# ssh settings
- sshd_disable_empty_passwords
- sshd_disable_rhosts
- sshd_disable_root_login
- sshd_disable_tcp_forwarding
- sshd_disable_x11_forwarding
- sshd_do_not_permit_user_env
- sshd_enable_pam
- sshd_limit_user_access
- sshd_set_loglevel_verbose
- sshd_set_max_auth_tries
- sshd_set_max_sessions
- sshd_set_maxstartups
- sshd_set_login_grace_time
- var_sshd_set_login_grace_time=60
# sudo settings
- package_sudo_installed
- sudo_add_use_pty
- sudo_custom_logfile
- sudo_require_authentication
- sudo_require_reauthentication
# su command limitation
- use_pam_wheel_group_for_su
- ensure_pam_wheel_group_empty
- id: 2.2.7
title: All non-console administrative access is encrypted using strong cryptography.
description: |-
Cleartext administrative authorization factors cannot be read or intercepted from any
network transmissions. This includes administrative access via browser-based interfaces
and application programming interfaces (APIs).
levels:
- base
status: automated
notes: |-
Related to requirement 12.3.3.
rules:
- configure_crypto_policy
- var_system_crypto_policy=default_policy
- configure_ssh_crypto_policy
- sshd_use_approved_ciphers
- sshd_use_approved_macs
- sshd_use_strong_kex
related_rules:
- configure_libreswan_crypto_policy
- configure_openssl_crypto_policy
- id: '2.3'
title: Wireless environments are configured and managed securely.
levels:
- base
status: supported
controls:
- id: 2.3.1
title: For wireless environments connected to the CDE or transmitting account data, all
wireless vendor defaults are changed at installation or are confirmed to be secure.
description: |-
For wireless environments connected to the CDE or transmitting account data, all wireless
vendor defaults are changed at installation or are confirmed to be secure, including but
not limited to:
- Default wireless encryption keys.
- Passwords on wireless access points.
- SNMP defaults.
- Any other security-related wireless vendor defaults.
levels:
- base
status: supported
notes: |-
Wireless interfaces are disabled by 1.3.3.
related_rules:
- wireless_disable_interfaces
- id: 2.3.2
title: For wireless environments connected to the CDE or transmitting account data, wireless
encryption keys are changed
description: |-
For wireless environments connected to the CDE or transmitting account
data, wireless encryption keys are changed
levels:
- base
status: supported
notes: |-
Wireless interfaces are disabled by 1.3.3.
related_rules:
- wireless_disable_interfaces
- id: '3.1'
title: Processes and mechanisms for protecting stored account data are defined and understood.
levels:
- base
status: manual
controls:
- id: 3.1.1
title: All security policies and operational procedures that are identified in Requirement 3
are Documented, Kept up to date, In use and Known to all affected parties.
levels:
- base
status: manual
notes: |-
Examine documentation and interview personnel to verify that security policies and
operational procedures identified in Requirement 3 are managed in accordance with all
elements specified in this requirement.
- id: 3.1.2
title: Roles and responsibilities for performing activities in Requirement 3 are
documented, assigned, and understood.
levels:
- base
status: manual
notes: |-
Examine documentation and interview personnel to verify that day-to-day responsibilities
for performing all the activities in Requirement 3 are documented, assigned and understood
by the assigned personnel.
- id: '3.2'
title: Storage of account data is kept to a minimum.
levels:
- base
status: manual
controls:
- id: 3.2.1
title: Account data storage is kept to a minimum through implementation of data retention
and disposal policies, procedures, and processes.
description: |-
Account data storage is kept to a minimum through implementation of data retention and
disposal policies, procedures, and processes that include at least the following:
- Coverage for all locations of stored account data.
- Coverage for any sensitive authentication data (SAD) stored prior to completion of
authorization.
- Limiting data storage amount and retention time to that which is required for legal or
regulatory, and/or business requirements.
- Specific retention requirements for stored account data that defines length of retention
period and includes a documented business justification.
- Processes for secure deletion or rendering account data unrecoverable when no longer
needed per the retention policy.
- A process for verifying, at least once every three months, that stored account data
exceeding the defined retention period has been securely deleted or rendered unrecoverable.
levels:
- base
status: manual
notes: |-
This requirement is very dependent on each site policies and business model.
Local policies should be consulted and audited. Manual checking is reasonable.
- id: '3.3'
title: Sensitive authentication data (SAD) is not stored after authorization.
levels:
- base
status: partial
controls:
- id: 3.3.1
title: SAD is not retained after authorization, even if encrypted. All sensitive
authentication data received is rendered unrecoverable upon completion of the
authorization process.
description: |-
This requirement is not eligible for the customized approach. This requirement does not
apply to issuers and companies that support issuing services (where SAD is needed for a
legitimate issuing business need) and have a business justification to store the sensitive
authentication data. Refer to Requirement 3.3.3 for additional requirements specifically
for issuers. Sensitive authentication data includes the data cited in Requirements 3.3.1.1
through 3.3.1.3.
levels:
- base
status: partial
controls:
- id: 3.3.1.1
title: The full contents of any track are not retained upon completion of the
authorization process.
description: |-
This requirement is not eligible for the customized approach. In the normal course of
business, the following data elements from the track may need to be retained:
- Cardholder name.
- Primary account number (PAN).
- Expiration date.
- Service code.
To minimize risk, store securely only these data elements as needed for business.
levels:
- base
status: partial
notes: |-
This requirement consists in auditing files, databases and memory to make sure the full
content of any track is not unnecessarily retained. It involves manual auditing but some
automated rules fit this requirement in order to reduce the chances if this data be
unintentionally stored in memory.
rules:
- coredump_disable_backtraces
- coredump_disable_storage
- disable_users_coredumps
- sysctl_fs_suid_dumpable
- sysctl_kernel_core_pattern
- sysctl_kernel_randomize_va_space
related_rules:
# These next three rules are interesting but can hit performance so it is better to
# investigate the performance impact before enabling them.
- kernel_config_page_poisoning
- kernel_config_page_poisoning_no_sanity
- kernel_config_page_poisoning_zero
- sysctl_kernel_core_uses_pid
- id: 3.3.1.2
title: The card verification code is not retained upon completion of the authorization
process.
description: |-
This requirement is not eligible for the customized approach. The card verification code
is the three- or four-digit number printed on the front or back of a payment card used
to verify card-not-present transactions.
levels:
- base
status: partial
notes: |-
Same rules already selected in 3.3.1.1 are valid here, but they are not repeated.
related_rules:
- coredump_disable_backtraces
- coredump_disable_storage
- disable_users_coredumps
- sysctl_fs_suid_dumpable
- id: 3.3.1.3
title: The personal identification number (PIN) and the PIN block are not retained upon
completion of the authorization process.
description: |-
This requirement is not eligible for the customized approach. PIN blocks are encrypted
during the natural course of transaction processes, but even if an entity encrypts the
PIN block again, it is still not allowed to be stored after the completion of the
authorization process.
levels:
- base
status: partial
notes: |-
Same rules already selected in 3.3.1.1 are valid here, but they are not repeated.
related_rules:
- coredump_disable_backtraces
- coredump_disable_storage
- disable_users_coredumps
- sysctl_fs_suid_dumpable
- id: 3.3.2
title: SAD that is stored electronically prior to completion of authorization is encrypted
using strong cryptography.
description: |-
This requirement is not eligible for the customized approach. Whether SAD is permitted to
be stored prior to authorization is determined by the organizations that manage compliance
programs (for example, payment brands and acquirers). Contact the organizations of
interest for any additional criteria. This requirement applies to all storage of SAD, even
if no PAN is present in the environment. Refer to Requirement 3.2.1 for an additional
requirement that applies if SAD is stored prior to completion of authorization. This
requirement does not apply to issuers and companies that support issuing services where
there is a legitimate issuing business justification to store SAD. Refer to Requirement
3.3.3 for requirements specifically for issuers. This requirement does not replace how PIN
blocks are required to be managed, nor does it mean that a properly encrypted PIN block
needs to be encrypted again.
levels:
- base
status: manual
notes: |-
This requirement is a best practice until 31 March 2025, after which it will be required
and must be fully considered during a PCI DSS assessment.
This requirement consists of auditing information stored during a relatively short period
of time. Where and how the information is possibly stored depends in each Business and
local policies so the check is not actually automatable.
- id: 3.3.3
title: Additional requirement for issuers and companies that support issuing services and
store sensitive authentication data.
description: |-
Additional requirement for issuers and companies that support issuing services and store
sensitive authentication data: Any storage of sensitive authentication data is:
- Limited to that which is needed for a legitimate issuing business need and is secured.
- Encrypted using strong cryptography. This bullet is a best practice until until
31 March 2025, after which it will be required as part of Requirement 3.3.3 and must be
fully considered during a PCI DSS assessment.
levels:
- base
status: manual
- id: '3.4'
title: Access to displays of full PAN and ability to copy PAN is restricted.
levels:
- base
status: automated
controls:
- id: 3.4.1
title: PAN is masked when displayed (the BIN and last four digits are the maximum number of
digits to be displayed), such that only personnel with a legitimate business need can see
more than the BIN and last four digits of the PAN.
description: |-
PAN displays are restricted to the minimum number of digits necessary to meet a defined
business need. This requirement does not supersede stricter requirements in place for
displays of cardholder data — for example, legal or payment brand requirements for
point-of-sale (POS) receipts. This requirement relates to protection of PAN where it is
displayed on screens, paper receipts, printouts, etc., and is not to be confused with
Requirement 3.5.1 for protection of PAN when stored, processed, or transmitted.
levels:
- base
status: manual
notes: |-
Consists on examining documented policies and procedures, checking system configurations
and observing relevant applications.
- id: 3.4.2
title: When using remote-access technologies, technical controls prevent copy and/or
relocation of PAN for all personnel, except for those with documented, explicit
authorization and a legitimate, defined business need.
description: |-
PAN cannot be copied or relocated by unauthorized personnel using remote-access
technologies. Storing or relocating PAN onto local hard drives, removable electronic
media, and other storage devices brings these devices into scope for PCI DSS.
This requirement is a best practice until 31 March 2025, after which it will be required
and must be fully considered during a PCI DSS assessment.
levels:
- base
status: automated
notes: |-
There are technical rules to disable removable storage devices. However, this requirement
still demand some manual auditing in documentation and eventual exceptions.
rules:
- kernel_module_usb-storage_disabled
- dconf_gnome_disable_automount
- dconf_gnome_disable_automount_open
- id: '3.5'
title: Primary account number (PAN) is secured wherever it is stored.
levels:
- base
status: partial
controls:
- id: 3.5.1
title: PAN is rendered unreadable anywhere it is stored
description: |-
PAN is rendered unreadable anywhere it is stored by using any of the following approaches:
- One-way hashes based on strong cryptography of the entire PAN.
- Truncation (hashing cannot be used to replace the truncated segment of PAN).
- If hashed and truncated versions of the same PAN, or different truncation formats of
the same PAN, are present in an environment, additional controls are in place such that
the different versions cannot be correlated to reconstruct the original PAN.
- Indexes tokens.
- Strong cryptography with associated key-management processes and procedures.
levels:
- base
status: partial
controls:
- id: 3.5.1.1
title: Hashes used to render PAN unreadable (per the first bullet of Requirement 3.5.1)
are keyed cryptographic hashes of the entire PAN, with associated key-management
processes and procedures in accordance with Requirements 3.6 and 3.7.
description: |-
This requirement applies to PANs stored in primary storage (databases, or flat files
such as text files spreadsheets) as well as non-primary storage (backup, audit logs,
exception, or troubleshooting logs) must all be protected. This requirement does not
preclude the use of temporary files containing cleartext PAN while encrypting and
decrypting PAN. This requirement is considered a best practice until 31 March 2025,
after which it will be required and must be fully considered during a PCI DSS
assessment.
levels:
- base
status: planned
notes: |-
This requirement likely demand assessment in application level for some environments and
this would be too specific to be automated. However, on system level we can ensure some
strong cryptographic algorithms. This is also generally covered by 2.2.7 but here would
be possible to include more specific rules, for openssl and libreswan for example.
However it would be first necessary to include a platform conditional in these rules
before selecting them so they are applicable only if the respective packages are
installed.
related_rules:
- configure_libreswan_crypto_policy
- configure_openssl_crypto_policy
- id: 3.5.1.2
title: If disk-level or partition-level encryption (rather than file-, column-, or
field-level database encryption) is used to render PAN unreadable, it is implemented
only on removable electronic media or complemented by another mechanism that meets
Requirement 3.5.1
levels:
- base
status: automated
rules:
- package_cryptsetup-luks_installed
- id: 3.5.1.3
title: If disk-level or partition-level encryption is used (rather than file-, column-, or
field--level database encryption) to render PAN unreadable, it is managed.
description: |-
If disk-level or partition-level encryption is used (rather than file-, column-, or
field--level database encryption) to render PAN unreadable, it is managed as follows:
- Logical access is managed separately and independently of native operating system
authentication and access control mechanisms.
- Decryption keys are not associated with user accounts.
- Authentication factors (passwords, passphrases, or cryptographic keys) that allow
access to unencrypted data are stored securely.
levels:
- base
status: manual
notes: |-
To properly check this requirement, site policies and documentation should be consulted.
- id: '3.6'
title: Cryptographic keys used to protect stored account data are secured.
levels:
- base
status: manual
controls:
- id: 3.6.1
title: Procedures are defined and implemented to protect cryptographic keys used to protect
stored account data against disclosure and misuse.
description: |-
Procedures are defined and implemented to protect cryptographic keys used to protect
stored account data against disclosure and misuse that include:
- Access to keys is restricted to the fewest number of custodians necessary.
- Key-encrypting keys are at least as strong as the data-encrypting keys they protect.
- Key-encrypting keys are stored separately from data-encrypting keys.
- Keys are stored securely in the fewest possible locations and forms.
levels:
- base
status: manual
controls:
- id: 3.6.1.1
title: 'Additional requirement for service providers only: A documented description of the
cryptographic architecture is maintained'
description: |-
Additional requirement for service providers only: A documented description of the
cryptographic architecture is maintained that includes:
- Details of all algorithms, protocols, and keys used for the protection of stored
account data, including key strength and expiry date.
- Preventing the use of the same cryptographic keys in production and test environments.
This bullet is a best practice until 31 March 2025, after which it will be required as
part of Requirement 3.6.1.1 and must be fully considered during a PCI DSS assessment.
- Description of the key usage for each key.
- Inventory of any hardware security modules (HSMs), key management systems (KMS), and
other secure cryptographic devices (SCDs) used for key management, including type and
location of devices, as outlined in Requirement 12.3.4.
levels:
- base
status: manual
- id: 3.6.1.2
title: Secret and private keys used to encrypt/decrypt stored account data are stored in
secure forms.
description: |-
Secret and private keys used to encrypt/decrypt stored account data are stored in one
(or more) of the following forms at all times:
- Encrypted with a key-encrypting key that is at least as strong as the data-encrypting
key, and that is stored separately from the data-encrypting key.
- Within a secure cryptographic device (SCD), such as a hardware security module (HSM)
or PTS-approved point-of-interaction device.
- As at least two full-length key components or key shares, in accordance with an
industry-accepted method.
Secret and private keys are stored in a secure form that prevents unauthorized retrieval
or access. It is not required that public keys be stored in one of these forms.
Cryptographic keys stored as part of a key management system (KMS) that employs SCDs are
acceptable. A cryptographic key that is split into two parts does not meet this
requirement. Secret or private keys stored as key components or key shares must be
generated via one of the following
levels: