Ensuring Data Security and Privacy On The Modern Web

Hello, basically how we get interested and do something together All right.

Hi, Mike. Thank you so much for joining us today for your first Cloudflare TV session.

We're very, very happy to have you here representing Tala.

So maybe we can start with a little bit of introductions.

I'm Jen Vaccaro. I'm the product marketing manager for Cloudflare Workers, Cloudflare's serverless platform.

And I'm here with Mike.

And Mike, do you want to introduce yourself a little bit? Sure, and thank you so much for having me.

I'm Mike Rogers. I am the senior director of solution architecture at Tala Security.

Awesome. So let's get started a little bit here.

We have some exciting things. We're going to talk about what Tala is up to, how they're solving some problems in the market today with Magecart and other security issues, and how they're integrating with Cloudflare Workers.

So why don't you get us started?

We have people from different sides in the audience.

So just to give us a little bit of background, can you tell us a little bit about Magecart as a problem and let us know how widespread it is, kind of why should people be concerned about this?

Yeah, for sure, absolutely. So Tala Security, we're all about protecting the sensitive data that's in the browser.

And when you say the name Magecart, there's a long history there.

Magecart, I guess, was a term that was coined in 2016 by some researchers at RISC-IQ and really dates back.

These kinds of techniques that were being observed date back all the way to the early 2000s, really coming into focus around 2010.

And Magecart in and of itself, that name is a contraction of Magento and Shopping Cart.

So this idea that these online stores, like in the Magento ecosystem, could be compromised at scale, being able to go in and modify JavaScript that powers the website and materially impact many websites all at once, that is a playbook that the bad guys really love.

And if you think about it, the way that these attacks, maybe in most cases that people hear about them, the way that they happen, it almost is like a JavaScript skimmer, or kind of like a credit card skimmer, if you've ever seen on the news where people are putting them in a gas pump and everybody that comes by, they stick their credit card in, and then the card data is stolen.

That same sort of playbook is happening every day on the web for sites.

And it's really not limited any longer to credit card data.

It's really any sensitive data. And so every business that has sensitive data either being entered into their website or read by users in the website are at risk for these kinds of attacks.

Interesting. So you talked about credit card data, and you said that it could be kind of expanding beyond that.

Just given the timeliness of this, are you seeing anything like that around elections, or election data, or anything like that that'd be concerned?

Or what else beyond credit card data might be of concern for people?

Well, I mean, for sure.

A couple of months back, there was a very large platform that powers some municipal governments, local governments that was breached.

And because it was a system for sending in your water bill payment, and other tax payments, and that sort of thing, it impacted many municipal governments across the United States.

And from a research and tracking perspective, absolutely our team sees this kind of stuff happening every day in the realm of health care, in the realm of insurance.

We see it even in such things that might be as simple as trying to compromise an email sign-up form to make an email database, for example.

So these areas where there might be less security, or folks that aren't as sophisticated, or outsourcing to third parties, are great examples of places where these attacks can happen and do happen.

Maybe you can explain a little bit for us why do these attacks happen? Do we have an understanding of that?

Yeah, I mean, I think that one of the biggest things is that the bad guys, the folks who are trying to do this, are always looking for the path of least resistance.

And so when we think about breaches, and security posture, and the like, we're often focused, maybe even myopically, on our own data center, and everything that we have to do there, which are obviously very important things.

We want to have a WAF that protects our servers from receiving bad requests.

We want to have a firewall and other perimeter security to make sure that no one can get in.

We're going to do things like Active Directory security, or identity and access management programs.

All of these things are to prevent someone from getting in and saying, hey, select all records from the database, and exfiltrating them.

Those are oftentimes very high hurdles for the bad guys to go after.

And so what we see them trying to do is look for a weakness. Maybe you're integrated with a small third party that is providing a JavaScript that runs on your website, and they might not have the best security, or they could have left an online object storage container or bucket unprotected.

And in that way, being able to go in and compromise those sorts of resources, say, upload or modify a JavaScript that's sitting in an AWS S3 bucket, for example, so that it's served to many websites, that's a prime example of a way that these attacks can and do happen.

And so when those actually make their way into your web application's running environment, every user that loads a page that has that code on it could have their data stolen.

And so this, now, the bad guys know that those simple ways to do it and the access to the data that's in a completely unencrypted plain text fashion, either in a form on a website or sitting in text on the website, those are really easy and enticing targets for them to go after.

Thanks, Mike. So you mentioned WAF and firewall protection.

Can these alone solve these kind of attacks? Honestly, they just can't.

I mean, they can do a lot to make sure that you have the right amount of security around the data itself while it's sitting in your data center.

You can even use all of these techniques to try to thwart anyone having the ability to get in and access and modify data that's sitting on your web servers.

But because of the dynamic nature of the web, the way that we're so reliant upon third parties and other integrations, open source, frameworks, et cetera, to build our web applications and deliver them to our customers and users on a daily basis, in this way, because all of the exploitive code is running in the browser, those tools really just don't have any way to prevent or stop that malicious code from running if a breach does occur in any part of the web applications infrastructure.

So when a bad guy is running some JavaScript and trying to skim it, they'll set something up to go ahead and have the JavaScript make a call out to their server and push the data there.

So it completely bypasses something like a WAF. It completely bypasses any firewalls that you have.

They'll leverage cross-site scripting vulnerabilities, which when we see the research, it's really the number one threat to the web today.

And so trying to patch every single potential cross-site scripting vulnerability is often extremely difficult.

And you have to have some way to have a backstop against this stuff and really prevent it.

Gotcha. So how would you say, clearly this sounds like this should be a priority for companies to be able to address this.

How would you say this ranks in all the security and threat issues?

Is this number one concern that companies should be really addressing more than ever nowadays?

Or how would you say this plays out amongst all of the other threat and security concerns that we're seeing out there?

That's a great question. There are so many problems out there that need to be solved.

And I think this is one of those problems that maybe folks don't really realize is as big of a deal as it is.

When we get into a meeting and we talk to CISOs or leaders in their security organizations of the various businesses we meet with on a day-to-day basis, a good number of them really don't have a handle on why this is super important.

The ones that do and that have more mature programs, they for sure see that this is something that they have to tackle.

And absolutely, I think and I know a lot of folks do believe this is one of the highest priorities for organizations out there.

I think what maybe makes it a great choice for something to prioritize is that in a lot of cases, this can be a compensating control for things like unpatchable cross-site scripting vulnerabilities or other things that you might not have complete control over.

So as businesses are charged with doing more and more with less resources, it just becomes difficult to stay up with all the latest in-browser security controls that are available.

And so for TALA and the way that we work and we integrate with Cloudflare and the opportunities that this presents, it makes for a difficult problem that is easy to solve.

Interesting, interesting.

And so it sounds like these security implications here are pretty widespread.

So curious, what other impacts should organizations be thinking about when considering the client-side security issues that Magecart leverages, such as privacy, compliance?

Yeah, I mean, this is another really, really great point. This isn't just an issue with data security in terms of worrying that your data is going to be stolen.

More and more, what we're seeing is that when folks are buying cyber insurance policies, they have to go get a risk rating.

And there are a number of risk raters out there.

Those risk raters are looking externally at your website and making sure that you have appropriate controls around your sensitive data.

And if you don't have these, then you're going to be dinged.

You're going to pay a higher premium for your cyber insurance when this is the case.

And not only that, if you do have a cyber policy today, we've seen evidence in other similar environments as security controls have matured that you could actually have your cyber insurance claim denied for failing to implement the appropriate controls around other security topics.

And now, as I said, as these rating services, as the insurance companies themselves become more and more aware and mature around how they evaluate this stuff, there's always a chance that you could come into a bit of trouble as a result of this.

You also mentioned compliance. And again, this is a huge deal.

So in the news just in the last couple of weeks, British Airways was, I guess, there was a resolution to a Magecart-style breach that they suffered a couple of years back, where they were fined about, I think, 30 million euros for failing to adequately protect their users' sensitive information on the website.

Almost 400,000 end-user credit cards and other bits of information were stolen in an attack exactly like this, where this is a huge impact to a business like that.

I guess that's probably the way I would say it.

Yeah. So what are some ways that organizations can defend against these type of attacks?

Yeah, actually, there are a number of ways out there that folks are thinking about solving this problem.

You can try to scan your website on an ongoing basis and identify changes and look for potential problems.

There are solutions that do that. There are solutions that attempt to control all of the JavaScript that runs on the page by doing basically a JavaScript virtualization approach and virtualizing all the JavaScript calls.

This is an interesting approach.

It has a bit of a challenge around the way that it impacts performance, so it's not the way that we think about it.

The browser vendors themselves, in conjunction with the W3C and specifically the Security Working Group for the World Wide Web Consortium, are constantly iterating over new controls that are and will be available in the browsers to further enhance the security that's available there.

In particular, there are ways to add just simple response headers to web pages as they're returned back to the browser and inserting these headers, like the Content Security Policy header or HSTS, which is for ensuring that a certificate is exactly correct and there's no man-in-the-middle attack, other capabilities in that realm.

That applying these standards really is the best process or best way to address this.

And not coincidentally, that's at the core of what TALA is all about.

Yeah, so maybe you can talk a little bit about TALA in particular as a company and how you are envisioning solving these prevalent issues.

Yeah, so historically, TALA, our founding team were guys that had worked at Symantec.

These are big time security guys in the world of endpoint.

And they worked a lot and maybe got part of the idea for the business in working on the target breach a few years back and looking at the kind of ways that those attacks are happening.

In the target breach, I guess someone had gone in and compromised the point of sale software at Target.

And in doing that, it allowed the theft of the credit card details.

And so that sort of aha moment and then with the foresight of what the threats would be on the web, that's how TALA came to be.

At our core, we're the platform for maybe automating, deploying these controls.

That would be our DNA.

But what we really are today is a platform for protecting sensitive data in the browser, continuously monitoring for the potential of abuse and theft of that data, and simplifying all of that in a way that really makes it a low barrier of entry to get involved in protecting your data in the browser with the highest security standards that are available.

Gotcha. And I know that you're using Workers, which I'm not sure if those people tuning in today are familiar with Workers as part of Cloudflare.

But like I said in the beginning, it's our serverless platform for edge scripting.

So can you tell us a little bit, how are you solving this with Workers?

Yeah, for sure. And we think Workers are great.

It's definitely an awesome, fast, easy-to-use platform that solves a lot of problems.

For us, what we're really trying to do is, as content is being returned back to the browser, we want to do two things.

One is we want to be able to append response headers.

And in many cases, we want to modify the HTML that's being sent back to the browser to add attributes to HTML source tags for scripts, for example.

Or in the case of an inline script, obviously add an attribute to that inline scripts tag as well.

So Workers, being a JavaScript-based solution and built for the web, super fast, highly distributed, all of that kind of stuff, it's just the perfect platform to very easily deploy a solution.

And not to mention that it has an API that we rely upon.

So we built a brokerage service that connects to Workers and then also leverages Workers KV, which is the key value database inside of Workers.

For everybody, I'm not sure if everybody knows that.

But we just thought, hey, this is a great platform. That brokerage service talks to our API, pulls it for changes on an ongoing basis, and then pushes a series of keys and values to the Workers KV store.

And then our Workers code executes on every page request, looks for the appropriate content type on the response, and then modifies the response on its way back to the browser.

So all of this is done with basically no effort to the Cloudflare customer.

It's super fast. Workers obviously adds almost no latency at all to the return in this case.

We're just very quickly doing what we need to do with the page content.

And it provides awesome security.

That's great. Yeah, that's great to hear. How long have you been using Workers?

I should have to go look at the exact date on the blog. I think it's been about six months since we've had official Cloudflare integration.

Interesting.

Yeah, we've definitely been evolving a lot over just even the last six months since I joined.

You mentioned KV, which as you said, is our key value store for eventually consistent data.

And I don't know if you've had a chance to play with or check out something we announced during the birthday week, which was a durable objects, which is our strongly consistent data offering.

Yeah, I mean, honestly, our engineering and product teams were so excited to see a number of those things, including the I think you guys also announced a timed or it's almost like a cron service.

Yeah, so all of this they look at very closely. I think even some of it we might have had a little bit of insider info in advance.

But that sort of thing we love to see because it helps us to iterate on our integration and continue to make things better.

What we really want to do is have something that can be easily used by every Cloudflare customer with almost no effort and just real simple process.

Interesting, and you also mentioned some of the performance benefits with workers and in general.

So maybe you can tell us a little bit about those performance benefits by delivering this solution with Cloudflare.

Sure, absolutely.

Solving this problem is very difficult. And like I said, one of the options that are out there that a number of our competitors uses to actually inject the JavaScript that runs in the browser.

Because we're simply deploying the browser's native controls using workers, it basically costs nothing in terms of performance that things like after the payload is received by the browser, there's no rendering overhead.

So it's super fast in that respect. And with workers, all it is required to do is just take a look at the payload that's coming back and make a couple of small edits to that, appending in response headers in 99% of cases and a small percentage of if it's enabled adding some attributes to the script tags.

I mean, what we're seeing is in the handful of milliseconds of overhead in the worst case by implementing us.

Gotcha. And are there any other performance considerations that would be top of mind for you or for your users?

Oh, man.

I mean, I think speed and all of the relevant speed metrics are the things that we end up talking about the most.

Obviously, there is a ton of benefit to having an end-to-end automated solution to organizational metrics around performance.

We don't want folks to have to spend a ton of time and have all the overhead that goes into trying to run their businesses and run their security teams.

We try to reduce their time and effort, not add to it.

Gotcha. So to that point, how hard is Tala to manage and what is the administration of it like?

Well, I mean, once you've set it up, and I just did this for a very large financial services company that's one of your customers, a shared customer.

That set up, we scheduled for 30 minutes.

It was about a seven -minute call, and that included us having a few laughs.

We also, on an ongoing basis, kind of in a management, I think a customer can be expected after there is a bit of a learning process up front when you deploy the security controls to the browser.

But after that initial couple of week or so where you might spend two 30 -minute sessions with one of our implementation engineers, you're probably not going to spend a ton of time on this, unless, of course, the bad kind of stuff happens.

But with the beauty of the positive security model of the header -based security or content security policy and the like, if you're under attack, you're generally not going to actually feel the pain of the attack, because it is a allow list.

You're not having to play whack-a-mole, blocking this, blocking that.

You simply, when working with Tala, we'll come up with a list of all of the sources for loading web assets and destinations for sending data.

And that entire bit of information becomes the application information model, which then is used on a continuous basis and continuously updated to provide an accurate in-time list of who's allowed to operate within the context of your web application.

So if anything is happening outside of that, an attacker somehow compromises your third-party service for click tracking.

In that case, that nefarious third-party's exfiltration endpoint would be blocked.

So they won't be able to get your data. You'll get alerted by Tala, and you can go ahead and deal with it, go mitigate that problem.

It's all end-to-end buttoned up.

It works perfectly with Cloudflare Workers and KB, and it's just a no-brainer for implementing this stuff.

That's great. And so you mentioned financial services customer that you share with us.

What sort of industries, in addition to that, have you seen success with or that would be a really good fit for this solution?

Yeah, for sure. I mean, anywhere that has sensitive data is kind of the party line.

The reality is, if you're in retail, you've got to make sure that no one is jumping in and stealing your customer's credit cards.

When it comes to the things like health care business, PHI, HIPAA controls, all of those kinds of things, critically important.

You need to make sure that folks aren't taking that data.

Anywhere that has a login, I mean, this is one that folks don't always think about.

They just say, hey, I don't have a ton of sensitive data.

But if your web application has a login, you're a great target for someone to try to harvest username and passwords.

Because despite all of the efforts by everyone, we still, by and large, folks are reusing usernames and passwords.

So if someone can sneak some JavaScript onto your web page in the context of the login form, that JavaScript can steal all of those usernames and passwords and go use them all over the web.

You're just going to end up on, have I been pwned?

Yeah, yeah. So we have a couple more minutes here. And I want to make sure if there's any sort of remaining things you want to share, how people could get started with this solution.

Do you have onboarding tutorials? What's the best way to get started?

Yeah, I mean, the best way to contact us is sales at talussecurity.io.

And we will love to chat about it and work with all the Cloudflare customers out there, or anyone who's not a Cloudflare customer.

Even if someone's not a Cloudflare customer and they're watching this, jump on to Cloudflare, work with us.

We would love to do it.

Gotcha. And do you have onboarding documentation? Or I know you have a video that's discussing integration with Cloudflare and whatnot.

If they don't want to go straight to sales, is there other places you might?

Yeah, absolutely.

We can share that video, and folks can take a look at it. It's just a quick YouTube video, about five minutes or less, where one of our great engineers, Sudesh, demonstrates exactly how to get up and running with this.

It's so simple. There's really no magic to getting set up with Cloudflare, dead simple, easy to do, five minutes or less.

What would someone look up if they wanted to get there to that video?

I think if you Google Cloudflare Talus Security, you'll find the video.

That sounds great. Good. So we have about two minutes remaining. I'm not seeing too many questions, but I'll open it up.

If people do have some questions, they can feel free to put it in the chat.

Otherwise, Mike, I'll let you take a minute or so and wrap us up here, or share any remaining thoughts that you do have.

Well, I just want to say thank you so much for having us and giving us the opportunity to use the platform of Cloudflare TV.

XSS, these kinds of vulnerabilities, client-side security, it's an important thing.

It's probably one of the most important and forgotten things for folks when they're budgeting out for their data security strategy.

There's data in the browser, and that data is unencrypted.

It's so enticing for the bad guys. And protecting it, especially if you're using Cloudflare, is so easy.

There's no reason not to do it. Great. Well, thanks for your time and for educating us all on Magecart and this integration with Cloudflare.

And thanks for using workers and being an advocate for our serverless platform.

So with that, I think we're coming to an end here, and we'll let everyone get back to their day.

But I appreciate the time, Mike. Thank you so much for having me.

All right. See you. Have a good one. Bye.