Vendor Onboarding Policies

  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. Applicability Notes This applies to ALL vendor default accounts and passwords, including, but not limited to, those used by operating systems, software that provides security services, application and system accounts, point-of-sale (POS) terminals, payment applications, and Simple Network Management Protocol (SNMP) defaults. This requirement also applies where a system component is not installed within an entity’s environment, for example, software and applications that are part of the CDE and are accessed via a cloud subscription service.
  
  
• Corporate security policy showing that vendor default accounts must be changed
  
  
• Evidence that vendor default accounts have been changed before an NSC has been allowed into the CDE
  
  
• Artifacts from vendor documentation and access control systems, for example, operating system documentation, configuration documentation, etc. Proof that every in-scope component has an access control system that is set to “Deny AH” by default, for example, vendor documentation showing the system implementation is correct and the default “Deny AH” rule is properly enforced.
  
  
• Vendor documentation for he systems and components used by the entity to show that authentication factors are rendered unreadable with strong cryptography during transmission and storage.
  
  
• System artifacts, documents, screenshots, etc. showing repositories of authentication factors to verify that they are unreadable during storage, for example, the Security Account Manager (SAM) database on a Windows Active Directory installation and others.
  
  
• With the assistance of the entity’s technical staff, perform data transmission captures to verify that authentication factors are unreadable during transmission. This can be accomplished using TCPDUMP (on NIX systems) or perhaps using Wireshark or some other data capture software.
  
  
• Vendor documentation for the systems and components used by the entity to show that the MFA system is not susceptible to replay attacks
  
  
• System artifacts, documents, screenshots, etc. showing that system configuration settings for the MFA implementation verify it is configured as such: 
  •The MFA system is not susceptible to replay attacks.
  • The MFA systems cannot be bypassed by any users, including administrative users unless specifically documented and authorized by management on an exception basis, for a limited time period.
  • At least two different types of authentication factors are used
  • Success of all authentication factors is required before access is granted. Interview notes from observing processes to verify that any requests to bypass MFA are specifically documented and authorized by management on an exception basis, for a limited time period.
  • Interview notes from observing processes to verify personnel logging into system components in the CDE are granted access only after all authentication factors are successful.
  • Interview notes from observing personnel connecting remotely from outside the entity’s network to verify that access is granted only after all authentication factors are successful