Maybe I should be certified…

…or at least put in a home for retired security pundits where someone can make sure I take my medication on time,  but I intend to go on blathering about security issues for a while yet. (At any rate as long as ESET continues to pay me to pontificate.)

Nevertheless, it’s officially the end of an era, though a very minor ripple on the surface of the Sea of Security. As of the end of August 2014, I will no longer be entitled to put the acronyms CISSP, FBCS, or CITP in my signature. (In fact, I haven’t been using those manifestations of alphabetti for quite a while now, in anticipation of this day. Or, more precisely, the 31st August.)

There’s nothing sinister about this: I haven’t been drummed out of (ISC)2 or the BCS Institute for conduct unbefitting a computer security guru: I’m simply dropping my annual subscriptions to those organizations. I’m still in sympathy with the general aims and ethics of both organizations. There are many otherwise rational people in the security business who are dismissive of any form of certification that results in an artificially lengthened signature, but I’m not one of them. These particular acronyms acknowledge many years of working to improve the security of the organizations for which I’ve worked since 1986 and the community as a whole: I’m honoured by that recognition of whatever I may have achieved in that time, and refuse to be ashamed of having been entitled to use them. So why am I letting them go?

First, let me save you anxiously searching the web for an explanation of all those acronyms:

  • CISSP = Certified Information Systems Security Professional: a certification awarded by (ISC)2 (formerly the International Information Systems Security Certification Consortium) to security professionals who meet the required criteria in terms of knowledge (as tested by a lengthy exam), relevant experience (at least 5 years), compliance with the ISC)2 code of ethics, endorsement by a member in good standing, and maintenance of your own good standing by earning at least 20 CPE (Continuing Professional Education) credits and keeping up to date with the subscription fee.
  • FBCS = Fellow of the BCS Institute (formerly the British Computing Society): to quote the Institute’s own criteria, Fellows “demonstrate leadership in the profession by influencing significant numbers of professionals and/or others to achieve common goals, understanding or views within the IT profession.” So maybe all those books do count for something, even if they didn’t benefit my bank balance much.
  • CITP = Chartered IT Professional: I was actually grandfathered into this certification, also awarded by the BCS Institute, because I met the requirements for acceptance as a Fellow. I’m not sure if BCS still does that: the normal certification process is quite stringent, and has in fact been made more demanding in recent years.

So, to answer the question “why am I dropping my subscriptions?”, I first have to make a confession. I didn’t maintain those subscriptions out of some purely altruistic desire to further the aims of (ISC)2 and the BCS, though of course I’m happy that my money went towards the attainment of goals that I’m generally in sympathy with. But – shock! horror! – my primary aim was to demonstrate that I have certifiable skills and acknowledged achievements that gave me credibility in the eyes of my peers and enhanced value in the job market. Like most people, even the good people who run (ISC)2 and the BCS (not to mention other organizations like ISACA and SANS), I have to make a living, though I’m fortunate in that I can do so by doing work that I enjoy and (I like to think) I have some ability. Over the last year, I’ve made a cost/benefit analysis (as all CISSPs are taught to do!), and while the cost of those subscriptions isn’t high, the benefits are not what they were:

  • I’m already past the age where I could, if I chose, be drawing my state pension. When either ESET – where I still hold the title Senior Research Fellow – or I choose to terminate our current arrangement, it’s unlikely that I’d look for another job. If I did, it probably wouldn’t be in security. And if it was in security, it certainly wouldn’t be the sort of managerial role where being a CISSP is sine qua non.
  • I haven’t been seriously engaging with BCS for some time, at any rate not at the level where being a Fellow matters. And I don’t see myself as a candidate for the sort of academic milieu where being FBCS might carry weight.
  • I no longer find it amusing to flaunt my alphabetti on those lists where it’s assumed that anyone with the letters CISSP after their name must be either a cheat or an idiot with delusions of grandeur and competence. Or, according to one person who commented on one of my articles for ESET, as compensation for underdeveloped genitalia. I can’t imagine how he knew. 😉
  • I actually have certifications that don’t entitle me to a string of acronyms. Not that I’m likely to look for work as a security auditor (for instance) at this stage, but perhaps it’s time to relegate all this stuff to my c.v., which I haven’t needed for a long time now and don’t anticipate needing much in the future. And wikipedia, maybe. 🙂

So from now on, I guess I’ll have to stand or fall by the quality (or lack of it) of my published work. But then, most of the time, I always have. And if I feel the need to expand my signature, I’ll have to fall back on my humble BA. (Now that’s a qualification I am proud of, having completed it under stressful circumstances: that is, as a new parent with a full-time job.)

I may well return to the topic of certifications, though. I addressed it at some length in a chapter in the AVIEN Guide, but maybe it would be a good topic to follow up on the ESET blog.

David Harley
Small Blue-Green World

Spamfighting and Hamfighting

This is an article from Virus Bulletin on Hamfighting, July 2006, made available here by kind permission of Virus Bulletin, which holds the copyright. (You can also read it at HTML on the Virus Bulletin site, but for that you need to be a subscriber – registration is free, though.)

It addresses the problem of legitimate mail (‘ham’) misdiagnosed as spam, with particular reference to aggressive filtering by Verizon. I’m putting it up here now because it has particular relevance to a post I’m putting together on Mac Virus. Brief extract from the introduction to the paper:

Complaints in various forums of poor email delivery service from the ISP seemed to be confirmed by claims from Verizon ‘insiders’ that a policy of rejecting mail by IP block resulted in the loss of all mail from large portions of Europe and Asia. This led to a much publicized class action, resulting in a settlement offer from Verizon to compensate customers who lost legitimate mail between October 2004 and May 2005.

I’ll probably be putting up some more papers and articles that aren’t available on my own sites, in the near future, or external links where appropriate.

ESET Senior Research Fellow

PIN Holes: Passcode Selection Strategies

This is the second paper I presented at the EICAR 2012 conference in Lisbon. As before, It’s posted here rather than on the ESET resources page for conference papers in accordance with EICAR’s copyright stipulation that EICAR conference papers be posted on personal web sites.

PIN Holes: Numeric Passcodes and Mnemonic Strategies 

And here’s the abstract:

Recommendations on how to select and/or memorize a four-digit PIN (Personal Identification Number) can be found all over the Internet, but while we have learned a great deal from analyses of mixed-character passwords and passphrases revealed by high-profile breaches like the highly publicized Gawker and attacks, there are no exactly equivalent attack-derived data on PIN usage. However, a sample of 204,508 anonymized passcodes for a smartphone application, by ranking 4-digit strings by popularity, gives us a starting point for mapping that ranking to known selection and mnemonic strategies.

Memorization strategies summarized by Rasmussen and Rudmin include rote learning; memorization according to keypad pattern; passcode re-use from other security contexts; code with personal meaning; code written down or stored electronically (as on mobile phone) – possibly using various concealment and transformation strategies.

The data provided by Amitay allows us to assess the degree to which memorization strategies are used in relation to a standard smartphone numeric keypad, but also to engage in some informed speculation on the extent to which they might be modified on other keypads, including QWERTY phone keypads, ATM keypads, security tokens requiring initial PIN entry, and hardware using an inverted (calculator-type) numeric layout. The ranking allows evaluation of the entropic efficacy of these strategies: the more popular the sequence, the likelier it is to be guessed.

These considerations are used to assess the validity of commonly recommended strategies in a diversity of contexts and generate a set of recommendations based on the findings of this analysis. These recommendations are placed into the context of more general mixed-character passwords and passphrases. They will provide a starting point for security managers and administrators responsible for the education and protection by policy of end users and customers using the kinds of device and application that require numeric passcodes for authentication.

ESET Senior Research Fellow

After AMTSO: a paper for EICAR 2012.

This is a paper presented at the 2012 EICAR conference in Lisbon. (I actually presented two: the other one will be posted here in a day or two, or maybe a little longer as I’m travelling right now.) It’s posted here rather than on the ESET resources page for conference papers in accordance with EICAR’s copyright stipulation that EICAR conference papers be posted on personal web sites.

After AMTSO: a funny thing happened on the way to the forum

Here’s the abstract: 

Imagine a world where security product testing is really, really useful.

  • Testers have to prove that they know what they’re doing before anyone is allowed to draw conclusions on their results  in a published review. 
  • Vendors are not able to game the system by submitting samples that their competitors are unlikely to have seen, or to buy their way to the top of the rankings by heavy investment in advertising with the reviewing publication, or by engaging the testing organization for consultancy. 
  • Publishers acknowledge that their responsibility to their readers means that the claims they make for tests they sponsor should be realistic, relative to the resources they are able to put into them. 
  • Vendors don’t try to pressure testers into improving their results by threatening to report them to AMTSO.
  • Testers have found a balance between avoiding being unduly influenced by vendors on one hand and ignoring informed and informative input from vendors on the other. 
  • Vendors don’t waste time they could be spending on enhancing their functionality, on tweaking their engines to perform optimally in unrealistic tests.
  • Reviewers don’t magnify insignificant differences in test performance between products by  camouflaging a tiny sample set by using percentages, suggesting that a product that detects ten out of ten samples is 10% better than a product that only detects nine. 
  • Vendors don’t use tests they know to be unsound to market their products because they happened to score highly.
  • Testers don’t encourage their audiences to think that they know more about validating and classifying malware than vendors.
  • Vendors and testers actually respect each others work.

When I snap your fingers, you will wake out of your trance, and we will consider how we could actually bring about this happy state of affairs. 

For a while, it looked as if AMTSO, the Anti-Malware Testing Standards Organization, might be the key (or at any rate one of the keys), and we will summarize the not inconsiderable difference that AMTSO has made to the testing landscape. However, it’s clear that the organization has no magic wand and a serious credibility problem, so it isn’t going to save the world (or the internet) all on its own. So where do we (the testing and anti-malware communities) go from here? Can we identify the other players in this arena and engage with them usefully and appropriately?

Small Blue-Green World
ESET Senior Research Fellow