Research

I am sitting on the porch reading a Sybase ASE document on transparent database encryption, so it’s ironic that a few minutes ago I got word that SAP bought Sybase for $5.8 billion. SAP posted a press release. This announcement is right on the heels of their partnership announcement last March. It’s been my feeling for several years now that relational databases have been on a steady retreat back into the core of the enterprise, from whence they came. Smaller, modular, more agile repositories are in vogue for everything outside enterprise IT data centers. They are easier and more accessible to developers, and they are free. I bring this up because this is one of the ways Sybase has been squeezed out of the enterprise relational database market. Let’s be honest – people looking for a new database now either go cheap and select a PostgreSQL / MySQL platform, or pay for the name brand / stack synergy / bundled pricing discounts for Oracle or IBM. Sybase has been steadily growing over the last five years due to new product offerings, but they remain something of an afterthought in the enterprise database market. Sybase does not enter into the discussion of new database sales, so they rely on keeping their current installed base happy and growth of their mobile offerings. And it’s not easy to succeed with Oracle undercutting them on price and IBM going after all their hardware vendor relationships. SAP levels the playing field for Sybase, putting them in a position to grow and get visibility with a larger body of prospects. Sybase gives SAP a technologically current database platform, an analytics engine, mobile data/device support and some other tools. Honestly, many of us had been wondering how long it would be before someone like SAP bought them. Sybase could not compete head to head in the relational database space without this relationship – not because of the technology, but due to customer preference to reduce risk by buying from stable providers. I really hate saying it, but the purchase legitimizes Sybase products and viability. An established company with over a billion in revenue should not need such endorsements, but when competing with Oracle and IBM, they do. Share:

I wrote last Monday’s FireStarter on Process and Peer Pressure because there were a few things bothering me that I needed to get out of my system, but I saved a lot for later. I didn’t really intend to write this followup so soon, but I saw that Cisco announced their own Software Development Lifecycle. I wanted to make some statements on SDL later this year when I begin publishing more concrete Secure Software Development Lifecycle (SSDL in Securosis parlance, SDL for most organizations) guidelines, but Cisco’s announcement changes things. I worry that sheer inertia will prompt the industry as a whole to rubber-stamp SDLs. Before you know it, HR reps will be including “SDL certification” requirements on every engineering job description, without a clue what they are demanding or why, so let’s stop this train before it runs too far off the tracks. If you are thinking about incorporating Secure Development Lifecycle practices for software development, that’s great. If you have read about Microsoft’s SDL, witnessed Microsoft’s success, seen Cisco’s endorsement, and believe their model will work for you, just stop. It’s not going to work for you. It’s based on a lot of factors and assumptions that do not pertain to you. It’s not a template for your requirements. Adopting MS-SDL wholesale is a little like a child putting on adult clothes because they want to be ‘big’. You cannot drop that particular process into your development organization and have it fit. More likely you will break everything. Your team will need to change their skills and priorities, and though it sounds cliche, people are resistant to change. Existing processes need to be adjusted to accommodate secure development processes and techniques. You will need new tools, or to augment existing ones. You will need a whole new class of metrics and tracking. And everything you pick the first time will need several iterations of alteration and adjustment before you get it right – this isn’t Microsoft’s first attempt either. It’s not that the SDL is bad – it isn’t. Microsoft did an excellent job with their SDL. It’s very well thought out, incorporates most effective defect detection techniques, has clearly evolved through several revisions, and includes intelligent tradeoffs in places where there is no single ‘right’ answer. But it is their SDL, not yours. If you take the SDL Microsoft has described and try to implement it, you will fail. I am talking to the 99% of people out there who would think about implementing SDL and think “Hey, Microsoft published this new thingie for free; let’s use it and save ourselves the time and money!” Wrong. Here’s why: Too Big: This process is geared for very large firms, with lots of resources, and a genuine desire to get better. You may not need all of it and frankly it would be overwhelming to start with. This is huge – I mean really huge. You are not going to swallow this elephant in a single gulp. Organic Evolution: Microsoft’s success is not just the introduction of process and techniques. It was not just hiring a handful of really good people and helping to educate the development staff. The MS-SDL reflects several years of focused evolution, and in software that is a lot. They spent a long time looking at the code and figuring out what was wrong. They developed their own tools to help discover problems. They developed software to help track their progress and provide metrics to demonstrate what worked and what did not. They evolved their own threat modeling. They tried, revised, fixed and re-implemented most of what they do several times over. Don’t think their publishing a guide can save you this pain – it cannot. Resources: People, Tools, and Time are the three classic resources you have when you build code. Resources are scare. Always. OK, if you have billions of dollars in the bank, or you are a bank, you might not be quite as pinched for resources. But developing quality code is expensive. Microsoft had the money to hire some of the best people, to buy or build the best tools, a willingness to take additional time for security before releasing software, and then hire some more of the best people. Your developers work nights and weekends to get the release out the door and collapse in a heap, dreaming about all the things they wanted to do before the code was released. Cisco? Yeah, they can do this. You? You don’t have the resources to do everything, so you need to pick and choose. Appropriateness of Techniques: Your program calls for white box testing. Great, but you don’t own critical code you rely on. You leverage open source where you can get code, but off-the-shelf software and even Microsoft tools do not provide source code. If you have four thousand web pages, and most of them don’t filter input values, do you really think you are going to fix this in the current release cycle, or are you going to deploy a WAF? If you are starting an application from scratch, your first step will be threat modeling. If you have a huge existing application, forget threat modeling for now – pen testing is probably much more effective and efficient. And it’s not just which techniques, but how you use them. Within all these techniques, there are many variations and supporting requirements that need tweaking so they can work for you. We discuss these tradeoffs in the Use Case portion of Understanding and Selecting a Web Application Security Program white paper, but the point is that the right choice for you is different than the right choice for Microsoft or Cisco, and you can’t discover what’s right for your environment by reading their SDLs. Do what Microsoft did, not what they do: Using the SDL as your program is a really bad thing to do. I really hope people don’t take this as a slam against Microsoft – my point is

I spend a heck of a lot of time researching, writing, and speaking about data security. One area that’s been very disappointing is the quality of many of the surveys. Most either try to quantify losses (without using a verifiable loss model), measure general attitudes to inspire some BS hype press release, or assess some other fuzzy aspect you can spin any way you want. This bugs me, and it’s been on my to-do list to run a better survey myself. When a vendor (Imperva) proposed the same thing back at RSA (meaning we’d have funding) and agreed to our Totally Transparent Research process, it was time to promote it to the top of the stack. So we are kicking off our first big data security study. Following in the footsteps of the one we did for patch management, this survey will focus on hard metrics – our goal is to avoid general attitude and unquantifiable loss guesses, and focus on figuring out what people are really doing about data security. As with all our surveys, we are soliciting ideas and feedback before we run it, and will release all the raw results. Here are my initial ideas on how we might structure the questions: We will group the questions to match the phases in the Pragmatic Data Security Cycle, since we need some structure to start with. For each phase, we will list out the major technologies and processes, then ask which one organizations have adopted. For technologies, we will ask which they’ve researched, budgeted for, purchased, deployed in a limited manner (such as testing), deployed in initial production, and deployed in full production (organization wide). For processes, we will ask about maturity from ad-hoc through fully formalized and documented, similar to what we did for patch management. For the tools and processes, we’ll ask if they were implemented due to a specific compliance deficiency during an assessment. I’m also wondering if we ask should how many breaches or breach disclosures were directly prevented by the tool (estimates). I’m on the fence about this, because we would need to tightly constrain the question to avoid the results being abused in some way. Those are my rough ideas – what do you think? Anything else you want to see? Is this even in the right direction? And remember – raw (anonymized) results will be released, so it’s kind of like your chance to run a survey and have someone else bear the costs and do all the work… FYI The sponsor gets an exclusive on the raw results for 45 days or so, but they will be released free after that. We have to pay for these things somehow. Share:

Yesterday I finished up a presentation for the Secure360 Conference: “Putting the Fun in Dysfunctional – How the Security Industry Works, and Why It’s Your Fault”. This is a combination of a bunch of things I’ve been thinking about for a while, mostly focused on cognitive science and economics. Essentially, security makes a heck of a lot more sense once you start trying to understand why people make the decisions they do, which is a combination of their own internal workings and external forces. Since it’s very hard to change how people think (in terms of process, not opinion), the best way to induce change is to modify the forces that drive their decision making. I have a section in the presentation on cognitive bias, which is our tendency to make errors in judgement due to how our brains work. It’s pretty fascinating stuff, and essential knowledge for anyone who wants to improve their critical thinking. Here are some examples relevant to the practice of security (from Wikipedia): Framing by using a too-narrow approach and description of the situation or issue. Hindsight bias, sometimes called the “I-knew-it-all-along” effect, is the inclination to see past events as being predictable. Confirmation bias is the tendency to search for or interpret information in a way that confirms one’s preconceptions – this is related to cognitive dissonance. Self-serving bias is the tendency to claim more responsibility for successes than failures. It may also manifest itself as a tendency for people to evaluate ambiguous information in a way beneficial to their interests. Bandwagon effect: the tendency to do (or believe) things because many other people do (or believe) the same. Related to groupthink, herd behavior, and mania. Base rate fallacy: ignoring available statistical data in favor of particulars. Focusing effect: prediction bias which occurs when people place too much importance on one aspect of an event – this causes errors when attempting to predict the utility of a future outcome. Loss aversion: “the disutility of giving up an object is greater than the utility associated with acquiring it”. Outcome bias: the tendency to judge a decision based its eventual outcome, rather than by the information available when it was made. Post-purchase rationalization: the tendency to persuade oneself that a purchase was a good value. Status quo bias: our preference for to stay the same (see also loss aversion and endowment effect). Zero-risk bias: preference for reducing a small risk to zero, over a greater reduction in a larger risk. Cognitive bias also has interesting ties to logical fallacies, another essential area for any good security pro or skeptic. Not that understanding psychology and economics solves all our problems, but they sure help reduce the frustration. And applied to ourselves, understanding can really improve our ability to analyze information and make decisions. Cool stuff. On to the Summary: Webcasts, Podcasts, Outside Writing, and Conferences Rich on the Digital Underground podcast with Dennis Fisher. Favorite Securosis Posts Rich: Thoughts on Data Breach History. I sort of have a thing for history… when you look at the big picture, sometimes things become obvious. Adrian Lane: You Should Ignore the NetworkWorld DLP Review. Nice. David Mortman: Firestarter: For Secure Code, Process Is a Placebo; It’s All about Peer Pressure! Other Securosis Posts Help Build the Mother of All Data Security Surveys. Download Our Kick-Ass Database Encryption and Tokenization Paper. Database Security Fundamentals: Encryption. Understanding and Selecting SIEM/LM: Use Cases, Part 2. Optimism and Cautions on OpenDLP. Understanding and Selecting SIEM/LM: Use Cases, Part 1. Favorite Outside Posts Rich: 2010 DBIR to include cases from U.S. Secret Service This is simply awesome! The Secret Service is analyzing all their cases from the past couple years using Verizon’s framework. This is a gold mine for those of us who care about real world security (disclosure – I’m on the board of the VERIS project for Verizon, but I am not compensated in any way). Adrian Lane: What Egress Filters Should I Use? Branden Williams offers a pragmatic discussion of egress filtering. Project Quant Posts DB Quant: Planning Metrics (Part 1) Research Reports and Presentations Understanding and Selecting a Database Encryption or Tokenization Solution. Low Hanging Fruit: Quick Wins with Data Loss Prevention. Top News and Posts Vuln Disclosure is Rude. Open letter to Facebook on privacy (Noticing a trend this week?). OMB issues new rules on IT security. Penetration Testing in the Real World. How Assumptions May Be Making Us All Less Secure. (Almost made my favorite of the week). Six Things You Need to Know About Facebook Connections. Didier Stevens on PDF Hacking and Security. Facebook disables chat after security hole discovered. DNSSEC on all root servers. Turning Stolen Credit Cards to Cash. Making dreams come true. God, I love online payment scams! The Cisco Secure Development Lifecycle: An Overview. I did not expect to see a secure development cycle coming from Cisco. Review to come. Regular expression sandboxing. An interesting discussion, albeit a little more technical, on the use of regex to parse / match JavaScript. Rethinking the Cyber Threat – A Microsoft paper. Feds Thwart Alleged ATM Hacking Spree. Cash machine reprogramming. More creative than skimming. Opera Plugs ‘Extremely Severe’ Security Hole. Encryption Can’t Stop The Wiretapping Boom. Former Ars Technica Forum Host Compromised. 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 Betsy Nichols, in response to Thoughts on Data Breach History. Very interesting presentation. The OSF is doing amazing work in two areas: data breaches and vulnerabilities. It is amazing what they have accomplished with a volunteer community. They are definitely a worthwhile cause that merits broad support from all of us who benefit from their work. You and other interested folks in the Securosis community may be interested in some of the quantitative analysis I have done using the OSF DataLossDB. You can see it at www.metricscenter.net. (No login necessary.) Just go to the Dashboards area of the site.

It’s kind of weird, but our first white paper to remain unsponsored is also the one I consider our best yet. Adrian and I have spent nearly two years pulling this one together – with more writes, re-writes, and do-overs than I care to contemplate. We started with a straight description of encryption options, before figuring out that it’s all too complex, and what people really need is a better way to make sense of the options and figure out which will work best in their environments. So we completely changed our terminology, and came up with an original way to describe and approach the encryption problem – we realized that deciding how to best encrypt a database really comes down to managing credentialed vs. non-credentialed users. Then, based on talking with users & customers, we noticed that tokenization was being thrown into the mix, so we added it to the “decision tree” and technology description sections. And to help it all make sense, we added a bunch of use cases (including a really weird one based on an actual situation Adrian found himself in). We are (finally) pretty darn happy with this report, and don’t want to leave it in a drawer until someone decides to sponsor. On the landing page you can leave comments, or you can just download the paper. We could definitely use some feedback – we expect to update this material fairly frequently – and feel free to spread the word… Share:

I’ve been writing about data breaches for a long time now – ever since I received my first notification (from egghead.com) in 2002. For about 4 or 5 years now I’ve been giving various versions of my “Involuntary Case Studies in Data Breaches” presentation, where we dig into the history of data breaches and spend time detailing some of the more notable ones, from breach to resolution. 2 weeks ago I presented the latest iteration at the Source Boston conference (video here), and it is materially different than the version I gave at the first Source event. I did some wicked cool 3D visualization in the presentation, making it too big to post, so I thought I should at least post some of the conclusions and lessons. (I plan to make a video of the content, but that’s going to take a while). Here are some interesting points that arise when we look over the entire history of data breaches: Without compliance, there are no economic incentives to report breaches. When losing personally identifiable information (PII) the breached entity only suffers losses from fines and breach reporting costs. The rest of the system spreads out the cost of the fraud. For loss of intelectual property, there is no incentive to make the breach public. Lost business is a myth. Consumers rarely change companies after a breach, even if that’s what they claim when responding to surveys. I know of no cases where a lost laptop, backup tape, or other media resulted in fraud, even though that’s the most commonly reported breach category. Web application hacking and malware are the top categories for breaches that result in fraud. SQL injection using xp_cmdshell was the source of the biggest pre-TJX credit card breach (CardSystems Solutions in 2004: 40 million transactions). This is the same technique Albert Gonzales used for Heartland, Hannaford, and a handful of other companies in 2008. We never learn, even when there are plenty of warning signs. Our controls are poorly aligned with the threat – for example, nearly all DLP deployments focus on email, even though that’s one of the least common vectors for breaches and other losses. The more a company tries to spin and wheedle out of a breach, the worse the PR (and possibly legal) consequences. We will never be perfect, but most of our security relies on us never making a mistake. Defense in depth is broken, since every layer is its own little spear to the heart. Most breaches are discovered by outsiders – not the breached company (real breaches, not lost media). The history is pretty clear – we have no chance of being perfect, and since we focus too much on walls and not not enough on response, the bad guys get to act with near impunity. We do catch some of them, but only in the biggest breaches and mostly due to greed and mistakes (just like meatspace crime). If you think this is interesting, I highly recommend you support the Open Security Foundation, which produces the DataLossDB. I found out only a handful of hard-working volunteers maintains our only public record of breaches. Once I get our PayPal account fixed (it’s tied to my corporate credit card, which was used in some fraud – ironic, yes, I know!) we’ll be sending some beer money their way. Share:

Continuing our theme of quick and effective database security measures, we now move into the data protection phase. The most common (and potentially most effective) security measure for data at rest is encryption. Since we are shooting for fast and effective, we are looking at some form of transparent encryption. Almost every database has transparent encryption built in, and it is effective for securing data files and archives from snooping. Several vendors also offer forms of transparent encryption at the OS/file system level, which behave in a very similar manner, so we will consider those options as well. It’s ironic that I am writing this post today, as I just completed the final editorial sweep through the Securosis Database Encryption & Tokenization paper. Rich and I will be releasing it tomorrow (Cinco de Mayo), so if you want a much deeper dive into the technology tradeoffs and variations, check it paper out when it becomes available (Shameless plug: If you are interested in sponsoring the paper, let us know). There are a handful of business reasons to use data encryption for databases: to buttress access controls in order to protect against unwanted insider access, to protect data at rest, or to comply with an industry or government regulation. Only the last two are covered by transparent encryption, as the former requires encryption at the application layer. Application level encryption requires code changes, database changes, and application recertification, so I exclude it from this Fundamentals series. Encryption embedded within disk drives is transparent, and it protects files on the disk as well. However, purchasing encrypted drives is a significant investment, does not protect exports or tape archives, and does not protect databases moving around virtual environments. Since we are focused on quick wins here, I am limiting the discussion to transparent database options – either using native database capabilities, or through OS/file system support. Native database encryption features are embedded within the database. The encryption operations are handled behind the scenes, with no changes to the tables, columns, indices, or queries. Enabling the feature is at most an add-on package, but in some cases as simple as a handful of DDL statements. The database encrypts the data just prior to writing to disk, and decrypts when processing authenticated queries for encrypted data. Key management is either handled internally (with keys stored within system tables and only accessible by DBAs), or externally (with a dedicated key management server). Internal key storage is easier to manage, and simpler in disaster recovery scenarios, at the expense of weaker security. In either case, keys are used without the end user interaction (or even knowledge). File/OS encryption works by intercepting the database’s writes to disk and encrypting data blocks before storing them. Conversely, data is decrypted as the database requests information from disk. Keys are stored within key management services embedded within the encryption product rather than the database, or provided by external key management products. Keep in mind that this type of product can applied to on specific folders where the data is stored and not just database files. File/OS encryption is attractive for its ability to address both database non-database data security issues. Two options are not a lot, but both transparent options are effective and offer the same business benefits. The choice comes down to four factors, in order of importance: performance, cost, versatility, and comfort level. How much does the solution impact transactional throughput? How much does it cost? How many different problems does it solve? How easy is it to use? Or at least this should be the order of importance, but from experience I know some people reverse that order because they know the database and are comfortable with a particular UI. If you are the sole DBA, how comfortable you are with the interface, or how easy it is for to use, will be the biggest factor because your time is more important than the other factors. If you have been using Sybase for years and are happy with their tools, odds are you will choose that. Regardless, if you have the opportunity, running a couple performance benchmarks is very handy for getting an idea of how much impact encryption will have. It may be 3%, or 12%. Nobody notices 3%, but 12% may mean calls from users. Run some basic performance tests between a) your unaltered database, b) the database vendor’s solution active, and c) an external tool. Understanding the impact on typical database transaction processing really helps with decision making. Get some pricing estimates from vendors. If there are others in your IT organization who already use file/OS encryption, ask them about usage and performance. Yes, this makes this a two-day task instead of a one-day implementation, but it’s worth it. Testing setup and execution will take at least a day, but will give you greater confidence in your decision and make the final rollout a lot easier. Select: The question of what type of transparent encryption to select – internal database native or external file/OS – is a murky one. Weigh your options and make your selection. Acquire the tool or licence. Define Scope: Column level, table level, or entire database? Understand what data you will apply encryption to, read the documentation, and generate your configuration scripts. Configure & Install: Once you have reached this step, you should be able to implement database encryption within an afternoon. Obviously, the first step in the process is to make sure you have a verified backup prior to the installation process. Once you have installed or configured the encryption engine, the first major step will be to generate the keys. Select a good passphrase (not password) to protect the keys. Produce a verified backup of the key archive. If the keys are stored in a system table, take a fresh backup of the database. If the keys are in an external key management service, before you go any further, make sure you have that backed up and can restore

The other day it hit me: Process is not that important to secure code development. Waterfall? Doesn’t matter. Agile process? Secondary. They only frame the techniques that create success. Saying a process helps create secure code is like saying a cattle chute tames a wild Brahma bull. Guidelines, steps, and procedures do little to alter code security, only which code gets worked on. To motivate developers to improve security, try less carrot and more stick. Heck, process is not even a carrot – it’s more like those nylon dividers at the airport to keep polite people from pushing and shoving to the front of the line. No, if you want to developers to write secure code, use peer pressure. Peer pressure is the most effective technique we have for producing secure code. That’s it. Use it every chance to you get. It’s the right thing to do. Don’t believe me? You think pair coding is about cross training? Please. It’s about peer pressure. Co-workers will realize you suck at coding, and publicly ridicule you for failing to validate input variables. So you up your game and double-check what you are supposed to deliver. Quality assurance teams point out places in the code that you screwed up, and bug counts come up during your raise review. Peer pressure. No developer wants his or her API banned because hackers trampled over it like fans at a Who concert. If you have taken management classes, you have heard about the Hawthorne Effect, discovered through studies in the 1920s and ’30s. In attempts to increase factory worker output, they adjusted working conditions, specifically looking for optimal lighting that produced the highest productivity. What they found, however, was that productivity has nothing to do with the light level per se, but went up whenever the light level changed. It was a study, so supervisors paid attention when the light changed to monitor the results. When the workers knew they were being watched, their productivity went up. Peer pressure. Why do you think we have daily scrum meetings? We do it so you remember what you are supposed to be working on, and we do it in front of all your peers so you feel the shame of falling behind. That’s why we ask everyone in the room to participate. These little sessions are especially helpful at waking up those 20-something team members who were up all night partying with their ‘bros’, or drinking Guinness and watching Manchester United till the wee hours of the morning. You know who you are. We have ‘Sprints’ for the same reason universities have exams: to get you to do the coursework. It’s your opportunity to say, “Oh, S$^)#, I forgot to read those last 8 chapters,” and start cramming for the exam. Only at work you start cramming from the deadline. 30 day sprints just provide more opportunities to prod developers with the stick than, say, 180 day waterfall cycles. I think Kent Beck had it wrong when he said that unacknowledged fear is the root cause of all software project failures. I think fear of the wrong things causes project failures. We specify priorities so we understand the very minimum we are responsible for, and we work like crazy to get the basics done. Specify security as the primary requirement, verify people are doing their jobs, and you get results. External code review? Peer pressure. Quality assurance? Peer pressure. Automated build failures? Peer pressure. The Velocity concept? Peer pressure. Testers fuzzing your code? Still peer pressure. Sure, creating stories, checklists, milestones, and threat analysis set direction – but none of those is a driver. Process frame the techniques we use, and the techniques alter behavior. The techniques that promote peer pressure, manifesting itself through fear or pride, are the most effective drivers we have. Disagree? Tell me why. Share:

I’m starting to think I shouldn’t take vacations. Aside from the Symantec acquisition of PGP and GuardianEdge last week, someone went off and released the first open source DLP tool. It’s called OpenDLP, and version 0.1 is currently available over Google Code. People have asked me for a long time why there aren’t any FOSS DLP options out there, and it’s nice to finally see someone put in the non-trivial effort and release a tool. DLP isn’t easy to create, and Andrew Gavin deserves major credit for kicking off the project. First, let’s classify OpenDLP. It is an agent-based content discovery/data-at-rest tool. You install an agent on endpoints, which then scans local storage and sends results to a central management server. The agent is a C program, and the management server runs on Apache/MySQL. The tool supports regular expressions and scanning of plain text files. Benefits Free. You can customize the code. Communications are encrypted with SSL. Supports any version of Windows you are likely to run. Includes agent management, and the agent is designed to be non-intrusive. Supports full regular expressions for building policies. Limitations Scans stored data on endpoints only. Might be usable on Windows servers, but I would test very carefully first. Unable to scan non-plain-text or compressed files, including current versions of Office (the .XXXx XML formats). No advanced content analysis – regex only, which limits the types of content this will work for. Requires NetBIOS… which some environments ban. I have been told via email (not from a DLP vendor, for the record) that the code may be a bit messy… which I’d consider a security concern. Thus this is a narrow implementation of DLP – that’s not a criticism, just a definition. I don’t have a large enough environment to give this a real test, but considering that it is a 0.1 version I think we should give it a little breathing space to improve. The to-do list already includes adding .zip file support, for example. I think it’s safe to say that (assuming the project gathers support) we will see it improve over time. In summary, this is too soon to deploy in any production capacity, but definitely worth checking out and contributing to. I really hope the project succeeds and matures. Share:

I’m catching up on my reading, and finally got a chance to peruse the NetworkWorld DLP Review. Here’s why I think you need to toss this one straight into the hopper: It only includes McAfee and Sophos – other vendors declined to participate. The reviewers state the bulk of their review was focused on test driving the management interface. The review did not test accuracy. The review did not test performance. The review did not compare “like” products – even the McAfee and Sophos offerings are extremely different, and little effort was made to explain these differences and what they mean to real world deployments. In other words, this isn’t really a review and should not inform buying decisions. This is like trying to decide which toaster to buy based on someone else’s opinion of how pretty the knobs are. I’m not saying anything about the products themselves, and don’t read anything between lines that isn’t there. This is about NetworkWorld publishing a useless review that could mislead readers. Share: