Friday Summary: September 10, 2010

I attended the OWASP Phoenix chapter meeting earlier this week, talking about database encryption. The crowd was small as the meeting was the Tuesday after Labor day, rather than the normal Thursday slot. Still, I had a good time, especially with the discussion afterwards. We talked about a few things I know very little about. Actually, there are several areas of security that I know very well. There are a few that I know reasonably well, but as I don’t practice them day to day I really don’t consider myself an expert. And there are several that I don’t know at all. And I find this odd, as it seemed that 15 years ago a single person could ‘know’ computer security. If you understood netword security, access controls, and crypto, you had a pretty good handle on things. Throw in some protocol design, injection, and pen test concepts and you were a freakin’ guru. Given the handful of people at the OWASP meeting, there were diverse backgrounds in the audience. After the presentation we were talking about books, tools, and approaches to security. We were talking about setting up labs and CTF training sessions. Somewhere during the discussion it dawned on me just how much things have changed; there are a lot of different subdisciplines in computer security. Earlier this week Marcus Carey (@marcusjcarey) tweeted “There is no such thing as a Security Expert”, which I have to grudgingly admit is probably true. Looking across the spectrum we have everything from reverse engineering malware to disk drive forensics. It’s reached a point where it’s impossible to be a ‘security’ expert, rather you are an application security expert, or a forensic auditor, or a cryptanalyst, or some other form of specialist. We’ve undergone several evolutionary steps in understanding how to compromise computer systems, and there are a handful of signs we are getting better at addressing bad security. The depth of research and knowledge in the field of computer security has progressed at a staggering rate, which keeps things interesting and means there is always something new to learn. With Rich in Babyland, the Labor Day holiday, and me travelling this week, you’ll have to forgive us for the brevity of this week’s summary: Webcasts, Podcasts, Outside Writing, and Conferences Seven Features To Look For In Database Assessment Tools. Adrian’s Dark Reading post. Favorite Securosis Posts Adrian Lane: Market For Lemons. Mike Rothman: This week’s Incite: Iconoclastic Idealism. Yes, voting for myself is lame, but it’s a good piece. Will be hanging on my wall as a reminder of my ideals. Other Securosis Posts New Release: Data Encryption 101 for PCI. Understanding and Selecting an Enterprise Firewall: Technical Architecture, Part 1. Understanding and Selecting an Enterprise Firewall: Application Awareness, Part 2. Favorite Outside Posts Adrian Lane: Interview Questions. I know it’s a week old, but I just saw it, and some of it’s really funny. Mike Rothman: Marketing to the Bottom of the Pyramid. We live a cloistered, ridiculously fortunate existence. Godin provides interesting perspective on how other parts of the world buy (or don’t buy) innovation. Project Quant Posts NSO Quant: Take the Survey and Win an iPad. NSO Quant: Manage IDS/IPS Process Revisited. NSO Quant: Manage IDS/IPS – Monitor Issues/Tune. Research Reports and Presentations Data Encryption 101: A Pragmatic Approach to PCI. White Paper: Understanding and Selecting SIEM/Log Management. White Paper: Endpoint Security Fundamentals. Top News and Posts IE 8 Bug. Vuln popped up late last Friday. Adobe Patches via Brian Krebs. Apple OS X Security Patch. Blog Comment of the Week Remember, for every comment selected, Securosis makes a $25 donation to Hackers for Charity. This week’s best comment goes to ds, in response to FireStarter: Market for Lemons. I guess this could be read both ways… more insight as would be gained from researchers could help shift the ballance of information to the consumer, but it could also confirm the conclusion that a product was low quality. I don’t know of any related research that shows that consumer information helps improve consumer outcomes, though that would be interesting to see. Does anyone know if the “security seal” programs actually improve user’s perceptions? And do those perceptions materialize in greater adoption? Also may be interesting. I don’t think we need something like lemon laws for two reasons: 1) The provable cost of buying a bad product for the consumer is nominal; not likely to get any attention. The cost of the security product failing are too hard to quantify into actual numbers so I am not considering these. 2) Corporations that buy the really expensive security products have far more leverage to conduct pre-purchase evaluations, to put non-performance clauses into their contracts and to readily evaulate ongoing product suitability. The fact that many don’t is a seperate issue that won’t in any case be fixed by the law. Share:

Read Post

Understanding and Selecting an Enterprise Firewall: Deployment Considerations

Now that we’ve been through technical architecture considerations for the evolving firewall (Part 1, Part 2), let’s talk about deployment considerations. Depending on requirements, there many different ways to deploy enterprise firewalls. Do this wrong and you end up with either too many or too few boxes, single points of failure, suboptimal network access, and/or crappy application performance. We could talk about all sorts of different models and use fancy names like tiered, mesh, peer to peer, and the like for them – but fortunately the situation isn’t really that complicated. To choose the most appropriate architecture you must answer a few questions: Public or Private Network? Are your remote locations all connected via private connections such as MPLS or managed IP services, or via public Internet services leveraging site-to-site VPN tunnels? How much is avoiding downtime worth? This fairly simple question will drive both network architecture and perimeter device selection. You can implement high availability architectures to minimize the likelihood of downtime but the cost is generally significant. What egress filtering/protection do you need? Obviously you want to provide web and email filtering on outbound traffic. Depending on bandwidth availability and cost, it may make sense to haul that back to a central location to be processed by large (existing) content security gateways. But for bandwidth-constrained sites it may make more sense to do web/email filtering locally (using a UTM box), with the understanding that filtering at the smaller sites might be less sophisticated. Who controls gateway policy? Depending on the size of your organization, there may be different policies for different geographies, business units, locations, etc. Some enterprise firewall management consoles support this kind of granular policy distribution, but you need to figure out who will control policy, and use this to guide how you deploy the boxes. Remember the technical architecture post where we pointed out the importance of consistency. A consistent feature set on devices up and down a vendor’s product line provides a lot of flexibility in how you can deploy – this enables you to select equipment based on the throughput requirement rather than feature set. This is also preferable because application architectures and requirements change, and support for all features on branch equipment (even if you don’t initially expect to use them) saves deploying new equipment remotely if you decide to take advantage of those features later, but we recognize this is not always possible. Economic reality rears its head every so often. Bandwidth Matters We most frequently see tiers of firewalls implemented in either two or three tiers. Central sites (geographic HQ) get big honking firewalls deployed in a high-availability cluster configuration to ensure resilience and throughput – especially if they provide higher-level application and/or UTM features. Distribution locations, if they exist, are typically connected to the central site via a private IP network. These tend to be major cities with good bandwidth. With plentiful bandwidth, most organizations tend to centralize egress filtering to minimize the control points, so outbound traffic tends to be centralized through the central site. With smaller locations like stores, or in emerging countries with expensive private network options, it may make more economic sense to use public IP services (commodity Internet access) with site-to-site VPN. In this case it’s likely not performance (or cost) effective to centralize egress filtering, so these firewalls generally must do the filtering as well. Regardless of the egress filtering strategy you should have a consistent set of ingress policies in place, which usually means (almost) no traffic originating from the Internet is accepted: a default deny security posture. Most organizations leverage hosting providers for web apps, which allow tight rules to be placed on the perimeter for inbound traffic. Likewise, allowing inbound Internet traffic to a small location usually doesn’t make sense, since those small sites shouldn’t be directly serving up data. Unless you are cool with tellers running their Internet-based side businesses on your network. High Availability Clusters Downtime is generally a bad thing – end users can get very grumpy when they can’t manage their fantasy football teams during the work day – so you should investigate the hardware resilience features of firewall devices. Things like hot swappable drives and power supplies, redundant backplanes, multiple network connections, redundant memory, etc. Obviously the more redundancy built into the box, the more it will cost, but you already knew that. Another option is to deploy a high availability cluster. Basically, this means you’ve got two (or more) boxes using sharing a single configuration, allowing automated and transparent load balancing between them to provide stable the performance and ride out any equipment failures. So if a box fails its peer(s) transparently pick up the slack. High availability and clustering used to be different capabilities (and on some older firewall architectures, still are). But given the state of the hardware and maturity of the space, the terminology has evolved to active/active (all boxes in the cluster process traffic) and active/passive (some boxes are normally hot spares, not processing traffic). Bandwidth requirements tend to drive whether multiple gateways are active, but the user-visible functioning is the same. Internal Deployment We have mostly discussed the perimeter gateway use case. But there is another scenario, where the firewall is deployed within the data center or at distribution points in the network, and provides network segmentation and filtering. This is a bit different than managing inbound/outbound traffic at the perimeter, and largely driven by network architecture. The bandwidth requirements for internal devices are intense – typically 40-100gbps and here downtime is definitely a no-no, so provision these devices accordingly and bring your checkbook. Migration The final issue we’ll tackle in relation to deployment is getting old boxes out and new boxes in. Depending on the size of the environment, it may not be feasible to do a flash cutover. So the more the new vendor can do to assist in the migration, the better. Fortunately the market is mature enough that many vendors can read in their competitors’

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.