Today The Industry Is Changed!

Don’t I love overly dramatic headings? Yup, I do.
Pretty much since the day Security Scoreboard launched, I was a MAJOR fan of the site and have always considered it “an industry-changing idea”  that can solve the #1 problem in information security – no, not APT! – inability to match solutions to security problems and rate what solutions actually solve those problems well. The industry, as we all know, is full of crapware – from “PCI scans” for $0.41 per month to fake anti-spyware and “magic” appliances that “do security stuff.”
And now we have a powerful weapon to fight it! Today Security Scoreboard changes everything … again.
Specifically:

Security Scoreboard has announced the appointment of security industry veteran
Dominique Levin as Chief Executive Officer. The site offering unbiased end-user
reviews and ratings on security products also received an investment and moved its
headquarters to the Silicon Valley.

Yes, you can still think of the site as “Yelp for Security Products” – but also start thinking of it as “crowd-sourced and reality-based Gartner.”  In my opinion, there is NOTHING (!!!) that our industry needs more than clarity and Yes, even more than APT defense and easy-to-use SIEM  Lately, a lot of very smart folks have been bemoaning the state of the industry (example, example) and Security Scoreboard relaunch cannot have come at a better time.
Full press-release is pasted below (original) – yes, I am that excited to do it:

Security Scoreboard, which offers security product ratings and analytics based on real-world user experiences, announced that it has received an initial angel investment.
"Crowd-sourcing could significantly improve the validity and quality of the information available about commercial IT products”, said Dana Gardner, president and principal analyst at Interarbor Solutions. “As a consumer I can look at Angie's List, Rotten Tomatoes or TripAdvisor and it's crazy such thing doesn't exist for IT."
“Even if you have the time and money to test different solutions, it's always the details of real-life implementations that come to bite you”, said Chris Sawall, Supervisor of Information Security at Ameren Corporation, a Fortune 500 company and one of the nation's largest investor-owned electric and gas utilities. “You never know how technologies and solutions will really work until you have invested in them. Security Scoreboard allows me to be better informed."
At the time of the investment, the company also appointedDominique Levin as CEO.
Levin comes to Security Scoreboard from LogLogic Inc., a leader in security and log management solutions, where she served as Chief Marketing Officer and Acting CEO. She was also previously VP Marketing at PoliVec, held positions at Nippon Telegraph and Telephone and Philips Consumer Electronics and generated over $630 million in shareholder value as a venture capital investor.
“The recent funding and the move to Silicon Valley will allow us to tap into engineering talent to accelerate our roadmap,” said Levin.
“Security Scoreboard recently introduced new analytics capabilities, which highlight top vendors by user ratings and present trends on site visits”, said Dr. Boaz Gelbord, President and co-founder of Security Scoreboard and himself a practicing security executive. “We are looking to add more sophisticated analysis leveraging user generated data”.   
"The new analytics move Security Scoreboard in the direction from merely showing you what your peers are thinking to making true crowd-based recommendations about which vendor tools to use", said Jay Leek, Vice President of International Security at Equifax.
The company plans to raise additional venture funding later this year.
About Security Scoreboard:
Security Scoreboard is a community generated review and rating site to help security practitioners and executives select the right information security solutions. Security Scoreboard is supported by an Advisory Group and User Council of industry leading CISOs, CIOs and security managers. The site leverages crowd sourced ratings and state of the art analytics to provide recommendations based on real life experiences of other customers.

I am REALLY looking forward to the new era – and I do realize that it will take work!
Possibly related posts:

• “Security Scoreboard” Out! 
• Security Scoreboard Updated

Latest Reviews From Security Scoreboard

www.securityscoreboard.com

JOB: SIEM Architect at RSA

As a favor to yet another friend, I am posting yet another SIEM-related job. IMHO, it is an ideal position for a good architect looking to jump ship from a failing or “non-performing” SIEM vendor:

The RSA Security’s fast-growing  Security Management group is looking for the best technical minds to develop the next generation of Security Information and Event Management (SIEM) software.  We are building a great organization with talented employees with the highest ethical and professional standards who deliver a portfolio of products to enable our customers to protect their information assets.

Ideal candidate will have broad knowledge of IT security with proven ability to architect and build complex enterprise systems.  You must enjoy working in a rapidly-changing, high-pressure environment spanning multiple geo locations. As a lead architect, you will exert significant influence over the technical strategy and the architectural definition of the next generation of RSA’s Security Management products.  Practical experience in one of the following areas is required: large-scale database systems, real-time design, network monitoring and analysis.

This position is full-time, based in Bedford, MA. If you are interested in joining the Security Management group in RSA, please send your inquiry or resume to Lauren Day at  lauren.day@emc.com or 978-686-2234.

… and somebody now owes me beer at RSA 

Possibly related posts:

• SIEM-related Job: Principal SIEM Consultant 
• SIEM-related Product Management Job: Atlanta, GA
• All jobs posts on my blog

Novell Bought–What Happens in SIEM?

After I came back from my vacation in Egypt, I started looking through all the noise related to Novell acquisition by Attachmate. Everybody whines about Microsoft, Linux, VMware, patents, open-source, unknown “IP bundle”,  etc – but what about SIEM? Novell has Sentinel SIEM and NetIQ, the previous Attachmate victim purchase, has their own toy “SIEM” – Security Manager.

Now, we can all joke about how sad that NetIQ SIEM really is, how it doesn’t scale and how nobody uses it – and culminate with quotes from Gartner’s Mark Nicolett about it (see “Magic Quadrant for Security Information and Event Management, 2010”): “not very visible in competitive evaluations” and “not growing with the market.” Seriously, if your product team fails to impress Mark with a few no-you-cannot-call-them-fake happy customer references and the final SIEM MQ report goes out with the above quotes, you should look into what seppuku really means to you

So, what can become the future “Attachmate SIEM”?

1. Is it NetIQ SM, coming back as a lumbering zombie to SIEM playground to be slaughtered in competitive deals?
2. Is it Novell Sentinel, which is now improving both its technology and market position by leaps and bounds?
3. Is it both but with some magic differentiation positioning? [ahem…like Tweedledum and Tweedledee of SIEM: IBM TCIM and IBM TSOM perhaps?]
4. Is it some future integrated version of both?

While I don’t claim to possess any deep inside information on the deal, I think one can envision the last option actually working out OK over the long term for all involved – as well as for customers?   For example, combine NetIQ SM strength on Windows (and servers/desktops in general) with Novell cross-platform correlation, UIs, new log manager, etc. Reuse their FDCC-focused pieces too maybe. Also,  integrate NetIQ system management tools with Sentinel.

So, if I were them (and here is my unsolicited product strategy tip), I‘d salvage NetIQ “SIEM” for parts and use them to bulk up Novell Sentinel where such parts can be plugged in with minimum effort. Salvage some useful Windows correlation rules they used to have and port them into Sentinel. At the same time, integrate more functional NetIQ products with Sentinel to improve “IT and security management” story for Novell/Attachmate. In the short term, just make most NetIQ Security Manager customers happy by upgrading them to Novell Sentinel.

How to Write an OK SIEM RFP?

Ok, some people think consultants are supposed to make money off helping enterprises write RFPs, but I am busy enough and so it goes. This is what happens if Anton is stuck in a metal tube for 5 hours in seat 1A

Question: How do I go about writing a SIEM or log management RFP?

Quick answer: don’t. This “purchase method” is probably equally hated by vendors and end-users. As somebody who was “volunteered” to help sales folks with 1600 page (yes, really!) and smaller RFPs more than once during my “vendor years,” I can tell you that – with a tongue firmly in cheek:

a) if you ask a vague question in your RFP, you will get either a “Yes” or a nice blurb taken from a random location in vendor datasheet

b) if you ask a question starting with “How…?”, you will get a nice blurb taken from a vendor datasheet

c) if you ask a silly question (“do you have an Albanian language interface?”), you will get either a “Yes” or a nice blurb taken from a random location in vendor datasheet

d) if you ask a question that is impossible to answer (“Can your product handle the high load?”), you will likely get a “Yes” – surprise!

e) if you ask an honest question that might cast a product in a negative light (“will you every lose log data?”), what do you think you will get….?

See a theme emerge here?  Note that I am not trying to imply that any particular vendor would lie in their RFP responses – the term here is “defensible creative exaggeration.” BTW, what do you think happens when a standard enterprises RFP template collides with a standard vendor RFP “boiler plate” response? Boom! The explosion of high-grade concentrated idiocy…  And if you think that I am a bit cynical about this whole thing, than maybe you are correct… making sausage for a long time does distort one’s personality a wee bit

Despite the above, there are two exceptions to this rule of not doing RFPs:

1. You are obligated to do a RFP (government, etc)
2. You’d like to use your RFP as a chance to distill and focus your SIEM/LM requirements.

Let’s address them both at the same time. If you are case #1 above, you should really turn it into case #2.  As you recall (if not, review these posts here), one of the most important things an organization should do before buying a SIEM is to set its own goals, requirements, use cases, etc. BTW, this recent SIEM presentation stresses the same point – esp. see slide 16 and around.  This older presentation has some things to avoid at the product selection stage – see “worst practices” 1-4.

So, based on my experience on both sides of the RFP “interface”, here are some of my SIEM RFP tips:

• Keep it short! If you cannot express what you need in under 10 pages, go back and rethink it. “Every time an organization releases a 500+ page RFP, God kills an intern.” Yes, that very intern who is tasked with responding to that monster, of course.
• Start from your REAL main reason for getting a SIEM, your problem statement – monitor PCI DSS CDE, perform IDS/IPS alert analysis, monitor servers for suspicious logins, protect web applications via log correlation, etc
• Include your use cases – which simply means to describe how you plan to use the system and what you expect the system to do for you. Some examples are shown here  (more high level) and here (more detailed inside the whitepaper).
• Based on your goals and use cases (and that is important!), describe SIEM product functionality that is essential for your mission: agentless collection, bandwidth throttling, rule-based correlation, visual dashboards, trend reports, whatever…
• Include log sources / devices that you absolutely need supported and what you mean by “supported” (e.g. parsed, normalized, categorized, suitable for correlation, covered by default correlation rules, updated promptly when log source changes, etc). This area is notorious for extra-high volume of “creative exaggeration” (“of course we support VidgetMaster 7.2! – via our generic LogMahgic 1.0 (TM) collector … which  dumps log files right into storage without analysis … and then rotates them to oblivion within 7 days”)
• Avoid or reduce the usage of vague terms: ”scalable”, “high”, “flexible”, “effective”, “advanced”, “automatic”, “proper”, etc. Why tempt the other side unnecessarily?
• Clarify most other terms, even those that look clear to you: “correlation”, “reporting”, “keyword search”, “trend”, “responsive”, etc
• Size the environment before writing an RFP, as we discuss in LogChat #2. Baseline your log sources for 2-4 weeks to get your average EPS rate then include both the volume of data and number of log sources that you absolutely need supported. Also, specify response time for reports and searches while you are at it.
• Make phases of your SIEM project clear up front – don’t say “400,000 devices and 4,000,000 EPS enterprise-wide.” I got news for you – you probably will never get there… Be very clear about your Phase 1-2 and simply keep later phases in mind for the coming years.
• Try hard to avoid idiotic statements (sorry!): “Vendor MUST specify their efforts and processes to guarantee that products and services provided will completely satisfy us or exceed our expectations” (quote from a real RFP)

And – hold on to your pants – despite the above effort you should be prepared to take the responses with a HUGE grain of salt. One of my contacts on the enterprise side put it simply: “of course we ignore all the specifics in RFP responses.” With this approach to RFP writing, you WILL still benefit even if you don’t read the responses…

Finally, a more useful question than “how do I write a SIEM RFP?” is “how do I buy the right SIEM for my organization?” Keep this in mind while tuning your RFP. Or just retain me to help – a $20k consulting project is known to sometimes save an organization from  a $500k SIEM failure….

Possibly related posts:

• Log Management Tool Selection Checklist Out!
• "So, What Should I Want?" or How NOT to Pick a SIEM-III? 
• On Choosing SIEM
• I Want to Buy Correlation” or How NOT to Pick a SIEM?
• The Myth of SIEM as "An Analyst-in-the-box" or How NOT to Pick a SIEM-II?
• Logging, Log Management and Log Review Maturity
• Log Management + SIEM = ?
• On SIEM Complexity
• SIEM Bloggables: SIEM Use Cases
• Whitepaper with detailed SIEM use cases (using a particular SIEM as an example)
• Log Management / SIEM Users: "Minimalist" vs "Analyst"
• All posts labeled SIEM

Security Scoreboard Updated

FYI, Security Scoreboard aka “Yelp for Security Products” comes up with an update which makes it even more useful!

The following is reposted from their news blast:

Real-time Vendor News and Reviews - Vendor pages now feature real time news and analysis pulled from select credible sources. Security Scoreboard filters and sorts these results to bring you the most relevant links for each company.

User Link Submission - Users can now submit their own links to relevant online sources for inclusion in vendor listings.

Listing Competitors - Security Scoreboard now lists select competitors on vendor pages. This helps CISOs and CIOs quickly find the main players in a specific market segment such as, for example, firewall management tools or phone-based 2-factor authentication solutions.  <- HOT feature! [A.C.]

Comment Section - Visitors can now leave comments on any listing without filling out a review.

Sadly, there are still a few mistakes. For example, check out their SIEM listings: which ONE company has absolutely nothing to do with SIEM there?

I always recommend starting your security product research there, if you don’t know where to start.

Log Management / SIEM Users: “Minimalist” vs “Analyst”

Just a random piece of some research project I did at some random point :-) In discussions at RSA 2010 conference, somebody mentioned that SIEM, log management and other monitoring/detection security product users are split into two major categories: one actually uses the product while the other “buys it for compliance” and then eventually uses … as a doorstop, for example.

And I actually had  an old presentation about this that was offered as strategic guidance to my consulting client (a vendor).

Here is that picture and text: two types of SIEM/log managements users that your solution has to make happy:

“Minimalist” SIEM/LM User

•Still evolves from “logs are dirt” to raw collection of log data

•Pure compliance focus – “deliver me from evil… eh… auditors” (or assessors, in case of PCI DSS)

•Collecting logs is the primary “activity”; not even thinking about log review yet

•Checkbox mentality is rampant among that type of user (sometimes, “correlation” is one of the checkboxes, sadly)

•Less mature; needs more hand-holding when deploying the product (might not want any help though…)

“Analyst” SIEM/LM User

•Evolved to “so we have them collected – now what?”; stuck now and not sure how to use “all that data”

•“Compliance+” or even pure security/operational focus; for example, SOC operation

•Using logs – review, analysis, at the very least investigations

•Explore and use logs mentality, focuses on getting the value of the data and solving problems

•More mature; needs more “cool tools”

So, before you plan/design/build your solution, think what is the primary user type… but keep in kind that to be truly successful you might need to entice both.

Enjoy!

Possibly related posts:

• SIEM Bloggables
• The Myth of SIEM as "An Analyst-in-the-box" or How NOT to Pick a SIEM-II?
• Log Management + SIEM = ?

 

More On Security Vendors and PCI DSS

Image by purpleslog via Flickr

This is a forced follow-up to my “Top PCI DSS Security Marketing Annoyances” post. What forced this is that a lot of folks are googling for “pci-dss market analysis”  (double laugh, if you read my previous post)!

So, let’s analyze this a bit: what creates such tidal wave of PCI security marketing stupidity is a mindset of some vendors. They keep thinking “how to sell our shit using PCI?” and not “how to help organizations with PCI challenges?” This is what drives people to buy encryption instead of not storing the data, to deploy IDS sensors with alerts going to /dev/null, to scan web sites and never fix them, etc.

It is not uncommon for a security vendor to review a report that says that “only 6% of companies under PCI DSS use a technology X mentioned in the standard” (and that said vendor happens to produce) and then think “Wow, those merchants are stupid! They really should buy out shit NOW!”  A quick question to merchants reading this: do you guys like it? :-)

The answer is obviously “NO!” You probably want said vendor to actually understand your problems with PCI DSS and then offer, well, SOLUTIONS! It is very hard for some vendor to shift to that helpful mode if they keep obsessing about the following: “Problems? What do you mean “what problems we solve?” – out bottom-line is our problem! ‘PCI-says-YOU-MUST-BUY!’” :-( 

Yes, PCI DSS does mandate the use of many security technologies and it is prudent to mention that fact, whether you are vendor looking to help others or an end user looking to gain management support. Admittedly, I’ve long called PCI our sledgehammer of both awareness and budget for information security. But you can build a house with a hammer or .. you know how this metaphor goes :-) PCI DSS has a lot of energy to motivate people to improve security, please help them do just that!

But what if a merchant’s only perceived challenge is to “make QSA go away and take his PCI thing with it?” Obviously, the other side of the coin is merchants buying something (like a Dell box with the the label “FIREWALL” taped on [source here]) just to fake validation. This is where you as a vendor must evangelize! As Guy would explain, “evangelism” is not the same as “shouting the loudest” or “lying the vilest,” it is educating and then eventually converting the customer base to your way of thinking, which also happen to be the most useful one for them as well…

Finally, if you did get here after googling for “pci-dss market analysis,” please keep in mind:

• Payment card security standard is called “PCI DSS”, not “PCI-DSS.”
• There is no such thing as “PCI market” so there is nothing to “analyze”; PCI is not for sale :-)

Enjoy!

Possibly related posts:

• Top PCI DSS Security Marketing Annoyances

Top PCI DSS Security Marketing Annoyances

I figured I’d offer some free consulting (via this blog post :-)) to all those folks that try to market some security thingy using PCI DSS.

As it happens, I just read one too many PCI-focused whitepapers and my annoyance at some vendor’s ignorance boiled over the top. This post is the result:

1. Don’t misspell PCI DSS. It is not “PCI DDS”, and even not “PCIDSS.” BTW, if you want to impress PCI literati, make sure that “PCI DSS” has a space, while “PA-DSS” has a dash.
2. Most definitely, do not pretend that you address ALL PCI DSS requirements for the only reason of wanting to look good.
3. You cannot “automate PCI.” Don’t market it and don’t sell it … or people will call you on it. Admittedly, you can automate a lot of it, but not all (think “policy and process”).
4. Please don’t say “PCI compliancy!” This is just another synonym of “I am a buffoon.” BTW, if you offer “free PCI compliancy”, then you are both a buffoon and an idiot :-)
5. Don’t call QSA (Qualified Security Assessor) “an auditor.” That “A” does NOT stand for “auditor” and PCI on-site assessment is not the same as, say, SOX audit.
6. Further, if you want to market to QSAs or ASVs, spent a few minutes learning what they actually do, which is which, etc. Helpful hint: QSA is not the same as a pentester :-( As per Requirement 11.3, QSA must ”obtain and examine the results from the most recent penetration test to verify that penetration testing is
   performed,” not go and ”just do it.”
7. “Ongoing compliance” theme is awesome. Sadly, a majority of your customers don’t do it like this (to their own loss – this why it is sad). They still have assessment-time rush, pleasing the assessor approach and checklist-oh-we-are-DONE! mentality. If you want to sell continuous compliance, you need to educate them first!
8. Don’t pretend that “PCI is about data encryption.” It is not! If you have to have some simple one-liner, use “PCI is about not having card data sitting around” instead.
9. Please don’t write whitepapers that are structured like this: “section 1: this is PCI”, “section 2: this is our shit”, “section 3": our shit is great” (and, no, it has only very, very tenuous relation to PCI DSS…). Specifically, don’t say “these are PCI-compliant features of our security product.”
10. If you mention cloud computing in your PCI marketing materials, think – very hard! - whether the rest of the content has ANY relationship whatsoever to it…
11. Finally, if you are building the dreaded matrix of how your product magically makes everything PCI compliant, try differentiating between features that directly satisfy requirements vs those that enable somebody to eventually reach compliance vs those that simplify compliance validation. Your users and their QSAs will thank you for it!
    
12. UPDATED (thanks Walt!) There is no such thing as "PCI certified" either. PCI validated is what you are likely trying to say. TO add to this, there are no "PCI validated" products, only companies or organizations.
13. UPDATED (thanks Walt!) Please also forget about "selling into PCI DSS market." This is simply your insanity talking :-) PCI might be a driver, might be some other motivation for buying stuff, might be the regulation du jour, etc. But it .. is ... not ... the ... market.

Overall, unless your goal is humorous relief of people working on PCI projects, please pay attention…

Enjoy!

Possibly related posts:

• All PCI DSS coverage.

Obligatory “added everywhere” posts :-)

• I am not at Qualys anymore and looking for the next big security idea to work on! I might be available for consulting projects…

Watch Ma .. A Blog Fight!

Always a suckler for a good blog fight! A subject is a bit dumb (“Is security a cost center?”), but still, this one is fun to watch:

1. McAfee, who should know better, starts it: “Is information security compliance really a cost center?” - “No. Absolutely and unequivocally not. I am drawing the line in the sand.” Read the rest here, even though it gets t sound pretty darn stupid at times (example: “ … makes it obvious that it is better and more efficient to be compliant as a business” – uhu… go tell it to all the small businesses trying to avoid PCI DSS)
2. First, Hoff kicks them in the balls (in their comments, no less): “If security compliance isn’t a cost center, are you then suggesting it’s a profit generator? So on the balance sheet it shows up as a revenue generator or profit center?”
3. Next, enlightened-not-insane Mike Rothman dropkicks them in “Compliance is SO a cost center” – “OMG. I figured a big company like McAfee would have a drug testing policy, but evidently not. I want some of what this guy is on” and even “A "Compliance Driven Company" is the next Heartland or TJX”, “CEOs don't care about security or compliance” and – fun! – “And even better, they don't want to spend money on avoiding either of those cases because it's not going to happen to them. Seriously. They see the headlines, they ask some questions about whether they are "secure," the CSO lies to them, and they go back to their mahogany conference room and check on the sales numbers.” He then ends with “Like I said, Little Red needs to check what's in this guy's water bottle. It ain't water.“
4. Finally, Pete runs, jumps in the air and lands on the McAfee guy ("Security Insights Draws Security Incite"): “It is entirely misleading to suggest that "information security compliance" is NOT a cost center. That smacks of a misunderstanding of exactly what a cost center is.” He then again jumps and lands with “I have a HUGE problem with this statement: "...a good business leader needs no justification to do to the right thing." It is so laced with b.s. that the cows are lining up in the barn waiting their turn.”

Enjoy! This whole thing makes me so want to kick them too, but I think there is a law against kicking the dead horse or something :-)

Also, this sooo reminds me of the ROI wars last year.

I will add to it, if this grows.

More on "Enterprise-Class" (or Enterprise-Quality)

Mike R makes what I consider to be an absurd claim here: "... How can Baracuda sell an anti-spam gateway for $3000 and other vendors sell a similar product for $50,000? Is the other product 15 times better? Of course not. But the enteprise customers in an early market can afford $50K per box, so that's what you charge them. "

Honestly, I am not sure about the anti-spam gateways, they might be all the same indeed (and so Mike might actually be right about that specific type of a product...), but I can tell you that in log management the answer "Yes, it is that much better in features that actually make it 'enterprise'" - see this five-part treatise on that very subject by our enlightened System Engineer Dimitri McKay.

You can get Sawmill for $0, you can get whatever other product for $5k - or you can get LogLogic. The difference in what you will get will be about the same as the price factor!

All this debate is BTW inspired by this RSA-related piece.

NAC Vendors Starting to ... You Know ... Die?

I really wanted to play some kind of joke on vendor being "knacked off," but all sounded too stupid to post here :-) In any case, some people were saying that there are way too many NAC vendors around, especially given slow adoption of this technology. Now they have proof.

Now, it is a sad thing to see a security company "go poof" and I am sure this one had good people, but I think certain market common sense should apply... For example, I know some people who want to launch a DLP vendor. Now, if their data loss "prevention" technology is better than anybody else's, they will probably fail. However, if they looked at the problem from a different angle and solved some of the challenges that nobody can touch (and which are real), now we are talking....

I Should Really Not Touch This ....

... I really should not. But - darn it! - how can I miss a potential blog fight related to log management?

So, it seems like Raffy baited some poor folks from Prism with his post on "IT search" (what an abomination of a term!). But, seriously, "IT search" is a marketing term (nothing wrong with that, BTW!), so it will mean whatever the folks who coined feel at any given moment. I really hate it when folks try to argue objectively with a clear fluke.

I think this debate is mostly about two approaches to logs: collect and parse some logs (typical SIEM approach) vs collect and index all logs (like, ahem, "IT search").

You can see where this one is going, right? :-)

Yes, Virginia! You do need to do BOTH - and you know who does both? LogLogic!

Guide to Hating Competitors

So, inspired by Andrew Hay post (here), I figured I'd expand a bit and create "A Brief Guide to Hating Competitors," a marvelous piece of vendor propaganda :-)

Indeed, many of my fellow vendors are fun and smart people, some are also friendly :-). Sharing technology and sometimes even market insight with them - while having your competitive market positions and IP concerns in mind - is perfectly fine, in my estimation.

However, there are certain vendor behaviors that, in my world, can trigger a prolonged hatred. These are (ALL were observed in real world - some not by myself...)

1. Super-unethical selling: fake references (I saw a vendor give a phone number of their own sales engineer as "here is a number for our reference government customer"...), direct and known lies, etc
   
2. Hacking the competitor's website and other online resources (e.g. support site) or accessing them using stolen credentials
3. Stealing evaluation gear/software from a side by side eval project at a prospect site
   
4. Other examples of direct IP theft (once I saw this done using a VC firm as a cover)
5. A few other things that SCIP folks would frown at.
   

Any additions? Thoughts?

UPDATE: fun follow-up post from Mike (and a bit more here) with more nefarious activities by vendors ... Yuck!

More Vendor on Vendor Action

Want more vendor on vendor action? This one is kinda fun: one unnamed security vendor "hacking" (well, sort of) another unnamed security vendor to harass their customers.

The reason? As dumb as a hidden form value and HEX "encryption". You think nobody is that dumb [in security business in 2007]? Think again...

Hot Vendor on Vendor Action :-)

Bua-ha-ha-ha-haaaa! I am NOT the only one seeing this: TK from nCircle just reported this as well...

Do You Compete with Dumbasses? A Simple Test for Security Vendors! :-)

Here is a fun test for my fellow security vendors. Using this test you can reliably determine if your competition is a bunch of loser dumbasses, who will soon fail and thus leave the market for you to own.

So, here comes "The Test":

1. Launch your web browser while sitting in the office at your headquarters
2. Type your competitor's URL in the address field and press 'Enter!'
3. Observe the result

What might you see, you'd ask? Well... the question is not as simple as you think. The choices are:

1. An appropriate website (duh!)
2. An old version of their website announcing version 1.1 of their product back in 1998
3. An unrelated website (possibly p0rn :-))
4. Nothing, the connection fails or times out

Not try the same from home - you are most likely to see the actual website (same as #1 above).

If, while doing it from the office, you see anything from the range of #2-#4, congratulations: you compete with dumbasses!

He-he :-)

Vendors, Lies and Users :-)

A vendor talking about lying vendors? Woooo, that's fun, you might think :-) Indeed, I won't disappoint you...

I hate it when vendors lie; I really do! But my 0xBEEF :-) with it is somewhat different than Mike Rothman's (and here too). Or Alan Shimel's, for that matter. I specifically hate it when competitors lie. I had this experience where a certain competitor was presenting [absurd] lies, pretty much in my face. What pond scum! But what do you do? Confronting them felt below me, letting it stand wasn't too good either... The only easy "solution", of sorts, is to rely on this principle "liars always get caught… eventually", highlighted here.

However, as luck would have it, their customer stood up and confronted them: "What? Easy to use and manage? It took us 9 months to deploy and we are not done yet!"

It sure felt good! :-)