Thoughts on Diversity and False Diversity

Mike Bailey highlights a key problem with web applications in his post on diversity. Having dealt with these issues as a web developer (a long time ago), I want to add a little color. We tend to talk about diversity as being good, usually with biological models and discussions of monoculture. I think Dan Geer was the first to call out the dangers of using only a single computing platform, since one exploit then has the capability of taking down your entire organization. But the heterogeneous/homogenous tradeoffs aren’t so simple. Diversity reduces the risk of a catastrophic single point of failure by increasing the attack surface and potential points of failure. Limited diversity is good for something like desktop operating systems. A little platform diversity can keep you running when something very bad hits the primary platform and takes those systems down. The trade off is that you now have multiple profiles to protect, with a great number of total potential vulnerabilities. For example, the Air Force standardized their Windows platforms to reduce patching costs and time. What we need, on the OS side, is limited diversity. A few standard platform profiles that strike the balance between reducing the risk that a single problem will take us completely down, while maintaining manageability through standardization. But back to Mike’s post and web applications… With web applications what we mostly see is false diversity. The application itself is a monolithic entity, but use of multiple frameworks and components only increases the potential attack surface. With desktop operating systems, diversity means a hole in one won’t take them all down. With web applications, use of multiple languages/frameworks and even platforms increases the number of potential vulnerabilities, since exploitation of any one of those components can generally take down/expose the entire application. When I used to develop apps, like every web developer at the time, I would often use a hodgepodge of different languages, components, widgets, etc. Security wasn’t the same problem then it is now, but early on I learned that the more different things I used, the harder it was to maintain my app over time. So I tended towards standardization as much as possible. We’re doing the same thing with our sooper sekret project here at Securosis – sticking to as few base components as we can, which we will then secure as well as we can. What Mike really brings to the table is the concept of how to create real diversity within web applications, as opposed to false diversity. Read his post, which includes things like centralized security services and application boundaries. Since with web applications we don’t control the presentation layer (the web browser, which is a ‘standard’ client designed to accept input from nearly anything out there), new and interesting boundary issues are introduced – like XSS and CSRF. Adrian and I talk about this when we advise clients to separate out encryption from both the application and the database, or use tokenization. Those architectures increase diversity and boundaries, but that’s very different than using 8 languages and widgets to build your web app. Share:

Read Post

A Phish Called Tabby

Thanks to Aza Raskin, this week we learned of a new phishing attack, dubbed “tabnabbing” by Brian Krebs. It opening a tab (unbeknownst to the user), changes the favicon, and does a great job of impersonating a web page – or a bank account, or any other phishing target. Through the magic of JavaScript, the tabs can be controlled and the attack made very hard to detect since it preys on the familiarity of users with common webmail and banking interfaces. So what do you do? You can run NoScript in your Firefox browser and to prevent the JavaScript from running (unless you idiotically allowed JavaScript on a compromised page). Another option is leveraging a password manager. Both Rich and I have professed our love for 1Password on the Mac. 1Password puts a button in your browser, and when logging in brings up a choice of credentials for that specific domain to automatically fill in the form. So when I go to Gmail, logging in is as easy as choosing one of the 4 separate logins I use on domains. Now if I navigate to the phishing site, which looks exactly like Gmail, I’d still be protected. 1Password would not show me any stored logins for that domain, since presumably the phisher must use a different domain. This isn’t foolproof because the phisher could compromise the main domain, host the page there, and then I’m hosed. I could also manually open up 1Password and copy/paste the login credentials, but that’s pretty unlikely. I’d instantly know something was funky if my logins were not accessible, and I’d investigate. Both of these scenarios are edge cases and I believe in a majority of situations I’d be protected. I’m not familiar with password managers on Windows, but if they have similar capabilities, we highly recommend you use one. So not only can I use an extremely long password on each sensitive site, I get some phishing protection as a bonus. Nice. Share:

Read Post

Understanding and Selecting SIEM/LM: Data Collection

The first four posts our the SIEM series dealt with understanding what SIEM is, and what problems it solves. Now we move into how to select the right product/solution/service for your organization, and that involves digging into the technology behind SIEM and log management platforms. We start with the foundation of every SIEM and Log Management platform: data collection. This is where we collect data from the dozens of different types of devices and applications we monitor. ‘Data’ has a pretty broad meaning – here it typically refers to event and log records but can also include flow records, configuration data, SQL queries, and any other type of standard data we want to pump into the platform for analysis. It may sound easy, but being able to gather data from every hardware and software vendor on the planet in a scalable and reliable fashion is incredibly difficult. With over 20 vendors in the Log Management and SIEM space, and each vendor using different terms to differentiate their products, it gets very confusing. In this series we will define vendor-neutral terms to describe the technical underpinnings and components of log data collection, to level-set what you really need to worry about. In fact, while log files are what is commonly collected, we will use the term “data collection”, as we recommend gathering more than just log files. Data Collection Overview Conceptually, data collection is very simple: we just gather the events from different devices and applications on our network to understand what is going on. Each device generates an event each time something happens, and collects the events into a single repository known as a log file (although it could actually be a database). There are only four components to discuss for data collection, and each one provides a pretty straight-forward function. Here are the functional components: Fig 1. Agent data collector Fig 2. Direct connections to the device Fig 3. Log file collection Source: There are many different sources – including applications, operating systems, firewalls, routers & switches, intrusion detection systems, access control software, and virtual machines – that generate data. We can even collect network traffic, either directly from the network for from routers that support Netflow-style feeds. Data: This is the artifact telling us what actually happened. The data could be an event, which is nothing more than a finite number of data elements to describe what happened. For example, this might record someone logging into the system or a service failure. Minimum event data includes the network address, port number, device/host name, service type, operation being performed, result of the operation (success or error code), user who performed the operation, and timestamp. Or the data might just be configuration information or device status. In practice, event logs are pretty consistent across different sources – they all provide this basic information. But each offers additional data, including context. Additional data types may include things such as NetFlow records and configuration files. In practice, most of the data gathered will be events and logs, but we don’t want to arbitrarily restrict our scope. Collector: This connects to a source device, directly or indirectly, to collect the events. Collectors take different forms: they can be agents residing on the source device (Fig. 1), remote code communicating over the network directly with the device (Fig. 2), an agent writing code writing to a dedicated log repository (Fig. 3), or receivers accepting a log file stream. A collector may be provided by the SIEM vendor or a third party (normally the vendor of the device being monitored). Further, the collector functions differently, depending upon the idiosyncrasies of the device. In most cases the source need only be configured once, and events will be pushed directly to the collector or into a neutral log file read by it. In some cases, the collector must continually request data be sent, polling the source at regular intervals. Protocol: This is how collector communicates with the source. This is an oversimplification, of course, but think of it as a language or dialect the two agree upon for communicating events. Unfortunately there are lots of them! Sometimes the collector uses an API to communicate directly with the source (e.g., OPSEC LEA APIs, MS WMI, RPC, or SDEE). Sometimes events are streamed over networking protocols such as SNMP, Netflow, or IPFIX. Sometimes the source drops events into a common file/record format, such as syslog, Windows Event Log, or syslog-ng, which is then read by the collector. Additionally, third party applications such as Lasso and Snare provide these features as a service. Data collection is conceptually simple, but the thousands of potential variations makes implementation a complex mess. It resembles a United Nations meeting: you have a whole bunch of people talking in different languages, each with a particular agenda of items they feel are important, and different ways they want to communicate information. Some are loquacious and won’t shut up, while others need to be poked and prodded just to extract the simplest information. In a nutshell, it’s up to the SIEM and Log Management platforms to act as the interpreters, gathering the information and putting it into some useful form. Tradeoffs Each model for data collection has trade-offs. Agents can be a powerful proxy, allowing the SIEM platform to use robust (sometimes proprietary) connection protocols to safely and reliably move information off devices; in this scenario device setup and configuration is handled during agent installation. Agents can also take full advantage of native device features, and can tune and filter the event stream. But agents have fallen out of favor somewhat. SIEM installations cover thousands of devices, which means agents can be a maintenance nightmare, requiring considerable time to install and maintain. Further, agents’ processing and data storage requirements on the device can affect stability and performance. Finally, most agents require administrative access, which creates am additional security concern on each device. Another common technique streams events to log files, such as syslog or the Windows Event

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.