Category: Security Good Practices

If you really want to piss off the PCI Security Standards Council (PCI SSC), show them how you are writing your Reports on Compliance (RoCs) automatically. You’ll find yourself in remediation very quickly.

But why? What possible difference could it make that you say things the same way from report to report as long as the validation of the controls was performed correctly?

For example, let’s take Requirement 2.2.b; “Examine policies and interview personnel to verify that system configuration standards are updated as new vulnerability issues are identified, as defined in Requirement 6.1.”

In order to validate that this in place you must perform the following three processes;

  1. Identify the policy documentation verified to define that system configuration standards are updated as new vulnerability issues are identified;
  2. Identify the personnel interviewed for this testing procedure, and;
  3. For the interview, summarize the relevant details discussed that verify that the process is implemented.

So, for 1.,  if you have mapped all relevant documentation to the PCI requirements (which you should) in your RoC Writing Tool (RWT), this will simply be an automated regurgitation of the document names, and hopefully section numbers. If not, you have the relevant documents already summarised in Section 4.10.

For 2., you should already have your personnel mapped against system grouping in your asset register, so again, this is just a regurgitation. If not, you have the relevant group(s) already summarised in Section 4.11.

For 3., this is where the SSC is looking for a true narrative, but all validation relevant to 2.2.b is performed in the same way for each system type, so as long as the QSA and their client are actually doing their jobs properly, the contents of this narrative will be basically the same;

For [asset group]:

“QSA interviewed [personnel], examined [documents], and obtained [validation evidence] for [client] [name of vulnerability management process] and [name of configuration standard process], as well as examined production configurations for [sample(s)].“

…and so on for each distinct and relevant asset grouping.

A huge advantage of this is that for any asset type you add, the list of related DSS Requirements, and the related validation evidence all become pre-defined and mandatory action items, assigned to an individual. Assuming you have also defined a compliance goal, you will also have due dates. Even further, with a correctly defined hierarchy you also have the beginning of true project management.

Imagine that, with asset management done well, you have an up-front list of EVERYTHING required to achieve compliance, along will full accountability for the collection of the necessary validation evidence. As the target organisation collects and uploads the evidence, the RoC is writing itself in the background, thereby giving full insight into the gaps and level of effort indicators required to either adjust resources, or justify technology or outsourcing investments.

Now imagine how simple APIs could accept information from end-point technologies like A/V for FIM, or from centralised management stations for logging or IDS, or how a simple agent could report against running services / listening ports / registry settings for an operating system, and you are starting to perform the validation itself automatically. Not against PCI requirements, but against your full gamut of corporate policies and standards, all of which are mapped against you asset type. And not annually, but all day, every day.

Forget PCI compliance, this is the type of Continuous Compliance Validation everyone needs, regardless of the data type, compliance regime, or industry sector.

Difficult? Yes. Simple? Always.

I’m sure that in an earlier blog I stated that I would never use this medium to promote a vendor or specific product. I cannot find that quote so it clearly didn’t happen, and seeing as this promo is for something that’s actually not-for-profit, I don’t feel like a complete sell-out.

An analogy is defined as; “a comparison between one thing and another, typically for the purpose of explanation or clarification.” and as such is an incredibly powerful tool to provide a necessary context to understand something for which we have limited knowledge or experience. For example, the immortal (well, except for his death and all that) Douglas Adams used what to me was the funniest analogy of all time;

“The ships hung in the sky in much the same way that bricks don’t.”

I have used analogies through my blogs and my career, and frankly, any ‘security expert’ who DOESN’T use them is likely a poor consultant, or just starting out. Too many of us are horribly guilty of the Curse of Knowledge, and end up blaming our clients for what, in the end, can only be our deficiencies.

In a conversation with Bruce Hallas, the founder and passionate driving force behind The Analogies Project, it was not surprising that two famous quotes from Einstein were used to perfectly summarise the issues faced by those giving, and those trying to receive, InfoSec services:

  1. “Insanity: doing the same thing over and over again and expecting different results.”, and;
  2. “If you can’t explain it simply, you don’t understand it well enough.”

And on further reflection, there’s this one that I have always loved by Alan Greenspan; “I know you think you understand what you thought I said, but I’m not sure you realize that what you heard is not what I meant.”

Any guidance we provide to our clients on information security is only as good as what is understood and retained. Imparted knowledge is meaningless without the listener’s understanding of it (knowledge = seeds, understanding = ploughed field, ooooh an analogy!!).  I have long maintained that the ultimate consultant is one who teaches, and there are no great teachers who do not take their audience’s individuality into account. You don’t explain where babies come from the same way to your 5 year old child as you would your teenager would you?

Yes, your client must WANT to learn in the first place, and the constant fight against the lack of security culture is not something we can fix by ourselves, but I firmly believe that a change in culture can only come with a true understanding of the benefits, and that will never be a one-size-fits-all, even within the same organisation.

This is where The Analogies Project could truly shine. Having an analogy for a risk assessment is one thing, but having a series of analogies for Receptionists, the C-level, and everyone one in between, broken down by personal interest or sector applicability and so on, will provide usable experience to everyone. Giver and receiver.

I am signing on as a contributor and will be mentioning The Analogies Project in all of my subsequent training or InfoSec presentations (ISC2, ISACA, ISSA etc.), I urge you to do the same;

Go here to begin; https://theanalogiesproject.org/contact-us/

 

 

Answer: When it’s an ISO Standard.

But before you get outraged, I believe the problem lies not with ISO, it’s that we don’t really know what a standard actually IS!:

  • Ask one person and they’ll say a standard is something that all ‘like things’ must be. i.e. they all must be the SAME.
  • Ask someone else and they’ll say that a standard is something you must reach   i.e. it’s a minimum bar.
  • Ask yet another person and they’ll say that a standard is an average of all things.

Even the OED backs this up!:

  • Something used as a measure, norm, or model in comparative evaluations;
  • A level of quality or attainment;
  • Something used or accepted as normal or average; and
  • A military or ceremonial flag carried on a pole or hoisted on a rope

OK, forget the last one, but you get the point, which is that the English language itself allows for multiple, often conflicting, interpretations of the SAME word! e.g. does the word ‘minute’ mean 60 seconds, or something very small? Right, this cannot be answered without context, but how about in this sentence; “The mouse was so minute that it fit into the tiniest of gaps.”?

So clearly the implementation of an ISO standard in any organisation depends entirely on the context to which they have chosen to adopt it, or are being forced to abide by it. An organisation looking for a marketing or competitive edge will adopt ISO as a quality attainment for example, and another will choose to use it for comparative purposes in their due diligence processes. Each will focus more heavily on different aspects of the ISO framework, and both can still meet the intent.

For things like information security this is no big deal, which I assume is why ISO 27001 uses the word ‘appropriate’ EIGHTEEN times! “…appropriate security…”, “…appropriate documentation…”, “…appropriate levels…” and so on. An organisation SHOULD choose which aspects of the standard are appropriate, and then go as deep into the framework controls as they deem …well, appropriate.

But what happens when the ISO standard (which is interchangeable with ‘framework’ in my opinion) is something like ‘Financial Transaction Card Originated Messages — Interchange Message Specifications’ (ISO 8583), or ‘Universal Financial Industry Message Scheme’ (ISO 20022) where you would think that everyone should not only interpret, but implement them in EXACTLY the same way to ensure global interoperability. Surely these things are not like an API bridge where you do whatever you want in the back end, surely they are more like a big puzzle where every single piece must meet SPECIFIC criteria to build the big picture?

Sure the message syntax might be defined, but the USE of fields and what actually goes IN the fields is optional. Why do you think the Card Brands, Issuers and Acquirers are going to have such a hard time implementing EMV tokenisation for example?

The mobile phone has changed everything; the way we communicate, the way we shop, and it won’t be long before it changes the way we think. If we are to embrace the enormous potential yet to come, globally, we must agree on a better definition of ‘standard’, or we might as well not bother. Information out of context has been the cause of innumerable wars, terror crimes, religious and lifestyle persecutions, and the continuation of nationalist behaviour to the detriment of the species.

Maybe we should standardise the word ‘standard’ …oh, wait?

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

Just about everyone who writes on information security has had ample blodder from the numerous high profile breaches, myself included. Some blame the PCI standards or the card brands themselves, some blame the retailers for not doing enough, and those that are a little more charitable, just blame the thieves.

In the end, it’s not about blame, it’s about learning the lesson, making the necessary adjustments, and moving on responsibly. Unfortunately, this will NOT include being able to move on from credit cards or from the PCI DSS v3.1 any time soon, so organisations wanting to avoid becoming the next Target (excuse the pun), had better pay more attention to their enterprise-wide security program, not just their annual compliance ‘projects’.

Just as importantly, they need to pay VERY close attention to innovation in the payment / authentication space, and advances in more real-time security measures / technologies.

Nothing in the PCI DSS is anything other than a bare minimum, and represents enough security for the card brands to say they are doing what they can. But any organisation who thinks this is enough will eventually lose data, and I for one have no sympathy.

You can look at every single requirement and come up with two choices: 1) Good enough for PCI, and 2) Appropriate for the business. 9 times out of 10, the second option is more difficult to implement, but in almost every instance, it is both easier to maintain, and more secure.

For example;

PCI DSS Requirements 1.X are all about networking, firewalls, segmentation and the like, and while it does stress that every service/protocol/port must have a business justification, it does not state specifically that every individual in-scope device must have least-privilege inbound and outbound rules applied.

  1. 1.1.6.a – Verify that firewall and router configuration standards include a documented list of all services, protocols and ports, including business justification for each
  2. 1.2.1.a – Examine firewall and router configuration standards to verify that they identify inbound and outbound traffic necessary for the cardholder data environment.
  3. 1.2.1.b – Examine firewall and router configurations to verify that inbound and outbound traffic is limited to that which is necessary for the cardholder data environment.

Yes, we can imply it means each device (especially 1.2.1.b), and yes, it’s the right thing to do, but no QSA can enforce anything that is not specifically written within the standard. If they had just replaced “the cardholder data environment” with “each in-scope system” DSS Section 1 would be VERY different, and instil a significantly better security posture.

However, if they DID change it to least privilege for every device, is it actually possible to implement and maintain it? Same goes for more robust configuration standards (DSS Section 2), or real-time logging (DSS Section 10), what should be done is very different from what the DSS requires.

In answer to the question, yes, it is possible, and it all boils down to one thing; baselines

Security is not about crunching big data to determine patterns, that’s only truly relevant in forensics when it’s already too late. Real security is knowing exactly what something SHOULD look like performing normally, and reporting everything outside of that. Keep it simple, or it cannot be monitored, maintained, or measured, but the PCI DSS can never go this far.

Hypothetically, if you knew every running service, listening port, and permitted connections each in-scope device should maintain to perform its function, then anything NOT those things should be investigated. That’s a baseline. Security would dictate that you have alerts based on these anomalies for all systems, not a sample of them and certainly not once a year (point-in-time).

How difficult would it be to automate this process so that EVERY system (not just PCI ones) reports back on a daily/weekly/monthly – or ANY period of time less than a year! – basis to a centralised management console to perform the baseline comparisons? Then what’s to stop you comparing the device’s listening ports to firewall rule sets to make sure they are properly defined? Or comparing them against enterprise policies and standards, or known business data flows?

Not one organisation or security vendor is doing this properly, at least not that I have seen, or not yet. Some vendors do bits of this, but the last thing you want to do is patch together a bunch of separate, non-integrated systems, as the effort to do so will usually outweigh the risk mitigation, or the cost-to-benefit ratio.

However, none of this can happen until you have centralised and accurate asset management, and seeing as the PCI DSS just added that as a requirement in v3.0, most organisations have a long way to go before they can ever achieve this ultimate in security; continuous compliance validation.

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

Ask 100 security ‘professionals’ what vulnerability management is and at least half of them will begin with patching, another 25% will focus on vulnerability scanning and penetration testing, and the majority of the rest will start quoting the gamut of Risk Assessment to Business Continuity. I’m not saying they are wrong, but most will not be right enough.

If you accept this description as standard; “Vulnerability Management is the cyclical practice of identifying, classifying, remediating, and mitigating vulnerabilities, especially in software and firmware. Vulnerability Management is integral to computer security and network security.“, it’s no wonder that actually performing appropriate vulnerability management is a concept rife with misinterpretation and bad decisions.

The old adage; “You can’t manage what you can’t measure.”, while often incorrectly interpreted from the original work of W. Edwards Deming, is actually completely relevant in information security. Security is series of baselines / whitelists /  known-goods, and is only ever effective if it’s simple and repeatable. In other words, if you don’t have a point to measure security from, how can you possibly know if it’s enough, or too much?

Like every process in security, vulnerability management  is only as good as the context in which you place it, and ANY security process out of context from the underlying business goals is doomed to failure. Rightfully so. The vulnerability management controls you put in place relevant to your environment therefore go through the exact same process as every other control, from firewalls to outsourcing.

Step 1: Determine your business goals – in order to conduct an appropriate Risk Assessment (RA) and Business Impact Analysis (BIA)

Step 2: Conduct a gap analysis – to determine the shortfalls or over-extensions between current security capability and desired capability

Step 3: Fill the gaps – to the capability level determined by the BIA (accept residual risk)

Step 4: Determine appropriate baselines – for the management, maintenance and monitoring of the ‘new’ infrastructure/processes

Step 5: Place appropriate ISMS-esque controls – around the ongoing management, maintenance and monitoring of the new infrastructure/processes

Step 6: Develop appropriate mechanism for the decision making process – from responsibility / function, to scoring / rating, to mitigation, everything must be in-line with Step 1 in order to be effective and sustainable

Step 7: Determine all control inputs to the process – including – and certainly not limited to – patching, vulnerability scanning, penetration testing, code review (if applicable), logging, FIM, and so on…

Step 8: Determine all appropriate internal and external sources of threat intelligence  – from relevant vendors to paid-for services.

Step 9: Bring everything together into a Management capability – one with a specific charter and report structure.

Step 10: Re-examine every step for continued relevant and effectiveness – on a regular basis

If this sounds complicated, it’s likely that you don’t understand one or several of the steps. All aspects of security are simple, they have to be, and while is can be difficult to implement, that’s almost always because you are not asking the right questions. In any endeavour outside of your business’s core competencies, the trick is not to ask for what you think you need, it’s to ask for help from someone who KNOWS what you need.

You don’t tell your doctor you have a brain tumour, you tell them you have a headache a leave the diagnosis up to the expert.

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