Smack in the middle of the holiday shopping season, Target was hit with a malware attack that infiltrated its point-of-sale systems and enabled the theft of credit card numbers and personally identifiable information from more than 70 million shoppers.
Now that we know more about the incident’s causes and scope, what effect will it have on organizations’ efforts to improve the compliance of their systems?
For starters, many merchants may not be up to speed on the significant changes in PCI 3.0, which mandate continuous compliance rather than discrete, point-in-time security. On top of that, Target’s POS systems may have been running a payments solution that wasn’t up to the standards required by PCI DSS.
Staying up to speed on an array of complex requirements such as PCI may seem tricky, but iSeries users have compliance options that can streamline security processes, so that they can avoid what happened to Target.
Key Compliance Takeaways and Next Steps
Many POS systems are not protected from malware. This would seem like an obvious vulnerability to address, but many retailers haven’t done so since they still haven’t become PCI 2.0 compliant, and as such they aren’t well positioned to detect unusual network activity.
While 2.0 guidelines stipulate that only commonly targeted platforms have to be hardened against malware, the 3.0 update is more stringent; organizations should now protect all systems against infection.
Similarly, PCI 3.0 requires that merchants perform risk assessment for any significant change to the cardholder environment. The intrusion malware from the Target breach certainly qualified as such an event, but somehow went unaddressed.
To avoid a similar fate, it’s key for organizations to have compliance monitoring technology that checks against default system configurations and typical user activity levels and then generates comprehensive reports that help identify anomalies.
While the Target breach by and large highlighted what the retailer had failed to do, there were also a few questionable things that it did do that probably jeopardized compliance. For example, Target was storing three-digit CVV codes, which is prohibited under PCI DSS. The guidelines also require encryption of any stored card data so that even if it is stolen, anyone without the encryption key would be unable to read it.
Businesses have to ensure that data is protected by strong encryption such as 256-bit AES, both at rest and while it is in transition between different platforms.
Simplify your audit reporting with Compliance Monitor for IBM i. Schedule a software demo to see for yourself.