RSI Security recently partnered with Jscrambler in an interactive Virtual Summit webinar. RSI Security’s Founder and Managing Director, John Shin, opened the event with a meditation on the importance of context and executing a power-move to go from context dependence to context awareness and agility—from needing context to recognizing it and operationalizing it.
Shin segued into presentations from two experts from our partner org, Jscrambler:
- Pedro Fortuna, CTO and co-founder at Jscrambler, boasts 20+ years working in security and 16+ years in WebApp Sec (and is a PCI SSC board advisor and OWASP Lisboa chapter leader), leads company product innovation strategy, research, and engineering.
- John Elliott, senior security advisor at Jscrambler, former QSA, boasts 16 years working in security and 14 years with PCI. He was also an RSA conference speaker and served and advised the board of the PCI SSC, where he worked extensively on the DSS 4.0.
After a brief introduction to set expectations, the presentations got underway.
Mitigating e-Skimming Threats and Data Leak Risks
Pedro Fortuna’s presentation focused on e-skimming risks and how to minimize them, including but not limited to the context of PCI compliance. He began by defining e-skimming as a digital counterpart of credit card skimming scans that use scripts in the place of physical scanners.
In the digital realm, company websites use third-party scripts (dozens, sometimes hundreds), which in turn often also involve the use of fourth-party scripts. In many cases, these connections also involve smaller and less mature organizations with poor or non-existent security controls.
The problem is that, if one script is compromised, attackers can skim an entire payment page and exfiltrate data to an external domain, potentially using a compromised third-party server.
One of the biggest reasons this is possible is the Same Origin Policy (SOP) from 1995, which enables JavaScript executions to access domains given matching document origins. In years past, organizations could isolate third parties to cross-origin iframes. But, now, efficient web development all but assumes seamless third-party access to most/all on page information.
So, what can organizations do to solve this problem?
Fortuna recommended implementing one or multiple of the following approaches:
- Limiting the amount of scripts included by:
- Not including any scripts you don’t need
- Being mindful of fourth-party scripts
- Ensuring you trust third-party teams
- Removing scripts to minimize the attack surface
- Limiting the amount of scripts that can be loaded by way of:
- Content Security Policy (CSP)
- Subresource Integrity (SRI)
- Protecting the integrity of scripts that are used by:
- Using file hash checks
- Making code tamper-resistant
- Limiting what permitted scripts can do by:
- Sandboxing (observing behaviors and allowing or blocking)
- Script fencing (installing boundaries for what scripts can do)
- Form Fencing (limiting script access to specific form inputs)
Fortuna closed out his segment talking about how PCI DSS 4.0 complicates solutions to these issues, which was a perfect segue into what the next presenter would focus on primarily.
Implementing Two New PCI DSS v4.0 Requirements
John Elliott’s presentation focused more specifically on the context of PCI DSS compliance, particularly addressing two new requirements in PCI DSS v4.0 that address e-skimming.
Elliott began by summarizing the problem as revolving around the way web development is approached today. Namely, the web is built by assembling JavaScript in browsers, despite the fact that every piece of JavaScript has access to any page element. Our attack surface is both first- and third-party sources, which is how and why most data gets lost in e-commerce contexts.
To put numbers to it, websites have about 100 scripts on average, with 52 being first-party and 28 being third-party. There’s also a mean of 13 domains per site, with a high extreme of 25.
The newest version of the PCI DSS addressed this issue with two requirements:
- Requirement 6.4.3, which calls for authorization for new script additions
- Requirement 11.6.1, which calls for authorization for any changes to scripts
Elliott noted that, in an ideal world, businesses would implement robust processes for adding new scripts, i.e. via a CSP, and a CSP (plus SRI) would be enough to satisfy these rules.
However, in our real world, there are so many scripts that this is virtually impossible.
So, there are important questions to ask to address key weaknesses that arise. Namely, organizations should be asking which first-party stakeholders can add JavaScript to payment pages, how, and whether IT or others can enforce change control. For third parties, there are questions regarding how and when scripts are changed and how change management gets enforced. And, ultimately, all these processes need to be optimized, ideally with automation.
Elliott rounded out his presentation noting that most CSP and SRI authorization processes fall into the categories of default authorization, pre-authorization, or post-authorization. However, in many cases, the CSP-SRI combination will not be applicable, and organizations need a tool.
So, in practice, most organizations use proxies, scanners, or dedicated agents—like Jscrambler.
Panel Discussion and Live Jscrambler Demo
Next, John Shin opened up a discussion between the presenters and other stakeholders from both organizations. Other panelists included Mohan Shamachar, Director of Information Security and Compliance at RSI Security, and Jeffrey Cleveland, Pre-Sales Engineer at Jscrambler.
Shin posed a question about the challenges organizations are facing with PCI 4.0.
Elliott talked at length about the nuances in the new framework, including 64 brand new requirements that need to be accounted for—13 by this year, and the remainder by next April.
Then, Shin extended the question to Shamachar, focusing on other factors he’s seeing from the assessor’s point of view. Shamachar noted that assessors are trained to examine documents, observe behaviors, and interview staff to gauge awareness. For these reasons, working with a qualified assessor on a readiness assessment is the best way to truly prepare for a PCI audit.
Then, Shin asked Fortuna what challenges he saw with respect to payment monitoring, to which he responded that CSP and SRi so often fall short of what’s required. He then clarified that, although the tool is not the solution, it’s important to find the signals amidst a sea of noise.
Shamachar then expanded on this concept, talking about how the best way to incorporate PCI compliance into the software development process is to integrate PCI SSF processes into it.
Then, Cleveland offered a brief demonstration of Jscrambler tools in action, showing how the webpage integrity tool manages PCI components such as 6.4.3 and 11.6.1 with relative ease.
Looking Ahead: How to Rethink Your Security
Closing out the event, John Shin introduced one final spokesperson: RSI Security’s Senior Solution Advisor, Tanner Judah. Judah spoke about how integral PCI compliance has been to RSI Security’s services for over 10 years. It remains a core focus of what we offer to our strategic partners, helping them navigate changes to the framework and other evolving cybersecurity concerns over time and at scale. We’re dedicated to helping organizations in every industry protect their sensitive data the right way—or, as we call it, the only way.
To learn more about risk mitigation and overall PCI DSS 4.0 compliance, check out the webinar—or schedule a consultation to see how we can help you rethink your security.