We often hear how a company was compromised by a sophisticated attack. This characterization contains all the romantic thrill of a spy movie, but it is usually not how most companies are victimized. Most breaches usually happen as a result of malware entering the environment. The need to protect against malware is addressed in progressive degrees in Requirement 5 of the new 4.0 version of the Payment Card Industry Data Security Standard (PCI DSS).
Ian Thornton-Trump, who has experience in both military intelligence, as well as corporate environments, sees profound impacts from the new requirement. Requirement 5 is titled: “Protect All Systems and Networks from Malicious Software.” This requirement flows along the same path as the previous version of the Standard, however, the PCI Security Standards Council (SSC) also anticipates that attackers are going to move to more targeted, as well as automated methods. This requires a similar, targeted and automated response to protect organizations.
The new requirement contains two sections that call for the frequency of periodic evaluations of system components identified as not at risk for malware is defined in the entity’s targeted risk analysis. To quote Ian, “This is a profound shift in the evolution of the Standard, making it evident that the Council recognizes that compliance is far more of an organizational security challenge, and no longer just a firewall problem or endpoint anti-malware problem. This moves proactive motion further ahead with the introduction of mandatory risk controls and specific documentation requirements for risk management.”
Requirement 5 contains a grace period for enactment of two of its sub-headings that address “the frequency of periodic evaluations of system components identified as not at risk for malware…,” and “the frequency of scans is defined in the entity’s targeted risk analysis…” Both of these are considered a best practice until March 31, 2025, after which they will be required and must be fully considered during a PCI DSS assessment.
Ian offers that “The delay in this change is a bit concerning, as it would be more timely to make the requirements mandatory by a year sooner than the deadline currently directed in the Standard.” He sees the entire updated standard as “a major opportunity for Managed Detection and Response companies, and other security manufacturers to help with many of these updated requirements.”
Requirement 6 of the new Standard offers similar opportunities. It seeks to prevent malicious software at its inception, directing organizations to “Develop and Maintain Secure Systems and Software.”
Tyler Reguly finds some problems with the construction of this requirement, stirring up some strong imagery. As the Manager of Security Research & Development at Fortra’s Tripwire, and a key member of Tripwire’s Vulnerability and Exposure Research Team (VERT), Tyler is a firm practitioner of the method of an organized approach makes for the best implementation of security. As he describes it, Requirement 6 “feels like the junk drawer my grandmother had in her kitchen. You never know what you’ll find and there’s no real explanation as to why those items all ended up together.”
This comical observation is fairly accurate. Tyler adds, “This vast scope that encompasses a variety of pieces and components ultimately becomes challenging from a ‘whose responsibility is this’ standpoint. That doesn’t even start to address the technical issues with getting the sub-headings of the requirement implemented in an enterprise, but you still have to figure out who owns each responsibility.”
However, Tyler is not just being hyper-critical, as he sees solutions to the apparent challenges of this requirement. “It is a catalyst for interdepartmental collaboration. It is important to note that only one part of this requirement applies to internal software development. The remainder applies to your systems and how they are used, configured, and managed. It really is a broad collection of mixed requirements that could definitely be split into other requirements to provide a bit more organization. Since that hasn’t happened, you really do need to take it upon yourself to make it happen.”
Ian Thornton-Trump sees Requirement 5 as an opportunity for external partnerships, and Tyler Reguly views Requirement 6 as an opportunity for internal collaboration. It becomes apparent that, if approached correctly, PCI DSS version 4.0 offers a way for organizations to expand their security in ways that can create a more cohesive force for security. The way forward is through partnerships and collaboration.
In the next part of this series, we will examine requirements 7 and 8 of the new PCI Standard. To learn even more about the new Standard, as told by other experts in the field, download our eBook.
Source link
