Application Hardening in Your DevSecOps Practice | DevOps Connect: DevSecOps 2023

Hi, I'm Dan sru. I'm the cybersecurity evangelist at Digital ai, and I thank you for coming and excited to talk to you today about how to ignite your DevSecOps practice with application hardening. Let's jump right in.

So the problem as we see it, and as likely you see it, is that the applications you create are under attack. More than half of the apps that are in production or that you've deployed, um, or our customers have deployed, have been tampered with in some way. And by that I mean they were either run in an unsafe environment such as a debugger, an emulator, or even a jailbroken or rooted device, or they've been run with modified code.

And we know this because we're monitoring, uh, the apps that our customers make. And over the course of four weeks, in October of last year, 2022, we found the 55% of those we monitored were run at least once in a debugger or with modified code. So what to do, well, simply put, what, what you need to do is, or what we all need to do is we need to build secure software, meaning we need to make applications that are secure from the inside out.

Um, specifically we need to protect the applications, whether they're mobile, web, or desktop, regardless of the language that they're written in. Um, and we need to do that, first of all, first of all, by obfuscating the code such that when it's reverse engineered, it's difficult to read. And then second, we need to have some sort of mechanism by which we can monitor the apps that we put out into the wild.

Um, so in other words, the custom apps that, uh, fin financial services companies or gaming companies, or even manufacturing companies like a car manufacturer, for example, put out into their consumer's hands, need to have some mechanism by which they can be monitored so that when the company that makes them put some out there, they can tell whether or not they're under attack. Um, they can also tell when that app has been put into some sort of unsafe environment, and ideally they can see where the threats to the apps are coming from. So where are the apps when they're attacked?

And then finally, ideally, every app needs to have the ability to react to an attack by doing some sort of, by taking some sort of action, such as forcing step up authentication, deprecating the features in the app, or even if it's something serious, just shutting down the app. Um, and then, you know, as I said, these, uh, security measures need to be built into the application from the inside out. And by that I mean the security mechanism has to be added into the app at the build stage in the app.

So let's talk about what types of protections are needed. So the first is, you know, once the app gets put out into the wild, there's no controlling what environment the app is put in. It's outside of your company's firewall.

Um, it's, you know, in the app store or the, uh, the play store, which means that it's, uh, anybody can do anything with it. I mean, once they have the app, I mean, there are some controls in the case of iOS where the app itself can't get into the, um, place, uh, the, the iOS or the app store rather. And likewise with the Android, the Play Store.

Uh, but once the app is downloaded, it can be put into an emulator, it can be put into a debugger, it can be reverse engineered, which means that anyone, whether it's just a curious user, um, or consumer or a threat actor, can disassemble the code and look at it and figure out what the code is doing. And that in turn means that the threat actor potentially could figure out where the instructions for accessing your company's backend server. Like, in other words, where the information that the app needs to get to in order to function correctly, where it's stored, and how it gets through the other protections that you have in place, whether those are authentication measures.

Um, you know, everybody has some sort of web app firewall or a network firewall. Um, and even in some cases, you know how to evade your intrusion detection, uh, mechanisms. So if those, um, instructions are exposed, your backend is potentially exposed to the threat actor.

ai is a, is a sponsoring member. They're saying, you know, if you put in an app out into the wild, you need to do something to obfuscate the code. And so that, that's what we recommend as well.

Uh, it's not, uh, it's not necessarily revolutionary, um, but surprisingly not everybody is doing it. The next thing you need to do is you need to provide some sort of mechanism that, uh, it, um, is able to detect when or if an application is put into, uh, an environment that allows it to be tampered with. Um, perhaps the most powerful of these is is Frida, which is a freely available, um, dynamic instrumentation toolkit.

And your app needs to be able to tell when it's running in Frida. And then, you know, as, as we talked about earlier, needs to have some way of shutting down when and if that happens. Now, ideally the app has, uh, several different mechanisms to detect when it's in an emulator.

So if and when the threat actor finds out about one and they, uh, neutralize it in some way, you have something else to fall back on. And so you're operating a sort of defense in depth within the app that you create. Um, the next thing that you need to do is ideally, and again, this is according to owas, the organization, organization of application security professionals, you need to provide some means of protection above and beyond the normal, um, say secure socket layer, um, or cryptography that's encrypting your communications.

And you can do that, uh, for instance with something called some form of white box cryptography, something that will protect the keys, um, the the private key that, that you store in order to, um, encrypt the data or the communications coming to and from the app, uh, or the data itself that's stored in the app. You need some form of, uh, uh, cryptography that goes beyond the standard, um, s S L, uh, to protect your most sensitive data or the keys, which essentially protect everything that the app is, um, communicating to and from itself. So those are the things that one needs to do.

Um, there are plenty of examples, um, for, in the case of digital ai, more than half of the global 2000 companies are using, uh, digital AI products. And I'm just giving one example from, uh, one of our customers that happens to be in the gaming industry. And I'm using the gaming industry because, um, sometimes surprisingly to some of our prospects and customers who aren't in gaming, we've found that gaming companies are attacked just as often as financial services companies.

And that's, uh, for a couple of reasons. One is, you know, there's money to be made in cheats for games. The, the cheats themselves can be sold, uh, on the dark web.

The other is that there's the people that tend to game, um, well, 2, 2, 2, 2 sort of salient facts about gamers. One is they tend to be technically astute, so they may have the wherewithal to try to, um, crack an application. And two is they have a personal incentive to do that because they take gaming very seriously and they want to do well or enter what, what they would call God mode, um, by developing some sort of a cheat.

So we see all kinds of attacks, um, you know, sort of low flying frequent attacks or almost like spray attacks on the gaming apps that we protect, as well as advanced persistent threats against apps. Um, at the level, nearly at the level of, you might see from, you know, a nation state attack and in some cases you are, we are seeing nation states actually attack games if they happen to be a particularly famous title. Um, at any rate, so, so we, we have, we, we have this experience of protecting games.

Um, and in this case, this is one of the biggest desktop games that is out there protecting the name of the company because we don't want to attract undue attention from crackers. Um, but in this particular case, they had an incident before they contacted us where some of the financial data, um, from their, uh, customers was exposed briefly. Um, and it was partially because they didn't have a white box cryptography, uh, solution in place.

So they wanted to get the white box cryptography. And in addition to that, they wanted to find, they wanted to obfuscate, um, the code and the application, and they wanted to provide a means to monitor when and if the application was, was under attack. So what they did was, uh, they implemented this in-app protection at the build stage.

They added what, what we would call, um, a protection blueprint or a guard spec to their host build pretest pre-release pre-deployment app. Um, they brought that protection blueprint along with the compiled code, um, in order to create a new, um, executable that was once disassembled, um, much more difficult, if not impossible, for the crackers or the hackers to read. Now they did this for a, a desktop application, so a, a big, uh, you know, a large application, large footprint.

Um, and they found that, you know, once they added the code, depending on the protection code, that is once there's some, in some cases there's some forms of, or some level of a performance hit. Um, so what they did was they, you know, applied every protection that they could just to see, okay, what's the delta? Um, see if whether or not that was, um, acceptable from a, uh, consumer experience point of view, and then figured out, okay, so if we have, you know, delta of X, how can we shrink that down by only writing protections for the most critical parts of the code?

And by doing that, they were able to reduce the, um, added footprint to the point where there was no perceivable difference from the consumer point of view in, uh, in terms of the, um, performance of the app. So they able to do that while protecting the code such that when it's disassembled, it was hard to read while protecting the keys and the data using white box cryptography. Um, and while adding the ability to actually add custom, a custom action when and if some sort of cheating was detected, cuz we're not gonna stop people from trying to cheat, we're just trying to make it, we're going to make it harder for them to be successful at cheating.

Um, and in this particular case, the, uh, the, the deprecation of feature that they added, in fact I've always found sort of amusing, is they turned off the gravity control when and if they detected that someone was cheating. In other words, that player's, uh, I'm sorry that, um, yeah, that gamers players, this is a, a sports game sports franchise that gamer's players just floated off the field when or if, uh, he or she tried to cheat, uh, which I thought was a pretty fun way to deal with this very real problem. Um, at any rate, it was a successful protection.

The game that they protected, you know, went out into the wild into the marketplace and was successfully protected for over a year until such time as they put out the next version. And when they put out that next version, they were able to just scramble the guards, um, or the protections such that the new game had a completely new, um, protection blueprint that made it, um, made all of the people who are trying to test or crack the application have to start over again. And in so doing the revenue for this particular game grew to 7 billion and over 500 million accounts.

So these are very sophisticated protections. Um, so I wanted to just tell that story, you know, real world, these are real customers who are really doing this. Um, and then just give a couple of points that I've sort of touched on through this, uh, very brief presentation.

ai, but there are other ones out there. And maybe most importantly is that you just use something to protect the app that you put out into the wild. And when you do that, you know, one of the things that you wanna look for is, uh, a solution that can protect all types of apps.

You know, not just mobile, not just web, um, but if, especially if you're putting out an app that's available, you know, if you're a bank and you're putting out an app that's available through a browser and mobile, you wanna be able to protect both cuz you don't wanna give away clues in either one of the two. Um, you also wanna provide visibility into attacks and then meaning, you know, the ability to monitor. And then finally, you wanna be able to go beyond the basic obfuscation techniques.

And by that I mean, you know, there are, um, sort of simple techniques you can use like control flow flattening, and then there are others that are more sophisticated and that we don't advertise so that our, you know, the people trying to crack us don't know about them, but that we can tell you about in a one-on-one conversation. Um, so you just wanna make sure that whichever vendor you choose is able to do, uh, the more advanced ob obfuscation techniques. Um, and by the way, and it's just, just a sort of a plug, digital AI and aam, which is the company that digital do AI bought, was the original holder of the rights to the original patent on office.

Um, and we have, um, over the years developed five others very, very briefly. ai? Digital Do AI is an amalgamation of five different companies, one of which was aan, the, the security company that I mentioned.

Um, we have over 50% of the Fortune 500, uh, customers, a billion dollars in PE investment, 50 combined years of experience, and 140 global partners. And with that, just wanna thank everybody for listening. com/in/de.

Thanks very much.