Appdome: Streamline Cloud Testing of Cybersecurity Features in Mobile Apps

Video Transcript

0:00 | Karen Hsu
Hi, my name is Karen and thank you for joining today’s. Session on streamlining cloud testing of secured mobile apps. A little background on me. I’ve been testing apps for over 30 years. I started testing apps when I was working at an enterprise application integration company. So I was testing a lot of ERP and CRM apps and the combinations of them. And I’ve been at AppDome for About three and a half years. I started a fraud detection company years ago and found the importance of fraud prevention. That’s why we became part of AppDome and have been here working on securing mobile apps and now ensuring The testing of them, the task automation of them. So today we’ll discuss a number of things. The first is we’ll start off with definitions, What is security testing versus testing apps with security? Then we’ll go into the challenges of each, how to streamline the testing of apps with security. We’ll talk about that. And then what’s the benefits of, what are the benefits of doing that? We’ll go through a case study demo, and then finally end up with the community and what we’d like to work with you on. So to start off with what are the definitions, What is security testing versus testing of security features? So security testing is about detecting vulnerabilities in an app, identifying what the weaknesses are in the code or in the configuration. And there are a lot of companies that do this kind of testing For mobile app security specifically, they’ll be called MAST or mobile app security testing vendors. You’ll also hear about SAST and DAST vendors. So companies that do static application security testing or dynamic… application security testing. And that is vastly different than testing secured apps or validating that the app is functioning as expected after security has been added to the app, and that the app works across thousands of mobile app devices and OS versions. So security testing versus testing apps are different and they also have different challenges testing. But in terms of security testing, there are a number of organizations like OWASP and others that you see at the top here, NIST and other organizations that provide standards for security testing. And they provide guides such as you see here like the mobile application security testing guide that help testers and organizations understand what their security standards are, and what testing is required. Now, for example testing, There are a number of items that these organizations propose we need to follow or companies need to… follow in order to securely test and secure their apps. And as an example, one of the areas is for network security. And in this case, we’re highlighting is one of the items is for the app to secure all network traffic according to the current best practices. So these organizations will outline what the specific best practices are, for example, ensuring data privacy and integrity of any follow Data in transit is critical for an app that communicates over the network and that you can do that by encrypting the data or authenticating the remote endpoint. So using these standards, organizations will often do an assessment or security test where they’re identifying all the weaknesses or vulnerabilities in the app. This is an example of an assessment that AppDome does for customers when asked and for free. And this is something where we identify the risks within the app and provide a risk profile. Now, the challenge with security testing in DevOps, and this is traditional vendors who offer security testing. And then the customers that they work with will come to a conundrum, They’ll come to a fork in the road where after they’ve detected the vulnerabilities, so basically, they’ve identified a bunch of issues. And now the developers have a choice to make, Do they go and refactor the code and make the fixes and changes that could take weeks or longer? Or do they waiver the issues away and allow them to proceed with the release on time? But then have apps that are in production that are at much higher risk and at much higher risk of attack. So this challenge here not only is in the early part of the process where the initial build is made and the security testing is done on that initial build. It also happens later on when there’s retesting of the app or the app is out in the wild and there are issues that are found there. So what AppDome is proposing is a different process and that is to really address the building of protections in early and automating those protections in so that the developers don’t have to code, they don’t have to make those fixes manually. And they have an automated process for making those fixes. Now, the challenges with testing secured apps is that there are many different combinations of secured apps. So once you have say built those protections in an automated way using AppDome. The challenge is now, how do you test that those protections are in there? And the app still functions as expected? The challenge is now for the tester, many different combinations of OSs and devices and all the different features that are in the apps and testing those different combinations. And so let’s go into these challenges a bit more. Those challenges include the fact that the methods that testers use often violate security policies. So these methods include using emulators. Virtualization and other services. These are the same services and tools that hackers use and therefore will trigger active security features in the app. Now, the other issue is friction in testing, slows down releases because the handoffs from one environment to another. For example, organizations will have one environment for testing unprotected builds versus another one for testing protected builds. So handing off between those environments can cause friction. And finally, the last challenge here that we’re talking about is integrating with the DevOps pipeline In order to automate cloud testing into CI CD workflows and into the DevOps flow organizations need to have or the systems need to have compatibility with those CI CD workflows and all the CI CD systems. So let’s go into the methods that could violate security policies. So on the left hand side are common tools that are used in automated testing services. On the right hand side are ways that these same tools are misused by hackers. So let’s start with emulators. So emulators are often used… in testing to simulate different device environments, allowing for extensive application testing without the need for physical devices. Now, on the other hand, hackers will use emulators to analyze and exploit app vulnerabilities in an environment without risking actual devices. Testers will also use virtualization, which enables them to run multiple instances of mobile OS environments, to facilitate parallel for testing across different configurations. Unfortunately hackers use the same or virtualized environments to obscure what they’re doing, test malware or reverse engineer apps without detection. Testers will use debugging to do real time monitoring, examine code execution, to identify and fix bugs in the testing phase. Unfortunately hackers will use debugging tools to understand how the app works, identify weak points and craft, exploits, Testers will use resigning which involves signing the app with a different certificate to allow modifications or insertions of testing frameworks. But hackers will use resigning with fraudulent certificates to inject malicious code or distribute counterfeit versions. Testers will use dual spaces to allow for running two instances of the same app simultaneously for testing different scenarios or versions. But hackers will exploit dual spaces to run and modify apps in a sandbox environment and allowing them to bypass detection. And finally testers will use Frida for modifying app behavior especially for testing vulnerabilities and this is at runtime. Whereas hackers will use Frida to inject malicious scripts, bypass security checks, or manipulate app functionality. So what we’re trying to share is… a number of examples of where testers will be using tools for legitimate purposes, which is for test automation or for testing, But hackers will use the same types of tools if not the same tools themselves to exploit app vulnerabilities and to compromise mobile apps. So we want to address is a new approach. And that is with AppDome, you can not only streamline the security testing and remediation because you have automated remediation, but you can also streamline the test automation of secured apps. So that is possible because AppDome as plugins or integrations with each and every one of the CI CD systems… that you see at the top here, whether it’s GitHub, Jenkins, GitLab, Azure, DevOps. We have a plugin so that your organization can plug into the DevOps pipeline for automation for remediation and for testing automation. And with the same concept of plugins. Appdome has an integration with Kobiton so that after the remediation is done, after the security protections have been automatically added to the app, Kobiton can be used to run the automation for the testing of the secured app. And we’ll show you how this works. So to go back to Bitrise as an example, Bitrise is one of the mobile specific CI CD platforms. And here is a workflow. As part of that workflow, what you would do is set the fusion set ID, which is basically the configuration for a specific security rule, set, a specific set of protections that need to be added to the app. So you can automate that as a step in this process. You know, where you first would build the Android app, and then you would add the protections with AppDome. And then you would execute the automation test with Kobiton before then deploying to your end users. So how does this work? How does this process of securing or automating the secure, the testing of secured apps work? Well, that works because AppDome has developed a trust model where we are able to recognize when the mobile app testing suite Kobiton is in use and allow the automated testing through Kobiton for example, without interruption. And this means AppDome also has service logs for all security events triggered so that developers can track and monitor all the mobile app defenses in every part of the release cycle. And finally, AppDome allows you to visualize that this testing is working through is a threat scope which allows you to see these events. So the benefits of streamlining testing of secured apps include first of all faster on time releases. So having fully automated testing of secured apps includes testing for all devices, OS versions. In every release, You’re able to also reduce friction in the DevOps pipeline because you’re able to eliminate the need to test? Protected and unprotected protected builds separately and not have to have different environments for protected and unprotected builds and their testing. You’re able to automate that integration into the CICD. You’re also able to visualize the test data and continuously protect and automate throughout the development lifecycle. Because AppDome ensures that security measures comply with the industry standards and regulations like GDPR, HIPAA, and others. And finally, with this new approach, in this methodology, you’re able to scale and evolve. So they’re testing scales with the apps in your organization as it grows, accommodating new security features and testing without changes to your workflow. So let’s talk about a case study. Appdome has worked with FIS, and this is where FIS uses the AppDome platform to automate testing. So to automate first remediation and add protections to the app in an automated way, And then second automate the testing of those secured apps. And we do this all or FIS does this all in the Bitrise DevOps pipeline And they do this for their credit union and banking customers. If you don’t know who FIS is, FIS, processes trillions of dollars worth of payments annually. Part of that comes through their mobile apps. And AppDome secures those mobile apps without coding or SDKs. And this is really important because it enables FIS to protect all their apps from reverse engineering and tampering, without having to have a separate engineering team or a separate security and DevOps team to handle all of the features that need to be added, all the security features that need to be added to the app… And all the testing that is required to make sure the app still functionally works after the security features have been added. Now, why this problem or this challenge come about of needing to automate security and automate the testing of secured apps. Well, it started because as FIS shifted left, it found it created many tasks for engineering that engineers simply could not handle. There were a lot of issues in the backlog that the engineers could not address. Fis, knew that they had a lot of challenges to address in the marketplace in terms of risk, especially given the increasing fraud risk, and the increasing technology advancements, especially around AI, where hackers are able to create malware create attacks faster and more sophisticated than they were before… They needed to have a way to defend the app without having to be a burden on development And with the AppDome solution and this ability to automate testing, FIS has continuous detection, defense and control, and allows them to not only have a continuous record of mobile app security, but also monitor offenses and threats. In the future impacting mobile apps and enable them to prioritize and respond To new attacks and threats in a timely manner. So what I’m going to do now is show you a demonstration. What I’ll focus on is the parts after the build has been created and after the security testing has been done, we’ll add the protections in and we’ll build a version of the app for testing specifically so that you can test in say, Kobiton or other systems. And so as a… reminder, what would usually happen is there’s some kind of security assessment or security test that is performed, and that would identify a number of issues, For example API keys or secrets in the clear or secrets that need to be protected. That’s one issue. Another issue is there are insecure connections in the app and, And those connections need to be secured or blocked if they’re insecure. So this goes back to the standard where you will have the objective of securing all network traffic according to the current best practices In an app dome. One way that we do that is to block non SSL connections, for example, in Android apps, This is one of the ways that we handle that issue. And so I’m just going to go ahead and show you how that works. So, oops, switching gears a bit, Here is the app dome platform. And what you can see on the left hand side are the apps. And so what customers will do is or what companies will do is load their apps And you’ll see them loaded on the left hand side, whether they’re iOS or Android apps. And Then on the right hand side, you can select one of these apps to then build in the protections. And so going back to our example of let’s say there are secrets that need to be protected that are in the app, API keys that need to be protected. Then you would simply click on data at rest encryption. And this is where then you would click on encrypt in app preferences, encrypting strings and resources, And that would ensure that data, those API keys or the secrets are protected. Now, let’s say you have that other issue where you have the need to protect the connection between the app and the server or to block non SSL connections or insecure connections. This is where then you would click on Android in the middle prevention and see that blocking non SSL connections is part of that. Once you have selected the protections you want. And AppDome has over 300 protections that we are supporting and constantly updating. So that wherever the issues are, whatever the hackers are doing now or in the future, we’re constantly updating them. Then you can choose from those three different protections, select the ones that you want or call the API, because everything that I’m doing here can be done through an API call. And then you just hit build my app. Now you would build the app if it goes into production, or you… can select build to test, which would allow you to create a version that is for testing purposes, for automated testing purposes. And as you can see here, Kobiton and amongst other solutions are out there for the customer to choose or for your company to choose. So once you hit build to test, it creates a version. And now you’re able to use this in your test environment. So want to test it. So let’s go to Kobiton for example, and you could see we have loaded the app here for testing and I can use the Kobiton environment to select the device that I want to test this on. I’m going to try this on an old older device and, And test this for example, on.

21:44 | Karen Hsu
The Galaxy Note five. And this is where I can load this session. Once the session is loaded, I can go in and install the app. And when I install the app, I will see some messages come up and these messages will show the error messages that we are protecting the app. So you can see here, Groupio, detected an untrusted connection. I will go back to the presentation so you can see this in slower motion. So what you’re seeing here in the demo, I took a screenshot here so you can see it more clearly. There’s a notification here or a message here saying the app detected an untrusted connection. And this was because we had in the app that the protection blocked non SSL connections. So the app is saying because of Appdome’s protection for your protection, please switch networks, close and reopen the app. And it will reference, look at the particular URL that was used. So if you go to this URL, you’ll see that it is not a secure connection. And so, Appdome is doing what it’s supposed to be doing, which is closing the app. And so it’s able to do this… Through a number of things here that you see in the platform. First is we use the platform to add the protections, For example, blocking non SSL connections or encrypting data. We were able to select those features and add them in and build the protections in minutes instead of weeks or longer with developers hand coding. So That’s the advantage of the Appdome automation. The second piece is we’re able to create a document which shows the protections that have been added by who, and when, And then what I’ll show you next? Or what you saw just now is the notification around… the error, the security event happening, which looks like an error message, but it’s an event notification which shows you, hey, the app is working as expected, which means it is protecting the app against an insecure connection and it will close the app, not shut down, but close the app so that the crash free rates remain high. And that notification can be customized by a security person or the developer. And then finally, what I’ll show you next is seeing these events in a monitoring environment, For example our ThreatScope. And so, for this last piece, I’m going to switch back to the demo and show you this last piece where we are able to see in.

25:10 | Karen Hsu
The monitoring environment, these test events. So this is the Apto monitoring environment. It has both the testing view as well as the production view For the testing part. I’m just going to show you what that looks like since we were talking about that earlier and I will select the build to test view. So I’m selecting a specific filter review of the data is just for build to test events. I’m going go to the specific app, the groupio app that I was testing. And to do that, I will again scroll down to the filters here and on the filter for the bundle ID. I will search for groupio type that in select just that one and Oops.

26:27 | Karen Hsu
Go and select all and just select groupio. So now I only get the groupio data and this is now where I can see For the app dome defenses and I could just highlight the ones in green.

26:50 | Karen Hsu
I could see that I have indeed protected against non SL connections as you see here. Now just to warrant you sell orange, you to this View here. What you’re seeing is the attacks… And this is seeing that the, In this case, the testing of the app as it tried to connect to an insecure connection is occurring in this geography here. And I can click on The events that app dome is protecting against as well as, the attacks that app dome has not protected against yet and may, and you may want to or the organization that you’re working with may want to protect later. So this is where I’m going to switch gears and now say, OK, let’s say I’m not Doing build a test. I have released my app. So I’m going to go back… To the presentation for a second And wrap up the demo here. The value of what we’re showing is We’re able to show you testing, but also once the app is deployed and is now in production, you can use the same tool here With a different filter. So I’m going to take out this filter and Clear it By clicking on all data. So now I’ve switched filters from the testing filter. And now to the production filter. So this is looking at all data. And If I were to look at… All anonymized data… I can see where all the attacks are coming from. So by geography, I can see all the attacks that Appdome has defended against. But I also can drill down into the attacks that have not yet defended against because they’re new or my organization has not decided to protect against these threats yet because they weren’t deemed as critical until now where I can see that Android debug bridge has become a much larger issue For example, and that’s where I would go… Back to Oops, back to appdome without saving. And I would click on the app that I want to protect. For example, Groupio, and I would go and Find the protection That needs to be put in place. And that would be android degabridge and simply click on that and add that to the next release. So what appdome allows you to do is really have that full cycle of protection whether it is in building in the protections as part of The release process To then Monitoring these protections once they’re in the wild. Now, through this process, appdome is able to not only protect or add the protections in automated way but also Through Kobiton Test in an automated way and complete that cycle as you go back again and have a… continuous security model. So in terms of next steps, what? I encourage you to do is first try it, Sign up for a free trial or see me or contact me for a custom trial where we walk you through that You please also see and learn from and join our community where we share information from our partners, For example, our penetration testing partners, as well as share the best practices from our customers. I also encourage you to learn and hear more about how our pesticide testers have tested ABDOME and validated the security protections work. So go to our website, sign up as you can see here in the far right hand corner, join our community. We have a number of webcasts and materials in specific topic areas, whether it’s around Android rooting and protecting against SSL pinning bypass, or protecting against Frida, as well as hearing from our customers like FIS, talk about best practices in digital banking or other customers. As you see here in this webcast with an analyst who used to work at Citigroup, and then finally see our collateral and our knowledge base articles on ABDOME. These are a couple of examples around social engineering and fraud detection, And finally take away agile DevSecOps into your organization and achieve agility, whether it’s reducing manual testing and freeing testers time to focus on work… Having automation, so you can fully automate testing of apps and all devices, OS versions without interruptions, Have readiness by improving test coverage, ensuring the app is more thoroughly tested, Ensure resilience, and make sure that the app is protected through testing and development, Have optimization and reduce the time it takes to test an app And finally have scalability, whether it’s testing Scaling as your testing changes, as your organization grows or accommodating new security features and testing without having to change the workflow. Thank you very much for your time. And I look forward to meeting you and speaking with you. Please do not hesitate to reach out to me whether it’s via email or connecting with me on LinkedIn, Thank you and speak to you soon.

32:54 | Cara Suarez
All right. So, we do have several questions that have come in… Let’s see. Okay?

33:08 | Cara Suarez
Hi. All right. Okay. So, we have our first question, How can security testing be adapted for cloud based applications and services? Considering the unique security considerations and architectural differences That came in from Vishal, Okay. Yeah. So.

33:30 | Karen Hsu
So, like we talked about, there are of systems that are being used for automating cloud testing. And so as an example, if you’re integrating into GitLab, GitHub or so forth, we have plugins, Appdom has plugins so that you can integrate the security remediation into those CI CD systems, those different various CI CD systems. And then as well, we are integrated in the testing automation piece with Kobiton, but also other test automation systems. So we’re flexible to whatever environment you have today. And in the future.

34:09 | Cara Suarez
Great. Our next question is, can we integrate Appdom with GitLab?

34:15 | Karen Hsu
Absolutely. So we have a pre built integration to GitLab. I can send you that if you just, I can put a link here later on maybe, but we have a knowledge based article on how that integration works. And I also have a video where we show you how you can configure GitLab, your GitLab environment to call what we showed earlier, which is a Fusion set that you create in Appdom. So it’s basically a security role set that you just call over and over again or change and have that called over and.

34:48 | Cara Suarez
Over again. Okay, great. Well, we’re running out of time already. That was an excellent presentation. We can answer the rest of the questions by text. And you can also see Karen over in the expo booth, if you have additional questions that we did not get to here. So thank you so much, Karen. Great talk.

35:09 | Cara Suarez
Thank you, Karen. All right. Take care.