Embedded Files
Beyond the Cable: Resilience in the Shift from Infrastructure to Culture
Beyond the Cable: Resilience in the Shift from Infrastructure to Culture
It’s not just the new kids on the block that need a helping hand to get started, get momentum, or find their balance. I’ve been struck more and more recently by how cloud migration, change management in IT, and the shift from Waterfall to Agile is not actually dependent on the technology, products, or platforms — but on a deeper cultural shift within organisations.
We’re moving from environments where expertise was built on physical systems — coax, cabling, server rooms, on-prem infrastructure — to cloud ecosystems where those physical touchpoints disappear entirely. Cloud providers will never step inside most organisations’ data centres, because there often aren’t any anymore. Even the idea of “knowing where things are” has fundamentally changed.
For many experienced engineers, that shift can feel unsettling. It can look like redundancy — like the skills that once defined your value are no longer needed. There’s no longer a need to carry pliers around the office if your entire environment now exists as code, APIs, and managed services. So the question becomes: where is your place now? How do you find your next step in an industry that is moving this fast?
This is where Agile thinking starts to matter in a more meaningful way. Not just as a delivery methodology, but as a mechanism for exploration. Creating a spike to understand dependencies in a data migration project, or experimenting with how cloud-native data platforms are structured, becomes a way of rebuilding confidence and context. Setting up cloud environments, working with infrastructure-as-code, or experimenting with services like identity platforms, data pipelines, or serverless functions are often the first practical steps back into relevance.
In larger organisations, there is often support in the form of technical advocates or enablement teams who can guide engineers through those early stages of transformation. But even with that support, the real shift happens when people engage with the change itself — not just as a project requirement, but as a personal evolution in how they work.
For me, it helped to actively explore. Attending conferences, listening to how others approached migration journeys, and understanding what actually worked in practice versus what looked good on paper. There is real value in seeing how different organisations solve the same underlying problems in different ways.
It also becomes important to play with the technology directly. Not in a production sense, but in a safe, experimental way. Setting up data structures, provisioning infrastructure through code, deploying small services, or experimenting with identity and security tooling. These are no longer heavyweight exercises — most of this can now be done in virtual environments, often quickly and at low or no cost. They become “taster environments” for learning, without the pressure of production responsibility.
Because ultimately, it’s not access to technology that is the barrier anymore. It’s not even training — the resources are everywhere. The real challenge is mindset. The cultural shift in how we see ourselves inside these systems, and how we adapt when those systems no longer look like the ones we built our careers on.
That shift is particularly hard when it happens at scale — when entire teams, deeply embedded in legacy systems, are expected to move together. It’s not just a technical migration; it’s a human one. And that’s where leadership, patience, and structured change become just as important as any architecture or platform decision.
Because in the end, resilience isn’t just about systems staying up. It’s about people being able to move with them.
OPERATIONAL RESILIENCE
OPERATIONAL RESILIENCE
Designing and strengthening organisations to maintain continuity, stability, and performance under disruption.
You've been brought into a new Security Function, you're faced with a vulnerabilities backlog expanding 4 years and running in the thousands. It's more than tempting to throw your army of security engineers or cloud platform engineers at critical CVSS scores. The burning question is, will this actually improve your security in reality.
What are you trying to achieve. Companies are often chasing the remediation of CVSS critical scores, like a race against the clock, trying to reduce backlog numbers while new vulnerabilities keep appearing in your environment.
There are a few critical questions to consider here before allocating all your resources in chasing down and planning remediation work. Firstly, how to stop the catastrophic bleed of vulnerabilities entering your systems. For OS vulnerabilities, templated golden image builds using Packer with Ansilbe/Chef/Puppet means teams can build VM's and OS with ease, in an immutable consistent approach and have the essential security controls or agents deployed on every built image. Combining this with a CIS hardened image goes even further to ensure compliance with standards that will satisfy your Auditors and Insurers.
So you can shift your security left, even at the OS level, to reduce vulnerabilities deployed into your environments. You're stemming the bleed, but you still have that backlog, so what should you tackle first - the obvious answer is the most critical risks, but what are they? Most companies default to the CVSS scores, and it's worth asking the question 'Why?' before following the crowd.
This opens up a much deeper debate, and perhaps one that needs to start at industry level with the Insurance Companies, the regulators and the auditors. Are CVSS scores the most accurate way to address risks to our business? Are there better algorithms, or combinations of different approaches can better guide us on allocating the scare resourcing we have, to where it will make the biggest impact.
Vulnerabilities can easily become a tick list, insurance companies requirements for 90% Critical Vulnerabilities to be remediated within 3 days or 5 days etc, these targets don't account for which environment these vulnerabilities exist in or what complimentary controls you have in place. Sure, it's an easy green, amber, red system and the biggest vulnerability repo's in the world using CVSS is run by NIST, so it's the dominant 'trusted' tooling. It's familiar, it's known, it simple to use. But does it really address risk in your business?
Should or rather, Can we start moving the industry towards Risk-Based Vulnerability management?
When looking for a sweet spot, I think we need to combine our datasets, what we know about our individual companies can help shape our responses.
Assets Inventories allow us to hone our resources around the critical assets, these hold most risk, so why not bring these into the scoring system, include this as a core part of understanding where risk sits in your business.
Enrich your scoring system by including other aggregating methods, EPSS etc. How do you measure the vulnerability against your complimentary control in place. How do you assess the network layer security controls in place, how does this affect the overall risk score. Move away from looking at vulnerabilities in isolation, and start to understand them as part of Risk, with the added value of CONTEXT!...
Context. There is increasing research to show that a patching strategy using CVSS scores is not better than random patching. So what are the alternatives, and can you use them without being penalised by Cyber Insurance companies using CVSS, or Auditors that aren't familiar with them?
Combine your ISAC data feeds with understanding what current Risks are, how are they trending, what impacts does this have on your environment and particular vulnerabilities. Look at your vulnerabilities alongside Risk assessments, combine a rating system of your assets. Use the EPSS as another predictive scoring system, it's not perfect, but it beats the solo use of CVSS, it's a start.
Have open conversations with your insurers, talk to them about why using this metric doesn't have risk reducing impacts on the whole, point them towards the research and Push the industry to move faster in a direction that encourages us to resource the RIGHT threats and risks.
Page updated
Google Sites
Report abuse