Transcript
Overson: My talk is all about the cost versus value of attacks, the economics of attacks. I was told that this was a boring title, so I changed the title to "How Much It Costs to Attack You," which is essentially what we're talking about. How much does it cost to attack you? Do you know? If it cost nothing, would you know? That's important to know because if it costs nothing, then I might just attack you just to see what I get out of you. Figuring out the return rate on an attack takes a little bit of math, and a little bit of understanding of the inputs to those equations.
Cost vs Value
When we're talking about rate of returns for different things, you need different equations, and let's for the sake of example, use something like a carnival game because it's similar to what we're talking about in attacks. You have a chance of success. You have a value in the prize you get, and you have the cost it takes to actually play the game. These are the inputs that we're actually looking for when we're talking about attacks.
Given a game like this, let's start off with the cost. This is obviously contrived, so I can make up whatever cost I want. Let's say this is a dollar. I think actually most carnival games right now are obscenely prized, like $5 or something. It's like they just smack you in the face about how much they're trying to rip you off. The value is something that you need to decide for yourself. It's not necessarily the value of this toy. The value is not necessarily what you could pay on Amazon for it because it's here, it's now. The value is different. You might not need a pink gorilla, in which case the value was just about zero. Or you might have two kids tugging on your leg, in which case the value of providing them this fantastic pink gorilla that you so skillfully won in front of them might be fairly high. You need to figure out your own value, and same with companies. You figure out your own value similarly, based on whether or not anyone's tugging on your pant leg.
Now, the chances of winning. This is where this example breaks down because carnivals games are never this straightforward, but for the sake of example, we're going to count up all the winning cups, count up all the losing cups, and calculate a percentage, a chance of success. In this example, this is calculated at 10%. In realty, obviously, it's much, much worse. There are no walls, there are shenanigans in play. Some of the winning cups might have springs that launch your ball out. Don't play these games, they're awful.
To calculate our return here, we want to multiply the value by the chance of success, divide it by the cost, and then subtract our initial investment, which is essentially 100%. What we get out of that is the rate of return if we play this over time. For the example that I laid out, we have a value of $10. It's a 1 in 10 chance of winning, and it costs us a dollar, so we subtract our initial investment 100%. Then, we get a 0% rate of return. That's not bad. It means that you're paying what it's worth over time. If you play this enough, you will eventually get enough pink gorillas to offset the cost.
If the value increases, the output changes. If the value increases to $20, your rate of return over time is 100%. This is a good place to be. When you find these particular scenarios, you want to keep playing over and over again because you will end up being very rich in pink gorillas, or money, whatever your form of currency is. On the opposite end of that, if the value or the chance decreases, your return is going to be lower. This is where a lot of carnival games want to be. They want you to go broke, and they want all your money. If the cost also goes up, then the cost versus value is way out of whack. The more you keep playing these games, the quicker you'll go broke.
We make these calculations all the time, whether or not we're using equations like this, or where we're just using gut feel. When we're at a supermarket, or Best Buy, or anything like that, we've got physical money. That's our cost. We're assessing the value of something on the shelf. If it is valuable enough, then we pay that amount and take it outside the store. We do this also in other things, while at work, in relationships, or as a parent. If any of you are parents, and you're trying to teach your kids how to tie their shoes, and you've got two untied shoes in front of you, is the value of you stopping to help them learn how to tie their shoes one more time greater than the cost of being late? You make those decisions a lot, all over the place. If the value is greater, then you do it. If it's not, then you just tie the shoes for them, and you move on.
Attackers do this too. This is why breaches and attacks are exploding right now. The cost of an attack is dirt cheap, and the value is astronomical. This is true for almost all types of attacks.
Who am I? Should you trust me at all now that I've already brought you in here? My name is Jarrod Overson, I'm a generic web dork. I'm a director at Shape Security, and a Google developer expert. I'm also an old school video game hacker. If you've ever played StarCraft, Total Annihilation, Fallout back in the day, if you ever broke those games, use map packs, or editors, or things like that, you might have been using my tools. That was my first foray into the back and forth with an entity trying to thwart what you're trying to do. You can find me at jsoverson almost everywhere. That is what I looked like when I had more hair, and didn't have glasses. I don't think I'm going to be updating that ever.
Oh yes, I have to do this every time because every time that I mention that I work at Shape, I get a bunch of blank stares in the audience because we're not cool like Microsoft, or Twitter, or Facebook, or Netflix. You can't take a picture with Shape and share it to your friends of the food that you're eating. Have you ever heard of the company YKK? Some people have. I guarantee that virtually everyone in this room uses their product on a daily basis, because YKK makes virtually all zippers in the entire world. If you look at your zippers right now - your zippers, not my zippers - you'll probably see YKK on them, on pants, shirts, backpacks, whatever else. Long story short, Shape is the YKK of web security. We're virtually everywhere. You probably have run code that I once wrote today. We're relevant, but you just don't know our name because we're YKK-ish.
Cost vs Value in Security
Cost versus value in security. It's important to also differentiate manual work and automation. When we talk about an attack, there is no attack that exists where you can go up to a button, press it, walk away, and get money pouring all over you. There is always some aspect of manual work, and some aspect of automation with every attack, and usually attacks walk this path back and forth. Automation can be anything from like a port scan, to a Google search, to using Burp Suite, or some sort of fuzzing tool, or Puppeteer, Google, anything like that. Then, manual work is basically everything else, everything that can't be covered by an automation tool, or is specially important enough to be handled by a person.
These are important to differentiate because they cost very different amounts. Manual work is sufficient when the value is high, or when there is no possible other option, and you assume that the outcome is going to be valuable. Manual work cannot scale when the value is reduced. Automation, on the other hand, is the exact type of solution to something that isn't as valuable as it once was. This is the same sort of stuff all businesses across all industries are talking about. We're all moving towards automating everything. Of course, the criminal ecosystem is going to be doing the same thing. As stuff becomes too expensive to do by hand, you automate it, and automation works until it costs too much, and then you see this back and forth. You see the seesaw flipping back and forth, and you want to be able to adjust that in order to figure out how to deflect attacks.
If there are no defenses in place, costs are negligible. Now think about back to the carnival game example. If it costs $0 to play, you would just play it until you won everything. This is why this is important, because if it costs too little to attack you, then people will attack you just to see what they get out of it, and if they're getting anything out of it, they're going to continue attacking you until they get as much as they possibly can. Now you add defenses, and every time you add a defense, you force a generational shift in the attacks. The cost of entry to those new generations is expensive, and the more defenses you add, the more expensive it is to attack you. We know, because we're all technologists who've been around for a while, that the cost of entry to anything technological decreases over time. Once you get to this point, and you're all happy, just by doing nothing, the cost of entry to all those generations of attack tools has decreased, and everything is advanced, so by doing nothing, the tables have tipped away from your favor all over again.
Now you combine that with the fact that we are all working with the sole responsibility of inflating our company's value, which means that the company gets more valuable, which means that everything inside the company gets more valuable, and you get this pull back and forth that is wildly not in our favor. The cost versus value of everything is just constantly in flux, and always pulling away from where we want it to be. This is causing massive iteration on the attacker side. Increased sophistication of tools, marketplaces, services, everything that can plug together, in order to make sure this stays as cheap as possible. You get massive sophisticated attacks that cost very little to perform. Now that is a really crappy place for all of us to be in, and it's not getting better.
Security, I hope most of us understand, is not a binary thing. You don't hire a security team and all of a sudden become secure. You don't purchase a vendor, and they don't have a silver bullet that works until a silver bullet doesn't work, and then you move on to somebody else. All of these things are just a gradient on the friction that you are applying to an attacker, and friction is cost. We use those terms with user experience. Same terms can be used for the attack landscape.
Let's say you don't patch anything ever. What you've done is just make it trivially easy for script kiddies to attack you. You'll just take a scan of all the services you have, all the versions that are running. You look up all the known vulnerabilities for all those versions. You find all the known exploits for those vulnerabilities, and bam, you're done. Obviously, that's not where you want to be, but you can have something like policy of patching within three months. This is actually substantially better because it means that you are only vulnerable to the latest vulnerability, and only for a window of three months. Or you could patch on day zero, as soon as the vulnerability, and the subsequent patch are announced, you apply all those patches, and then you make it extremely painful, and expensive, for an attacker to attack you. They have to find their own vulnerabilities. They have to find their own zero days. That is a position that not many attackers can be in. That's a level of extreme sophistication that attackers need to be in. It's ok to not be there because it's really expensive. You just have to know that you're not there, and you have to understand the tradeoffs you're making on that gradient as you fluctuate up and down, and it's going to fluctuate up and down on its own, like we already went over. You need to constantly assess what those tradeoffs are and assess whether or not those are still appropriate tradeoffs for you to be making in your company.
There are also some threats that can't be patched away. This is the OWASP automated threats, and they look like they're prioritized because the numbers are all messed up. They're actually alphabetized by the attack, which is just strange; I copied this off the wiki. It's basically the stuff that an attacker can abuse that you have to keep open - things like account creation. You're never going to go to your product owner and be like, "I'm sorry, I don't think we should allow more accounts." No one's going to say, "Ok" to that. I mean, that would be a great way to completely eliminate account creation fraud, but that's not going to happen. You have to keep your account creation open, but attackers will abuse those and try to get anything they can out of these open endpoints in order to figure out what they can extract out of you.
Attack in Detail
We're going to go over a single attack in detail. I work a lot with credential stuffing. That is a very hot topic nowadays. Credential stuffing, for anyone who's not 100% up to date, is the automating replay of previously breached credentials across other sites, or services, in order to find out who's reusing passwords. A lot of people reuse passwords, and there are a lot of breaches. If I can get your passwords from the past 10 years, and just try them over and over again, hopefully not you, but somebody probably in this audience would get exploited because I am the first to acknowledge that I have not always been a security person. I've had some pretty poor hygiene in the past. I used to have three passwords.
There were three classes of passwords. The crappy password that you use across everything. Then, the somewhat ok password that you use for things that have your credit card in them, like Amazon or Best Buy, and then the really, really good password for like banks and email, and stuff like that. That's actually a really common password policy. That gets you screwed because these services will get breached at some point, and then when your password is out there, it can be used to exploit anything else.
Credential stuffing takes four steps. You got to get credentials somehow. You have to automate the login, because you're not going to sit through and type through hundreds of millions of emails and passwords by yourself. You have to defeat whatever existing defenses there are because there's inevitably something. Then, you need to distribute globally, or at least make it look as though your traffic is distributed globally.
Getting credentials, at one point in time, was actually somewhat difficult. You needed to know the right people, run in the right groups, pay a lot of money, or do the breaching yourself. Now, you can go to a site like RaidForums.com and download almost a terabyte of credentials for virtually nothing. This is the post that announced the Megaleak, collections one, two, three, four, and five, and the anti-public megadump. That was about 2.3 billion credentials unlocked for eight credits, which is about $2.50, which was $2.50 more than I had on this account, but that's ok, because it was just hiding a torrent link, and there were five other posts on the forum that had that same torrent link. You can get 2.3 billion credentials for literally nothing. These are breaches all the way back, as far as I can tell from anything, 2008-2009. I think the eLance breach was one of the first ones I recognized there. One of the more recent ones was CD Projekt Red. Anyone who played video games, play The Witcher, things like that? Those forums had been breached, and those were included in there as well - a whole range, a decade worth, of credentials.
If accessing publicly accessible shady websites is not your thing, then just go to Twitter. You can follow a bot like this, which is advertising dumps. You can follow this right now. This is a real screenshot. You can get daily updates of whatever combo lists are being advertised on the internet. Combo list is basically a text file with username and passwords, ready to be used as input to a tool. Credentials are no problem. You get those for basically nothing. High quality credentials are different, but let's not talk about those right now. Let's talk about the base level.
Next up, you got to automate the login. This is one such tool that you can use to automate logins. This is Fraud Fox. This is the ultimate solution to automating because it's a virtualized, by default, and set up to avoid, and bypass browser fingerprinting. Browser fingerprinting is basically IP rate limiting with browser data all mashed together. Because it's virtualized, once you get this all set up, you just plop it on to whatever virtualization cloud service you want to use, and you're ready to go.
Next up, you have to defeat the existing defenses, and there is inevitably something there. You probably have seen something like this at some point: Google's reCAPTCHA. This is Google's reCAPTCHA version two. Version one was the squiggly words. Version three is actually kind of a completely different product, but you get the swirly swirl and a green checkmark if you are ok. If Google doesn't think you are ok, maybe you're using Firefox, like some sort of weirdo, then it pops open a grid of pictures, and you have to answer some questions in order to make Google's machine learning systems all the better. You got to figure out what a crosswalk is, what a street sign is, things like that. Once you get through enough, Google eventually says, "All right, but use Chrome next time."
This is fantastic at detecting malicious automated traffic. I work at a company whose sole goal is to be better than this. Google reCAPTCHA is fantastic. The problem is everybody uses it. Now put a hacker hat on, and think like a hacker, think like an attacker. You have a neighborhood of 1,000 houses all with 1,000 unique really good locks. You have another neighborhood all with the same exact lock. As an attacker, are you going to bypass one lock that gets you one house, or one lock that gets you 1,000 houses? The answer is obvious there, and of course, when something like this is that obvious, it breeds a marketplace of solutions like this.
This is Death by CAPTCHA. This is one of dozens of CAPTCHA solvers. There are actually so many CAPTCHA solvers, that if you Google CAPTCHA solvers, Google's algorithms will find all the CAPTCHA solvers, and everything written about CAPTCHA solvers, and propagate the top 10 CAPTCHA solvers to its answer box. This is not hard to get to. You don't have to be some sort of shady hacker to get this stuff. This is a $1.39 for 1,000 solved CAPTCHAs - not CAPTCHA attempts, solved CAPTCHAs, or 99 cents if you're a gold member. This is already very cheap to get what you need, but if that's still expensive, then you can use something like this, XEvil. This is a free API list tool, that you can download, that will attempt to break CAPTCHAs. Its success rate is less than using a service like Death by CAPTCHA or 2CAPTCHA, but if you're strapped for cash, then this is better than nothing. If you have a 50% success rate, you know what you do? You just double the amount of traffic you're sending, and eventually you'll get where you need to be. This is what happens.
Next up, you need to distribute globally. Like I mentioned a little bit earlier, it's necessarily distributing the code globally. It's distributing where the traffic looks like it's coming from globally. This also used to be somewhat expensive. You had to figure out where to put your code across a bunch of machines, or get botnets, or get exploited Microsoft Windows XP machines. You have so many cloud service providers with the ability to just put your code anywhere across the globe whenever you want. If that's not enough, you have hundreds of thousands, if not millions, of free proxies that you can then funnel all the traffic to in order to make it look like your traffic is coming from somewhere other than a single point, because you can't make it look like it's coming from IP address, because thanks to firewalls a billion years ago, if you have 100,000 requests coming from one IP address, you're going to stick out like a sore thumb, and you're going to get swatted down very quickly. You have to distribute to make yourself look like you're more natural.
The cost of this attack right now, if you wanted to go home tonight and get started, is nothing for 2.3 billion credentials. You're all developers here. You could probably develop your own script, or configure your own tool, but if you're spending time, time is money. You might as well just spend some money and get something configured for you. There are marketplaces for that, you can probably pay about 50 bucks, depending on the service you want to attack. You just get that, you get started much more quickly.
We could use XEvil, but again, we're entrepreneurial. Why should we waste our time with a substandard success rate, when we can pay $139 and 100,000 solved CAPTCHAs. We want 100,000 because we want a substantial attack that gets us something. Then, we can get 1,000 global IPs for virtually nothing, for actually, I think, literally nothing, but if you spend a few bucks, then you can tailor the demographics a little bit more and have less likelihood of getting blocked. It's less than $200 for 100,000 account takeover attempts.
Now we have the cost. It's less than a quarter of a penny per request. What's the value? The value, obviously, I think you probably imagine, fluctuates depending on the service you're attacking. You can browse sites like this, dark web account marketplaces, in order to find out what accounts are going for. This is one of the more popular ones. You can search for Wells Fargo accounts, SunTrust accounts, Apple, Airbnb, Marriott, IKEA, Epic Games if you want some really sweet Fortnite skins.
The value of these accounts differs for the seller, but they all kind of normalize around some similar criteria. By this seller, Amazon.com accounts are priced based off of the last purchase price in that Amazon.com account. For an Amazon.com account that has the last purchase price of $613, sell for about $15. A Sephora.com account with over 4,000 loyalty points will sell for $22.60. If you have hundreds or thousands of these accounts, you're going to be making some money. This is also actually just selling the account, not even any of the downstream fraud that can occur once you own that account. Even if you're just doing you're just doing a [inaudible 00:24:33] attack just accounts, that has value in itself that you can just realize very quickly.
We have values ranging between a couple of dollars is what I've seen, up to about $150. Smaller amounts for less valuable services, game accounts that have few skins in them. High amounts for services that allow you to transfer money because that helps in money laundering. You've got a success rate, from what we've seen, between about .2 and 2%, which is variable depending on the quality of the credentials that you got, but .2 and 2% is generally the number that we repeat, and a cost per attempt is less than a quarter of a penny.
We're looking at a return, at the low end, of 100%, and at the high end, of about 150,000%. You don't need to be Warren Buffet to know whether or not this is a good deal. This is where we are right now, and we are on the wrong side of this. We should all be attackers. We are not making enough money to be protecting against these people. This is fueling massive iteration and evolution because there's so much money there.
Remember when I was talking about the cost of entry? In this specific case, cost of entry and the generations of attacks are different for the attacks. In credential stuffing, it's basically new tools that are created that make it easier to get past existing defenses. This is SentryMBA. This is a very old one. This is a basic tool that does basic HTTP requests, but it's optimized for the credential stuffing use case. It takes in combo lists, it rotates through proxies, it does a lot of things that you just don't want to do, or you would have to do yourself if you're using something Curl or W Get. Then, as soon as these things got blocked, then you would get tools like Browser AntiDetect, which is a Chrome and Firefox plugin that allows you to randomize the fingerprints. So when you have something that's trying to look at your fingerprint in order to see the similarities in traffic, you can just randomize it, and bypass all that completely. Then, you keep on going from there. You've got fingerprint marketplaces now that you can purchase hundreds of thousands of fingerprints, and use legitimate fingerprints through a fingerprint switcher to go through that process. Randomizing is not enough now. You have to actually have legitimate looking fingerprints. If you're on iOS or something, you should be reporting that you have iOS-y like things. Rather than randomizing that yourself, just get somebody else's iOS fingerprint.
As the human emulator in the middle, which specializes in actually making traffic look like it is being manipulated by a human. All of these tools are trying to drive closer and closer to imitating real human behavior. From their demographics, from their traffic origins, from their behavior, from the clients they're using, everything. If you were here earlier from one of the talks, talking about the Illuminati network and the Hola VPN, that's a way to basically outsource the usage of residential IP addresses to a legitimate company. If you want to look like you're coming from an actual home, you can just do that as well by proxying through those channels.
How to Affect Cost
How to affect cost? There's not exactly a silver bullet at the end of this, and I apologize, but we'll go through some examples. There's millions and millions of spooky marketing dollars talking about bots, and botnets, and super shady tools, and things like that, but those are just the symptoms. Everything that we are able to see on our servers, on our network, are just the symptoms of something else. If you treat the symptoms, you're not going to be affecting the source of those symptoms. You need to target the person, or the group, behind those attacks in order to have any chance of getting ahead.
It's not as simple as just blocking an IP address, or a bot, or a tool, or a botnet, or anything like that. You actually have to target what is going to cost the attacker the most to change over, and over again. It might be the tool for novice attackers. They might not be skilled enough to iterate towards other tools quickly, so they're just move to softer targets. For other attackers, it might be the services they use. It might be going so far as damaging their reputation on the dark web, which ends up being kind of a fun little game because you're trying to reverse search where all this is coming from, and looking for clues in order to figure out how you can properly damage this person enough so that it is just too expensive to continue attacking you.
What we do, and what I have found particularly effective, is by focusing on sabotaging the software development lifecycle of an attacker. The software development lifecycle looks just like our software development lifecycles. You have phases that progress, and they start with something like planning, or gathering requirements. For an attacker, it's what are you trying to attack? What URLs do you need to hit? What data do you need? What services do you need to integrate with? What is your path to value? They go through, they probably have scrum masters, I don't know, but it looks very similar to what we go through.
Then, you go through the development phase. Development is exactly what you would think it would be. Now think about how you develop. When you are creating a web application, a rest API, or something like that, you invest in a framework, maybe Spring or something like that. If there are Node people here, maybe you invest in Coho or Express. You're investing in a platform, and I want you to keep that in mind. There's a lot of work being done here in order to get to the end.
For an attacker, it might be investing a tool. Maybe Chrome, or SentryMBA, or something along those lines, and you go through testing. These are scripts that need to be running on their own for days, weeks, or even months. You don't want to babysit them. You want to make sure they're actually working, so you go through the testing phase.
Integration is the last phase before release. This is where you make sure everything's working properly, making sure edge cases are handling, making sure that your credit is topped up in the APIs you're using. The final stage here is the release, which we all know, because that is the only thing people care about in our companies. That's what they're all looking for, and for an attacker, it's the same. That's the attack.
Why is this important? Because these first four stages are pure cost incurring stages. There is no value realized in those first four stages. We all know that really well. You have product managers and executives breathing down your neck, waiting for that next release, because that's the only thing they care about, because that's where value is realized. The same thing is true on the attacker side.
Think about back when I was mentioning your commitment to a framework. If you have, let's say, a silver bullet against Headless Chrome, if you deploy this, you will never ever be bothered by Headless Chrome, or anything that uses Headless Chrome every again. If you have that deployed all the time, all you've done is tell the attacker at the planning phase, "Don't worry about Headless Chrome." You have saved the attacker time and money, which is the last thing you want to be doing. What would be more valuable is for you to be detecting this, of course, but to have nothing mitigating. You have the attacker going through the process of developing everything they need to develop. Then, as soon as they get to the release phase, you squash them there. Not with your silver bullet, with something, anything that would work, because your goal is to just keep on directing them to the first four stages over and over again.
Now think about how infuriating that would be to, as a developer, because you're spinning cycles. Also think about the success rate I was talking about with some of these attacks - credential stuffing, or whatever else. They're not 100% successful. You can let some of them through, and that's what you want to do. You want to let just enough through that they think they're on to something. Maybe you block them with something simple, and they go back like, "I should have accounted for that." They go through the whole process again. You squash them again, and you keep on squashing them with your bag of tricks until they're gone, or you have to use a silver bullet, and they move onto something else. Then, you go through the process all over again. This is how you can deter attacks and push them off to softer targets.
Real World Example
I know, this is all kind of fuzzy and hard to understand, so I'll give you a real world example of something that we actually did in 2015. The scenario is, we got a Credential Stuffer, and an Account taker-overer, and a big US retailer, basically, a marketplace online. The problem here is that we had an attacker who was very sophisticated. For Fortune 500 retailers, you can imagine very high value targets. If you have a specific goal to extract value from that, you're not going to go away. There are multiple tiers of attackers. Tier one, you got script kiddies - you knock them over relatively easy, you don't worry about them again. You have experienced attackers who can iterate a little bit more. Then, you get the advanced tool developers, people developing their own things. Then, you have the people who are damn well determined to get what they want to get out of your service, and those are the ones that cause the most frustration. That's eventually what companies get to until they get rid of them.
This guy had been attacking and retooling for months, and would not go away. What we did is, we had an ability to send targeted custom payloads to individual attackers. This is something we had developed, but we hadn't yet used because no one had gotten to the point where that was necessary. We deployed a targeted custom JavaScript bundle to this particular attacker, which then ran our code on his machine, which is kind of like tipping the tables. This allowed us to inspect the API, as he or she was overwriting, in order to see what the code was that he or she was using. We got this code delivered back up to us in real-time, so we could see everything the attacker was doing in real-time, in the browser. Console logs, comments, typos, everything.
Now think about things like comments and console logs. When you enter them in your code, you don't expect behavior to change. There shouldn't be any reason why behavior would change when you add a comment. What this enabled us to do, because we were observing this, and we had this data coming back to us, we could make decisions based off of the content of this code. We would do things like, when we saw it, and when he was going through a retooling process, everything would work, but as soon as a comment was added, or subtracted, or a console log was added, things would break in weird ways.
If that happened in your code, what would you expect? It's clearly because of a log statement or comment. Why would that possibly be the case? Maybe in a log statement, maybe there's some sort weird getter on the object that you're outputting, and then you go down that route. Maybe the console log method is instrumented, and you need to figure out what's going on there. This is what we were trying to do. We were trying to drive the attacker down a path that was not fruitful. After just a few days of doing this, we have never seen that attacker again. We professionally piss people off at our company.
What we did after this is, we built up defenses based on the tool that was being used. Because there were some typos in that code, we could do a Google search. When you're Google searching typos, you get the results you're looking for really well. We were able to find the source code that this tool was based off of, and then with the pieces that we were getting from the browser side, able to piece together what he or she had changed. We were able to build up more defenses around that, and we're going to make things more resilient. Then, we started productionalizing some of the variable feedback. Then, we were making it easier to turn things on and off, be more dynamic on our side, and then generalizing everything so that it could be repeated over and over again.
How much does it cost to attack you? I can't answer that, but I can at least tell you how to go about learning that. First off, you got to address all the low hanging fruit. If you have versions that are vulnerable, or ports that are open, or anything that is easy to exploit, take care of that. If you don't, your cost is pretty low, and you don't need to do anything else. After you've taken care of that, hack yourself. For the problems that are plaguing you, or the problems that you're most worried about, figure out what it takes to attack you, especially when it comes to credential stuffing and automated stuff. You got a bunch of web developers in your company and QA testers. Figure out how hard it is to actually do this. If it's very easy, and they don't have to do anything, then the cost you've already seen is virtually nothing. You need to figure out how to up those costs. Then repeat, because like I said, all of this is constantly in flux, and by doing nothing, everything is tipping away from our favor just naturally.
See more presentations with transcripts
