{
  "version": "https://jsonfeed.org/version/1.1",
  "title": "Dave Ferguson — Advice from the first line",
  "home_page_url": "https://daveferguson.blog",
  "feed_url": "https://daveferguson.blog/feed.json",
  "description": "Notes on cyber security from someone who has to make it work. Vulnerability management, AI, supply chain risk, and the economics of attack and defence.",
  "authors": [
    {
      "name": "Dave Ferguson",
      "url": "https://www.linkedin.com/in/daveferguson01/"
    }
  ],
  "language": "en-GB",
  "items": [
    {
      "id": "https://daveferguson.blog/how-ai-breaks-everything-we-know-about-cyber-economics",
      "url": "https://daveferguson.blog/how-ai-breaks-everything-we-know-about-cyber-economics",
      "title": "How AI Breaks Everything We Know About Cyber Economics",
      "summary": "AI is simultaneously crashing the cost of building security controls AND the cost of attacking. Both curves are approaching zero. The winner won't be whoever spends the most, it'll be whoever moves the fastest. Here's why that changes everything about how we justify, fund, and deliver security.",
      "content_text": "I've been thinking a lot about economics lately. Not the boring kind with GDP and interest rates, but the kind that actually affects my day job, the economics of attacking and defending.\n\nFor as long as I've been in security, there's been a fairly stable economic model. Controls cost money to build and maintain. Attacks cost money to develop and execute. Your job as a defender was to make attacking you more expensive than attacking the person next door. Harsh, but that's how it worked.\n\nAI is breaking this model. Completely.\n\n## The old maths\n\nLet me paint the picture of how security economics has worked for the past two decades.\n\nYou want to implement multi-factor authentication across your organisation. That'll cost you licensing, integration work, support staff, user training, and an endless parade of \"I've lost my token\" tickets. Call it six figures for a mid-sized organisation, conservatively.\n\nYou want to build a detection capability for lateral movement. You need a SIEM, log sources, detection rules, analysts to monitor it, and a process to respond to alerts. Another six figures, probably seven.\n\nOn the attack side, building teams, developing tooling and farming exploits has a cost. Running a sustained campaign against a well-defended target was expensive. This meant attackers had to be selective. They couldn't afford to attack everyone, so they went after the easiest targets first.\n\nThe strategic implication was clear: raise the cost of attacking your organisation above the expected return for the attacker, and you'd be left alone. \n\nSecurity economics 101.\n\n## Both curves are collapsing\n\nHere's what's happening now, and why it matters.\n\n**On the defence side**, AI is making everything cheaper:\n- Writing detection rules? AI can generate and test them in minutes, not days.\n- Vulnerability scanning? AI finds things that have been latent in codebases for years.\n- Security tooling? What used to require a team of engineers to build can now be prototyped in an afternoon.\n- Incident response? AI can triage, investigate, and even remediate certain categories of incident faster than any human.\n\nThis sounds great. And it is great. The backlog of \"security improvements we know we need but can't afford to build\" is being cleared at an astonishing rate.\n\n**But on the attack side**, the same thing is happening:\n- It's now easier to become an attacker, to find and develop exploits. AI lowers the skill barrier dramatically.\n- Phishing campaigns that used to require human effort to personalise can now be crafted at scale with perfect grammar and context.\n- Voice cloning, deepfake video, synthetic identities. All approaching commodity pricing.\n- Vulnerability discovery isn't just faster for defenders. Attackers are finding the same vulnerabilities, and they don't have change boards to slow them down.\n\nBoth cost curves are approaching zero. But they're not collapsing symmetrically.\n\n## The asymmetry problem\n\nThis is the bit that keeps me up at night.\n\nDefenders benefit most from cheaper *routine* activities: patching, monitoring, configuration management, log analysis. Yes, it's security hygiene again! These are the \"boring but essential\" tasks that have always been the backbone of good security. Attackers benefit most from cheaper *novel* activities: finding vulnerabilities, crafting attack chains, creating convincing fakes. \n\nWhen everything is cheap, the advantage goes to whoever can exploit novelty faster. And right now, that favours attackers. They don't need to submit change requests. They don't need to test in staging. They don't need to write a business case.\n\nI was chatting with a penetration tester last month who told me his team's AI-augmented workflow had cut their average time to initial compromise by about 80%. \n\n## Things that change\n\nIf the old game was \"reduce the cost of controls to deploy more per pound spent,\" the new game is fundamentally different. Here's what shifts:\n\n### 1. The constraint moves from budget to speed\n\nWhen controls are cheap to build, the bottleneck isn't money, it's how fast you can deploy them. The organisation that can discover a vulnerability, develop a fix, test it, and push it to production in hours will massively outperform the one that takes weeks, regardless of how much either spends.\n\nThis has practical implications. All those change boards, approval chains, and deployment windows? They need rethinking. Not eliminating, that would be reckless. But fundamentally accelerating.\n\n### 2. Validation becomes more important than implementation\n\nWhen AI can generate and deploy a control in minutes, how do you know it actually works? How do you know it doesn't have unintended side effects? Does by business still function as I would expect? How do you know it'll hold up against a real attacker?\n\n### 3. Complexity becomes the real enemy\n\nEvery system, every service, every connection point in your environment is something an attacker can probe at near-zero cost. In the old world, complexity was a nuisance. In the new world, it's an existential risk.\n\nThe organisations that will win are the ones with simpler, more modern architectures. Fewer systems, less heterogeneity, smaller blast radius. Every bit of technical debt you're carrying just got more expensive in risk terms, even as it got cheaper to fix.\n\n### 4. Headcount loses to leverage\n\nA team of 10 people who can effectively orchestrate AI-augmented security tools will outperform a team of 100 doing manual work. The skills that matter shift from \"can you write a detection rule\" to \"can you design a system that writes, tests, and deploys detection rules automatically.\"\n\nIf you're building a security team right now, hire for judgment, architectural thinking, and the ability to validate automated outputs. The hands-on-keyboard skills are being commoditised whether we like it or not.\n\n## Can you adapt, at pace, in a safe way?\n\nWe're living through a phase change in the economics of security. Both attack and defence are becoming dramatically cheaper, but the strategic implications are asymmetric. Speed matters more than budget. Validation matters more than implementation. Simplicity matters more than comprehensiveness.\n\nThe organisations that invested in modern architectures, fast deployment pipelines, and automation-first cultures are about to see those investments compound dramatically. The ones still running legacy environments with manual processes are about to find the gap between themselves and both mature organisations and increasingly capable attackers widening at an alarming rate.\n\nThe good news? Fixing things just got cheaper too. The bad news? So did breaking them.\n\nStart moving faster. It's the only competitive advantage that matters now.",
      "date_published": "2026-04-05T00:00:00.000Z",
      "date_modified": "2026-04-05T00:00:00.000Z",
      "tags": [
        "AI",
        "Agentic AI Security",
        "AI Agent Governance",
        "Agentic AI Risks",
        "AI Identity Management",
        "Shadow AI",
        "AI Privilege Management",
        "CISO Guide Agentic AI",
        "Enterprise AI Control Plane",
        "AI Observability",
        "AI Agent Accountability",
        "AI Governance Framework",
        "Machine Identity",
        "Non-Human Identity",
        "Autonomous AI Risk",
        "Cybersecurity Leadership"
      ]
    },
    {
      "id": "https://daveferguson.blog/agentic-ai-governance-practical-guide",
      "url": "https://daveferguson.blog/agentic-ai-governance-practical-guide",
      "title": "A No-Nonsense Guide to Governing AI Agents in Your Organisation",
      "summary": "AI agents are being deployed across your organisation without governance. Here's a practical 5-step framework for identity, privileges, and accountability.",
      "content_text": "The year is 2010 and AWS cloud is all the rage:\n* Everyone says they're doing it,\n* Few really are,\n* And those that are, are not doing it well!\n\nNow lets fast forward to the year 2026 and it's the same story, but with AI Agents...\n\n---\n\nI had a conversation recently with a security engineer who casually mentioned their development team had deployed \"a few AI agents\" to handle code reviews and ticket triage. When I asked how many, he said \"maybe twelve.\" When I asked what access they had, he went quiet. When I asked who was responsible for them, he went quieter.\n\nThis is the state of agentic AI governance in most organisations right now. And honestly? It reminds me of the early days of cloud adoption. Everyone was spinning up instances, nobody was tracking them, and security was playing catch-up for years. Except this time, the things we're deploying can make autonomous decisions. So, you know, no pressure.\n\n## What are AI agents and why should you care?\n\nLet's cut through the hype for a moment. An AI agent, in practical terms, is a piece of software that **can take actions on behalf of a user or a process** without someone explicitly telling it what to do at each step. It observes, decides, and acts. That might be triaging support tickets, writing and deploying code, processing invoices, or interacting with other agents.\n\nThe difference between an AI agent and a traditional automation script is judgment. A script does what you told it. An agent decides what to do based on context. That distinction matters enormously from a security perspective because it means you can't predict exactly what it will do in every situation.\n\nGartner reckons 33% of enterprise applications will include agentic AI by 2028. From what I'm seeing on the ground, that feels conservative. \n\n## The governance problem in plain English\n\nHere's the fundamental issue: we've spent decades building identity and access management frameworks for humans. We know how to onboard a person, give them appropriate access, monitor what they do, and revoke their access when they leave. It's not perfect, but there's a playbook.\n\nFor AI agents? Most organisations are winging it. And the risks are real:\n\n- **Privilege creep on steroids.** An agent deployed to \"help with admin tasks\" gradually accumulates access to systems it was never intended to touch. Unlike a human, it won't question why it suddenly has access to the finance database.\n- **Shadow agents.** Teams deploy agents without telling security. Sound familiar? It's shadow IT all over again, but with autonomous decision-making capabilities.\n- **Emergent behaviour.** When multiple agents interact, they can produce outcomes nobody predicted or intended. This isn't science fiction, it's happening now in organisations with interconnected automation.\n- **Accountability gaps.** When an agent makes a decision that causes a breach or a compliance violation, who's responsible? The developer who built it? The team that deployed it? The vendor who provided the model?\n\n## A practical governance framework\n\nI'm not going to give you a 47-page policy document. Instead, here are the five things you actually need to get right, in order of priority.\n\n### 1. Treat every agent as an identity\n\nThis is the non-negotiable starting point. Every AI agent in your environment needs a formal identity, just like every employee and every service account. That means:\n\n- A unique identifier tied to a specific purpose\n- A documented owner (a human, not another agent)\n- A classification of what it's allowed to do and what data it can access\n- A lifecycle: creation, review, modification, decommissioning\n\nIf you can't tell me how many AI agents are running in your environment right now, who owns them, and what access they have, then you have rogue undocumented employees within your company.\n\n### 2. Scope privileges like you mean it\n\nLeast privilege isn't a new concept, but applying it to AI agents requires a different mindset. Humans have roles that are relatively stable. Agents have tasks that can be dynamic and context-dependent.\n\nThe approach I'd recommend:\n\n- **Start with zero access.** Agents get nothing by default.\n- **Define action boundaries, not just data boundaries.** It's not enough to say an agent can access the CRM. You need to specify what operations it can perform. Can it read? Write? Delete? Export?\n- **Set blast radius limits.** What's the maximum damage this agent could do in a given time window? If it goes rogue, what's the worst-case scenario? Design constraints around that.\n- **Implement rate limiting.** An agent that suddenly starts making 10,000 API calls when it normally makes 100 is either broken or compromised. Either way, you want to catch it.\n\n### 3. Build observability from day one\n\nYou cannot govern what you cannot see. This sounds obvious, but most organisations deploying AI agents have minimal logging of what those agents are actually doing.\n\nYou need:\n\n- **Decision logging.** Not just what the agent did, but why it decided to do it. The reasoning chain matters for incident investigation and compliance.\n- **Interaction tracking.** When agents communicate with other agents or systems, log those interactions. Agent-to-agent conversations can produce unexpected outcomes.\n- **Anomaly detection.** Baseline what normal behaviour looks like for each agent and alert on deviations. This is your canary in the coal mine.\n- **Regular reviews.** Just as you'd review user access periodically, review agent access and behaviour. Are they still doing what they were deployed to do? Have they drifted?\n\n### 4. Establish an agent control plane\n\nThink of this as the central nervous system for governing AI agents across your organisation. It doesn't have to be a single product, it's more of a capability. The control plane should give you:\n\n- **A registry of all agents**: What they are, where they run, who owns them, what they're authorised to do\n- **Policy enforcement**: The ability to set and enforce rules across all agents consistently\n- **Kill switches**: The ability to immediately suspend any agent if something goes wrong\n- **Audit trails**: A complete record of agent actions for compliance and investigation\n\nIf this sounds a lot like what we built for cloud governance, you're right. The patterns are remarkably similar. The difference is the speed at which things can go wrong.\n\n### 5. Define accountability before you need it\n\nWhen (not if) an AI agent causes an incident, you don't want to be figuring out accountability on the fly. Define it now:\n\n- The **deploying team** is responsible for the agent's configuration and scope\n- The **model provider** is responsible for the model's behaviour within its stated capabilities\n- **Security** is responsible for the governance framework and monitoring\n- **Executive leadership** is responsible for the risk appetite decisions around AI agent deployment\n\nDocument this. Get sign-off. Because when something goes sideways at 2am, you don't want to be having a philosophical debate about who owns the problem.\n\n## The uncomfortable truth about speed\n\nHere's what makes this genuinely difficult. The whole point of AI agents is speed and autonomy. Every governance control you add creates friction. And the business teams deploying agents are doing so precisely because they want to move faster.\n\nThis is the same tension we've always navigated in security. Enabling the business while managing risk. But the stakes feel higher because the technology is more capable and less predictable than what we've dealt with before.\n\nMy advice? Don't try to boil the ocean. Start with a simple agent registry. Get visibility. Then layer on controls based on risk. The organisation deploying agents to summarise meeting notes needs a different governance approach than the one deploying agents to approve financial transactions.\n\n## Questions to ask yourself\n\nIf you take nothing else from this article, go back to your organisation and ask these questions:\n\n- How many AI agents are currently operating in our environment?\n- Who owns each one?\n- What access does each one have, and is it the minimum required?\n- What happens if one goes rogue at 3am on a Saturday?\n- Who is accountable when an agent makes a bad decision?\n\nIf you can answer all five confidently, you're ahead of most. If you can't, you've got some work to do.\n\nThe agents are already here. The question is whether you're governing them, or they're governing you.",
      "date_published": "2026-03-29T00:00:00.000Z",
      "date_modified": "2026-03-29T00:00:00.000Z",
      "tags": [
        "AI",
        "Agentic AI Security",
        "AI Agent Governance",
        "Agentic AI Risks",
        "AI Identity Management",
        "Shadow AI",
        "AI Privilege Management",
        "CISO Guide Agentic AI",
        "Enterprise AI Control Plane",
        "AI Observability",
        "AI Agent Accountability",
        "AI Governance Framework",
        "Machine Identity",
        "Non-Human Identity",
        "Autonomous AI Risk",
        "Cybersecurity Leadership"
      ]
    },
    {
      "id": "https://daveferguson.blog/how-i-manage-my-tasks-in-cyber-security",
      "url": "https://daveferguson.blog/how-i-manage-my-tasks-in-cyber-security",
      "title": "How I manage my tasks in Cyber Security",
      "summary": "The blog focuses on effective time management within the cybersecurity industry. It highlights the importance of prioritization as a skill and introduces a weekly planning strategy, centered around a mission statement. The author categorizes tasks into three groups: those that could lead to termination, those that could lead to promotion, and volunteering tasks. Emphasis is placed on the ability to say no and the value of task delegation, recognizing tasks that are unique to one's skills. The article aims to guide professionals in managing overwhelming workloads by aligning tasks with organizational goals and personal growth.",
      "content_text": "Prioritization is a skill I was forced to develop.\n\nThe cyber security industry has a horrible habit of overwhelming people. It can feel like you’re constantly drowning in a sea of emails, messages, and tasks.\n\nI don’t claim to be a guru on this topic, but I’ve discussed my approach to time management with a couple of people, and they’ve found it useful. So, I thought I would share it more widely.\n\n> I've found if you take 30 minutes each week to plan your activities against what you want to achieve, you’ll be amazed at the results.\n\n \n\n![A blank three-column table under the heading \"Mission statement\", the columns labelled 1st \"Get me fired\", 2nd \"Get me promoted\", 3rd \"Volunteering\"](https://imagedelivery.net/QDjDXYt6u3RXENRp4Vk9rw/70adc22f-520b-4616-3f03-caea021dab00/public)\n\nI start by reminding myself of the “mission statement”. This could be for the organization, the department, or the team. It should be easily understood and is the guiding star (or goal) for all your activities!\n\nBefore you agree to do anything, ask yourself one question: **Does this activity contribute towards the mission statement? If the answer is no, it must be placed in the “volunteering” column**.\n\n> Learning to say NO is an important skill. Not all tasks should be done, and not all tasks should be done by you.\n\nWhen planning, I have 3 columns of tasks. I break them into: **what’s going to get me fired, what’s going to get me promoted,** and finally, **volunteering time.**\n\nI know, it's very odd, but it works for me 😄\n\n## Tasks that are going to get me fired\n\nThese are the most mission-critical tasks (the reason the day job exists). If they didn’t happen or were done poorly, it would be damaging to the organization/my reputation and could lead to me losing my job.\n\nThis typically takes between 70% to 110% of my weekly availability. These are the tasks that would require overtime and cause other tasks to be paused. It’s the core part of the job, and some weeks are better than others.\n\nThe point is these tasks take priority over all other tasks!\n\nI think about department vision, finances, people management, critical vulnerabilities, and incidents but a Security Engineer would have very different tasks on their “get me fired” list.\n\n## Tasks that are going to get me promoted\n\nThese are the tasks that you know will make the organization, department, and yourself better. They’re the operational or capital efficiencies you’ve been waiting to test out, the relationships you want to strengthen, or the education/growth you’ve been waiting to apply.\n\nAll tasks under the \"get me promoted\" column must align with your mission statement.\n\nThis is about you doing amazing things above and beyond the regular day job and **getting the exposure for it!**\n\n## Volunteering time:\n\nLife will give you allot of side quests. Volunteering time is **ANY** task that does not directly contribute towards your mission statement. If you do this properly, you’ll be amazed at how many things you complete within a week that do not directly benefit your job role or your promotion prospects.\n\nGiveback is good, and volunteering is a valuable part of your weekly routine.\n\nI highlight it as you need to find the balance right. You’re empowered to define your ratios between the 3 columns.\n\n## Finally, use task delegation.\n\nOne of the hard lessons managers and leaders need to learn is task delegation.\n\nI did, and still do find it difficult at times. In my mind, I could do the task quicker and better, so why delegate? It seems inefficient.\n\nThe reality is, that you rob yourself and others of growth experiences.\n\nYes, it will take longer to train someone, but once it’s complete,  they've benefited and you get that time back to apply your skillset **on tasks only you can do**. \n\nThe last and final lens I apply to all the tasks on the list is: **what are the tasks that only I can do?**\n\n**In theory, all other tasks could and should be delegated**.",
      "date_published": "2024-03-11T00:00:00.000Z",
      "date_modified": "2024-03-11T00:00:00.000Z",
      "tags": [
        "Ways of working",
        "Cyber Security Management",
        "Time Management Skills",
        "Effective Prioritization"
      ]
    },
    {
      "id": "https://daveferguson.blog/finding-the-best-cyber-security-initiatives-for-your-organisation",
      "url": "https://daveferguson.blog/finding-the-best-cyber-security-initiatives-for-your-organisation",
      "title": "Finding the Best Cyber Security Initiatives for Your Organisation",
      "summary": "Gain essential insights on choosing and implementing effective cyber security initiatives. This guide covers balancing limited resources with stakeholder engagement and the evolving threat landscape. Discover methods to measure ROI, tackle implementation challenges, and adapt to emerging cyber threats, ensuring your organisation's security aligns with its mission and operational needs. Ideal for enhancing your organisation's cyber security posture efficiently.",
      "content_text": "Cyber Security is a world full of compromises.\n\nYou rarely have enough resources to implement a gold standard. Even if you did have unlimited resources, I’ve found departments have an optimum capital deployment rate, dependent on stakeholder engagement and the organisation's metabolism. If you try implementing change quicker than the environment allows, you quickly hit a diminishing returns curve where each pound deployed has a reduced effect on your end goal of risk reduction.\n\nBecause of these factors, we must be strategic when picking new security initiatives.\n\n> We need to make sure we get the best bang for our buck!\n\nThe topic of which initiatives yield the best return on investment (ROI) could easily fill a book. However, at a high level, and a minimum, I believe all initiatives should confidently sit in the middle of this Venn diagram:\n\n![A three-circle Venn diagram labelled Threat Landscape, Organisation's Mission and Organisation's Security Posture, with ROI at the centre where all three overlap](https://imagedelivery.net/QDjDXYt6u3RXENRp4Vk9rw/b1112ed9-3b41-47fe-e117-df4a9f03c700/public)\n\n- **Threat Landscape**: What are the **real threats** affecting your industry? All investment decisions must be intelligence-led, based on the challenges you’re likely to face.\n- **Organisation’s Security Posture**: An honest appreciation of your control effectiveness against your threat landscape. Use industry frameworks like NIST, leverage external benchmarks, and continuously validate your assumptions. You need to i**dentify what security controls are lacking or ineffective against today’s threats**.\n- **Organisation’s Mission Statement**: Why does your organisation exist? I would argue that **if you don’t know how your organisation makes a pound, you don’t know how to secure it!** Executives balance Risk against Revenue generation and Operational Cost. Your job is to enable that!\n\n> Remember: Nearly 90% of all cyber-attacks are not the result of elite hackers, but opportunistic cybercrime gangs taking advantage of failures in an organisation's patching, configuration, or authentication posture. Your initiatives don’t need to be fancy; they need to make a difference.\n\nIf your initiative only ticks the Threat Landscape box, it’s likely great for storytelling but has no real relevance to the organisation. If it only bolsters the Security Posture without considering the organisation's needs or the real threats, it’s likely a passion project that won’t move any meaningful needles. Finally, if it only ticks the Mission Statement box, you’re likely a ‘yes person’ avoiding those difficult risk and control conversations with your board.\n\n## A simple example for illustrative purposes: Network Segregation\n\nIf my initiative was to propose network segregation for critical services and the business doesn’t understand the ask, you will get a lot of pushback. From their perspective, you’re asking to invest resources to make the user experience more complicated. Why should they use a jump box and 2-factor authentication to access internal services when today’s solution has always worked?\n\nIt’s a fair question, and to gain their buy-in, we need them to:\n\n- Understand why we’re asking for the change.\n- Appreciate that the ask is proportional.\n- Care about the outcome we’re trying to achieve.\n\nThis same model allows us to explain how the risk to the organisation mission has materially changed.\n\nA **new criminal is actively taking advantage** of **network architectures which resemble ours** to **compromise Banking Services**. We’ve seen this with the Bank of Bangladesh, where $88 million was stolen because the network architecture lacked the layers of control needed to protect a system of that criticality. We believe the proportional mitigation controls are X, Y, & Z.\n\nYour initiative is much easier to justify when it meets the model's test.\n\n![The model applied to a real case: the Lazarus crime group uses flat networks to compromise banking services, and beneath it the Bank of Bangladesh had a flat network which helped enable $88 million being stolen](https://imagedelivery.net/QDjDXYt6u3RXENRp4Vk9rw/b88438f5-a328-4497-efbf-0612913a7b00/public)\n\n \n\nThere will be some outliers to this rule such as projects which focus on providing opex or capex efficiencies. However, as a litmus test for all new initiatives, I’ve found it invaluable when all 3 align. Plus, as demonstrated it’s a great model for Cyber and other stakeholders to talk through **why** different initiatives will impact the organisation positively.\n\nBeyond the model, think about how you could further enhance the overall deliverables by factoring in the Pareto Principle, and most importantly, the human factor.\n\nSimples.\n\n \n\n \n\n---\n\n \n\n### FAQs Based on the article\n\n**Q: How can an organisation effectively address the challenges that arise during the implementation of these cyber security initiatives, especially in environments resistant to change or with limited technical expertise?**\n\nA: Addressing implementation challenges requires a multifaceted approach. Firstly, education and awareness are key. Providing training and clear communication about the importance and benefits of the initiatives can help alleviate resistance. For those with limited technical expertise, it’s crucial to simplify the concepts and relate them to everyday impacts. Additionally, involving all levels of staff in the planning and implementation process can foster a sense of ownership and ease the transition. It’s also beneficial to start with small, manageable changes to build confidence and demonstrate value before scaling up.\n\n**Q: What specific metrics or methods can be used to measure the return on investment (ROI) and overall effectiveness of different cyber security initiatives, ensuring that they are not just cost-effective but also truly enhance security?**\n\nA: Measuring ROI in cyber security can be challenging, but it's not impossible. Key metrics include the reduction in the number of security incidents, the response time to incidents, and the cost savings from avoiding potential breaches. Additionally, benchmarking against industry standards can provide a comparative measure of effectiveness. Regular security audits and penetration testing can also offer insights into the robustness of your security posture. It's important to balance quantitative metrics, like cost savings, with qualitative ones, like improved employee security awareness.\n\n**Q: How should an organisation adapt its cyber security strategy to rapidly evolving and emerging threats, especially when facing sophisticated cyber-attacks that might not be covered by traditional security measures and frameworks?**\n\nA: To adapt to evolving threats, organisations need to adopt a proactive and dynamic approach to cyber security. This involves staying informed about the latest threats and trends, which can be achieved through intelligence sharing platforms and industry collaborations. Regularly updating and testing your security infrastructure is crucial. Incorporating advanced technologies like AI and machine learning can help in identifying and responding to new threats more quickly. Finally, it’s important to have a flexible incident response plan that can be adapted to different types of cyber threats.",
      "date_published": "2024-03-01T00:00:00.000Z",
      "date_modified": "2024-03-01T00:00:00.000Z",
      "tags": [
        "Strategy",
        "Cyber Security Initiatives",
        "ROI in Cyber Security",
        "Implementation Challenges",
        "Threat Landscape Adaptation",
        "Organisational Security Posture"
      ]
    },
    {
      "id": "https://daveferguson.blog/simplifying-cyber-supply-chain-risk",
      "url": "https://daveferguson.blog/simplifying-cyber-supply-chain-risk",
      "title": "No Bullsh*t Approach To Simplifying Cyber Supply Chain Risk",
      "summary": "Pick high-quality suppliers but don’t blindly trust them. Assume your supply chain will be directly to indirectly compromised. It’s about resilient processes, not trying to prevent the…",
      "content_text": "**tl;dr: Pick high-quality suppliers but don’t blindly trust them. Assume your supply chain will be directly or indirectly compromised. It’s about resilient processes and it's not about trying to prevent the inevitable.**\n\n\n\n---\n\nOrganisations are increasingly dependent on 3rd party suppliers to provide mission-critical services. You are a unique member of the most complicated ecosystem of business services to have ever existed!\n\nIn 2022, supply chain cyber attacks in the United States impacted 1,743 organisations. **An increase of 235% year-over-year since 2017** \\[1].\n\nWe’ve seen suppliers become a lucrative target for cybercriminals. Why? Because these suppliers have access to multiple customer’s data and can be leveraged to gain access to these other organisations. **From an attacker’s perspective, service providers give a great return on their hacking investment.**\n\nIt’s a problem we need to take seriously, but I’ve seen a lot of organisations overcomplicate the topic of cyber assurance for supply-chain risk.\n\nTo the point that:\n\n- it costs astronomical amounts of money\n- we appear to be trying to control the uncontrollable by asking endless questions\n- it has become a security theatre activity proving pseudo-comfort\n- it provides very little real-world bang for the buck on the investment\n\n## So are 3rd party assessments bullsh\\*t?\n\nThe answer is “yes” and “no”.\n\nIt’s difficult to benchmark a wide range of vendors in an effective way and achieve a high level of accuracy.\n\nThe time invested vs. the value derived quickly reaches a saturation point and the diminishing returns curve kicks in.\n\nWe need to be pragmatic about what questions will illuminate risk, focus on the most critical supplier relationships and quickly form a defendable decision.\n\nThere are 3 common approaches when assessing suppliers:\n\n- **Certificates**: ISO 27001 and other certificates are a great way of demonstrating compliance. However, we all know the **presence of controls does not mean effective controls**.\\\n  But, it does demonstrate they have given thought to taking cyber risk seriously.\n- **Questionnaires**: Suppliers wishing to sell you **services might be overly optimistic about their security posture** when providing feedback, to the point where responses are not an accurate reflection of the risk.\\\n  But, it does mean the vendor is participating in active dialogue and the answers can form part of a legal protection level agreement \\[2].\n- **Scorecards**: Vendors will try and sell you magic scorecards that bench 3rd parties. However, these solutions **don’t have the depth of data to be any more than a litmus test**.\\\n  But, it occasionally returns actionable data and it is a quickly maturing field of service offerings.\n\nAll 3 of these activities provide an element of value, but should not be process-heavy, embellished or overly relied upon.\n\nInstead, treat them as the **foundation needed to develop a defendable decision** on whether the supplier meets your organisation’s high-quality requirements.\n\nHowever, the achievement of this high-quality requirement does not mean the supplier is immune to cybercrime. Mimecast, SolarWinds and Atlassian would have passed all 3 of these assessments and still:\n\n- Hackers were able to compromise the security certificate that authenticated the **Mimecast** service on Microsoft 365 Exchange Web Services.\n- Attackers injected a backdoor into a software update of **SolarWinds.**\n- Security researchers discovered that **Atlassian** applications were vulnerable to abuse of single sign-on.\n\n> Supply chain cyber compromise is an inevitable part of business operations.\n\nThe truth is, to positively move the needle on supply chain risk you need to select **high-quality vendors and develop your own resiliency against them being breached.**\n\n## Pragmatics assessments and process resilience\n\nIt always starts with the basics.\n\nDevelop an inventory of who are your suppliers, what they do and do they meet your organisation’s high-quality bar.\n\nDoes the supplier:\n\n- support the organisation’s mission-critical services?\n- meet the organisation’s high-quality bar?\n\nYour resources are not infinite and all applied effort must be risk-weighted.\n\nThe inventory will allow you to **focus efforts on the suppliers supporting mission-critical services** and quickly filter those not meeting your organisation’s high-quality bar.\n\nSuppliers failing the high-quality bar should be encouraged to raise their game or the organisation will be forced to seek a new supplier. **A supplier who takes security seriously is less affected and less likely to be breached.**\n\nIn terms of results-focused questionnaires, I like Gartner’s approach to Protection Level Agreements (PLA) \\[2]. They’re a more pragmatic alternative to the hundreds of questions currently being asked in supplier questionnaires (aspirational I know, but I still like it).\n\n![A Gartner graphic titled \"16 Metrics to Transform Cybersecurity Measurement, Reporting and Investment\", showing a four-by-four grid of named metrics from incident containment to phishing reporting rates](https://imagedelivery.net/QDjDXYt6u3RXENRp4Vk9rw/eef839aa-e8a2-4480-bb1d-0d9e374e2000/public)\n\nGartner’s 16 Metrics \\[2]\n\nPlus, the PLA can also become an enforceable part of the legal agreement between parties.\n\n> Strong Cyber Security is a competitive advantage for companies within the supply chain!\n\nThen we can ask the questions which help us shape our resilience posture by embedding preventative and reactive controls/responses.\n\nThe purpose of these controls/responses is to ensure if a supplier is breached, the **impact on your organisation has the smallest possible blast radius, and the time in which you’re able to respond is reduced to the shortest possible timeframe.**\n\n### If the supplier holds sensitive information…\n\nProactive controls:\n\n- Your organisation must clearly understand the data fields being given to the supplier and business purpose.\n- The supplier must only hold the data for the period required to fulfil the agreed function.\n- Understand where the data is being held and how is the data being protected. Validate this if possible.\n- Seek assurance in independent certifications (i.e. ISO27001) and PLA’s.\n- Ensure that a legal framework is agreed upon to enforce good practices.\n\nReactive controls/responses:\n\n- Monitor/communicate with suppliers to understand if a breach has occurred.\n- Understand what data, how much data, and how the data was affected in a breach.\n- Consider internal incident management processes for handling.\n- Consider internal legal assistance in communicating with the supplier.\n- Consider internal comms and press office involvement for clarity in any announcements.\n- Consider your legal reporting obligations to bodies such as the ICO.\n\n### If the supplier provides software products or services…\n\nProactive controls:\n\n- Only accept verified products or services from approved suppliers.\n- Do not blindly trust the product or service. Only give the access required to perform the given function. Think Zero-Trust for both products and people.\n- Your organisation’s environment must operate a defence-in-depth approach with layers of controls and detection capabilities.\n- Seek assurance in independent certifications (i.e. ISO27001) and PLA’s.\n- Ensure that a legal framework is agreed upon to enforce good practices.\n\nReactive controls/responses:\n\n- Monitor/communicate with suppliers to understand if a breach has occurred.\n- Verify signatures and vetting from products and services that come from an approved supplier.\n- Monitor your environment and staff. Your organisation must be able to use its attack detection and response (SOC) capabilities to detect the actions of Trojan software or malicious insiders.\n- Consider how your business processes could function in the absence of the service or product.\n- Consider internal incident management processes for handling.\n- Consider internal legal assistance in communicating with the supplier.\n- Consider internal comms and press office involvement for clarity in any announcements.\n- Consider your legal reporting obligations.\n\n### If the supplier has remote access to my systems…\n\nProactive controls:\n\n- Ensure remote access is only granted to the required resources for the time period required.\n- Access is centrally controlled and requires a minimum of 2-factors to authenticate. You should exclusively control one of those factors, if possible.\n- Actions are monitored and verified by your organisation.\n- Seek assurance in independent certifications (i.e. ISO27001) and PLA’s.\n- Ensure that a legal framework is agreed upon to enforce good practices.\n\nReactive controls/responses:\n\n- Monitor/communicate with suppliers to understand if a breach has occurred.\n- Remove remote vendor access.\n- Understand which of your organisation’s resources have been accessed since the supplier was breached.\n- Consider how your business processes could function in the absence of the service or product.\n- Consider internal incident management processes for handling.\n- Consider internal legal assistance in communicating with the supplier.\n- Consider internal comms and press office involvement for clarity in any announcements.\n- Consider your legal reporting obligations.\n\nThese control and response steps reduce both the blast radius and your response time to a supplier breach!\n\n**It’s not about measuring and controlling everything. It’s about knowing which supplier relationships could affect processes you care about, reducing the likelihood, and ensuring you can react proportionally to maintain business continuity.**\n\n---\n\nReferences:\n\n\\[1] [https://www.statista.com/statistics/1367208/us-annual-number-of-entities-impacted-supply-chain-attacks/](https://www.statista.com/statistics/1367208/us-annual-number-of-entities-impacted-supply-chain-attacks/)\n\n\\[2] [https://www.gartner.com/en/cybersecurity/research/cybersecurity-business-value-benchmark](https://www.gartner.com/en/cybersecurity/research/cybersecurity-business-value-benchmark)",
      "date_published": "2024-02-22T00:00:00.000Z",
      "date_modified": "2024-02-22T00:00:00.000Z",
      "tags": [
        "Supply chain",
        "Supply Chain",
        "Cyber Supply Chain",
        "Cyber Ecosystem"
      ]
    },
    {
      "id": "https://daveferguson.blog/developing-an-approach-to-attack-path-analysis-for-security-posture-management",
      "url": "https://daveferguson.blog/developing-an-approach-to-attack-path-analysis-for-security-posture-management",
      "title": "Developing an approach to Attack Path Analysis for Security Posture Management",
      "summary": "Developering an approach to attack path analysis which would work!",
      "content_text": "The biggest problem with most vulnerability management solutions is they overload you with data.\n\nAttack path analysis takes that disconnected data and calculates the relationships between entities. This allows you to **ask questions of your environment** when verifying control effectiveness; rather than looking at thousands of vulnerabilities.\n\n> Traditional vulnerability management is not enough to keep organisations safe. Security Posture Management looks to broaden the scope...\n\nSecurity posture management looks to understand if the organisation struggles to keep pace with **patching**, if environment **configuration** drifts over time, and if complexity affects **authorisation**.\n\nWe commonly refer to this trio as the holy grail of security hygiene.  Microsoft estimates that 90% of breaches occur not because of elite hackers, but opportunistic criminals taking advantage of organisations who have neglected their security posture.\n\nThe problem I’m noticing with most platforms who claim to solve the problem in this space is they fail to enrich the data with context, and therefore, are unable to exploit its potential correctly. They only give a **data overload experience filtered and ranked by criticality**…\n\nI want a platform **not to give me security data**, but instead **tell me what to do.**\n\n**Give me intelligent actions!**\n\n## **Security Data Vs Intelligent Action Enabled by Attack Path Analysis**\n\n> Sorry upfront, this is where it gets techie...\n\n![A two-column comparison. Security Data: information overload, requires interpretation, you have to think about what question to ask, low value widgets, relies on smart people knowing what to ask. Intelligent Actions: enriched and computed data, specific to an organisation's worries, computes possible attack vectors, highly actionable against key risks, and validates the environment the way coders do test-driven development](https://imagedelivery.net/QDjDXYt6u3RXENRp4Vk9rw/550a5bd7-45b9-449b-e1f1-e28c27076200/public)\n\nIntelligent actions enabled via attack path analysis would provide two distinct benefits when analysing your organisation’s security posture. Instead of having a list of security flaws, you could:\n\n- **Proactively computed high-value attack paths.**\n  - e.g. there is an exploit path from the user zone to the SCCM server, this is being actively targeted by threat actions and similar organisations have been ransomwared because of this control failure.\n- **Validate the environment against key use cases and have them recalculated daily.**\n  - e.g. Can anyone in the user zone gain access to any production data in the database zone? Could a breached front office work terminal put the critical servers at risk?\n\nIn both of these scenarios, we would look to understand if a combination of possible network connections, patch vulnerability data, misconfiguration and broken authorisation could create a toxic combination where controls are no longer effective and a real attack path exists.\n\nWe can do this by using a graph database to create a digital twin of our environment. Think of each server or workstation in your environment as a node. A possible network connection between them creates an edge relationship and a remotely exploitable server could be a condition of the edge relationship. This would then allow you to query paths through your graph database.\n\nTo map this fully and be effective we need to collect 5 key data sources:\n\n1. Network connection information\n2. Asset context via tagging\n3. Patch vulnerability data\n4. Environment misconfigurations data\n5. Authorisation data\n\n## 1. Network connection information\n\nUsing a host-based agent, record the current connections and fuzz the network to understand other possible network connections:\n\n- Understand every connection which is currently occurring\n- Understand every node with an agent and the open ports\n- Over several days allow every node with an agent to attempt a connection to every other node’s services to map possible connections.\n\nThis will allow you to create a Graph map of the environment where edge relationships map connections which can occur.\n\n![A network graph of grey nodes joined by many lines, with a key showing black lines for connections which occur and blue lines for connections which could occur](https://miro.medium.com/v2/resize:fit:1400/1*IDCZaCo_OA1qL4B50wmXhg.png)\n\n## **2. Asset context via tagging**\n\nIt’s very easy to tell if something exists. The harder part is knowing WHY it exists.\n\nEmbedding organisational context at an early stage is imperative. At a minimum, the graph database should have an understanding of:\n\n- SCCM / Intune / Domain Controllers / Backups\n- User zone laptops\n- DEV zone\n- UAT zone\n- PROD zone\n- Databases\n- DMZ\n- Critical assets\n\n![The network graph with nodes colour-coded by tag — SCCM, domain controllers, backups, user zone laptops, DEV, UAT and PROD zones, and databases — with black lines for connections which occur and blue for connections which could occur](https://imagedelivery.net/QDjDXYt6u3RXENRp4Vk9rw/df33d428-82dd-4c9c-18ff-6d29ca83e500/public)\n\n## **3. Patch Vulnerability data**\n\nWhat vulnerabilities could cause remote compromise of a node?\n\n- Pull vulnerability information and filter on the ones known to cause remote compromise of nodes.\n- Understand the protocol/port on which this vulnerability exists.\n- Create a new edge relationship between nodes which are vulnerable and all the known devices on the network which can create a connection to them on that port.\n\nNow we understand all the remotely exploitable boxes and the relationships which could take advantage of the vulnerability.\n\n## 4. E**nvironment misconfiguration data**\n\nWhat misconfigurations could cause remote compromise of a node?\n\n- Pull the information of misconfigurations in the environment which are known to cause remote compromise of nodes.\n- Understand the protocol/port on which this vulnerability exists.\n- Create a new edge relationship between nodes which are vulnerable and all the known devices on the network which can create a connection to them on that port.\n\nNow we understand all the remotely exploitable boxes and the relationships which could take advantage of the misconfigurations.\n\nWe’re starting to form a very rich view of the organisation’s security posture and the workstation and server components which could take advantage of each other.\n\n![The tagged network graph again, now with red arrows added for compromises which can occur due to an exploit, converging on nodes in the DEV and PROD zones](https://imagedelivery.net/QDjDXYt6u3RXENRp4Vk9rw/88977db4-0829-4f87-c834-d595e402cd00/public)\n\n## **5. Authorisation data**\n\nThe final piece of the puzzle is to understand broken trust relationships. What authentication information could cause remote compromise of a node:\n\n- Pull the information of:\n- Active directory trusts\n- Local accounts on the hosts\n- Cached accounts via Windows login\n- Keys/secrets/passwords held on the host’s filesystem or console history\n- AD credentials easily cracked via ”rockyou”.\n- Create a new edge relationship between nodes\n\nNow we understand all the authentication relationships which could take advantage of the misconfiguration.\n\n \n\n## **An example of how Attack Path Analysis works**\n\nNow that we have a digital twin of our environment we’re able to visualise it and ask questions…\n\n![The tagged network graph with three black arrows marking entry and target points: user laptop on the left, payment DB and payment service on the right](https://imagedelivery.net/QDjDXYt6u3RXENRp4Vk9rw/91b09873-315d-492d-8892-2485dc65de00/public)\n\n**Question:** Can an attack path leveraging patching, misconfiguration and authorisation allow a user who has been phished to gain access to the production Payment service?\n\n**Answer**: YES, an attack path does exist from the user’s zone to the payment service. The current security controls are ineffective.\n\n- 1->2: Lateral movement share local account\n- 2->3: Lateral movement missed patch\n- 3->4: Lateral movement misconfiguration\n- 3->4: Breaks organisation's segregation policy\n- 4->5: Lateral movement creds found on the host\n\n![The same network graph twice. Above, a red attack path is traced from a user laptop through five numbered nodes to the payment database. Below, the same path is annotated with its five lateral-movement steps and the verdict \"Payment service is at risk!\"](https://imagedelivery.net/QDjDXYt6u3RXENRp4Vk9rw/0955f3c1-85dc-446f-0dcf-77b2145df200/public)\n\n \n\n**Simples. Now you know enough to build your digital twin** 😄",
      "date_published": "2024-02-20T00:00:00.000Z",
      "date_modified": "2024-02-20T00:00:00.000Z",
      "tags": [
        "Posture",
        "Attach Path Analysis",
        "Vulnerability Management"
      ]
    },
    {
      "id": "https://daveferguson.blog/opensource-your-software-is-not-written-by-your-people",
      "url": "https://daveferguson.blog/opensource-your-software-is-not-written-by-your-people",
      "title": "90% of ‘your’ software is not written by your people",
      "summary": "An easy way to understanding Open-Source risks and the options available.",
      "content_text": "Alarming? Maybe, but that number is probably even higher for most.\n\nSoftware development in the modern age is fortunate to build upon the foundations of the past. As a result, organisations can develop applications and achieve impressive levels of sophistication in record times.\n\nOne of the primary contributors to our development maturity is the plethora of Open-Source components that developers can leverage. A seemingly infinite collection of code from users across the world, available to you, for free. This obviously introduces Open-Source benefits, but it can also introduce Open-Source problems.\n\nI remember coding my first website. I developed it in Perl as it was easier than C, and at that time helper modules were scarce. I coded my own cookie handler, I worried about execution times and had to keep the page small for a better end-user experience. After all that, my website looked terrible. Mostly just GIFs and an “Under Construction” banner.\n\nFast forward and any website can look amazing with little effort. Thanks to component libraries like Bootstrap, the UI heavy lifting has been done. Forms function seamlessly because of the Milk module, notifications pop-up thanks to the Toast modules; the list goes on, and on, and on.\n\n> The truth is software development for the majority is really about the orchestration of Open-Source components; intelligently weaving them together to meet the needs of a user.\n\nYour new software solution will then likely sit upon more Open-Source. You might be hosting it on Linux OS, Apache, and PostgreSQL all of which heavily leverage Open-Source components.\n\nIf you’re reading this and thinking you purchase everything from IBM, Dell and Oracle so Open-Source is not my concern, you might want to think again. A lot of what is sold under an off-the-shelf banner is a solution-focused collection of Open-Source components with a commercial wrapper. If you’re lucky it might even be AI-powered and blockchain-enabled, but that depends on how good the vendor's marketing department is.\n\nOpen Source is a good thing, it’s all around us, and it’s here to stay. However, the “Open-Source Problem” will rear its head from time to time in meetings, and it’s a fair comment as increasingly as we start to see attackers use components as a vector.\n\nSo how can we achieve an acceptable level of risk when our system development relies heavily on Open-Source?\n\nWe can easily make this a very complicated solution. However, entertain me for a moment and let’s try a simple approach and apply a few understandable steps:\n\n## Trust it\n\n- It’s all about trust. Do you trust the individual, the group or the organisation developing and maintaining the Open-Source Component?\\\n  \\\n  Do you trust them today, and will you be able to trust them next year to put in the required effort to maintain the component? Do you trust them not to sell to a Russian software house now that they’re downloaded over a million times? If you were the unpaid brain behind a popular component and a software house offered to continue the maintenance while giving you $100k, would you say no because of their political leaning?\\\n  \\\n  Trust is difficult. You need to work out how you evaluate trust and how often you reassess your decision.\\\n  \\\n  Look at historical behavioural trends. Past trends don’t predict the future but they’re better than blindly guessing. Ask yourself, is the component growing in popularity? Does it have a supportive community? Do the maintainers respond to bugs and vulnerabilities in a positive way? Do the maintainers live in an evil underground lair?\\\n  \\\n  Answers to simple questions such as these can normally give you 80% of what you need to know and there is a range of tools which can help you automate these steps.\n\n## Don’t fully trust it\n\n- Just because you think you can trust something, does not mean you should rely on trust alone. That’s where you need defence in depth.\\\n  \\\n  Layered security controls and design patterns such as defence in depth are why your organisation remains safe when mistakes happen or when fixes such as patches take time to deploy. Most software at some point in its life will require patching, Open-Source Components are not exempt from this.\\\n  \\\n  Many of your Open-Source components will let you down at some point! You must prepare for this in your architecture by building in layers of defence. Control such as a WAF could have given you the ability to apply a temporary fix preventing Log4Shell from affecting your application.\n\n## Monitor it\n\n- Finally, you need to monitor it. If you implemented the Duck component and suddenly it begins to Bark, then something might be wrong.\\\n  \\\n  Understanding how a selection of components is intended to function or has historically functioned is important. To understand if a system has rogue components (or users) you must have either an understanding of what good looks like or know upfront what poor behaviours you’re trying to catch.\n\nWhen applied pragmatically, a few simple steps such as the above can bring a project reliant on Open-Source into risk tolerance.\n\nOpen-Source components can introduce risks if not deployed mindfully, but I often find the “Open-Source Problem” is a label attached to the symptoms resulting from a bigger problem. Poor Secure Software Development Lifecycle Management.\n\nIt’s beyond the scope of this article, but ask yourself a few questions:\n\n- Does your organisation have coding standards?\n- Do you develop unit and integration tests?\n- Does your development lifecycle use key management in the CI/CD pipeline?\n- Do your developers undergo regular secure code enablement training?\n- Does your Agile development practice look like the Waterfall methodology but with new tooling?\n\nIf the answers to the above are not easy to satisfactorily evidence in your organisation, I would suggest Open-Source is only one of your problems. You likely have broader and more pressing secure development concerns.",
      "date_published": "2024-02-20T00:00:00.000Z",
      "date_modified": "2024-02-20T00:00:00.000Z",
      "tags": [
        "Supply chain",
        "Open Source",
        "SDLC",
        "Software Development",
        "Secure SDLC"
      ]
    },
    {
      "id": "https://daveferguson.blog/preparing-your-organisation-for-ai-cyber-warfare",
      "url": "https://daveferguson.blog/preparing-your-organisation-for-ai-cyber-warfare",
      "title": "Preparing your Organisation for AI Cyber Warfare",
      "summary": "Are you ready for the rise of the machines? As AI becomes more prevalent, it's time to start thinking about how to prepare your organisation for a world of AI Cyber Warfare.",
      "content_text": "Allow me to sound a little paranoid for a moment, and remember, these are my thoughts intended to spark a conversation.\n\nI was reminded this week of Thomas Rid’s book, **The Rise of the Machines**. An excellent read on the origins of cybernetics.\n\nThomas tells the story of Vannevar Bush, vice president of MIT and dean of the School of Engineering, who in 1939 became concerned about the “antiaircraft problem”.\n\nBush saw that aircraft would grow bigger, faster, and capable of flying at higher altitudes. This evolution, he understood, made it difficult, if not impossible, to bring down the machines with run-of-the-mill gunnery.\n\nTo shoot down the new bombers, ground-based artillery needed complex ballistic calculations completed faster and more accurately than humans could perform or even read off a recalculated range table. Machines needed to be invented for the task. And soon those “mechanical brains” would start to “think”. The rise of the machines had begun.\n\nBush’s concerns were valid. Battle for Britain began as German bombers attacked London in the summer of 1940, and cybernetics played a pivotal role in both sides’ offensive and defensive capabilities.\n\nFast forward 80-odd years to today, and mankind appears to be at another pivotal moment. AI has become prevalent and on the verge of great power.\n\nI run several personal labs and projects. It satisfies my technical itch and allows me to stay current. Like any human, I’ve misdesigned things, neglected to patch and misconfigured my servers. When making some of the more critical blunders, the time I’ve typically seen it take for the server to become compromised in 2023 is between 20 min to 2 hours.\n\nIt’s not human hackers compromising the server, but instead, an autonomous crypto-mining operation which scans the internet for common weaknesses and deploys malware to harvest your electricity.\n\nI’ve noticed similar exploitation and timelines in the corporate world. The primary difference is scale. Organisations have more moving parts. More services and more employees with various technologies, skills and experience.\n\nMistakes happen. When they occur, do you file a Jira ticket for an employee to pick up on Monday morning? Or do you automatically repair your organisation?\n\nAI adversaries will accelerate the exploitation timeline. Your ability to respond must match or beat those new timelines.\n\n## **My theory is:**\n\nToday’s organisations are not able to respond promptly or proportionately to an AI adversary. The speed and scale at which AI attacks will be able to deploy resources and attack techniques will overwhelm traditional technology operating models.\n\nThe threat, unfortunately, is real. We’ve seen how ransomware groups are well-funded, innovative and ruthless in their approach to revenue generation. Their adoption of AI tooling is inevitable.\n\n## **My proposed solution:**\n\nAn Adversarial-AI requires a Counter-AI response. (Yes, I know this is obvious)\n\nHowever, the technology estates of organisations which can support a Counter-AI response will need to behave very differently.\n\nOrganisations need to start thinking about their technology estate as an organism nurtured to achieve an outcome rather than a piece of machinery directed to perform a task.\n\nFuture technology estates needs to have three fundamental characteristics:\n\n- The environment will have a Described-Purpose\n- The environment will be Self-Aware\n- The environment will be Self-Healing\n\n## **The implementation:**\n\nThe technology needed to achieve this does not exist today. Even if it did most organisations would struggle to adopt such an approach. There are significant hurdles in both the culture and processes within most operating models. Humans generally want to feel like they have more control.\n\nAgain, I’m reminded of a passage from Rise of the Machines: “Machines are about control. Machines give more control to humans: control over their environment, control over their own lives, and control over others. But gaining control through machines also means delegating it to the machines. Using the tools means trusting the tools!”\n\nFuture target operating models will leverage an extreme amount of automation. We must become comfortable with this!\n\nToday we can help prepare our organisations for this transformation by challenging some potential culture and process pushbacks. Introducing the ‘Safe Autonomous Automation’ concept and having it become a trusted part of working.\n\nAn example: Imagine some digital ‘Roomba Robots’. A little army of them, each with objectives centred around cleaning our environment. Stale files, old permissions, unowned servers… Each robot autonomously wanders the environment to highlight areas for cleaning. Each week, I would present the findings to a crowd of decision-makers and request permission to do implement the Roomba Robots suggestions. Each week, our environment would become cleaner, quicker, and cheaper to run. All without causing an incident. It would only be a matter of time before that board of decision-makers would get frustrated with me asking for permission each week and ask to robots to “do their thing”. At that point, we would have earned the organisation’s trust and banked a few points for our autonomous future. A simple test from a technological perspective, but we’d leverage it to introduce cultural and process change.\n\nAutomation will be key, but it’s only one critical element in this complex transformation. If I were sketching out a roadmap on a napkin to move organisations in the right direction pragmatically, it would look like this…\n\n## **Roadmap to Becoming a Self-Aware, Self-Healing Organisation.**\n\n**Today**\n\n- Do not f\\*\\&k up today by focusing all your energy on tomorrow. Silver bullets don’t exist, so don’t neglect Cyber Security fundamentals.\n- Organisations with the lowest-hanging fruit will be the first to be affected by early AI adversarial techniques. Organisations should apply secure-by-design methodologies, attack surface reduction, layered defence models, environment hardening, patching, user education, cyber defence and playbooks. These are your bread and butter and should never be neglected.\n- I’m still a big believer that truly exceptional Cyber Security comes from being consistent at the basics. If you can’t be trusted to do the basics, the board will never trust your robots. It’s not sexy, but it’s true!\n\n**Step 1 — Increase visibility and trust.**\n\n- Develop an accurate inventory of your organisation. Yes, I know you’ve probably heard this before, but seriously, do it!\n- Describe your organisation. Set against your inventory, how should systems, domains, hosts, and users be able to interact with one another? What is important within your organisation? What are the trust boundaries? What is your expected exposure, and to who?\n- Record and understand your organisation’s behaviour.\n- Create a program to build credibility for autonomous automation within your organisation.\n\n**Step 2 — Challenge your assumptions, master the basics and don’t forget about your people.**\n\n- Develop an autonomous way of running unit tests against the assumptions made within your “Describe your organisation”. Have the environment consistently challenge itself and flag where it does not meet expectations. This could be because of design flaws, misconfiguration, vulnerabilities or excessive permissions.\n- Master patching, configuration management and entitlements. Microsoft recently published a paper reiterating that 92% of breaches in 2022 were rooted in failed basics.\n- When mastering the basics, use a **descriptive approach,** not a **directive approach**. *Describe* what criteria a system must meet before connecting to the network, and place it in purgatory until that bar has been met. Avoid using a *directive approach* where hosts are requested to apply patches within a time window.\n- Generate alerts for abnormal behaviours within your organisation. Fine-tune these to flag issues which require a response.\n- Understand that social engineering will take on new approaches with the accessibility of deep fakes. User awareness training must adapt based on what’s happening in the threat landscape.\n- Remember, in a resource-constrained world, we should make decisions based on actionable intelligence first, then educated guesses. Everything else should be left to the world of fiction.\n\n**Step 3 — Develop a community response, increasing automation, automation & automation.**\n\n- Collaboration and information sharing. As cyber threats become more advanced and AI-driven, collaboration and information sharing among organisations, governments, and industry partners will be critical to staying ahead. This trend will likely continue to grow, with increased efforts to establish platforms, alliances, and standards for sharing threat intelligence and best practices.\n- Identify what alerts could have been automatically identified and contained with the assistance of AI.\n- Increase your automation beyond patching and host configuration basics to trust boundaries and domain communication models. Have the environment identify weaknesses, suggest remediations and test services against the proposed change to ensure no disruptions.\n\n**Step 4 — Something smart that I’ve not thought of yet**\n\n- I know I’ve missed something, and a “5-step plan” sounds better than 4-steps.\n\n**Step 5 — A Self-Aware, Self-Healing technology environment to support your organisation.**\n\n- A Self-Aware environment understands how it’s expected to operate. Their purpose, behaviours, performance, criticalities, and more as all are ***described.***\n- The environment will consistently iterate to meet the described purpose per the SLAs.\n- A central orchestration brain will have an army of AI Roombas directed to complete bespoke tasks while collaborating together.\n- The environment will learn to self-identify failures, malicious behaviour and attacks against systems. It would have the knowledge required to realign to the ***description***, repair and automatically adapt. While also developing a memory of the event to respond quickly if it were to occur again in the future.\n- Knowledge of an evolving threat and how to protect the environment would be automatically shared between collaborating parties such as industry forums and critical supply chains. Each environment would automatically apply remediations to protect both the technology and users within the organisation.\n\n**Simples.**\n\n\n\n---\n\n\n\nThis document discusses the potential for AI to revolutionise cyber security and the need for organisations to prepare for AI cyber warfare. The author proposes a roadmap for becoming a self-aware, self-healing organisation that includes increasing visibility and trust, mastering the basics, developing a community response, and increasing automation. The author emphasises the need for a foundation and culture that embraces automation, continuous improvement, and industry collaboration.",
      "date_published": "2024-02-17T00:00:00.000Z",
      "date_modified": "2024-02-17T00:00:00.000Z",
      "tags": [
        "AI",
        "AI Warfare",
        "AI future",
        "Machine vs Machine",
        "Automation"
      ]
    },
    {
      "id": "https://daveferguson.blog/critical-vulnerability-management-cheat-sheet",
      "url": "https://daveferguson.blog/critical-vulnerability-management-cheat-sheet",
      "title": "Critical Vulnerability Management Cheat Sheet",
      "summary": "A cheat sheet to help you manage critical vulnerabilities like a pro!",
      "content_text": "Ideally vulnerabilities should be remediated as part of your **regular patching cycle.**\n\nHowever, if you believe there is a **strong likelihood of the vulnerability being exploited before the patching cycle kicks in**, then you might want to escalate the patching to avoid a security incident. \n\nThe Critical Vulnerability Management Cheat Sheet is a series of actions to streamline this escalation activity. It will ensure all options are considered, actions play out and stakeholders are informed.\n\n[**>> Download the Critical Vulnerability Management Cheat Sheet Here**](https://drive.google.com/file/d/1EbXJDtQ-X9098Z6Ft97EPdGsRBuLRsqk/view)\n\n\n\n---\n\n## 1. Assess the situation\n\n> *The information available to assess zero-day vulnerabilities will be incomplete and may change as the community learns more. **If the facts change, don’t be scared to reassess your situation and the response you’re taking.***\n\n- Identify the team you need to help assess and remediate; this should include the individuals who manage affected systems, and who will best understand their purpose and criticality.\n- Collectively establish the vulnerability’s criticality for your organisation and agree on how to move forward\n- Think Impact:\\\n  \\- What criticality has the vendor or community rated the vulnerability?\\\n  \\- Do you rely on the affected technology?\\\n  \\- What is the function of the affected systems in your organisation?\\\n  \\- How would your organisation respond if those systems were compromised or became unavailable?\n- Think Likelihood:\\\n  \\- Do you have public or internal exposure?\\\n  \\- Can the vulnerability be exploited remotely?\\\n  \\- Has a POC been released?\\\n  \\- Has exploitation in the wild been reported?\\\n  \\- Do you have other technologies or processes which would help mitigate the vulnerability?\n- Setup live information feeds to ensure you have the latest information. Think Twitter & Reddit.\n- If there is value in a centralised coordinated response, reach out to your industry working groups and governing bodies. Think FSCCC, NCSC & NSA (country & industry dependant)\n- Identify any 3rd party vendors which could be affected. If required, reach out to understand their exposure and response.\n\n## 2. Ensure your defences\n\n> *If patching is not an option or unavailable, **consider other mitigations and compensating controls** you can safely implement. Then move to permanently secure the organisation at a later date via the patch management process.*\n\n- Do you have any mitigations or compensating factors that can be deployed? i.e., a WAF in front of a web application, additional email filters or end-user controls.\n- Has the vendor or the community released any mitigation steps to aid remediation?\n- Has the vendor released a patch for remediation?\n- What is the community’s feedback on remediation effectiveness and safety?\n- Deploy the remediation to a testing group which is representative of your organisation’s workforce or the UAT systems. You must quickly gain confidence in the suggested fix.\n- Test the remediation has been effective in closing out the risk introduced by the vulnerability.\n- Providing remediation steps have been successful, push to the wider organisation and production systems.\n- Depending on the criticality and remediation steps, the timelines for these activities could be a few hours to a few days. This should be agreed at a senior level based on your organisation's risk appetite set against the new threat.\n- Finally, if the initial remediation steps only focused on a mitigation step, then you must still patch. Work with your standard patch management process to ensure a vendor-approved patch is applied once released.\n\n## 3. Detect & respond\n\n> *While doing what you can to prevent one, make sure you’re **ready for an incident**, especially if you know you’re vulnerable and it’s trending.*\n\n- Do you have enough information to develop a detection case to identify if an adversary were to use the zero-day against your organisation?\n- Do you have confidence that your incident management process could contain and respond if an adversary were to use the zero-day against your organisation?\n- Can you retrospectively run the new zero-day detection case against recent logs to understand if you’ve been previously exploited?\n- Does the detection case require out of regular hours support?\n- What is your level of confidence that your organisation has not been exploited? Can you explain the reasoning behind your answer?\n\n## 4. Keep communicating\n\n> *Communication is the linchpin that holds a good response together. It’s essential during times of high-pressure to **keep everyone on the same page and build confidence** across the organisation.*\n\n- Use collaboration tools to develop a single source of truth for the working group.\n- Clearly explain what the vulnerability means to your organisation, how you’re responding and set expectations across the spectrum of stakeholders.\n- Identify your senior and executive stakeholders. If the vulnerability is likely to receive a brand name and be published in the national press, ensure you’ve pre-emptively alerted them and given them confidence that everything is under control.\n- Reach out to your industry governing body to understand how your peers are tackling the issue. Your approach should have some alignment with your peer’s wider response. Feed this into your comms to build trust.\n- Reach out to your government governing body for advice and guidance on the national response and their views on how this could affect different industry sectors. Again, feed this into your comms to build trust.\n- Have a communication and action plan. Develop a structure and predictable cadence for your communication with stakeholders.\n- Consider informing the wider organisation. Use email channels and internal forums to help the organisation understand the Cyber Security Department is responding to a threat. They’ll be more understanding if you need their assistance or cause them minor inconveniences.\n- Privately and publicly say “Thank you” to the individuals who helped remediate the vulnerability. If appropriate also ask the big boss to express their appreciation.\n\n## 5. Post critical vulnerability review\n\n> *Conduct a review of your organisation’s response, identify weaknesses, and ensure you’re in the best place to handle the next critical vulnerability.*\n\n- Hold a formal Post Incident Review (PIR) to identify successes and weaknesses in your process. Follow the rules of a blameless post-mortem — the key is making improvements, not attributing blame.\n- Your incident might be over, but 3rd parties you rely on may still be affected. Consider if you wish to follow up and how.\n- If you’re unhappy with the way in which the supplier handled the vulnerability, ensure you give formal feedback.\n- All incidents and high-profile vulnerabilities should be developed into marketing material which enables future training and bolsters the business case when the Cyber Security Department requires additional funding. Never let a good crisis go to waste.\n\n \n\n---\n\nFinally, create a feedback loop to ensure that everyone is aware of the lessons to be learned. Don’t repeat the same mistakes next time… because there will be a next time!",
      "date_published": "2024-02-01T00:00:00.000Z",
      "date_modified": "2024-02-01T00:00:00.000Z",
      "tags": [
        "Vuln management",
        "zero-day",
        "vulnerability management"
      ]
    }
  ]
}