How Much Of A CASE Are You?

This piece is adapted from Chapter 3 of Security De-engineering, titled “Checklists and Standards Evangelists”.

My travels in information security have taken to me to 3 different continents and 15 different countries. I have had the pleasure and pain to deal with information security problems in every industry sector that ever existed since the start of the Industrial Revolution (but mostly finance’y/bank’y of course), and I’ve had the misfortune and pleasure to meet a whole variety of species and sub-species of the genus Information Security Professional.

In the good old days of the 90s, it was clear there were some distinctive features that were hard-wired into the modus operandi of the Information Security Professional. This earlier form of life, for want of a better name, I call the “Hacker”, and I will talk about them in my next post.

In the pre-holocene mid to late 90s, the information security professional was still plausibly human, in that they weren’t afraid to display distinguishing characteristics. There was no great drive to “fit in”, to look the same, talk the same, and act the same as all the other information security professionals. There was a class that was information security professional, and at the time, there was only one instance of that class.

Then during the next few years, going into the 2000s, things started to change in response to the needs of ego and other head problems, mostly variants of behaviour born out of insecurity. The need to defend territory, without possession of the necessary intellectual capital to do so, gave birth to a new instance of the class Information Security Professional – the CASE (Checklists and Standards Evangelist). The origin of the name will become clear.

My first engagement in the security world was with a small, ex-countries (mostly former Yugoslavia and Soviet Union) testing team in the late 90s. Responding incorrectly to the perceived needs of the market, around 2001/2 there were a couple of rounds of Hacker lay-offs – a common global story at the time. A few weeks after the second batch of lay-offs, there was a regional team event, wherein our Operations Manager (with a strong background in hotel management) opened the event with “security is no longer about people with green hair and piercings”. Well, ok, but what was it about then? The post 2000s version of “It” is the focus of this post, and I will cover a very scientific methodology for self-diagnosing the level of CASE for the reader.

Ok, so here are some of the elements of CASE’dom that are more commonly witnessed. Feel free to run a self-diagnosis, scoring from 0 to 5 for each point, based either on what you actually believe (how closely you agree with the points), or how closely you see yourself, or how closely you can relate to these points based on your experiences in infosec:

  • “Technical” is a four letter word.
  • Anything “technical”, to do with security (firewall configuration, SIEM, VM, IDS/IPS, IDM etc) comes under the remit of IT/Network Operations.
  • Security is not a technical field – its nothing to do with IT, its purely a business function. Engineers have no place at the table. If a candidate is interviewed for a security position and they use a tech term  such as “computer” or “network”, then they clearly have no security experience and at best they should apply for an lowly ops position.
  • You were once a hacker, but you “grew out of it”.
  • Any type of risk assessment methodology can be reduced down to a CHECKLIST, and recited parrot fashion, thereby replacing the need for actual expertise and thinking. Cost of safeguard versus risk issues are never very complex and can be nailed just by consultation of a check list.
  • Automated vulnerability scanners are a good replacement for manual testing, and therefore manual testers, and by entering target addresses and hitting an enter button, there is no need for any other type of vulnerability assessment, and no need for tech staff in security.
  • There is a standard, universally recognised vocabulary to be used in security which is based on whichever CISSP study guide you read.
  • Are you familiar with this situation: you find yourself in a room with people who talk about the same subject as you, but they use different terms and phrases, and you get angry at them in the belief that your terminology is the correct version?
  • CISSP is everything that was, is, and ever will be. CISSP is the darkness and the light, and the only thing that matters, the alpha and omega. There is a principle: “I am a CISSP, therefore I am”, and if a person does not have CISSP (or it “expired”), then they are not an effective security professional.
  • You are a CEH and therefore a skilled penetration tester.
  • “Best Practice” is a phrase which is ok to use on a regular basis, despite the fact that there is no universally accepted body of knowledge to corroborate the theory that the prescribed practice is the best practice, and business/risk challenges are all very simple to the extent that a fixed solution can be re-used and applied repeatedly to good effect.
  • Ethics is a magnificent weapon to use when one feels the need to defend one’s territory from a person who speaks at, or attends “hacker conferences”. If an analyst has ever used a “hacking tool” in any capacity, then they are not ethical, and subject to negative judgment outside of the law. They are in fact a criminal, regardless of evidence.
  • You look in the mirror and notice that you have a square head and a fixed, stern grimace. At least during work hours, you have no sense of humour and are unable to smile.
  • For a security professional in an in-house situation: it is their job to inform other business units of security standard and policy directives, without assessment of risk on a case-by-case basis, and also no offering of guidance as to how the directives might be realised. As an example: a dev team must be informed that they MUST use two-factor authentication regardless of the risk or the additional cost of implementation. Furthermore, it is imperative to remind the dev team that the standards were signed off by the CEO, and generally to spread terror whilst offering no further guidance.
  • You are a security analyst, but your job function is one of “management” – not analysis or assessment or [insert nasty security term]. Your main function is facilitating external audits and/or processing risk exemption forms.
  • Again for in-house situations: silence is golden. The standard response to any inter-department query is defiance. The key element of any security professional’s arsenal is that of silence, neutrality, and generally not contributing anything. This is a standard defence against ignorance. If a security professional can maintain a false air of confidence while ignoring any form of communique, and generally just not contributing anything, then a bright future awaits. The mask that is worn is one of not actually needing to answer, because you’re too important, and time is too valuable.
  • You fill the gap left by the modern security world by adding in words like “Evangelist” in your job title, or “thought leader”. Subject Matter Expert (SME) also is quite an attractive title. “Senior” can also be used if you have 1 second of experience in the field, or a MBA warrants such a prefix.
  • Your favourite term is “non-repudiation”, because it has that lovely counter-intuitive twist in its meaning. The term has a decent shelf-life, and can be used in any meeting where management staff are present, regardless of applicability to the subject under discussion.
  • Security incident” and “security department” both have the word “security” in them. Management notices this common word, so when there’s an incident and ops refuse to get involved, the baton falls to the security department which has no tools, either mental or otherwise, for dealing with incidents. So, security analysts live in fear of incidents. This is all easily fixed by hiring folk who both need to “fit in” with the rest of the team and also who use words like “forensics” and “incident” on their CV (and they are CISSPs).
  • “Cloud Security” is a new field of security, that only came into existence recently, and is an area of huge intellectual capital. If one has a cloud-related professional accreditation, it means they are very, very special and possess powers other mortals can only dream of. No, really. Cloud adoption is not merely a change in architecture, or places an emphasis on crypto and legal coverage! It’s way more than that!
  • Unlike Hackers, you have unique “access” to C-level management, because you are mature, and can “communicate effectively”.
  • You applied for a job which was advertised as highly technical as per the agent’s (bless ’em eh) job description that was passed on by HR. On day one you realise a problem. You may never see a command shell prompt ever again.

A maximum score of 110 points will be seen as very good or very bad by your management team, hopefully the former for your sake, hopefully the latter for the business’s sake.

Somewhere in the upper area of 73 to 110 points is max’xed-out CASE. This is as CASE as it gets. I wouldn’t want to advocate a new line of work to anyone really, but it might just be the case than an alternative career would lead to a greater sense of fulfilment and happiness.

There is hope for anyone falling in the less than 73 area. For example, its not too late to go through that [insert core technology] Security Standard, try and understand the technical risks, talk to operations about it, and see it all anew. If “tech” really is something that is against your nature, then you will probably be in the 73 to 110 class. Less than 73 is manageable. Of course by getting more tech, you could be alienating yourself or upsetting the apple cart. Its your choice ultimately…

The statement that information security is not actually anything to do with information technology, is of course nothing more than pre-tense, and more and more of our customers are starting to realise this.