This post will discuss security and compliance use cases for an enterprise application security program. The following are the main issues enterprises need to address with enterprise application management, in no particular order. None of these drivers are likely to surprise you. But skimming the top-line does not do the requirements justice – you also need to understand why enterprise applications offer different challenges for data collection and analysis, to fully appreciate why off-the-shelf security tools leave coverage gaps.
Compliance
Compliance with Sarbanes-Oxley and the Payment Card Industry Data Security Standard (PCI-DSS) remain the primary drivers for security controls for enterprise applications. Most compliance requirements focus on baselining ‘in-scope’ applications – essentially configuration assessments – to ensure known problem areas are periodically verified as compliant. Compliance controls typically focus on issues of privileged user entitlements (what they can access), segregation of duties, prompt application of security patches, configuring the application to promote security, and consistency across application instances. These assessment scans demonstrate that each potential issue has a documented policy, that the policy is regularly tested, and that the company can produce a report history to show compliance over time. The audience for this data is typically the internal audit team, and possibly third-party auditors.
Change management & policy enforcement
Beyond external compliance requirements enterprises adopt their own policies to reduce risk, improve application reliability, and reduce potential for fraud. These policies ensure that system and IT administrators perform their jobs – both to catch mistakes and to help detect administrative abuse of assigned privileges. Examples include removal of unneeded modules which contain known vulnerabilities, tracking all administrative changes, alerting on – and possibly blocking – use of inappropriate management tools, disabling IT administrators’ access to application data, and detecting users or permissions which could provide ‘backdoor’ access to the system. All of which means these policies are specific to an individual organization, are more complex, and require a great deal more than application assessment to verify. Effective enforcement requires a combination of assessment, continuous monitoring, and log file analysis. And let’s not beat around the bush – these policies are established to keep administrators – of IT, databases, and applications – honest. The audience for these reports is typically internal audit, senior IT management, automated change management systems, and the security group.
Security
A debate has raged for 15 years about whether the greatest threat to IT is external attackers or malicious insiders. For enterprise applications the distinction is less than helpful – both groups pose serious threats. Further muddying the waters, external parties seek privileged access, so they may be functioning as privileged insiders even when that is an impersonation. Beyond attack detection, common security use cases include quarterly ‘reconciliation’ review, watching for ad hoc operations, requests for sensitive data at inappropriate times or from suspicious locations, and even general “what the heck is going on?” visibility into operations. These operations are commonly performed by users or application administrators. Of all the use cases we have listed, identifying suspicious acts in a sea of millions of normal transactions is the most difficult. More to the point, while compliance and policy enforcement are preventive operations, security is the domain of monitoring usage in near-real time. These features are not offered within the application or supporting database platform, but provided through external tools – often from the platform vendor.
Transaction verification
As more enterprise applications serve external users through web interfaces, the problem of fraud growing. Every web-facing service faces spoofing, tampering, and non-repudiation attacks, and often (and worst) SQL injection. When successful these attacks can create bogus transactions, take partial control of the supporting database, and cause errors. But unlike general security issues, these attacks are designed to create fraudulent transactions and constructed to look like legitimate traffic. How companies detect these situation varies – some firms have custom macros or procedures that look for errors after the fact, while others use third-party monitoring and threat intelligence services to detect attacks as they occur. These tools are designed to detect users who attempt to make the application behave in an unusual manner – relying on metadata, heuristics, and user/device attributes to uncover misuse by application users.
Use of sensitive information
Most enterprises monitor the use of sensitive information. This may be for compliance, as with payment data access or sensitive personal information, or it may be part of a general security policy. Typical policies cover IT administrators accessing data files, users issuing ad hoc queries, retrieval of “too much” information, or any examination of restricted data elements such as credit card numbers. All the other listed use cases are typically targeted at specific user or administrative roles, but policies for information usage apply to all user groups. They are constructed to define uses cases which are not acceptable, and alert or block them. These controls may exist as part of the application logic, but are typically embedded into the database logic (such as through stored procedures), or provided by a third-party monitoring/masking tool deployed as a reverse proxy for the database.
The next post will detail how enterprise applications differ from other platforms, and how those differences create security gaps for off-the-shelf tools.
Reader interactions
One Reply to “Building an Enterprise Application Security Program: Use Cases”
This is the best piece I’ve seen from Securosis in years. The worst piece I’ve seen in years was a few weeks ago on WAFs. You should really give up the WAF thing — it makes no financial sense for any organization to go that route. I’m especially happy there is no mention of WAF in this post.
Especially kudos to the mention of the unintentional insider threat, which does actually equate instead of conflate the insider threat debate. Second, the issue of coverage from COTS tools is possibly the largest misunderstanding of application security or app penetration testing. So, I’m also glad to not see any mention of scanner technology in this post.
The next-generation products and services for application security are still slowly emerging, compounded by the ever-increasing reach of applications into emerging technologies such as wearables (previously mobile), ambient intelligence (previously cloud computing and the maker movement), and sensor technology in general. Thus, appsec’s future is predicated on sensor-based application instrumentation and continuous application security concepts. However, I prefer to hear words describing this technology as “antifragile” instead of “rugged” as nomenclature is extremely important.