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.

Share: