Application Security: How to Transition From a “Fire-Fighting” to a “Fire Prevention” Strategy
We’re all keenly aware that cyber attacks occur on a regular basis. Every business that utilizes applications — Web-based or mobile applications for their customers, business partners or employees — must invest in cyber security.
Frankly, their investments are not paying off. Why? Because many organizations mistakenly believe that paying for security breaches after they occur offers a better financial return than investing in improved security protection prior to a potential breach.
In reality, what businesses are paying as a result of security breaches far exceeds the investment they’re making: Research suggests that the cost of an attack ranges anywhere from five to 30 times the investment that businesses are currently making. Industry sources also report that anywhere from 30 to 50 percent of attacks are targeted on the application layer.
Why are organizations generating such a poor ROI and seeing so many application layer attacks?
There are many reasons, but two in particular are worth highlighting:
1. Pressure to deploy apps quickly
Part of the problem is a management issue: Businesses are too focused on getting applications to market quickly. As a result, many cut corners with security. In a recent report, 79 percent of IT professionals said they were pressured to roll out projects that weren’t security-ready.
2. Inadequate attention on app security
For most organizations, application security is not a high priority — even though it should be. Recently, 451 Research identified that only 6 percent of organizations considered “application security” a top-three project priority for the next 12 months. Projects focused on identity management, security information and event management (SIEM) and firewall management were twice as popular.
For those offering applications to consumers, most rely on traditional safe-coding practices and basic encryption that are offered by app stores; but it’s quite easy to hack an app if your preventative measures are so primitive (see article I wrote a couple of weeks ago).
For those offering applications to partners or employees, many have a false sense of security, thinking that if they protect the device, they’re protecting the application as well. Unfortunately, most mobile device management solutions don’t protect applications or, if they do, protection typically takes the form of “policy wrappers” that govern mobile application management (for example, when an app is used, where it is used). These solutions still leave mobile applications exposed.
What Can We Do About It?
First, management needs to evaluate their approach to application security and, for many, step up investment in terms of budget and overall resources for key projects.
Second, management must move beyond a “marking the boxes on a checklist” approach to application security and understand that, in today’s mobile world, there are new risks that we need to address. Most organizations that build and deploy mobile applications follow common secure development and penetration testing practices. While these are excellent preventative measures, the little-known irony is that a mobile application hacker does not need to prey upon security flaws (vulnerabilities) in a mobile app in order to exploit them. Unless the app is protected, mobile hackers have access to the application binary and can quickly and easily reverse-engineer it back to source code. This gives them a clear blueprint of all the security controls, business logic, proprietary algorithms and more, leaving the door wide open to tampering, malicious code injection, data or IP theft and other forms of exploitation.
Industry Leaders Recommend That Binary Code Be Protected
- Leading analysts are identifying the need for binary protection. Says Gartner, “For critical applications, such as transactional ones and sensitive enterprise applications, hardening should be used.”
- The Open Web Application Security Project (OWASP) — the largest application security community — recently released its list of top 10 mobile risks and included “lack of binary protection” as a top risk that should be addressed.
- Many leading application security consultancies and penetration testers are making similar recommendations. As an example, in their best practice guide for secure mobile app development, viaForensics recommends implementing “resistance against run-time manipulation and leveraging code obfuscation to complicate reverse engineering.”
The Future of Application Security
Despite the above recommendations by analysts and consultants, precious few organizations are protecting binary code. Member-based data from OWASP indicates that 86 percent of mobile applications that were tested lacked binary hardening. The good news is that the right technology choice makes it relatively easy to harden your applications. Characteristics of such technology include:
- No requirement for you to change source code.
- An automated engine utilized at the compile stage of the process.
- Hardening performed for apps that run on major mobile platforms and developed with standard development tools.
Deploying this technology results in an application that:
- Defends itself against attacks through advanced obfuscation, encryption, pre-damage and metadata removal.
- Detects when an attack is being attempted at run-time through techniques like check-summing, resource verification, debugger detection, method swizzling/hook detection and jailbreak/root detection.
- Reacts to ward off attacks by shutting down applications, self-repairing or alerting.
When you use application hardening best practices, positive business impacts can be achieved, such as those summarized in the chart below:
75% of Mobile Security Breaches Will Be the Result of Mobile Application Misconfiguration
Gartner recently predicted that by 2017, “75 percent of mobile security breaches will be the result of mobile application misconfiguration.” Let’s take a major step forward by focusing more on application protection and not overlooking new mobile risks (such as unprotected binary code) so we can prove them wrong. This may require you to significantly reevaluate your overall security spend or redistribute more of it to the application layer. If we take these steps, companies will see fewer application-focused attacks and realize a greater return on their application security investments.