Aug 28

ceo, cfo, pants on fire?

By alberg CSO, useful stuff No Comments »

A recently published research paper entitled “Detecting Deceptive Discussions in Conference Calls” provides an interesting look at lies and the liars who tell them (in this case, company CEOs and CFOs) as well as a peek into the future of of lie detection in general.

For this paper, the researchers decided to look at a group of statements by CEOs and CFOs in quarterly earnings conference calls held with investors.  They specifically wanted to focus on the times when fibs may have been told on these calls.   In order to find these occasions, they looked for cases where companies had to restate their financial results after the calls, or had to disclose other information such as material weaknesses in controls, late filings, changes to auditors, or form 8-K filings.

The researchers got hold of all available transcripts for US quarterly earnings conference calls between 2003 and 2007.  The transcripts were formatted in XML, making them a lot easier to parse.  Next, they broke down the transcripts, ignoring the “Management Discussion” parts which are presumed to be heavily scripted and vetted by legal, investor relations, marketing and other corporate types before a word is uttered.  That left the “Question and Answer” parts of the calls, which tend to be more spontaneous (hence providing more opportunities for questions leading to prevarications to be asked).  Finally, the statements of the CEOs and CFOs were isolated for analysis.  The researchers presumed that the CEO and CFO would know the true state of the company, thus providing them with opportunities to fib to investors during the Q&A.

After analyzing the data, they found that when executives fib…

  • They make more references to audience or general knowledge – “As you know…”
  • They use more words linked to extreme positive emotions – “The outlook for the company is fabulous!”
  • They make fewer references to shareholders value and value creation
  • CEOs in particular make fewer references to themselves and use more third person and impersonal pronouns.  They also use fewer words indicating non-extreme positive emotions as well as fewer “hesitation words” and words indicating certainty.
  • Interestingly, when CFOs tell lies, they tend to use more words indicating certainty

While the study itself was fascinating reading, I also found the authors’ summary of the different perspectives on deception noted by other researchers in the field.

From an emotional perspective, deceivers are thought to feel guilty about their deceptions and have a fear of being caught in their lies.  This leads to negative emotions, and a negative affect.  According to this perspective, deceivers will make more negative comments, use more general terms and avoid referring to themselves.  Their statements will tend to be short, indirect and evasive.

Taking a cognitive perspective on deception highlights the fact that it takes mental energy to lie and keep one’s story straight.  This perspective  suggests that deceptive statements will use more general terms and lack specific details.  Again, the deceiver will avoid referring to themselves and will avoid mentioing personal experiences.  Statements will tend to be shorter, to minimize the amount of keeping track that the deceiver must perform to make their narrative consistent.

Looking at deception from an attempted control perspective focuses on the deceiver’s efforts to avoid making statements which would expose their lies.  This perspective also expects deceptive statements to have non specific language, few self references, and short statements with little real detail.  The deceiver may inject irrelevant information into his or her statements to distract their audience.  If the deceiver is well prepared, there will be more specific information, and fewer of the natural hesitations found in normal speech.   This perspective also looks for lexical diversity as an indicator of deception; people telling the truth tend to repeat themselves, while deceivers seem to use a more varied vocabulary.  Maybe this is why it is interesting to listen to storytellers and other “professional deceivers.”

The final perspective on deception is that of lack of embracement – in this approach, the deceiver feels uncomfortable telling a lie and appears to lack conviction in what they are saying, mainly due to the fact that their claims are not in line with their experience.  Again, speaking in generalities, few slef references and short answers would be expected from a deceiver operating under this framework.

I had a few take aways from this paper:

It gave me a rational basis for the “gut feelings” we have when deciding whether a person is telling us the truth or not.  I will be a lot more conscious of the structure and content of statements when making these evaluations.

I also see this type of research, when combined with technologies such as pervasive digital recording and speech recognition, as possibly marking the beginning of a time when many of the statements we make will be automatically dissected, analyzed and evaluated (possibly in real time) to indicate whether statements are true or deception.  Like any other lie detection technology, this must be used with a clear understanding of its limitations.  A few years ago, we were told that voice stress analysis would make it possible for our phones to tell us when someone is lying in real time; the technology has not lived up to the hype.  A lot more research needs to be done here, but I think we are going to be hearing a lot more about this topic in the future.

I mean, would I lie to you?

  • Share/Bookmark
Aug 16

so long, SAS70!

By alberg CSO, best practices Comments Off

SAS70 season - the most wonderful time of the year!

Since 1992, many organizations have relied on SAS70 audit reports to determine whether their service providers’ controls are appropriately designed and effectively implemented. 

In the information security field, the SAS70 has become the unofficial standard for how service providers provide assurance to their customers that their systems are safe and secure.  This is not what the SAS70 was originally designed to do – SAS70 reports are supposed to focus on financial matters, but the people have spoken.

Since my employer is a service provider, we conduct an annual SAS70 Type 2 audit with an external audit partner.  We then provide the resulting report to our customers’ information security and risk teams to help convince them that they can trust us with their sensitive information.  This is pretty typical for the industry.

It is important to remember that the SAS70 standard simply describes the format for the report produced by the external auditor.  There is no such thing as being “SAS70 Certified.”  It is even more important to realize that the scope of the SAS70 report (in the form of the list of controls to be tested) is pretty much up to the organization being audited.  If the organization does not want to test certain controls, they can simply leave them out of the report.  For this reason, when evaluating a SAS70 report from a vendor, you need to read carefully – what is not said in the report is probably even more important than what is included.  (very zen, don’t you think?)

The new SSAE 16/ISAE 3402 standards which took effect in June of this year are meant to replace the SAS70.  SSAE 16 is the US version of the standard, while ISAE 3402 is the international version.   These new frameworks do provide some improvements over SAS70 for those evaluating outsourcers.  I am pleased with two of the changes in particular:

  • While the SAS70 was centered around the description of controls, SSAE 16/ISAE 3402 adds a requirement to include a description of the system being audited.  This description must include transaction flows as well as significant non transaction events.  While this is going to mean more reading for the recipient of a report, it also provides the recipient with much better context to evaluate whether the controls described later on are sufficient.

 

  • The new standard also requires organization to do a risk assessment and make sure that the controls that are reviewed address the risks to the system described.  The service provider does not have to include the risk review in the report, but the auditor will be looking for risk/control linkages during the review process.  I think that this is a good thing, especially for smaller service providers who may not have a mature enterprise risk management function, as it will force management to take stock of risks in a systematic way.

While these are welcome changes, they do not really address what I think is main problem with SAS70 as an information security assurance tool – the lack of common objective criteria to be assessed.   The approach that I have taken in the SAS70 that I am responsible for is to map out all of the controls described in the report against the ISO 27002 standard, which provides provides  ”established guidelines and general principles for initiating, implementing, maintaining, and improving information security management within an organization.”  While my shop has not gone through the formal certification process for 27002, I feel that using the standard as a framework provides the readers of our SAS70 with some additional assurance that we are including all of the relevant infosec controls.

So, as we bid a (somewhat) fond farewell to SAS70, I look forward (somewhat) to our new, improved minty fresh SSAE 16 reports.  My company will be doing our first SSAE 16 early in 2011 – I’ll report back on how the process differs from what we have done to date.

  • Share/Bookmark
Jul 10

who’s watching the watchers? in this case, nobody

By alberg CSO, worst practices Comments Off

Friday’s Wall Street Journal featured a page 1 article (unfortunately behind a subscription paywall – less detailed but free coverage here, but you can get the full WSJ article by searching Google News for “HSBC data theft”) on a massive theft of private banking client data from HSBC.  The thief was… wait for it… an HSBC infosec employee whose job it was to improve the security of the systems and databases holding that data.  Said employee then shopped the data around to a number of European tax authorities as well as to competing banks.  When the French police raided his parents’ home in France as part of the investigation into the theft, the data was turned over to the French tax people, resulting in collection of 1 billion euros from les tax evadeurs.  Now the French tax people are sharing this treasure trove of data with their colleagues in other countries, who also expect to collect lots of back taxes.

Of course, the guy at the center of this claims he was not in it for the money – he wanted to point out flaws in HSBC security or help catch tax evaders or was working for intelligence services.  (He can’t seem to decide on which story to go with…) In any event, he denies any illegal activity and stated that he copied the data to his personal computers and offsite servers as part of his normal work.  HSBC states that it is against company policy to copy such data to non HSBC computers.

The story is quite interesting and raises a number of questions for security pros, organizations and law enforcement (as well as folks who like to stash their cash out of sight of the tax man).

Is France’s use of the ill gotten data and it’s further distribution of what is in effect stolen property a legitimate tool for government authorities? While there is a social good in collecting these taxes from the rich tax evaders, is this benefit outweighed by the message it sends vis a vis the rule of law?

Why was this very sensitive data not protected by some sort of DLP solution or even just old fashioned auditing and log review on the database server? Someone looking at a log and seeing this guy perform SELECT * on a sensitive database was all that would have been needed to detect this crime.

Why did this employee even have access to this data? I can’t see how his job function (in a properly designed technical and procedural environment) required the ability to view and copy database information.  Changes and testing of security for that database should have been done in a separate QA environment using test data and then staged to production by another party.

My final question is one for the security community… Where does our fiduciary duty to our employers end and our responsibility as citizens start? In this case, I think that the HSBC employee was clearly in the wrong.  HSBC was offering a service to it’s clients which is perfectly legal under Swiss law.  The users of the service had a responsibility to report their income to their taxation authorities under the current regime.  If the employee had a problem with the world of private banking, he should have gotten into a new line of work rather than resorting to theft.  As for his claimed pure motives, I would have a lot less trouble believing him had he not shopped the data to competing banks.  I’d also point out that it would have been reasonable for him to expect some sort of renumeration from the tax authorities for his “aid” in collecting lost revenue.  His stories just don’t seem to add up.

It is important to note that this is not a problem unique to HSBC – the lapses that led to this data theft are extremely common across all industries.  Heck, even the US military has data stolen through loopholes in data protection policies (and Lady Gaga).

This case is a great learning opportunity for security and risk professionals – organizations need to remember that security personnel are human and need to have appropriate controls placed on their systems access as well.  In most organizations, the Internal Audit group can provide this oversight.  Smaller organizations may need to resort to periodic reviews of internal security by an external consultant.  In any case, make sure someone is watching the watchers!

Update 2010-07-10  2010 – Just noticed that US tax authorities are “ramping up” their investigation into whether HSBC marketed tax evasion services to US clients.  Now, if they did engage in this activity, shame on them.  However, if the allegations are found to be true, it still does not transform a data theft by a person in a position of trust.  Had the employee involved simply contacted authorities with his concerns, the data could have been gotten by the authorities.  And his shopping the data to competitors still sticks in my craw.

  • Share/Bookmark
May 02

massachusetts kicks data protection butt!

By alberg CSO, best practices, online security Comments Off

Data protection... Massachusetts style

Now I have two things which I really like about Massachussets – The Friendly Toast in Cambridge (mmm… Caribbean waffles) and their new data protection law.  As of March 1, any organization which holds personnally identifiable information (PII) about residents of the Commonwealth must attest that they have a written information security plan designed to protect that information.  And that PII maust be encrypted both when it travels over the wire and when it is stored in systems.  Penalties for violation are quite hefty – $5,000 per violation and per record lost.

The law also requires businesses handling MA residents’ PII to take a number of steps that they should already be doing – having someone responsible for the infosec program, identifying risks, training personnel, preventing terminated employees from accessing the PII, secure authentication and the like.    You can read the entire text of the law here…

It is about time and I hope that other states (and the federal government – call me a socialist) follow Massachusetts’ lead.  Requiring businesses to take some very basic and inexpensive steps to protect our information from unauthorized access is quite reasonable.    It seems to me that complying with the encryption requirements can be accomplished via an SSL cert, laptop encryption software (such as BitLocker, included with Windows 7 or FileVault on Macs), and use of database encryption features are just common sense, as is having an information security plan.

Bravo, MA!

  • Share/Bookmark
Apr 25

when was the last time we retired a security control?

By alberg CSO, deep thoughts Comments Off

This weekend, I attended the Security B-Sides Boston conference  (which, by the way, I heartily recommend to all info sec types).  My favorite session of the day was Josh Corman‘s “Fsck the FUD” talk… this talk was chock full of security thought leadership goodness and will probably result in a number of blog postings here at Paranoid Prose.

In his talk, Josh asked a really thought provoking question:  When was the last time that the information security community retired a control?  If you take a look at lists of recommended security controls from 10 or even 20 years past, you will see many of the same measures that are found in the latest PCI, COBIT and other prescriptive documents.  Each year, a few new must have controls are added, much to the chagrin of CSOs and security personnel (who then have to spend more of their limited time and resources implementing new controls as well as maintaining existing ones) and to the delight of auditors (who get job security and longer audit checklists to fill out, and thus more billable hours).  This approach of continuous “improvement” of security “standards” is just not scalable, given most organizations’ unwillingness to fund the corresponding infinite growth of security resources (how unreasonable!).

Why is this happening?  Josh’s theory (with which I agree) is that auditors and standards writers tend to be very conservative.  In their minds, once a control is written down, it becomes revealed truth, and having more controls must ensure a higher level of security, right?  As a result, many organizations (especially those in heavily regulated industries like Finance, Health Care and payment card processing) seem to fear their auditors more than the attackers who the security folks are supposed to be fending off.   We have to make sure that we can check all of the boxes and get “good grades” on our audits and assessments, whether or not the controls being tested are relevant and provide real protection.

This model leads to a stifling of innovation in the info sec industry, according to Corman.  Since most info sec spending is concentrated around passing audits and fulfilling regulatory and compliance requirements, we continue to spend most of our time and money on legacy controls which may or may not be very effective at addressing evolving (and quite dangerous) threats.  We get that warm and fuzzy feeling from passing the audit, but that does not necessarily mean that we are well protected.  Security vendors respond to this pattern and concentrate their product offerings in spaces which address the tried and true controls they know that their customers need to meet.  They are simply not incented to come up with new ideas and better products and their marketing departments spend most of their time figuring out how to spread FUD and convince CSOs that their existing products somehow address the mind numbingly scary threat du jour.

A couple of examples come to mind:

Anti malware software - signature based anti malware software is having a harder and harder time keeping up with the threats we expect it to protect against.  More and more evil code is produced from toolkits which generate custom versions that differ from the AV vendors’ signatures just enough to slip by the defenses.  In a number of recent cases, totally customized, highly targeted code has been used to infect machines of interest and extract valuable information.  It seems to me that signatures are becoming less and less effective as controls against malware and that protections based on system behavior make much more sense.  Yet we still buy, deploy, maintain and update lots of signature based AV software, so that we can check the proper audit boxes and vendors don’t have real incentive to come up with new and more effective defensive products.

Passwords - One of the most frequent complaints I get from users at my company is that our password policies (long passwords with different types of characters that need to be changed pretty frequently) are a pain in the posterior.  I feel for them… complicated passwords that are changed frequently do provide protection against some threats, but it seems to me that the main threat to passwords today is malware which grabs the password as it is typed – and it doesn’t matter how long, complicated and frequently changed the password is.  Yet, we still enforce our password policy.  Part of the reason is that the policy does provide a certain level of protection against some threats, but in reality, we have kept the policy mainly because our business partners (customers, regulators, etc.) expect us to have such a policy and would look askance at us if we didn’t.  (In spite of recent research suggesting that the negative economic effects of these policies may exceed their protective benefit).

So… what do we need to do as an industry?  I think we need to start a dialog in which we take a long, hard look at the security controls we “require” and answer some key questions about them:

  • What is the threat that this control addresses?
  • Is the threat we are protecting against still a threat?  If so, has the nature of the threat changed significantly?
  • How can we update the control requirements to better address the threat using currently available technology or processes?
  • What new technology (if any) do we need from vendors in order to address the threat as it stands today?

The big question is how to get this discussion going… conferences like Security B-Sides, Defcon and the like are great places to start talking, but we need to find a way to get the mainstream security media and standards bodies to participate… going to be giving this a bit of thought and would love to hear from you with ideas!

  • Share/Bookmark
Apr 19

monday volcano news roundup

By alberg CSO, travel security Comments Off

From the BBC News website…  this map shows today’s ash situation… does not look too good as far as trans Atlantic flights from the States to Northern Europe and vice versa, but I am hearing that some trans Atlantic services are resuming (see @AirlineRoute  for updates). 

However, it looks like the European travel situation should be getting better tomorrow, as the EU replaces a blanket ban on air travel with a more focused and layered approach.  European air space will be divided into sectors described as “no fly zones,” “limited service zones,” and “open airspace,” based on the amount and dispersion of ash from Iceland’s volcano, according to the BBC.  I get the first and last categories, but I don’t know that I would want to go on a flight in the “limited service zones” – does this mean they are sorta safe?   In a press release issued today, Eurocontrol (the air traffic agency for the EU) had this to say… 

  

“…while the initial reaction by the States was prudent and reduced risk to an absolute minimum, it was now time to move towards a harmonized European approach (set out below) that permitted flights – but only where safety was not compromised… Accordingly a limited “No-fly zone” will be established by the States concerned, based on forecasts from the VAAC. EUROCONTROL will provide the data and the forecast to States every 6 hours.  Aircraft Operators will be permitted to operate outside this zone. In their decision as to whether to fly, they will be supported by shared data including advice from the scientific community (meteo, volcanic ash proliferation etc.) – including safety assessments supported by tests under the oversight of the competent Safety Authorities.  The conference also concluded that, in time, it should be possible to move towards an approach in which full discretion is given to Aircraft Operators.” 

Earlier today, a mislabeled webcam in Iceland led to false news reports of yet another volcano erupting.   Turns out that it was the same volcano continuing to erupt.  D’oh! 

Looking for some stories and advice from the people affected by this whole mess?  Searching for #ashtag on Twitter yields a fascinating real time look at what’s going on – and makes you glad not to be traveling…”

Oh, and by the way, here is how (and how not to) pronounce the name of the Icelandic volcano… 

  • Share/Bookmark
Tagged with:
Apr 18

don’t want to make an ash of myself…

By alberg CSO, best practices, travel security Comments Off

One of my responsibilities at work is to make sure that our employees are safe while traveling.  Until today, this week’s Icelandic volcanic eruption was a no brainer… flights in the affected area were cancelled for safety reasons.  Now, the airlines and the EU have been performing test flights to see if it is possible to restart flights in Northern Europe in spite of the continuing eruption.  KLM flew a plane (with no passengers on board) from Duesseldorf to Amsterdam on Saturday without incident, although at lower altitude than normal.  Similar flights by BA, LH and AF also landed without incident.  Given the magnitude of the economic losses and travel chaos being caused by the cessation of air traffic, I can understand why folks are anxious to get planes back into the air.  However, not everyone is a fan of this plan… the Finnish airforce ran their own tests using F-18 fighters and concluded that even short term exposure to the ash cloud caused damage to the planes’ engines.  And tests run by NASA showed that even very thin clouds of ash could significantly damage jet engines.

So… what if the EU decides to reopen Northern Europe’s airspace?  What travel advice do I provide to my colleagues?  Should people currently stuck waiting for flights to or from the region take one of the first flights?  Personally, I would not be ready to get on a flight to LHR today if the air space were to reopen whilst Eyjafjallajökull is still being uppity.  And I would be hesitant to get on a plane which had flown through the ash for some time after the eruption ceases, since damage to engines may manifest itself over time.  For now, the airways are still closed, so this is a hypothetical question.  But if the EU and airlines decide that the risks are acceptable, people are going to want to get home or make trips for business.  Coming up with a travel policy which balances risk with the need to conduct business is going to be a challenge – especially if this eruption continues for a long period of time or if it is a precursor to a much larger volcanic event.  Stay tuned…

  • Share/Bookmark
Apr 07

the maley affair take two

By alberg CSO, best practices Comments Off

So after meeting Bob Maley, the former CISO of the Commonwealth of Pennsylvania, at this week’s CSO Perspectives conference in Santa Clara, CA, I am having some second thoughts regarding my earlier posting regarding his firing.   While I still feel that the Commonwealth was technically within its rights in firing him, it seems to me that the people of Pennsylvania were done a disservice by the Commonwealth’s actions. Bob seems very passionate about the responsibilities of stewardship of citizens’ information and it sounds like he implemented a number of impressive initiatives to better protect that data.  Yes, he did speak at RSA in spite of being told not to, but it seems to me that his heart was in the right place and that he took a calculated risk in order to highlight the need for application security in e-government.  There also seems to be a political element t0 all of this (transition of administration stuff) as well.  In the end, after meeting the guy, I came away impressed that he was willing to gamble his job (and lose that gamle with grace) in an effort to make e-gov initiatives safer for us all.

The nice folks at CSO Magazine published a good article on the topic… read it and decide for yourself.

  • Share/Bookmark
Apr 06

of notebooks and ipads

By alberg CSO, best practices Comments Off

Disclaimer to those of you reading this at my place of employment:  Nothing in this post indicates a change to any existing corporate infosec policies… it is simply my first step in trying to figure out how to deal with those meddling kids and their durn iPads!

Just about everyone at my workplace carries around a notebook (of the dead-tree variety) to take notes during meetings.  I’m sure that in the wrong hands, access to said notes could reveal information about the company that would better be left unrevealed to those outside our little commercial cabal.  However, I have not (and would not, for fear of snickering) sent out an email warning employees not to use unauthorized paper based storage devices in the course of their work.  As much as I would love to have a data leakage protection client (in this case, a security guy reading everything written in said notebooks as it is written and tearing out offending pages) and remote data destruction capabilities (security guy who sets notebook on fire if it is stolen), both the company and the employee might have some legitimate concerns about such an arrangement.

Which brings me to the iPad.  I have using my shiny new iPad for the past few days to take notes at the CSO Perspectives 2010 conference and have come to the conclusion that it is a great device for the consumption of media as well as a great note taking tool.   Which begs the question:  How are notes taken on an electronic device (iPad, non company phone, non company laptop) different than those ensconced in dead-tree notebooks?  

In some ways, a properly configured electronic device (one with a password required for access) seems to be a more secure note taking device that the trusty Moleskine.  Should a nefarious person acquire my Moleskine, the only barriers between them and any juicy secrets contained therein are my atrocious handwriting and my use of eccentric and non standard abbreviations.  Should the same evildoer swipe my spiffy new iPad, they would get 10 tries to guess my device passcode, after which all data on the device would be erased.  Now, the passcode is only a 4 digit number, but the odds are that it would take more than 10 guesses for our evildoer to come up with the code.

Add the cloud, in the form of Evernote and other such services, and the issue gets a bit  more complicated.  Evernote has a great iPad app which allows you to take written and audio notes on the iPad, attach files to those notes and sync them with servers somewhere in the cloud.  I love Evernote for personal stuff – it allows me to access notes from multiple devices and serves as an upgrade to my meatware memory.  Of course, as a security professional, I know better than to save anything work related in my Evernote account.  The web based Evernote client means that our hypothetical evildoer could access all of my notes (and search for the good stuff) if they could guess my password.  I am not so sure that all of my colleagues would make the same risk/benefit calculation that I have.

So, as a paper notebook replacement, iPad seems to provide a reasonably secure place to take and keep personal notes if it is properly configured with a reasonable passcode and data erasure feature.  It is important to understand that the protection provided by this configuration is not absolute… a variety of tools exist for the iPhone/iPad platform to extract data from these devices sans passcode, so a determined attacker will be able to get at your notes.    My plan for the iPad as a notebook replacement?

  • Configure a passcode and data delete policy as well as auto locking of the device.
  • Using the device only for notes that I would be comfortable having written in my old Moleskine.
  • Being aware that the security of notes in the cloud is outside of my control and not entrusting corporate info to cloud services.

Next step… how to communicate this use case to business people whose main focus is doing business… I feel another blog entry coming on here… but my next iPad piece will focus on another aspect of the device – as a way to carry around (and share) content.  Stay tuned.

  • Share/Bookmark
Mar 25

a plea to security vendors…

By alberg CSO, worst practices Comments Off

Have I got a deal for you...

Every day, I get at least 5 emails from vendors wanting to set up a meeting or web demo of their latest and greatest product as soon as possible.  Of these, two or three will be totally unrelated to security.  The rest are security related, but almost all of the messages are obviously canned (some with the wrong salutation as a result of mail merge errors).  The vendors sending them have no idea what my company does (no, I don’t care about PCI compliance as we are an institutional brokerage) and tend to be from obscure companies.  I usually ignore these messages, and block the sender from further contact.

Every once in a while, a vendor does something to distinguish themselves from the pack… the other day, a salesman for a vendor who shall remain nameless sent me a canned “I would like to arrange a meeting with you” message, which I opened, looked at and deleted.  There must have been a web bug in the html, because this email was followed by a message which stated that the salesman “noticed I had read the email” and reiterated the request for a meeting.   Bzzzzzt!

I find this kind of behavior invasive and creepy and that particular vendor will need to be offering a machine that turns water into gasoline before I will want to talk to them ever again – and I would insist on a different salesperson.   It is one thing if I visit your web site, provide my contact information and give you permission to email me, but to spam me and then spy on me puts you and your company on the fast track to al-blivion as far as I am concerned.

Salespeople, I understand that you guys have a tough job and that recent economic conditions have made that job tougher.  But please realize that sending spam (while quite effective for dodgy pharmaceutical sales, offers of great wealth from Nigerian princes and attempts to infect PCs with malware) is not how to sell enterprise security products that cost tens or hundreds of thousands of dollars.  Want to sell to me?  Get a good reputation and good PR – I will find you.  If you are going to contact me, take a few minutes to learn something about my company before you email.  And don’t cold call me – all I can think of when I get a cold call from a salesman is Jack Lemmon in Glengarry Glen Ross.

Rant over…

  • Share/Bookmark
Previous Entries
preload preload preload