“London calling, yes, I was there too…And you know what they said – well, some of it was true“!
So it was the 14th of December 1979 when the now classic rock album London Calling was released by the Clash. A mind blowing 44 years, three months and 28 days later, London is calling me, once again.
I’m back here in town attending what I think it is my 20th Gartner Identity Management event. Back then it was called Catalyst, and it was the domain of the Burton Group. If you were there too, well some of it was true – right? Identity has become a huge thing and that’s what has drawn us all back here to London today.
I’m here at the O2 working with one of my portfolio companies CyberIAM. I joined the board of the company nearly two years ago, and I’ve come back to London to help the co-founder Andy Pinnington and his team tell their story. They’ve done a great job building a fantastic Identity Management services company and I’m proud to be here to help them as they continue to grow.
But you know it really is déjà vu. Walking around the event showcase floor, I see so many familiar faces, familiar companies and old friends, it’s like going to a class reunion. But fascinating to see how everything changes, but yet everything remains the same. I guess I can, with hand on heart, claim some degree of source and origin for the creation of this space. With many of the folks at this event, we created an industry, a marketplace and a lot of vendors.
Today I sit on the investor and advisory side of the equation, working with entrepreneurs, investors, and customers to bring to market the next generation of IAM solutions. If you’re interested in seeing one of them, come listen to my session at 1:10 pm on the “Evolution of Identity Infrastructure” and an introduction to the new ServiceIAM product that CyberIAM is bringing to market. I’ll give you an introduction to how I seen this space evolving, and to why I think the focus needs to move from new infrastructure to new tools that help manage it.
If you miss the session, no problem we’ve recorded a delivery of the slides which we’ve made available from the CyberIAM web site here.
So if you are at the event, London really is calling. Listen to that track by the Clash, come find me on the show floor and as Mick Jones said in the classic last line of the song, “and after all this, won’t you give me a smile”.
If ever I’m asked how a general home network user can drastically improve their security posture, my first recommendation is “use Quad9 for DNS”. Quad9 runs a completely free global public recursive DNS resolver, that goes a huge way towards stopping malware and phishing attacks. By simply changing your default ISP provided resolvers to 9.9.9.9, you can dramatically improve things. There are very few true easy wins in internet security, but Quad 9 is one of them.
Quad9 is now, a Swiss public not-for-profit foundation, with the mission of improving security and maintaining privacy. Most unskilled in our art, don’t realize how critical and potentially vulnerable the whole Domain Name System is. You type a name in the browser and the resolver decides which actual server to send you to. Bad resolution, bad target, bad result, its as simple as that. Quad9 does an amazing job of actually doing something good and blocking the bad guys – for free!
This post highlights the crazy situation going on in Germany right now. In summary, Sony Music thinks its Quad9’s fault that bad guys are stealing their IP and pirating their media. Sony took out an interim injunction (310 O 99/21) at the Hamburg Regional Court to require Quad9 to implement network blocking on their behalf. The trouble is, this is just not how the system works AND it introduces a frightening precedent that if upheld, allows corporations to make DNS providers responsible for for just about everything bad that happens on the internet. It probably means the end of their awesome service and a step back to the dark ages for the rest of us.
Fortunately, most sane people that understand what’s going on here agree that Sony should just drop it. Quad9 already have the support of the GFF – the German-based Gesellschaft für Freiheitsrechte e.V. – a Germany specific version of the EFF – the Electronic Freedom Foundation that I’m a member of. BTW, if your not a member/supporter of GFF or EFF – go subscribe and get an awesome t-shirt.
The GFF is helping pay Quad9’s legal bills. “If non-profit IT security projects like Quad9 must bear the costs of combating copyright infringements, they can no longer offer their services in Germany in a way that covers their costs,” said GFF project coordinator Julia Reda. “As a result, everyone’s IT security suffers.”
“We view this case with Sony Music as a much bigger issue outside of Quad9’s mission to keep the Internet safe. This eventual final outcome of this ruling will set a precedent for European cybersecurity and policy,” said John Todd, Managing Director of Quad9. “This isn’t just about Quad9’s DNS recursive security capabilities; we believe it has a much broader application to a wide range of internet services, and service providers should understand the implications of either outcome of the case.”
More detailed information on the case and this issue is available on the Quad9 website at https://quad9.net/news/press/german-court-rules-against/. If you care about security and understand what services like Quad9 do, write to someone, post a blog, or go join the GFF/EFF and help them fight off a bad ruling with potentially hugely damaging implications.
I gave a virtual presentation last week at the Kuppinger Cole CSLS event. My title was “Old Dog New Trick: Musings on Enterprise Identity Governance in a Cloud-First Zero Trust Ecosystem”. The thesis of the session was how to apply old-world identity governance thinking to solve new-world security objectives. I wanted to pull out a couple of the key points here to hopefully, promote a little wider thinking and debate.
Cloud-first & Zero Trust are key enterprise security topics, so the question posed by the session was exactly how does governance & provisioning support them both and what does that look like in deployment?
As I’ve done before in the past, I offered three specific things that provisioning and governance can do to support a Zero Trust approach: implementing true least privilege, building a policy-based lifecycle and embracing something I’ll explain here as temporal entitlement. In the rest of this article, I’ll explain all three and let’s open the debate.
Implementing True Least Privilege
I think most people these days understand what least privilege means. To me, it means only giving people the access they need to get the job done. The question is how do you apply this to a cloud-first ecosystem?
Inventory & Visibility
And the answer starts with inventory and visibility. Here, the old mantra that “you can’t manage what you can’t see” has never been truer. If you don’t know who has access to what and why they have it least privilege has no chance. So, before you can adopt Zero Trust for cloud, you must deliver on what are basically old-dog security and governance tricks. It means you must aggressively manage a full inventory of all cloud apps and access. Of course, this must cover all AWS, GCP and Azure resources, plus your complete DevOps lifecycle footprint.
Least Access
Least privilege for cloud also means Least Access. By that I mean, thinking differently about providing access in the first place. We’re often all focused on providing the most access we can, but we need to flip that and think least or minimum access instead.
Let me give you a practical example of what I mean. How many of you, when you see cloud access in an access review, think revoke by default? Or when you’re delivering role mining and “birthright access” are you really focusing on the least amount of access possible? So, the closest peer-grouping, the highest match criteria, and the smallest access profile.
Because to really support Zero Trust provisioning and lifecycle management, it means giving out less entitlement by default. Giving out less by default requires no new technology capability being delivered by some magical new cloud services either, it’s a simple philosophy, delivered by word of mouth if needs be.
Self-service @ Center
And giving out less by default only make sense when it’s supported by first-class self-service and delegation. You must deliver intelligent self-service to your users that includes effective delegation and highly automated provisioning and approvals. If you focus on understanding patterns of access, instead of delivering them directly via birth-right provisioning (by default), you’re getting there. It requires making the self-service capabilities you deliver easy to use and available “on request”, or maybe “just-in-time”, something I’ll come back to in a moment.
I’ll say it again, none of the things I’ve mentioned here so far are rocket science or anything new. Good inventory, minimal birthright access and delivering self-service are all achievable with pretty much any old provisioning and governance tooling. Or maybe you just need the right delivery partner, with the right philosophy in mind.
Building a Policy-based Lifecycle
The second pillar for supporting cloud-first Zero Trust is a policy-based lifecycle. This one’s important for Zero Trust, but it really is something much bigger that crosses over the access management, provisioning, and privilege management boundaries.
Governance Models
Building a policy-based lifecycle starts with putting well known and well understood Governance models at the center of the access lifecycle. Yes, that often does mean Role Based Access Control, so building roles and maintaining their lifecycle, but it also means building other models too. Models that capture the policy of the “desired state” for access and entitlement usage.
Sometimes governance models are simple things like ownership and approval definitions that overlay responsibility and stewardship for all the things we care about. Sometimes they are manual or automated change control policies that carry out known actions when Identity, attribute and resource states change.
Or maybe sometimes that governance model is as simple as a clean set of requestable units of access – so self-service available to the right people to request the right access at the right time. These are all the models that drive a governance-based approach to identity and ultimately to best support a Zero Trust approach. We must commit to model and govern these policies prior to usage if we plan to minimize the risk.
Embedded Controls
If a policy-based lifecycle means developing core governance models, it also means understanding and implementing embedded controls. We must take the checks and balances of business best practice and embed them in the request and provisioning flow.
Again, no new trick here. Embedded controls are what we’ve been talking about in identity for 15 years now. But it’s still our job as identity specialist and IAM thinkers, to “evangelize” and to make sure that embedded controls like preventive Separation of Duty (SoD) are absolutely required for cloud-first zero trust.
Attributes Driving Access
Lastly, a policy-based lifecycle means understanding exactly when and where attributes drive the access. I know this sounds a bit esoteric but when I say Attributes Drive the Access I mean when any system makes an access policy decision based on identity data, or any verifiable credential, controls need to be in place to govern it.
To explain what I mean let me provide an example. When an AWS access policy picks up an attribute like manager from an Identity Provider (IdP) and embeds it in an S3 access control policy, the attribute drives the access. How do you run govern that? How do you define and implement the controls and where is the governance? Who manages the Attribute providence, are these attributes accurate and up to date and who verified them? Does the IdP know that this attribute is driving access down-stream, and are these dependencies being reviewed and audited?
These are very important questions. So, I foresee a cloud-first Zero Trust future where the providence and assurance of identity attributes and runtime access policies will be a key governance control. As we edge ever closer to a world of verifiable credentials and self-sovereign distributed identity, composing, delivering, and validating verifiable credentials will be a key focus for the access governance of the future.
Temporal Entitlement
And so, onto the third and final element of Identity Governance supporting a cloud-first Zero Trust ecosystem, Temporal Entitlement. Like most of the things I’ve highlighted in this article, this can be achieved with old-school provisioning and governance. But what does it mean?
So, imagine if you will, a world where everything provisioned was temporal, time based and non-permanent. Imagine a situation where every entitlement and credential hit a pre-defined “sun-set” date and was simply suspended, revoked, or removed. Now that really would be least privilege, wouldn’t it? Maybe you only get access to Salesforce for day, or a week, or a month and then you must ask to retain it. I appreciate that this may sound unrealistic, but with the capabilities of just about any reasonable provisioning tool, this is very doable. To prove my point let me walk you through a scenario.
Consider Dave, your company’s #1 DevOps pipeline delivery guy. He spends all week working with the access he needs to get his job done. Whenever he needs access to an image or a test suite, or he needs credentials to check in code, the governance engine is squarely in the loop. That means all access entitlements and their connections are either recorded in, or delivered by, the centralized tool. Again, no new trick here, the primary goal of any provisioning system is to track and manage the connections between people access and data.
Then the following week Dave goes on vacation for two weeks and arrives back in the office early on a Monday morning. While he’s been gone, his access and his entitlements have simply dissolved away – and all he’s been left with is a basic network account, an SSO launchpad, and the ability to request more access.
Now I can already see the help desk folks reading this rolling their eyes and shaking their heads but, trust with me this can and does work. With just basic provisioning and governance capabilities, it is trivial to simply put all his access back in place, maybe before he even knows it went away!
Using basic integration between SSO and provisioning, you can catch Dave’s actual access event and trigger a provisioning response. Based on his attribute and credential providence and his documented access history, we know we have the right guy trying to make the right access to the right applications. We can run automatic approvals, kick off dynamic provisioning and enjoy the protection of embedded controls; in short, we can put the right least privilege back in place, Just in Time.
With just a little bit of Old Dog infrastructure and just a little bit of new trick thinking, we really can make cloud-first Zero Trust a deployment reality TODAY.
In today’s work-at-home, socially distanced world, we’re increasingly reminded of the importance of proximity and the critical nature of physical access. As someone who’s worked in the logical world of enterprise security for so many years, it’s easy to forget that the fastest DOS attack ever, is a hammer swung violently at your physical storage array! And with the Corona virus on everyone’s doorstep, physical proximity has become an issue in every walk of life. For COVID-19 it’s social distancing and the now extensively accepted elbow bump. In software security it’s proximity to the hardware and control over physical access that underpins everything we do.
I’m reminded of this critical dependency by the recent announcement that nearly all Intel processors have yet another critical security flaw, that is “rooted” in the ability to touch the hardware. It now appears that anyone with machine access is able to bypass all platform security measures, including the full and unmitigated exploitation of the Trusted Platform Module (TMP). Anyone that’s tracked the long and intricate history of cryptographic “root of trust” fully understands the magnitude and implications of this statement.
The March 5thposting from Positive Technologies, titled “Intel x86 Root of Trust: Loss of Trust”, outlined a newly discovered critical flaw in the Intel CSME (Converged Security and Management Engine). The Intel CSME provides the cryptographic foundation for all hardware security technologies developed by their TMP, DRM, TPM and Intel Identity Protection system. Their report states that this newly discovered vulnerability “affects the Intel CSME boot ROM on all Intel chipsets and SoCs available today other than Ice Point (Generation 10). The vulnerability allows extracting the Chipset Key and manipulating part of the hardware key and the process of its generation. However, currently it is not possible to obtain that key’s hardware component (which is hard coded in the SKS) directly. The vulnerability also sets the stage for arbitrary code execution with zero-level privileges in Intel CSME.”
The report goes on to say that “this vulnerability jeopardizes
everything Intel has done to build the root of trust and lay a solid security
foundation on the company’s platforms”. They further state that “The larger
worry is that, because this vulnerability allows a compromise at the hardware
level, it destroys the chain of trust for the platform as a whole.”.
This latest news means that all Intel
processors released in the past five years have an unpatchable vulnerability
that is, once again, rooted in physical access protection. If
you’ve got physical access, you’ve got a vulnerability. Today, in the
shadow of the COV-19, just writing those words feels so old and yet so new.
Everything we thought was safe is only safe if it’s physically
secured, social distanced and wrapped in the unsettling reminder that
trust is transient and when lost, so very hard to regain.
There has been a lot said in the IT press lately about people burn-out in cyber security. To that point, it appears that the tenure of an average CISO continues its downward spiral, now trending towards 20 months or less. Twenty months is a crazy short time for anyone to be in such a critical business role. Most organizations need 20 months to accept the scope of the problem and fund a basic plan to move forward. There’s no way 20 months is enough time to understand business impact or enact lasting change.
The question that most boards are asking is why, why does’t that CISO stick around? Well Nominet, the UK DNS folks put out an interesting cyber report last week that may help point to an answer. They interviewed over 800 CISO’s from the USA and UK and concluded that extreme levels of stress are a prime factor. Sadly 48% of those questioned said that work stress was having a detrimental impact on their mental health. OMG, 48% and metal health in the same sentence! Even allowing for lies-damned-lies-and-statistics, that’s a crazy number that casts a troubling shadow over the future of security programs everywhere. The Nominet report seems to conclude that far too many security leaders feel the stress of being out-gunned in a unwinnable war – or as Gary Hayslip calls it a “Cyber Cold War”. And worse, most reported feeling underfunded and miss understood by their fellow executives and by their governing boards – ouch! And although Nominet only surveyed high-ranking exec’s, this problem likely crosses the security hierarchy and affects practitioners at every level. Just imagine being a threat analyst or a security tester when you are constantly under attack by a sophisticated adversary – it’s a psychological nightmare. Or take a tour of duty on a security incident response team and you’ll quickly see how totally consuming, exhausting and relentless the cyber defense and response game can be.
The Nominet numbers might seem staggering to anyone looking in from the outside, but if you’ve been part of a large security program you know the pitfalls. Building and sustaining a comprehensive cyber program is as much art and psychology as it is tools and computer science. Not every leadership team or governing board of directors even knows what to ask their CSIO to deliver, let alone how to measure their success. There’s plenty off tools and methodologies out there, but are they making the job of the CSIO any less stressful? If not, pass the hammer and order me a new monitor please…
Our journey began more than 4 days ago and I’ve not had a chance to think. The relative tranquility of our ride setup pre days, soon turned into the reality of the road. We set off from Jaiselmer and made good speed to Jodphur on solid roads. The mayor roadways are often smooth and fast and we made good time. The rolling thunder of the road in India is pretty wild from the seat of a Rickshaw. The noise, the smells, the people – we must have met (and I mean met, so introduced, conversation, goodbye) at least 20 people while they rode their moto bikes along side us.
Having a bike pull along side for a chat and a selfie while driving with one hand is common and unavoidable when you’re in an open-sided ride. We become “friends” as they weave skillfully along squashed between us and the oblivion of potholes, dust and dead things that is the near curbside of a major road.
John and I saw in the New Year from the rooftop of the Haveli. The rest of the crew stayed late to enjoy the RickshawRun party madness. We made another campfire on the roof and watched the stars get knocked out by the fireworks. A pretty cool place to end the decade it has to be said. Sometimes the internet pays back, as I was able to connect live (or near live) with the people I love that are now so far away.
After what felt like a cold morning in a meat locker, we spent the rest of a hazy crazy day on the Rickshaw Run lot pimping out the rides. We “attached” all the extended luxury rolling travel items we’d spent 24 hours collecting. We attached bottle holders and seat covers, and stuck foam to the bars and casings of the ride. With maybe two full days of cold northern road to cover before we get far enough south of the cold front, we had drop sides made to keep out whatever cheap India foe-leather can handle. Pimped out or puckered up, we all then headed out onto the roads of India for the test ride and appertiser before the main course starts tomorrow. Are we really ready? Maybe. Are we going regardless? Absolutely.
The crew just staggered in from the desert, back to the comfort of the hotel after a crazy night out in the dunes.
We took a “safari” with a short one hour camel ride – the dromerdary was not really high on anyone’s must do list so we went short on that. This was a lot more boys camping that fancy tents and tourist “gypsy dancers”.
And you can’t beat a hand cooked japatti, and some dall over an open fire. We tried Boogly for the first time – I can’t reliably describe it as it’s a cross between a fried savoy snack and a crunchy pasta noodle. Huddled around the fire eating off the production line was quite something. The chicken tika pieces were to die for. Just knockout camp chow for what turned out to be the coldest day in a century.
This was by far not the most comfortable night ever, but the stars were just amazing and the long night took on an challenge rating. The blankets weighed 20-odd pounds – really; the sand was as hard as board – which was odd, why not soft and grainy; and the wind blew cold, cold late in the night as the weather closed in. A warm start turned into cold finish as Northern India broke through a century-old cold weather record. Past midnight it was almost wet outside – but not frozen. Five coffin-like pods curled up in a row, really feeling the weight and the warmth of what feel like a mattres.
And now, from the warmth of my hotel bed, with the prospect of a cold night out there I think I might stay in bed with my socks on. As maybe a 1000 booming new years bahangra parties get ready to spark all over the city I might just stay in for new years. It’s dam comfetable and warm inside a 15th century fortress, wrapped up in bed with a cup of hot chia…
There’s something magical about being up before the crowd, particularly here in India. Life kicks off at a more sober pace before the dogs, horns and people take to the streets. The rooftops are empty, the streets washed clean and a hazy sun struggles to raise its head above yesterday’s output.
And as the sun rises over the great fort of Jaiselmer the early morning sounds reflect how things must have been. The sound of quiet. Just the cooing of a pigeon and the sound of the first street cart being pushed into place ready for the onslaught. It takes about an hour; by 8am she’s awake. The haze clears (just a little), the motors start, the horns blow (who the **** are you honking at dude, the street is empty) and so it begins again.
Having arrived safely in Jaiselmer in the far north west of India, we’ve moved into our digs at the Desert Haveli house inside the old fort. The guest house is a 450 year old merchant mansion from the time before time. We spent our first day here walking the markets and collecting goods. Everyone is a little jet-lagged and dazed but picking up fast.
Tomorrow we meet our Rickshaws and start planning our journey. You can track our possible track on Google maps here.
We’ll most likely start out heading for Jodphur and the magnificent fort there, then head south for Pune as fast as our little wheels will take us. The plan is to make the Sailpoint office in Pune on Wednesday 8th. After several passenger rides in local Rickshaws we’re all starting to wonder just how crazy this journey might actually be (gulp).
