Compliance Unfiltered is TCT’s tell-it-like-it is podcast, dedicated to making compliance suck less. It’s a fresh, raw, uncut alternative for anyone who needs honest, reliable, compliance expertise with a sprinkling of personality.
Show Notes: Interview with Pedro Fortuna of Jscrambler
Quick Take
On this episode of Compliance Unfiltered, the CU Guys are proud to be joined by, friend of the show, Pedro Fortuna of Jscrambler.
Pedro Fortuna serves as Jscrambler’s Co-Founder & Chief Technology Officer responsible for technology innovation, product strategy, and R&D. Pedro sits on PCI SSC Board of Directors and is a qualified Internal Security Assessor (ISA). Pedro brings over 20 years of experience in software engineering and security, leading innovative products from concept to market.
In addition to his role at Jscrambler, Pedro sits on the PCI SSC Board of Directors and is a qualified ISA himself.
Read The Transcript
So let’s face it, managing compliance sucks. It’s complicated, it’s so hard to keep organized, and it requires a ton of expertise in order to survive the entire process. Welcome to Compliance Unfiltered, a podcast dedicated to making compliance suck less.
Now, here’s your host, Todd Coshow, with Adam Goslin.
Well, welcome in to another edition of Compliance Unfiltered. I’m Todd Coshow alongside the whip cream on top of your compliance hot chocolate, Mr. Adam Goslin. How the heck are you, sir? I’m doing great today, Todd. How about you? Man, I can’t complain. I really can’t. Today is a special day in the Compliance Unfiltered world. We have a guest, and it’s not just any guest. We are fortunate enough to be joined by Pedro Fortuna, who serves as the co-founder and chief technical officer for Jscrambler, and is responsible for technical innovation, product strategy, and R&D. Pedro also sits on the PCI SSE Board of Directors, which we’ll come on to, and is a qualified internal security assessor. Pedro brings over 20 years of experience in the software engineering and security game, leading innovative products from concept to market. We are gosh darn excited to have you here Pedro. Thanks so much for joining us.
Tell us the story of how you got into the security and compliance space. Thanks, Todd, and thanks, Adam. Thank you for having me. I’m excited. So, well, I got into security, I think, right out of college. I guess, I’ve always worked in the security space. I think I’ve started more on system security, and network security, that was the side of things I was exploring in the early days. And then I think around 2010 or 2009, I started working with JavaScript security in the very early days of Jscrambler. And I remember going to application security events like OWASP and that sort of thing, and that really got me into the application security space. And then more specifically, I’ve always been very close to web technologies and code running on the browser. So that was my thing. And joining that together with application security really created the sweet spot for me. And I’ve always been following more or less, the compliance space as well. And I think that roughly like three years ago, I really got closer because, we’ve all learned that in DSS, they introduced two e-scheming requirements, which like with Jscrambler, we were already offering products to do what was needed to address those two requirements. So that’s how I got closer. And I’ve been close ever since. Gotcha. Very, very cool.
So when you were saying that you were involved in the security compliance space from the beginning, before you were in Jscrambler, what types of security or compliance engagements were you involved with? What was your role in those prior organizations? No, what I meant is I was following the space. I was not really doing anything. I wasn’t like helping companies become compliant, but I was interested in what was being done in several security standards and regulations, because that was like a reference for people working in security. Gotcha. Yeah, it sounds a lot like my path into the security and compliance space. I grew up in the IT management space, and then ended up basically getting forced to flip over into the security and compliance arena. So yeah, fun times.
So let’s see, while you’ve been doing security and compliance without shaming anyone, let’s leave names out of it, but what’s one of your entertaining security and compliance horror stories that you’ve had the opportunity to either help somebody with, or experience? Yeah, well actually these days, the story that I like to tell is the one where roughly two years ago, our research team, with me involved, we found a new type of supply chain attack methodology, where the attackers were chasing domains that were once used to host popular JavaScript libraries, and then just proceeded to acquire those domains to host a schemer on the exact same URL as the once popular JavaScript library was using. So one of the reasons I like this story so much is how unsophisticated the attack is. I mean, all they had to do, is just find domains that were now free, that were once used by popular JS libraries. And, anyone working in the web space, we know that the reason why we all use the browser as the main vehicle to use applications, is because the web technologies, and browsers are very forgiving. Like you can basically make all sorts of mistakes in your code, and the browser will do as much as it can to still run the application and show you the information. But on the other hand, that comes with a cost, people don’t do housekeeping. They don’t remove broken links. They don’t remove anything because, your website will not stop working. And that’s the basis why an attack like this is possible. What was possible, is still possible these days.
So we ended up calling this attack a defunct domain attack. And when we saw this for the first time, we ended up uncovering a defunct domain attack that was scheming around 5000 compromised sites, and had been active for years until we found it. We actually ended up building a free tool, which allowed organizations to scan their sites for defunct domains, if they are using it. Which is like, yeah, just a side a side effect of our research, we’re not getting any money out of that at all. No interest. Well, that’s interesting.
I think that actually lines up perfectly to ask, I mean, how long have you been with Jscrambler? And tell us more about the reality of your role there. Yeah, so as one of the founders, I’ve been there since the beginning. We actually started with this other company, and then pivoted. So at the beginning, we were building bot detection technology, but specifically for ad campaigns, like they were getting rid of click fraud, that sort of thing. But we were building bot detection in the very, very early days for that, like 2008, 2009. And now if you look at that space, there’s tons of companies doing that, and it’s a huge market. But we started doing that very early on. And I guess back then, it wasn’t a big market yet. And while doing that, we were collecting a lot of very sensitive information using JavaScript. And we found the problem of lack of integrity. How can you trust data collected with JavaScript, when a threat actor could have another script running at the same time, just spoofing everything that you’re collecting.
So how can you base your conclusions, your auditing based on that? So that’s what got us thinking, how can we improve that situation? How can we trust that data collection taking place in the browser? And that’s how we got to build the first product of the company, Code integrity. Code integrity is meant to turn code into becoming temper resistant, avoiding a whole class of attacks against code and interference on the browser side. So that’s how we started. And I’ve been there from the start. At some point we changed the course of the company. We renamed it to the name of the product, this product that I just mentioned called Jscrambler. And the company had a different name. And then when it was apparent and obvious to us that we should focus on that, because of the amount of JavaScript out there would only increase, as it’s obvious to anyone these days. And there was a significant opportunity to start developing technology to address the increasing risk of JavaScript running inside the browser. So we just renamed the company Jscrambler. And then we ended up renaming that product something else called Code Integrity. A few years later, we built a second product which is the one that we use to monitor websites, and the one that we use to address the DSS 643 and 1161 requirements.
At the company, to answer your question, I basically lead all product innovation. So as CTO I oversee the engineering products and research, I’m heavily involved with that. I also sit on the board of advisors of the PCI SSC. And these days, I’m working a lot in the compliance space. Well very cool. So tell us a little bit more about your involvement with the PCI SSC Board of Directors, and tell us a little bit about some of the recent changes that you’re seeing with PCI. I guess you’re probably referring to, last week’s announced changes to the SAQ-A. Yeah, that’s certainly the topic of the moment. Everyone’s buzzing about it. Being one of the vendors out there addressing the 643 and 1161. I should pause and explain what actually changed, because some people might not know what the change was in the SAQ-A. They removed the requirements 643 and 1161 and replaced that with a new, not replaced, but they introduced a new eligibility criteria that now says, SAQ-A eligible merchants need to confirm that their site is not susceptible to attacks from scripts that could affect the merchant’s e-commerce systems.
Okay, that’s a very vague and ambiguous eligibility criteria, but going back to what I was saying, I think as a vendor addressing these requirements, I’ve heard people, before all of the changes, I’ve heard people saying, the council will end up postponing the due date of April 1st of 2025, to meet these two requirements. And I always thought, no, they won’t, because they have been telling people for three years about this date, so companies really have no excuse. And also because if they did, then what’s stopping people from doubting every deadline that the council sets? So I really never thought that they would. Of course the changes to the SAQ-A is not a postponement, but it’s equivalent in the sense that it’s setting a bad precedent of making changes last minute. So what’s to stop people from thinking that, well, maybe I won’t meet this requirement that I don’t like because, like last time they cancel it last minute, and maybe let’s see if that happens again. So, it doesn’t help the council to be taken seriously when they introduce new requirements or setting deadlines. Yeah it’s tough when they’re doing it late in the game.
The other thing that we’ve seen is they’ll issue changes to the standards, then once they get the input and the feedback, you’ll see another iterative version of their changes come back out again. So it’s always exciting trying to keep up with the pace of change, right? Yeah. And also people haven’t been told the motivations of the change. So we’re a principle participating organization, And as I said, we sit on the board of advisors and I still don’t know, no one really saw it coming, right?. So as you say, this is definitely not making compliance suck less. Well, that’s why we’re all in this space, right? Is to help people navigate the waters. So, now I totally get it. But to help make compliance suck less, I think that the question is, how do you confirm that your site is not susceptible to attacks? You have to do something in, or you have to have something in place to confirm that. And that takes people back to the two requirements, which is why people are saying that this looks like a circular logic. Yeah, totally.
Well, I mean, that actually leads me to a question, Pedro. And that is, how can Jscrambler help organizations facing PCI compliance, including the upcoming deadlines for 331? Right. So as I mentioned, we help with these two requirements, 643 and 1161, including all of the demands of the two requirements. So 643, you have to maintain an inventory of scripts running on the parent page of the payment page, or on the payment page if you have one. You have to ensure a method to ensure the integrity of each script. And with 11.6.1, you have to detect any unauthorized modification to scripts, and you have to do this at least once every seven days. And our product really gives you all of this in a very easy way, so it’s easy to integrate our products. We basically offer the two different ways that you see out there. You either use an agent, which is a script that you put in your monitored pages, and that gets you going, or you use our agentless version. Our agentless version is basically something that you don’t have to integrate at all. It just gives us the URL and we have the tool go there, and do the inventory and detecting. With assisting, you and customers can use our dashboard, and the tool to authorize scripts to provide a justification for those scripts being used on your payment pages. It’s really just about making it quick, helping them meet the two requirements as quickly as possible, which is now very important given that the deadline is either March 31st or April 1st. It will help make their lives easy to maintain compliance with those two requirements. There was a lot of effort into designing the product to make it easier.
If you’re familiar with these two requirements in the guidance column of on the DSS standard, you see references to content security policy, or sub-resource integrity, and that takes people right off the bat to think about script hashes, and using hashes to detect that scripts have changed. And that really doesn’t work with the third-party hosted scripts, because they keep changing. They will not call you up and ask you if they can change their scripts, they will just change them. So, I guess some implementations might seem naive because they are using script hashes, and people will have lots of work every day. We just make all of that way easier, because we are not using hashes, we’re using behavior analysis. So we look at the behaviors, we see if they are within what was authorized, and if they go beyond what was authorized, we make a risk classification. So we provide all of that information, we make it easier for people to drive their everyday work around these two requirements. Sure.
Now, one question for you as it relates to these, is the information analysis and collection, is that something that happens on demand?
Is it running and doing a periodic sweep? How does that work? So it depends what version of our product you’re using, if you’re using the agent version, that means that every user session, every transaction will be monitored. And then data collection is continuous, and you will not miss anything. If you’re using the agent list, then it’s just a recurring thing. So we have an automated process to go there every once in a while. Like you can go to the page every five minutes, or every hour, wherever frequency that makes sense for the organization. That’s what we do. And then data collection is not continuous. it’s not like data is not being collected from real user sessions, but rather what we call synthetic users. So because it’s an automated browser going there, it doesn’t correspond to a real user, but it’s still very effective to see what scripts are running, and what they’re doing. And therefore, it could be lighter in some ways, because you have no integration, you don’t have as much data to process, and it could be very effective for some organizations to get going really quickly, without involving engineering, to just speed up the process of being onboarded into these two requirements.
Sure, different question for you. So let’s say I’m going in, I understand the one version will run literally in line if you will, the other one is periodically scheduled. If there’s a change that happens, whatever, something new is found, or there’s a modification to something that was existing, how does the user know that something’s different or has been discovered? So apart from just logging into our product and checking that out, they can receive email notifications, Slack notifications, other messaging systems notifications. They can feed the alerts and the notifications to CMs. There’s also the possibility of integrating with third-party software that manages compliance. So, we have lots of ways of adjusting to the way that we have integration with Jira. So there’s lots of ways that people can use it, because we have to adjust to how the organization works, not the other way around, because this is about making their lives easier, not harder. Totally understood.
Now that said, with the system basically doing the monitoring and having the capability for alerts, I can imagine that there are stories of organizations that had something changing on their system that they weren’t expecting. Oh yeah, you’re putting me on the spot. A lot of these stories I cannot share, or I don’t want to go into details. But no ,all I was saying is that at a high level, is it helping these organizations? Because that’s one of the problems, right? We go back, five, ten, fifteen years in the security and compliance days, oftentimes organizations didn’t even know they had a problem. Oh yeah, absolutely that was a big issue, absolutely. It happens very frequently, because one of things is that, and not just in compliance, but in the broader security space, think about the fact that traditionally in security there’s a lot of focus on the back end of web applications. So like the back end it’s your server, you have walls around it, you’re monitoring it, you’re on top of it. And the client side, it’s running in an environment that’s not controlled by the application owner, it’s probably the user’s device, whether that’s a mobile device or a laptop, but you don’t really control that. I need to choose my words carefully here but, they don’t pay as much attention to securing the client side of a web application. I’m not saying they should secure the whole device, that’s not their job, but they should deploy security controls to make sure that whatever is happening on the client side is secure. Because if I ask someone, what’s the worst thing that could happen to you, like to your company, they come back saying, oh, probably someone grabbing my whole database and leaking it to the dark web. Yeah, that’s an obvious response to that. But probably, and think about the payment space, if you’re collecting credit card information and storing it, that’s probably encrypted in a way that it would be garbage to the attackers. But, if they are able to scheme that data from the browser side as the user is typing it, then there’s no encryption at that moment. And if they are able to sit in every user session, they will just end up collecting the same amount of data that you would potentially, if you had breached the server and just grabbed the copy of the database. Yeah well, in some ways, although skimming it off of the browser, you’re not going to be getting it in the same volume as if I breached the backend database. But, you’re still getting ready to use information at that point in the game. Exactly, and it’s not just about collecting information. You can you can change what the user is seeing, you can totally tamper with the application, you can show more information about the user, that’s really the danger.
To answer your question. what we see on a very regular basis, is that companies will find that first of all, they don’t even know what they’re running on the client side, they don’t have a clue. They have the tag managers, and they have marketing teams injecting stuff in. They’re bypassing the security team, and they security team, most of the time don’t know what’s going on. They get angry at this because, they want to have a better grasp, they want to have processes, and they have they want to have control. So the things that we do with our tool provides that to them, starting with visibility, and then by enforcing control. You can block certain scripts behaviors, preventing them from harming the security, or undermining the security of the web app. And that’s it, we keep finding new stuff and new scripts. Some stories I cannot share actually. Nope, I totally get it. I would not want you to.
But that said, let’s move let’s move on to the next thing. At a high level, why don’t you talk a little bit more about your thoughts on the notion of continuous compliance, and development of an in depth strategy for organizations to be able to protect themselves. Yeah, I think some organizations, sometimes they’re overly focused on what they have to do to start meeting the requirements in general, but then they don’t think as much about what they need to do to stay compliant. And, sometimes the methods that they decide to use will not help them stay compliant afterwards. They’ll probably be able to stay compliant, but it’s not necessarily like the best method to minimize the amount of work that they will have after first addressing compliance. So I think organizations should defiantly think of compliance in a more continuous fashion, like automating as much as they can, streamlining the workflows, and decide who will be involved, and who needs to approve and verify something. So definitely I would encourage every organization out there to be more strategic in regards to setting up how they plan meeting requirements, and how they plan to go through every day chores.
Sure. Back when I initially generated the TCT Portal. Actually backing it up a little bit. I was out working on helping organizations both attain, and then maintain their compliance. The big thing that I was seeing time after time after time is, they would go through all of this effort to get compliant in the first place, and then breathe this sigh of relief and just adopt this approach that, okay, we’re finished with security and compliance now. I’m not going to need to touch this for another nine months or so, and then we’re going to go through the annual scramble again. It was interesting because, I’d land up in annual engagements talking with, sitting with a client, sitting with their assessor, and being forced to answer some really tough questions about, well, you need to give me your last four quarterly vulnerability scans as an example. And sure enough, the client will have done three of the four, and then have to do a dance to try to explain why they hadn’t done the other things. But it used to be very prevalent for organizations to adopt that annual scramble approach to their compliance, and it’s heartwarming to see more and more of these organizations taking this stuff seriously.
Real quick before we before we leave this topic, as it relates back to your work with the helping customers with 6.4.3 and 11.6.1.
How did the clients basically grab or extract their evidence, so that they can port it over to their compliance management processor system? Yeah, that’s a good question. So everything that we have in our dashboard is exportable, so they can export all the evidence that they need to prove that they have been meeting the two requirements. Not just like, as you said before, like they don’t do anything for nine months and then all of a sudden they start doing it. The 6.4.3 and 11.6.1, you have to actually show that you have been authorizing scripts, and you have been responding to changes as scripts start introducing new behaviors that weren’t authorized. So you have to have that evidence. You cannot just start doing it just before the assessment and hope that the QSA will not, at the very minimum, frown upon that. So yeah, so the tool provides every export and porting feature. The data can also be fed continuously to other software’s that customer might be using. And the goal is to make it really streamlined and simple for them. Sure, understood. Outstanding.
Before we get out of here, Pedro, tell the folks where they can find you. Well, they can find Jscrambler first, hopefully. That’s what I wish. Just type in jscrambler.com, or just go to any PCI community event, we’re usually around there. I also go to a lot of the top security conferences in the world. That’s where I hang. These days I live in Europe, but I probably spend a couple of months a year in the US, because so many of our customers are from there. Also, hit me up on LinkedIn if you want. I’ll be glad to get back to you and help you any way I can.
Fantastic. Parting shots and thoughts for the folks this week, Adam. Well thank you very much Pedro for joining us for this session. It’s always fun talking to folks in the space. I know that both TCT and Jscrambler have had a lot of fun over the years manning booths at the various PCI Community Meetings. It’s really cool that you guys have solutions that can generate that continuous compliance approach for 6.4.3 and 11.6.1. Then we can take the exports from your tool and be able to ingest them into the client’s overall compliance management. That is super awesome. We’re glad you guys are making things easier for people out there.
You brought up our tagline earlier about how we love making compliance management suck less. It’s awesome that you guys are in the same boat trying to do the same for the elements that you guys are covering. The other thought that I had Todd, is that in terms of an organization and their approach, it used to be that organizations would primarily go through that annual scramble for security and compliance. All of a sudden it’s compliance season and I guess, pun intended, scrambling to go ahead and get ready for their annual compliance event. More and more it’s heartwarming to see organizations adopting a compliance approach, an operational compliance approach, keeping their eye on things.
Pedro, earlier you were talking about the security team becoming aware, that somebody else had made a browser change that they weren’t exposed to. It’s all of the various suite of tools that you’ve got at your disposal, as well as the organization’s approach toward compliance that really truly does help to protect the organization, and helps to proactively set them up for their annual compliance engagement, by being able to give them real tangible improvements to their security position as a result. I’ve often said that, if somebody put a gun at my temple and said hey you need to either keep your continuous compliance program, or you can keep your cyber liability insurance, I’d drop the cyber liability insurance in a heartbeat. So it’s awesome that we’ve got cool folks like Jscrambler out there, helping folks manage and maintain their continuous compliance approach, and being able to solve problems which make the compliance world suck less.
And that right there, that’s the good stuff. Well, that’s all the time we have for this episode of Compliance Unfiltered. I’m Todd Coshow. And I’m Adam Goslin. Hope we helped to get you fired up to make your compliance suck less.
