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

Screen Shot 2016-08-02 at 10.25.51

Social Media Is Killing Customer Service

In a truly stunning service provider fail, I was without Internet access at home for 14 straight days. FOURTEEN DAYS!! But at least my service provider responded promptly on social media.

I won’t tell you who my provider is [virgin media cough], but as someone who works from home, not having Internet is a severe liability. I also happen to work in Internet security, so the vast majority of my day is spent faffing around online. At least my data was safe I guess.

It’s not so much that I was without access for so long, bad things happen, it’s that I STILL don’t know why! To be told every day that it’s a “known fault” and that it will be ‘resolved by 2PM tomorrow” makes an utter mockery of customer service. Not once did they update their site with an outage statement, not once did they call us with updates, and not once did they tell us what the issue was.

For God’s sake, my next door neighbour had Internet access from the same provider! Literally, next door, I’m at 45, they’re at 47.

Enough background, now to my real issue; While their actual customer service left a lot to be desired, their social media department was totally on the ball. And no, that’s not a good thing. About 30 seconds after we Tweeted about the disgraceful service their rep was back to us apologetic and full of concern.

What’s wrong with that you might ask? Well…

  1. They had no access to our account, so they could not even speak to the issue;
  2. They had no access to tech support to find out what was actually wrong;
  3. Once they realised they were making things worse they referred me to their utterly pointless Code of Practice;
  4. They kept no record of their previous contact so every subsequent bad Tweet was followed by the exact same conversation, and;
  5. Zero follow-up, zero accountability.

Bottom line; customer service over social media is nothing more than an attempt to protect their online image. At no point was this ever an attempt to actually help.

Customer Service is both an art and a science, and is one of the few competitive advantages left in the digital world. It should be pro-active, an extension of an organisation’s values, and absolutely cannot be faked. Most people I know would stick with a lesser product / service if they believed their provider actually cared.

I have never understood the visceral resistance to admitting that you’ve messed up. It’s akin to one of my favourite lines in The Dark Knight when the Joker says “You know what I’ve noticed? Nobody panics when things go “according to plan.” Even if the plan is horrifying! If, tomorrow, I tell the press that, like, a gang banger will get shot, or a truckload of soldiers will be blown up, nobody panics, because it’s all “part of the plan.

In this case, all my service provider had to do was tell me the minute they knew there was a problem, which was 4 days before the line went down. Then, if they had just keep me pro-actively informed on progress, I would have only been disappointed, not angry. Of course, it would have been great if they had offered to provide a temporary alternative, like a MiFi for example, but this was not necessary. They would have made a loss on the month, but they would have earned years of my loyalty.

As things are today, I will not only leave my current provider as soon as there is a viable alternative, but I will actively dissuade anyone from using them.

Social media is a critical aspect of customer service, but only if these two things are seen as intrinsic components of the right corporate values. If not, you’re just pandering, and I for one will not be pandered to.

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

PCI SSC: Effective Daily Log Monitoring

PCI SSC: ‘Effective Daily Log Monitoring Supplement’ – They Missed Again

The SSC released their Information Supplement ‘Effective Daily Log Monitoring‘ in MAY, and I’m only just hearing about it now! Either I’m completely out of the loop (not being a QSA) or the SSC did a very poor job PR-ing it.

I think I understand which it is now that I’ve read it.

Anyway, despite the blatant oxymoron in the document’s title, and my own predisposition toward negative bias where the SSC is concerned, I was still hoping to be pleasantly surprised.

I wasn’t, but nor was I as horrified as I have been while reading output from other SIGs.

It’s actually a really good beginner’s guide to logging, but it’s completely unsupported by the DSS in its current form. And it’s not just me looking for faults, they have not put logging into a proper, or even accurate, context to the DSS requirements as written. With their knowledge of best practice, they basically made the rookie mistake of assuming requirements mean more than they do.

To be clear; If it’s not specifically spelled out in the standard, it is not mandatory. Period / full stop. Even if it’s the right thing to do.

For example: There is no requirement for any automated alerting. Not from firewalls, not from A/V, not from IDS, not from FIM, and not from ‘system components’ like servers and applications. So the statement; “The PCI DSS recognizes the importance of proactive monitoring of security logs in the detection of attacks on information assets and the protection of those assets from compromise.” is inaccurate. The SSC might recognise the importance of pro-active monitoring, the SIG’s participants clearly do, but the DSS only recognises the need for what amounts to forensic evidence. Nothing more.

The DSS uses the word ‘alert’ in only 5 relevant Requirements:

  • 6.6  For public-facing web applications, ensure that either one of the following methods is in place as follows:

• Examine the system configuration settings and interview responsible personnel to verify that an automated technical solution that detects and prevents web-based attacks (for example, a web-application firewall) is in place as follows:

– Is configured to either block web-based attacks, or generate an alert that is immediately investigated.” – [Alerts are non-mandatory, and can be manually generated.]

  • 10.5.5  Use file-integrity monitoring or change-detection software on logs to ensure that existing log data cannot be changed without generating alerts (although new data being added should not cause an alert).” – [No time-period defined, so you have to assume weekly like 11.5, or at most daily like 10.6. Alerts can be manualy generated.]
    o
  • 10.6 Review logs and security events for all system components to identify anomalies or suspicious activity.

Note: Log harvesting, parsing, and alerting tools may be used to meet this Requirement.” – [Non-mandatory]

  • 11.1.d  If automated monitoring is utilized (for example, wireless IDS/IPS, NAC, etc.), verify the configuration will generate alerts to notify personnel.” – [Non-mandatory, and/or no time-period defined.]
    o
  • 11.4  Use intrusion-detection systems and/or intrusion-prevention techniques to detect and/or prevent intrusions into the network. Monitor all traffic at the perimeter of the cardholder data environment as well as at critical points in the cardholder data environment, and alert personnel to suspected compromises.” – [Alert how? Automatically or during a daily review?]
    o
  • 11.5  Deploy a change-detection mechanism (for example, file-integrity monitoring tools) to alert personnel to unauthorized modification (including changes, additions and deletions) of critical system files, configuration files, or content files; and configure the software to perform critical file comparisons at least weekly.” – [Weekly notification, so clearly does not require automation.]

So if there’s no requirement for automatically generated alerts, and daily is the maximum defined review timeframe, how can they possibly insist on 24/7 availability related to Incident Response (DSS Req. 12.10.3)? Who is going to choose 2AM for their daily review?

Even the SIG makes the statement; “Without automated alerting mechanisms, it is almost impossible to identify and alert about such events in near real-time.“. In other words, in time to actually do something about it before it gets out of hand.

But I thought this was about effective DAILY log monitoring?

So All In All…

The thing that still confuses me most, is that the DSS is full of mandatory technologies, but a manual and daily review of logs is still OK?! Not one technology in the DSS is required to be utilised properly, and some have significantly less benefit than a Security Incident & Event Management (SIEM) or an equivalent managed service:

  • why require firewalls and routers then don’t mandate review of the traffic logs?
  • why require an asset database, but not an asset management system on which every other security processes can rely?
  • anti-malware is based on signatures so is all but useless
  • intrusion detection is pointless unless the entire infrastructure is baselined to a known-good
  • …and so on.

So of ALL requirements, how can centralised logging and automated alerts not be mandatory?

This post in already too long, and I’ve barely begun to scratch to surface of why logging and monitoring is so important.

There’s no escaping that the document name; ‘Effective Daily Log Monitoring‘ is misleading, it should be called the ‘We Cannot Tell You to Buy a SIEM, But Good Luck Getting Compliant Without One‘. Basically the SSC has all but admitted that the logging and monitoring requirements are completely inadequate, but can think of no way to change them in the DSS. Not without pissing off a lot of people anyway.

Finally, it IS  a good document, worth a read, and kudos to the authors. Unfortunately it’s guidance is meaningless to those without the means to perform anything other than manual daily reviews.

Bonus Material

If you’re interested, I have provided some additional thoughts in my own Logging Supplement document. There are 3 sections:

  1. Breakdown of Existing DSS Logging & Alerting (Non-Server) – There are 5 DSS requirements outside of the established logging and alerting requirements, and are ambiguous at best. They are also not covered appropriately in the SSC’s Supplement.
    o
  2. Missing from the DSS – The SSC’s Supplement did not cover daily review appropriately, nor did then then go far enough to cover appropriate automation. This section covers a few of the major benefits of logging and monitoring properly.
    o
  3. Automating the Daily Review – There are only three processes required to automate the daily review, but it cannot be done without centralised logging and scripting skills, a managed service, or a SIEM.

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

Visa Europe's New Fine Structure

Visa Europe’s New Fine Structure – Can YOU Afford €500K?

[Disclaimer: The following is based on information received from a single acquirer, and I have been unable to corroborate any of this from other sources.]

Have you seen Visa Europe’s new fine structure for cardholder data breaches? Can you afford THAT kind of loss? More importantly; Are you really PCI compliant, or did you just fake your way through a Self Assessment Questionnaire (SAQ)?

In case you weren’t aware, the fines for a breach are levied against the results of the mandatory forensics investigation, not just your self-assessment status. Anyone caught lying on a self-assessment attracts the maximum fines, and rightfully so.

OK, full disclosure on the title, I did go straight into a worst case scenario, but would you read about PCI otherwise? If you’re like 99% of the people I’ve ever had as PCI clients, you care nothing about PCI compliance per se.  Other than wanting it to just go away of course. Historically, even threats of fines have done little to motivate organisation to take PCI seriously.

Until now perhaps.

But first, believe it or not,  some good news!; “Assessments levied for non-progressions and portfolio targets have been withdrawn.” – in other words, there will no longer be Visa Europe-defined fines for non-compliance. This is not to say your ACQUIRER can’t fine you, but Visa has only ramped-up the fines in the back-end.

In this case, the ‘back-end’ means you’ve been breached, and there is now a whole host of things you have have to take into account to work out your potential losses:

  1. The loss of 1 PAN & CVV attracts a fine of €18.
  2. There is a €3,000 ‘Account Data Compromise (ADC) Management Fee’ imposed on all breaches.
  3. For penalties over €100,000, the fines can be capped at “5% of the merchant’s Visa gross annual purchase volume in 12 months prior to the initial notification.” I assume this is entirely discretionary and weighed against the egregiousness of the non-compliance.
  4. Did the acquirer correctly report the merchant’s compliance status? – Even is the status is non-compliant, there is a 25% reduction in fines for correct reporting.
  5. Are the ‘majority’ of the merchant’s transactions authentication with Verified-by-Visa (VbV) – 50% reduction in fines if yes.

ADC Scenarios:

  1.  Non-compliant Level 4 Merchant puts 1,000 PAN and CVV2 numbers at risk – Acquirer correctly reported compliance status, and VbV is in place;
    o

    PAN & CVV 1000 x €18: € 18,000.00
    Compliance Reductions @ 25%: -€ 4,500.00
    Sub Total:  € 13,500.00 
    VbV Reduction: -€ 6,750.00
    Sub Total:  € 6,750.00 
    ADC Management: € 3,000.00
    Cap Applied: N/A
    Grand Total:  € 9,750.00 

    o

  2. ‘Compliant’ Level 3 Merchant puts 5,000 PAN and CVV2 numbers at risk – Acquirer incorrectly reported compliance status, and VbV is not in place;
    o

    PAN & CVV 5,000 x €18: € 90,000.00
    Compliance Reductions @ 25%: € 0.00
    Sub Total:  € 90,000.00 
    VbV Reduction: € 0.00
    Sub Total:  € 90,000.00 
    ADC Management: € 3,000.00
    Cap Applied: € 25,000.00
    Grand Total:  € 28,000.00 

    o

  3. Non-compliant Level 2 Merchant puts 75,000 PAN and CVV2 numbers at risk – Acquirer correctly reported compliance status, and VbV is in place. No penalty cap applied;
    o

    PAN & CVV 75,000 x €18: € 1,350,000.00
    Compliance Reductions @ 25%: -€ 337,500.00
    Sub Total:  € 1,012,500.00 
    VbV Reduction: -€ 506,250.00
    Sub Total:  € 506,250.00
    ADC Management: € 3,000.00
    Cap Applied: N/A
    Grand Total:  € 509,250.00

Conclusion:

Will Visa Europe’s new fine structure get merchants moving towards compliance? I seriously doubt it. Frankly nothing will get them moving unless the CEO / BoD see these fines as a legitimate business risk instead of a worst case scenario. And what are the chances of that when the cost of properly securing cardholder negatively impacts the quarterly numbers?

Fining for non-compliance was stupid anyway. It basically forced merchants to just lie on their SAQs and do nothing to actually reduce the risk. Huge fines for a breach is arguably a more appropriate way of punishing those who egregiously ignored the standard. But it’s still after the fact.

But what if the card schemes actually provided INCENTIVE for achieving [and appropriately demonstrating] compliance? Reduced interchange rates perhaps? Financial incentive to adopt their increasingly desperate ‘innovations’ maybe? Wouldn’t THAT be something.

Screen Shot 2016-07-29 at 13.59.29

PCI DSS v3.2 vs CIS Critical Security Controls v6.0

A few months ago, while incredibly bored, I decided to perform my own mapping of the PCI DSS v3.2 to ISO 27001:2013.

I know what you’re going to say; “You can’t compare the two, one’s a management framework, the other’s a controls-based assessment standard!” I agree with you, however, it IS possible to map PCI’s Control Requirements to the ISO’s Control Objectives.

The DSS did not fare well; PCI DSS v3.2 vs ISO 27001-2013

This is not surprising really, the PCI DSS was never designed to be a security framework. It was designed to reduce the risk of card holder data loss to acceptable levels, and nothing more. Whether or not it has succeeded is a debate for the ages, and any frequent readers of my blog will know where I stand.

This week I found myself bored yet again, so I decided to give the DSS another shot at matching up to an ‘industry-accepted’ standard. This time I chose the CIS Critical Security Controls (CSC) v6.0 which, by definition, should have given the DSS a shot at redeeming itself.

It didn’t; PCI DSS_v3.2 vs CIS Critical Security Controls_v6.0

In the DSS’s defence, this is not a fair apples-to-apples comparison either, for 2 main reasons:

  1. The DSS is not a 100% controls-based standard, the CIS CSC is. The DSS, quite rightly, includes a significant chunk of policy and procedure, only a reverse mapping would give the full picture.
    o
  2. The CIS CSC includes a significant number of technologies ill-suited for all but the most advanced and mature environments. Not to mention those with unlimited budgets. The PCI DSS was written to be understood by as many people, and be as universally affordable, as possible.

That said, we can certainly make some observations that illuminate some of the PCI DSS’s more significant deficiencies:

  1.  Data Protection (CSC 13): 18% coverage – Rather ironic, but the entire raison d’être for the DSS; protection of card holder data, scores the lowest in terms of controls requirements. While CSC 13 does not include as much encryption as the DSS, the lack of Data Loss Prevention (DLP) techniques in the DSS is starkly transparent. The DSS has never even mentioned DLP in the main body, or even alluded to it in the “Scope of PCI DSS Requirements“. Only the Designated Entities Supplemental Validation (DESV) section mentions it, and that only in the Guidance as an option.

  2. Inventory of Authorized and Unauthorized Devices CSC 1 & Software (CSC 2)20% coverage – Asset Management is at the heart of every security program, nothing else can possibly function without it. The requirement for an asset register was not added to the DSS until v3.0. Along with Logging & Monitoring, the PCI minimums related to asset management are the most damaging to the overall program. Automation and alerting are both next to impossible without the baselines the asset register should provide.

  3. Malware Defences (CSC 8): 27% coverage – The DSS focuses almost entirely on anti-malware, and that almost exclusively on Windows. That’s what they mean by “…commonly affected by malicious software” in Requirement 5.1. Base-lining, white-listing, black-listing and so on aren’t featured in the DSS, because with asset management there is no way to track what should and should not be there.

  4. Security Skills Assessment and Appropriate Training to Fill Gaps (CSC 17): 28% coverage – This one is truly unconscionable given the enormous power of education and training. Security Awareness means nothing unless it’s in appropriate context to the individual taking it. One size does not fit all, and PCI would be wise to take note.

Clearly I have a significant bias against the PCI DSS in general, so I would welcome any counter-argument from others who are equally bored.

Now I have to go find something else to do..