What we built yesterday
In most enterprises today we have to care about privileged access. We’ve known insider threat was one of the biggest threat factors we face even before the likes of Snowden came along. And yet still we try to constrain and control access the same way.
If we consider some of the traditional ways organisations are managing privileged access I would boil it down to these:
- Employee vetting is a good way to find out if any incidents have happened in the past but doesn’t predict the future.
- Strong logging and reactionary controls are by their nature, too late.
- Strong authentication helps us to ensure that the person we granted access to is the person using it – but doesn’t govern the what.
- Constrain access to the minimum and lock down / require authorisation for anything sensitive – we stop administrators from doing their jobs.
- Segregation of duties – one person requests and waits the other gets round to approving or we artificially separate people from working on both sides of a system.
In my last blog, I talked about identity and behaviour being key to ensuring a modern authorization approach. Given we have large amounts of legacy environments today, then this is critical. But what about tomorrow’s legacy that we are building now?
If we continue to build applications in the same way we will have the same problems tomorrow, and the next year, and the next decade. Given that some systems organisations are maintaining are systems created in the 80’s and 90’s (!) we must think long term about our approach.
What can we build in the future
So what would be the best way to manage privileged access? Of course, the flippant and easy answer is not have it. But is that even possible?
Well, yes and no. We could design and architect our systems in a way that minimises the need for privileged access. This would, therefore, help to alleviate the problem.
If the application does all the encryption and the storage layer is dumb then who cares who has access to a database or file store? The worst they can do is delete content and in the grand scheme of things that is a small worry (that can be managed with backups and traditional privileged management).
But if we do that aren’t we just moving the problem to the application servers? After all, that’s where the keys will sit. Well, in a way yes and that’s a good thing.
If we also create Crypto as a Service (CAAS) type architectures whereby applications are calling into the service to perform all the encryption and decryption, then we now only have a single service to worry about.
That service could do all the behavioural based detection I mentioned in previous posts, does this application usually need to decrypt all this data, at this time, for this user. The crypto service would be able to see greater context than the other applications that only know their individual use case.
And of course, the administrators of the CAAS service could be segmented from the other application administrators, or maybe even the Information Security Team itself.
This architecture makes particular sense when it comes to cloud-based services, as now you can choose where to locate your CAAS. In a different cloud, on premise or in a separate account of your main cloud provider.
Of course, as with any technology, this isn’t the silver bullet to solve all privileged access issues. You would need to decide how to do searching, probably move away from the drug addiction that are relational databases. These are non-trivial problems to solve.
But if we consider the alternatives. In 20 years time another long manual process centred around a spreadsheet to do privileged access reviews and provide to auditors, I would much rather solve these tricky problems now.
What can we do today
So if I’m right and we can change the future we will operate in, that would only be applied to new applications we will build in the coming years (and the sooner the better). So what can I do now?
Today it seems like many focus on Privileged Account Management starting and finishing with control over the credential (usually a password). Sometimes coupled with log collection and occasional review.
This isn’t enough. You only have to look to the Bank of Bangladesh hack last week to see that abuse of privilege is occurring with huge financial impacts, and this is the most public of many.
Simply logging and handing out a password is insufficient. We must move to real-time review and response NOW! And not just when root access is provided. There is great technology available to do this and it does require us to think outside of the proverbial box.
Whilst retrofitting any technology is hard we can apply real-time analytics on actions being taken by a privileged user (and that isn’t just technical administrators) today. Moving from a compliance-driven retroactive control to a real-time preventative control could have saved the 10’s millions stolen.
We all strive for a defence in depth model. My challenge to you all, dig deeper, you are not at the right depth until you have this!
Adrian has been working in Information Security for 16 years of his 21 years working in technology. He classes himself as a technologist that specialises in Security. Working now as London Stock Exchange Group CISO having just been HSBC’s CISO where he was in charge of all IT security globally for two years. He has worked in many industries and companies, bringing his unique brand of security that puts the business first.
Prior to HSBC Adrian was Executive in Residence at Accel Partners (London) helping and advising startups. CISO at Skype for 5 years where web scale and big data was one of the most challenging environments to apply security to. Betfair, Man Group, Barclays Capital, BAA, BA, are just some of the other companies he has worked for across high tech and financial sectors. He holds a Masters in Information Security from the University of London.