Research

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

This is a corporate news post, so skip it if all you want is our usual snarky security analysis. For the first time since starting Securosis we are increasing our prices. Yes, it has been over seven years without any change in pricing for our services. The new prices are only a modest bump, and also streamlined to remove the uncertainty of travel expenses on engagements. Call it ego, but we think we are a heck of a bargain. This only affects speaking/strategy days and retainers. Papers, Securosis Project Accelerator workshops, and one-off projects aren’t changing. Strategy day pricing stays the same at $6,000, but we are adding in $1,000 for travel expenses and will no longer bill travel separately (total of $7,000 for a strategy day or speaking engagement which involves travel). Webcasts stay the same, at $5,000 if we don’t need to travel. Our retainer rates are increasing slightly, around $2-3K each, with $2,000 also being added to our Platinum plan to cover the travel for the two included strategy days: $10K for Silver. $15K for Gold. $25K for Platinum. The new pricing goes into effect immediately for all new clients and renewals. As a reminder, for our papers we offer licenses, not sponsorship, so nothing has changed there. Securosis Project Accelerators (our focused end-user workshops for SaaS providers, enterprise cloud security, security management, network security, and database/big data security) are still $10,000. We do have some other workshops in the… works for next year, so if you are interested in another topic just ask. If you have any other questions, just go ahead and email. Service levels remain the same. You can only blame yourselves for keeping us so darn busy. Share:

In the introduction to our series on Monitoring the Hybrid Cloud we went through all the disruptive forces which are increasingly complicating security monitoring. These include the accelerating move to cloud computing and expanding access via mobile devices. Those new models require much greater automation, and significantly less visibility and control over the physical layer of the technology stack. So you need to think about monitoring a bit differently. This starts with getting a handle on the nuances of monitoring, depending on where applications run, so we will discuss monitoring both IaaS (Infrastructure as a Service) and SaaS (Software as a Service). Not that we discriminate against PaaS (Platform as a Service), but it is similar enough to IaaS that the concepts presented are similar. We will also talk about private clouds because odds are you haven’t been able to unplug your data center, so you need to provide an end-to-end view of the infrastructure you use, including both technology you control (in your data center) and stuff you don’t (in the cloud). Monitoring IaaS The biggest and most obvious challenge in monitoring Infrastructure as a Service is the difference in visibility because you don’t control the physical stack. So you are largely restricted to logs provided by your cloud service provider. We see pretty good progress in the depth and granularity available from these cloud log feeds, but you still get much less detail than from devices in your data center. You also cannot tap the network to get actual traffic (packet capture). IaaS vendors offer abstracted networking so many networking features you have come to rely on aren’t available. Depending on the maturity of your security program and incident response process, you may not be doing much packet capture on your environment now, but either way it is no longer an option now in the cloud. We will go into more detail later in this series, but one workaround is to run all traffic through a cloud-based choke point for collection. In essence you perform a ‘man-in-the-middle’ attack on your own network traffic to regain a semblance of the visibility inside your own data center, but that sacrifices much of the architectural flexibility drawing you to the cloud in the first place. You also need to figure out where to both aggregate collected logs (both from the cloud service and from specific instances) and where to analyze them. These decisions hinge on a number of factors including where the technology stacks run, the kinds of analysis to perform, and what expertise is available on staff. We will tackle specific architectural options in our next post. Monitoring SaaS If monitoring IaaS offers a ‘foggy’ view compared to what you see in your own data center, Software as a Service is ‘dark’. You see what the SaaS provider shows you, and that’s it. You have access to neither the infrastructure running your application, nor the data stores that house your data. So what can you do? You can take solace in the fact that many larger SaaS vendors are starting to get the message from angry enterprise clients, and providing an activity feed you can pull into your security monitoring environment. It won’t provide visibility into the technology stack, but you will be able to track what your employees are doing within the service – including administrative changes, record modifications, and login history. Keep in mind that you will need to figure out thresholds and actions to alert on, mostly likely by taking a baseline of activity and then looking for anomalies. There are no out-of-the-box rules to monitor SaaS. And as with IaaS you need to figure out the best place to aggregate and analyze data. Monitoring a Private Cloud Private clouds virtualize your existing infrastructure in your own data center, so you get full visibility, right? Not exactly. You will be able to tap the network within the data center for additional visibility. But without proper access and instrumentation within your private cloud you cannot see what is happening within the virtualized environment. As with IaaS, you can route network traffic within your private cloud through an inspection point, but again that would reduce flexibility substantially. The good news is that many existing security monitoring platforms are rapidly adding the ability to monitor within virtual collection points which run in a variety of private cloud environments. We will address alternatives to extend your existing monitoring environment later in this series. SLAs are your friend As we teach in the CCSK (Certificate of Cloud Security Knowledge) course, you really don’t have much leverage to demand access to logs, events, or other telemetry in a cloud environment. So you will want to exercise whatever leverage you have during the procurement process; document specific logs, access, etc. in your agreements. You will find that some cloud providers (the smaller ones) are much more willing to be contractually flexible than the cloud gorillas. So you will need to decide whether the standard level of logging from the big guys is sufficient for the analysis you need. The key is that once you sign an agreement, what you get is what you get. You will be able to weigh in on product roadmaps and make feature requests, but you know how that goes. CloudSOC If a large fraction of your technology assets have moved into the cloud there is a final use case to consider: moving the collection, analysis, and presentation functions of your monitoring environment into the cloud as well. It may not make much sense to aggregate data from cloud-based resources, and then move the data to your on-premise environment for analysis. More to the point, it is cheaper and faster to keep logs and event data in low-cost cloud storage for future audits and forensic analysis. So you need to weigh the cost and latency of moving data to your in-house monitoring system against running monitoring and analytics in the cloud, in light of the varying pricing models for cloud-based