← All talks

The Squid That Lost Its Shell - Simon Goldsmith & Christine Sharder

BSides Bristol33:177 viewsPublished 2025-01Watch on YouTube ↗
Show transcript [en]

thanks everyone thanks for having me hope you're um enjoying the day um I thought Sarah kicked it off brilliantly so hopefully um I'll do this talk Justice um as you can see I am only one person therefore it is just Simon Goldsmith you're getting today you aren't getting Christine um and what that means is you're missing out on an amazing business intelligence lead that works in my team and probably a whole load of Texas jokes that I'm just not going to do justice so I'm not even going to try um so I'm going to do my best but please bear in mind the vast majority of what I'm about to present here is not my work it's the work of my

team and so they need to take full credit for everything that I talk about unless you don't like it in which case it's all on me so I'll start with the metaphor that um uh that is the basis of this talk and the squid that lost its shell so squids used to have shells um back in the Jurassic period they used shells to rely on defense they looked a little bit like ammonites for those that have wandered the beach beaches a Dorset and and elsewhere um but as the Seas became more acidic um those shell shells weakened and uh the calcium carbonate faded away and they need to develop other defenses it was probably kind of two goes hand in

hand right if you kind of develop other other defenses you have less need for a shell so it's probably half you know six of one half a dozen the other but it did mean that squid wids now have three new mechanisms for defense that they didn't have before so they're able to manage their exposure camouflage in in kind of let's not take that too literally otherwise we go down a whole thing about security by obscurity but right we'll stick with exposure management um they developed agility they can react really quickly to danger and they've got a level of intelligence that other animals don't um don't uh don't exhibit so that's the kind of the metaphor we're

working with and I'm sure most of you in the audience won't take too much to make that link to De parameterization so um I think the one of the main points that I want to get across in this talk is when we talk about de parameterization and I'll use the words zero trust um we think about it from a security angle and I'll get into it in a little I I'll get into it a little bit so going back to the early 2000s um a bunch of Brits and a bunch of Americans got together and formed something called the Jericho forum and they recognized that the way that the internet was taking us inevitably was

down this path of deep aromatization and taking down the hard Network um boundaries that were protecting our organizations against cyber attackers um unfortunately and I say this is back in the early 2000s right so this is 20 plus years ago unlike the acidity of the Seas attackers aren't a particularly good feedback loop it's taken probably about 20 years to realize that we've got this continuous kind of attacking against our organizations probably a little bit less than that if you kind of take it into account but it's really things like ransomware and business email compromise that we're talking about this morning it's that kind of continuous erosion of our of our boundaries that we we take

down our own boundaries but also those attackers coming in has meant that we've got a really big security problem so the first thing and I think take away from this side is we've got to recognize the business imperative first so take your security hats off the reason that businesses are doing this because they can collaborate together with each other they can start to take Advance advantage of really commoditized services like infrastructure as a service or cloud or software as a service they can take all of those really commoditize Services into their organization and we can put data in there they can move faster they're more agile and they can make the staff EXP experience and the customer

experience better so there's all these business imperatives to do it and my argument would be that when the Jericho Forum formed kind of 20 years ago and then you know a few years after that they kind of declared success because they invented zero trust they'd come up with a technology solution and that did leave a little bit of a gap because without the hard shell we're really exposed to kind of three evolutionary challenges number one is misaligned incentives so I don't know how many of those in the room actually have to deal with business stakeholders on a day-to-day basis but on the whole business stakeholders don't put security as their number one objective unless you're a security company most other

companies will not put security as their number one objective they will put as their number one objective improving customer experience um lowering their costs speeding up their time to Market there's a few objectives that quite often come before security so those incentives are something we should be worried about how do we get the incentives to be secure aligned with the incentives of the business to move fast secondly we've got this challenge around rapid and accurate and efficient response and all three of those are really important you can respond really quickly but you might not respond in the right way and it might take you a swarm of 200 people to solve a security Incident That's not

particularly efficient so getting that response really accurate and really efficient is a big Challenge and depends on some some foundations which I'll cover in a minute and then the third one I'll talk about is information asymmetry and for those of you that um have heard of maybe the market for lemons um and this is kind of an economic theory going back to the 1970s which says that the sellers of something know more about their solution than the buyers so it the market for lemons comes from used cars so the seller of used cars knew more about the condition of the cars than the buyers of those cars and the contrast with the market for peaches was because

you didn't know as much about the actual state of the car you could sell a lemon for more than it was worth but you couldn't sell a peach for what it was worth and so the value that a seller was able to or the the incentive for the sellers to sell peaches went down and the market ended up with lemons I'm not saying that all Security Solutions are lemons but I'm saying that there is an information asymmetry there that acts against us it also happens within our organizations we know an awful lot more and thanks to some The Talk this morning we learn an awful lot more about the tactics and the threats posed by cyber

attackers and hopefully we'll always know a little bit more than than the people in the business about that because that's kind of that's our job is to understand that threat and translate that into risk so there's this information asymmetry that we got to get over and as I say evolve will die hope you don't die it's it's just um it's just you'll have suffer some Financial losses so the challenge that I'll cover in this talk is number one is around incentives incentives really equals people and people equals organization so how do we get people aligned on those incentives and feel the accountability to act securely and that's a kind of a trick in itself as well as having the

skills to do that the skills to act securely as well the second bit is around processes or operations and that's where we get into operating models and I'm going to suggest today a few examples of operating models that we've found really useful and give you some kind of um hopefully some useful useful tips on those operating models they aren't this isn't this isn't kind of a recipe that will work for everybody but hopefully there's some operating models that you'll all find useful and maybe helping your communication with with business stakeholders and it stakeholders and people who aren't as Steep and as passionate as about security as we are I'm not going to talk about technology

so if you want to go in deep into network network security and talk about zero trust network access and um and identity security Technologies I love that stuff but today we're going to focus on the people in the process okay so we're going to apply squiddle Evolution to security operating models we as a group are going to decide together whether patch of vulnerability management are an example of exposure agility or intelligence um and as I say technology is different talk so three security operations models um as I say these are kind of three models that have proven useful for us and a way to kind of communicate within our own team and with the teams

that we're working with so that they can understand what our aims are and how we're going about things but essentially exposure squids camouflage again let's not get into the security obscurity thing um it's about minimizing your exposure to cybercity risk so what is the operating model that we use to collaborate with the business and with technology owners to minimize that exposure agility is about threat detection instant response so what do we use for that um for that kind of process and then what do we mean by intelligence and how do we kind of get into the the nuts and bolts of having good good intelligence life cycle so start with exposure the goal here really is both secure by

demand and security by Design um if you if you want to read more about the idea of security by demand or secure by demand and security by Design I really recommend the papers that cesa in the US are publishing on secureity by demand and secureity by Design now they're they're they're talking about it more from A supplier buyer relationship so they're saying this is how you as an organization specify the software that you need a way that is then built to a security standard um really good paper on that very kind of business friendly in its language but also kind of gets into the security bits that we really need to be talking about and then the

second bit which is security by Design is a little bit more um well trodden and well understood but again a really good paper from cesa about how do you go about building software in a secure way from the start now the the operational model that we use for secure by Design and secure secure by demand is a really simple and this I'm sorry this does sound a bit kind of consultancy big four stuff but it it it works in kind of getting everybody on the same page is a plan do check act cycle so from a planning perspective we talk about well what are our expectations what are our policies what are our standards how do

we make sure that the stuff that we put in our policies and standards can actually be built and be adhere to so there's this whole thing of um don't think about security or just don't just imagine Security in your Ivory Tower specify that to a bunch of Engineers and say go on deliver it you have to kind of have that planning um planning exercise together then there's the doing of it so you go off an experiment we need a new we need a new security control whatever that security control is whether it's networks devices applications um email whatever it is we go off an experiment with that control does that control achieve the effect that we're trying to

deliver so you know whether however you measure that Effectiveness you can measure it with um does it mitigate these um threat um tactics techniques and procedures does it meet the regulatory requirement I've got to have for this control um and then you check so you kind of come back and you verify that it's actually done what it's um it's intended to do and then turn that into a control that you hold out across the whole organization and that's kind of a continuous cycle and that's a key bit of just making it a continuous cycle who do we have doing this plan do check Act who do we have leading on it it's our governance risk and compliance team

and our security engineering team so they need to work together on that whole kind of build operate plan do check act cycle by the way I'm going to give you kind of all a um opportunity to kind of Challenge and ask questions on it later and I would really appreciate that the agility so how do we go about responding quickly and accurately presume um quite a lot of you have probably heard of the U Loop so observe Orient decide and act and this is designed around a much more agile Fast Response great feedback loop approach to dealing with complexity in the chaos which can kind of happens in in a in a security incident so the

observe bit the eye in the diagram then feeds into the Orient bit so you you try and gather as much data as possible try and collect as much information as possible about an incident you know who's affected what devices have we got where's the what's the data look like where are the applications what networks it sit on all of that kind of is good contextual information to work out actually do I really have an incident and how material is that incident you then based on all of that information you synthesize it into right I've got some hypotheses around what might have happened go off and prove those hypotheses and that's takes you into the decide we're going this is how we're

going to go about firstly containing the incident and then this is how we're going to go about responding and recovering from it in the future and that's where you get into the ACT piece who do we have looking after this this is our cyber defense operations team um one of them is sat in the room there we go Martin um and you know they they operate on this life cycle pretty much on a daily basis um some of it and like the real key here is how do we automate as much of this as possible how do we kind of get into playbooks talking to that kind of efficiency Point yes we could answer the answer the incident by

getting all 200 people involved in technology on a call but actually it would be a lot more efficient if we just had the five who really knew you know the key things of where the dat is and who's that got access to it and what it looks like has happened to it in our um in our monitoring platforms then the intelligence bit and this is kind of the Crux of the whole talk because if you think about the squid the Squid's not able to kind of change color and blend into their background and not get spotted by Predators it's not able to respond quickly without the intelligence so without that brain that it's developed which came from not having a shell it

would not be able to do the things that we've been talking about in the previous two bits so we talk we look at intelligence from a intelligence life cycle perspective this is a pretty standard one from um kind of UK military talks about it quite a lot first of all you got to direct the intelligence efforts so what is your intelligence requirement namely what's the question that you're trying to answer and we tend to have got pretty set four questions what matters most to our organization and why does it matter so what are our critical economic functions what are the things that if those functions aren't aren't performing or aren't available where do we end up kind of

getting hit in the getting hit in the hit in the pocket or our customers getting impacted you know what are the things that are really critical to the business and then what are the bits that under what are the bits that underpin those critical economic functions what is the data what's the what are the applications and so that's the kind of the what matters most and why once we work out where is that where does this sit on the networks where does it sit in our supply chain how are the how are the controls protected or how are the controls set up around it and as a result of that where are our coverage and our gaps and where are we where are

they're not effective and where might they be in place but not necessarily turned on and configured as they could be so those are kind of really those are the questions that we input into the intelligence life cycle and if you don't have good questions it's like statement the obvious you're not going to get a really good answer out the back of it so that determines what data do we need to go off and collect and the collection is not straightforward sources are all over the place very rarely actually the data sort is sat in security quite often the sources of the data are sat in other bits of the organization it might be business information might be data about

the systems it might be the tech operations or the it operations team that actually has the data um so it's what's the sources of the data and how much how confident can we be and how can we how much can we rely on that data so and quite often we'll have to cross validate to to increase our confidence in the data what it's telling us then we kind of go into the processing bit so how do we look at the look at the data cross correlate work out what really matters what doesn't what's noise what's signal and then we can turn into a a product an intelligence product that we can then send off to the teams that need

it so sometimes those intelligence products are are kind of pretty regular they might be a report for the for the board once a month or once a quarter might be product for the um for the Cyber defense team so that they can add some um add some color and add some more context to their incidents and that could kind of be you know like a 24-hour demand so time Horizons on this kind of stuff is really important and then making sure that it's kind of delivered at PACE and delivered at the Cadence that people can use it's no good giving I don't know chief executive a readout on um on what the systems are telling us

about our our exposure and and where we need to invest our money in in improving our security controls um and coming out and coming up with a whole load of data at the scene so it's it's that kind of what's the time Horizon the chief exx are generally worried about three months ahead 6 months ahead 18 months ahead the incident team are worried about what's happening today and so getting those time Horizons synced up for this intelligence cycle is really important so going a bit deeper on the intelligence bit as I said it's kind of fundamental for for exposure and for um and for agility um and with me kind of prattling on for however long I've been

talking I've not been keeping track um I'd be interested in what operations model you as a group would choose for Paton vulnerability management so maybe a show of hands who would who would choose exposure as the you know the plan do checka cycle for fundability and Patch management anybody would select that we got one there we go who would choose response or agility few more hands and then who would put it in intelligence interesting okay um so we'll talk about that um and then what are the intelligence requirements for incentives and then who leads on intelligence so it's classic it's a security answer it depends so um if the goal is to respond really quick and

accurately we put it in response and we put it in agility because this is like a planet melting vulnerability log 4J treat it like an incident get it into the UDA Loop you're going to have to be operating at PACE working out where this vulnerability sits in in your supply chains and in all of your software so that is if it's a if it's a you know if it's that kind of press the emergency button it goes into the intelligence workflow and becomes part of the ud Loop if it's more of the kind of the operational side and it hygiene type of patch and vulnerability management you want it in in kind of the it operation

space and you want it in kind of the techop space and really there my recommendation for people in security is stay out of it don't get into the details of individual vulnerabilities that should just be part of the it and admins and their teams regularly staying on top of stuff now that doesn't mean you leave them alone if they need if they need help you give them help but broadly or you should really be interested in there is a service level objective are you patching and are you fixing your vulnerabilities within the time scale that we've agreed is a reasonable time scale and you know if you're kind of within 90% of your patch and vulnerability of service level

objectives okay that's probably a fairly healthy number and so you agree that and as long as they're staying within those those guard rails or those bounds we're all good don't make and don't make the mistake of a lot of security which is just going deep deep deep on vulnerability management because your time is better spent elsewhere is the the kind of the tldr of that one who do we have looking at that well if it is an incident then that's a cyber defense operations team one of the things that and maybe this is kind of useful for for those of you um who are wondering what do we do about staying on top of the

exposure piece as I say that's kind of a plan do check act cycle but it's bit more operational than where security Engineers will often be um often be looking so security Engineers are often looking at building security and and security by Design as I say so we've actually stood up in a tax surface management Squad and what they do is look at the more operational sides of keeping the exposure at a at a minimum for the organization so they look right across the piece one day they might be looking at on device or server one another day they might be looking at software vulnerabilities or Cloud misconfigurations so they can kind of switch their skill sets depending on the

the type of infrastructure we're talking about but the idea is there they're an operational team that is helping out other operational teams to build new processes and stay on top of their their it hygiene practices or in pretty mature organizations the techops team might just take care of it and as I say just they just pump then an SLO how they're doing against their service level objective back into the security team um the other key thing that I think is really important is to kind of redefine int Ence and the reason I say that is that threat intelligence has gotten both a kind of a good and a bad name and it is a real enabler when it comes to instant

management enriching detection response and that sort of stuff but that tends to be the angle that is pitched for most threat intelligence and there's a couple of issues with that one threat intelligence providers do not have your context they don't know your business they don't know those four Qui key questions that I said um in the direction piece they don't know where your most important business processes are or the tech supports and the data that supports those those business processes and they don't really know the context for the for the intelligence that they're providing so think of intelligence as both kind of understanding yourself as well as kind of understanding the outside world um and that leads you into more of a

strategic use of of intelligence in my view and we then split that out into two bits so we've got a kind of a a nail the basics bit of of intelligence and that's really what we call our key control indicators so we've got six big risks that we worry about as an organization we're worried about people um performing an insecure action just doing something that that they shouldn't do we're worried about um insecure access people having too much access or bit too much blast radius if a if an account gets compromised we're worried about insecure applications inure insecure infrastructure compromis third parties and detecting responding to to cyber attacks so those are kind of our six big

risks underneath each of those we've just got some nail the basics metrics and that's that really helps us to kind of communicate and close that when I talked about misaligned incentives if you just give a business a really small number of key control indicators they can focus on those if you give them all of the controls in ISO 270002 or you know the 190 whatever it is in CIS or whatever control framework you want to use they're going to get swamped and overwhelmed and they're not really going to know what matters if you give them kind of these key control indicators they can get that this is our minimum this this is essentially our minimum

viable product for security this is this if you and if you put them against the risks this is what the board says we can accept in terms of really measurable things also kind of if you if you phrase it that way as I say insecure infrastructure or insecure applications something that we can do about as a business if you phrase your risks entirely and kind of threats might rant some wear us or they might business email compromise us sometimes boards can feel a little bit helpless okay but what do you want me to do about it I can't do anything to kind of control or influence the behavior of attackers and get into a side conversation about deception but

then I'm definitely taking them down the rabbit hole um bring them back to stuff that they can really control and do something about it's the stuff that we build the stuff that we manage again even like the insecurity actions thing you can't control your behavior of your people you can influence them and you can invest in in helping people to act more securely so those now the basics and then the other bit that we do is we look at how do we start supplying the evidence that security is there and you know pick a control framework as I say ISO 270002 could be any of them how do we start supplying the evidence that those controls got

good coverage and are effective on a much more continuous basis and that's kind of a key pit bit of this kind of intelligence cycle is making that more continuous we're we're kind of at the beginnings of um of what a few people have called GRC engineering sets a few people's teeth on edge because people like to think well I'm either an engineer or I'm in governance risk and compliance this is kind of this hybrid this hybrid thing now of the technology can start telling that story around governance and risk and compliance and how and policy is C you might have heard policy of code you might have heard a whole other ways a whole load of other ways that the

technology can start providing machine readable evidence that security controls are there and so GRC engineering is kind of this this a term to look at have we put those have we put the policy in code have we got the security that we said we we say we need and can we provide that evidence in a really machine readable way rather than having armies of people walking around the business asking questionnaires taking up everybody's time with with security assessments this is the bit I'm just not going to do justice because Christine's way better than me and kind of she talks about this from firsthand experience so just pretend I'm a business intelligence person who has joined a security team

she's she's given us a few gotchas here and this is kind of key for your for your day to people you're in security now don't cut Corners I love that she put that one down first um security rarely own the data sources so building those relationships with the people who own the data and making sure those that kind of collection plan is really well described and you have some confidence in it is really key um if you put in another thing which I thought was super interesting is quite a lot of security tools would present a dashboard or have some sort of user interface which is really useful um but the API will serve up

completely different data it's almost like the security vendors look at the dashboard and say the person reading this doesn't understand security so I'm going to give them a real really good good Contex really kind of good in-depth view of of of what this tool is telling us but the PE person reading the API is a security person doesn't need that kind of rapper and that's actually not always the case because as I say we've got data engineers and data analysts in here so I think that was an interesting piece partnering is really critical and making sure that you're managing up and across the business and and with everybody that's all of the stakeholders top tips

let the data lead the way build mutual respect and Trust don't use the data to beat teams up make sure that that's a mutual thing um and nip the the kind of the data is wrong in the bud the first reaction to data is quite often to go question the data quality if if you view it as a collaborative thing that you're building that data picture together that's less likely to happen and also even if it does happen you've both then got a stake in in fixing it so in summary it's inevitable boundaries have dissolved we don't have our shells um uh for some of us you could join and present I'm I'm not speaking from experience here definitely

um there is no security uh before the security team arrives um but you have to bear in mind the reason why businesses are doing this and they're doing it to collaborate more to integrate better with their Partners move faster all of that kind of good stuff hopefully I've convinced you that a squid analogy kind of works and maybe is a way to talk to your business stakeholders and and your own security folks about something which previously as I say zero trust is quite technology oriented thank you very much as I say credits to my team thank you yeah absolutely the rest day y we got two minutes so [Music] um as a more technical uh minded person

um I'm wondering how the collaboration between businesses on an uh intelligence sharing uh way works do do you have like ironcloud contracts or they Define what you can and cannot give out it really depends on the industry vertical in my experience so like the sector some sectors have a really mature your ecosystem when it comes to intelligence sharing so fsis Zac is quite a famous example Financial Services has an information sharing body where those contracts are quite well established and are quite explicit other Industries it's what'sapp so it does really vary on your organization and the and the vertical you're in what I would say my experience of kind of that intelligence sharing yes it's things like who's attacking us and

what are the ttps and all that sort of stuff but it's also about how it's it's great to share intelligence about how youve solve security problems and quite often that's less about a contractual agreement and ndas and all that sort of stuff and it's actually just security peers talking to each other this event is great for stuff like that so I think combination of the formal contracted and informal is is my kind of answer to that one I think all right thank you

[Music]

uh so how you said it's very important to share the solutions that you found to security problems how do you share the solution without giving away those uh four core uh questions that you need to figure out about your company because a solution isn't going to mean as much without the context like you say how how do you strike the balance uh between giving too much away and not giving enough away I think we we often overstate how secret are secret sources you know as Defenders so um I will I I kind of I'll give you two examples one there is a there's a whole bunch of Frameworks out there around mitro attack if you've heard of it and

mitro attack then has MIT to defend what are the what are the ways that you can defend against those attack tactics the miter defend can can map to control Frameworks and those control Frameworks can then map to Security Solutions quite often internal team would have built that logic of ttps all the way down to solution none of that is particularly secret Source it's hard work and it kind of is personal kind of intellectual property but there's no real reason we can't share that more openly and go into kind of Open Source around that kind of logic that I think provides a whole load of value to the community there's there's another kind of example that I'd

use of quite often when you're looking at control um uh reporting and controls monitoring your problem is what's your denominator let's take devices how many devices do I have in an organization unbelievably hard questions to to answer for large organizations and how many of those devices have got EDR on it have got scanned for vulnerabilities are within patching policy that is a data problem how you go around go about solving that data problem using the plan do check C cycle again is something that I can share pretty freely without worrying about um sharing any kind of particular vulnerabilities of our organization right thank you nice one and so let's put our hands together again and thanks