Secure configurations: Building hardening standards

- [Instructor] PCI Requirement 2 talks about creating and applying secured configurations onto all of your PCI scoped components. We're skipping Section 2.1, with its roles and responsibilities, and moving straight into Section 2.2. 2.2 speaks to making sure these system components, such as servers, network devices, or Storage Area Networks contained in your CDE, are built in a secure way. You don't want to introduce a weakness into your CDE by forgetting about a system which could have, for example, Telnet running on it, waiting to capture clear text administrative credentials. 2.2.1 is ensuring that when a new system component is deployed to your CDE, that it's properly hardened, and that you've confirmed that. You should have build sheets with hardening standards for every type of device in your PCI scope. What are hardening standards? They're widely available, they may come from the vendor, or from a known source, such as the DISA STIGs which stands for Defense Information Systems Agency, and a STIG is a Security Technical Implementation Guide. Continuing with 2.2.1, the configuration standards need to be reviewed at least annually to make sure settings are still correct and new issues, such as published threats in the wild, are addressed in those hardening standards. Then when you roll out a new system, the admins need to follow these build standards and confirm that all items are in place, ideally, prior to the system component formally going into production, but if that's not an option, as soon as possible after that. What's a vendor default account? In many cases in the past, it used to be admin as the account and admin as the password. Fortunately these days, hardware manufacturers have become a little more sensible, and so these default, easily guessable passwords are not as common, but you need to check, and 2.2.2 provides some guidance on what's required. You may need to use the vendor account, so perhaps it's a root account on your Linux server, but you need to make sure you change the password and maintain that password appropriately. If you've got no plans to use that default account, then just go ahead and remove it if technically feasible, otherwise, set it to be permanently disabled. In an ideal world, you would also have a log alert if that account then became enabled, because, after all, who needs to use it? 2.2.3 has some specific guidance around primary functions and how they have to be set up on a given component. You have three choices. Firstly, you can put just one primary function, let's say Windows Active Directory Domain Controller for authorization on that component, no mixing with print or file server functions. Secondly, you can have primary functions with differing security levels, perhaps your payment application in your file server, on the same component, but completely isolated from each other. And then finally for 2.2.3, you can share functions with different security levels, as long as that system component is defaulting to the highest security requirements based on the highest security need. Realistically, it's most simple to follow the first option around separating them out entirely, but that may not be feasible or necessary if the other options can be easily met. 2.2.4 states that only necessary services, protocols, daemons, and functions are enabled, it also wants you to shut down everything that's not on that list. So, let's say you have a database server which is administered using SSH. You can enable the items associated with the database server generally acting as a database, and you can keep the SSH client alive, but you should shut down, if it's there, the Remote Desktop Protocol client, as you are not using it. Everything else you don't need that may be running by default also needs to be disabled or uninstalled, and that final minimal configuration needs to be documented and maintained. It's hard to come up with a good example for 2.2.5 of an insecure service, protocol, or daemon that wouldn't be excluded by other PCI controls. I tried, but everything I thought of seemed to be clearly impossible to use in such a secure environment. However, I do accept that something may be out there. Instead, I'm just going to state that 2.2.5 wants you to make very, very sure that if you do have such a thing in your environment, that you justify why it's still there, and figure out a way to mitigate the risk of such an insecure thing being used. This could be additional alerting, use only in certain exceptional circumstances, really, anything. 2.2.6 is straightforward, configure things, like a required login to a router, properly, to ensure they're working as designed. We'll cover more controls related to this later in the chapters. 2.2.7 is likewise very clear. Unless you're at a hardwired console, encrypt all administrative traffic, including authentication, using strong cryptography, which we'll cover in Requirement 3. 2.3 is specifically geared towards wireless configurations and making them secure. Depending on your scope, you may not have any wireless networks to worry about for PCI. However, if for example, you have a retail store using wireless point-of-sale devices, then these controls will come into scope. 2.3.1 wants you to change the defaults in your wireless devices as you roll them out into the PCI zones. You either have to change the vendor defaults or confirm that you've secured the devices appropriately as part of your bill process, typically by documenting it in the bill sheet, or the change ticket. If you are using SNMP, or Simple Network Management Protocol, to manage your wireless network devices, make sure it's configured in a secure manner, of a recent version, and doesn't use defaults, such as a string value of public. We've all seen a default router pathway of admin/admin, which provides full access into the wireless network administration portal, or perhaps an open SSID available to anyone to join. This particular control ensures that such insecure wireless networks don't provide a weak entry point into your cardholder data environment. 2.3.2 simply asks the organization to make sure that any wireless keys which are shared with people are changed when those people leave, or no longer need access. As with the previous example, if you have a retail store, and a wireless network that all of the payment devices are on, you wouldn't want a disgruntled employee who has just terminated logging on and capturing data in-flow over that network. If a log shows some anomalous activity on a network, perhaps that ex-employee's device, then you could assume that the wireless key has been compromised, and should move to change it immediately. Personally, I would like to ensure that these steps are taken throughout your entire organization. They're typically not technically hard to achieve, though nobody likes having to add a new password for WiFi. This section was reasonably straightforward, let's move into a requirement that's much more complex, how to protect stored data.