Recently, for the SSE Forum as part of our Breaking down Zero Trust podcast series John Spiegel and I had the opportunity to talk to Paul Simmonds on how he started his journey in IT and security, how and why the Jericho Forum was created and his advice to others getting started. When asked on how he started off in his IT career Paul's answer was ‘Totally by accident, it wasn't designed, it just sort of happened, like a lot of people in the early days to be fair’.
Paul did a degree in electronics and worked in theatre lighting, working in field service in the early days of microprocessor-based theatre lighting. Paul felt that this held him in really good stead as he got used to thinking on his feet and learning really quickly how to solve a problem.
Paul then did a couple of years in North Sea oil with subsea control systems and then spent seven years at JET. JET (Joint European Torus) was the world leader in nuclear fusion and it was a strange environment as nobody had ever done it before. Because nothing existed before, almost everything needed to be built. It was the norm, there is a problem, how do we solve it, now go build it. Little was available off the shelf as nobody had ever done it before.
As part of his role at JET, he got involved in the very early stages of the Internet. The scientists at JET were connected on what became known as the JANET and JET wanted to talk to other scientists across the world so they installed a 64k leased line (that cost an arm and a leg) and this allowed them to communicate with email.
The next request came to investigate a thing their sister lab, CERN, called the world wide web and everyone asked “what's the world wide web”. Paul and his colleagues had a day trip to CERN so that they could understand what the world wide web was, before coming back and implementing their own web server so that the scientist could upload their results and share them with colleagues around the world.
Next, the scientists wanted direct access to the reactor results so that they could analyse the results themselves. This meant them connecting the Nuclear Fusion reactor directly to the Internet which obviously didn't feel like a good idea! As firewalls could not be purchased at that point in time as nobody made them; they took the theory from the authoritative book [Firewalls and Internet Security: Repelling the Wily Hacker, Cheswick, Bellovin & Rubin] and used a SUN5s and a TCP/IP toolkit to write their own firewalls.
They had five firewalls in (what they called) the “onion skin model” with increasing layers of security as you move inwards with a web server on the outer layer of the onion; so that the results could be shared with all the scientists around the world and from there the rest is history.
Paul was then head-hunted by Motorola Cellular Infrastructure where he spent seven years as their (what you would now call) CISO, before going to work at Hostmark (and high-security Internet hosting provider) as their CISO and then on to ICI [Imperial Chemicals Industries] as their first CISO. He spent 7 years with ICI and this is when the Jericho Forum was born.
Paul commented that when he started his role at ICI, the Internet was really starting to ramp up and as a “real dedicated CISO” (with a full-time team) at a corporate level he was looking at business issues; as well as being on the “speaking circuit”. Security was really starting to take off so at conferences you would talk to the other CISOs.
Paul noted that the biggest problem he, and the other CISOs, saw at this time was that the vendors wanted to sell them bigger deep packet inspection firewalls to shore up their borders but actually the business was saying “You are the boys that like to say no”. Paul said the CISOs were saying “you can't do that because you need to do this, that, and the other; you need a DMZ, and you need to spend a lot of [extra] money”.
So, there was this conundrum between security and business. Security wanted to make things more secure, but the businesses felt they were being inhibited and being told “no” all of the time or that “it would take a lot more money for security to say yes”. Although everyone saw the same problem, they were all seeing it from their own perspective relevant to their businesses.
Next came “supper clubs”, especially if they could get ‘interesting’ vendors to pay for them. Everyone would sit around and discuss the problem over dinner and by late 2002 they all agreed that there was a big problem; and that there was a big disconnect between the vendors trying to sell bigger deep packet inspection firewalls and what the business wanted.
Everyone agreed that something needed to be done, but they all had quite large day jobs so the approach was for everyone to describe the Elephant in common terms so that they could then go out to the vendors (with a huge amount of security budget between them) and say if “you build this we will buy it”.
Everyone understood that normally it took around three years for things to come out of the R&D lab so if they wanted to buy it in three years to meet their business needs, they needed to influence the R&D labs now; thus Jericho was born. The name was all about “blowing the trumpets” and the ‘firewalls’ would come tumbling down [Joshua 6:vs20]
For the first six to nine months no vendors were allowed as they didn’t want them to skew the pitch. This time was used to define the problem and the principles in which they should operate. They started off with about twenty principles and whittled them down over time to eleven principles which they called commandments.
From there Jericho took a strategic direction and they drew up several papers including one called ‘Business rationale for de-perimeterisation’ which talks about the perimeter becoming less and less useful as a security boundary. Ultimately, they wanted to be called the “boys that said yes'' rather than the “boys that said no”.
They started to look at what this would look like (de-perimeterization over time) and realised that if you don't have a perimeter as a security boundary then it doesn't matter where you do your compute. They called this “computing outside your perimeter” - that then became called cloud [computing]!
The forum did a lot of work on computing outside your perimeter and then along came the Cloud Security Alliance with Jim Reavis (next in our podcast series ‘The Edge’!) who was setting up CSA. The Forum had always felt that if someone else was doing it then they didn't want to do compute, so why not throw their lot in with them! Which they did, and the research they had done became part of Version 1 and Version 2 of the CSA’s guidance.
The Forum threw their lot in with Open Group, as it needed some form of management, and the Forum members all had day jobs. The Open Group is committed to Open Source and one of the key things that Jericho had always said was that everything that Jericho produces will be Open Source. They did not want people paying to read the information. [You can find it here: https://en.wikipedia.org/wiki/Jericho_Forum]
The two last problems that Jericho tackled circa 2009/2010 were “how to secure data in an environment you don't control” and “how do you manage identities when you don't control them”. For the first one, it was felt that the industry already had a good handle on this issue so they concentrated on the second problem which they felt nobody had a good handle on.
Jericho felt that every attempt globally at doing some form of large global identity solution has failed miserably. They either implode into a subset that is used by the government or explode and fail (like the UK’s two attempts at the national identity system). This work continues today; it has transitioned into the Global Identity Foundation which Paul runs today and is aimed at fixing the problem of global identity so that we can deliver on the promise behind what we now call zero trust.
When asked how people should go about starting the Zero Trust journey Paul's answer was great. He said ‘by not using the word zero trust’. His take on it was that zero trust as a term was complete BS as it means totally different things to totally different people. He mentioned that John Kindervag (Podcast 1 in the series) first talked about zero trust as a network problem with a network solution but Google with their BeyondCorp ‘solution’ designed it to be network agnostic.
Paul feels that there are opposing opinions in regard to where people have come from, what their experiences are, what their attitudes are, and what they are trying to solve. For him, it's much simpler to talk about security full stop. What will it do for your business and your bottom line? As C-Level executives, these are the type of discussions people should be having.
What the board wanted to know is “what are you going to save us in terms of money and how are you going to de-risk the business”. The nuts and bolts are irrelevant; “tell us what it will do for us, what it's going to cost us, what it will save us, and what the risk is”.
For Paul, Zero Trust is about how you enable a business to work faster, cheaper and quicker; simple as that. As we have all seen, those businesses that have moved to a Zero Trust environment pre-pandemic generally are the ones that are the real winners; they are the ones that had first mover advantage. We have all seen businesses with lots of legacy systems and on-premise systems struggle over the last few years and these people are now really on the back foot.
John asked Paul if he could give some guidance to people who are struggling to implement the Zero Trust concept into their businesses and how they get over the barriers. Paul said he agreed that Zero Trust was a journey and not a product and that it’s an architecture and a business enabler; and that at best it will be multiple products. He added you need to be very careful to not try and boil the ocean.
Paul said his take would be to “pick your battles that are big enough to matter and small enough to win” [the Jonathan Kozol axiom/quote]. It's very much a case of working out where your quick wins are and what are the biggest things you can do for the smallest cost; then prove it from there. If you are going to tackle a big organisation, work out which systems are critical and start there. Those are the ones you want to enable. Repurpose money to do things properly, with a Zero Trust based solution so you can deliver value to the business.
Paul felt the biggest one for him was cross-collaboration. Every business has huge amounts of collaborative working. Joint ventures, third parties, ‘frenemies’ and it's really important to be able to collaborate securely. Things like M&A, and divestments are causing huge amounts of grief. The challenge is, can I set up a collaboration between five equal-sized partners and not have them all enroll in my identity and access management system to make this Zero Trust stuff work. He felt the answer today was ‘No’.
The acid test question is can I have this infrastructure sitting in China, can I enroll people that are not on my IAM system as equal players in this environment? This is what people should be thinking about to decide if this is truly Zero Trust or where you are having to compromise. Paul acknowledged that there was nothing wrong with compromise, but people should understand where they are compromising, and what it means for their businesses.
Paul said with his CISO strategic hat on, it's OK to cherry-pick solutions as long as you don't pick lots of disparate solutions as you are likely to end up with a real mess where nothing interoperates. So, you need to think about things a little more strategically; and look at maybe the top-twenty systems that are share price affecting, the ones causing the largest amount of business pain; and where they are in the refresh cycle. This makes the ‘sell’ easier and [your argument] more cost-effective.
It's critical to remember that this isn't really about securing an asset, this is about enabling the business and going from a position of ‘no’ to a position of ‘yes’. This is a business project and not a security or IT project.
