Building an Enterprise Application Security Program: Security Gaps

This post will discuss the common security domains with enterprise applications, areas where generalized security tools lack the depth to address application and database specific issues, and some advice on how to fill in the gaps. But first I want to announce that Onapsis has asked to license the content of this research series. As always, we are pleased when people like what we write well enough to get behind our work, and encourage our Totally Transparent Research style. With that, on with today’s post! Enterprise applications typically address a specific business function: supply chain management, customer relations management, inventory management, general ledger, business performance management, and so on. They may support thousands of users, tie into many other application platforms, but these are specialized applications with very high complexity. To understand the nuances of these systems, the functional components that comprise an application, how they are configured, and what a transaction looks like to that application takes years of study. Security tools also often specialize as well, focusing on a specific type of analysis – such as malware detection – and applying it in particular scenarios such as network flow data, log files, or binary files. They are generally designed to address threats across IT infrastructure at large; very few move up the (OSI) stack to look at generic presentation or application layer threats. And fewer still actually have any knowledge of specific application functions to understand a complex platform like Oracle’s Peoplesoft of SAP’s ERP systems. Security vendors pay lip service to understanding the application layer, but their competence typically ends at the network service port. Generic events and configuration data outside applications may be covered; internals generally are not. Let’s dig into specific examples: Understanding Application Usage The biggest gap and most pressing need is that most monitoring systems do not understand enterprise applications. To continuously monitor enterprise applications you need to collect the appropriate data and then make sense of it. This is a huge problem because data collection points vary by application, and each platform speaks a slightly different ‘language’. For example platforms like SAP speak in codes. To monitor SAP you need to understand SAP operation codes such as T-codes, and there are a lot of different codes. Second you need to know where to collect these requests – application and database log files generally do not provide the necessary information. As another example most Oracle applications rely heavily on stored procedures to efficiently process data within the database. Monitoring tools may see a procedure name and a set of variables in the user request, but unless you know what operation that procedure performs, you have no idea what is happening. Again you need to monitor the connection between the application platform and the database because audit logs do not provide a complete picture of events; then you need to figure out what the query, code, or procedure request means. Vendors who claim “deep packet inspection” for application security skirt understanding how the application actually works. Many use metadata (including time of day, user, application, and geolocation) collected from the network, possibly in conjunction with something like an SAP code, to evaluate user requests. They essentially monitor daily traffic to develop an understanding of ‘normal’, then attempt to detect fraud or inappropriate access without understanding the task being requested. This is certainly helpful for compliance and change management use cases, but not particularly effective for fraud or misuse detection. And it tends to generate false positive alerts. Products designed to monitor applications and databases actually understand their targeted application, and provide much more precise detection and enforcement. Building application specific monitoring tools is difficult and specialized work. But when you understand the application request you can focus your analysis on specific actions – order entry, for example – where insider fraud is most prevalent. This speeds up detection, lessens the burden of data collection, and makes security operations teams’ job easier. Application Composition Throughout this research we use the term ‘database’ a lot. Databases provide the core storage, search, and data management features for applications. Every enterprise application relies on a database of some sort. In fact databases are complex applications themselves. To address enterprise application security and compliance you must address many issues and requirements for both the and the application platforms. Application Deployments We seldom see two instances of the same application deployed the same. They are tailored to each company’s needs, with configuration and user provisioning to support specific requirements. This complicates configuration and vulnerability scanning considerably. What’s more, application and database assessment scans are very different from typical OS and network assessments, requiring different evaluation criteria to assess suitability. The differences lie in both how information is collected, and the depth and breadth of the rule set. All assessment products examine software revision levels, but generic assessment tools stop at list vulnerabilities and known issues, based exclusively on software versions. Understanding an application’s real issues requires a deeper look. For example test and sample applications often introduce back doors into applications, which attackers then exploit. Software revision level cannot tell you what risks are posed by vulnerable modules; only a thorough analysis of a full software manifest can do that. Separation of duties between application, database, and IT administrators cannot be determined by scanning a network port or even hooking into LDAP – it requires interrogation of applications and persistent data storage. Network configuration deficiencies, weak passwords and public accounts, all easily spotted by traditional scanners – provided they have a suitable policy to check – but scanners do not discover data ownership rights, user roles, whether auditing is enabled, unsafe file access rights, or dozens of other well-known issues. Data collection is the other major difference. Most assessment scans offer a basic network port scanner – for cases where agents are inappropriate – to interrogate the application. This provides a quick, non-invasive way to discover basic patch information. Application assessment scanners look for application specific settings, both on disk

Read Post

Incite 11/5/2014: Be Like Water

You want it and you want it now. So do I. Whatever it is. We live in an age of instant gratification. You don’t need to wait for the mailman to deliver letters – you get them via email. If you can’t wait the 2 days for Amazon Prime shipping, you order it online and pick it up at one of the few remaining brick and mortar stores. Record stores? Ha! Book stores? Double ha!! We live in the download age. You want it, you buy it (or not), and you download it. You have it within seconds. But what happens when you don’t get what you want or (egads!) when you have to wait? You are disappointed. We all are. We get locked into that thing. It’s the only outcome we can see. Maybe it’s a thing, maybe it’s an activity. Maybe it’s a reaction from someone, or more money, or a promotion. It could be anything, but you want it and you get pissy when you don’t get it – now! The problem comes down to attachment. Disappointment happens when you don’t get the desired outcome in the timeframe you want. Disappointment leads to unhappiness, which leads to sickness, and so it goes. I have made a concerted effort to stop attaching myself to specific outcomes. Sure, there are goals I have and things I want to achieve. But I no longer give myself a hard time when I don’t attain them. I don’t consider myself a failure when things don’t go exactly as I plan. At least I try not to… But I was struggling to find an analogy to rely on for this philosophy, until earlier this week. I was in a discussion in a private Facebook group, and I figured out the concept in a way I can easily remember and rely on when my mind starts running amok. I think many of us fall into the trap of seeing a desirable outcome and getting attached to that. I know I do. I’m trying to flow like water. Water doesn’t care where it ends up. It goes along the path the provides the least resistance at any given time. Not that we don’t need resistance from time to time to grow, rather we need to be flexible to adapt to the reality of the moment. Be like water. Water takes the shape of whatever vessel it’s in. Water flows. Water has no predetermined goal and can change form as needed. As the waves crash they show the awesome power of harnessed water. The analogy also works for me because I like being by the water, and the sound of water calms me. But I am not the only one who likes the water. Bruce Lee figured this out way before me and talked about it in this classic interview. Maybe the concept works for you, and maybe it doesn’t. It’s fine either way for me – I’m not attached to a particular outcome… –Mike Photo credit: “The soothing sound of flowing water” originally uploaded by Ib Aarmo The fine folks at the RSA Conference posted the talk Jennifer Minella and I did on mindfulness at the conference this year. You can check it out on YouTube. Take an hour and check it out. Your emails, alerts and Twitter timeline will be there when you get back. Securosis Firestarter Have you checked out our new video podcast? Rich, Adrian, and Mike get into a Google Hangout and.. hang out. We talk a bit about security as well. We try to keep these to 15 minutes or less, and usually fail. October 27 – It’s All in the Cloud October 6 – Hulk Bash September 16 – Apple Pay August 18 – You Can’t Handle the Gartner July 22 – Hacker Summer Camp July 14 – China and Career Advancement June 30 – G Who Shall Not Be Named June 17 – Apple and Privacy May 19 – Wanted Posters and SleepyCon May 12 – Another 3 for 5: McAfee/OSVDB, XP Not Dead, CEO head rolling Heavy Research We are back at work on a variety of blog series, so here is a list of the research currently underway. Remember you can get our Heavy Feed via RSS, with our content in all its unabridged glory. And you can get all our research papers too. Monitoring the Hybrid Cloud: Evolving to the CloudSOC Introduction Building an Enterprise Application Security Program Introduction Use Cases Security and Privacy on the Encrypted Network The Future is Encrypted Secure Agile Development Deployment Pipelines and DevOps Building a Security Tool Chain Process Adjustments Working with Development Agile and Agile Trends Introduction Newly Published Papers Trends in Data Centric Security Leveraging Threat Intelligence in Incident Response/Management The Security Pro’s Guide to Cloud File Storage and Collaboration The 2015 Endpoint and Mobile Security Buyer’s Guide Open Source Development and Application Security Analysis Advanced Endpoint and Server Protection Defending Against Network-based DDoS Attacks The Future of Security Incite 4 U Shiny attack maps for everyone: I hand it to Bob Rudis and Alex Pinto for lampooning vendors’ attack maps. They have issued an open source attack map called IPew, which allows you to build your own shiny map to impress your friends and family. As they describe it, ‘IPew is an open source “live attack map” simulation built with D3 (Datamaps) that puts global cyberwar just a URL or git clone away for anyone wanting to display these good-for-only-eye-candy maps on your site.’ Humor aside, visualization is a key skill, and playing around with their tool may provide ideas for how you can present data in a more compelling way within your own shop. So it’s not all fun and games, but if you do need some time to decompress, set IPew to show the Internet having a bad day… War Games FTW. – MR Not for what you think: Occasionally we need to call BS on a post, and Antone Gonsalves on Fraudster Protection

Read Post

Totally Transparent Research is the embodiment of how we work at Securosis. It’s our core operating philosophy, our research policy, and a specific process. We initially developed it to help maintain objectivity while producing licensed research, but its benefits extend to all aspects of our business.

Going beyond Open Source Research, and a far cry from the traditional syndicated research model, we think it’s the best way to produce independent, objective, quality research.

Here’s how it works:

  • Content is developed ‘live’ on the blog. Primary research is generally released in pieces, as a series of posts, so we can digest and integrate feedback, making the end results much stronger than traditional “ivory tower” research.
  • Comments are enabled for posts. All comments are kept except for spam, personal insults of a clearly inflammatory nature, and completely off-topic content that distracts from the discussion. We welcome comments critical of the work, even if somewhat insulting to the authors. Really.
  • Anyone can comment, and no registration is required. Vendors or consultants with a relevant product or offering must properly identify themselves. While their comments won’t be deleted, the writer/moderator will “call out”, identify, and possibly ridicule vendors who fail to do so.
  • Vendors considering licensing the content are welcome to provide feedback, but it must be posted in the comments - just like everyone else. There is no back channel influence on the research findings or posts.
    Analysts must reply to comments and defend the research position, or agree to modify the content.
  • At the end of the post series, the analyst compiles the posts into a paper, presentation, or other delivery vehicle. Public comments/input factors into the research, where appropriate.
  • If the research is distributed as a paper, significant commenters/contributors are acknowledged in the opening of the report. If they did not post their real names, handles used for comments are listed. Commenters do not retain any rights to the report, but their contributions will be recognized.
  • All primary research will be released under a Creative Commons license. The current license is Non-Commercial, Attribution. The analyst, at their discretion, may add a Derivative Works or Share Alike condition.
  • Securosis primary research does not discuss specific vendors or specific products/offerings, unless used to provide context, contrast or to make a point (which is very very rare).
    Although quotes from published primary research (and published primary research only) may be used in press releases, said quotes may never mention a specific vendor, even if the vendor is mentioned in the source report. Securosis must approve any quote to appear in any vendor marketing collateral.
  • Final primary research will be posted on the blog with open comments.
  • Research will be updated periodically to reflect market realities, based on the discretion of the primary analyst. Updated research will be dated and given a version number.
    For research that cannot be developed using this model, such as complex principles or models that are unsuited for a series of blog posts, the content will be chunked up and posted at or before release of the paper to solicit public feedback, and provide an open venue for comments and criticisms.
  • In rare cases Securosis may write papers outside of the primary research agenda, but only if the end result can be non-biased and valuable to the user community to supplement industry-wide efforts or advances. A “Radically Transparent Research” process will be followed in developing these papers, where absolutely all materials are public at all stages of development, including communications (email, call notes).
    Only the free primary research released on our site can be licensed. We will not accept licensing fees on research we charge users to access.
  • All licensed research will be clearly labeled with the licensees. No licensed research will be released without indicating the sources of licensing fees. Again, there will be no back channel influence. We’re open and transparent about our revenue sources.

In essence, we develop all of our research out in the open, and not only seek public comments, but keep those comments indefinitely as a record of the research creation process. If you believe we are biased or not doing our homework, you can call us out on it and it will be there in the record. Our philosophy involves cracking open the research process, and using our readers to eliminate bias and enhance the quality of the work.

On the back end, here’s how we handle this approach with licensees:

  • Licensees may propose paper topics. The topic may be accepted if it is consistent with the Securosis research agenda and goals, but only if it can be covered without bias and will be valuable to the end user community.
  • Analysts produce research according to their own research agendas, and may offer licensing under the same objectivity requirements.
  • The potential licensee will be provided an outline of our research positions and the potential research product so they can determine if it is likely to meet their objectives.
  • Once the licensee agrees, development of the primary research content begins, following the Totally Transparent Research process as outlined above. At this point, there is no money exchanged.
  • Upon completion of the paper, the licensee will receive a release candidate to determine whether the final result still meets their needs.
  • If the content does not meet their needs, the licensee is not required to pay, and the research will be released without licensing or with alternate licensees.
  • Licensees may host and reuse the content for the length of the license (typically one year). This includes placing the content behind a registration process, posting on white paper networks, or translation into other languages. The research will always be hosted at Securosis for free without registration.

Here is the language we currently place in our research project agreements:

Content will be created independently of LICENSEE with no obligations for payment. Once content is complete, LICENSEE will have a 3 day review period to determine if the content meets corporate objectives. If the content is unsuitable, LICENSEE will not be obligated for any payment and Securosis is free to distribute the whitepaper without branding or with alternate licensees, and will not complete any associated webcasts for the declining LICENSEE. Content licensing, webcasts and payment are contingent on the content being acceptable to LICENSEE. This maintains objectivity while limiting the risk to LICENSEE. Securosis maintains all rights to the content and to include Securosis branding in addition to any licensee branding.

Even this process itself is open to criticism. If you have questions or comments, you can email us or comment on the blog.