It’s inevitable. Every organization needs externally-developed applications to some degree or another. Increasingly, these apps are web-based and accessed over the Internet. As part of a forthcoming report on protecting applications, F5 commissioned a survey with Ponemon. In it, we asked security professionals what percentage of their applications (by category) were outsourced. The top answers were:

• Financial apps, such as banking and ecommerce: 45%
• Document management and collaboration: 41%
• Office suites: 40%
• Backup and storage: 32%

Since these are externally hosted applications, it stands to reason that organizational data is now being stored, processed, and accessed outside of the organization’s defensive perimeter. Therefore, in that same survey, we asked what percentage of those applications also store critical data. The results were:

• Financial apps, such as banking and ecommerce: 36%
• Document management and collaboration: 60%
• Office suites: 52%
• Backup and storage: 67%

So, essential apps are holding essential data, and they’re out of direct oversight. Obviously, it’s not enough to just trust that things are going to be fine.

Assessing the Security of a Third-Party App

Assessing the security of your outsourced applications requires multiple steps. The first is to assess the security of the organization itself. A key way to look at the organization is through its third-party audits and security assessments. We explored that in our article Can Audits Help Us Trust Third Parties?

The second step is look at the security of the app itself, but before we delve deeply into that, it’s worth looking at how the third-party itself handles vulnerability submissions from outside. If the vendor’s response to reports of security holes is to ignore the submitter or worse, sue the submitter,¹ then you know that security isn’t going to be a high priority for them. If they are open to security submissions, is there a formal mechanism for collecting and scoring discovered vulnerabilities? Is there a dedicated department or a named point of contact? Even better, is there a bug bounty program? At the very least, you want to make sure that externally discovered holes are investigated and risk analyzed.

As a customer, you should expect to have some say in the vulnerability remediation process. One thing to inquire about is how the organization prioritizes discovered vulnerabilities. Do they use a standardized risk-based process? Common Vulnerability Scoring System v3.0 (CVSSv3)?² OWASP risk rating?³ Or is the process arbitrary? Do you get a vote in the prioritization? How are status updates on remediations communicated? Are all open vulnerabilities available for your review? What are the escalation paths if you’re not satisfied with this process? It would be best if this is spelled out in the contract or support agreement for the greatest clarity amongst all parties.

• Developer security training – Programmers should be very familiar with web app risks like the OWASP Top 10 as well as common mitigation strategies such as input sanitization and session management.
• Security standards – Developers know and follow published policies and procedures for secure development. An excellent example is the OWASP Secure Coding Practices.⁴
• Threat modeling – Attacks against the app are mapped out and neutralized in the development design. This is where you can generate “abuse cases” which describe attacker behavior you intend to prevent.
• Code review – There is a review (either automated or manual) of new code before it is compiled into the production application.
• Static application security testing (SAST) – More advanced than a code review, this is security-specific scanning of the codebase for potential security problems.
• Security functionality testing – Security features are tested for use and abuse cases (see threat modeling) to ensure they function as expected.
• External code library vulnerability management – Many security problems come not from core code but from third-party libraries and frameworks. These should also be tested and patched on a regular basis.
• Vulnerability / Dynamic Application Security Testing (DAST) – Compiled, running code is tested against simulated hacks.

One area we haven’t focused on yet are the security features of the app itself. Of course, you need to look at the security features, starting with how users log in. Does the app support enhanced authentication beyond a local username and password? Single sign-on, multifactor authentication and federation support are all basic expectations for application access. And regarding access, what do the password reset mechanisms look like? Hopefully they don’t rely on something weak like secret questions.

Beyond access, what does the encryption look like? What forms of transport encryption are in place and are they up to date? Are the TLS certificates issued from a reputable authority? Are good TLS practices in place such as HTTP Strict Transport Security (HSTS) and Online Certificate Status Protocol (OCSP) stapling? Beyond transport encryption, is user data stored in an encrypted format?

Conclusion

All of these questions are important to answer before you find yourself wedded to a critical outsource application that holds critical data. It’s just as important to revisit these questions at least annually to ensure threats are being mitigated to an acceptable level. In fact, it would be a good idea to keep raising the bar on security expectations because attackers are always evolving to work around our defenses. These kinds of assessments are critical not only to maintaining the security of your outsourced apps but to improving the app community as a whole. If enough customers insist that a vendor improves their security, then everyone benefits. Whatever you do, don’t assume app security is “just taken care of.” You rarely get what you expect—you get what you inspect.

More to come in our Application Protection Report July 25th

As noted in the intro, the perspective to write this article was actually derived from a Ponemon survey as part of a forthcoming Protecting Applications Report, which will be published here on F5 Labs on July 25, 2018!