Category: Innovation

Remember when CheckPoint were just firewalls, Symantec were just AV, and security companies could just provide consultancy?

Neither do I, it’s been too long.

Security has now become too complex, and too important to play the mix-and-match game with individual vendors, it’s only integrated, multi-function, solutions that will now make the cut.  But there are so few of them out there.  Well, so few that actualy do what they say they do anyway.

As security became a multi-billion £/$/€ a year industry, hundreds of companies started up to bring us the silver bullet appliances that will end our problems forever.  Not only do silver bullets not exist in security – and you should be shot for using the phrase in any way that’s non-derogatory – but where are those companies now?

They either failed, or have been bought up by larger companies who have tried to duct-tape the disparate products into silver-bullet SOLUTIONS.

Which have also failed.

It’s not that the products don’t work, some of them actually do, it’s that;

  1. Businesses threw technology at problems without knowing WHY they were doing it
  2. The big companies that collected the smaller ones tried to integrate the individual products together under one GUI, instead of unifying the functionality under a single code base
  3. There has never been, and there never will be, a one-size-fits-all solution to security

But the market is still ripe for innovation, and there will continue to be companies starting up with the goal of bringing a single product to market that will catch the latest security hype/wave/buzz and make them their fortunes (MDM for example).  They may even succeed, but only if they make their impact in the first year or two, otherwise the market will have moved on.

If they’re VERY lucky, the larger companies that collect little ones will be naive / ignorant enough to buy them and save them the trouble.

I am not against combining single products into a larger solutions, in fact it’s the only way to go, but only if it’s done correctly.  Single product companies have 100% focus, which gives them drive, goals, and a dedication to making their one product the best. The second you absorb that company, every one of those attributed that put them on (or near) the top, is lost in the larger mix.  The functionality is diluted, innovation ceases, and the the whole thing quickly becomes obsolete.

True integration of functionality can only be accomplished with a single code base, and a single platform, which means that any organisation that absorbed the smaller companies better have a plan in mind to migrate not only the applications over to their growing solution, but they will need to consider all of the clients who bought the product prior to the M&A.  These guys often suffer from a total lack of customer service and support, and there’s no way they’ll buy into the larger programme.

From what I have heard, the due diligence necessary to combine product companies is not overly abundant, and until it is, we should all be VERY careful when we look to resolve our security issues with multi-function solutions.

That’s why I call these ‘collage companies’, as the picture might be pretty, but it’s in no way whole.

Here are a few questions you might want to ask your potential providers;

  1. Can your solution replace some / most of my current functionality?
  2. Do you provide a consultancy ‘wrapper’ around these solutions to help us manage them against our business goals?
  3. Will the output from your solution feed into my current collection mechanism, or can my current output feed into yours?
  4. Are the various aspects / functions of your solution ‘home grown’, or obtained through acquisition?  If acquisition, how have you unified the back end code and platforms?
  5. How do you ensure that the different functions of the solution receive a similar attention to what the single product vendors provide?
  6. Do you have a single customer support process to handle all functionality questions?

Regardless of the shenanigans going on in the security product market, your choice of vendor should only be driven by what your risk assessment and gap analysis said you need, and your due diligence should cover any requirements you may have regarding integration and ongoing maintenance.

If is doesn’t, don’t expect the collage companies to help, they have enough problems keeping their own houses in order.

Choose wisely.

The only established job title I agree with, is ‘Consultant’. They can:

  1. say without fear of repercussion; “I have no idea, but I know someone who does.” They are enablers, not [necessarily] SMEs;
  2. add new projects / functions / experiences to their CVs/resumes because their entire role isn’t defined by a single job description; and
  3. stop someone asking questions about what they do, because the answer; “I’m a consultant.” fulfilled the societal obligation.

Every other title out there tells you what that person does, and to an uncomfortably large [judgemental] degree, WHO they are. Ever taken an instant dislike to someone who told you they were a traffic warden? But how many people really think of themselves as defined by their job? Nurses perhaps, charity workers, priests? Do you really think of yourself as an ‘actuary’, or a ‘receptionist’?

While there are many jobs out there where your personality shines through, most of us are not doing them. We’re working in the information age where we our entire output can easily point to nothing tangible. We’ve ‘made’ nothing, yet we still want to believe that we are making a positive difference, don’t we? How can we possibly put the age old corporate strictures around something so fundamentally different as today’s job market?

Doctors don’t prescribe leaches and bleeding for every illness, banks don’t process every transaction on paper (though I think Lloyds might), so why do we maintain the centuries old concept of pigeon-holing everyone into a job title? Would it not make more sense to describe all the FUNCTIONS or TASKS a business requires, then let the right individual(s) perform them?

How often does the best person to perform a task actually get to do it? They may be in the wrong department, the wrong ‘grade’, or have the wrong boss, but the effect is the same; the person who is paid to perform the task as part of their defined job description does it, and possibly nowhere near as well as the person best suited.

There is a very good chance that no-one even KNEW there was someone who could do it better. Usually this is a combination of two things; 1) no-one bothered to find out, and 2) no-one volunteered the knowledge. This is not just about employers not providing an environment that embraces change, it’s also about employees that don’t WANT change. Either be the agent for change, or don’t complain about the status quo.

How many times have you had an idea for a process change, and new profit line, a morale booster etc, then had it shot down for one or more of the following reasons:

  • It’s not your job, go back to doing what you’re PAID to do;
  • It’s not the right time – with no indication of when it MIGHT be the right time;
  • We’ve always done it this way – try not to punch this person in the face; and/or
  • It simply won’t work – with no indication as to why.

…or a thousand other reasons that all amount to the same thing; You have your day job, leave it at that. You may even have been made to feel bad about suggesting it in the first place, which means you’ll never do it again.

The reasons for this are as infinite as the excuses. A few are:

  • Your boss has no idea what he/she is doing and you’re humiliating them;
  • Your organisation is led by someone with no imagination, or ability to inspire; and
  • They simply don’t understand the concept.

YOU can be just as much to blame however:

  • You spend all your time at work working on things that you are not being paid for, and your real work suffers;
  • You have put no real thought into the idea, or formalised your plan; and
  • Your idea is crap.

But these examples don’t change the fact that most organisations hire people to fulfil a specific task without taking the individual’s full skill-set into account. They are then either marginalised, or actively held back from developing additional skills, or expanding their function beyond a very limited scope (usually departmental).

Nature doesn’t label, it just is. The strongest in the pack is Alpha, the best hunters lead the hunt, and every living thing just gets on with doing what they were born to do. Not humans. We have to label, compartmentalise, pigeon-hole, classify – I mistyped that as ‘calcify’ which is amazingly appropriate – in order to understand. We have good-vs-evil, up-vs-down, in-vs-out, just so we can explain things to ourselves.

In the workplace, the larger a business becomes, the more disconnected it becomes. There is no room for the individual, let alone the individual’s unique set of talents and skills, but I believe this is exactly where we need to go. It may well be that the guy in accounts payable is a wizard at data analytics, so have him help out in Marketing. The girl working in Research & Development has an uncanny ability to relate to people and “talk their language”, so take her out to close the more complex deals.

Once you know the individuals, titles are irrelevant. People just KNOW who they are. The two people above are “the data guru’ and ‘the closer’ respectively, and are happy because they get to do what they’re good at! Who knows, they may even get appreciation for it, and the organisation is happy because they have a competitive advantage.

Even hiring becomes easier. You don’t hire against a job title, you hire against a required skill-set, which is MUCH easier to interview for. Then when you ask that person what title they would like, they can be creative / unique enough never to feel as though they are just another cog in the wheel.

Of course, to the outside world you will still need to give them known titles. Until this catches on anyway. And some people WANT to go to work 9-5, be anonymous, and that’s OK, every business can’t be full of entrepreneurs and go-getters.

[If you liked this article, please share! Want more like it, subscribe!]

As you probably know, the PCI DSS is a minimum set of security controls that must be in place around anything that transmits, stores, or processes cardholder data. That’s probably why the card brands and the SSC get so irritated that even this basic set of good practices is so hard to achieve.

That said, unless you have a way of monitoring and maintaining your compliance within these baselines, it’s not only VERY difficult to stay compliant (let alone secure), it makes validation of your compliance an annual nightmare of gathering screenshots, log samples, and so on. I estimated that validation of controls can take up to 50% of the entire annual assessment cycle.

This is a tremendous loss of resource time, and does nothing for your ROI. So why DOES the PCI DSS only require an annual point-in-time validation and not validation of continuous compliance? Yes, you are accountable to stay compliant at all times, but you only have to validate it once a year, and – if you’ve earned it – on only a sample of your systems.

The answer is, they simply cannot go that far. Continuous compliance validation is far more difficult than achieving PCI compliance, and is firmly in the realms of good security practices. They can enforce minimums, they cannot enforce more than that and get the necessary acceptance.

So what IS Continuous Compliance Validation? “It is the near real-time notification of a variation from your baseline norms.” Or to put it another way; once you know what something should look like all day every day, you want to know if it changes from that.

For example, the PCI DSS specifies over 20 validation points for an operating system; e.g. business justification for all listening ports; access control; logging; FIM and so on. Once a year, you have to show your assessor that these validation points meet the DSS requirements, and that’s it for the YEAR! All too often, systems fall out of compliance within a matter of days.

Instead, what I propose, is that you should automate (as much as possible) the collection of that validation data, and compare it to not only the PCI DSS requirement minimums, but to ALL of your compliance / regulation / internal policies / standards. And not yearly, but hourly, daily, weekly, whatever makes sense. Wouldn’t you rather show your assessor a green checkmark for ALL of your systems than a dozen screenshots for a mere sample?

If this can be configured for just 50% of your in-scope devices, your entire annual validation burden will be enormously reduced. Plus, you also have a very convincing addition to your compensating controls for lack of FIM or AV (if applicable).

Best of all, you are now doing security as it was meant to be done; Enterprise wide, and Business As Usual.

Any operating system experts out there want to help me put this together?

[If you liked this article, please share! Want more like it, subscribe!]

If you came this far you did one of the following when you read the title:

1. Scoffed;

2. Screwed up your forehead in confusion, or;

3. Laughed.

Good, these all mean you’re cynical and therefore a perfect audience, so let me put you out of your misery; this is a story of unintentional cause and effect, and has started a trend that will not stop until credit cards as we know them are dead and buried.

About time too. 60+ year old technology in payments is akin to leaches in medicine (no offence card brands, but this analogy is particularly relevant).

When PCI was first drafted, it was very clear for whom it was geared; e-commerce organisations running Windows. How do you translate the configuration standard requirements (for example) to someone working on a mainframe. For Windows, you take out what you don’t need (hardening), for zOS, you build in only what you need. What about logging? Can syslog record everything you need in 10.2.X?

This is one of the most minor issues that drove organisations to seek alternatives to compliance, cost / effort / ROI, you name it, PCI is a burden any way you look at it. Yes, cardholder data should be protected, but enforcement of a single standard across all industry sectors and business types was never going to work.

At first, organisations became VERY creative in making their PCI burden go away. From outsourcing, to revamping all business processes in favour of truncated card numbers (except authorisation of course), to going back to cash only (not kidding). While almost EVERY merchant organisation should consider the first 2 anyway, it really didn’t help either retail, or e-commerce.

So the first foray into a technical ‘innovation’ was to make PCI go away for areas where they could not fix their systems to a degree that supported PCI compliance. Organisations started looking for alternatives to processing the full cardholder data; tokenisation was born (poetic licence, we’ve had forms of tokenisation for centuries). But this does nothing for authentication traffic which requires the fill account number.

Then came my personal favourite; Point to Point Encryption (P2PE), a.k.a. – and before the SSC decided to kibosh it – End to End Encryption (E2EE). The theory is very sound; encrypt the data for the point of interaction (usually a Pin Entry Device, or PED) all the way to the point of decryption, but the eventual PCI-approved solution is as complex as the DSS, limited (currently) to approved hardware devices, and requires a degree of certification few have even looked at.

A lot of organisations put their entire PCI programme on hold until such times as the P2PE standards were defined, and now that the first one (hardware/hardware) cannot apply to them, they continue to do nothing until such times as a hybrid standard is released.

So what you have here is; PCI forced the innovation, which in turn caused a justifiable delay in doing anything at all, which means that cardholder data is no better protected. Brilliant.

So P2PE, which had so much promise, is now stagnant. Organisations SHOULD have developed software solutions for legacy PEDs 3 years ago, which would have almost forced acceptance. But no-one did, and now it’s too late. How do you standardise a P2PE solution for an infinite number of scenarios? You don’t obviously, but with the advent of the next innovation, even PEDs themselves are becoming redundant…

We have the ultimate PCI and card brand killer; Mobile Applications / Mobile Payments. Still fairly new, growing exponentially – and to add the ultimate piece of irony – but cannot be PCI complaint unless the device was built for purpose. In other words, smart phones and tablets, by themselves, can never be PCI compliant. Not that this will stop their use.

Mobile payments, in all its forms, is already forcing the CARD BRANDS to innovate, or in the case of Visa, buy interest in vendors like The Square. But the SSC, as a standards only body, can never keep up. Eventually, as credit card numbers decline, so will the SSC and ALL it’s standards, and a replacement will be formed when people realise this massive drive for innovation has set us BACK in security…again.

That’s my final point of this blog; unless security is built in from the ground floor of this wave of innovation, the innovators will be directly responsible for the impossible-to-follow standards of the future.

As long as there are profit drivers, and Windows OS, I will always have a job…

 

With the exception of the iPhone ‘S’ versions;, The Cloud is perhaps the most irritating concept of the last decade.  It is the definitive re-branding of an existing service in order to drive new business in an era of doubt and uncertainty.

Security issues have become far more mainstream over the last few years, and lawmakers in every country are struggling to keep up with the demands for better protection of personal data.  So what we have now are hundreds of companies providing cybersecurity services ‘In the Cloud’. As though this is something new, and a must have for all organisations.

Breaking it down into its simplest terms, services in the cloud are services provided over the Internet.  Haven’t we had this for quite literally decades?  Why is the service to manage your firewalls suddenly a Cloud service, what’s wrong with simply calling it a MSS?

There are really only two valid ‘Cloud’ services;

1. Access to applications or resources you don’t have, and;

2. Distribution of functionality.

Everything else you do ‘In the Cloud’ is simply outsourcing, which is a perfectly valid, and often the best option.

Like everything else in security, never buy anything based on either a perceived need, what is the latest-and-greatest, and especially not a compelling sales pitch.  All capital expenditure, and moves toward outsourcing start with a business need, not external influences. This  includes compliance to regulatory standards.

You don’t need Cloud per se, you need a business process made cheaper, more efficient, or more competitive. HOW you get that done MAY include Cloud-esque services, but that will be determined by your Risk Assessment. Not by your CEO who read an article on his/her way to work, and certainly not by the fear of not having the latest toy.

Cloud services also add a layer of complexity that will generally be missing from most bespoke managed services; shared resources across multiple clients.  Who has access to your data?  How is your data kept separate from everyone else’s?  Because Cloud is a relatively new phenomena, SLAs and contract language has yet to catch up, so vendor due diligence takes on additional import.

In terms of providing a platform expertise that you don’t posses, or an operational resilience you simply can’t afford, Cloud may be an option. That said, you have best be sure your ‘Cloud’ provider has designed their service from the ground up, and not adjusted their marketing material. The latter, sadly, is by far the most prevalent.

Bottom line; do your homework, and run your needs by a security expert before taking the plunge.