Category: Core Concepts

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/

 

 

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

…is the appearance of innovation.

Well, it certainly seems that way; Can’t sell services over the Internet? Call them The Cloud. Can’t sell Risk Assessments and Vulnerability Management? Call it Operational Resilience. Can’t sell data management and access control on mobile? Call it BYOD.

When it becomes clear that there is no-where left to go with your existing product or service, the appearance of innovation seems to be the go-to place for institutions staring down the barrel of obsolescence. Instead of working on their customer service, value-adds, or – God forbid – actually improving their offerings, too many organisations resort to smoke and mirrors to stay competitive.

And the worst part? We let them.

The payments sector is perfect target for this blog, especially given the fact that I know little else. Take these two examples from the last few month; There’s a New Way to Pay With a Selfie, and TD, MasterCard and Nymi Pilot Heartbeat-Authenticated Contactless Payments.

Where is the innovation here, we’ve had biometrics for years? The only thing new is the ability to actually bring the biometrics to bear, which is an advance in mobile technology, not payments. The payment itself  hasn’t changed, we’re still stuck with the same primary account number (PAN) being used by the same intermediaries (Acquirer, Issuer & Card Scheme), over the same systems we’ve had for decades. Even if you build in tokenisation with these systems they’re still mapped to a PAN in the back-end somewhere.

If you accept that a payment is just a transfer of value from one place to another, true innovation must involve the complete disintermediation of almost every player in the current ecosystem except the banks. Sure, there can be service provider intermediaries, but they will be providing true benefits to consumers and banks alike in the fields of identity management / authentication, anti-fraud, customer service, loyalty and reward programs, ratings and reviews, big data analytics and host of others services of which I can barely conceive.

To be worthy of the term ‘innovative’, any service or product offering must have the following attributes:

  1. Be of practical use, and not just theoretical
  2. Provide long-lasting benefit to all stakeholders
  3. Cannot knowingly stifle or exclude competition

For payments, there are a few more:

  1. Be available to the largest portion of the population possible (including those with disabilities)
  2. Be frictionless to the average consumer, or better yet, invisible
  3. Maintain appropriate confidentiality, integrity and availability of all underlying sensitive data, to meet – or exceed – all current legislation, regulation and best practices

Not one, or even ALL of these things at once should be too much to ask, but it’s never that simple. There will always be those existing players whose power and position can make some of these requirements all but impossible for newcomers. And the newcomers themselves rarely do themselves any favours; disruptive innovation, competitive advantage, and blatant greed all prevent true innovation from reaching the mainstream.

In payments, like most industry sectors, collaboration is the key to significant and beneficial change, and in a market worth tens of TRILLIONS of £/€/$, I would have thought there was enough to go around.

 

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