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.

More from Software Vulnerabilities

X-Force Prevents Zero Day from Going Anywhere

8 min read - This blog was made possible through contributions from Fred Chidsey and Joseph Lozowski. The 2023 X-Force Threat Intelligence Index shows that vulnerability discovery has rapidly increased year-over-year and according to X-Force’s cumulative vulnerability and exploit database, only 3% of vulnerabilities are associated with a zero day. X-Force often observes zero-day exploitation on Internet-facing systems as a vector for initial access however, X-Force has also observed zero-day attacks leveraged by attackers to accomplish their goals and objectives after initial access was…

8 min read

Patch Tuesday -> Exploit Wednesday: Pwning Windows Ancillary Function Driver for WinSock (afd.sys) in 24 Hours

12 min read - ‘Patch Tuesday, Exploit Wednesday’ is an old hacker adage that refers to the weaponization of vulnerabilities the day after monthly security patches become publicly available. As security improves and exploit mitigations become more sophisticated, the amount of research and development required to craft a weaponized exploit has increased. This is especially relevant for memory corruption vulnerabilities.Figure 1 — Exploitation timelineHowever, with the addition of new features (and memory-unsafe C code) in the Windows 11 kernel, ripe new attack surfaces can…

12 min read

Direct Kernel Object Manipulation (DKOM) Attacks on ETW Providers

17 min read - Overview In this post, IBM Security X-Force Red offensive hackers analyze how attackers, with elevated privileges, can use their access to stage Windows Kernel post-exploitation capabilities. Over the last few years, public accounts have increasingly shown that less sophisticated attackers are using this technique to achieve their objectives. It is therefore important that we put a spotlight on this capability and learn more about its potential impact. Specifically, in this post, we will evaluate how Kernel post-exploitation can be used…

17 min read

Dissecting and Exploiting TCP/IP RCE Vulnerability “EvilESP”

10 min read - September’s Patch Tuesday unveiled a critical remote vulnerability in tcpip.sys, CVE-2022-34718. The advisory from Microsoft reads: “An unauthenticated attacker could send a specially crafted IPv6 packet to a Windows node where IPsec is enabled, which could enable a remote code execution exploitation on that machine.” Pure remote vulnerabilities usually yield a lot of interest, but even over a month after the patch, no additional information outside of Microsoft’s advisory had been publicly published. From my side, it had been a…

10 min read