Speed, scale & stealth: Securing against ATO events

So let me introduce Frank Walsh. He's the Field CTO for Human. He's going to talk to us about speed, scale, stealth and securing against ATO events. Frank?

Oh yes, thank you, appreciate being here today. Sorry if we're running a little late today.

First, we're going to talk a little bit about the economics of cybercrime and why attackers are incentivized to attack your applications. What's at stake? These are just some interesting figures - what an attack is worth to an attacker in general, on average, whether it be a bank account or a social media account or an email account.

Attackers are looking to scale their abuse and achieve success in compromising many accounts, creating many fake accounts, performing transaction fraud at high volume using transaction interfaces, not to place transactions, but instead to test credit card numbers to identify those that work that they could sell to other cyber criminals.

So, a very sophisticated underground marketplace exists where attackers have basically found ways to monetize stages in an attack life cycle and support each other in those stages. Account takeovers over the last year continue to be on the rise. Certainly we offer services to application users that are unauthenticated, but a lot of the most valuable capabilities that our applications offer are behind login. So of course, attackers are focusing very much on identifying stolen credentials.

I've been in the space for close to 20 years and I can tell you a lot of my relatives, family, close family often are reusing the same passwords. And there's even tools out there that actually facilitate determining if an account has access to a certain service. A lot of times password reset or forgot account user name interfaces are used by attackers to actually test and see if an account exists before they actually go and attempt to break into that account via stolen credentials or credentials they got from a dump.

And the attack life cycle is complicated. I talked a little bit about how attackers prepare, how they test your application interfaces, how they implement tools to support scaling their abuse and then finally their end game - exploitation and exultation of your application interfaces.

So attackers, just the same way we think about our businesses and build processes and systems to support our business, they build processes and systems to support their attack life cycles and even to support one another or monetize stages of an attack. They're really good at like creating a bunch of fake accounts.

The speed and scale - the scale of the speed of security events has certainly grown. So we're seeing more and more security events. Often people will struggle with the concept of alert fatigue, looking for a variety of ways in which they identify attacks in a SIM or on CloudWatch for example. And often this becomes a game of whack-a-mole where you block an IP and all of a sudden an attacker shows up on another IP or you cancel or flag a compromised or abusive account and all of a sudden attackers end up on other accounts, right?

So really the speed of these security events, how frequently they're happening, and the scale of these security events is growing undeniably. And finally, a lot of security events go undetected. An attacker's end game is to hide within the noise or beneath any triggers that you have that would identify abuse in progress.

How do they do this? They spread out across a number of IPs, they spread out across a number of accounts. So they're often creating fake accounts as a precursor to using those accounts to stay beneath the security event thresholds or the anomalies that you would use to identify a specific account as compromised or a specific account as doing more than it should be.

So the focus here to defeat attackers really, it involves increasing the speed of your response, being able not to simply rely on log analysis, no longer play games of whack-a-mole blocking IPs or identifying compromised accounts and closing them or challenging users - really to shorten the life cycle of an attack from days and hours to seconds.

And this really takes away the power that an attacker has as they use these accounts at scale or as they create automation that orchestrates activities across pools of accounts or pools of IPs.

There's a lot of tools out there. Bright Data being one that's a place where you can go and lease access to hundreds, if not thousands or millions of IPs. It's pretty interesting. What happens is services will actually reach out to companies that make free apps that you download to your phone and they'll say, hey, we'll help you monetize that app. If you embed this small SDK into your app, what that SDK does is it turns that app and that phone into a proxy that can facilitate traffic on behalf of anyone who pays for access to that proxy.

So increasing the speed of your response, increasing the scale of your response, enacting automation against attackers to impede their automation, their ability to stay beneath these thresholds, to spread out their attack across thousands of IPs or thousands of accounts, is really the only path forward.

Really, honestly, the playing whack-a-mole searching for immutable aspects of an attack - a bad user agent, a bad IP, a bad account, a bad credit card number, a bad shipping address - is a never ending game. And especially when you're doing it manually, especially where you're surfacing these insights and then delivering them to a fraud and abuse team or uploading them into your SIEM or like trying to basically keep ahead of attackers who are operating 24/7/365 across every time zone and who are putting automation tools that are often used by defenders or even developers in testing apps to use to abuse apps.

How many of you have used Selenium or PhantomJS? These are great tools for developers to test their apps as they build them to identify, you know, what's working, what doesn't work to automate the QA process so that you can have a tighter and a more effective release cycle. Attackers look at those tools as tools that they can use to script activities against your application interfaces. So they're using the same tools, but they're using them for completely different purposes.

And that's just the start of it. Often attackers will even monetize attack tool kits like OpenBullet for example. And they'll build that they sell to others who have interest in compromising accounts or using checkout interfaces or taking an API that services your app and using it for some other purpose.

A lot of apps these days do geocoding, right? Converting addresses to GPS or a GPS coordinate that they get from a browser back to an address when you are presenting nearby stores for example. Attackers look at those same interfaces and they say, hey, look, here's a geocoding interface I don't have to pay for. Maybe if I tie into it and then I sell it to others, I can basically offer a service I don't have to pay for.

So there's a lot of really dangerous things that attackers can do when they have access to your applications. And the fastest you can respond is the review of security incidents and the manual implementation of security rule sets at the WAF or fraud rules that are implemented at the account level.

So really your goal is to keep unauthorized users unaware of your response rather to be able to react so quickly that an attacker isn't quite sure why their attack is no longer working or didn't work and they move on to some other application landscape.

So really, this is a game of activating defenses that can operate 24/7/365, can self improve, can confirm human. We like to say at Human, the idea of real human, right? Human first - making sure the person on the other end of the line is in fact a human being. And secondly, making sure that that human has good intent - that they're planning to use your application in a way you'd expect and want your application to be used.

So that's the goals of the Human Defense Platform. Types of problems we're helping customers solve span from overall abuse all the way to abuse that occurs against advertising spends or advertising that may even be delivered through ads that you embed into your site. But across the board, what I can promise you is if you have an application interface, it's only a matter of time before an attacker is looking at that application interface and saying, what can I do to make money using this?

Often they don't even know why they're creating fake accounts, they create a bunch of fake accounts, then they advertise them for someone else who eventually finds some way they plan to use them.

So how can we help? We can help you look at ways you could stop account takeovers, you could stay ahead of unauthorized or abusive users. You respond quickly in real time using a system that learns and adapts faster than an attacker can type, right? Or use automation tool kits.

We integrate very quickly, a lot of powerful ways we can integrate directly with AWS CloudFront, Lambda being a couple, we've got integration packages that work for all different AWS services that you might implement at the edge or within the fabric of your applications architecture. And the end goal is to reduce the amount of time you spent managing and reacting to security events, right? So keep you focused on what your application was designed to do, what its purpose is, not focused on defending your application functions that you want real users to use instead focusing on building out those application features and functions.

So we're located right over there. If you follow the sign 1200 back to our virtual bookstore, we were founded by a couple of folks in New York that in the back of a science fiction bookshop. One of our founders, Dan Kaminsky is very famous for having discovered one of the biggest vulnerabilities in DNS years ago. A lot of deep roots with the world of Defcon and advanced sophisticated defenders and hackers.

So I'm proud to say we have a booth here today and we'd love to find ways to help you all think about how better to defend your apps and make sure they're being used by the real and right humans.

So, thank you for your time today. I hope you all have a great AWS re:Invent.

Thank you, Frank. Appreciate it.