NOWSECURE NOW AVAILABLE IN THE MICROSOFT AZURE MARKETPLACE

Microsoft Azure customers gain access to NowSecure Mobile App Security and Privacy Testing for scalability, reliability, and agility of Azure to drive mobile appdev and shape business strategies.

Media Announcement
NOWSECURE NOW AVAILABLE IN THE MICROSOFT AZURE MARKETPLACE NOWSECURE NOW AVAILABLE IN THE MICROSOFT AZURE MARKETPLACE Show More
magnifying glass icon

Detecting Mobile AppSec Testing Vendor Bullsh#t (BS)

Posted by
Brian Lawrence

Brian Lawrence

Solutions Engineering Manager
At NowSecure, Brian helps enterprises design and implement solutions to secure their mobile transformations and develop higher quality, more secure mobile apps. Prior to a stint in the restaurant and hospitality industries, Brian instituted a managed services provider's SaaS delivery model as a solutions engineer.

Recently the United States Department of Defense (DoD) released a guide called “Detecting Agile BS.” Setting aside the lighthearted title from a serious government agency, the document brought some common misconceptions about Agile development and tools into sharp focus. In this day and age of marketing buzzwords, carnival barkers and information overload, it’s hard to distill down to what’s really important.

While Agile development is certainly top of mind for many development teams, mobile security isn’t quite as mature or as talked about. However, we still see a considerable share of mobile application security BS. Many people have been testing the security of networks and web applications for years, but mobile app security testing is still in its infancy. So if imitation is the sincerest form of flattery, here comes my cut on mobile appsec testing.

Key Foundations of Mobile App Security

Over the last decade, NowSecure has built an impressive set of mobile security best practices. We also draw from industry standards and guidelines such as the Open Web Application Security Project (OWASP). OWASP has been an outstanding resource for web app security and recently upped its mobile appsec game. Some of the key tenants that we use to support our clients mobile app needs are:

These key warning flags may indicate that a tool does not perform proper mobile appsec testing:

  • The tool cannot analyze binary packages. Binaries contain components that can leave apps vulnerable which cannot be found by source code review.
  • The tool uses emulators to test mobile apps. Emulators do not fully simulate what a physical device and network can do, leaving exploitable gaps in coverage.
  • The tool performs static-only testing. Not exercising the app binary dynamically on a physical device leaves incredible gaps in testing, particularly for data at rest and data in motion.
  • The tool does not have feature parity between iOS and Android. iOS can be difficult to test but is also susceptible to high risk vulnerabilities, and must be tested with the same rigor as Android applications.
  • The tool relies on people to perform testing. In the DevOps world, it’s all about automation and there is no way to add enough skilled security analysts to keep pace with releases.

There are three crucial components of a mobile appsec testing program to consider. Here they are outlined below along with a few examples.

Questions to ask web app/static scanners:

  • How do you test for Man-in-the-Middle Attacks?
    • Wrong answer: Examining code. Network communications can only be tested with the app via DAST on a real device.
  • How to you test for data at rest?
    • Wrong answer: Static only. To test data storage you have to run the app and see all the different ways and methods it uses to store data to the device.
  • How do you develop new mobile functionality?
    • Most web app testing vendors do not have dedicated teams with mobile expertise.
  • How fast can you generate results?
    • Wrong answer: Daily, weekly, bi-weekly. DevSecOps requires test times in minutes not days.
  • Show me how you cover the OWASP MASVS.
    • Wrong answer: Static covers it all. Actually only parts of three of the 10 can be identified via static analysis.
  • What devices do you use to perform dynamic testing?
    • Wrong answer: None. Many vendors run simple scans on hard-coded API endpoints but do not test the actual app.
  • What code platforms do you support? Do you support XAMARIN, cross-platform and low-code tools?
    • Wrong answer: Native only. Most tools cannot test for hybrid platforms. Follow up to ask how soon it will offer support.
  • How does your iOS testing compare to Android?
    • Wrong answer: We don’t need to test as much on iOS. Testing on iOS devices is much more difficult, requiring jailbreaking or code injection where dynamic on device is the only option — but the vulnerabilities are the same.

Questions to ask “dynamic” testers:

  • What devices are you testing on and where are those device rigs?
    • Wrong answer: Emulators. Ideally test your mobile apps on local devices or a web farm.
  • How does your iOS testing compare to Android?
    • Wrong answer: They are the same. iOS testing is much more difficult, they will not have feature parity.
  • How fast do you return test results in DevOps pipeline?
    • Wrong answer: Anything longer than 30 minutes. It is important to make sure that results can be consumed via API as well, otherwise you cannot truly integrate.
  • Do you offer jailed testing on iOS?
    • Wrong answer: No. Jailbreaks are never consistent enough to stake your organization on.

The image below is a helpful decision tree that walks you through asking the right questions to get to the bottom of what a vendor’s products really do.

 
I hope you found this blog valuable in terms of peeling away the layers of vendor claims vs reality. We all wish we lived in a no-BS world but it’s out there and we need to recognize when it happens. Beyond the questions above we have a checklist that you might find valuable as well.