Application security needs to be shored up now

PCI DSS requirement 6 falls into the domain of software developers who are involved in the development of applications that process, store or and transmit cardholder data. There is little low-hanging fruit here, and firms that have in-scope applications have a lot to do to ensure PCI compliance.

Application security has come a long way. Now it’s mainstream and is being reported in media like The Wall Street Journal and CNN. The last few years has seen myriad application-related meltdowns from Stuxnet, Duqu 1 and 2 and more. The recent July 8 meltdowns of United Airlines, WSJ and NYSE attest to the fact that application security is a major concern, irrespective how often it is ignored.

Brick and mortar financial institutions are the targets of choice for attackers since that’s where the money is. It’s no different in the cyber world as hackers have been targeting payment applications because that’s where the money is. Today, Target, Home Depot, Neiman Marcus, OPM, Anthem Healthcare and more are among the victims.

Breach incidents involving payment processing systems have skyrocketed, due in part because vulnerabilities and related attack surfaces are still not being eliminated from applications. Point-of-Sale (POS) system-targeting malware continues to evolve in sophistication and complexity to include stealth attachment to application processes, self-morphing profiles to evade detection, cardholder data (CHD) related RAM scraping intelligence to harvest Primary Account Numbers and other sensitive data from victimized system memory.

Application security is at the core of information security, primarily due to the fact that most data breaches and compromises result from security related vulnerabilities contained within applications. Firms have spent much of the last decade securing their network environments with fancy information security hardware and software such as WAF, UTM, IDS/IPS and things with a lot of acronyms. In the meantime, a myriad of high profile data breaches have occurred with application security vulnerability as the primary root cause of compromise. These application deficiencies were exploited which led to critical data theft.

Within a week in June 2015 alone, there were announcements about major security flaws with Apple applications, Samsung Galaxy phones and Duqu 2. The application security wake-up calls happened some years ago. These flaws should be a reminder that application security is not something to be taken lightly, especially when considering the veritable explosion of new applications available for mobile devices.

Application security – why can’t everyone ‘just do it’!

Like regular physical exercise, everyone agrees that application security is of paramount importance. The challenge is getting motivated to both hit the treadmill, and to ensure secure code is being written and delivered into production applications.

So if application security is so undeniably important, why isn’t everyone on the application security bandwagon? The reality is that there is a lot that can get in the way of application security, and some of the most significant issues are:

  • Time-to-market pressures - marketing and sales want the application shipped last week, while the code reviewers aren’t even close to finishing their reviews. With often huge time-to-market pressures, it’s invariable the insecure code will get shipped. A team of the CIO, CSO and head of application development need to work together to ensure that time-to-market pressures don’t force bad code out the door.
  • Taxing an already overtaxed applications development team – most development shops are already overburdened. Adding the task of secure coding to their plate may create a mutiny. But the reality is that it’s 2015 and for any application dev group, metrics around secure coding and the requirement to write secure code is no longer an elective. It must be built into the team’s DNA. A final issue is that the corporate information security team often may not realize that developers can’t become overnight security experts. Give them time.
  • Tools integration into the Software Development Lifecycle (SDLC) – a real problem is that, while there are application security tools; they don’t often integrate well into the SDLC. Often, they can be difficult to configure and run, and also can produce numerous ‘false positive’ indicators. Finally, many of the tools will note a problem in the code, but don’t provide adequate guidance on how to fully fix it.

In part 2, we’ll get into the details of PCI and application security, and detail the compliance domains relevant to PCI and application security. Read Part 2.

Ben Rothke CISSP PCI QSA is a Senior eGRC Consultant with Nettitude, Inc. and the author of Computer Security: 20 Things Every Employee Should Know.

David Mundhenk, CISSP, PCIP, QSA (P2PE), PA-QSA (P2PE) is a Senior Consultant for the Application Validation team at Coalfire Labs.

Copyright © 2015 IDG Communications, Inc.

Microsoft's very bad year for security: A timeline