Category: Security Good Practices

The temptation to spend money to make something annoying just go away is almost irresistible. I’m not just talking about security now, this is a human condition. From get-rich-quick schemes, to diet pills, to online ‘dating’, we want instant gratification and / or results. Sadly we also expect the underlying cause of our issues to be miraculously fixed as part of the fee.

What do you mean “Get your fat arse off the couch and go for a walk!”, I paid you to make me thin!? There are no shortcuts to fitness, and there are no shortcuts in security.

None.

But with phrases like; ‘panacea’, ‘silver bullet’ and my personal favourite; ‘guaranteed hack-proof’, the cybersecurity industry is becoming one of the worst offenders. Money is clearly more important than good service to many security vendors, and to those expounding on their virtues.

And we’re letting them get away with it! Whether it’s because we’re lazy, don’t know the right questions to ask, or just don’t care, it’s immaterial. Vendors will keep making useless products and we’ll keep buying them if things don’t change. Vendors have sold F.U.D. for years and we’re bringing only a few of them to task (FireEye for example).

The more complicated vendors can make security appear, the easier it is to sell their technology. At least that’s how it seems. There’s really no escaping that security must be simple to be effective; forget big data, use baselines; forget microsegmentation, just segment properly, forget user and entity behavioural analytics, fix your access control. In fact, ignore every acronym in the Gartner ‘Top 10 Technologies for Information Security in 2016‘ and focus on the basics, I’ll almost guarantee they aren’t addressed appropriately.

From policies and procedures, to change control, to vulnerability management, to incident response, worry about the base processes. They are not only more effective than any new technology, they are a damned sight more sustainable, more scalable, and cheaper!

One of the universal truths in security is that you cannot fix a broken process with technology, you can only make a good process even better. Better in terms of accuracy, speed, effectiveness, efficiency, long-term cost, you name it, the underlying process had to have worked beforehand.

Take incident response (IR) for example. If you have top-notch plans, a well trained team, and robust vulnerability management, a technology that gives you earlier event warnings is of distinct value. As would technologies that; reduces false-positives; automatically quarantine infected machines; supplies greater forensic information up-front, and so on.

However, if your IR plans are crap, your team has no idea what to do, and your systems have not kept up with the threat landscape, no technology in the world will stop an event from becoming a business crippling disaster.

Be honest,  how many of you have:

  1. Firewalls but poor segmentation?
  2. Routers but no mapping of your business processes?
  3. Anti-Virus and no OS hardening?
  4. HSMs and no idea where all your data is?
  5. Centralised logging with no idea what ‘normal’ looks like?
  6. …and the list goes on.

How can you expect a new technology to help when you’ve haven’t optimised what you already have?

There are of course exceptions to every rule, and in this case the exception is to buy an Asset Management System. Everything else you do in security has your assets at the core. Do this well and everything else becomes much easier.

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

[For a little more information on technology purchases, this may help; Security Core Concept 2: Security Control Choice & Implementation]

Type “virtual CISO” into Google and you’ll get ~1,200,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 Lead’. 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 (if they have the interest/skill-set). 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

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 6 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!]

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..

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!