RX 24 - Card Testing And Cloudflare Panel Discussion

Transcribed Content

Session number five. I'd like to welcome Jonathan, Brian, and Morgan for their panel discussion on card testing and Cloudflare. Hey, guys. Thank you so much for coming. I'm Morgan from MyWell. I'm gonna be kicking us off, and then I've got Brian Davis from One and All and Jonathan Anderson from The Arc who are both MyWell churches that have some experience with this stuff. So we brought them in to share their expertise and give you guys some real world knowledge about some of these things that churches are facing. So I'm going to get us started with just a general overview of what card testing is, what Cloudflare is in Rock, and just some kind of big picture knowledge for you before we let these guys do all the technical talking for me. So I'm gonna get us kicked off. So what is card testing, and why are churches targeted? So card testing is when nefarious actors have some card data that they have acquired, and they need to find a way to make sure that that card data works somehow. And if you think about when you're on the internet and you're using your credit card, often churches or nonprofits are the only places where you have to enter very little information to make some kind of charge on a card. So you put in $1 You put in the card information, hit Submit, and you're off to the races. Whereas if you go to a store online shopping, you may have to log in. You have to put something in the cart. And for card testers, that's just not efficient. And so churches websites make it super efficient. Oftentimes, that's because there's no login. A lot of churches don't require you to log in. There's no barrier to entry for them to put in that card information. And so churches get targeted exponentially more than other e commerce kind of platforms or platforms that accept cards on the web. So that's what card testing is. And you definitely want to avoid it because you as a church, if that car testing goes through, those transactions are successful, you'll still be responsible for the costs associated with those transactions. And so if they can get off 1,000 transactions in a few minutes, you'll still be responsible for the processing fees associated with those, even if they were nefarious transactions. So it's important to know about this and take steps to prevent it with your processor, your donation management provider. So this is kind of a high level of what processing is. Oftentimes when we talk with churches, they don't necessarily understand the difference between gateways and processors and things like that. And so this is a high level of what's happening there so you can kind of understand that. You have the cardholder, the person who is making the payment. And that information goes to the gateway. So specifically with MiWA, when you are in ROCK and you're making a payment, we have what's called a tokenizer that's collecting that card information. So that's never hitting your Rock instance. That information is hitting our gateway. So we're responsible for PCI compliance. And so you don't have to handle that. And so the gateway then takes that information, encrypts it, and passes it on to the processor. And the processor is the one who actually contacts the card issuing banks and pulls that money out of that person's accounts and then passes that on to your bank. And so with MiWEL, like I said, our tokenizer is handling all that so that you don't have sensitive information hitting your ROCK instance. So what are effective ways to prevent card testing? So this is going to be different for every donation management system and how they choose to handle this. So I'm going to kind of speak specifically to some of the things that MiWell does and other things you can do as a church, regardless of your donation management system as well. So the first thing is requiring a CVV number. Sometimes gateways have the ability to toggle this on or off. A lot of times card testers won't have this. So if you require it and if you have your fraud rules checking for it, this is one quick, easy way to prevent that. And for MiWELL, this is one of the required rules we have. When you start with MiWELL, we have some fraud prevention rules that we highly suggest you implement. You can always opt out. But these are some of the ones that we set you up with. Check addresses and zip codes. Another thing card testers often don't have is the billing address associated with the card. So if you're actually checking that that is the accurate address, which not every gateway does that, this can help prevent the transaction from successfully going through. Set a minimum value. Card testers are going to just try $1 They don't want to let anyone know what they're up to. And so they're just going to try small amounts. So if you set minimum transactions, they're going to hit a wall, right? They'll try $1 it'll fail. They'll try $2 it'll fail. And whenever they eventually they're not going to want to go any higher. And so whatever your church is comfortable with as a minimum value, that's recommended that you would set one of those up. Blocking multiple transactions from the same IP. If you're in the middle of an attack, you're being actively card tested, one of the quickest ways to stop it is if they're coming from the same IP is to block that IP. Now, can always change it. But this is a quick temporary solution for you to implement other things to stop the card testing. I'm going to kind of jump around a little bit. The other one would be requiring a login. So if you're in the middle of an attack, you can always put your page behind a login wall while you work on setting up some other things to stop the card testing. You can do this permanently. You can put your giving behind a login wall. But that's not a best fit solution for some churches because it does require that your users have an account. Now I could get on my soapbox and tell you all the reasons I think that's a great solution of getting good data and knowing who your people are. But that doesn't work for everyone. We know some people want giving to be as easy as possible. So we'll go back. Limit checkout attempts, velocity. The other thing that happens with card testing is they'll build a script. And that script is just going to run really quickly through 1,000 different cards they have. And so you can have, with our fraud prevention rules, a velocity check. So how many transactions in x amount of time do you want to trigger a fail set? You want it to stop those transactions. And so that's a really helpful one with card testing. One that may not be a best fit for your organization but can be helpful is blocking countries outside of The US. So a lot of times these are going to come from IPs outside of The United States. If you're an organization that has a lot of international givers, this is probably not an option for you. But if you're a smaller organization and you don't typically see that, this could be a great option to help prevent card testing. Set up a firewall or Cloudflare to guard against bots, and we'll talk more about that. And then CAPTCHA. There are a lot of blocks in Rock now that work with CAPTCHA, and this is a functionality that helps verify if you are alive and breathing. Those fun little click the one that's not like the others or all the crosswalks or fire hydrants or whatever kind of things they have in there. And then use a third party monitoring service. So like with MyWell, you can set up the fraud prevention tool and customize that to fit your church's needs. And so these are the blocks that you can set up CAPTCHA in, in ROCK. And Cloudflare actually has a free account that you could set up today and configure in your Rock instance that's super basic, but will at least get you CAPTCHA on these blocks. And so if you want to add that, Rock has documentation on how to accomplish that. That's super straightforward. And then you can have this little checkbox you see there with the GIF on your giving blocks to verify for the living, breathing humans. Okay, I'm going to welcome my awesome tech guys to share some of their experience with some of this stuff. So we're going to go through three different questions. And then we'll have time for some Q and A for you guys to ask them or me about any of the questions you have around card testing. So the first question I have for these guys and whoever wants to go first, just feel free to come grab the microphone. How have you and your organization experienced card testing? And how did you handle it? So yes, we have experienced card testing. The first time that we experienced it, we had been on Rock for several years. And so it was a surprise for me as a Rock admin. I had no hand in any of our Rock implementation, so I didn't know anything about any of this. It's a bit of a panic moment. Our card presser card processor actually shut us down. We had 10,000 plus transactions, in a span of a couple of hours in the middle of the night. And so we woke up to this. The the next day, whenever they caught it, shut us down, pulled us in the loop, and it was painful to go through. There were lessons learned. The fraud prevention rules that Morgan mentioned are just necessary. So I would highly recommend if you do not know if you have any of the processor rules on there that you should check it out and verify what you have. She gave an exhaustive list of the things that you would wanna do, and I would definitely recommend going through that list and seeing what makes sense for your organization. Yeah, very similar story here. We definitely had it happen. And yeah, it was something that happened over the night. We woke up the next day, I believe we got an email from our processor. And they let us know that it happened, that we've been shut down. And then we took a look at our ROCK instance and basically backtracked and found, Okay, these are the users that I mean, anytime you get that many users pop up overnight too, it's kind of suspicious. So we had thousands of users show up too. So it was kind of a scary process for us. And we immediately stepped in and tried to implement these rules. I think one of the things we wanted to do before we even came back online was get those rules back in place just because we were clearly on someone's radar. So we put those rules in place before we came back online, and then our data management team started going through and doing merges. And it's to basically get rid of those accounts, and then work with our finance team on it as well. So yeah. Yeah, if you do get hit with card testing, that is one of the hardest parts I think is the cleanup of when you have to clean up all those records, potentially refund any successful transactions that did go through, and just all that work. A lot of processors do shut you down if it happens to you. And so you will be without a way to take donations until typically they want evidence that you have implemented some kind of solution. And so you've got to take pretty quick action to get your donations back up. And so it's always better to be not preemptive. It's always better to be prepared and not get attacked than have to do all the work after the attack. Yeah, that's for sure. So my next question for you guys is what are some things that you have implemented to protect your organization from CART testing? Yeah, in our case the first thing we did was go through, and I think we immediately went through and locked the page down after it happened just to make sure nothing else came through. Even though our processor was off at the moment, we just wanted to take control of the situation. In order to come back online, we did go into Cloudflare. At the time, Rock had not built the functionality to allow there to be an integration into Rock for Cloudflare. Right now, their system now is much cleaner. The block that's taking the payment is actually doing the check via Cloudflare, but that did not used to exist. So back then, Rock had a way where you could basically just say certain pages as a whole should go through an extra check. And they have a really good way in there where you can use a lot of those same rules. They're not related to payments, but they're related to someone's IP address, where they are, how many times they've come through your site. And then Cloudflare has a pretty good job of just kind of detecting whether things don't quite look right. And so you can set those things up and basically lock down certain pages specifically. So that's one of the things we did. So similar story. Of course, we got shut down by our processor, we went in and turned on login on the page. I believe we might have even shut down the processor just in our ROCK instance for a little bit. Got with our processor and started implementing rules, turned it back on. I will say once they find you, they will be back. And so the rules that you pick, you might have to fine tune them a little bit. We found that a dollar amount was really important here. We actually upped our minimum donation to $5 because we found that they were going up, up I'm sorry, dollars 6. They were going up, up, up. We bumped it $2.03 dollars 4 dollars 5 dollars 6 dollars it stopped. So doing that, limiting by IPs, how many failed transactions, that was another thing. Of course, hackers get smart, and so they just start changing their IPs. And so that is something that you might put IP blocks in there, and they're still coming through. Back whenever this happened, there was no Cloudflare integration into Rock. And so we did the same thing, put Cloudflare in front of it. And then I actually protected our entire site. And then I had to go into Cloudflare and make exceptions for things that Cloudflare broke because being overly protective. So between the processor rules and the Cloudflare rules, there is a balance to be struck there on what you want to do. Neither one will be foolproof, but now with the combination of both of them, it's been really solid for quite a while. Yeah. It's definitely not a one size fits all. So that's why, like with MiWELL, we'll have some recommended rules and then ask you what else you think your organization might want just because you have to figure out what's going to work for you. And especially after you've experienced card testing, you may have some things you really want as an organization. You know you want address verification for sure or a certain amount that you want set because you've experienced it before. So you have to figure out what works for your organization. And then what are your best practices for Cloudflare, and what has worked best for your organization? And any tips? So best practices for Cloudflare probably depend on your organization. For us, like I said, I protect our entire site with Cloudflare. They have some default rule sets that you can use. One is an OWASP core rule set. Not sure if anyone's familiar with that, but basically it is a penetration testing top 10 list. These are the things that they go after. And so Cloudflare curates these rule sets and lets you use them. And so it is a great benefit to IT admins that need to protect something and do not have the time to manage all of these rule sets their self. There are some caveats there. There are some things that you might need to turn off on that. And in Cloudflare, they have a WAF, a web application firewall. Whenever you turn it on, you put it in front of your site. You do have to proxy DNS, so your DNS queries go through Cloudflare. But it works really seamlessly. It even works if you have a CDN. We've recently updated our website. New website is out. And we're using a Triumph CDN in front of our website and Cloudflare in front of that. And it all works seamlessly. So like I said, there are some things in there whenever you're going to your application firewall that you'll need to make exceptions for when you're doing that. There are things that Cloudflare might break other than payment processing. Some quick examples are your image uploaders. If you have group leader toolbox and they could upload images and things like that, if you put Cloudflare in front of your entire site, it could break some of those pages. Communication entry page was another one that broke both internal and external for us. And so adding a few exceptions to the rules. The other thing that we did with Cloudflare is like on campus. If you're on campus specifically, if you're coming from our IP address that is staff, I've turned off Cloudflare on that portion. Might not be the best thing to do, but again, it depends on your organization and what you can handle. So there are definitely some things there. If you have any questions about that, I'd be willing to answer any of those afterwards. Yeah, a lot of the same. I would just add to that. One of the things that we noticed, there are lots of features built into Cloudflare apart from the firewall and apart from this. The turnstile is the product that actually allows you work directly in the block. And if you don't have something to protect in place, I would say go ahead, set up Cloudflare with just with turnstile or just with the firewall and turn off everything else. That'll get you the best protection today. Everything else just basically helps to optimize your site, makes things move a little faster, makes the user experience a little cleaner because the browser is not having to download as much stuff. Cloudflare basically goes through and groups together a lot of the files and provides them to the browser a lot quicker. So you'll see some speed ups there. But there is some downsides to that that that he kind of mentioned. It can break some things in the process of grouping things and cleaning things up. Sometimes it actually throws something out the window that you actually needed. So I would say just go through, get the basic setup to get protection you need in place, and then maybe go through and just slowly start adding those other features in. And if it slightly breaks something, then it's easy for you to go and turn that one back off again and maybe figure out why. One of the things that we've turned off was the ability when your browser loads a page, it goes and gets scripts from all over inside of Rock and even other sites sometimes to help the interface work. And that JavaScript can have a lot of load and slow down. So Cloudflare will group all that together and compress it, which is really good, but that did break things for us. And so I just turned that off. I found there on some pages, it actually worked really well. And then I went in and put in special rules and said, you know what? It works fine on the public site. Go ahead and let that work on the public site where the users are really going get that improvement. But on the admin side, I'd rather wait another half second and actually have it work all the time. So you can go in and dial in it. But again, would say just go in, put the firewall in place first, and then turn on that stuff. One of the things I really like about Cloudflare is even though we're throwing around a lot of technical terms, it is the absolute easiest way to turn on some of these features. And you really don't need a big technical background to do it. I'm not an expert in the areas of a lot of the things that we've talked through. And a lot of the things that you turn on in Java in Cloudflare is just a single toggle to switch it on. And you kind of get the advantage of people with really, really good knowledge. I mean, at Cloudflare have gone through and make us made this a single toggle on, and they've done their due diligence. And so then you just kinda have to work through the very, very rare cases when it doesn't work as you want. That's great. So what questions do you all have? We got a wealth of knowledge up here between Brian and Jonathan, so we'll open the floor.