Cloud and SaaS security

It is the split of security duties between the cloud provider and you, and most cloud incidents happen on your side of the line. The provider secures what it runs: data centres, hardware, the network between them and, depending on the service, the operating system and the application itself. You remain responsible for how you use it: who has accounts and with what rights, multi-factor authentication (MFA), how storage and services are configured, which data you put there, your own applications and their patches, and your backups. The line moves with the service type. With rented virtual servers you manage almost everything above the hardware; with a SaaS product such as an office suite you mainly manage identities, sharing settings and data. Read your provider's own responsibility matrix, map each item to a named owner in your company, and check it after every new service. A provider's certificates cover the provider's part, not your configuration.

They describe how much of the stack the provider runs for you, and therefore how much security work stays with you. With infrastructure as a service (IaaS) you rent virtual servers, storage and networks; you install and patch the operating system, configure firewalls and run your applications, so the security work is close to running your own servers. With platform as a service (PaaS) the provider runs the operating system and runtime, such as a managed database or an application platform; you remain responsible for your code, configuration, identities and data. With software as a service (SaaS) you use a finished application such as e-mail, CRM or accounting; your part is mainly who has access, with what rights and multi-factor authentication, how data is shared, and keeping your own copy of important data. Many companies use all three at once. Map each service to its type, because the questions an auditor or insurer asks differ for each, and so do the logs you can get.

It can, for the parts the provider takes over, but it moves risk more than it removes it. A large provider patches its infrastructure, runs redundant data centres and employs security teams few mid-sized companies could afford, so physical security, hardware failures and basic availability usually improve. What does not move is responsibility for identities, configuration and data, and those become more exposed: a cloud admin account is reachable from anywhere on the internet, a storage setting can publish files to the world with one click, and a stolen password with no multi-factor authentication opens everything at once. Attackers have followed companies to the cloud, and many of the incidents they cause there start with a phished account or a leaked access key. Moving safely means MFA on every account, least privilege for admins, logging switched on and reviewed, backups you control, and someone who owns cloud configuration. Your office network still matters too: laptops, printers and servers left behind are often where an attacker first lands.

The connections between your devices and the cloud, not what happens inside the cloud. A sensor on the office network or an agent on a server sees which devices connect to which cloud and SaaS services, when, how often and how much data moves in each direction, plus the server name in the TLS handshake where packets are captured. That is enough to notice a laptop uploading gigabytes to a storage service it never used, a server checking in with a rented cloud machine every few minutes, or a device talking to an unexpected region. It does not see what users do inside a SaaS application, such as sharing a folder publicly, creating a forwarding rule or granting an app access to a mailbox; it does not see traffic between cloud services; and it does not see staff working from home on unmanaged devices. Those come from the provider's own audit logs and admin consoles. NetSenX covers the network side: beaconing, scanning, lateral movement and unusual outbound volume on every plan. It does not replace your cloud provider's logs.

Partly: it sees the network behaviour of Linux servers that carry its agent, wherever they run, but it does not read your cloud provider's control plane. The NetSenX agent runs on Linux and macOS, so a Linux virtual server you operate at a cloud provider can carry it like any other Linux machine; the agent then sees that server's own connections, and the core detections apply on every plan: beaconing to a command-and-control server, scanning, lateral movement to other servers, and unusual outbound data volume. Each such server counts as a device on your plan. What stays outside: managed services you do not run yourself, such as databases, serverless functions and storage; traffic between cloud services that never touches a server with the agent; and everything in the provider's management layer, such as account sign-ins, permission changes and configuration. For those, switch on the provider's own audit and flow logs and send them where someone reviews them. Combining both views gives you the network behaviour of your servers and the account activity around them.

By looking at who the destination is, how the connection behaves and whether anything in your business explains it. Attackers like rented cloud servers because anyone can create one in a couple of minutes and the address belongs to a reputable provider, so the provider's name alone proves nothing. Better questions: does the destination match a service you use, by its name in the TLS handshake or DNS, and is that service in your list of suppliers? Is the connection regular, small and around the clock, like a program checking in, rather than driven by people during working hours? Did it start right after something unusual on that device, such as a new program or a login from abroad? Does a server that normally only receives connections suddenly open them outwards? A legitimate backup or monitoring service usually has a documented destination and a contract; an unknown virtual machine contacted every five minutes by a workstation does not. NetSenX flags the regular check-in pattern, called beaconing, and unusual outbound volume on every plan, with the destination, so you can ask the right owner.

Find out from the connections first, then ask the owner of each server, because most such connections have a boring explanation and a few do not. Legitimate reasons include monitoring and backup services, software update mirrors, a supplier's API, a developer's test machine, or a SaaS vendor that hosts on a budget provider. Worrying signs are the opposite: a server that has no business reason to talk to the internet at all, connections that repeat at fixed intervals day and night, traffic that started after an incident or a new install, and destinations that nobody in the company recognises. Rented virtual servers at low-cost hosts are a common place for attackers' command-and-control and for staging stolen data, precisely because they are cheap, quick and anonymous to rent. Keep the list of expected destinations per server, review it with the owners, and block outbound traffic from servers that do not need it. On every plan, NetSenX shows connections from your hosts with their destinations, and alerts on beaconing and unusual outbound volume, which are the patterns that matter most here.

Yes, and they do, because traffic to a well-known cloud service rarely gets blocked or questioned. Malware can fetch instructions from a file in a public cloud storage account, a shared document, a code-hosting site, a messaging app's bot interface or a content-delivery network, and send stolen data back the same way. To a firewall that judges destinations by reputation, it looks like an ordinary employee using a popular service. What still gives it away is behaviour. A program checking a cloud file at regular intervals, day and night, from a device whose user is not working, has a rhythm that people do not; uploads may be unusually large for that device; and the client fingerprint in the TLS handshake may not match a browser or the service's official app. Practical steps: allow only the cloud services the business uses, by tenant where your tools allow it, and investigate devices that talk to personal accounts of popular services. NetSenX detects beaconing and unusual outbound volume on every plan, whatever the destination, and TLS fingerprints from the Starter plan where the agent captures packets.

Compare the transfer with what that device normally does and with the tools your company actually uses. A sync client sending files to the company's approved storage service follows a pattern: it runs from workstations of people who use it, its volume rises and falls with working hours, and the destination is the service you pay for. Data theft tends to differ in at least one way: a server, rather than a workstation, uploads a lot; the destination is a personal or unknown storage account, a file-sharing site or a rented server; the volume is far above that host's usual level; it happens at night or over a weekend; or it follows other warning signs such as scanning or new admin logins. Tools attackers use for this, such as command-line sync utilities, often look just like legitimate backup. Ask the owner of the host first, then check the storage provider's own logs for the account used. On every plan, NetSenX alerts on unusual outbound data volume per host and shows the destination; it cannot see which files were sent.

You can see whether a company device sends unusual amounts of data to cloud services, which is often the most useful early signal, but not who did it or which files. In the weeks before someone leaves, a sharp rise in uploads from their laptop to a personal storage service, a file-transfer site or an AI tool is worth a conversation, especially at odd hours. A sound offboarding process matters more than detection: agree in writing what stays with the company, remove access to SaaS and cloud accounts on the last day, revoke tokens and app passwords, check sharing links and forwarding rules in mail and storage, and collect devices. Data-loss prevention and the audit logs of your storage and mail services can show file names; a network sensor cannot. Keep any review proportionate, focused on devices and company data, and agreed with HR and, where required, the works council, because monitoring staff is regulated in every EU country. On every plan, NetSenX alerts on unusual outbound data volume from a device and shows the destination.

Yes, mainly through the devices and accounts that sync or administer them. When ransomware encrypts files on a laptop whose folders are synchronised with cloud storage, the sync client faithfully uploads the encrypted versions, so the cloud copies change too. An attacker with a stolen admin account can delete or encrypt data directly in the service, remove backups and versions, or exfiltrate everything first and threaten to publish it. What helps: keep file versioning switched on with enough history, and know how to roll a whole folder back at once; protect admin accounts with phishing-resistant multi-factor authentication and separate them from daily accounts; enable deletion protection or retention locks where the service offers them; keep an independent backup that the same admins cannot remove; and limit sync to the folders people need. Watch the steps that come before encryption, because they are where you can still intervene: on every plan, NetSenX detects beaconing, scanning, lateral movement and unusual outbound volume, including large uploads to cloud storage. It does not see actions inside the cloud service's admin console.

Usually not in the way you need. SaaS providers protect their service against their own failures, with redundant storage and disaster recovery, but they generally do not promise to restore your data after something you or an attacker did inside your account. Deleted items sit in recycle bins and version histories for a limited period and then go; a ransomware attack that encrypts synced files, a malicious admin who deletes mailboxes, or a sync error that overwrites a folder can outlast those periods; and when a subscription or user licence ends, the data may be removed. Read your provider's terms: most describe this split as part of shared responsibility. If the data matters, keep your own copy: a backup service or export that copies mail, files and key application data to storage the SaaS admins cannot delete, kept for as long as your business and legal needs require. Test a restore of a mailbox and a folder at least once, because that is when gaps appear. A network sensor does not help here; this is backup and retention planning.

Start with identities, because most account takeovers begin with a phished or reused password. The essentials, in order: multi-factor authentication for every user, with phishing-resistant methods such as security keys or passkeys for admins; separate admin accounts used only for administration, and as few global admins as possible; legacy authentication protocols that bypass MFA switched off; sign-in policies that block risky locations or unmanaged devices where your licence allows; audit logging switched on and kept long enough to investigate; alerts on new mail forwarding rules, new admin roles and new OAuth app consents; limits on external sharing and on which third-party apps users may connect; and a backup of mail and files outside the provider, because the provider's recycle bins are not a backup. Review admin roles and guest accounts every quarter. Most of this is configuration you already pay for. A network sensor does not see what happens inside these services; what it can add is the view of the devices that connect to them, such as a laptop that starts beaconing after someone opened a phishing attachment.

It is an attack in which the victim is tricked into granting a malicious app access to their account, rather than giving away a password. The user receives a link to what looks like a useful app or a document request, signs in on the real Microsoft or Google page, and clicks to approve permissions such as reading mail, files or contacts. From then on the attacker's app holds a token that works without the password and often survives a password reset and multi-factor authentication, because the user consented. It is effective precisely because every page the victim sees is genuine. Defences: restrict user consent so that only verified publishers or admin-approved apps can be granted access, require admin review for high-risk permissions, alert on new app consents, and review the list of connected apps regularly, removing anything nobody recognises. If you find a malicious grant, revoke the app and its tokens, then check what it accessed in the audit logs. A network sensor does not see consents, which happen inside the identity provider; that is where the controls belong.

The ones you will need to answer what happened after an incident: who signed in, what changed and what data was accessed. For each cloud or SaaS service, check that these are on: sign-in logs with location and device; admin and configuration changes, such as new roles, policies, forwarding rules and app consents; access to files and mailboxes where the service offers it; API activity for cloud accounts; and network flow logs for your cloud networks if you run servers there. Then check how long each is kept by default, because some services keep only a short window unless you pay for more or export them. Store copies somewhere the admins of that service cannot delete, so an attacker with admin rights cannot erase the trail. Decide who reviews them and which events raise an alert. Incident reporting under NIS2 and GDPR, and your insurer, will expect you to reconstruct a timeline. A network sensor adds the device side of that timeline: NetSenX keeps alerts for the period your plan includes, with hosts, destinations and times.

Usually something bad, and quickly, because attackers scan public code repositories for keys continuously. A cloud access key or API token works like a password that never asks for multi-factor authentication; whoever has it can use the account with that key's permissions from anywhere. Typical abuse ranges from starting expensive compute for cryptomining, to copying storage buckets and databases, to creating new users so the attacker keeps access after the key is revoked. Leaks happen through code committed to public or shared repositories, configuration files in backups, screenshots, CI logs and chat messages. If it happens: revoke or rotate the key at once, not after the investigation; check the account's activity logs for everything done with it since the leak, including new users, keys and resources in unusual regions; remove what the attacker created; and review billing. To prevent it, use secret scanning in your repositories, short-lived credentials instead of long-lived keys, narrow permissions per key and budget alerts. A network sensor cannot see a key published on the internet; it may see the consequences on servers it watches.

It is cloud storage that is readable, or even writable, by more people than intended, often by anyone on the internet. Object storage services let you share a bucket or container publicly with a single setting or a link, which is useful for a website's images and dangerous for backups, exports, invoices or customer files. Many publicised data exposures were not hacks at all but files found by someone scanning for open buckets. Avoid it with a few habits: turn on the provider's account-wide block on public access unless a bucket truly needs to be public, and keep public content in separate, clearly named buckets; prefer time-limited signed links over public sharing; encrypt data and restrict who can change sharing settings; use the provider's configuration checks or a posture tool that flags public storage; and review sharing links in SaaS storage, such as links that work for anyone who has them. Check after every new project, because test buckets are a common culprit. A network sensor does not see bucket settings; that belongs to cloud configuration management.

It is a special internal address on every cloud virtual machine from which the machine can read information about itself, including temporary credentials for the permissions assigned to it. Software running on the server uses those credentials to reach storage, databases and other cloud services without a password in its configuration, which is good practice. The risk is that anything able to make the server send a web request to that address can read the credentials too. A common route is server-side request forgery (SSRF): a flaw in a web application that lets an attacker make the server fetch a URL of their choice. With the credentials in hand, the attacker acts in your cloud account with the server's permissions. Defences: require the newer, session-based version of the metadata service where your provider offers one, which blocks simple forged requests; give each server role only the permissions it needs; fix SSRF flaws and validate URLs that applications fetch; and alert on credentials from a server's role being used from outside your environment, which the provider's activity logs can show.

Usually first on the bill, which is why budget alerts are the cheapest detection you can set up. Attackers who obtain cloud credentials often start many powerful virtual machines or containers, frequently in regions you never use, to mine cryptocurrency at your expense. Signs: a sudden rise in compute spend or in the number of instances, machines with GPU types nobody ordered, new resources in unfamiliar regions, new access keys or users created around the same time, and servers running at full CPU around the clock. On a server you operate, a mining process also shows on the network: steady, long-lived connections to mining pools, often on unusual ports, from a machine that normally only serves web requests. Respond by revoking the credentials used, removing what the attacker created in every region, checking for persistence such as new users, roles and scheduled functions, and asking the provider about charges. NetSenX sees the network behaviour of servers that carry its agent, such as regular connections to an unknown destination; it does not watch your cloud bill or resources it has no agent on.

Combine a few cheap sources, because none of them sees everything. The identity provider shows which apps people sign into with their company account, including OAuth apps they connected to mail or files. Expense reports and card statements reveal subscriptions bought by teams. Browser and endpoint management can list installed extensions and desktop apps. DNS logs and firewall or proxy logs show which services company devices reach. Then sort the list: tools that duplicate an approved one, tools that hold company or customer data, and harmless ones. For each tool that handles data, decide to approve it properly, with a contract and admin control, replace it, or retire it, and tell the users why. Doing this once a quarter keeps the list short. A network view helps with the reach part: NetSenX shows which hosts connect to which destinations, with a dedicated view for AI services from the Pro plan; it does not identify every SaaS application by name, and it does not see sign-ins or app consents, which live in the identity provider.

They are three kinds of cloud security tools that look at different things. Cloud security posture management (CSPM) checks the configuration of your cloud accounts, such as public storage, open firewall rules, missing encryption or overly broad permissions, against best practice and reports drift. SaaS security posture management (SSPM) does the same for SaaS applications, checking settings like MFA enforcement, external sharing and admin roles. A cloud access security broker (CASB) sits between users and cloud services, through a proxy or the providers' APIs, to discover which services are used and to enforce policies such as blocking uploads of sensitive data. Whether you need them depends on scale. A company with one cloud account and one office suite can often get far with the providers' own built-in recommendations and secure-score dashboards, which cost nothing extra. Several cloud accounts, many SaaS tools or regulated data make dedicated tools more worthwhile. None of them watches the behaviour of devices on your network; that is a different layer, which network detection covers.

Ask questions whose answers you can check and that matter if something goes wrong. Evidence: which independent reports or certificates cover the service you are buying, such as a SOC 2 Type II report or ISO/IEC 27001 certificate, with scope and date, and whether you may read them. Data: where it is stored and processed, which sub-processors are involved, whether it is used to train models, how long it is kept and how you get it back in a usable format when you leave. Access: single sign-on, MFA enforcement, role-based permissions, and audit logs you can export. Incidents: how fast they notify you, through which channel, and what support they give for your own reporting duties under GDPR or NIS2. Resilience: backups, restore objectives and how they protect against an admin account being misused. Vulnerabilities: how they handle reports and how fast they patch. Write the key answers into the contract or the data-processing agreement, not only a questionnaire. A smaller vendor with clear, honest answers can be safer than a large one with vague ones.

Usually both of you, for different things. The provider is responsible for securing its service and, under the GDPR, a provider acting as your processor must notify you without undue delay after becoming aware of a personal data breach. You, as the controller of your customers' or employees' data, remain responsible for assessing the risk to the people affected and, where required, notifying the supervisory authority within 72 hours of becoming aware, and informing the people concerned if the risk is high. If your company falls under NIS2, a significant incident caused by a supplier can trigger your own reporting duties, and NIS2 expects you to manage supply-chain security as part of your risk-management measures. Contracts decide much of the practical side: notification times, cooperation, information you will receive and liability. Prepare before it happens: know which suppliers hold which data, keep their security contacts, and include a supplier breach in your incident plan. Your national NIS2 law may add details; check it.

Not for running it, but for managing the risk it creates for you, if your company is covered by NIS2. Directive (EU) 2022/2555 lists supply-chain security, including the security aspects of relationships with direct suppliers and service providers, among the cybersecurity risk-management measures in Article 21. In practice that means knowing which cloud and SaaS providers your important services depend on, assessing their security, writing requirements into contracts, and planning for their failure or compromise. Cloud computing service providers are themselves listed in NIS2 as entities in the digital infrastructure sector, so many have their own obligations, which helps, but does not replace your assessment. Useful evidence from providers includes independent audit reports, certifications with a clear scope, incident notification commitments and exit terms. Keep a supplier register that names the data and services each one supports, and review it yearly and after incidents. National transpositions can add requirements or guidance; check your country's law and your authority's publications.

Contain first, then find out what happened, and keep a record as you go. Containment: reset the password and revoke all active sessions and tokens for the account; remove MFA methods you did not register and re-enrol; check for and delete new forwarding rules, app consents, API keys, users or admin roles the attacker created; and if it was an admin account, look across the whole tenant or cloud account, because attackers create backdoors. Investigation: use the provider's sign-in and audit logs to establish when access started, from where, and what was read, changed, shared or downloaded; check whether the same password was used elsewhere. Then decide on obligations: personal data accessed may mean a GDPR notification within 72 hours of becoming aware, and a significant incident may be reportable under NIS2 in your country. Look at the devices too: the stolen password often came from an infected laptop or a phishing page. On every plan, NetSenX can show whether a device in your network began beaconing, scanning or sending unusual volumes around that time. It does not see the cloud account's sign-ins.