Podcast
Join Viktor, a proud nerd and seasoned entrepreneur, whose academic journey at Santa Clara University in Silicon Valley sparked a career marked by innovation and foresight. From his college days, Viktor embarked on an entrepreneurial path, beginning with YippieMove, a groundbreaking email migration service, and continuing with a series of bootstrapped ventures.
Links
Follow Me
Follow Me
Join Viktor, a proud nerd and seasoned entrepreneur, whose academic journey at Santa Clara University in Silicon Valley sparked a career marked by innovation and foresight. From his college days, Viktor embarked on an entrepreneurial path, beginning with YippieMove, a groundbreaking email migration service, and continuing with a series of bootstrapped ventures.
Nerding out about Security with Andrew Martin
Play On
01 JAN • 2024
59 mins
Share:
In this inaugural episode, I’m joined by Andy Martin from ControlPlane to explore the fascinating world of Cloud Native security. Andy’s extensive experience in regulated industries like finance and government offers unique insights into modern security challenges.
We start by revisiting our “Internet of Shit” conference talk, which sets the stage for a deeper discussion about current security concerns. What particularly caught my attention was Andy’s perspective on penetration testing and its role in both digital and physical security assessments. His breakdown of social engineering attacks reveals just how sophisticated modern security threats have become.
The conversation gets especially interesting when we dive into the ethics of hacking. Andy’s analysis of Black Hat, White Hat, and Grey Hat approaches provides valuable context for understanding the security landscape. We also tackle the ongoing debate between on-premises and cloud security, examining the unique challenges each presents.
I was particularly intrigued by our discussion of compliance and certification frameworks like SOC 2 and ISO 27001. Andy’s practical threat modeling exercise demonstrates real-world risk assessment strategies that organizations can implement immediately. We also explore supply chain security and Software Bills of Materials (SBOMs), highlighting their growing importance in modern software development.
If you’re interested in cybersecurity, cloud infrastructure, or risk management, you’ll find plenty of practical insights here. Andy brings both deep technical knowledge and real-world experience to the discussion, making complex security concepts accessible while maintaining their technical depth.
Transcript
Show/Hide Transcript
Welcome to this inaugural episode of Nerding up with Victor.
Today I have with me a very good friend of mine, Andy Martin from Control Plane.
We go way back, we've been on the conference circuits quite a bit together, travel the world and had a lot of fun at various conferences over the years and I think kind of related to this conference, this talk is our conference talk didn't have shit that we gave a while back ago which was a really fun talk at least for me to do.
So maybe Andy, do you want to do a quick introduction about yourself and Control Plane to give the listeners some context?
Sure, yes.
Thank you for having me on Victor.
Deeply honored to be the first guest.
Yeah, I mean I am a security engineer by trade I started a consultancy about six years ago based on servicing regulated industries, financial service, government.
We are now grown to just about 50 people based out of London but also in North America and Australasia and we love cloud native security Basically if it's got something to do with the cloud and something to do with security it is in our wheelhouse.
Everything from formal methods through to infrastructure as code preventative detection, protective and corrective controls, threat modeling, basically making sure that we harden platforms with usable security.
Still really focused on developer experience.
I am a computer science major, a deep technologist and yeah really love that work.
I'm also CISO at Open UK where I have a charitable position helping to advise UK government.
This is in the same kind of space as the European Union's CRA or the Biden ordinances out of the White House basically trying to ensure usable legislation is emitted from government and that we don't have things like trying to backdoor encryption or any of those nightmare scenarios and finally I'm co chair in the CNCF's TAG security where we help to assure Kubernetes based ecosystem projects such as Flux and Argo CD have come through recently We've got Kubeflow coming up at the moment we're looking at the Kubernetes CSI storage driver so we threat model and provide assurance and recommendation around those things and yeah all good fun and I missed the last time we gave that talk Victor.
I think were in Vancouver I.
Believe that's true, yeah I think it was a Linux summit or in Summit.
2019 would it have been?
Yeah, it sounds about right.
Must have been like a year or two before COVID Yeah, that sounds about right.
Yeah Good times.
Good times indeed.
So needless to say you are an authority when it comes to cloud native security and the Reason why I want to bring you on the call is to talk a little about security at large boats with regards to screenly and regards to like debunking a lot of common myths that you see a lot in security that I've exposed, that I've been exposed to quite a lot myself over the years that I kind of want to talk about that.
And to kick things off, I just want to share a slide real quick.
This is coming out of a report call from a company called Invitis, which is a German analyst firm that focuses on the digital signage market.
And a theme for this report was security.
And I can see people are being hit seriously by the lack thereof.
Secure, really.
And I really wanted to have like used as an opportunity stepping into what actually does it mean to be secure, what preventive measures doesn't want to have to do.
And then we're going to go through some various concepts over the over that are common to people in the security industry but may not be outside of the industry.
So I'm going to put the slide away real quick but and start by asking you about something you already mentioned, which is pen testing or short penetration testing.
You want to explain a little about the concept of that and how that works a little bit to the viewers?
Yeah, absolutely.
For any system or any property, if we take digital and physical, then anything can give some guarantee of security.
It may be that there's no guarantee or that we're of 80% secure against a multitude of things.
So for example, if I've got a wooden hut at the back of my garden where I keep my bicycle, well, probably someone could force the lock or they can punch through the window or they could just take the roof off because it's a wooden shack, it's not very strong.
That is a form of penetration test on a physical entity on a physical property.
Now if I put my bicycle inside Fort Knox, those attacks won't work.
There's no window to punch.
I can't force the lock because I'll probably get shot.
I can't take the roof off because, well, I can't get close enough to it.
And of course my bike's probably in the basement.
So then there's some different attacks.
Maybe I could trick somebody to get me into the building or I could dig underneath Fort Knox and see if I could get in that way.
So these are big physical attacks on infrastructure.
The same thing applies for digital attacks on technical infrastructure.
So for example, if I'm running an old WordPress site, then there's 20 different ways that as an attacker I can get into that site, onto the server and deface it or use it as a relay to launch further attacks, all sorts of different things.
But if I move my website to a static hosting service, for example, well, that eliminates a whole class of remote code execution vulnerabilities.
And then someone has to perhaps trick somebody who works for the provider, say Cloudflare or Netlify, and get through their security instead.
So penetration testing is a way of giving a degree of certainty to the owner of a property that they're resistant to a certain set of attacks at this point in time.
Now, it's only a rubber stamp because as soon as I put my bike in a shed and maybe somebody punches through the window and steals the bike, well, the next thing I do is I put bars on the window.
So if someone's going to test the security, they need to do it every time I change the structure or I change behaviors or processes around when I put my bike inside or what the thing is made of or how it's secured.
So pen tests give you a point in time.
Human observation and test of a digital estate.
Okay.
And we actually, we just finished our pen test, actual control plan.
Just conducted a pen test on Screenly actually, which was conducted last week and very happy with the result.
Only some minor fundings.
So very pleased with that.
So just bringing that full circle there.
So good job.
Shoot us.
You guys did a really good job on doing good assessment.
So good job there.
Used to word trick.
And I'm going to expand a little bit and just dive into what's commonly known is social engineering attacks.
And they can take many shapes and forms like they could be everything, more phishing attacks to proper social engineering attacks.
Do you want to expand a bit more on that and what that means and how to view that as a security threat vector?
Absolutely.
The weakest link in any chain is in any technical chain is generally a human running WordPress on an old version.
That's the weakest link in the chain.
But generally once something is highly secure, as in it's patched to the latest versions, it's using best practice, it's well monitored, logged and observed and integrated with people who can respond very quickly.
Changes or the release of new threats, new software vulnerabilities, once something reaches that level of high security and we can say something like Instagram has reached that level of high security, then people who want to steal someone else's Instagram account can't do that by attacking the castle.
Instagram is Your kind of Fort Knox in very general terms.
And you could say, actually, if you look at online banking, well, that is actually a type of Fort Knox in itself.
So instead of attacking the fort, then tricksters will attack the people who man the fort, or the people who are going in and out to deposit stuff.
And they do this via various different mechanisms.
But ultimately it's a form of confidence trickster or trickery.
And it can be done in such a way that perhaps there's a coercion aspect, perhaps there's just straight up deceit or misleading.
And this can be.
For example, there's a group of children basically called Lapsus, who have been responsible for a number of different attacks.
And they advertise on telegram saying, we buy VPN credentials.
So that's actually kind of not even social engineering.
It's just straight up digital piracy.
So then people will sell their VPN credentials, and people can access the system that way.
Now, the social engineering version of that attack is to phone somebody up and say, hi, we're from the central help desk.
We've noticed that there's a problem with your VPN or it's going to expire tomorrow.
Can you confirm your password?
Someone then confirms the password, but they've leaked it to somebody outside of the organization.
That is the social engineering aspect.
So manipulating a social situation in order to get a technical gain.
That reminds me of when were at DEFCON a few years ago.
Social engineering village.
Yeah.
Which was beautiful.
I mean, this.
It's.
Social engineering is something that I find personally beautiful because it exposes human weakness to various.
Well, it's psychology at the end of the day.
And going back to Kev Mitnick, who was a genius, or rest in peace, was a genius at this.
But that attack back there is using.
One of the one most striking with me was the one where they're using a record of just playing a child screaming in the background and was able to basically engage sympathy with the person letter end to disclose more than they should.
Right.
And it is.
Social engineering is obviously one of the most prominent vectors for more sophisticated attacks that we see more and more going more into the regular security world.
Do you want to expand a bit more on the console?
Black hat, white hat, gray hat, for those not familiar with those concepts, perhaps, that you probably run across once in a while?
Yeah, absolutely.
The.
The color of hat that a security engineer wears dictates what they do with their findings and the ethical approach that they take to determining the security of a system in the first place.
So if we go back 30 years.
If somebody called up a website on the very early Internet, let's say, and said we have access to all your passwords, they would generally do that in order to extort money from the individuals.
And that's because at that early stage, the reciprocity of a small number of highly intelligent, perhaps not formally educated and highly inquisitive individuals and the new kind of nascent commercialism of the Internet was not well understood.
Roll Forward kind of 10 years or so to the early 2000s.
Sometimes you could phone somebody up and say, hey, by the way, I've noticed that there's this vulnerability now.
Sometimes the person owning the website would say, tell me what it is or I will sue you.
Sometimes they would say thank you very much.
And sometimes they'd say that's great, I know that I would have lost millions if you hadn't told me.
Here's a small reward that became the bug bounty system, if you like, which now legitimizes hacking as long as the attacker only goes as far as they need to do to prove the attack.
So bug bounties are white hat hacker activities because you're performing a service for the public good, essentially.
You may be remunerated, but you're using your powers for good.
On the other end of the spectrum is the black hat hacker who has no allegiance or affiliation, maybe particularly anarchic or anti system, anti capitalist, doesn't necessarily just want to watch the world burn, but is often pursuing their own intellectual or financial ends.
And then in the middle sits the grey hats.
And a grey hat hacker may be aware of some of the darker techniques.
Let's say social engineering is a reasonably sort of slightly more on the manipulative end of the spectrum because you know that there are humans involved and if it's not done in a compassionate way, people could lose their jobs and people are being directly manipulated, let's say.
But the grey hat accepts that these sort of black hat techniques exist, but then uses them for good.
So that kind of spectrum, a gray hat will probably report a vulnerability that they find.
A black hat will perhaps try and sell it or extorts or something of that ilk.
And then you have the cause of zero days being traded, which kind of fits into that framework to some degrees as well.
You have a lot of, on the dark web, a lot of trading of zero days, for instance, before rather doing responsible thing of reporting them, they trade them instead of.
And if you find a zero day knife and like they would sell for like tens of millions of Dollars.
So there is a massive financial interest for people to trade these as well.
Right.
So it's interesting how that has evolved over the years.
When I started in the digital signage industry, one of the were cloud from day zero and one of the early arguments we had to have with particular with banks and more secure institution was they were under this notion that on prem is always more secure than cloud.
Do you want to speak a bit more a bit about that or how you see that world?
Because obviously you've been in the tech industry long enough, as I have.
Like you've seen the cycles to back and forth between on Prem and cloud a few times and.
Well, at least once.
And speak a bit about the security element of that, how you see that world.
Yeah, absolutely.
The pendulous swing back from sort of cloud to on prem infrastructure is almost the same as the declarative and procedural code configuration.
Sometimes people say this is the one true way and then the industry shifts and the pendulum swings back the other way.
Everything used to be on Prem and then the cloud turned up and we had the promise of developer agility.
No longer takes you a week to add a new server to your rack.
We had the promise of elastic scaling.
It no longer takes a week to scale for Black Friday.
You can just do that on demand and scale back down again.
We had the shared responsibility model.
So providers will deal with your infrastructure, with your network encryption, with racking and stacking everything with physical security for the infrastructure.
In some cases with a platform as a service, even patching your VMS or hiding VMS altogether and giving you access to Fargate or cloud Run or something like this.
That was great until most organizations realized, I mean, firstly, no one ever got fired for going to the cloud yet.
And then most organizations who pursued that then realized, well, actually this is very expensive.
We don't have spiky loads.
We're not Amazon.
So we don't have a huge Black Friday rush necessarily.
Even if we do, it's probably cheaper for us to burst into the cloud or to just over provision that capacity for two years because cloud makes sense in year one, year two, it gets more expensive.
Year three, people maybe start to ask questions.
But once all the infrastructure has replatformed to the cloud, it's very sticky.
There's some concepts of cloud gravity and lock in terms of security.
The idea was if my hard disks are encrypted in a data center, they're more secure because they're not in somebody else's data center.
The cloud is just somebody else's.
Computer.
Realistically there are certain things that cloud provider can get access to.
The network fabric is symmetrically encrypted.
But then once you get that data into your vm, once it's being processed off the network by the kernel or the network card, it's available.
And the shared responsibility model.
There's two different approaches.
For UK government deployments we had to accept that the Patriot act was the biggest risk of using AWS infrastructure.
In the US they have dedicated fedramp infrastructure which is staffed by security cleared people for that purpose by Amazon.
For GCP they do a monitored access so you get notified if ever somebody accesses your the data.
Cloud providers all provide HSMs as well.
So you want to expand on what an HSM is for?
Yeah, it's a hardware security module which is a one way diode for encryption keys.
You put an encryption key in and then when you want something signed, you pass in the unsigned data, it's signed internally and then you have the signed response or the encrypted response back.
So it fancy a version of a TPM essentially?
Yeah, it's basically a computer with epoxy resin in all of the holes and then they're graded some level of compliance with probably something like fips, which gives us an indication of how governmentally trusted almost that they are.
So those are kind of the two extremes.
Where the rubber really hits the road is a small number of people deal with a massive number of servers in the cloud.
Whereas for on prem infrastructure you have to go and do your own background checks on everybody there.
The physical security of the location is rarely as good as it would be with the cloud.
Procedures and processes are more uniform.
And to some extent, as we both know, this is not really the right question.
The right question is, well, what's the most common cause of breach?
It's misconfiguration and so almost kind of noodling over whether or not one is more secure than the other.
It's more about the patterns and practices that an organization has in place to ensure that they're secure today.
And it's like a pen test.
You make a change, you change the lock or you change the roof.
You need to re pen test that.
So having automated infrastructure as code and security as code testing throughout deployment, pipelines at runtime, and then running intrusion detection on the systems as well, it's far more effective for an organization than merely platforming to hybrid or on prem versus cloud.
Yeah, I think one of my beefs I guess with the whole on prem versus Cloud argument has always been it's true if you have a fleet of SREs from Google to manage your fleet of servers in your basement at your office, you probably going to be slightly more secure.
You could probably make an argument for it, but the reality is that unless you are the top 1 percentile of companies on the planet, you do not have the security staffing to actually do this, which you can.
So it's a bit of a false comparison to say that my survey the cost is actually more secure because you do not have, you don't have the benefit of benefiting from that pool of engineers that there are only so many top talented engineers at that level in the world and they are, most of them are working for the big cloud vendors or potential big banks.
I think that's kind of what was coming in with that argument.
But you absolutely right there is, it's, it's a lot about the configurations as well.
The other thing I wanted to talk a little bit about was compliance and certifications.
So when you do any of this there are Obviously the big two ones are I would say SOC2 and European version of that isO 2701.
Right.
I think at least to me these certifications are used a lot as a assurance to the customers that it's a kind of a rubber stamp that we are secure.
And I'm kind of curious about what your vantage point on that is because at least from my vantage point is that is not really like it does have some element of security, but it's more about the documentation process around your security practices rather than your actual real security where it's.
And that's more like in the NIST territory in my opinion.
But curious about your thoughts around that.
Yeah, I strongly agree.
It is a documentary compliance exercise in a lot of cases.
Some things are close to being self certified, although they're officially not.
And a lot of screenshots to get through an audit is of course that the complete and utter antithesis of any form of automated security.
I have horror stories from organizations going through these things where people have opened the web page, opened the browser tools, edited something on the page, taken a screenshot and that's their evidence.
None of the customers that I've worked with that is a friend of a friend, remotes from the organizations that we work with story.
But nevertheless all too easy auditors for this level of testing rarely have the in depth technical knowledge to perform any sort of automated verification in the first place.
Where organizations would do better in these Instances, it comes back to these three things, detective controls in the pipeline.
If we consider everything that comes into the build process as untrusted, so the end user device is pulling in open source code.
We're into the supply chain security story here.
But even less generally we have open source dependencies and transitive dependencies that are unassured.
We have the code that the developer's writing, which may not be secure in itself.
We have potential access to that developer's device from other people or their keys.
Any of those things can put untrusted code into a pipeline.
So first of all we have detective controls that run static analysis, dynamic analysis, that are looking structurally for abstract syntax tree errors and patterns.
Did this introduce a SQL injection?
Is there an XSS here?
It's more difficult actually, but still possible.
And scanning.
Have we committed keys here by accident?
Is this build actually reproducible Kind of detective?
Once those go through those initial quality gates, then we also have preventative controls.
So running in production, I try and deploy for kubernetes and containers, I try and deploy a container that's not signed or I deploy a container that violates the security context.
In those cases we have admission controllers that say, well I will prevent that from actually deploying.
So that preventative step, then the detective step, it is at runtime making sure our intrusion detection system works.
People are not escalating their privilege.
We're not spawning new processes either on the host or in a namespace that we don't expect.
There's a single process per container, that there's only one user and that's an unprivileged user in the namespace, etc.
And then finally corrective controls.
Okay, our detection has identified something.
Either our logs have gone to a splunk somewhere and we do a lot of this work where we go and sit in a security operations center, generate violations of policy rules, make sure that the detection is correctly configured in splunk and that then fires a notification which allows either a human operator to take a corrective measure or which is far more efficient for an automated process to freeze, quarantine, isolate, take some action with the non compliant workload and then we've got the whole suite of tools.
So we run that preventative to feedback to developers in the pipeline.
We run that detective at runtime.
So because we can't ever prevent anything, there's always mistakes.
And then finally the last line of defense, intrusion detection, and the output of that is some corrective measure, be that automated or with a human intervention, those are the Things that meaningfully keep a system secure.
There's always a zero day hidden somewhere.
We just don't know about it yet.
So when it lands, how do we detect it?
And all of those things are far more effective than box ticking exercises.
And none of those things would be covered in either those compliance.
I mean maybe NIST touches slightly on this, but I don't think ISO or SoC2 even touches on any of this.
So I think it's worthwhile lesson learned for people who do use that for procurement as like a rubber stamp saying hey, you're secure because you did ISO or Soc2.
But the reality is I'm not saying it's not a good exercise, I think they're both good process to do.
But from a more of getting a docs in a row rather than from security standpoint perspective, at least that's my view of it.
One interesting things, that thing that I early on heard a lot from particular banks and this is five, ten years ago at least it might have changed, it has changed since then.
But what you saw back then was particular for IoT devices such as our signage players.
The argument from the CISO or the CTO back in those days at least used to be, well, the only way to the way we secure our infrastructure is we slash them on a dedicated VLAN that is completely shielded off from the Internet and therefore they're secure.
And there is no reason for like you don't have to care about updating, patching, and they sit there on the isolated network.
But I'm not sure where to start with that.
But where do you want to unpick that myth?
Because for me there are multiple fallacies in that argument.
Right.
Where do you want to start unpicking that myth?
I mean it, I guess it's worth saying that the whole zero trust model is trust but verify.
And ultimately there is nothing's ever entirely secure.
So when Google were hacked by China in sort of 2011 and they were discovered to have had a long term penetration, I guess from the Chinese, they responded by building up beyond Core, which is their version of zero trust, kind of standardized it for the industry.
And BeyondCore essentially says for each machine that we're running, don't just trust a connection, but verify externally, use further heuristics.
Did this connection come from a machine we've spoken to before?
Are we in business hours in our region?
Is there any more metadata we can get from this ip?
Has it been doing other things?
Do we recognize it?
Does it come with cryptographic validation?
Of who it is.
And then the kind of levels of this can be seen in the way that logging into a Google account, for example, sometimes if you change locations or countries it will say well I haven't seen this before, going to make you log in again.
So that's the most effective way of securing perimeters if you like.
But the second part of this is just because something is in a zero trust network does not mean it has to sit on the public Internet instead you still want to layer defense in depth.
If it's a highly sensitive system, stick it behind the vpn.
But in terms of how things should be secured really it comes down to a threat model individually for each circumstance.
Who are the threat actors that we're protecting against?
What's the classification of data in the system?
Do we trust the system at all anyway?
And yeah, there's so much more nuance as you say, than the VLAN or not.
Yeah, I guess my counter that was always like yeah, but it's a matter of time before something enters that VLAN that wasn't supposed to be there.
And if they're not patched enough to date all these devices it's kind of game over because you haven't billion vulnerability to pick and choose between.
Right.
Launch metasploit and Happy Days and which is where there's.
We can dive into zero trust a little bit later on.
But the idea around zero trust is to re.
To.
To restate that it's basically you assume a hostile environment.
Right.
You assume that.
You don't assume that just because you're in your office that it's a safe space to be in.
It's.
You assume that everything that's on the network is essentially has the same threat as a public facing device on the public Internet.
Right.
And that's what you make your assumptions based on rather than inverse.
So I think that's.
Yeah, it's an interesting thought process and model that started to be adopted more mainstream.
But back in five, 10 years ago that was obviously not a very well adopted framework.
But now we start to see more push of that which Is great from a secure perspective.
You touched a bit on threat modeling and I'm quickly gonna do you a threat modeling on the spot.
Dandy.
Which is something that you have for breakfast normally.
This is a very simplistic flowchart of how in this example it will be a digital signage device, obviously the device and then you have end user in the back end.
Do you want to do a quick threat modeling how you See this like really big picture, like what are threats for each side of these?
How you see this world, starting from the device?
Like how would you think about these?
I mean, we don't have to go to nation state actors, but if you are 14, 500, what do you have to think about if you want to deploy something like this at scale?
Yeah, absolutely.
My preferred way of threat modeling is to use the stride model out of Microsoft.
And it has four stages.
First of all, what are we building?
Then what can go wrong?
That is a catastrophization exercise where there are no wrong answers.
Then what are we going to do about it?
So how do we make sure that we've got appropriate controls for everything?
And by appropriate controls we mean are we going to accept this risk, Are we going to fix the risk or are we going to mitigate it?
What that means by extension is if we've got a risk and we can buy insurance to save ourselves from putting in a complex technical fix.
Well, we might want to do that, but it just means that everything is logged and cataloged and there's no risks unaccounted for.
So in this case, what are we building?
Well, we have an IoT device of some description here.
Who knows what type it is.
It is attached to the Internet and the user accesses the Internet to get to the device.
And there is a backend which is also Internet accessible.
So what are we building?
Well, that's at a high level.
Next we might look at the data flows.
So we've got, we assume TLS is coming over HTTP for those things or TLS 1.3 is A, depending there's some sort of HTTP or TLS protocol going on there.
We would also assume that over TLS we have some sort of binary protocol or maybe it's a restful or graphql thing going on between the back end and the device is able to call out.
So those arrows may be a bi directional for they would bidirectional in this.
Case, I would say yeah.
And so at that point we have an idea of what the thing is, what data is going through it.
And we'll just assume, I guess, that everything is at the same level of sensitivity, which is we don't want to leak this, but it's not necessarily pii.
We just want to keep everything private.
So with those assumptions and also we'll assume that we're dealing with criminal gangs and not nation states, because a nation state can more or less do anything if they really want, you know, it kind of depends exactly what level of target you are.
But yes, it is a level of abstraction even more difficult to.
So for example, the nation state here might just record all the traffic between the points, send it to a data center and just wait until they've decrypted it.
Or that the protocol has been broken in five or 10 years time that changes the security model because then there's a temporal secrecy aspect to the data.
So let's descope those and talk about criminal gangs.
So what might they want to do?
Well, if we know that the user is going through the Internet to get to the device and they want to understand what can be done there, can they sneak on that information?
Well, what can they do?
They can attack the user.
So the user's physical device security should be considered.
They can try and get some sort of man in the middle.
TLS is designed with an asymmetric key exchange Diffie Hellman start off with so that it can run over an untrusted network.
That's how TLS bootstraps with perfect forward secrecy as well.
It becomes quite difficult to decrypt because you're constantly changing that encryption key.
So we're probably reasonably safe.
That criminal gang, maybe even a nation state can't get to that information through a man in the middle box.
There might be.
I mean there's other things in there, like maybe there's a VPN or Tor that would have to be attacked separately.
But if we assume it's just a straight through connection.
So Internet to device, if it's an IoT device, where is that hosted?
Does the TLS get terminated on the device or is there a viral that's decrypting the TLS in front of the device?
Can we attack the firewall?
Is the firewall the latest patch set?
If it is being decrypted on device, can we get physical access to the device?
Where is that hosted?
Is it possible to just turn up, pop the COVID off and attach some electrodes and read some memory?
Is there a TPM on the device?
Are there private keys that are used for the encryption exchange?
Can they be exfiltrated with physical access?
Let's assume that we've.
Those are all the threats.
And for threat modeling, I think fiscal.
Access kind of game over in this case.
Right.
Unless you're dealing with really sophisticated hardware that is unreachable for most providers, really.
Right, absolutely.
And that's generally true for everything.
As soon as you can physically get access to something, you can probably get into it.
But yeah, exactly the case even with tpms and confidential computing, which are designed to defend against a hostile root user, if you can shave off each layer of a chip until you can get to it, you can reverse engineer a lot of things.
That is very difficult, of course.
But yeah, there is some recent development.
That recently that I've seen about attacking BitLocker, for instance, using this.
And yeah, but I think that's out of scope for this exercise.
Right.
And I think.
Sorry to like derail that a little bit, but one of the interesting questions one of your team members asked me when we started conducting our pen test for our infrastructure was what's the worst thing that can happen?
Like, what's the worst thing that you can think of?
Worst case scenario.
Right.
So in the scenario of Signage, it's like, well, there are a few things is using the device's stepping stone into the network and there have been multiple attack vectors, attacks like that over the years, in particular using IoT devices.
Another one is also defacing the screen content is not a big one, of course, and that can be everything from a PR disaster to far worse.
Right.
So I guess that's kind of like the angle I'm coming on here.
What is the worst case scenario?
You like a device, for instance, like rogue firmware update, for instance, is a good example of things I'm thinking of that could potentially be used for this.
Right.
But yeah, sorry to derail you a little bit there, but yeah, that.
Just to think level how I'm thinking about it as well.
Cool.
Yeah, I mean, I remember there was a casino.
I don't remember if it was Vegas, but casino that was broken Iot.
Fish tank monitor.
Yes, yes.
So Iot when unpatched is obviously a common access to an internal network.
Okay, so the initial view there was snooping on the information between the user and the device.
Let's look at the back end.
So that device is able to talk out to a backend and vice versa.
What functions does that provide?
Well, there's some remote procedure calls, there's the system patching, as you've said.
So it might be taking the user data and sending it back out across the Internet.
It's also pulling in trusted data that it will load into itself, which is that update mechanism.
And I happen to know screenly uses snapshots, which are a great isolation mechanism because they're just containers, basically.
So actually those updates are severely de risked for application updates.
If it was a full device firmware update.
Then we're back into, well, this is installing Ring zero into the.
We have a DEB package, right?
Unless it's properly verified.
Yeah.
So what comes across there?
Well, we're relying on the sanctity of the transport, which is the transport layer is encrypted.
Then we get a hash that comes with debs.
So we know that the package that we receive is the package that the package maintainer has packaged and advertised on the DPG repo.
We have also got anything that comes with, I guess down into the firmware.
So we've got the kernel updates.
On the one hand, one thing with Linux that is generally less opaque is its firmware updates.
Of course, for Raspberry PI that is very well known and quite transparent, I believe, compared to for example, the Intel Management Engine updates, which are binary blobs, Nvidia driver updates, just completely opaque binary blobs.
So from that set of threats, and I've kind of merged together threats and controls there, which is not best practice when threat modeling, but we would say, okay, so threats, malicious user forces device to download vulnerable updates with backdoor.
Okay, so what are the controls we have against that?
First of all, the set of update servers that we use are hard coded into the ETC APT sources list.
So we know that they're going to a DNS location that we trust.
Second of all, we've got checksums that come with them.
So even if we're pulling down a vulnerable package because someone's compromised the upstream package repo, they would also have to compromise the secondary location.
This is deemed good enough for many millions of installations of Debian and Ubuntu around the globe.
And it's the same for Red Hat and various other mechanisms.
There are also GPG signatures that go with those checksums to verify that they've come from somebody that owns the key.
So we've got multiple layers that defend against the likelihood of a malicious update and what we do.
So the way that I conduct these, my stride practice, if you like, is I say, well, what's the risk?
The risk one to five of somebody loading a malicious update?
Well, it's actually, sorry, the risk is the impact and the probability.
So the impact is 5.
This would backdoor the system and it would compromise and be.
It would be game over.
But the probability, well, let's look at the number of controls that are upstream before we've even bothered to configure this ourselves.
We have so much trust in the quality of the work that's gone there.
That's a one.
So impact five probability one.
The risk score is five out of 25.
And if we look at a different route, which would be compare and contrast to the user having their password in a data breach.
So let's say I'm Joe Bloggs and I use the password joe blogs.
For every single website I have log into, one account is compromised, uploaded to haveibeenpwned.com and then someone decides to try and attack my user account.
Here they do joe blogsoe.com and they put the password that they found from a different breach in and it works because the users reused their password.
So impact probably maybe a three because it's only maybe three or four because it's only one device and one user or one account.
So it's constrained to the correct and normal usage of the system probability maybe 2, 2 or 3.
So I mean, and then you could say so let's call it two by four.
So the risk of that is an eight.
And then we start to get this list of things.
Now it is very difficult for a website to prevent a user from reusing a password.
There is an API for have I been pwned?
That allows you to do fractional hash comparisons that does try and stop people reusing.
It's not very widely implemented and honestly it is on the user at that point.
I mean you have Google's push for passkey, right?
Google and Apple, are they pushing more of a passkey, right?
You might want to say fee word for that because that kind of eliminates a big part of that vector, right?
Yes, that's definitely true.
The passkey then relies upon the sanctity of the end user device, which of course we have to have in order for the password not to be key logged and stolen anyway.
So yeah, I mean passkeys are a great way of doing a human certificate identity.
It's kind of a long cryptographic string that replaces passwords and so replaces password reuse.
They can also be anchored in a physical root of trust.
He says, like Yubikey.
Gotta love a yubikey.
Carry this around with me 24, 7, which provides cryptographic verification of a certificate that I own.
And so I can use to sign things, to say at this point in time I'd liked or trusted this thing enough to sign it.
It doesn't really mean anything else, but if we consider it in those terms, it's a useful way of putting a kind of rubber stamp or an old signet ring wax seal on something.
Do you think we're derailing a bit here?
Do you think PassKey will replace MFA or 2fa or do you think they'll be in conjunction?
Usually.
Conjunction usually.
How do you see that?
So MFA relies on something you have, own or are and a passkey is.
No, no sorry.
Something you know, Something you have.
Yeah, something you are, something that you know or something that you have.
So the knowledge is the password.
The thing that you have in this case is a token.
Something that you are would be a biometric scan or a fingerprint.
The problem with something that you are for a human is that you can't rotate those things.
I can't change my retina.
Once my retina scanned, someone takes a high definition photo of it and then recreates my eyeball and uses that to get into a high secured facility.
It's the stuff of Hollywood legend, but nevertheless fingerprints are non rotatable With a workload, with the digital workload, you shoot the thing in the head and just spin off another one.
So you can use things like process id, which is now in the order of billions on a modern Linux kernel Process ID environment, variable hash, the process name, the age of the binary, the size of the binary, all of these kind of things can give you a set of selectors that you put into a certificate and that's then something that you are.
So that's the second factor there for passkeys.
Passkeys are still something that you know.
The difference is you don't quite know them in the same way because you don't memorize them.
They become accessed through a Central.
You use 1Password to access or use a single password to access a repository of pass keys and then that's validated in a second factor way, either pressing a notification on your phone or your watch.
As long as there is a secondary mechanism that is not reliant upon a single password, it doesn't really matter what the second factor is.
Some are better than others.
Obviously SMS is awful because GSM is backdoored.
I was, ironically I was in the House of Lords for an open UK Open Source Awards event on Monday telling the Right Honorable Lord Vazy about police interception of GSM for SMS2.
I appreciate the fact he did take the time to listen.
So yes, I don't think, I think we'll replace 2fa entirely because we need to have a secondary mechanism to ensure that if there's one level of compromise, for example, someone steals my laptop and I'm already logged in, I still have a secondary mechanism to defend myself.
All right, that's fair.
I want to bring this back a little bit to the diagram.
Real Quick because one thing that I've been.
Well, we've been talking a lot internally about screen in the last year or so as we delved into the x86 world.
So we obviously we have TPMS on every, on all our devices.
We use them heavily for both secure boot and we use them for mtls and zero trust like workloads.
But the one thing that scares me a little bit when we start to think about threat modeling the actual devices is the importance of the bios.
Because I recall this must have been good 15 years ago I went to OpenBSDcon back in those days and I still around and there was a talk about how an attacker compromised a VPN server by modulating the power to the tpm.
Essentially the cryptographic.
It was HSM probably and was able to predict the rng, the random number generator on the board and bringing this back into modern day with screenly.
One of the things we're thinking about is like how can we actually trust.
What's the bias?
Because at the end of the day for most people, just much like you were saying about the Nvidia blobs, just a binary blob that you apply patch your bias.
You don't have much insight in that.
I mean I guess core boot is the only really interesting project in that space.
But what I'm saying is if you can compromise the buyers, you can't trust any cryptographic operations on the device whatsoever.
So I'm just curious about what you're thinking about that in terms of probability, I guess and in terms of impact because I guess impact would be 10 and probability might be 2.
But it is still like an interesting one that I guess not a lot of people think about going all the way down to that level.
One of the biggest or slowest patch sets ever to hit the Linux kernel was from Matthew Garrett, the lockdown patch set, which is kind of based on this.
What happens if we don't trust in that case, what happens if we don't trust the kernel?
Actually what happens if we don't trust after we've securely booted?
So the concept of secure boot from a TPM is the hashes of the firmware in other parts of the bios.
So the BIOS firmware itself and the controllers for memory and disk etc.
At boot time then they are hashed and they self report back into the tpm.
The TPM then compares that to a set of signed hashes that it has and is able to say well that's not what I expect this system has been tampered with.
I won't boot anymore.
So that's one way of securing the bios.
It does go a decent way against physical intrusion, but of course you'd never say never with physical access to a device.
After that point, the lockdown patch set will try and continue to validate whether or not the kernel and the Linux system are actually doing what they say they should do in the event of a compromised bios.
It's building upon a foundation of sand, essentially.
Ironically, computers are just melted sand anyway.
But yeah, in that case, the cryptographic verification of the firmware versions is about as far as things can go at this point.
Operating everything within an enclave does.
Does really help confidential computing aspect that is more about defending against a compromised user session so the root user is untrusted.
Ultimately it sort of comes down once again to sort of where the threat model is on this.
But yes, a compromised BIOS is difficult, but there are mechanisms, especially with tpm, that make a lot of sense to help defend.
Yeah, no, it was just.
It's something that we talked about in particular, like predictable RNGs.
Right, because then every cryptography you could possibly do on the system at runtime is void.
Right?
Which is a terrifying idea to think about.
You can have the safest security in the world, but it doesn't really matter.
You want touch a bit on this, but I would like to dive in a little more about this because it's something that I know you've been passionate about for a long time, which is supply chain security and S BOMs.
Maybe you want to start by explaining what I mean, you already did a little bit about what is supply chain security, and then maybe dive in a bit about what S bombs are.
Yes, absolutely.
So supply chain security is the concept of all things that make up and compose a piece of software.
So the actual software itself is one thing.
So I've written my application, but then I call in a dependency, and that dependency might be my restful framework, let's say.
So I've written something that gives me back cat gifs and then I put it behind the restful API.
That API pulled in another 10 dependencies, each of which have their own 5, 6 dependencies.
These are called transitive when they're not the primary, but the secondary or tertiary, etc.
Dependency.
So what happens from there is I've written one piece of software, but I'm calling thousands of lines of other people's code.
I don't run any direct assurance on those lines of code.
This is the supply chain.
And it's analogous to building an aircraft carrier.
Every single piece of steel, every nut and bolt, every pan, everything that lands on that aircraft carrier must be accounted for and identified by a sku.
And the source of that supply linked back to where it came from.
So for software this is very difficult.
Not as difficult as for an aircraft carrier, of course, but we've generally had a problem with this in security, in open source, because we trusted open source.
And now that banks have adopted open source, it's seen as a good way to get into other people's infrastructure.
So supply securing the supply chain can be done in one of various ways.
There's a push for software builds of materials, which is where you list out all your dependencies and then you track them all and you query against them.
Which can be useful if you have a vulnerability in maybe log 4 shell, but it requires assiduous tracking of everything and we're not there yet.
We can have build monitoring.
So this protects against the solar winds problem.
What happens if somebody is running malicious code in the build?
Well, we trace the whole build and make sure that's, that's safe and secure.
We've got repackaging where you take open source dependencies, you have them centrally repackaged.
This is what Red hat enterprise Linux does, what Google assured open source does.
It's what the chainguard approach.
And you repackage those and you say I certify these to be free of known vulnerabilities, which is the preventative aspect.
But as we spoke about, you need that detective and corrective too for a secure system.
So it's all very well to do that, but you also want to run intrusion detection because it's only known vulnerabilities and there are various other nuances of those approaches.
But ultimately taking a software assets inventory of everything that is installed across an estate, across a bank, across a startup is the first thing.
And there's salsa that the software levels of supply chain assurance I think it stands for, that gives us a view on well just check everything and then check and sign it and then check, sign and verify and then check, sign, verify and test across everything all the time.
Essentially it's an intractable problem that can be de risked dramatically.
But because of all the lines of open source code going on here, there will always be vulnerabilities in software and it's just about reducing our risk down to a tolerable level for our organization.
And I think SNYC has done a lot of good work around state of open Source their annual report.
Right.
And around.
I think NPM is probably the most targeted, I would argue supply chain attack.
Right.
And one of the interesting attack vectors is fuzzing packages.
Right.
You just rename them ad ness or whatever and attack in that way.
Maybe you want to speak a bit about what have you seen from that point and like what like common attack vectors around supply chain security.
Well, NPM is perhaps unique in that it was a new package registry that turned up with the advent of Node JS and it was the fastest growing because nodes and JavaScript optimized for very small composable libraries instead of bigger Java like framework libraries which meant that it proliferated and there was a huge number of open source projects pushed.
Then when supply chain attacks turned up, one of the first ones was typo squatting where instead of running left pad someone registers left pad all one word copies the same code up and then when a developer accidentally uses the wrong one, they don't notice it's still installed.
It still works.
After there's 10,000 monthly installs, the attacker who's typo squatting uploads malicious code and suddenly it runs.
On every build server In Silicon Valley we saw namespace registering attacks where people actually deleted software and then somebody else registered it and then that was automatically installed.
So yeah, NPM became the battleground for open source supply chain attacks in the first case.
PYPI and rubygems have also seen a lot of this since.
Also maven, but slightly less so.
Java has more trouble with replaying old versions that are vulnerable to the historical attacks.
So NPM now requires two FA for any provider, any producer that pushes software to the system.
It supports Sig Store so we can sign the piece of software and upload it to and upload that signature to a public registry.
We can run salsa attestations in builds and push those up as well.
So all of these things just gradually increase confidence ultimately if any of those things that there's also the CICD best practice scorecard.
If a developer is doing any of these things it betrays a supply chain awareness that is unlikely to.
Well, that's more likely to be indicative of good security practices across the entire developer platform, across the entire developers output.
Nothing is gold standard, nothing is bulletproof.
But when it comes to supply chain security then NPM have taken steps because they've been so highly focused on Good.
Thank you Andy.
I think we are running out of time here and very much appreciate you coming on and it's always a pleasure to no doubt about security with you.
So thank you so much for your time and, yeah, I hope this was helpful and useful for people listening.
Thank you so much, Andy.
Have a good one.
Thanks for having me.
Bye.
Found an error or typo? File PR against this file or the transcript.