Lecture_287

.pdf

School

University of Toronto *

*We aren’t endorsed by this school

Course

568

Subject

Information Systems

Date

Dec 6, 2023

Type

pdf

Pages

Uploaded by ColonelOysterMaster630

267 You’re Compliant, Now What? reviews; that is what your QSA will be asking for. The reviews should be detailed enough to show that an engineer checked every item and validated that it was still needed. Your assessor will also review documentation for two other requirements in this domain, and while they may not have to be updated through a formal process, many companies have failed parts of their PCI Assessment because they forgot to do something simple like update a configuration standard that referenced outdated, or known vulnerable software. Be sure that during your normal review for Requirement 1.2.7, you review and update your firewall and router configuration stan- dards. Do the ruleset review first and note anything that is not in the standard, then go update the standard so that it matches what is in the ruleset. While it may seem overly picky, an assessor would be right if he noted outdated configuration standards for Requirement 1.2.1. In addition, go back through all of your in-scope system types and ensure that their configura- tion is up-to-date for Requirements 2.2 and 2.3. Companies fall short of this requirement when they reference out-of-date software packages or versions that have security vulnerabilities in them. For example, if your configuration standards for a new mail server still say to start with a stock Solaris 5.7 build with Sendmail 8.9, an outdated and vulnerable version of Sendmail, you would not be able to pass that requirement. P ROTECT A CCOUNT D ATA Requirement 3 has two key items to address, and one that may just need to have a fresh set of eyes. Requirement 3.2.1 mandates that you create retention requirements for account data and have a quarterly (technically once every three months) requirement to purge old data by way of manual review or automated disposal process. Even if your process is 100% automated, take the time each quarter to make sure that the processes are in fact functioning correctly. During your assessment, expect your assessor to ask you to produce your oldest set of retained data. They will then check to make sure that it does not exceed the retention requirements set forth in the aforementioned review. WARNING Our guidance from Chapter 7, Protecting Cardholder Data, still stands: It is usually easier to avoid storing data than to protect stored data. This is not a traditional way to think about data security, but it is one way of thinking about it, which is extremely useful for painless PCI DSS compliance. Consider expanding that quarterly process to include a review of the actual requirements to retain data. The business, regulatory, and legal environments can easily change more than annually (maybe not all at the same time, but one of the three will happen at least more than annually), so use that time to be sure that you do not need to alter your data retention requirements. If you do, republish the information and perform a new review to make sure you are in compliance with your own policy. NOTE Time and time again, companies write policies in good faith and then completely ignore them in practice. As an example, Matt works for a large regional grocery chain that is a Level 2 merchant. His company’s corporate policy is actually more restrictive than PCI to require all critical and high-risk security patches to be deployed within 10 days and all cardholder data to be encrypted internally over the wire. When Matt’s assessor was performing the assessment, she noticed that one process for the florist shop inside his stores did not encrypt the cardholder data over the wire. When Matt confronted the department responsible for the

268 PCI Compliance florist shop’s systems, the response he got back was “Well, it’s not a PCI requirement so we just did the minimum,” thus completely ignoring the corporate policy. Usually, you don’t find that just one policy is violated—there tend to be many. This would be a clue for his asses- sor to dig deeper to ensure that policies requiring the minimum PCI requirement are actu- ally being followed. Moral of the story? If you have a corporate policy that exceeds the base requirements of PCI, FOLLOW IT. There is a reason why that policy is in place! Requirement 3.7.4 states that keys should be rotated once they have “reached the end of their crypto- period (e.g., after a defined period of time has passed and/or after a certain amount of ciphertext has been produced by a given key), as defined by the associated application vendor or key owner, and based on industry best practices and guidelines.” This formerly was a pre-defined period to be an annual key rotation requirement for all keys used for the encryption of in-scope data. Expect some challenges with your assessor here as they will ask for your analysis to justify the period you chose. They may still want to see annual or semi-annual changes, and you may need to educate them on what an acceptable cryptoperiod is for your particular implementation. Your assessor will first look at your key management processes and make sure the requirement to rotate is documented, and then will check your implementation to see if you actually did rotate the key per the document. This becomes challenging on new installations with longer cryptoperiods (say a new installation with a three-year rotation requirement), so again, expect an education session. While you are reviewing your documentation for this, take a look at the overall key management processes and procedures and ensure they are up-to-date for Requirement 3.7. Common gotcha’s here include forgetting to update the key management processes when you change encryption technologies. That’s a big, red flag for an assessor, and it is pretty easy to spot. M AINTAIN A V ULNERABILITY M ANAGEMENT P ROGRAM Vulnerability management is a task that is easily seen as ongoing. New vulnerabilities, viruses, and malware are found every day, and companies need to take the appropriate precautions to ensure that they are protected. Requirement 5.3.2 uses that indefinite term periodic. To comply with this requirement, you must perform periodic scans of your in-scope machines. TOOLS We cover the vulnerability scanning tools that help with external and internal network scan- ning in Chapter 9 , Vulnerability Management and Testing. With the ever-changing landscape of attacks and malware, you probably should not be using what we traditionally think of anti-virus tools. You should now be using Endpoint Detection and Response (EDR) tools to better protect endpoints against malware and other malicious behaviors. In addition, Requirement 11.3.1.3 mandates that you run authenticated scans against internal systems after any significant change, but at a minimum Requirement 11.3.1 has a quarterly internal scan require- ment. You should probably be scanning systems more frequently (or including detailed vulner- ability checks during Continuous Integration and Continuous Delivery [CI/CD] build processes). I would suggest weekly if your systems can handle this. More of the quality vulnerability vendors offer unlimited scanning, or you can use freeware tools such as Nessus as well for internal scans and “unofficial” external scans (those not performed by an ASV). To determine how often you should scan your systems, perform a risk analysis of these systems and include elements such as the criticality of the systems, amount of processing power, business hours and uptime requirements, bandwidth, and the frequency by which you update your antivirus definitions. Such risk analysis is in fact prescribed in Requirement 12.3.1 and must be performed

Your preview ends here

Eager to read complete document? Join bartleby learn and gain access to the full version

Access to all documents
Unlimited textbook solutions
24/7 expert homework help