Cybersecurity Collage

Without 3rd Party Security ‘Vendor Brokers’, AWS and Azure May Not Be For You

…at least for PCI anyway. It’s just too damned difficult to get all the security wrappers PCI requires without Vendor Brokers.

Cybersecurity has now be made too complex – by security vendors – to be able to mix-and-match with individual vendors from the AWS/Azure marketplaces. I don’t know of any single vendor who can cover even a majority of the PCI requirements related to platforms.

i.e.

  1. Firewall Management;
  2. Configuration Standard(s);
  3. Anti-Virus;
  4. Vulnerability Management;
  5. Patching;
  6. Access Control;
  7. Authentication Mechanism(s);
  8. Logging & Monitoring;
  9. Web Application Firewall; and
  10. File Integrity Monitoring

There are many reasons for this, one of which is that ever since security became a multi-billion £/$/€ a year industry, hundreds of companies have started up to try bring us the ‘silver bullet’ appliances.  Not only do silver bullets not exist in cybersecurity – and you should be shot for using the phrase in any way that’s non-derogatory – but where are the overwhelming majority of those companies now?

They either failed, or have been ‘collected’ by larger companies who have tried to duct-tape the disparate products into silver-bullet solutions.

Which have also failed.

It’s not that the original products didn’t work, some of them actually did, it’s that;

  1. Organisations threw technology at business problems without knowing why they were doing it;
  2. The big companies that collected the smaller ones tried to integrate the individual products together under one GUI, instead of unifying the functionality under a single code base; and
  3. There has never been, and there never will be, a one-size-fits-all solution to security.

But the market is still ripe for innovation, and there will continue to be companies starting up with the goal of bringing a single product to market that will catch the latest security hype/wave/buzz and make them their fortunes (UEBA for example).  They may even succeed, but only if they make their impact in the first year or two, otherwise the market will have moved on.

And if they’re VERY lucky, the larger companies will be naive / ignorant enough to buy them and save them the trouble.

Don’t get me wrong, I am not against combining single products into a larger solutions. In fact it’s the only way to go, but only if it’s done correctly.  Single product companies have 100% focus, which gives them drive, short-term goals, and a dedication to making their one product the best. The second you absorb that company however, every one of those attributes that put them on (or near) the top, are lost in the larger mix.  The functionality is diluted, innovation ceases, and the the whole thing quickly becomes obsolete.

True integration of functionality can only be accomplished with a single code base, and a single platform, which means that any organisation that absorbed the smaller companies better have a plan in mind to migrate not only the applications over to their growing solution, but they will need to consider all of the clients who bought the product prior to the M&A.  These guys often suffer from a total lack of customer service and support, and there’s no way they’ll buy into the larger program.

In my experience, the due diligence necessary to combine product companies is not overly abundant, and until it is, we should all be VERY careful when we look to resolve our security issues with multi-function solutions.

I call these Vendor Brokers ‘collage companies’, as the picture might be pretty, but it’s in no way whole.

Here are a few questions you might want to ask your potential providers;

  1. Can your solution replace some / most of my current functionality?
  2. Do you provide a consultancy ‘wrapper’ around these solutions to help us manage them against our business goals?
  3. Will the output from your solution feed into my current collection mechanism, or can my current output feed into yours?
  4. Are the various aspects / functions of your solution ‘home grown’, or obtained through acquisition?  If acquisition, how have you unified the back end code and platforms?
  5. How do you ensure that the different functions of the solution receive a similar attention to what the single product vendors provide?
  6. Do you have a single customer support process to handle all functionality questions?

Regardless of the shenanigans going on in the security product market, your choice of Vendor Broker should only be driven by what your risk assessment and gap analysis said you need, and your due diligence should cover any requirements you may have regarding integration and ongoing maintenance.

If is doesn’t, don’t expect Vendor Brokers to help, they have enough problems keeping their own houses in order. 

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

PCI L1 Service Provider

From FinTech Concept to PCI Compliant in 6 Months?

Anyone wanting to start a new business in FinTech/payments – digital wallets for example – has to address PCI. Like it not, payment cards are still the dominant form of non-cash payment on the planet. By far.

So what if you have a great idea in this amazing world of opportunity, but your skill-set is in payments and innovation, and not IT or cybersecurity. How do you get your service to market, AND play by the rules? Can you do this in time to be ahead of game given the incredibly short timeframe of today’s competitive advantage?

Well, you could just self assess, but you are restricting yourself to a maximum of 300,000 transaction annually.  But more importantly, would you trust your money to a service provider who self assesses? No, neither would I.

However, I’m talking about full Level 1 Service Provider compliance through a reputable QSA (yes, there are some out there). How can you set up the infrastructure, get all the documentation in place, AND get all the way through a PCI DSS Level 1 assessment in 6 months? And if you do, have you really done it properly?

The answer is yes, you can, but there are MANY caveats, and if you deviate from these steps you will not get there. I am only interested in helping organisations get compliant properly, I have no interest in adding more crap service providers to the ecosystem.

First, you have to completely ignore the PCI DSS. Any plans you make to design both your physical infrastructure and your security program from scratch must be with real security in mind. Never compliance alone. For that, many organisations turn to the ISO 27001 standard. There are others, but try finding affordable consultants who can help you implement them. As long as you realise they are all just frameworks, not step-by-step instructions, then you’re ready to start asking questions.

So What Are the Steps to Compliance?

o

  1. Get Help – This should be no surprise. I don’t perform emergency appendectomies, I’m not remotely qualified, why would you try to achieve compliance when that’s not your experience or skill-set. Yes, is can be expensive, but nowhere near as expensive as any of the alternatives. There are some very good consultants out there, do your homework and find the best one for you.
    o
  2. Outsource the Infrastructure – Unless you’re an expert in everything from hardened operating systems, to logging and monitoring, to firewall management, you will want to outsource as much of the platform as you possibly can. Unfortunately, finding a single provider who can take on anything more than physical hosting and some networking stuff is still ridiculously difficult. Amazon Web Services (AWS) for example is about as bad as you can get. Unless of course you want a dozen or so independent service providers to manage along with Amazon.
    You MUST ask the right questions, and this is where your  consultant comes into play. S/he will write your RFP, interview providers, and eventually produce a responsibility mapping of services against the PCI DSS. This will match their Attestation of Compliance, as YOU should only do business with L1 PCI compliant service providers.
    o
    You are welcome to use my mapping if you don’t have one: PCI DSS v3.2 SP Responsibility Mapping
    o
  3. Policies, Standards & Procedures – You have to start somewhere, so you will likely want to buy a Policy Set. Once again, you have to be very careful as there are dozens of options but few will be fit for purpose. In this case, ‘fit for purpose’ means the service must 1) get you through compliance, 2) provide a platform for your unique culture, and 3) be self-sustainable for the long-term.
    If you buy a Policy Set with ‘PCI’ in the title, you have already failed. Buy one that your consultant can customise on your behalf, and then teach you to manage yourself. Get one that; 1) Is already mapped to both the PCI DSS and your chosen framework (usually ISO 27001), 2) has document management built in (numbering, content standards, assigned coordination etc.), and 3) is easily distributed to the subject matter experts best placed to maintain them.
    o
    I have written a quasi-white paper on how to choose the right the right service, you use the questions as an RFP: ‘Selecting the Right Policy Set
    o
  4. Hire a Completely Independent QSA – While it may be very tempting to have your consultant take care of all the ‘PCI stuff’, bite the bullet and keep these separate. No, you don’t have to be an expert in this stuff, but if you are relying completely on your consultant you are building in a single source of failure. By all means have your consultant run with the assessment, but be involved. If you don’t, you’ll have no idea what you paid for in the first place. In fact, you may even want to build in some SLAs regarding how much remediation is required from by QSA. There will always be some, but if it involves significant scope creep or capital cost, your consultant has failed you. Remember, you have outsourced almost the entire function of PCI to your platform provider, validation of compliance should be a formality.

Of course this is oversimplified, but I’m already way over my self-imposed word limit. However, while I haven’t included any of the inevitable challenges, the process is a simple as security itself, it’s up to you to find someone who can make it simple.

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

Deception Technologies

Deception Technology: Only if You’re TRYING to Get Fired!

One of Sun Tzu most quoted phrases in The Art of War states; All warfare is based on deception.

Sun Tzu was not in cybersecurity.

99% of the defence against hackers has nothing to do with deception. It’s about making things too difficult to be worth attacking in the first place. Very few of you reading this are ever going to be the specific target of a state-sponsored agent, or an organised crime ring. Threats to you will therefore be mostly opportunistic in nature. Bad guys are lazy, make things difficult and they will usually move on pretty quickly.

On the other hand, expose something to an opportunistic hacker that looks easy to break, and you will have his/her attention. You would not have had their attention otherwise. To make it worse, when they find out that they have been deceived, you have done the worst thing imaginable. You’ve pissed them off.

Now it’s personal, and for a hacker, this means they will be patient. Very patient.

This is bad.

So What is Deception Technology?o

According to TechTarget a deception technology is a; “category of security tools and techniques that is designed to prevent an attacker who has already entered the network from doing damage. The technology uses decoys to misdirect the attacker and delay or prevent him from going deeper into the network and reaching his intended target.

You’ve already failed to detect the intruder through your other security controls / technology, so you should buy another tool to slow them down?

Even the very far from perfect PCI DSS has enough security controls defined to make breaches difficult enough. From hardening standards, to encryption, to access control, to FIM, to penetration testing, very few organisations need more. The issue is not the number or even type of controls in place, it’s the complete inadequacy of their implementations.

Why Deception Technology is a Horrible Idea

As far as I’m concerned, it should be possible to assume any organisation that implements deception technologies has or is:

  1. …completely optimised their security program – because why would you try to deceive before you’ve done your best to prevent, or detect with existing controls?;
  2. …the in-house expertise to perform the function – because who in their right mind would buy Deception-as-a-Service?;
  3. …ridiculous amounts of money to spend on cybersecurity toys – because even open source tools have a corresponding resource cost;
  4. …happy to draw the attention of the bad guys – because hackers hate a challenge, right?; and
  5. …a security chief who wants to be fired – because why else would they waste their time and the company’s money on something so pointless?

If you accept that you shouldn’t buy technology until your risk assessment process highlights a relevant functional gap, then consider this; In 15 years of performing security assessments at organisations both large and small, I have NEVER seen the need for deception technology. Never. Governance, yes. Policies and Procedures, absolutely. Incident Response, without doubt. Deception Technology, not even on the radar.

You Won’t Get Fired for Doing the Basics

Finally, every blog I have ever written harps on about the exact same thing; back to basics. If you were doing the established cybersecurity processes correctly, deception technologies would not be necessary. Every aspect of your security program must focus on baselining your environment to a known-good, and reporting exceptions. Nothing more.

But risk assessments, vulnerability management, change control, asset management etc are just not sexy enough to sell. If it’s not shiny and has a fancy new name, vendors can’t get a foot in the door. Demand generation is ruling the day, and only the vendors are seeing the benefit.

It’s not their fault though, you’re the ones buying their snake oil.

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

Insecurity Through Technology

Insecurity Through Technology

Some time ago I gave a presentation on BrightTalk titled ‘Insecurity Through Technology: Back to Basics‘ with the premise that the uncontrolled purchase of security technology to satisfy a perceived need may actually INCREASE your risk (go to Downloads if you just want the presentation).

Despite the crayon-esque diagrams, and the majority focus on PCI, I wanted to expand upon this concept in light of my current focus on simplifying security into “core concepts”, “appropriate / proportional security”, and “business-first”.

PCI lends itself as the perfect example of how a perceived need for technology can result in some very poor purchasing decisions.  Just look through the 12 sections of the PCI DSS and you may, in some form – and if you’re very unlucky – need ALL of the following; firewalls / routers, encryption, anti-virus, web application firewall, access control mechanisms, physical security measures, logging mechanism, vulnerability scanning, penetration testing, wireless scanning, file integrity monitoring, and a ton of ‘paperwork’.

All too often budgets are spent on items such as these at the beginning of a compliance project instead of when, and IF it’s really necessary. A lot goes into a compliance before you should be buying anything other than expert guidance or an education series.

The problem is on both sides of the sales process. The salesperson only knows how to sell either what they are being asked for, or more usually, as much as they possibly can. The purchaser has probably not done their proper due diligence and is asking the wrong questions. The best way to resolve this is if at least one side of the equation is aware of the The 6 Security Core Concepts, and follows the established good practice for the institution of a security program.

Analogy; If your doctor tells you you’re going to require an operation, you will of course learn all you can about the procedure. You may even become something of an authority in your condition (to laymen anyway). What you will NOT do is try to perform the operation yourself. Why would you treat cybersecurity any differently if you’re not an expert?

Know enough to ask the right questions, then let the experts take over. How do I…

  • choose the right technology?
  • ensure it can be integrated with current processes?
  • manage and monitor it?
  • measure it?
  • show the benefit to senior leadership?
  • …and so on…

If new technology is not properly configured, baselined, monitored, and maintained, you have added another potential vulnerability to your infrastructure. Any appliance is just another hardened server running an application of some sort, and should be treated the same way as the ones you build yourself.

Also, the more data you receive the more important baselining and tuning becomes, as you don’t want the important stuff to be obscured under layers of false positives. I do not believe there is room for Big Data analysis in security (per Don’t Get Me Started on ‘Big Data’), so integration of new technology with less-is-more security processes is paramount.

This has been, and will continue to be a theme throughout my blogs; 1) don’t buy anything until you know why you need it, 2) install nothing in production until you have figured out how to use and manage it, and 3) integrate all processes around it with a single overarching operations centre.

The threat landscape is intimidating enough without making things easier for the bad guys.

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

No Cloud

Don’t Get Me Started On ‘The Cloud’

With the exception of the iPhone ‘S’ versions;, The Cloud is perhaps the most irritating concept of the last decade.  It is the definitive re-branding of an existing service in order to drive new business in an era of doubt and uncertainty.

Security issues have become far more mainstream over the last few years, and lawmakers in every country are struggling to keep up with the demands for better protection of personal data.  So what we have now are hundreds of companies providing cybersecurity services ‘In the Cloud’. As though this is something new, and a must have for all organisations.

Breaking it down into its simplest terms, services in the cloud are services provided over the Internet.  Haven’t we had this for quite literally decades?  Why is the service to manage your firewalls suddenly a Cloud service, what’s wrong with simply calling it a MSS?

There are really only two valid ‘Cloud’ services;

1. Access to applications or resources you don’t have, and;

2. Distribution of functionality.

Everything else you do ‘In the Cloud’ is simply outsourcing, which is a perfectly valid, and often the best option.

Like everything else in security, never buy anything based on either a perceived need, what is the latest-and-greatest, and especially not a compelling sales pitch.  All capital expenditure, and moves toward outsourcing start with a business need, not external influences. This  includes compliance to regulatory standards.

You don’t need Cloud per se, you need a business process made cheaper, more efficient, or more competitive. HOW you get that done MAY include Cloud-esque services, but that will be determined by your Risk Assessment. Not by your CEO who read an article on his/her way to work, and certainly not by the fear of not having the latest toy.

Cloud services also add a layer of complexity that will generally be missing from most bespoke managed services; shared resources across multiple clients.  Who has access to your data?  How is your data kept separate from everyone else’s?  Because Cloud is a relatively new phenomena, SLAs and contract language has yet to catch up, so vendor due diligence takes on additional import.

In terms of providing a platform expertise that you don’t posses, or an operational resilience you simply can’t afford, Cloud may be an option. That said, you have best be sure your ‘Cloud’ provider has designed their service from the ground up, and not adjusted their marketing material. The latter, sadly, is by far the most prevalent.

Bottom line; do your homework, and run your needs by a security expert before taking the plunge.