Screen Shot 2016-06-24 at 10.39.30

What Will Brexit Mean for Cyber Security?

No idea.

But let’s be honest, everyone will be making wild speculations at this point, just as ‘experts’ in every other field will be. The only thing for certain, is that the UNcertainty will be used by security vendors to try to scare UK companies into buying something.

This one is unrelated, but is actually very good and you should read it first; Brexit: The Implications for the Insurance Industry.

Two of the pending EU laws in the pipeline that will be most cited are the Payment Services Directive 2 (PSD2) and the General Data Protection Regulation (GDPR). While both of these do not relate to information security per se, security is an enormously important component of each, and penalties will be commensurate with the egregiousness of the data misuse/loss.

The UK would have had to make these law within the next 2 -3 years, but now what? If we’re not IN the EU, do we have to follow the EU rules? Can’t we just do our own thing, like the US?

Well yes, we could, all we’d have to do is adopt something like Safe Harbor and all EU countries would be more than happy to do business with us. Right?

I don’t think so somehow.

Clearly the UK would never put itself in that position [praying silently], and seeing as both PSD2 and GDPR are fully supported by the UK, I would very much doubt any UK-only law would be markedly different. But ANY difference will still complicate things for UK businesses. It will likely require UK organisations to be far more pro-active in the demonstration of their compliance than would otherwise be necessary.

And if there’s one thing that no organisation I have ever come across is good at, it’s the demonstration of good security practices.

Not one.

Luckily for us, there is absolutely nothing in ANY regulation of which I am aware that requires anything more than ‘appropriate’ controls. From the GDPR for example; “Personal data should be processed in a manner that ensures appropriate security and confidentiality of the personal data, including for preventing unauthorised access to or use of personal data and the equipment used for the processing.

This is the greatest thing about my chosen career; Information security cares nothing for law, regulation, compliance, geography, or politics, it’s about a piece of data, on a computer, that someone wants to steal. Everything else is just reporting.

However, getting to the point where the demonstration of compliance is business as usual, is extremely difficult. Not complicated, just difficult. It’s actually very simple, all you have to do is get the CEO/BoD to care about it and it will happen. Easy, right?

UK organisations had 2 years from May 25th to demonstrate compliance with the GDPR, now [potentially] they have to demonstrate their equivalent compliance to every EU business with whom they want to transact. And you thought answering RFPs was bad now!

Nothing will change anytime soon, but in the meantime, just do what you know you should have doing all along, but start now.

Don’t know how, ask.

Agile Security

An Agile Security Program? I Don’t Think So.

In my vast experience of the Agile Methodology (just over a month now), I have managed to go from a proponent (as in Running PCI as an Agile Project?) to someone who is rather more circumspect when the objective in question falls outside the realm of a short-term project. An easily defined short-term project at that.

In other words, NOT a soup-to-nuts security program.

The overused adage; “If all you have is a hammer, everything looks like a nail.” is particularly relevant here, as Agile proponents have actually gone looking for nails to the point where some security ‘professionals’ are designing their entire program around this single tool! Being generous, this shows a spectacular naiveté,  at worst, it shows a complete ignorance of what constitutes a sustainable and effective security program.

And to be clear; Agile is a tool, nothing more. It is not a philosophy, it’s not even a framework, it is used for very specific requirements at very specific times for an easily quantifiable result; like a new user interface, a segmentation project, or even the installation of a centralised logging technology. Where it make absolutely NO sense is the exact place a good security program starts; with the culture.

The implementation of a good security program has always been, and will always be, more art than science, and completely dependent on the prevailing culture, a culture defined by the CEO’s attitude towards it. In other words, trying to implement a security program AND instill a culture at the same time with nothing more than a single tool, is no different from trying to build an entire house with just a hammer. It simply does not work that way.

Also, those focusing on Agile tend to come from a highly technical background and therefore focus on technology over process, which just compounds the problem to the point where any short-term gains will be built on nothing but air (like my sandcastle ‘metaphor’). Technology is critical for the automation of KNOWN-good processes, it can never be the solution in and of itself.

In one of my first blogs I posited that there are only Four Foundation of Security:

  1. Management Buy-In / Culture
  2. Policies & Procedures
  3. Governance
  4. Education & Training

…I would now actually add a fifth; Vision (or perhaps just include it in the first one), as it’s the CEO’s vision for the organisation that will drive the development of an appropriate security program.

Assuming you agree with the Foundations, perhaps you can now see how using Agile for any one of them is utterly meaningless. Implementing two week sprints and daily stand-ups to ask whether or not the CEO has signed-off on the security policy framework, or if all relevant staff have taken their annual awareness training, makes no sense whatsoever.

In the development of a security program, a competent security practitioner at the CSO / CISO level would usually follow these steps (gross oversimplification):

  1. Get the CEO to agree to take an active role in the program’s implementation / socialisation. Get this in writing.
  2. Define the governance framework to get all relevant senior stakeholders to the table. Have the CEO ratify it.
  3. Draft Information Security Policy Framework for the policy committee’s review and approval. Have the CEO sign it.
  4. Distribute the relevant policies to the right people as part of the socialisation and initial training exercise. Have the CEO visibly endorse it.
  5. Implement an ongoing awareness program to solidify the culture changes. Have the CEO evangelise it.

If you can’t even get the first step in place, you needn’t bother with the rest, as no matter what you do your security program will collapse under the weight of indifference.

No tool is going to fix this, certainly not Agile.

Screen Shot 2016-06-08 at 14.47.48

Why I Offer a ‘CEO Discount’

A CEO Discount is when I offer an organisation a 10% reduction on my consultancy day-rate if they can arrange for a 30 minute 1-on-1, face-to-face, with the CEO.

Sound like a gimmick? Well, it is partially, I’m trying to run a business, but it’s only partially a gimmick, as it is also extremely beneficial to both sides. It also addresses to most fundamental of all security challenges; management buy-in.

From the client side; no project, especially ones related to security, get anywhere near the amount of support from all levels of the organisation that they need to be; a) operationally effective, and b) cost effective. If the CEO offers not only their verbal support, but active/pro-active support behind an objective, it becomes everyone’s priority. As I’ve quoted incessantly; “If my boss doesn’t care about something, guess how much I care about it.“. This begins at the CEO level and doesn’t stop until the most junior person is equally infected by apathy, indifference, or both.

If the CEO cares, or is seen to care, security related projects tend to finish in half the time, at half the cost, and with double the effectiveness and sustainability. Yes, I just made these statistics up, but in 15+ years doing this stuff I would be very surprised if I’m off by much.

From my side; If the prospective client is not prepared to even entertain the notion of approaching their CEO, that tells me all I need to know about their security culture. They don’t have one.

A phrase I have used MANY times now; “Let’s be very clear; The CEO sets the tone for the entire company: its vision, its values, its direction, and its priorities. If the organisation fails to achieve [enter any goal here], it’s the CEO’s fault, and no-one else’s.

I should UP my day-rate if I DON’T get to see the CEO!

So with just 30 minutes of prep, which will hopefully result in an agreement from the CEO to send just 3 emails over the next 6 months (which I will even draft), I will have removed the vast majority of roadblocks faced by every security person, usually on a daily basis.

Most security people feel, and in the words of the hopefully immortal Billy Connelly; “…as welcome a fart in a spacesuit.”, anything I can do to deflect that stigma is worth a measly 10%.

Anyway, what are the 3 emails I referred to (with gross summarisation)?:

  1. Dear All, a company-wide security program is happening, this is VERY important to me, pay attention and give the implementation team your full support. I will be receiving regular reports.“;
    o
  2.  “Dear All, we have finished the security framework, and released the new policies, procedures and standards that will dictate how we conduct our business from this point forward. An education and training program will be released shortly, and your FULL cooperation is expected. I will be receiving regular reports.“, and (if required);
    o
  3. Dear Some, [and I know who you are from my reports] you are not taking this program seriously, start doing so or there will be consequences.”

Of course, this is all very negative, but there is no reason this could not be organised as more of a ‘carrot’ than ‘stick’ exercise. Marketing/PR should be allowed to focus their communication skills and efforts internally when stakes are this high.

It takes just one visionary CEO in an organisation’s history to get the ball rolling in the right direction, the security program should then become completely self-sustaining as the obvious and ever growing need for security becomes embedded in the culture. There is no security until everyone accepts their individual accountability for it, and are active in doing their part.

With any security program, individual incumbents in ANY role should take a backseat to the company-wide culture, even the CEO. The reason most security programs fail is because they were driven by the security department without the necessary support from senior leadership. From my perspective, if the CEO doesn’t support something, don’t even bother trying to implement it, even if it’s the right thing to do.

Why do you think so many CSOs and CISOs fail? A few are clearly incompetent, but the majority of them just didn’t get enough support to make positive change.

If a few hours a year of the CEO’s time to instill a business saving culture is too much to ask, they will be breached, and they will deserve it.

leadersdemotivator

Manager or Leader? I’ll Take The Third Option Please

Have you ever noticed that a lot of organisations purporting to embrace change and innovation end up hiring the same type of people who are the majority cause of their current challenges?

‘Talent acquisition’ is much like the famous [mis]quote by Henry Ford; “If I’d asked my customers what they wanted, they’d have said a faster horse.”. By sticking to standard job descriptions and not looking for PEOPLE to fulfill the leadership’s vision, companies will get what they ask for, and not what they need.

I’ve never seen a job description yet (that wasn’t written by me, FOR me) that did not set me up for failure before I even began. There are people much better at certain things than me, and who may actually enjoy doing them, why would you give those things to me?

Worst of all, above a certain level of seniority, you wind up being lumped into one of two categories, and if you’re REALLY unlucky, both; Leader and/or Manager.

What if you’re neither?

Here’s a little experiment I conducted:

I typed; “books on leadership” into Google and got >271,000,000 hits. If even 0.1% of those are ACTUAL books, that’s 271,000 books on leadership, some of which may even have been written by a true leader. Possible, but unlikely.

Then I typed “books on being a manager” and got >170,000,000 hits If I apply the same criteria as above, that’s another 170,000 books to plough through.

Finally, I typed “books for neither a manager or a leader” and these are the top 5 hits;

  1. 3 Things That Separate Leaders From Managers – Business Insider
  2. Managers and Leaders: Are They Different? – Harvard Business Review
  3. Why All Managers Must Be Leaders – Forbes
  4. Leaders and managers, leadership and management … – CIPD Courses
  5. Why Managers Can’t Lead and Leaders Can’t Manage

OK, so I’ve completely tipped this in favour of the point I’m trying to make, but not ONE article on the first 5 pages of hits gets close to what I’m saying, which is;

People who are very good at what they do don’t need to be a Leader or a Manager, they need a great leader in whom to believe, and great managers to get the right people on board.

My favourite phrase on leadership is on www.despair.com; “Leaders are like eagles, we don’t have either of them here.”. The same could be said for managers, both leadership and managing people are talents not skills, and the really good ones are equally rare.

What if the skills you need, even temporarily, are actually in someone who’s neither? The odds are they are not, well, not good ones at least.

A good leader has specific attributes that VERY few people have (hence LEADer I suppose), and I truly believe leadership is not something you can learn.

A good manager is, to me, someone who can recognise the talents and skills you HAVE, not the ones they either a) think you might have, or b) want you to have, or c) need you to have for the job at hand.

Focusing on these 2 senior-level talents ignores the vast array of available of other talents that require neither of these attributes to provide enormous benefit. Call them subject matter experts, gurus, trusted advisors, or a whole host of meaninglessly clichéd names, what you get is the same; someone who can take the leader’s vision, and translate it into something the managers can act upon. Leaders usually can’t manage, managers should rarely lead, and neither has the necessary talents / skills / knowledge to bring the vision to life.

So if you have failed at fulfilling either of these roles (as I have many times), maybe they are not for you. But what you DO have could be of equal importance, if you know what it is.

No one likes to think they’re not a good fit for a senior position, but there’s little reason to extrapolate one or two bad ‘corporate’ fits into the rejection of an entire line of opportunities. Just make damned sure you ask the right questions up front. No you can’t guarantee an honest answer, but hopefully you’ll know pretty quickly if they sold you down the river.

Screen Shot 2016-05-26 at 13.48.23

PCI DSS v3.2 – What a Difference a ‘Dot’ Makes

In my continuing struggle to prove once and for all that I am the saddest bastard alive, I have spent an inordinate amount of time performing a side-by-side comparison of the PCI DSS changes from v3.1 to v3.2.

Not just the DSS itself, oh no, that would be too simple and nowhere near as pathetic, I have actually taken the Report on Compliance Reporting Templates and compared them instead! All 1,359 lines of it! You can download my initial draft here: PCI DSS v3.1 – v3.2 Mapping of Changes_v160526

Impressed? No, me neither.

Self deprecating humour aside, I actually had a very good reason for this; Only the validation of compliance really matters, the standard itself is not where the rubber meets the road, the RoC Template is. Even the ‘Summary of Changes from PCI DSS Version 3.1 to 3.2‘ cannot match the level of detail you can obtain from comparing the individual ‘Report Findings’.

I have written frequently on the inadequacy of the PCI DSS, so what is my overall opinion of the changes to v3.2? Actually, they are not that bad. I’m not saying the standard is starting to look like real security, but as far as it CAN go, it’s heading on the right direction in terms of how to both validate and report compliance.

Aside from the new requirements (which I address below), to me the biggest change was the significant reduction in the number of Report Findings for which you need to “describe how”. The consolidation of these descriptions puts the onus back on the assessor to properly validate the requirement, instead of having to spell out everything they did to do so.

However, the issue I can see with constant change from version to version is that it becomes next to impossible to even partially automate validation in centralised tool-sets (like GRC) because the RoC Template still focuses more on WHAT is written than HOW to actually perform the validation itself.

So, to the significant changes for everyone:

  1. Requirement 3.3 – Not sure why anyone would want to see any of the ‘middle 6’ digits and not the full PAN, but this requirement now helps to clarify things for those who do. Basically, you need to put the same controls around the middle six as you would the full PAN.
    o
  2. Requirement 6.4.6 – It’s unfortunate that the SSC feels obligated to insist on validation that any changes to the CDE still conform to the PCI DSS, but it would not be have been added if organisations were actually doing it properly.
    o
  3. Requirement 8.3 – Change from 2-Factor Authentication (2FA) to Multi-Factor Authentication (MFA), and now EVERY form of administrative access to systems must be via MFA, not just remote access (this is by far the biggest ‘blanket’ change). This has always been a best practice as far as I’m concerned, and I’m glad that the SSC has finally written this into the standard. If this is difficult for an organisation, or something they want to avoid, I have to wonder what else they don’t have in place.

…and for the poor Service Providers who rightfully bear the brunt of the changes:

  1. Requirement 3.5.1 – SPs must now provide a ‘cryptographic architecture’, but it’s not clear if it’s only to be given to the the QSA validating the SP’s compliance, or if it’s for client consumption as well. Have to assume the former.
    o
  2. Requirement 10.8 – SPs must now detect and report on system failures. How this was not part of every organisation’s vendor due diligence process, and written into every SLA as a matter of course, is beyond me, but I know for a fact this stuff rarely is.
    o
  3. Requirement 11.3.4.1 – SPs must now perform semi-annual penetration testing on segmentation (if applicable). This should not be an issue for Cloud or VM providers IF, and ONLY if, they have configured their service correctly. However, this requirement does not cover those  SPs who have a bunch of servers on flat network and do not care about segmentation, which I would argue is far less secure.
    o
  4. Requirement 12.4 – Pushing SPs to make protection of CHD an Executive responsibility. Unless there are some kind of penalties attached, SPs will pay limited lip-service to this and just write some kind of charter or policy. Smoke and mirrors basically, but good for the SSC for even trying.
    o
  5. Requirement 12.11 – SPs must now perform QUARTERLY audits against several controls, which is a very good thing IF it’s done correctly. To perform this function well, SPs would need to institute some form of Internal Audit function, as well as a Governance-esque function to oversee it. Good luck with that.

So, overall, I’d say this was a pretty good change as the DSS goes, but with another 20 months until any of it is enforced, I sincerely doubt things will change for the better in the short-term.