by Rohit Sethi and Yuk Fai Chan
The Problem
We have a pervasive problem in our field. We lump two disparate classes of security weakness together. Some articulate the difference as “business logic” vs. “technical” or “semantic” vs. “syntactic”. I’d like to build on a familiar term to developers: “domain”. Each kind of software weakness is domain-specific or domain-agnostic (or both). Making this distinction is critical. We currently try to fix both sets of weaknesses with the same sets of tools, processes, and expertise when in fact they need to be treated differently. Our current approaches to application security work well for domain-agnostic vulnerabilities, but we need domain experts to solve domain-specific problems.
Examples
Let’s suppose an energy wholesaler in a deregulated market builds a new web application. They hire security testers to perform a combined source code review and penetration test against their application prior to deployment. The testers find a series of well known web application vulnerabilities: cross-site scripting (XSS), insufficient password complexity requirements, user enumeration in forgotten password, direct object access, and the like. Now suppose this system had another vulnerability: by simply changing the date field on one of the pages to a day in the past, users have access to pricing history which may give energy market speculators an unfair advantage tantamount to insider trading. The odds of the testers finding this particular vulnerability rests squarely on how much they understand the domain of deregulated energy markets. XSS, direct object access, and similar vulnerabilities are domain-agnostic; they’re dangerous but they’re also well understood by the security community. The insider trading vulnerability could amount to millions or more in losses and is likely to go uncaught for a longer period of time.
Another example helps illustrate this dichotomy. Suppose a large manufacturer hires a seasoned penetration tester to assess the security of their web-based ERP application (think SAP, PeopleSoft, or Oracle Financials). The tester is likely to find a directory traversal vulnerability but much less likely to find segregation of duties violations. For example, suppose an end user could both authorize and receive a payment from the Accounts Payable module. If the tester understands basic accounting concepts, he may catch this. More complex accounting issues will likely remain undiscovered, however, unless the tester has deep domain knowledge of accounting.
Finally, consider a popular consumer electronics retailer who keeps stock-keeping unit (SKU) entries in its inventory database for all products that it carries. Typically, these entries might include product descriptions or model numbers for easy identification. Now, imagine that this retailer creates placeholder inventory entries in anticipation for a major product release from a giant technology company known for its secrecy around its future products. If these entries are overly descriptive and include legitimate details about the unreleased products, this information could be leaked through employees of the retailer who have access to the inventory database. Such a leak can potentially damage the business relationship that the retailer has with its partner.
Do You Speak Ubiquitous?
Eric Evans presents an in-depth treatise of the effects of the domain on software design in his book Domain-Driven Design (DDD). Evans presents a number of concepts related to DDD. One such concept, “Layered Architecture”, breaks software into four common layers: User interface/presentation, application, domain/model, and infrastructure. The book concentrates largely on the domain/model layer by presenting a series of modeling techniques and patterns. The “ubiquitous language” is a domain-specific language that evolves over time. In the energy wholesale example, developers may describe their model with terms like “market participant” and “congestion revenue rights” which are part of their ubiquitous language. Without understanding the concepts behind the ubiquitous language, security assessors run the risk of missing important vulnerabilities in the system. Developers, quality assurance testers, in-house security experts, and security experts with extensive expertise in a specific industry are often comfortable with the ubiquitous language. These domain experts are ideally suited to identify domain-specific threats during requirements and design and hunt for domain-specific vulnerabilities during development, testing, and deployment. XSS and other forms of domain-agnostic vulnerabilities should be relegated to domain-agnostic testing tools such as static analysis, automated security runtime testing, and integration of security testing into QA testing frameworks with human oversight. Third party penetration testers need not understand the domain very well to find these vulnerabilities. Parameter manipulation, cross-site request forgery (CSRF), fine-grained authorization bypass, manipulation of page-flow navigation, and other domain-specific vulnerabilities should be treated separately; they need people to think of them to find these vulnerabilities. If you elect to use the same people and tools to find both categories of vulnerabilities then you need to ensure the security experts take the time to understand their domain and speak the ubiquitous language. Having a deficiency of skill-set in either domain-agnostic vulnerabilities or domain-specific knowledge will almost certainly leave your system open to risk.
A Familiar Pattern
The security community explicitly understands the importance of domain-specific knowledge in technical domains. For example, many security experts have examined Secure Socket Layer (SSL), but presumably few take the time to understand the Online Certificate Status Protocol (OCSP). OCSP is a sophisticated replacement for Certificate Revocation Lists (CRLS); essentially a mechanism to determine if a particular certificate is revoked and no longer valid. In 2009, Moxie Marlinspike discovered that a man-in-the-middle could circumvent OCSP responders in certain cases simply be sending the number 3 [1]. The Request For Comments (RFC) for OCSP dates back to 1999 [2] – ten years before Marlinspike’s discovery. In 2008, Dan Kaminsky found a critical flaw in the Domain Name Service (DNS) which resulted in a massive multi-vendor patch [3]. In 2007, Brad Hill discovered that servers implementing the XML Digital Signatures protocol may be vulnerable to critical remote command execution vulnerabilities – particularly worrisome because XML Digital Signatures is part of the WS-Security specification [4]. In all of these cases, the security researcher took the time to understand the underlying protocol in some level of depth. Although they neither wrote the protocols nor created products that that adhered to the protocols, they understood the domain well enough to point out logic flaws.
Moving Forward
Identifying the distinction between domain-specifics and domain-agnostics is an important first step. The next step is to change the way we define application security techniques. We should approach both sets of problems with a commensurate set of techniques. We should divide Top N lists and lists of vulnerabilities into the two categories. We should correctly and clearly classify new vulnerabilities as being domain-specific, domain-agnostic, or both. Organizations should have separate plans to deal with both: for example, heavy reliance on automated testing and cross-industry security expertise for domain-agnostic vulnerabilities and more reliance on manual testing and domain understanding for domain-specific vulnerabilities. We should pool expertise in individual domains, perhaps by starting with particular industries, to share knowledge of domain-specific vulnerabilities and disseminating that knowledge as successfully as we currently disseminate domain-agnostic vulnerabilities. If cross-industry sharing is not viable, organizations should separate and maintain domain-specific security knowledge internally and share that information with developers, QA, and all stakeholders in the secure SDLC. Cross-industry security groups such as FS-ISAC for financial services do facilitate some security knowledge transfer, but they rarely share knowledge to the granularity of domain-specific threats against particular types of applications.
What Can You Do?
You can help make this happen. Start to explicitly talk about the difference between these two kinds of vulnerabilities in your daily conversations, and make sure that you adjust your techniques for detection, prevention, and remediation accordingly. Encourage your industry groups to start focusing on sharing domain-specific threat data. Are you aware of an attempted or actual incident on an application that involved manipulation of that application’s business logic? Find ways to share that data with your industry! Make the data anonymous if necessary, but find a way to centralize and share the information so that everyone benefits from preventing opportunities for fraud.
[1] http://www.blackhat.com/presentations/bh-usa-09/MARLINSPIKE/BHUSA09-Marlinspike-DefeatOCSP-PAPER2.pdf
[2] http://www.ietf.org/rfc/rfc2560.txt
[3] http://news.cnet.com/8301-1009_3-9998906-83.html
[4] https://www.isecpartners.com/files/XMLDSIG_Command_Injection.pdf
