When Apps Attack! What Is – and Isn't – Application Security

Posted on by John Linkous

One of the most interesting subjects at RSA Conference 2014 was the defense of software code, in all its many forms. While many of the developer-centric tracks and sessions were heavily focused on eliminating flaws within code, one of the key messages that crossed the boundary of speaking events is the idea of what is—and is not—application security.

Black-box testing of apps is a fascinating concept. While there are a large number of security tools and controls that can aid software developers in making their applications less likely to be hacked—think of firewalls, anti-malware, and IDS/IPS—these tools are not "application security" in and of themselves.

Though these tools are still needed, and very much important, the real threat from application security comes from the prevalence of well-known programmatic problems: buffer overflows, cross-site scripting attacks, SQL injection susceptibility, and more. While no developer can be 100% effective in eliminating these issues, developers can reduce these problems by relying on trusted and security-tested code libraries, ensuring that QA testing includes rigorous security evaluation, and making sure that there are periodic tests through vulnerability assessments by trained security personnel. The days of security, developers, and software QA teams maintaining an antagonistic stance with each other have come to an end; everyone is in this together and will sink or swim as a team.

Of course, these well-known threats are not the only issues that can affect application security today. Another area where application security lags—and unfortunately, there aren't really many good security controls to mitigate the threat—is side channel attacks. We've already seen low-frequency acoustic cryptanalysis proof-of-concepts (yes, you read that correctly: hacking with sound waves), as well as BadBIOS concepts in the wild. But even more threatening than these cutting-edge attack vectors are more traditional wireless threats, including the pervasiveness of "wireless everywhere," honeypotting wireless networks, and more. IP-based devices love IP-based networks; as Ed Skoudis of SANS rightfully pointed out at RSA Conference 2014, "at best, the air gap is a low-latency connection." With the expansion of traditionally electromechanical devices into the IP-based, Internet-connected world, such as smart meters, appliances, and even cars, there is a greater possibility—and perhaps even a likelihood—that application security flaws can result in incursions to the physical world through kinetic impact.

So what does all of this mean? For security professionals, it means that the problem is likely to get worse before it gets better—if ever. Defense in depth is always a more effective strategy, including both monitoring and alerting as well as eliminating or disabling APIs, interfaces, ports, and protocols that can be used for attack. For developers, it means the need to work hand-in-hand with security and quality assurance teams to ensure that security is engineered into application development, rather than being an afterthought. For software vendors (including all of you PaaS/SaaS cloud vendors out there), this means that the additional development costs of thorough security testing need to be built into your solutions from the start. And finally, for users of applications and technology, always apply a "least common denominator" approach. Not using your wireless? Turn it off. Don't need Bluetooth when you're out of your car? Disable it. The threat chain begins with you; don't give attackers the foothold they need to exploit your systems and data.

John Linkous

, Technology Advisor

hackers & threats

Blogs posted to the RSAConference.com website are intended for educational purposes only and do not replace independent professional judgment. Statements of fact and opinions expressed are those of the blog author individually and, unless expressly stated to the contrary, are not the opinion or position of RSA Conference™, or any other co-sponsors. RSA Conference does not endorse or approve, and assumes no responsibility for, the content, accuracy or completeness of the information presented in this blog.

Share With Your Community

Related Blogs