Virtual CISO

Are ‘Virtual CISOs’ a Good Idea?

Type “virtual CISO” into Google and you’ll get ~240,000 hits, with the top 10 being mostly vendors who offer this as a service. I have no doubt much of the remaining pages are the same.

In other words, just about every security vendor out there is seeing a need, and they want to be the ones to fill it. As a corollary, if organisations weren’t crying out for the service, no-one would be offering it.

I am no different, in that I too see a massive gap in senior leadership security expertise that no one in-house can fill. Due to price constraints, it is quite often inappropriate to fill such a senior and specialised role on a full-time basis. Where I differ is the length and function of the v-CISO, as I cannot see how an indefinite ‘outsourcing’ is in my client’s best interest.

Let’s face it, once you outsource the function of something, it is a very small step to try and outsource the responsibility for it too. And finally, if you got away with that, an attempt at shirking the accountability is never far behind. This is where both organisations asking for help, and v-CISOs alike, make their biggest mistake.

The v-CISO should never be a long-term proposition, which is why I call my service an ‘Interim Security Chief’. While this may seem like semantics, it’s the difference between doing the work for you, and enabling you to do it for yourselves.

First and foremost, a v-CISO should be a teacher and a mentor, not [necessarily] a ‘doer’. Yes, they can design big-picture processes, from secure architecture to governance charters, but they had better not be expected to own them. A good v-CISO is nothing more than an consultant at the senior management level, and any deliverables must be sustainable long after they have moved on.

That said, I see nothing wrong with a v-CISO remaining part of ‘steering committees’, providing ongoing security awareness training, or even taking part in incident response testing. But, once the CISO functions have been absorbed internally, the v-CISO becomes part of the cycle for continuous improvement only. They stay around to provide strategic input on industry trends and the changing threat landscape, they don’t dictate the enterprise goals.

What You Should  Expect From a v-CISO

These are the three main things you should expect from a v-CISO, take particular note of the transience of each deliverable.

  1. Governance Charter Development – There is no security program without Governance, and there is no better platform onto which the v-CISO can pass on their operational function. This committee can in fact replace the v-CISO in due course, but may bring them back in as a trusted advisor or SME. The members of the governance committee will share the CISO function amongst themselves based on individual capability, and their meetings will bring it all together.
    o
  2. Policies & Security Awareness Training – Along with governance, policies are intrinsic to a security program, and along with the formation of that committee, represent the most important part of a v-CISO’s role. Unless the polices are in place, and all employees appropriately trained, nothing else they try to do will work effectively.
    o
  3. Process Development – Security programs consist of a number of critical processes, all of which must be developed, tested, tested again, and take their place in the never-ending cycle of improvement and business as usual. These are the big ones:o
    • Risk Management – Includes the enterprise-wide risk assessment and risk treatment procedures.
    • Vulnerability Management – Keeping up with the threat landscape.
    • Vendor Due Diligence & RFPs – Significant aspects of the security program will likely be outsourced to skilled providers, so the right questions must be asked.
    • Event Management & Incident Response – Bringing all the controls together into a business saving process.
    • Disaster Recovery & Business Continuity – What to do if everything goes completely pear-shaped.

Anything else the v-CISO does will depend on the organisation’s needs and the v-CISO’s skill-set.

But what about Strategic Advice, Board Level Interface, Regulatory Compliance Lead and a whole host of other fancy names / clichés? Yes, these are all important, but are utterly meaningless until the basics are in place.

Any security program put in place by a v-CISO must be in-line with the business’s goals, appropriate to their needs, and sustainable in their absence. So if you’re on the market for a v-CISO, you had better know what you need, or you’ll get what a salesperson thinks you asked for.

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

Change Your QSA

Too Scared to Change Your QSA?

Or perhaps the question should be; “Can’t be bothered to change your QSA?

Or an even worse scenario; you know you can’t change your QSA because the new one might discover things you’ve been hiding from the last one!

I can almost empathise with the first two, but if it’s the third scenario you deserve the bad things that will happen when you get breached.

The fact is, if you have been working with a good QSA, not one of the challenges I list below will apply to you, Changing QSAs, or even QSA companies will not be an issue. You will have been doing security properly, and not just faking compliance.

Challenges:

A significant number of organisations are faced with at least 1 of these 5 main challenges;

  1. Lack of Continuity – Employee attrition is inevitable. QSAs have historically bounced from one QSA company to the next following the money. Which has been abundant for almost a decade now. This has left many clients in the unfortunate position of having to start all over again with another QSA. Often one who has received little to no hand-over.
    o
  2. Lack of Guidance – This is the QSA’s only real job. Other than writing the second half of the Report on Compliance, ALL of the remediation work belongs to the client. The role of the QSA is to ensure that the client NEVER hits a roadblock. QSAs are supposed to have ‘been-there-done-that’, so “What’s next?” should never be a question the client has to ask.
    o
  3. Inconsistent Opinions – Every security consultant has a different skill-set. Some are network wizards, others know encryption, most should be very familiar with policies and procedures. What happens when your last QSA agreed something that your current QSA won’t accept? Who is accountable for the loss of resource and/or capital cost?
    o
  4. Starting Over Again Every Year – Too many  QSAs are ‘just QSAs‘, with little experience or capability in fitting PCI into sustainable security processes. If your PCI compliance looks like an annual project, it is. Validation of compliance should be a simple process that should fit neatly into your BAU program. If it doesn’t, there’s a very good chance your QSA is at least partially to blame.
    o
  5. Black-Hole Communications – If you expect your QSA to be a project manager, you have completely misunderstood the dynamic. But if you expect them to respond to emails requesting guidance in a timely fashion, you should. A QSA is there to tell you everything you have to do to achieve compliance, that’s their job, they must be readily available.

Mitigation:

OK, so those are all the bad things, how do you fix them? Easy, choose the right QSA in the first place!

Facetious yes, and likely a moot point, but it’s never too late to change:

  1. For Lack of Continuity – All good QSAs have a methodology; Have you seen it? Does you QSA even have one? If the answer is no, you don’t have a good QSA. Continuity is simple, it just requires discipline, and a plan.
    o
  2. For Lack of Guidance – As stated above, this is the QSA’s only purpose, if they can’t provide it, find someone who can. Interview your QSA(s) before letting them onsite, but have your questions prepared. Insist on having access to QSAs suitably qualified in ALL 12 DSS Requirements. You’ll never find this in a single QSA, unless it’s one of the 3 that I know that come close (I’m not one of them).
    o
  3. For Inconsistent Opinions – Agree a process whereby the QSA company accepts mitigation plans or compensating controls, not individual QSAs. Agree, in writing, that ALL QSAs they send will accept a company approved option.
    o
  4. For Starting All Over Again – This is as much your fault as the theirs. If you had a security program in place that appropriately covered your business, PCI would fit into it, not the other way around.
    o
  5. Black-Hole Communications – Vendor Due Diligence + Service Level Agreements + Vendor Management. Period / Full Stop.

Changing QSAs every few years is a best practice, you should ALWAYS want fresh eyes on such a critical process. If changing your QSA is too difficult or inconvenient, it says a lot about both your current QSA, and your organisation’s attitude toward security;

They both leave a lot to be desired.

Here’s some old guidance I threw together a while back; Selecting the Right QSA for Your Business

Like this Article? Don’t forget to subscribe!

All About the Data

Forget Cyber, Forget Cloud, It’s ALL About the Data!

Ever wonder why data breaches are now called cyber attacks, or an application on the Internet is now called The Cloud? It’s for the same reason that Coca Cola is constantly changing it’s ‘look’, adding ‘new’ flavours of what is basically the same sugary mess. And why they’ve changed their slogan FORTY SEVEN times in their 125 year history;

To keep things fresh, to keep you thinking about them, and of course, to help you spend money.

So is this necessarily a bad thing for the field of information security? The answer is clearly no if these marketing ‘tricks’ actually help keep you secure though valid awareness programs and good services. But a resounding YES if it’s just a new buzz-phrase used to sell the same services with less due diligence.

Too many vendors and self-interested lobby groups are frighteningly good at demand generation. From new buzz-phrases, the invention of perceived needs, and playing on an organisation’s fear of losing a competitive edge, these have all been the cause of many bad purchasing decisions. This is especially frustrating when the tools for making good decisions have been around for decades. Literally.

For example; ISO 27001 – probably the best known and de facto security framework – has it’s roots in BS 7799 first published in 1995, ISACA’s COBIT was released in 1996, and even PCI (which is just a controls based standard for the protection of cardholder data) has some merit in its 10th year in existence. If these aren’t enough, the ages-old – but still VERY much alive – concept of Confidentiality, Integrity and Availability has been around for so long that no-one seems to know when it started.

And these are just the overarching frameworks for the security of data, beneath them you have equally well known, mature, and readily available tools for the protection of your data assets:

1. Governance – The Business side and the IT side having meaningful conversations;

2. Risk Assessment – An examination of the business needs applied to the current ability to achieve those goals;

3. Vendor Due Diligence – a THOROUGH review of the external help you’ll likely need;

4. Asset Management – You can’t manage what you don’t even know you have; and

5. Vulnerability Management and Change Control – If you have absolute control over the changes you make internally, the only things that can increase risk are from the outside. These two tools work hand-in-hand.

All of these tools are covered to a varying degree in the above frameworks, and represent standard good security practices established for longer than most of us have been alive. Without these processes in place, you don’t have data security. Full stop.

So if they are that established, why are they not as well known and pervasive as they should be? Simple, and for the same reason no-one likes paying for insurance; there is no obvious positive impact on the bottom line. Where’s the ROI for spending money on security? But this assumes that an ROI involves making MORE money, but is not LOSING money just as impactful? Fines, damages / reparations, and the inevitable loss of reputation all have significant negative impact.

Instituting an appropriate level of data security for your business is actually quite simple, keeping it in place requires much more effort but is equally simple; follow the decades-old advice of the existing frameworks.

[Ed. Written in collaboration with Voodoo Technology, Ltd.]

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

‘PCI Compliant’ Service Providers, You Are Warned!

Readers of my blog know I am opinionated, which I why I have so many non-readers I suspect. I find myself now with something of a mission, and that is to either train providers of PCI-related services to perform 12.9 correctly, or I will make available a responsibility mapping matrix of their Attestation of Compliance (AoC)-defined services. Merchants need to perform appropriate due diligence, without full disclosure and guidance from Service Providers (SPs), this is all but impossible for the majority of non-PCI experts.

I  am not saying the SPs are doing anything nefarious,[mostly] they are not, it’s just clear that neither they, nor it would appear their QSAs, have taken the time to produce a responsibility mapping that makes sense.

I will not be posting names, but if you contact me on david@coreconceptsecurity.com and ask about a specific provider, I will tell you whether I have the mapping or not (just started this, so it’s unlikely, but stay tuned…). I am also happy to accept AoCs for your provider if you want a mapping done. Finally, I am also happy to help SPs directly if they would like to get ahead of this.

For Merchants: Regardless of the SAQ you complete, you are responsible for EVERY requirement in the PCI DSS, so any mapping and contract you have in place must be at that requirements level, not that of the SAQ, so if all you get is an AoC, there’s a very good chance your residual responsibility is significantly higher that you would like, and perhaps been led to believe.

At a minimum, your mapping will have 3 columns:

  1. AoC Mapping – This is the only ‘official’ recognition of the requirement numbers included that you have to go by, anything else the SP may say is irrelevant. If it’s not on the AoC, you cannot point your RoC/SAQ to it, and the requirements must still be assessed on your behalf. Note: Be VERY careful re: sub-requirements, if they are not SPECIFICALLY addressed, they are not included (Listing Req. 1.1.5 on the AoC does not necessarily mean Reqs. 1.1.5.a AND 1.1.5.b for example).
    o
  2. Services YOU Require – This is where you specify EVERY requirement you’re looking to outsource, but you need to be reasonable. There are surprisingly few requirements you can fully outsource (depending on the service), and you must detail what partial responsibility must remain with you. For example; you can outsource the changes to your rule-set, but you will usually retain ownership of it (which is the majority of Reqs. 1.X).
    o
  3. Residual Responsibility – This is what’s left for you to cover, and will represent an agreement between you, your service provider, and your QSA (if applicable). Anything NOT handled by your SP, is yours.

The above is not to say that an SP cannot provide significant support outside of their officially assessed services, but whatever they are doing needs to be noted, and included in your report.

For example; regardless of the services provided, EVERY policy requirement is owned by you, and followed by your SP. They may have their own policies, and even have them listed on their AoC, but those policies do not cover you as a merchant from a RoC/SAQ perspective.

Once complete and agreed by both sides, this mapping should form the basis of your contract. It does not matter if it’s an annex, addendum or in the main contract body, but the actual PCI DSS v3.0 requirement numbers must be part of any binding agreement. Whether or not you put SLAs around the services, or require full compliance on an ongoing basis, is a business decision, tying your SP to the DSS requirements they cover on your behalf is a PCI obligation.

I have uploaded an example of a Service Provider Responsibility Mapping that I recently provided to a client – help yourself. Hopefully it makes sense, but you are free to contact me if you would like more guidance.

This is actually a very simple process, as is everything else in security, it’s only not knowing yourself what to do that makes it difficult. So ask for help.

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

PCI DSS v3.0: Service Provider Agreements (Req. 12.8.X)

There seems to be quite a bit of confusion about the ‘new’ requirements for service provider contracts. I say ‘new’ sarcastically because this should have been part of your vendor due diligence processes from the beginning.

From a merchant’s perspective, unless they have hired a QSA (or other PCI expert) to help define the service requirements and contractual obligation, it’s very difficult for them to ask the right questions. From a  service providers perspective, I’ve seen the gamut from complete ignorance of their obligations, to out-and-out lies in terms of what they are and are not providing.

The DSS v3.0 requirements of 12.8.X go a long way to resolve this, but not far enough in my opinion. The bottom line is that someone has to be responsible for each requirement, and there are only the following choices;

  1. SP agrees to be fully responsible for the requirement;
  2. SP agrees to be partially responsible, and;
  3. SP pushes the entire requirement back on you.

That’s it.

The above list is fairly obvious, but for the service provider’s clients the challenges are now twofold:

  1. If the service provider accepts full responsibility, are they PCI compliant for the service(s)?
  2. If they are only partially responsible, EXACTLY what part of the requirement is left?

Does the service provider need to be fully PCI compliant for you to achieve compliance? The answer is no, but if they are not, you have just doubled your assessment scope. Again, someone has to answer the questions, so if your service provider has not validated compliance for the services they are offering, you need to add them to your validation efforts.

As for the partial responsibility, that’s easy, get your service provider to tell you what they’re doing. For example;

DSS Req. #

Description

Service Provider Responsibility Client Responsibility
1.1.3

Examine data-flow diagram and interview personnel to verify the diagram:

*  Shows all cardholder data flows across systems and networks.

*  Is kept current and updated as needed upon changes to the environment.

SP will provide initial diagrams in Visio format for the pre-production environment but will not own, manage, or keep up-to-date the data-flow diagrams post-production.

 This requirement is not part of SP PCI Report on Compliance dated [Mmm dd, yyyy]

Client must own, manage, and keep up-to-date all data-flow diagrams for inclusion into their own PCI compliance efforts once services have reached a production state.

You must repeat the above for EVERY requirement in the PCI DSS v3.0, then add this as an addendum or annex to your signed service contract. This applies not only for the services they are providing DIRECTLY, but the SP has a responsibility for any SUB-contractor they may bring in, and so on down the line.

Again, SOMEONE has to answer the questions!

However, let’s back up a bit and handle each DSS Requirement in turn:

12.8.1 Maintain a list of service providers

Easy, just maintain a list of Service Providers, with – at a minimum – the following detail;

  • Company Name
  • Service Description
  • Is [CONFIDENTIAL] Data Shared?
  • Regulatory Compliance Date
  • Status Verified By

12.8.2 Maintain a written agreement that includes an acknowledgement that the service providers are responsible for the security of cardholder data the service providers possess or otherwise store, process or transmit on behalf of the customer, or to the extent that they could impact the security of the customer’s cardholder data environment.

Even easier, they wrote it down for you!! Include – again, at a minimum – the language in red in your contracts. You will likely want significantly more than this as there is no declaration of LIABILITY, or even SLAs.

12.8.3 Ensure there is an established process for engaging service providers including proper due diligence prior to engagement.

If you don’t have robust vendor due diligence and vendor on-boarding/off-boarding processes you are really asking for trouble. For PCI services, if you have not ensured they are PCI compliant for the services they are providing AND you have the full details written into contact, then you have created a world of pain for yourself.

12.8.4 Maintain a program to monitor service providers’ PCI DSS compliance status at least annually.

Does this say anything about the service providers actually working towards PCI compliance? No, it doesn’t, so the status could be; “They will never achieve PCI compliance.” and this is good enough for PCI. This should NEVER be good enough for you.

12.8.5 Maintain information about which PCI DSS requirements are managed by each service provider, and which are managed by the entity.

This we’ve already covered, all you need is a table, like the above, of every PCI requirement handled by each of your service providers and their sub-contractors. Your QSA can then tell you precisely what is left for you to cover for full compliance.

Whether you’re assessing for the first time, or re-assessing under v3.0, you need to start these conversation with your service providers NOW, as while this may be simple, it is not easy.

Advice for Merchants:

  • Only choose PCI compliant service providers (start here; Visa Europe Merchant Agent List)
  • Only choose service providers who have already addressed 12.8.2 and 12.8.5 up-front. You should not have to ask for this from SP worth their salt
  • If you have existing SPs and don’t know where to start, hire a decent consultant who is familiar with the PCI DSS to help

Advice for Service Providers:

  • Get your responsibility mappings and your contract language sorted out now, BEFORE you are asked
  • If you need help, ask for it, ignorance is not an excuse your clients can accept, nor can the card schemes

Easy huh?