Our goal for this series is not to cover the breadth and depth of an entire enterprise application security program – most of you have that covered already. Instead it is to identify the critical gaps at most firms and offer recommendations for how to close them. We have covered use cases and pointed out gaps; now it’s time to offer recommendations for how to address the deficiencies. You will notice many of the gaps noted in the previous section are byproducts of either a) attackers exposing soft spots in security; or b) innovation with the cloud, mobile, and analytics changing the boundaries of what is possible.

Core Program Elements

Identity and Access Management: Identity and authorization mapping form your critical first line of defense for application security. SAP, Oracle, and other enterprise application vendors offer identity tools to link to directory services, help with single sign-on, and help map authorizations – key to ensuring users only get data they legitimately need. Segregation of duties is a huge part of access control programs, and your vendor likely covers most of your needs from within the platform. But there is an over-reliance on basic services, and while many firms have stepped up to integrate multiple identity stores with federated identity, attackers have shown most enterprises need to improve in some areas.

• Passwords: Passwords are simply not very good as a security control, and password rotation has never been proven to actually increase security; it turns out to actually be IT overhead for compliance’s sake. Phishing has proven effective for landing malware on users’ machines, enabling subsequent compromises, so we recommend two-factor authentication – at least for all administrative access. 2-factor is commonly available and can be integrated out-of-band to greatly increase the security of privileged accounts.
• Mobile: Protecting your users running your PCs on your network behind your firewalls is simply old news. Mobile devices are a modern – and prevalent – interface to enterprise applications. Most users don’t wait for your IT department to make policy or supply devices – they go buy their own and start using them immediately. It is important to consider mobile as an essential extension of the traditional enterprise landscape. These ‘new’ devices demand special consideration for how to deploy identity outside your network, how to _de-_provision users who have leave, and whether you need to quarantine data or apps on mobile devices. Cloud or ‘edge’ identity services, with token-based (typically SAML or OpenID) identity and mobile application management, should be part of your enterprise application security strategy.

Configuration and Vulnerability Management: When we discussed why enterprise applications are different we made special mention several deficiencies in assessment products – particularly their ability to collect necessary information and lack of in-depth policies. But assessment is still one of the most powerful tools at your disposal, and generally the mechanism for validating 65% of security and compliance policies. It helps automate hundreds of repetitive, time-consuming, and highly technical system checks. We know it sounds cliche, but this really does save compliance and security teams time and money. These tools come with the most common security and compliance policies embedded to reduce custom development, and most provide a mechanism for non-technical stakeholders to obtain the technical data they need for reporting. You probably have something in place already, but there is a good chance it misses a great deal of what tools designed specifically for your application could acquire. We recommend making sure your product can obtain data, both inside and outside the application, with a good selection of policies specific to your key applications. A handful of generic application policies are a strong indicator that you have the wrong tool.

Data Encryption: Most enterprise applications were designed and built with some data encryption capabilities. Either the application embeds its own encryption library and key management system, or it leverages the underlying database encryption engine to encrypt specific columns – or entire schemas – of data. Historically there have been several problems with this model. Many firms discovered that despite encrypted data, database indices and transaction logs contained and leaked unencrypted information. Additionally, encrypted data is stored in binary format, making it very difficult to calculate or report across. Finally, encryption has created performance and latency issues. The upshot is that many firms either turned encryption off entirely or removed it on temporary tables to improve performance. Fortunately there is an option which offers most of the security benefits without the downsides: transparent data encryption. It works underneath the application or database layer to encrypt data before it is stored on disk. It is faster that column encryption, transparent so no application layer changes are required, and avoids the risk of accidentally leaking data. Backups are still protected and you are assured that IT administrators cannot view readable data from disk. We recommend considering products from several application/database vendors and some third-party encryption vendors.

Firewalls & Network Security: If you are running enterprise applications, you have firewalls and intrusion detection systems in place. And likely you also have next-generation firewalls, web application firewalls, and/or data loss prevention systems protecting you applications. Because these investments are already paid for and in place, they tend to be the default answer to any application security question. The law of the instrument states that if all you have is a hammer, everything looks like a nail. The problem is that these platforms are not optimal for enterprise application security, but they are nonetheless considered essential because every current security job falls to them. Unfortunately they do a poor job with application security because most of them were designed to detect and address network misuse, but they do not understand how enterprise applications work. Worse, as we shift ever more toward virtualization and the cloud, physical networks go away, making them less useful in general. But the real issue is that a product which was not designed to understand the application cannot effectively monitor its use or function. We recommend looking at application-specific monitoring tools and application gateways – discussed in the next section – to detect and block application-specific attacks. We do not suggest throwing out your existing investments, but some problems are best addressed in a different fashion, and you need to balance network security against application security to be effective.

Logging and Auditing: You need audit logs for visibility into system usage, covering the areas simple assessments cannot, but many firms only capture the subset of events which are easy to get. Discussing logging with enterprises is difficult because every they all log; unfortunately most do it poorly and don’t want to be reminded of their SIEM and log management headaches. As we mentioned in our discussion of why enterprise applications are different, as a rule application logs were not designed for security and compliance. So many firms leave application logging off, and instead use network logs to seed security systems. There are a couple of reasons not to go this way. First, many platform providers now understand that logs are used for security and audit teams more than for IT, and have adjusted log content and system performance to accomodate this. Second, third-party application and database monitoring systems handle complex data capture and filtering for you. Finally, some complex data types can be captured and correlated with other data to deliver on yesterday’s promises. The available data is improving while the overhead (cost) of collection is shrinking. We see a convergence between the continually dropping cost of storage, improved scalability of SIEM and Log Management systems, and “big data” databases which make roll-your-own collection and analysis clusters feasible at a fraction of the cost of a 2-year-old data warehouse. Our research shows that enterprise security operations centers are collecting both new types of data, and from many more sources, in order to have sufficient information to detect attacks or perform forensic analysis. What was collected just a couple years ago is simply not adequate given current threats. You may feel you have a need to produce better log data for security or compliance, but we want to make clear most of the impediments enterprises had with log data collection are no longer at issue.

Overlooked Elements

Application and Database Monitoring: Monitoring application activity, with full understanding of how that application works, is the most common gap in enterprise security strategies. Application monitoring and database activity monitoring tools, at minimum, capture and record all application activity (including administrator activity) in real time or near real time; across multiple platforms; and alert and/or block on policy violations. The tools remotely monitor application events, collected from a combination of sources, and collected in a central location for analysis. Think of them as an application specific SIEM and IDS combo. They are designed to understand how application platforms work down to the transaction level, with multiple methods (including heuristics, metadata, user behavior, attributes, command whitelists, and command blacklists) available to analyze events. These tools are focused on the application layer, and designed to understand the specific nuances of these platforms to provide more granular and more effective security controls. They work at the application layer so they are typically deployed one of three ways: as an agent on the application platform, as a reverse proxy for the application, or embedded into the application itself. Our recommendation is to use one of these platforms to monitor application events; general-purpose network monitors do not fully understand applications, which causes more of both false positives (false alarms) and false negatives (missed attacks).

API Gateways: In their rush to provide more services in order to promote customer usage and affinity, large enterprises have reimplemented traditional back-office applications to directly support customer-facing web applications. Many enterprise applications, designed and built before the Internet, have been recast as front-line customer-facing services. These platforms provide data and transactional services to support web applications, put their security is often a disaster. Command injection, SQL injection, remote vulnerability exploits, and compromise of administrative accounts are all common. In the last couple years, to support safe access to enterprise application services for remote users – particularly to support mobile applications – several firms have developed API gateways. They offer an abstraction layer which maps back-office application functions to the most common modern programming interface: RESTful APIs. The gateway builds in version control, testing facilities, support for third-party developers, detection of jailbroken devices and other signs of potential fraud, policy support for mobile app usage, integration with internal directory services for provisioning/de-provisioning, and token-based user credentials for improved identity management. If you intend to leverage enterprise applications to support end users we recommend moving past the simple firewall and web filtering security model to API gateways.

Penetration Testing: Penetration testers offer an invaluable service, going outside the box to attack application security and find ways to bypass or break security controls. Most pen tests discover unknown defects in applications or deployments. This approach is so powerful because the tests find issues developers did not even know to look for. Enterprise applications and databases incorporate a great deal of custom code, which naturally includes unique vulnerabilities. Attackers are good at finding these defects, with very powerful software tools to help them. A good tester finds these defects using the same tools, as well as issues you don’t have policies for, possibly examining aspects of security you were not even aware of. Of course people who know what they are doing cost money. But you should test on an ongoing basis anyway. Every time a new version of your application, a new server, or a change to your custom code occurs, you have potential for new vulnerabilities. We are big proponents of penetration testing, and strongly recommend having a service regularly check your sites. That said, there are many good third-party commercial and open source tools available if money is tight and you have expertise on staff.

These enterprise applications security recommendations address both interfaces and internal workings. Shoring up deficiencies with preventative controls, opting for more appropriate security controls, and building in real-time monitoring greatly improve security. We understand that some of these recommendation incrementally add to security or compliance budget, and we are not fans of telling people to “Do more with more.” We appreciate how difficult security budget is to obtain, so we are very sensitive about making these types of recommendations. But the good news is that the majority of our recommendations are for tools that automate existing work, bundling reporting and policies that would otherwise require manual work. And in several cases our recommendations only reallocate where existing budget is spent, using tools more focused on core applications.