No company wants to buy or create insecure software. But in daily practice, requirements like a “slick” UI or being first to market, usually win out over security. So the question is…

Are we doing it wrong?

Not necessarily.

From a pure business risk perspective, picking time to market over more security might sometimes be the right choice (much though security pros might be loath to admit it). Remember – the point of an application security program isn’t to win the title of “most secure.” The point is to give the stakeholders and decision makers targeted, accurate intelligence so they can make business focused risk decisions that meet the company’s needs. If the risk of preventing a key application from deploying is greater than the data loss or downtime that could result from an exploitable vulnerability in the app, then deploying (even with that vulnerability) may make the best business sense.

Even more sense? Using tools and tests to determine that the vulnerability is there, putting a compensating control like an IPS (intrusion prevention) rule in place to prevent an attacker from exploiting that vulnerability and creating a response plan for fixing the source of the vulnerability in the application code as soon as possible.

In a perfect world, the company has a robust security methodology in place and applications never make it to final user acceptance testing with the vulnerability in the first place. But we know the world isn’t perfect — and that many companies are far from being at a point where all applications reach UAT completely free of defects and exploit exposures.

And the problem is growing because the number of applications is growing. In 2013, car manufacturers have more than crash impact tests to worry about. Now they have to evaluate if their brake software is properly tested and their in-console movie ticket buying app is PCI compliant. We’re still building complex applications to power back-end business processes, we’re still building web and cloud-based solutions to embrace features those platforms provide, and now we’re also writing apps to feed the hungry App stores of Apple, Google and Microsoft… all to power increasingly “smart” and connected devices from TVs to cars.

A better way

With all those apps to build, test and secure, companies need a better way to make application security and risk decisions. That’s why I believe we’re seeing these programs transform. We’ve already seen a move from manual code reviews for a small part of the portfolio to use of automated, and manually assisted, testing tools on a much larger part of the portfolio.

In 2014 and beyond we’ll see companies move towards using targeted intelligence from their testing programs to enable them to, not only make better risk decisions, but also to lay the groundwork for continuous improvement of the program as a whole. Watch this space for ways to use intelligence to improve security throughout the SDLC, but for now, let’s take a look at one aspect of the class risk equation, “consequences”, as it pertains to mobile and embedded application security.

Understanding the risks

To determine the consequences of exploits in a mobile or embedded app, consider the user base and what can go wrong if the vulnerability is exploited. Consider companies that produce mobile apps aimed at children and who, for the second time this year, have been called out by the FTC: most recently in the report “Mobile Apps for Kids: Disclosures Still Not Making the Grade.” If the application is made by a company that is more interested in short term gain than long term reputation, failure to make proper disclosures may not be a concern. But if a brand builds value by having parents’ trust, then failure to violate disclosure policy could negatively impact long-term financials. Another consideration is compliance, the Children’s Online Privacy Protection Act (COPPA) was passed in 1998 and failure to disclose how data is used in a mobile app aimed at children could be in violation of the Act.

Exploit consequences

There are consequences to exploiting vulnerable applications on devices like cars and TVs too. Researchers recently published an exploit for a popular Smart TV that allows remote root access to the television and access to files on a USB plugged into the TV. One of the consequences of this kind of vulnerability is brand reputation damage for the manufacturer. If a customer has sensitive data on the USB and it’s accessed by an attacker, the customer could get their loss covered in the media. Is that a major consequence for the brand? Only the brand can make that decision, but the application security team can help the decision makers be smarter about their decision by providing data on ease of exploiting this kind of vulnerability — and draw clear damage and consequence scenarios. What are the consequences of an attacker retrieving music and movies off of a USB? What about sensitive data about that owner of the USB?

Very often consequence discussions include scope considerations. Will an exploit expose data for many users or only a few? Contrast a vulnerability in a database that stores millions of health records with a Trojaned mobile app that can only gather health data about the owner of the phone.

Getting smarter about risk

There’s no doubt we are doing more with software and deploying more apps both mobile and embedded than we ever have before and that makes the security of those apps a major concern going forward. As application security programs evolve to include security throughout the lifecycle, we will get smarter about the risks associated with those applications. And we must know what, if any, vulnerabilities exist and make smart risk decisions to determine if the consequences of exploiting those vulnerabilities are critical enough to justify blocking deployment. Block too many apps and you impede business progress — but let a critical app into the Play or AppStore that results in loss of data, and you could bring about significant brand damage as a consequence.

To make smarter risk decisions we need to improve our application security programs. Organizations can’t afford the impact of bad mobile and embedded application risk decisions and that’s why I believe we’ll see a transformation in application security programs that puts the emphasis on understanding the consequences of the exploit and the total business risk picture.