Security | Threat Detection | Cyberattacks | DevSecOps | Compliance

Your business almost certainly runs on cloud services. From document storage, email and finance software to your customer data and internal systems, the chances are that most of what keeps your business operational lives, at least in part, in the cloud. And yet, for many businesses, the question of whether that cloud environment is secure rarely gets asked. It tends to be presumed. After all, you’ve got bigger things to worry about. You’re with a reputable provider.

Security teams rarely work from a single rulebook. They may use the NIST Cybersecurity Framework to organize the program, ISO/IEC 27001 to build a formal management system, SOC 2 reports to assess vendors, and laws such as HIPAA, GDPR, DORA, or NIS2 to meet legal obligations. Those names are often grouped together, even though they serve different purposes. Some provide guidance. Some can be certified or independently assessed. Others are contractual requirements, laws, or mandatory sector standards.

A correlation rule joins records from several sources to establish that one thing happened. Two of those sources return different answers about the same identity, the same session or the same action. Something has to happen next, and what most systems do is pick a winner. ‍ Picking is the wrong default. The disagreement carries information that resolving it discards, and in a few specific cases the disagreement is the most useful thing the system produced. ‍

Cyber loss models are built around information leaving an organization. Records exposed, notification costs, regulatory penalty, litigation from affected individuals. Every category assumes the harm is informational. ‍ A compromise affecting vehicles in the field produces something the model has no term for. The vehicle can behave differently, the manufacturer may have to recall it, and the recall cost is frequently larger than anything the cyber categories would have produced. ‍

Approval works at the tool layer and it works well. A platform is assessed, terms are reviewed, a data processing agreement is signed, the tool enters the register, and named identities are entitled to it. Everything about that maps cleanly. ‍ Then somebody uses the approved platform to assemble an agent that acts on their behalf, with its own reach and its own credentials. The approval covered the application.

Three reads from surfaces most organizations already own produce a usable AI usage register in a morning. Entitlement, from the identity provider, showing who is licensed for what. Activity, from network or gateway logs, showing who reached which destination and how much. Identity, from the directory, showing who those people are and which scopes they sit in. ‍ The register answers more questions than people expect.

External threat models estimate how often somebody gets in and what they reach afterward. The susceptibility term does most of the work, weighing what an attacker can do against what the controls prevent. ‍ An insider is already inside. The credentials are valid, the access is entitled and the workflow is familiar. None of that makes the model harder to run, it changes which side of it breaks, and the break is on frequency rather than on magnitude. ‍

The tricky thing about AI compliance is that most organizations are going to experience it from both sides. You need to be able to explain how AI is being used inside your own organization, what it can access, and how you're managing the risk. At the same time, you need to understand how your vendors are using AI and whether that introduces new risk into your environment.

If you manage vendors, supplier drift looks familiar. A delivery arrives late. A vendor misses a service-level agreement (SLA) target, and nobody flags it. Tickets sit unresolved, and quality dips just enough that it never makes the weekly stand-up. The problem is timing. Most teams find out a vendor missed its uptime or response-time targets at renewal, months after anyone could’ve fixed it.

Computers are not safe. Even the best hardware and software products have the potential to conceal as-yet unknown vulnerabilities. And they aren’t all made that well. Many are shuffled into the world without a plan to detect, remediate, and notify users of those vulnerabilities. The EU’s Cyber Resilience Act aims to improve that situation.