Fintechs and Security – Prologue

  • Prologue – covers the overall challenge at a high level
  • Part One – Recruiting and Interviews
  • Part Two – Threat and Vulnerability Management – Application Security
  • Part Three – Threat and Vulnerability Management – Other Layers
  • Part Four – Logging
  • Part Five – Cryptography and Key Management, and Identity Management
  • Part Six – Trust (network controls, such as firewalls and proxies), and Resilience

Fintechs and Security – A Match Made In Heaven?

Well, no. Far from it actually. But again, as i’ve been repeating for 20 years now, its not on the fintechs. It’s on us in infosec, and infosec has to take responsibility for these problems in order to change. If i’m a CTO of a fintech, I would be confused at the array of opinions and advice which vary radically from one expert to another

But there shouldn’t be such confusion with fintech challenges. Confusion only reigns where there’s FUD. FUD manifests itself in the form of over-lengthy coverage and excessive focus on “controls” (the archetypal shopping list of controls to be applied regardless of risk – expensive), GRC, and “hacking/”[red,blue,purple,yellow,magenta/teal/slate grey] team”/”appsec.

Really what’s needed is something like this (in order):

  • Threat modelling lite – a one off, reviewed periodically.
  • Architecture lite – a one off, review periodically.
  • Engineering lite – a one off, review periodically.
  • Secops lite – the result of the previous 3 – an on-going protective monitoring capability, the first level of monitoring and response for which can be outsourced to a Managed Service Provider.

I will cover these areas in more details in later episodes but what’s needed is, for example, a security design that only provides the answer to “What is the problem? How are we going to solve it?” – so a SIEM capability design for example – not more than 20 pages. No theory. Not even any justifications. And one that can be consumed by non-security folk (i.e. it’s written in the language of business and IT).

Fintechs and SMBs – How Is The Infosec Challenge Unique?

With a lower budget, there is less room for error. Poor security advice can co-exist with business almost seamlessly in the case of larger organisations. Not so with fintechs and Small and Medium Businesses (SMBs). There has been cases of SMBs going under as a result of a security incident, whereas larger businesses don’t even see a hit on their share price.

Look For A Generalist – They Do Exist!

The term “generalist” is seen as a four-letter word in some infosec circles. But it is possible for one or two generalists to cover the needs of a fintech at green-field, and then going forward into operations, its not unrealistic to work with one in-house security engineer of the right background, the key ingredients of which are:

  • Spent at least 5 years in IT, in a complex production environment, and outgrew the role.
  • Has flexibility – the old example still applies today – a Unix fan has tinkered with Windows. So i.e. a technology lover. One who has shown interest in networking even though they’re not a network engineer by trade. Or one who sought to improve efficiency by automating a task with shell scripting.
  • Has an attack mindset – without this, how can they evaluate risk or confidently justify a safeguard?

I have seen some crazy specialisations in larger organisations e.g. “Websense Security Engineer”! If fintechs approached security staffing in the same way as larger organisations, they would have more security staff than developers which is of course ridiculous.

So What’s Next?

In “On Hiring For DevSecOps” I covered some common pitfalls in hiring and explained the role of a security engineer and architect.

There are “fallback” or “retreat” positions in larger organisations and fintechs alike, wherein executive decisions are made to reduce the effort down to a less-than-advisable position:

  • Larger organisations: compliance driven strategy as opposed to risk based strategy. Because of a lack of trustworthy security input, execs end up saying “OK i give up, what’s the bottom line of what’s absolutely needed?”
  • Fintechs: Application security. The connection is made with application development and application security – which is quite valid but the challenge is wider. Again, the only blame i would attribute here is with infosec. Having said that, i noticed this year that “threat modelling” has started to creep into job descriptions for Security Engineers.

So for later episodes – of course the areas to cover in security are wider than appsec, but again there is no great complication or drama or arm-waiving:

  • Part One – Hiring and Interviews – I expand on “On Hiring For DevSecOps“. I noticed some disturbing trends in 2019 and i cover these in some more detail.
  • Part Two – Security Architecture and Engineering I – Threat and Vulnerability Management (TVM)
  • Part Three – Security Architecture and Engineering II – Logging (not necessarily SIEM). No Threat Hunting, Telemetry, or Threat “Intelligence”. No. Just logging. This is as sexy as it needs to be. Any more sexy than this should be illegal.
  • Part Four – Security Architecture and Engineering III – Identity Management (IDAM) and Cryptography and Key Management (CKM).
  • Part Five – Security Architecture and Engineering IV – Trust (network trust boundary controls – e.g. firewalls and forward proxies), and Business Resilience Management (BRM).

I will try and get the first episode on hiring and interviewing out before 2020 hits us but i can’t make any promises!

A Desperate Call For More Effective Information Security Accreditation

CISSP has to be the most covered topic in the world of infosec. Why is that? The discussions are mostly of course aimed at self-promotion (both by folk condemning the accreditation and then the same in the defensive responses) and justifying getting the accreditation. How many petabytes are there covering this subject? If you think about it, the sheer volume of the commentary on CISSP is proportional to the level of insecurity felt by infosec peeps. It’s a symptom of a sector that is really very ill indeed, and the sheer volume of the commentary is a symptom of how ineffective CISSP is in accreditation, and also the frustration felt by people who know we can do better.

We need _something_. We do need some kind of accreditation. Right now CISSP is the only recognised accreditation. But if you design an accreditation that attempts to cover the whole of infosec in one exam, what did you think the result would be? And there is no room for any argument or discussion on this. Its time to cut the defensiveness and come clean and honest.

The first stage of solving a problem is acknowledgment of its existence. And we’re not there yet. There are still 1000s in this field who cling onto CISSP like a lifebuoy out on the open ocean. There is a direct correlation between the buoy-clingers and the claim that “security is not about IT” …stop that!! You’re not fooling anybody. Nobody believes it! All it does is make the whole sector look even more like a circus to our customers than it already does. The lack of courage to admit the truth here is having a negative impact on society in general.

Seems to me that the “mandatory” label for CISSP in job qualifications is now rare to see. But CISSP is still alive and is better than nothing. Just stop pretending that it’s anything other than an inch thick and a mile wide.

Really we need an entry-level accreditation that tests a baseline level of technical skills and the possession of an attack mindset. We can’t attack or defend, or make calls on risk without an attack mindset. GRC is a thing in security and its a relevant thing – but it doesn’t take up much intellectual space so therefore it needs to be a small part of the requirements. Level 2 SOC Analysts need to understand risk and the importance of application availability, and the value of electronic information to the business, but this doesn’t require them to go and get a dedicated accreditation. Information Security Manage-ment is really an area for Manage-ers – the clue is in the name.

What are the two biggest challenges in terms of intellectual capital investment? They’re still operating systems (and ill-advised PaaS and SaaS initiatives haven’t changed this) and applications. So let’s focus on these two as the biggest chunks of stuff that an infosec team has to cover, and test entry-level skills in these areas.

Make Cybersecurity Great Again, Again.

Another ‘we can fix infosec‘ is out there.

“OK I admit we can’t make cybersecurity great again, because it never was great in the first place”.

It was certainly better than it is now. At one point in time, we had the technical folk, but not the managers. Now we have neither. There was a brain drain from security around the early 2000s whereby tech folk left in droves, either voluntarily or ‘as a business need’. They were seen as aesthetically unpleasing at a time where the perception was that a threat did not exist! In the proceeding years risks increased on the top of the aforementioned shedding of intellectual capital from organisations. Then around 2010 things reached boiling point when security incidents found their way back on the front pages of the Financial Times.

So around 2010 some organisations wanted to get ‘tech’ again but since all the skills were lost 10 years ago, who knows what good looks like? The same folk who inherited the kingdom of security with their fine aesthetics were now charged with finding the skills, while not knowing what the skills look like.

“President Trump recently appointed Rudy Giuliani as cybersecurity adviser. Some reacted to this as a joke”. I would agree that this reaction is short sighted.

“Well me and my colleagues are in industry and we see the issues every day, we are the consultants, the IT auditors, systems administrators, security managers and network engineers. No we are not CEOs or business owners but it’s our job to educate and inform these business leaders of the risk of doing business on the internet. Sometimes they listen and too often they don’t seem to hear us”. All you can do is confidently state your case and get it in writing somewhere. But be aware that confidence should never be faked. Either learn the skills necessary FAST, or find another vocation. C-levels can detect BS ladies and gentlemen and the more of you that try to BS a C-level, the harder you’re making it for the rest of us. Ask yourselves why it is that security was once a board level thing and now most security chiefs reports to a CIO or COO.

“I see this every day as I travel across Florida doing IT audits and assessments. The organizations with a security role funded do 90 percent better than those with no such funded position.” Audits are a poor way of assessing the performance of security. Really poor in fact. Although it can be said that if an audit is failed – that’s uber bad, but if an audit is passed it does not mean all is good.

“One of the problems of the Internet is that we didn’t install what I like to call strong user authentication or strong file authentication.” Yes, we did. Its called an Operating System. For the most part the security sector has shied away from the OS because its hard for folk who don’t have an IT background to understand. Infosec would like to convince decision makers that it doesn’t exist, because if it does exist, then vendors can’t sell many of the snake oil offerings, and non-tech infosec folk are in a vulnerable position.

Operating Systems come with a slew of controls that can be used to thwart and/or detect attacks – perhaps it would be good if we started using them and reporting on how effectively the organisation uses each control? Why spend extra on snake oil products? For example, why spend gazillions on identity management in cloud deployments when we already have it?

“All too often we see organizations relegating cyber security to the IT department. I have said this a hundred times, cybersecurity is a business problem not an IT issue”. This statement suits a certain agenda that plays to the non-tech/GRC oriented folk. Security is a business problem AND an IT problem, but in terms of the intellectual capital required, its 10% a business problem, and 90% an IT problem.

“All users need awareness training” – yes, i think we are now at the stage where security has to be something that is everyone’s responsibility in the same way as checking for cars before crossing the road is everyone’s responsibility.

Infosec is in dire straits because of the loss of critical skills from the sector, and now we have a situation where people with the wrong skills are reporting to the likes of Rudy Giuliani with a lack of confidence and a myriad of confused messages, mostly built around self-serving interests at the expense of the whole. Its likely the former mayor of NY won’t be any wiser as to the scale of the problem, and therefore how to solve it.

Security professionals with no IT background are like animals handlers who are afraid of animals, and its these folk who are representing the sector.

The message that will be delivered to Giuliani will include the part that the sector needs more money. You know it really doesn’t – it needs less. Stop spending money on “next gen” products where “old gen” gets it done. “Legacy” stuff isn’t legacy unless you allow yourself to be duped by vendors into believing that its legacy. Really firewalls and OS offer most of what’s needed.

The same goes for people. We have too many people. Don’t create jobs around products – this is creating micro-specialisations that you are then calling ‘skills’, and hiring dedicated staff who won’t be very busy and won’t be very enthused or ‘synergistic’. This is what you’re looking for...http://www.seven-stones.biz/blog/addressing-the-information-security-skills-gap/

As Upton Sinclair said “It is difficult to get a man to understand something, when his salary depends on his not understanding it.” This quote lends itself to the problems in information security more than any other sector. Moreover it has defined information security as a broken entity since it was first adopted seriously by banks and then others.

Addressing The Information Security Skills Gap

We are told there is a skills gap in information security. I agree – there is, but recent suggestions to address the gap take us to dangerous places that are great for recruitment agencies, but not so great for the business world.

I want to steer away from use of the phrase ‘skills’ in this article because its too micro and the phrase has been violated by modern hiring practices. We are not looking for ‘Websense’, ‘DLP’ skills or as i saw recently ‘HSM’ skills. These requirements are silly unless it is the plan for organisations to spend 10 to 50 times more than they need on human resource, and have a security team of 300. Its healthier for organisations to look at ‘habits’ or ‘backgrounds’, and along those lines, in information security we’re looking for the following:

  • At least 5 years in an IT discipline: sys admin, DBA, devops bod, programmer for example
  • Evidence of having excelled in those positions and sort of grown out of them
  • Flexibility: for example, the crusty Radagast BSD-derivative disciple who has no fundamentalist views of other operating systems (think ‘Windows’) and not only can happily work with something like Active Directory, but they actually love working with Active Directory
  • A good-to-have-but-not-critical is past evidence of breaking or making things, but this should seen as a nice bonus. In its own right, it is insufficient – recruiting from hacker confz is far from guaranteed to work – too much to cover here

So really it should be seen that a career in infosec is a sort of ‘graduation’ on from other IT vocations. There should be an entrance exam based on core technologies and penetration testing. The career progression path goes something like: Analyst (5 years) –> Consultant -> Architect/Manager. Managers and architects cannot be effective if they do not have a solid IT background. An architect who doesn’t know her way around a Cisco router, implement a new SIEM correlation rule, or who cannot run or interpret the output from a packet sniffer is not an architect.

Analysts and Consultants should be skilled with the core building blocks to the level of being confidently handed administrative access to production systems. As it is, security pros find it hard to even get read-only access to firewall management suites. And having fast access to information on firewall rules – it can be critical.

Some may believe that individuals fitting the above profile are hard to find, and they’d be right. However, with the aforementioned model, the workforce will change from lots of people with micro-skills or product-based pseudo skills, to fewer people who are just fast learners and whose core areas complement each other. If you consider that a team of 300 could be reduced to 6 – the game has changed beyond recognition.

Quoting a recent article: “The most in demand cyber security certifications were Security+, Ethical Hacking, Network+, CISSP, and A+. The most in demand skills were Ethical Hacking, Computer Forensics, CISSP, Malware Analysis, and Advanced Penetration Testing”. There are more problems with this to describe in a reasonable time frame but none of these should ever be called ‘skills’. Of these, Penetration Testing (leave out the ‘ethics’ qualifier because it adds a distasteful layer of judgment on top of the law) is the only one that should be called a specification in its own right.

And yes, Governance, Risk and Control (GRC) is an area that needs addressing, but this must be the role of the Information Security Manager. There is a connection between Information Security Manage-ment and Information Security Manage-er.  Some organisations have separate GRC functions, the UK public sector usually has dedicated “assurance” functions, and as i’ve seen with some law firms, they are separated from the rest of security and IT.  Decision making on risk acceptance or mitigation, and areas such as Information Classification, MUST have an IT input and this is the role of the Information Security Manager. There must be one holistic security team consisting of a few individuals and one Information Security Manager.

In security we should not be leaving the impression that one can leave higher education, take a course in forensics, get accreditation, and then go and get a job in forensics. This is not bridging the security skills gap – its adding security costs with scant return. If you know something about forensics (usually this will be seen as ‘Encase‘ by the uninitiated) but don’t even have the IT background, let alone the security background, you will not know where to look in an investigation, or have a picture of risk. You will not have an inkling of how systems are compromised or the macro-techniques used by malware authors. So you may know how to use Encase and take an integral disk image for example, but that will be the limit of your contribution. Doesn’t sound like a particularly rewarding way to spend 200 business days per year? You’d be right.

Sticking with the forensics theme: an Analyst with the right mindset can contribute effectively in an incident investigation from day one. There are some brief aspects of incident response for them to consider, but it is not advisable to view forensics/incident response as a deep area. We can call it a specification, just as an involuntary action such as breathing is a specification, but if we do, we are saying that it takes more than one person to change a light bulb.

Incident response from the organisational / Incident Response Plan (IRP) formation point of view is a one-day training course or a few hours of reading. The tech aspects are 99% not distinct from the core areas of IT and network security. This is not a specialisation.

Other areas such as DLP, Threat Intelligence, SIEM, Cryptography and Key Management – these can be easily adopted by the right security minds. And with regard security products – it should be seen that security professionals are picking up new tools on-the-fly and don’t need 2 week training courses that cost $4000. Some of the tools in the VM and proxy space are GUIs for older open source efforts such as Nessus, OpenVAS, and Squid with which they will be well-versed, and if they’re not, it will take an hour to pick up the essentials.

There’s been a lot of talk of Operating Systems (OS) thus far. Operating Systems are not ‘a thing from 1998’. Take an old idea that has been labelled ‘modern’ as an example: ok, lets go with ‘Cloud’. Clouds have operating systems. VMs deployed to clouds have operating systems. When we deploy a critical service to a cloud, we cannot ignore the OS even if its a PaaS deployment. So in security we need people who can view an OS in the same way that a hacker views an OS – we need to think about Kill Chains and local privilege elevations. The Threat and Vulnerability Management (TVM) challenge does not disappear just because you have PaaS’d everything. Moreover if you have PaaS’d everything, you have immediately lost the TVM battle. As Beaker famously said in his cloud presentation – “Platforms Bitches”. Popular OS like Windows, *nix, Linux, and popular applications such as Oracle Database are going to be around for some time yet and its the OS where the front-lines are drawn.

Also what is a common misconception and does not work: a secops/network engineer going straight into security with no evidence of interest in other areas. ‘Secops’ is not good preparation for a security career, mainly because secops is sort of purgatory. Just as “there is no Dana, only Zool“, so “there is no secops, only ops”. There is only a security element to these roles because the role covers operational processes with security products. That is anti-security.

All Analyst roles should have an element of penetration testing and appsec, and when I say penetration testing, i do mean unrestricted testing as in an actual simulation. That means no restrictions on exploit usage or source address – because attackers do not have such restrictions. Why spend on this type of testing if its not an actual simulation?

Usage of Cisco Discovery Protocol (CDP) offers a good example of how a lack of penetration testing experience can impede a security team. If security is being done even marginally professionally in an organisation, there will exist a security standard for Cisco network devices that mandates the disabling of CDP.  But once asked to disable CDP, network ops teams will want justification. Any experienced penetration tester knows the value of intelligence in expediting the attack effort and CDP is a relative gold mine of intelligence that is blasted multicast around networks. It can, and often does, reveal the identity and IP address of a core switch. But without the testing experience or knowledge of how attacks actually go down, the point will be lost, and the confidence missing from the advisory.

The points i’ve just covered are not actually ground-breaking at all. Analysts with a good core background of IT and network security can easily move into any new area that marketeers can dream up.

There is an intuition that Information Security has a connection with Information Technology, if only for the common word in them both (that was ‘Information’ by the way, in case you didn’t get it). However, as Upton Sinclair said “It is difficult to get a man to understand something, when his salary depends upon his not understanding it”.

And please don’t create specialisations for Big Data or Internet of Things…woops, too late.

So, consider a small team of enthusiastic, flexible, fast learners, rather than a large team of people who can be trained at a high cost to understand the UI of an application that was designed in the international language and to be intuitive and easy to learn.

Consider using one person to change a light bulb, and don’t be the butt of future jokes.

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.

The Search For Infosec Minds

Since the early 2000s, and in some of my other posts, I have commented in different forms on the state of play, with a large degree of cynicism, which was greeted with cold reservation, smirks, grunts, and various other types of un-voiced displeasure, up to around 2009 or so. But since at least 2010, how things have changed.

If we fast forward from 2000 to 2005 or so, most business’s security function was reduced down to base parrot-fashion checklists, analysis and thinking were four letter words, and some businesses went as far as outsourcing security functions.

Many businesses who turned their backs on hackers just after the turn of the millennium have since found a need to review their strategies on security hiring. However 10 years is a long time. The personnel who were originally tasked with forming a security function in the late 90s, have since risen like phoenixes from the primordial chasm, and assisted by thermals, they have swooped up to graze on higher plains. Fast forward again to 2012, and the distance between security and IT is in the order of light years in most cases. The idea that security is purely a compliance game hasn’t changed, but unlike the previous decade, it is in many cases seen as no longer sufficient to crawl sloth-like over the compliance finishing line every year.

Businesses were getting hacked all through the 2000s but they weren’t aware of it. Things have changed now. For starters the attacks do seem to be more frequent and now there is SIEM, and audit requirements to aggregate logs. In the past, even default log settings were annulled with the result that there wasn’t even local logging, let alone network aggregation! Mind you, even after having been duped into buying every well-marketed detection product, businesses are still being hacked without knowing it. Quite often the incident comes to light after a botnet command and control system has been owned by the good guys.

Generally there is more nefarious activity now, as a result of many factors, and information security programs are under more “real” focus now (compliance-only is not real focus, in fact it’s not real anything, apart from a real pain the backside).

The problem is that with such a vast distance between IT and security for so long, there is utter confusion about how to get tech’d up. Some businesses are doing it by moving folk out of operations into security. This doesn’t work, and in my next post I will explain why it doesn’t work.

As an example of the sort of confusion that reigns, there was one case I came across earlier in 2012 where a company in the movies business was hacked and they were having their trailers, and in some cases actual movies, put up on various torrent sites for download. Their response was to re-trench their outsourced security function and attempt to hire in-house analysts (one or two!). But what did they go looking for? Because they had suffered from malware problems, they went looking for, and I quote, “Malware Reverse Engineers”. Malware Reverse Engineers? What did they mean by this? After some investigation, it turns out they are really were looking for malware reverse engineers, there was no misnomer – malware reverse engineers as in those who help to develop new patterns for anti-virus engines!! They had acquired a spanking new SIEM, but there was no focus on incident response capability, or prevention/protection at all.

As it turns out “reverse engineer[ing]” is now a buzzword. Whereas in the mid-2000s, buzzwords were “governance” and “identity management” (on the back of…”identity theft” – neat marketing scam), and so on. Now there are more tech-sounding buzzwords which have different connotations depending on who you ask. And these tech sounding buzzwords find their way into skills requirements sent out by HR, and therefore also on CVs as a response. And the tech-sounding buzzwords are born from…yes, you got it…Black Hat conferences, and the multitude of other conferences, B-sides, C-sides, F-sides and so on, that are now as numerous as the stars in the sky.

The segue into Black Hat was quite deliberate. A fairly predictable development is the on-going appearance of Infosec managers at Black Hats, who previously wouldn’t touch these events with a barge pole. They are popping up at these events looking to recruit speakers primarily, because presumably the speakers are among the sharper of the crayons in the box, even if nobody has any clue what they’re talking about.

Before I go on, I need to qualify that I am not going to cover ethics here, mainly because it’s not worth covering. I find the whole ethics brush to be somewhat judgmental and divisive. I prefer to let the law do the judgment.

Any attempt to recruit tech enthusiasts, or “hackers”, can’t be dismissed completely because it’s better than anything that could have been witnessed in 2005. But do businesses necessarily need to go looking for hackers? I think the answer is no. Hackers have a tendency to take security analysis under their patronage, but it has never been their show, and their show alone. Far from it.

In 2012 we can make a clear distinction between protection skills and breaking-in skills. This is because as of 2012, 99.99…[recurring to infinity]% of business networks are poorly defended. Therefore, what are “breaking-in skills”? So a “hacker” breaks into networks, compromises stuff, and posts it on pastebin.com. The hackers finds pride and confidence in such achievements. Next, she’s up on the stage at the next conference bleating about “reverse engineering”, “fuzzing”, or “anti forensics tool kits”…nobody is sure which language is used, but she’s been offered 10 jobs after only 5 minutes into her speech.

However, what is actually required to break into networks? Of the 20000+ paths which were wide open into the network, the hacker chose one of the many paths of least resistance. In most cases, there is no great genius involved here. The term “script kiddy” used to refer to those who port scan, then hunt for public declared exploits for services they find. There is IT literacy required for sure (often the exploits won’t run out-of-the-box, they need to be compiled for different OSs or de-bugged), but no creativity or cunning or …whatever other mythical qualities are associated with hacking in 2012.

The thought process behind hiring a hacker is typically one of “she knows how to break into my network, therefore she can defend against others trying to break in”, but its quite possible that nothing could be further from the truth. In 2012, being a hacker, or possessing “breaking-in skills”, doesn’t actually mean a great deal. Protection is a whole different game. Businesses should be more interested about protection as of 2012, and for at least the next decade.

But what does it take to protect? Protection is a more disciplined, comprehensive IT subject. Collectively, the in-house security teams needs to know the all the nooks and crannies, all the routers, databases, applications, clouds, and operating systems and how they all interact and how they’re all connected. They also collectively need to know the business importance of information assets and applications.

The key pillars of focus for new-hire Security Analysts should be Operating Systems and Applications. When we talk about operating systems and security, the image that comes to mind is of auditors going thru a checklist in some tedious box-ticking exercise. But OS security is more than that, and it’s the front line in the protection battle. The checklists are important (I mean checklists as in standards and policies) but there are two sides to each item on the checklist: one is in the details of how to practically exploit the vulnerability and the potential tech impact, the other are the operational/business impacts involved with the associated safeguard. In other words, OS security is far more than a check-list, box-ticking activity.

In 12 years I never met a “hacker” who could name more than 3 or 4 local privilege elevation vectors for any popular Operating System. They will know the details of the vulnerability they used to root a server last month, but perhaps not the other 100 or so that are covered off by the corporate security standard for that Operating System. So the protection skills don’t come by default just because someone has taken to the stand at a conference.

Skills such as “reverse engineering” and “fuzzing” – these are hard to attain and can be used to compromise systems that are well defended. But the reality is that very few systems are so well defended that such niche skills are ever needed. In 70+ tests for which i have either taken part or been witness, even if the tests were quite unrestricted, “fuzzing” wouldn’t be required to compromise targets – not even close.

A theoretical security team for a 10000+ node business, could be made of a half dozen or so Analysts, plus a Security Manager. Analysts can come from a background of 5 years in admin/ops or devs. To “break into” security, they already have their experience in a core technology (Unix, Windows, Oracle, Cisco etc), then they can demonstrate competence in one or more other core technologies (to demonstrate flexibility), programming/scripting, and security testing with those platforms.

Once qualified as a Security Analyst, the Analyst has a specialization in at least two core technologies. At least 2 analysts can cover application security, then there are other areas such as incident handling and forensics. As for Security Managers, once in possession of 5 years “time served” as an Analyst, they qualify for a manager’s exam, which when passed qualifies them for a role as a Security Manager. The Security Manager is the interface, or agent, between the technical artist Analysts and the business.

Overall then, it is far from the case that Hackers are not well-suited for vocational in-house security roles (moreover I always like to see “spare time” programming experience on a resume because it demonstrates enthusiasm and creativity). But it is also not the case that Analyst positions are under the sole patronage of Black Hat speakers. Hackers still need to demonstrate their capabilities in protection, and doing “grown-up” or “boring” things before being hired. There is no great compelling need for businesses to hire a hacker, although as of today, it could be that a hooligan who throws security stones through security windows is as close as they can get to effective network protection.