Is the traditional AAA model of authentication, authorisation and accounting outdated? We sat down with Eban Escott, co-founder and CEO of Codebots.
Technology entrepreneur and co-founder of the successful startup Codebots joined Daltrey co-founder and MD Blair Crawford to talk about security, testing strategies, and the evolving relationship between software and clients. Below is a snippet of the conversation, but you can listen to the full interview via Apple Podcasts, Spotify, your favourite podcast app or online at Omny.
The theme of this podcast is application security, and it all starts with the AAA framework of authentication (who or what is accessing), authorisation (do they have the right to access something), and accounting (what did the application do, when did it happen, what commands did they use).
While the AAA framework sets up the right thinking within an organisation, it’s become outdated and it no longer fills all the necessary gaps when you’re considering a modern security posture. So can you explain to us a bit about the OWASP framework, and where that sits for organisations when they’re developing their security posture?
When I teach students and people new to software engineering, I use AAA as the first way to think about it. When you think about authentication, authorisation and accounting, which is sometimes referred to as auditing, it’s a nice way to get people in that mindset. But AAA was originally developed around network protocols and the like, and it’s been used in various other contexts over the years.
So OWASP (Open Web Application Security Project) for me takes it a little bit further and looks at some really good pragmatic things. There are multiple layers within OWASP and it’s actually a community-driven initiative. Many, many moons ago, a big gap in knowledge was identified and there was a need for an open standard on doing security on web applications. So that’s where the OWASP initiative came from. It’s non-profit and it’s basically set about to improve the security of software.
So how can organisations start to implement something like that. How did your business do it?
It’s a really good question and it’s almost more about the journey. It’s a commitment to doing more secure things – there are so many different layers to it. One of the layers to talk about, and it’s been in the news recently, is the SAMM (Software Assurance Maturity Model) framework. Many people have seen maturity models before, and you can think of it in the same way.
Now, what’s really cool about version two of SAMM that’s just come out is they’ve brought in operational management as a new security practice, which wasn’t there previously. I think that’s really important with a lot of the movement to the cloud and various platforms like this. So it’s got new functions and parts to the actual SAMM standard.
Whose responsibility is it to bring a framework into an organisation – is it the security team, the CTO or does it go up as high as the CEO?
The higher you can get buy-in for any initiative, the more likely it is to actually get implemented. Sometimes it’s difficult to get buy-in right up to the top depending on how big the organisation is. But there are lots of ways you can start implementing it within your team or within your department or business unit.
It sounds like you’re saying it’s better to start small with a specific project and then prove some sort of return to the C-suite. What are the returns for an organisation that adopts an approach like this?
There are two main bits that Codebots uses from OWASP. So you’ve got the SAMM standard, which is more organisational. It’s not specific to the technology or the application that you’re building right now – it’s broader than that.
Then there’s another standard, which is the OWASP Testing Guide, and that’s more specific. So if you’re developing an actual application itself, then this goes down to a really good level of detail on what you should actually be testing within that application.
And when an organisation adopts this, what type of benefits will they start to see?
This is super important for me, and a lot of the security-related stuff comes back to testing as well. So the stronger the testing framework is and the more resilient your software is going to be, the higher the quality. You can start pushing down the number of bugs and vulnerabilities in the software. I couldn’t give you an exact number on the benefits, but I believe if you have an annual turnover of $3 million or more, then you must report any data breaches and all sorts of other things around it. So how do you measure the impact socially and the reputation of the business?
Overall, there are lots of benefits to implementing the security. The real difficulty, however, is that because it sits in the ‘testing’ side of things, testing is a sliding scale. So what I mean by that is it’s been theoretically proven that it’s impossible to 100% completely test a software application. You just can’t do it – the permutations and combinations of the various things that can happen are exponential.
So where you end up with testing in software is a scale – you can become more rigorous and do a lot more testing, and as you move that scale up higher on the testing side, it obviously creates a lot more effort, which is what a lot of safety-critical systems do. Those sit at the rigorous end of the spectrum. If you move the sliding scale down the other end – maybe you’re just releasing a little WordPress website for a personal blog – then maybe you don’t need a lot of testing because the implications aren’t serious.
But the big problem is that there’s no such thing as 100% testing.
If you could give an organisation one piece of advice, what’s the first thing they should do to adopt a better security posture?
I would focus on your SAMM. So start by doing your broad audit, which is the maturity model. And then move on to the OWASP Testing Guide.
This is a big part of what we want to do at Codebots. Half of my PhD was spent on the testing problem around the bot’s writing code. So the bots write to the development target and they write to the testing target as well. That means you get this good mix with code that’s tested. And what we’re trying to do is get the bots to write to these OWASP Testing Guides. So out of the box when the bots write the code, you’ve got all of these actual items ticked off and tested, which means we’re delivering highly functional, highly secure software out of the box.
If you’re not interested in a technology like Codebots, then there’s definitely lots of other technology in the model-driven software engineering world. There are lots of tools out there that you can use to help accelerate and strengthen your software processes.
Let’s discuss the future relationship between humans and AI. Do you think we’ll see the bots doing all the ‘grunt work’ and tedious tasks, while humans do the more creative and fun stuff when it comes to delivering software?
That’s the general consensus across our industry and a lot of other industries at the moment. Just look at manufacturing and the Toyota Production System (TPS). Another way people talk about it is in terms of the lean methodology. Everything within that area is about the human touch, about building something the first time and then building a machine to take it forward and do it repetitively from then on.
I think you’ll find that will spread across into lots of other industries – it’s already happening – and we see bots as a natural extension for that within software.
So which industries are going to be the biggest adopters?
There’s no particular industry that won’t end up using this. My vision of the future is that every company needs to have some type of software-development capability, right down to small businesses.
The reason for this is that one of the biggest inhibitors around innovation is the inability of the software systems and the processes to underpin what people are trying to achieve. For them to be able to achieve it, they need to be able to take control of their software systems and not just use off-the-shelf.
I’m not saying off-the-shelf systems don’t have a place in the future – they definitely do – but it’s about using those off-the-shelf systems in the right context. When those systems can’t do what you need them to do, or when the total cost of ownership doesn’t have any budget constraints, then there needs to be the ability for the organisation to develop a custom system. And I see that happening across all industries.
Want to hear more about security frameworks, AI and how you can take the first steps towards a better security posture? Listen to Episode 3 of IDentity Today in full via Apple Podcasts, Spotify, your favourite podcast app or online at Omny.
