Why WAFs and MDM are not Security Silver Bullets

silverbullet.jpeg

Security is hard. There's no doubt about it. From network access to data access and everything in between, the sheer number of issues to track to make sure an environment is secure is daunting at best. So even though we know that the proverbial silver bullet (for solving security problems) does not exist, it's really not too hard to imagine that security professionals sometimes believe that a product might actually "solve" one of the many security issues they face. Even the steadfast realist/cynic falls into the trap now and again. By the way, I am not pointing fingers. I was guilty of the same thing a time or two back when I was an information security manager.

 

There are many examples of this way of thinking, but one that stands out and that has been around for a few years is the Web Application Firewall, or WAF. The idea behind the WAF was very simple: you install a device or software in front of your web application infrastructure, and it uses signatures to identify and filter out attacks on the web applications. This was great idea (and still is). It provides a layer of protection for the web applications in addition to practices such as secure coding and regular security assessments of web applications for security flaws. A WAF can also potentially give more time for developers to secure the code, and it can even give the security department visibility into web-specific attacks that are coming into the network. However, the trap is sprung when organizations decide to look at the WAF as a substitute for secure coding practices. This view is not uncommon.

 

A few questions we get about the effort that needs to go into securing applications:

 

  • Can't I just get a WAF to lock down my applications?
  • Why do I need to have an application vulnerability test done when I have WAF?
  • I need my developers to learn secure coding practices? They're too busy. I'll just get a WAF to lock the apps down.


Unfortunately, the second question above is only reinforced when the Payment Card Industry gives an either/or choice to secure applications. Section 6.6 in PCI DSS allows for either performing web application vulnerability tests OR installing a WAF. Granted, the PCI Council has released a supplement that clarifies many points and specifically points out that a WAF "does not eliminate the need for a secure software development process (Requirement 6.3)." However, it does cause issues when cost-conscious managers are making choices on how much and where to spend dollars on the security program. And it also can give a false sense of security to security managers and staff that the WAF is "good enough".

 

Another more recent development that falls along these same lines (of the silver bullet) is mobile device management (MDM). As mobile devices have become more and more a part of everyday business, organizations are looking for a way to secure those devices. And the same "silver bullet" thinking has risen its head in the mobile device security market in the form of MDM. Mobile application management (MAM) is the specific feature in many MDM solutions that is causing the issue (though MAM vendors are sometimes standalone companies, the market has turned to MDM companies offering MAM as part of their suite of products). While many MAM solutions offer some security controls (app wrapping, app tunneling, authentication controls, etc.), the primary purpose is to provide control around the provisioning of and access to applications on mobile devices. So essentially, organizations using MAM are trying to stop app security issues by controlling what their users can download and access in the first place. I like that as one way of getting a secure mobile environment. What MAM is not meant to be is a robust security tool that locks down any application, no matter what two-bit application store the app comes from.

 

But I am hearing from colleagues and coworkers that there is some confusion around the purpose of MAM, and I am personally seeing this same issue. The questions are being asked by customers:

 

  • Can't I just get MDM (and the MAM features that come along with it) to secure my mobile applications? 
  • Why do I need to have you or anyone else check to see if the mobile apps are secure? 
  • Why do I need to ensure that my mobile apps aren't leaking data or user credentials? Won't MAM lock that down?

 

Sound familiar?

 

Again, I am not faulting security folks for looking for a solution to a problem. I understand the temptation. But no product should be viewed as a FIX. Instead, products should be viewed as being PART of a full solution. Securing mobile applications has some unique aspects in so far as the details are concerned, but overall there is no difference from securing any application. Educate the developers on secure coding practices. Embed security in the SDLC by doing things like creating security requirements before development, creating threat models in the design phase, analyzing the code during development, testing dynamically once there is a deployable version, and testing regularly after it is deployed. Make sure that the app is as secure as you can make it, and then deploy the MAM solution after it has been determined to be a good part of a full solution. The users of your apps will thank you, and the security world in general will thank you as well.

Leave a Comment

We encourage you to share your comments on this post. Comments are moderated and will be reviewed
and posted as promptly as possible during regular business hours

To ensure your comment is published, be sure to follow the Community Guidelines.

Be sure to enter a unique name. You can't reuse a name that's already in use.
Be sure to enter a unique email address. You can't reuse an email address that's already in use.
Type the characters you see in the picture above.Type the words you hear.
Search
Showing results for 
Search instead for 
Do you mean 
About the Author
US Army veteran. IT and infoSec professional since 1994. Founder of HouSecCon. aka m1a1vet


Follow Us
The opinions expressed above are the personal opinions of the authors, not of HP. By using this site, you accept the Terms of Use and Rules of Participation