Research

With the two girls at sleepaway camp, the Boss and I weren’t sure how the Boy would handle it. After all, he’s pretty much always surrounded by someone. Having a twin sister will do that to you. If he’s not at school, with his buddies, or doing an activity, he’s usually playing with one of his sisters. In fact, we think his ability to tune out almost everything directly correlates to always being around people. But don’t think the summer is only fun and games. I described Mommy Food Camp last week, and he’s doing well. He eats hot dogs now (“I don’t like them, but I’ll eat them”), and I even got him to eat a hamburger (“It was horrible!”). He’s now thinking of becoming a vegetarian (like his Dad), and tried to convince me that there’s no meat in Chicken Nuggets. He may actually be right, but that’s another story. We were also hoping he would become a bit more assertive, as he tends to be pretty quiet. We learned this was a non-issue when he had a tantrum at day camp when he wasn’t in a group with his buddies. Suffice it to say, the situation was rectified immediately, and we didn’t have to get involved. Of course, we’d like him to deal with things without crying and screaming, but he has friends who were put in the wrong group and didn’t say a word for days. We’ll take Mr. Assertive any day of the week. Truth be told, I think he likes the peace and quiet. We joke that the only time he had any peace was the minute after his sister was born, while he was waiting his turn. We do let him play on one of the iPads a bit and maybe watch a little TV, but nothing crazy. We’re glad he’s enjoying the few weeks he’s flying solo because the plan is to send him to sleepaway camp next year. Even though he maintains that he doesn’t miss his sisters, we make him write letters to them anyway. It’s as much to keep him writing as anything else, though we know the girls love to hear from him. He wrote a nice letter, telling them what’s he’s been up to, who he’s been hanging out with, and that he just lost another tooth and is awaiting the Tooth Fairy’s visit. At one point in the letter, he wrote: “I’m the King of the House.” We wondered whether we should pull that out, since it might make the girls feel bad, but decided to leave it in. Mostly because it was so damn cute. But when we dug a bit deeper, clearly the Boy does get overshadowed by his strong-willed sisters. With them not around (for a little while anyway), he assumes the mantle of the King. Of course, I don’t have the heart to burst his bubble. He’s no more the King of the House than I am. But that didn’t stop us from asking the King to clean up his dishes and get ready for bed. Even royalty needs beauty sleep. -Mike Photo credits: “KING CLUB” originally uploaded by oknovokght Incite 4 U The Daily Breach: Given the challenges of traditional media, it’s surprising that none of the tech books have launched a Daily Breach newsletter. It’s not like there’s no inventory. I mean, check out this screen grab of my SC Magazine newsletter this AM. 4 latest news stories, and 4 breaches. And that doesn’t even include the Booz Allen breach. Folks, this is the new reality. Breaches happen. Breaches are disclosed. Customers are pissed. Some folks would use a data point like this as an excuse to be grumpy or to do nothing. But there has always been a Daily Breach. You just didn’t know about them before. So now the spotlight is on us. Guess we should have been careful what we wished for. – MR Just do the work, or hire crap: Let’s look at A List Apart’s recent post on “RFPs: The Least Creative Way to Hire People”. You don’t need to be creative to hire people – you want to hire creative people (whether or not you yourself are). I have seen just as many bad creative hiring methods as bad conventional ones – both unwittingly filter due to the process. Have I even mentioned the time I was interviewed by 115 people for a VP of Engineering Job? Only two interviewers actually understood the skills needed for the job, and one interviewer wanted a bad candidate to ensure there was no challenge for her fiefdom. However it’s done, you just need to put in the time to understand what you are hiring for and adequately screen the sea of resumes. It’s the latter point that people don’t want – or know how – to do. So they create, effectively, giant lists of screening questions to filter the resumes. But here is a hint: PEOPLE LIE. Liars get through, and honest people don’t. Forget all the other fancy nonsense, put in the time, and do the work. – AL Know thyself: Managing your identity online is more than merely controlling your credentials and avoiding keyboard-mediated tourettes (something I should probably work on). In the real world our lives are naturally compartmentalized. There’s work, home, hobbies, groups, and all sorts of social circles. The online world isn’t really set up like this, and when we use work email accounts for personal communications, or tie our identities to our jobs, or link in everyone on the same social media platforms, we blur lines in ways we cannot always anticipate. That’s why Jeff Jones’ article on how he’s segregating his identities really resonated with me. I did something similar a while ago – Twitter is fully public, Facebook is now for (mostly) non-work friends and family only, and I’ve switched more personal email off Securosis, despite being a partner in the company. Think about your online personae, and it

In my last post I discussed how tokenization is being deployed to solve payment data security issues. It is a niche technology used almost exclusively to solve a single problem: protecting credit card data. As a technology, data tokenization has yet to cross the chasm, but our research indicates it is being used to protect personal information. In this post I will talk about using tokens to protect PII – Social Security numbers, driver’s license numbers, and other sensitive personal information. Data tokenization has value beyond simple credit card substitution – protecting other Personally Identifiable Information (PII) is its next frontier. The problem is that thousands of major corporations built systems around Social Security numbers, driver’s license numbers, or other information that represents a person’s identity. These data were engineered into the foundational layers of myriad applications and business processes which organizations still rely on. The ID (record number) literally tied all their systems together. For example, you could not open a new telephone account or get an insurance policy without supplying a Social Security number. Not because they needed the number legally or technically, but because their IT systems required the number to function. SSNs provided secondary benefits for business analysis, a common index for 3rd party data services, and useful information for fraud detection. But the hard requirement to provide SSN (or driver’s license number, etc.) was that their application infrastructures were designed to require these standard identifiers. PII was intrinsically woven into database and application functions, making it very hard to remove or replace without negative impact on stability and performance. Every access to customer information – billing, order status, dispute resolution, and customer service – required an SSN. Even public web portals and phone systems use SSN to identify customers. Unfortunately, this both exposed sensitive information to employees with no valid reason to access customer SSNs and contributed to data leakage and fraud. Many state and local government organizations still use SSNs this way, despite the risks. Organizations have implemented a form of tokenization – albeit unwittingly – by substituting SSN and driver’s license numbers with arbitrary customer ID numbers. Social Security numbers are then moved into secure databases and only exposed to select employees under controlled circumstances. These ad hoc home-grown tokenization implementations are no less tokenization than the systems offered by payment processors. A handful of organizations have taken this one step further, used third-party solutions to manage token creation, substitution, data security, and management. But there are still thousands of organizations with sensitive data in files and databases to identify (index) clients and customers. PII remains a huge potential market for off-the-shelf tokenization products. While this is conceptually simple, and simply a good idea for security, not every company uses tokenization for PII – either commercial or ad hoc – because they lack sufficient incentive. Most companies lack strong motivation to protect your personal information. If it’s lost or stolen, you will need to clean up the mess. There are many state regulations that require companies to protect PII and alert customers in the event of a data breach. But these laws are not adequately enforced, and provide too many loopholes, so very few companies ever face fines. For example, most laws are designed to excuse breaches if data encryption was in use. So if a company encrypts network communications, or encrypts data archives, or encrypts your database, they may be exempt from disclosure. The practical upshot is that companies encrypt data in one context – and escape legal penalties such as fines – while leaving it exposed in other contexts. The fact that so many data breaches continue to expose customer data clearly demonstrates the lack of effective data security. Properly deployed, encryption is a perfectly suitable tool for protecting PII. It can be set up to protect archived data or data residing on file systems without modification to business processes. Of course you need to install encryption and key management services to protect the data, understanding this only protects data from access that circumvents applications. You can add application layer encryption to protect data in use – but this requires changing applications and databases to support this additional protection, paying the cost and accepting the performance impact. In cases like PII – which really is not needed for the vast majority of application functions – tokenizing personal information reduces the risk of loss or theft without impacting operations. Risk is reduced because you can’t steal what’s not there. This makes tokenization superior to encryption for security: If encryption is deployed insecurely, if administrative accounts are hijacked, or if encryption keys are compromised, the data is exposed. Tokenization simplifies operations – PII is stored in a single database, and you don’t need to install key management or encryption systems. Setup and maintenance are both reduced, and the number of servers which require extensive security is also reduced. Tokenization of PII is often the best strategy as it’s cheaper, faster, and more secure than alternatives. Share:

A few weeks ago I posted on different methods for encrypting IaaS volumes, which tends to be one of the top questions I get about data security in the cloud. Also high on that list is encrypting (or tokenizing) for SaaS and (some) PaaS. I call this the “Salesforce.com Problem”, because more often than not I’m talking to someone on the larger side, specifically about Salesforce.com. Before I go into options, I need to explain why I’m only talking about some PaaS. PaaS covers a very wide range of technologies – from Database as a Service, to things like Google APIs, to full-on application environments like CloudFoundry and Elastic Beanstalk. For this post I’m mostly restricting myself to SaaS-related PaaS like Force.com. In other words, API interfaces to things you can also run completely via a web interface. I know this is a grey line, and in some future post I’ll go more into detail on encrypting for the rest of PaaS. Just recognize that the core architecture described here works for cases beyond this scope, but some of the issues & details may not apply. There are only two options for SaaS encryption: Encrypt it at the SaaS provider. Encrypt it before you send it. To review quickly, when analyzing encryption systems we look at the locations of three components: the data, the encryption engine, and key management. If your SaaS provider handles the encryption on their side, they hold all three components, so this option requires trust in your provider. Yes, there are many subtleties and options that dramatically affect security, but at the core the provider needs the key and the data at some point. The advantage (for you) is simplicity and flexibility. But if you don’t trust your SaaS provider, you’ll need to encrypt on your side… which means increased cost and complexity. If you encrypt it before you send it, there are two options: Encrypt in a client application before uploading the data. Proxy connections and encrypt at the proxy. The first option is common for things like backup applications, but as I mentioned that’s more PaaS – the part we aren’t talking about here. Espcially because the vast majority of the apps I am talking about today are web-based. So most organizations I know which are looking to do this are evaluating proxy-based solutions such as CipherCloud, PerspecSys (maybe – their website sucks and doesn’t mention how they work), and Navajo Systems. These are application-aware web proxies that intercept browser calls to the SaaS provider and replace sensitive data with encrypted or tokenized values. Instead of connecting directly to the SaaS provider, users go through the proxy. You configure it to encrypt or tokenize sensitive data, although instead of defining every field on every form you should be able to say “account number” and have the product automagically replace it everywhere. In some future post I’ll delve into this architecture in more depth, but there are three main challenges to this approach: The product needs to stay totally up to date with any changes with the SaaS provider UI/application. When you are intercepting and rewriting HTML fields on the fly, you really need to know exactly where they are. Users need to connect back through your enterprise, or a trusted web-based host (e.g., running the proxy at Rackspace). For your internal network, this means you’re back to running VPNs. If you host on the outside, you have another party to trust but can handle it with bookmarks or such. If you use a cloud-based web proxy for URL filtering and content security, you might be able to map it up there. You might break application functionality/usefulness. This requires a lot of translation, which affects SaaS features that rely on the protected data. This becomes more of an issue as you protect more fields and data types – the more you obfuscate, the less your SaaS app can process. (It can still process the un-tokenized data). Because of these challenges I tend to regard this proxy approach as a band-aid for SaaS. It’s definitely not ideal, and a heck of a lot of work for the vendor to keep up and running. I believe it makes more sense for PaaS, where you rely more on APIs than HTML interfaces. In all cases I think the web proxy approach is best used for very discrete and limited data – otherwise there is too much potential loss of core application functionality, at which point you might as well stick to internal systems. Share:

Every company I have worked for has had some degree of friction between sales and marketing teams. While their organizational charters are to support one another, sales always has some disagreement about how products are positioned, the quality of competitive intelligence, the quality of leads, and the lack of <insert object here> to grease the customer skids. Marketing complains that sales does not follow the product sales scripts, doesn’t call leads in a timely fashion, and don’t do a good job of collecting customer intelligence. Friction is a natural part of the relationship between the two organizations, so careful balancing is necessary. I was reading George Hulme’s interview David Litchfield on securing the data castle this morning, which provides basic security steps every organization should take. There’s also a list of intermediate Oracle security controls (PDF). But the real challenge was not performing Litchfield’s steps – it’s managing the resulting friction. The issue is that problems arising between database administrators and everybody else. Litchfield says: Beyond patch updates and good password management, what else can organizations be doing that they’re not? Use the principle of least privilege within their applications. This is a very important one. People are pressured into getting their applications running as quickly as they can. However, when they try to manage permissions properly, that good practice can delay deployment slightly. So they say, “Oh look, let’s just give users all the permissions. The application seems to work with these settings. Let’s shove that into production.” Not a great approach. If you don’t want a breach, it’s really worth spending the extra time to design an application that operates on least privilege. Which is all true, but only one side of the coin. For example, setting permissions is easy. Managing and maintaining good permissions over time is more work and creates friction between organizations. Most DBAs face user calls on a daily basis, asking for added permissions to complete some task. Users look at permissions – or their lack – as impediments to getting their jobs done. Worse, should the DBA decline the request, the DBA takes the blame for lost time. DBAs need to add the permissions and then – at some prearranged time – revoke them. But most DBAs, looking to avoid future calls to add privileges, never revoke them. It’s easier and less hassle, and users are happier. Face it – a few minutes of wasted time for both parties, especially with hundreds or even thousands of users, adds up to a lot of time. Who’s going to notice? Patching is the same – upgrade an application or database revision and stuff breaks. Or just as bad, the application works differently than before. New features and functions create complaints like “What happened to X?” and “It used to do Y, but now it doesn’t!”, so for several weeks the help desk is swamped with calls. And password rotation and long password requirements both generate help desk calls by the dozen. So what’s the result? User complaints. Systems are not reliable, which results in the poor DBA getting a poor ‘performance’ rating. Which is sad because the friction between user demands for everything and DBAs holding the line for security is a sign that DBAs are doing their jobs. But doing their jobs gets them dinged on performance, so they don’t get raises, so they leave for other jobs. Any good DBA understands that there is a correct degree of friction in their role for security. It’s not just planning for the security measures you want to put in place, but understanding how to mitigate their impact on the organization. Plan ahead and don’t let security be “your fault”. Share:

I have to admit that some days I have no idea what will resonate with readers. For example, my latest column over at Dark Reading seems to be generating a lot more interest than I expected. For a few months now I’ve been bothered by all the pile-ons every time some organization gets hacked. Sure, some of them really are negligent, and others are simply lazy or misguided, but the rest really struggle to keep the bad guys out. There’s never any shortage of experts with hindsight bias ready to say X attack would have been stopped if they only used Z security best practice. It’s like a bunch of actors sitting around going “I could have done it better”. Frequently this ‘advice’ is applied to a large organization which “should know better”. But these critics consistently fail to account for the cost and complexity of doing anything at scale, or for (universal) resource constraints. This was the inspiration behind Simple Isn’t Simple. Here’s a quote: This isn’t one of those articles with answers. Sure, I can talk all day about how users need to operationalize security more, and vendors need to simplify, consolidate, and improve functionality. But in the end those problems are every bit as hard as everything else I’m talking about and won’t be solved anytime soon. Especially since the economics aren’t overly favorable. But we can recognize that we rely on complex solutions to difficult problems, and blaming every victim for getting hacked isn’t productive. Especially since you’re next. Security is hard. It’s even harder at scale. And we need to stop pretending that even the most basic of practices are always simple, and start focusing on how to make them more effective and easier to manage in a messy, ugly, real world. I thought is was the usual analyst BS, but I guess there’s something more to it… Share:

The US is playing ‘catchup’ in contactless security. The US lags in smart identity card technology adoption. We lag in payment card security. It’s frustrating for Americans to travel in Europe. We have rudimentary ePassport technology, and it has been almost a decade since the first draft of the HSPD-12 PIV standards. We’re behind. We are laggards. And I say “So what?” When it comes to smart card adoption, the US is not even in the race. Citizen ID, government employee ID, ePassports, first responder cards, Chip and PIN payment cards, whatever – we are in no hurry. And I am not at all convinced we should be in many cases. Credit card fraud rates in the US are not much higher than Europe’s. Sure, it’s still pretty easy to ‘skim’ credit cards – but not enough to rework the entire payment infrastructure to accommodate Chip & PIN systems. Are people breaching the security of federal buildings due to the lack of advanced PIV cards? How many terrorist attacks on RFID systems have you seen? Many of the efforts are technology for the sake of technology. You’re getting new technology, at 10 times the cost, for only slightly better security. Like those motorized paper towel dispensers or automated Japanese toilets – sometimes technology was not a necessary solution. I am amused that smart card, ePassport, National ID, and PIV vendors market their products as benefits to the consumer. Do you know anyone who thinks their life would be better if they had a smart national ID card? Me either. And the only time I have even heard about problems around the lack of EMV (Europay-Mastercard-Visa alliance) smart cards is in the last few months for US travelers in Europe. Even then there are plenty of solutions if you plan ahead. The noise on this subject seems to be coming from the SmartCard alliance and associated organizations – not from consumers, merchants, or even the payment card industry. It’s not that we lack the technology, it’s that we lag in deployment of the security technologies. So why is that? Because there is not enough financial justification for the expense. It would cost billions to swap merchant payment terminals, and possibly billions to issue new cards, given the investment in back-end personalization and issuance systems to produce the cards. The fact that many of the security problems have been mitigated with fraud detection and other forms of authentication offsets the need for these smart token systems. It’s a classic security vs. business tradeoff. Do we really really need Chip and PIN in the US? Will it keep us more secure? Will it drop credit card fraud enough to offset the cost of replacing the infrastructure? Does it reduce merchant liability? Are RFID systems really being hacked for fun and profit? Not enough to warrant adoption today, at least. Ultimately we’ll see smart cards with increasing frequency as things like multi-app EMV cards offer more business opportunities, but the motivator will not be security. Share:

It won’t surprise any of you to learn that I don’t follow Fox News on Twitter. I know, I can see the shock in your eyes, but I’m not the biggest fan of our friends on the right. Actually, I hate all 24 hour news stations – Fox biased to the right, MSNBC to the left, and CNN to the stupid. So I missed their announcement of to the demise of our commander in chief. It seems one of their Twitter accounts was hacked, and the attackers had a little fun with some bogus tweets. If you read this blog you probably know everything I’m about to write, but it’s probably a good time to review it anyway. If you use these services for business purposes, there are a few precautions to put in place: If you use social media in your business, make sure you set up accounts (or use your personal accounts) to monitor your official account. Be very cautious in how you handle your account credentials (who you give them to, how they are secured, etc.). The list of people with access should definitely be very short. Use an OAuth-based service or application to allow employees to tweet to your account without having to give them your account password. This is how most Twitter clients work today, for example. If you are large enough, talk to your provider ahead of time to understand how to report problems, and who to report them to. The last thing you want to be doing is hanging out waiting for a help desk person to see your request in the queue. Make contact, get a name, and establish a validation process to prove you are the owner of the account in an incident. You’ll also use this process if an employee goes rogue. Simple stuff, but I suspect very few businesses follow these basics. Share:

As mentioned last week, our girls are off at sleepaway camp. They seem to be having a great time, but you can’t really know. Obviously if there was a serious issue, the camp would call us. Since we dealt with the nit-uation, we have heard from the guidance counselor that XX2 is doing great, and from the administrator that XX2 needs more stationary. Evidently she is a prolific writer, although our daily mailbox vigil has yielded nothing thus far. We’ll save a spot for her at Securosis, since by the time she’s out of school, I’ll need someone else to pick up the mantle of the Incite. The one thing that is markedly different than when I went to camp is the ability to see daily photos of the camp activities. Back when I went in the 80’s camp was a black box. We got on the bus, we’d write every so often, but my folks wouldn’t really know how we were doing until they came up for visiting day. Now we can see pictures every day, and that’s when the trouble begins. Why? Because the pictures don’t provide any context. Our crazy overactive brains fill in the details we expect to be there, even if it means making stuff up. We read between the lines and usually it’s not a positive thing. So you see XX1 in a picture she isn’t wearing her skirt. What’s the matter, doesn’t she like her clothes? Or she is smiling from ear to ear, but is that a genuine smile? Or she’s at the end of the row of kids. Why isn’t she right in the middle? Yes, we understand this line of thinking makes zero sense, but your brain goes there anyway. And even worse is when the girls aren’t in any pictures. What’s the deal with that? Are they in the infirmary? Aren’t they having fun? Why wouldn’t they be attention whores like their Dad and feel compelled to get into every picture. Don’t they know we are hanging on every shred of information we can get? How inconsiderate of them. Yes, I am painfully aware that this behavior is nonsensical. Camp is the greatest place on earth. How could they not have a great time? Grandma got a letter from XX1 and she said her bunk is awesome. We know the girls are doing great. But I also know we aren’t alone in this wackiness – when we get together with our friends we’re all fixated on the pictures. I’m pretty sure having the ability to fill in details in the absence of real information saved our gene line from a woolly mammoth or something 10,000 years ago, so it’s unlikely we’ll stop. But the least we can do is make the story a happy ending each day. -Mike Photo credits: “Reading Between The Lines” originally uploaded by Bob Jagendorf Incite 4 U Most (but not all) is lost: Good thought-provoking piece here by Dennis Fisher entitled Security May Be Broken, but All is Not Lost. His main contention is that the public perception is awful, but that’s only half the story – folks who block stuff successfully are not highlighted on CNN. It’s part of why I call security a Bizarro World of sorts. Only the bad news is highlighted and a good day is when nothing happens. But the real issue that Dennis pinpoints is the continued reticence to almost everyone about share data on what’s working and what isn’t. Whether the sharing is via formal or informal ISAC-type environments, security benchmarks, online communities (like our sekret project), or whatever, Dennis is spot on. Until we start leveraging our common experience, nothing will get better. – MR Dropped Box: It’s hard to root for a company – whose product you use and like – when they keep making boneheaded moves. If you didn’t hear, Dropbox poured gasoline on the idiocy fire when they came out with new Terms of Service that grant them wide latitude to mess with your stuff. I was hoping for an acknowledgement of the security architecture issues on the client and server side, along with a roadmap for when they will be resolved. Instead they lawyered up and gave themselves immunity to do stuff to your stuff, and when customers complained, they basically said customers misunderstood them. Yes, customers must be wrong because Dropbox is the first company to hold vast stores of customer data, so no one else could not possibly understand the nuances of their business. Who over there is not getting it? Management? Tech staff? Their PR agency? Their lawyers? All of the above? Do they not understand they must never – under any circumstances – allow a stolen configuration file to grant any client access to customer data? There is no reasonable explanation for a cascading failure on the server side which exposes accounts. It might be understandable that you need to make ‘translations’ of content (though Mike says that’s a bunch of crap); so they should specifically only need permission to do that. Don’t use overly broad legalese, like derivative works, because that opens up totally unacceptable use cases! Why is anyone satisfied with a security document that fails to explain how they handle key management or multi-tenant data security? I moved everything except 1Password’s independently encrypted password store off Dropbox yesterday, and am evaluating Spideroak. I’ll come back as an advocate and customer if they fix their mess, but they continue to pat themselves on the back for bad decisions, so it might be a long wait. – AL Second: Hopping onto Twitter at one point over the weekend I thought Dropbox had been taken over by Kim Jong-Il and all my data printed out and personally mailed to Anonymous, the NSA, and my third-grade English teacher. Hunting it down (you know, by reading 2 tweets back), I learned it was a change in the Terms of Service. Then I read the new terms and I realized some

As while back, I spent some time categorizing tactics vendors use to create Fear, Uncertainty, and Doubt (FUD) as a buying catalyst for their products. We followed up with a survey trying to understand what kinds of security marketing content is useful at different stages of the sales cycle. I’m parsing and doing some lightweight analysis of the survey results as we build our inaugural vendor newsletter. Given space restrictions I couldn’t analyze all the data, but I do want to focus on one of my pet peeves: competitive attacks. When I was on the vendor side, one of the things that got my goat was the insistence on focusing (almost exclusively) on the competition. Everyone – both sales reps and customers – expected us to provide information sales reps could use to beat the competition. The dirtier and nastier the better. Some folks spread rumors about competitors’ finances, or bogus reports that competitive products fell over at customer sites, or that competitors were kicked out of Account X or Y. It all made me sick. Mostly because I thought it didn’t work. I figured prospects would appreciate information about how our products solved their problems. Unfortunately I had no data to prove that, beyond anecdotal reports of pissed-off prospects not appreciating hit pieces sent directly to their CIOs (two levels above where the decision got made). So we asked questions to provide a sense of if and where competitive attacks are useful, and to compare them against less-aggressive competitive analyses. To be clear, we aren’t dealing with a lot of data here. Only 32 responses, but enough to build my soapbox and support me urging vendors to stop worrying about competitors and start worrying about customers. Let’s take a look at the data on specific competitive attacks. The question was phrased: “Competitive Attacks”: This is down and dirty hand to hand combat tactics, where the vendor attempts to make the competition look bad. There are seemingly no boundaries here, where vendors will question financial viability, spread rumors about staff defections, gossip about investors pulling money out, or anything else to make the competition look bad. Click the image for a full-size view. Almost half of respondents believe this behavior negatively impacts their perception of the vendor. A lot less responded that it negatively impacts their view of the competitor. Very few said these tactics actually improved their perception of the attacker. And few used this information to guide vendor selection or justify selection of specific vendors. When we looked less aggressive competitive analyses, the results were a bit more favorable – but not much. “Competitive Analysis”: Some vendors will provide information (usually informally) about why its product/service is better than the competition. They may question the product’s technical capabilities, and/or talk about how they replaced the competitor in an account. They may also provide some reference accounts to discuss why they are better than the competitor. Click the image for a full-size view. About a quarter of respondents use this information in the selection process. As a client, I’m a fan of getting as many reference accounts as I can. Then I call them up and spend very little time on the vendor they chose. I ask why they didn’t choose the other vendors. They are usually pretty forthcoming about companies that didn’t make the cut. I put little stock in what they say about the vendor who gave me their name. Why? Because I know more than I should about the back-room arrangements that take place to get very busy practitioners to spend some of their days doing favors for sales reps. But those are stories better told over frosty beverages. Listen, I’m not naive here. I understand how the game works. Direct sales is like a street fight. You use whatever advantage you can. I can only tell you that the most successful reps I’ve worked with spent a lot more time focused on customer problems, and much less on the competition. Smart customers buy products based on who solves their business problems best, and do their homework on what products really work in the field. If a product falls over, they know about it from their own research, not the sniping of a competitor. But at the end of the day, it gets back to people. I’ve always done business with folks I like, and I’m not a big fan of dirty tactics. So if you badmouth your competition I’ll generally send you on your way. But that’s me. Share:

How many of you had the experience as a child of wandering around your grandparents’ house, opening a cupboard or closet, and discovering really old stuff? Cans with yellowed paper or some contraption where you had no idea of its purpose? I had that same experience today, only I was in public. I visited the store that time forgot. My wife needed some printer paper, and since we were in front of an Office Max, we stopped in. All I could say was “Wow – it’s a museum!” Walking into an Office Max looked like someone locked the door on a computer store a decade ago and just re-opened it. It’s everything I wanted for my home office ten years ago. CD and DVD backup media, right next to “jewel cases” and CD-ROM shelving units! Day planners. Thumb tacks. S-Video cables. “Upgrade your Windows XP” guide. And video games from I don’t know when, packaged in bundles of three – just what grandma thinks what the grandkids want. It’s hard to pass up Deal or No Deal, Rob Schneider’s A Fork in the Tale, and Alvin and the Chipmunks games on sale! I don’t know about most of you, but I threw away my last answering machine 9 years ago. I have not had a land line for four years, and when I cancelled it I threw out a half-dozen phones and fax machines. When I stumbled across thermal fax paper today, I realized that if I were given a choice between a buggy whip and the fax film … I would take the buggy whip. The whip has other uses – fax paper not so much. It’s amazing because I don’t ever think I have seen new merchandise look so old. I never thought about the impact of Moore’s law on the back end of the supply chain, but this was a stark visual example. It was like going to my relatives’ house, where they still cling to their Pentium-based computer because it “runs like a champ!” They even occasionally ask me whether it is worth upgrading the memory!?! But clearly that’s who Office Max is selling to. I think what I experienced was the opposite of future shock. I found it unfathomable that places like this could stay in business, or that anyone would actually want something they sold. But there it is, open daily, for anyone who needs it. Maybe I am the one out of touch with reality – I mean how feasible is it financially for people to keep pace with technology. Maybe I have unrealistic expectations. I know I still have that uneasy feeling when throwing out a perfectly good fill in the blank, but most of the stuff we buy has less useful lifespan than a can of peaches. So either I turn the guest room into a museum to obsolete office electronics, or I ship it off to Goodwill, where someone else’s relatives will find happiness when they buy my perfectly good CRT for a buck. On to the Summary: Webcasts, Podcasts, Outside Writing, and Conferences Rich on the NetSec podcast. Rich quoted on the Lockheed breach. Favorite Securosis Posts Rich: The Age of Security Specialization is Near! “Even doctors have to specialize. The scope of the profession is too big to think you can be good at everything.” Adrian Lane: The Age of Security Specialization is Near! Mike Rothman: Friday Summary (OS/2 Edition). Yes, Rich really admitted that he paid money for OS/2. Like, money he could have used to buy beer. David Mortman: Incomplete Thought: HoneyClouds and the Confusion Control. Other Securosis Posts Incite 6/28/2011: A Tough Nit-uation. When Closed Is Good. File Activity Monitoring Webinar This Wednesday. How to Encrypt IaaS Volumes. Favorite Outside Posts David Mortman: Intercloud: Are You Moving Applications or Architectures? Rich: The Cure for Many Web Application Security Ills. This is high level, but Kevin Beaver makes clear were you should focus to fix your systemic app sec problems. Adrian Lane: JSON Hijacking. Going uber-tech this week with my favs – and BNULL’s Quick and dirty pcap slicing with tshark and friends. Mike Rothman: Know Your Rights (EFF). Even if you don’t hang w/ Lulz, the Feds may come a-knocking. You should know what you must do and what you don’t have to. EFF does a great job summarizing this. Gunnar: Security Breaches Create Opportunity. The Fool’s assessment of Blue Coat (and other security companies) Project Quant Posts DB Quant: Index. NSO Quant: Index of Posts. NSO Quant: Health Metrics–Device Health. NSO Quant: Manage Metrics–Monitor Issues/Tune IDS/IPS. NSO Quant: Manage Metrics–Deploy and Audit/Validate. Research Reports and Presentations Security Benchmarking: Going Beyond Metrics. Understanding and Selecting a File Activity Monitoring Solution. Database Activity Monitoring: Software vs. Appliance. React Faster and Better: New Approaches for Advanced Incident Response. Top News and Posts Rootkit Bypasses Windows Code Signing Protection Take a bow everybody, the security industry really failed this time. Surprised nobody picked this as a weekly favorite, but it’s too good not to list. eBanking Security updated via Brian Krebs. What will be very interesting to see is how firms comply with the open-ended requirements. Defending Against Autorun Attacks. In case you missed this tidbit. Robert Morris, RIP. Jeremiah knows your name, where you work, and where you live (Safari v4 & v5). Google Chrome Patches. Branden Williams asks if anyone wants stricter PCI requirements. Well, do you? LulzSec Sails Off. Apparently like Star Trek, only they completed their mission in 50 days. Or something like that… MasterCard downed by ISP. No, that’s not a new hacking group, just their Internet Service Provider. Google Liable for WiFi scanning. U.S. Navy Buys Fake Chips. iPhone Passcode Analysis. Groupon leaks entire Indian user database. 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 Mike Winkler, in response to The Age of Security Specialization is Near! The Security generalist is going the Way of