You can have great cybersecurity across Identify, Protect, Detect, Respond, and Recover without being very resilient. However, you can’t be resilient without being great at cybersecurity. Resilience is the ability to absorb shocks and recover quickly. The type of toughness we need to build into our organizations for resilience goes beyond what is needed for good cybersecurity:
We need to be able to adapt to the situation
We need to be able to limit the damage and build back better
We need to make sure the people can tolerate the wear and tear of the incident
A simple cyber resilience framework consisting of psychological resilience, adaptability and response readiness.
Package delivery example process – CryptoPack
At the heart of Ron and Don’s modern venture, CryptoPack, is a completely digitized customer journey powered exclusively by Bitcoin. To send a package, the customer interacts solely with the CryptoPack webpage—selecting options, completing a secure Bitcoin payment, and receiving a unique package code. The logistics are automated: a sophisticated route planning system dynamically assigns pickups to drivers. These drivers utilize a proprietary smartphone app for real-time tracking and verification, culminating in instant confirmation messages delivered to both the sender and the recipient upon successful delivery.
There are many ways this business can be disrupted through a cyber attack, from bitcoin theft to personal data breaches to downtime of the scheduler. While risk assessments are helpful in planning detection capabilities, backup plans and incident response, they will not cover every possible disruptive event. Ron and Don’s promise to customers are: we deliver, now matter what.
They want to be really resilient to make sure they honor that promise.
Adaptability
When designing the customer side process, they have 3 key principles:
The customer shall always be able to pay with Bitcoin
The customer shall always be able to order a package delivered
The customer shall always know when a package has been picked up and when it has been delivered
To plan the system they start to think in terms of adaptation and redundancy.
Bitcoin payments:
Use different Bitcoin payment nodes in different regions and hosted by different cloud providers.
Have a fallback to payment into static Bitcoin wallets that are manually monitored in case the integrated payment tracking system fails.
Supporting payments over a Bitcoin lightening network, for regular customers (allowing payments that are not verified on the main Bitcoin network)
Order availability:
Create a streaming backup solution for the order database, to allow fast recovery
Use immutable backups to protect against ransomware
Have a hot fail-over database to take new orders in case the primary database solution goes down
Build multiple backup solutions that can be quickly activated during problems and quickly communicated to customers. This can be one solution built using a static website hosted on completely independent infrastructure, a dark web mirror, and an SMS based infrastructure as last resort.
Status transparency:
Provide an SMS-based backup system for messages to customers, that drivers can directly use from a dedicated phone when the primary system is down
Also post messages on a static website based on package codes, so that senders and receivers can manually check status without revealing personal data
These are just examples of measures that can be built into the system to allow redundancy and prepared fail-over. During an incident, independent systems are available to continue delivering on the company’s key promise: we deliver no matter what. Operating in that manner is going to be more challenging, and will require more resources if it lasts very long, but combined with effective incident response, this will help deliver the required resilience.
Response readiness
Operating on backup systems can shield the customers form annoyance but it will be more costly and annoying. Getting back to normal, better than before, is necessary. Because of this, response readiness is required. Ron and Don implements a solid cyber response capability:
All systems have clear isolation and recovery patterns, that have been prepared for the infrastructure.
A solid detection capability has been built to detect incidents early. The detection plan is reviewed regularly and updated based on threat assessments.
Backup and recovery functions have redundancy and the necessary capacity, and is regularly tested.
They have contracted a modern incident response company that has built a highly automated incident response system for pre-mapped incident models, and have 24/7 readiness for more complex cases.
Every month, Ron and Don runs incident exercises, focusing on different aspects of the response and recovery processes. They use exercises to test, adapt, improve.
Psychological resilience
Ron and Don know that their resilience strategy will only work if everyone contributes, and can handle the unavoidable stress that comes with delivering through incidents and changing ways of working quickly.
Pre-incident: Ron and Don want to bring the hearts and minds of employees and customers on board. They set up to build psychological safety into the company’s life blood. To do this, they:
Set the stage to show that making an effort is valued, and mistakes are allowed. Speaking up and radical candor is expected.
Include customers in resilience thinking by communicating about robustness and adaptation as key parts of the “we always deliver” promise.
Set clear expectations for what will happen during an incident, and which support structures will be available. During incidents, all drivers will be able to call in to management on an open call to discuss problems, suggest ideas and get status updates.
During incident: Ron and Don knows that information vacuum is the friend of chaos. They therefore have established routines for reporting incident progress to drivers and customers. They also provide the open call-in option to discuss problems and issues. Support for using the alternative channels and ways of working is also available in a paper booklet in each car, and on phone for support.
After incident: an open “what will we do better next time” session is held afterwards, with blameless discussion. The purpose is to learn from the incident and to spread good practice. Praise for effort and willingness to put in the extra work needed will be loud and clear with a focus on joint achievement.
Cyber resilience take-aways
Security posture is about strong security architecture, good patching practices, great observability. Without good security posture, resilience is impossible. To achieve good cyber resilience we need:
Adaptability: plan for alternative ways of delivering the service when we are hit by attacks. Absorb the shock, adapt. Keep calm and carry on.
Response readiness: work tirelessly to detect early, respond effectively and build back better.
Psychological readiness: build a culture of psychological safety, clarity of purpose and community. This underpins adaptability and response capabilities.
Have a great cybersecurity month – this year with focus on digital readiness.
This week we celebrated the “Sikkerhetsfestivalen” or the “Security Festival” in Norway. This is a big conference trying to combine the feel of a music festival with cybersecurity talks and demos. I gave a talk on how the attack surface expands when we connect OT systems to the cloud, and how we should collaborate between OT engineers, cloud developers and other stakeholders to do it anyway, if we want to get the benefits of cloud computing and better data access for our plants.
OT and Cloud was a popular topic by the way, several talks centered around this:
One of the trends mentioned by Samuel Linares (Accenture) in his talk “OT: From the Field to the Boardroom: What a journey!” was the integration of cloud services in OT, and the increased demand for plant data for use in other systems (for example AI based analytics and decision support).
A presentation by Maria Bartnes (SINTEF) about a project that SINTEF did for NVE on assessing the security and regulatory aspects of using cloud services in Class 1 and 2 control systems in the power and utility sector. The SINTEF report is open an can be read in its entirety here: https://publikasjoner.nve.no/eksternrapport/2025/eksternrapport2025_06.pdf. The key take-away form the report is that there are more challenging regulatory barriers, than chalelnges implementing secure enough solutions.
My take on this at the festival was from a more practical point of view.
(English tekst follows the Norwegian)
Sikkerhetsfestivalen 2025
Denne uka var jeg på Sikkerhetsfestivalen på Lillehammer sammen med 1400 andre cybersikkerhetsfolk. Det morsomme med denne konferansen, som tar mål av seg å være et faglig treffsted med konferansestemning, er at kvaliteten er høy, humøret er godt, og man får muligheten til å få faglig påfyll, treffe gamle kjente, og få noen nye faglige bekjentskaper på noen korte intense dager.
I år deltok jeg med et foredrag om OT og skytjenester. Stadig flere som levererer kontrollsystemer, tilbyr nå skyløsninger som integrerer med mer tradisjonelle kontrollsystemer. Det har lenge vært et tema med kulturforskjellen mellom IT-avdelingen og automasjon, men når man skal få OT-miljøer til å snakke med de som jobber med applikasjonsutvikling i skyen, får vi virkelig strekk i laget. På OT-siden ønsker vi full kontroll over endringer, og må sikre systemer som ofte har svake sikkerhetsegenskaper, men hvor angrep kan gi veldig alvorlige konsekvenser, inkludert alvorlige ulykker som kan føre til skader og dødsfall, eller store miljøutslipp. På den andre siden finner vi en kultur hvor endring er det normale, smidig utvikling står i høysetet, og man har et helt annet utvalg i verktøyskrinet for å sikre tjenestene. Skal vi få til å samarbeide her, må begge parter virkelig ville det og gjøre en innsats!
For å illustrere denne utfordringen tok jeg med meg et lite demoprosjekt, som illustrerer utviklingen fra en verden der OT-systemer opprinnelig var skjermet fra omgivelsene, til nåtiden hvor vi integrerer direkte mot skyløsninger og kan styre fysisk utstyr via smarttelefonen. Selve utformingen av denne demoen ble til som et slags hobbyprosjekt sammen med de yngste i familien i sommer: Building a boom barrier for a security conference – safecontrols.
La oss se på hvordan vi legger til stadig flere tilkoblingsmuligheter her, og hva det har å si for angrepsflaten.
1992: Angrepsflaten er kun lokal. Det er kun en veibom med en enkel knapp for å åpne og lukke. Denne betjenes av en vakt på stedet.
2001: Vakt-PC i vaktbua, med serielltilkobling til styringsenheten på bommen. Angrepsflata er fortsatt lokal, men inkluderer nå vakt-PC. Denne er ikke koblet til eksterne nett, men det er for eksempel mulig å spleise seg inn på kabelen og sende kommandoer fra sin egen enhet til bommen om man har tilgang til den.
2009: Systemet er tilkoblet bedriftens nettverk via OT-brannmur. Dette muliggjør fjerntilgang for å hente ut logger fra kontoret, uten behov til å reise ut til hver lokasjon. Angrepsflaten er nå utvidet, med tilgang i bedriftsnettet er det nå mulig å komme seg inn i OT-nettet og fjernstyre bommen.
2023: Aktiviteten på natt er redusert, og analyser av åpningtidspunkter viser at det ikke lenger er behov for nattevakt.
2025: Skybasert styringssystem “Skybom” implementeres, og man trenger ikke lenger nattevakt. De få lastebilene som kommer på natta får tilgang, sjåførene kan selv åpne bommen via en kode på smarttelefonen. Nå er angrepsflaten videre utvidet, en angriper kan gå på programvaren som styrer systemet, sende phishing til lastebilsjåfører, bruke mobil skadevare på sjåførenes mobiler, eller angripe selve skyinfrastrukturen. Det er også en ny hardwaregateway i OT-nettet som kan ha utnyttbare sårbarheter.
I det opprinnelige systemet var de digitale sikkerhetsbehovene moderate, på grunn av veldig lav eksponering. Etter hvert som man har økt antallet tilkoblinger og integrasjoner, øker angrepsflaten, og det gjør også at sikkerhetskravene bør bli strengere. I moderne OT-nett vil man typisk bruke risikovurderinger for å sette et sikkerhetsnivå, med tilhørende krav. Den mest vanlige standarden er IEC 62443. Her skal man bryte ned OT-nettet i soner og kommunikasjonskanaler, utføre en risikovurdering av disse og sette et sikkerhetsnivå fra 1-4, hvor 1 er grunnleggende, og 4 er strenge sikkerhetskrav. Her er det kanskje naturlig å dele nettverket inn i 3 sikkerhetssoner: skysonen, nettverkssonen, og kontrollsonen.
Det finnes mange måter å vurdere risiko for et nettverk på. En svært enkel tilnærming vi kan bruke er å spørre oss 3 spørsmål om hver sone:
Er målet attraktivt for angriperen (juicy)?
Er målet lett å kompromittere (lav sikkerhetsmessig modenhet)?
Er målet eksponert (feks tilgjengelig på internett)?
Jo flere “ja”, jo høyere sikkerhetskrav. Her ender vi kanskje med SL-3 for skysonen, SL-2 for lokalt nettverk, og SL-1 for kontrollsonen. Da vil vi få strenge sikkerhetskrav for skysonen, mens vi har mer moderate krav for kontrollsonen, som i større grad også lar seg oppfylle med enklere sikkerhetsmekanismer.
I foredraget viste jeg et eksempel vi dessverre har sett i mange reelle slike systemer: de nye skybaserte systemene er laget uten særlig tanke for sikkerhet. Det hender seg også (kanskje oftere) at systemene har gode sikkerhetsfunksjoner som må konfigureres av brukeren, men hvor dette ikke skjer. I vårt eksempel har vi en delt pinkode til bommen som alle lastebilsjåførene bruker, et system direkte eksponert på internett og ingen reell herding av systemene.Det er heller ingen overvåkning og respons. Dette gjør for eksempel at enkle brute-force-angrep er lette å gjennomføre, noe vi demonstrerte som en demo.
Til slutt så vi på hvordan vi kunne sikret systemet bedre med tettere samarbeid. Ved å inkludere skysystemet i en “skysone” og bruke SL 3 som grunnlag, ville vi for eksempel definert krav til individuelle brukerkontoer, ratebegrensning på innlogginsforsøk, bruk av tofaktorautentisering og ha overvåkning og responsevne på plass. Dette vil i stor grad redusert utfordringene med økt eksponering, og gjort det vanskeligere for en ekstern trusselaktør å lykkes med og åpne bommen via et enkelt angrep.
Vi diskuterte også hvordan vi kan bruke sikkerhetsfunksjonalitet i skyen til å bedre den totale sikkerhetstilstanden i systemet. Her kan vi for eksempel sende logger fra OT-miljøet til sky for å bruke bedre analyseplattformer, vi kan automatisere en del responser på indikatorer om økt trusselnivå før noen faktisk klarer å bryte seg inn og stjele farlige stoffer fra et lager eller liknende. Skal vi få på plass disse gode sikkerhetsgevinstene fra et skyprosjekt i OT, må vi ha tett samarbeid mellom eieren av OT-systemet, leverandørene det er snakk om, og utviklingsmiljøet. Vi må bygge tillit mellom miljøene gjennom åpenhet, og sørge for at OT-systemets behov for forutsigbarhet ikke overses, men samtidig ikke avvise gevinstene vi kan få fra bedre bruk av data og integrasjoner.
OT and Cloud Talk – in English!
This week I was at the Security Festival in Lillehammer along with 1400 other cybersecurity professionals. The great thing about this conference, which aims to be a professional meeting place with a festival atmosphere, is that the quality is high, the mood is good, and you get the opportunity to gain new technical knowledge, meet old friends, and make new professional acquaintances over a few short, intense days.
This year I participated with a presentation on OT and cloud services. More and more companies that deliver control systems are now offering cloud solutions that integrate with more traditional control systems. The cultural difference between the IT department and the automation side has long been a topic of discussion, but when you have to get OT environments to talk to those who work with application development in the cloud, you really get a stretch in the team. On the OT side, we want full control over changes and have to secure systems that often have weak security features, but where attacks can have very serious consequences, including severe accidents that can lead to injury and death, or major environmental spills. On the other hand, we find a culture where change is the norm, agile development is paramount, and there is a completely different set of tools available for securing services. If we are to collaborate here, both parties must truly want to and make an effort!
To illustrate this challenge, I brought a small demo project with me, which illustrates the development from a world where OT systems were originally isolated from their surroundings, to the present day where we integrate directly with cloud solutions and can control physical equipment via a smartphone. The design of this demo came about as a kind of hobby project with the youngest members of my family this summer: Building a boom barrier for a security conference – safecontrols.
Let’s look at how we are constantly adding more connectivity options here, and what that means for the attack surface.
1992: The attack surface is local only. It is just a boom barrier with a simple button to open and close. This is operated by an on-site guard.
2001: The guard has a PC in the guardhouse, with a serial connection to the control unit on the barrier. The attack surface is still local, but now includes the guard’s PC. This is not connected to external networks, but it is, for example, possible to splice into the cable and send commands from your own device to the barrier if you have access to it.
2009: The system is connected to the corporate network via an OT firewall. This enables remote access to retrieve logs from the office, without the need to travel to each location. The attack surface has now expanded; with access to the corporate network, it is now possible to get into the OT network and remotely control the barrier.
2023: Activity at night is reduced, and analyses of opening times show that there is no longer a need for a night watchman.
2025: A cloud-based control system “Skybom” is implemented, and a night watchman is no longer needed. The few trucks that arrive at night are granted access, and the drivers can open the barrier themselves via a code on their smartphone. Now the attack surface is further expanded; an attacker can go after the software that controls the system, send phishing emails to truck drivers, use mobile malware on the drivers’ phones, or attack the cloud infrastructure itself. There is also a new hardware gateway in the OT network that may have exploitable vulnerabilities.
In the original system, the digital security needs were moderate due to very low exposure. As the number of connections and integrations has increased, the attack surface also grows, which means that security requirements should become stricter. In modern OT networks, risk assessments are typically used to set a security level, with associated requirements. The most common standard is IEC 62443. Here, you should break down the OT network into zones and conduits, perform a risk assessment of these, and set a security level from 1-4, where 1 is basic and 4 is strict security requirements. Here, it is perhaps natural to divide the network into 3 security zones: the cloud zone, the network zone, and the control zone.
There are many ways to assess network risk. A very simple approach we can use is to ask ourselves 3 questions about each zone:
Is the target attractive to the attacker (juicy)?
Is the target easy to compromise (low security maturity)?
Is the target exposed (e.g., accessible on the internet)?
The more “yeses,” the higher the security requirements. Here we might end up with SL-3 for the cloud zone, SL-2 for the local network, and SL-1 for the control zone. This would give us strict security requirements for the cloud zone, while we have more moderate requirements for the control zone, which can also be fulfilled to a greater extent with simpler security mechanisms.
In the presentation, I showed an example that we have unfortunately seen in many real systems like this: the new cloud-based systems are created with little thought for security. It also happens (perhaps more often) that the systems have good security features that must be configured by the user, but this does not happen. In our example, we have a shared PIN code for the barrier that all truck drivers use, a system directly exposed to the internet, and no real hardening of the systems. There is also no monitoring and response. This makes simple brute-force attacks easy to carry out, something we demonstrated as a demo.
Finally, we looked at how we could better secure the system with closer collaboration. By including the cloud system in a “cloud zone” and using SL 3 as a basis, we would, for example, define requirements for individual user accounts, rate limiting on login attempts, the use of two-factor authentication, and have monitoring and response in place. This would largely reduce the challenges with increased exposure and make it more difficult for an external threat actor to succeed in opening the barrier via a simple attack.
We also discussed how we can use security functionality in the cloud to improve the overall security posture of the system. For example, we can send logs from the OT environment to the cloud to use better analysis platforms, we can automate some responses to indicators of increased threat levels before someone actually manages to break in and steal dangerous substances from a warehouse or similar. To implement these good security benefits from a cloud project in OT, we must have close collaboration between the owner of the OT system, the relevant suppliers, and the development environment. We must build trust between the teams through openness and ensure that the OT system’s need for predictability is not overlooked, while at the same time not rejecting the benefits we can get from better use of data and integrations.
Cybersecurity abounds with “to-do lists” in the form of guidance documents and control frameworks. However, these lists alone don’t strengthen a network; implementing the controls does. Given that frameworks often contain hundreds of controls, distinguishing between basic and additional security controls is beneficial. It’s crucial to implement the foundational basics before moving on to risk assessments, strict governance procedures, and other advanced measures.
– I don’t have the paperwork but at least we have firewalls and working patch management!
Luckily, there are also “quickstart” guidelines available. One of the best is the UK NCSC’s “Cyber Essentials”. This includes 5 technical controls that will stop most cyber attacks and make your organization much more resilient.
Help cover the cloud and hosting costs of this blog?
1 – Secure configuration
Remove software and features you don’t need
Do not allow administrative accounts to be used for daily work. Use separate accounts for administration, and preferably only a few people from the IT department should be able to be administrators.
Remove default accounts, and change any default passwords.
2 – Malware protection
Install anti-malware software on all computers and smartphones
Configure the anti-malware software to check web links as well
3 – User access control
Only give access to people who need it
Only give access to necessary resources the user needs to do their job
Implement strong authentication with two-factor authentication for all services that can be reached from the Internet
Set a routine to go through user accounts regularly and remove or disable user accounts that should no longer be there
4 – Firewalls
Make sure all Internet connected devices have a firewall
Configure the firewalls to only allow the necessary traffic
Block all inbound traffic, unless the device has a role requiring it, for example a web server
5 – Security updates
Only use supported applications that still receive security updates
Automated security updates where possible
Keep an inventory of the installed software on all devices. This will be available in most modern anti-malware software systems.
When a high severity vulnerability is published, check the inventory if you have this software and implement the patch or other mitigations quickly.
Next steps
When the essential controls are in place, the next step should be to set up an incident response plan, and practice using it. Then you are ready to start building a risk based governance structure and focus on continuous improvement and compliance using one of the big frameworks such as ISO 27001.
When we first started connecting OT systems to the cloud, it was typically to get access to data for analytics. That is still the primary use case, with most vendors offering some SaaS integration to help with analytics and planning. The cloud side of this is now more flexible than before, with more integrations, more capabilities, more AI, even starting to push commands back into the OT world from the cloud – something we will only see more of in the future. The downside of that as seen from the asset owner’s point of view is that the critical OT system with its legacy security model and old systems are now connected to a hyperfluid black box making decisions for the physical world on the factory floor. There are a lot of benefits to be had, but also a lot of things that could go wrong.
How can OT practicioners learn to love the cloud? Let’s consider 3 key questions to ask in our process to assess the SaaS world from an OT perspective!
The first thing we have to do is accept that we’re not going to know everything. The second thing we have to do is ask ourselves, ‘What is it we need to know to make a decision?’… Let’s figure out what that is, and go get it.
Leo McGarry – character in “The West Wing”
The reason we connect our industrial control systems to the cloud, is that we want to optimize. We want to stream data into flexible compute resources, to be used by skilled analysts to make better decisions. We are slowly moving towards allowing the cloud to make decisions that are feeding back into the OT system, making changes in the real world. From the C-Suite, doing this is a no-brainer. How these decisions challenge the technology and the people working on the factory floors, can be hard to see from the birds-eye view where the discussion is about competitive advantage and efficiency gain instead of lube oil pressure or supporting a control panel still running on Windows XP.
The OT world is stable, robust, traditional , whereas the cloud world is responsive, in a constant flux, adaptable. When people managing stable meet people managing flux meet, discussions can be difficult, like the disciples of Heraclitus debating the followers of Parmenides in ancient Greek phillosophy.
Question 1: How can I keep track of changes in the cloud service?
Several OT practitioners have mentioned an unfamiliar challenge: the SaaS in the cloud changes without the knowledge of the OT engineers. They are used to strict management of change procedures, the cloud is managed as a modern IT project with changes happening continuously. This is like putting Parmenides up against Heraclitus; we will need dialog to make this work.
Trying to convince the vendor to move away from modern software development practices with CI/CD pipelines and frequent changes to a more formal process with requirements, risk assessment spreadsheets and change acceptance boards is not likely to be a successful approach, although it may seem to be the most natural response to a new “black box” in the OT network for many engineers. At the same time, expecting OT practitioners to embrace a “move fast and break things, then fix them” is also, fortunately, not going to work.
SaaS vendors should be transparent with OT customers what services are used and how they are secured, as well as how it can affect the OT network. This overview should preferably be available to the asset owner dynamically, and not as a static report.
Asset owners should remain in control which features will be used
Sufficient level of observability should be provided across the OT/cloud interface, to allow a joint situational understanding when it comes to the attack surface, cyber risk and incident management.
Question 2: Is the security posture of the cloud environment aligned with my OT security needs?
A key worry among asset owners is the security of the cloud solution, which is understandable given the number of data breaches we can read about in the news. Some newer OT/cloud integrations also challenge the traditional network based security model with a push/pull DMZ for all data exchange. Newer systems sometimes includes direct streaming to the cloud over the Internet, point-to-point VPN and other alternative data flows. Say you have a crane operating in a factory, and this crane has been given a certain security level (SL2) with corresponding security requirements. The basis for this assessment has been that the crane is well protected by a DMZ and double firewalls. Now an upgrade of the crane wants to install a new remote access feature and direct cloud integration via a 5G gateway delivered by the vendor. This has many benefits, but is challenging the traditional security model. The gateway itself is certified and is well hardened, but the new system allows traffic from the cloud into the crane network, including remote management of the crane controllers. On the surface, the security of the SaaS seems fine, but the OT engineer feels it is hard to trust the vendor here.
One way the vendor can help create the necessary trust here, is to allow the asset owner to see the overall security posture generated by automated tools, for example a CSPM solution. This information can be hard to interpret for the customer, so a selection of data and context explanations will be needed. An AI agent can assist with this, for example mapping the infrastructure and security posture metrics to the services in use by the customer.
💶 Do you enjoy this post? Consider supporting my cloud experiments and hosting costs on Buy me a coffee! ☕
Question 3: How can we change the OT security model to adapt to new cloud capabilities?
The OT security model has for a long time been built on network segmentation, but with very static resources and security needs. When we connect these assets into a cloud environment that is undergoing more rapid changes, it can challenge the local security needs in the OT network. Consider the following fictitious crane control system.
Crane with cloud integrations via 5G
In the situation of the crane example, the items in the blue box are likely to be quite static. The applications in the cloud are likely to see more rapid change, such as more integrations, AI assistants, and so on. A question that will have a large impact on the attack surface exposure of the on-prem crane system here, is the separation between components in the cloud. Imagine if the web application “Liftalytics” is running on a VM with a service account with too much privileges? Then, a vulnerability allowing an attacker to get a shell on this web application VM may move laterally to other cloud resources, even with network segregation in place. These type of security issues are generally invisible to the asset owner and OT practitioners.
If we start the cloud integration without any lateral movement path between a remote access system used by support engineers, and the exposed web application, we may have an acceptable situation. But imagine now that a need appears that makes the vendor connect the web app and the remote access console, creating a lateral movement path in the cloud. This must be made visible, and then the OT owner should:
Have to explicitly accept this change for it to take action
If the change is happening, the change in security posture and attack surface must be communicated, so that compensating measures can be taken in the on-prem environment
For example, if a new lateral movement path is created and this exposes the system to unacceptable risk, local changes can be done such as disabling protocols on the server level, adding extra monitoring, etc.
The tool we have at our disposal to make better security architectures is threat modeling. By using not only insights into the attack surface from automated cloud posture management tools, but also cloud security automation capabilities, together with required changes in protection, detection and isolation capabilities on-prem, we can build a living holistic security architecture that allows for change when needed.
Key points
Connecting OT systems to the cloud creates complexity, and sometimes it is hidden. We set up 3 questions to ask to start the dialog between the OT engineers managing the typically static OT environment and the cloud engineers managing the more fluid cloud environments.
How can I keep track of changes in the cloud environment? – The vendor must expose service inventory and security posture dynamically to the consumer.
Is the security posture of the cloud environment aligned with my security level requirements? – The vendor must expose security posture dynamically, including providing the required context to see what the on-prem OT impact can be. AI can help.
How can we change the OT security model to adapt to new cloud capabilities? We can leverage data across on-prem and cloud combined with threat modeling to find holistic security architectures.
Do you prefer a podcast instead? Here’s an AI generated one (with NotebookLM):
Doing cloud experiments and hosting this blog costs money – if you like it, a small contribution would be much appreciated: coff.ee/cyberdonkey
Vibe coding is popular, but how good does “vibe security” compare to throwing traditional SAST tools at your code? “Vibe security review” seems to be a valuable addition to the aresenal here, and performs better than both Sonarqube and Bandit!
Here’s an intentionally poorly programmed Python file (generated by Le Chat with instructions to create a vulnerable and poorly coded text adventure game):
import random
import os
class Player:
def __init__(self, name):
self.name = name
self.hp = 100
self.inventory = []
def add_item(self, item):
self.inventory.append(item)
def main():
player_name = input("Enter your name: ")
password = "s3Lsnqaj"
os.system("echo " + player_name)
player = Player(player_name)
print(f"Welcome, {player_name}, to the Adventure Game!")
rooms = {
1: {"description": "You are in a dark room. There is a door to the north.", "exits": {"north": 2}},
2: {"description": "You are in a room with a treasure chest. There are doors to the south and east.", "exits": {"south": 1, "east": 3}},
3: {"description": "You are in a room with a sleeping dragon! There is a door to the west.", "exits": {"west": 2}},
}
current_room = 1
while True:
room = rooms[current_room]
print(room["description"])
if current_room == 3:
action = input("Do you want to 'fight' the dragon or 'flee'? ").strip().lower()
if action == "fight":
if random.randint(0, 1):
print("You defeated the dragon and found the treasure! You win!")
else:
print("The dragon defeated you. Game over!")
break
elif action == "flee":
current_room = 2
continue
command = input("Enter a command (go [direction], get [item]): ").strip().lower()
if command.startswith("go "):
direction = command.split("go ")[1]
if direction in room["exits"]:
current_room = room["exits"][direction]
else:
print("You can't go that way.")
elif command.startswith("get "):
item = command.split("get ")[1]
player.add_item(item)
print(f"You picked up {item}.")
else:
print("Invalid command.")
if __name__ == "__main__":
main()
The code is made unnecessarily complex, and allows user input to be injected directly into the command line. It also has a hardcoded “password” that is not really used for anything. Let’s check the security of this with 3 methods:
Sonarqube Cloud (free version)
Bandit (Python SAST tool)
Github Copilot with GPT-o4
Sonarqube is run with the default ruleset “Sonar Way” with no extra configuration effort. The scan detects “2 security hotspots” and some maintainability issues. A security hotspot is a potential weakness that the SAST tool can’t conclude on, and will require manual review.
The first hotspot is the “password”:
Sonarqube also gives guidance on how to assess if this is dangerous, and how to fix it, which is quite helpful. The other hotspot is “weak cryptography” when the game is using random.randint to choose whether fight or flee is the winning strategy when encountering a dragon – not a (software) security issue. Dragons can be dangerous, though!
Badit did its job – and provides links to more information, including CWE references. Blue is “not good” and red is “bad”.
OK, now for Github Copilot.
Prompt – and then followed by the formatted report!
You are a professional software quality expert and security test engineer. Please review this code and provide an overview of security weaknesses with references to CWE's, and suggested fixes. Analyse the current file. Create the output as a security vulnerability report in markdown format.
Security Vulnerability Report for spaghetti.py
This report provides an analysis of the security weaknesses in the provided spaghetti.py file. Each vulnerability is referenced with its corresponding Common Weakness Enumeration (CWE) and includes suggested fixes.
Vulnerabilities
1. Hardcoded Password
Description: The password is hardcoded in the file (password = "s3Lsnqaj"), making it vulnerable to exposure if the file is shared or accessed by unauthorized users.
Impact: Hardcoded passwords can lead to unauthorized access to sensitive resources.
Suggested Fix:
Store the password securely using environment variables or a secrets management tool.
Example:
import os
password = os.getenv("GAME_PASSWORD")
if not password:
raise ValueError("Password not set in environment variables")
2. Command Injection
Description: The os.system call uses unsanitized user input (os.system("echo " + player_name)), which can lead to command injection if a malicious user provides crafted input.
Impact: Unvalidated input can lead to crashes, security vulnerabilities, or incorrect program behavior.
Suggested Fix:
Validate and sanitize all user inputs.
Example:
player_name = input("Enter your name: ").strip()
if not player_name.isalnum() or len(player_name) > 50:
print("Invalid name. Please enter a valid name.")
return
4. Predictable Randomness
Description: The use of random.randint(0, 1) for critical game logic (e.g., dragon fight outcome) is predictable and not cryptographically secure.
Impact: Predictable randomness can lead to unfair or exploitable outcomes in the game.
Suggested Fix:
Use a cryptographically secure random number generator if randomness is critical.
Example:
import secrets
if secrets.choice([True, False]):
print("You defeated the dragon and found the treasure! You win!")
else:
print("The dragon defeated you. Game over!")
5. No Input Length Restriction
Description: The player_name input does not restrict the length, which could lead to buffer overflow or other issues in certain scenarios.
Impact: The program may crash or behave unpredictably when encountering errors.
Suggested Fix:
Add proper exception handling to ensure the program handles errors gracefully.
Example:
try:
direction = command.split("go ")[1]
if direction in room["exits"]:
current_room = room["exits"][direction]
else:
print("You can't go that way.")
except KeyError:
print("Invalid room configuration.")
except Exception as e:
print(f"An unexpected error occurred: {e}")
Summary
The code contains several vulnerabilities that could compromise its security and reliability. Addressing these issues will improve the robustness and safety of the application.
Recommendations
Replace hardcoded sensitive information with secure storage methods.
Avoid using os.system with unsanitized input; use safer alternatives like subprocess.run.
Validate all user inputs and restrict their length to prevent unexpected behavior.
Use proper error handling to ensure the program does not crash due to invalid input or unexpected conditions.
Consider using cryptographically secure randomness for critical game logic if necessary.
By implementing these fixes, the code will be more secure and maintainable.
Summary
Using Copilot to do a security review and generate a report created the most thorough assessment, which is not surprising. Bandit did quite well and detected the actually dangerous injection vulnerability. Sonarqube provides a nice UI but did not detect the one actually serious vulnerability here.
AI agents are revolutionizing how we interact with technology, but their autonomous nature introduces a new frontier of security challenges. While traditional cybersecurity measures remain essential, they are often insufficient to fully protect these sophisticated systems. This blog post will delve into the unique security risks of programming AI agents, focusing on how the OWASP Top 10 for LLMs can be interpreted for agentic AI and examining the surprising vulnerabilities introduced by “vibe coding.”
The Rise of Agentic AI and Its Unique Security Landscape
The landscape of artificial intelligence is undergoing a profound transformation. What began with intelligent systems responding to specific queries is rapidly evolving into a world populated by AI agents – autonomous entities capable of far more than just generating text or images.
What are AI Agents? At their core, AI agents are sophisticated software systems that leverage artificial intelligence to independently understand their environment, reason through problems, devise plans, and execute tasks to achieve predetermined goals. Critically, they often operate with minimal or no human intervention, making them distinct from traditional software applications.
Imagine an agent analyzing images of receipts, extracting and categorizing expenses for a travel reimbursement system. Or consider a language model that can not only read your emails but also automatically draft suggested replies, prioritize important messages, and even schedule meetings on its own. These are not mere chatbots; they are systems designed for independent action. More advanced examples include self-driving cars that use sensors to perceive their surroundings and automatically make decisions that control the vehicle’s operations. The realm of autonomous action even extends to military drones that observe, select targets, and can initiate attacks on their own initiative.
Why are they different from traditional software? The fundamental difference lies in their dynamic, adaptive, and often opaque decision-making processes. Unlike a static program that follows predefined rules, AI agents possess memory, sometimes can learn from interactions, and can utilize external tools to accomplish their objectives. This expansive capability introduces entirely new attack surfaces and vulnerabilities that traditional cybersecurity models were not designed to address. It gets very hard to enumerate all the different ways an AI agent may react to user input, which depnding on the application can come in different modalities such as text, speech, images or video.
The Paradigm Shift: From Request-Response to Autonomous Action This shift marks a critical paradigm change in software. We are moving beyond simple request-response interactions to systems that can autonomously initiate actions. This dynamic nature means that security threats are no longer confined to static vulnerabilities in code but extend to the unpredictable and emergent behaviors of the agents themselves. A manipulated agent could autonomously execute unauthorized actions, leading to privilege escalation, data breaches, or even working directly against its intended purpose. This fundamental change in how software operates necessitates a fresh perspective on security, moving beyond traditional safeguards to embrace measures that account for the agent’s autonomy and potential for self-directed harmful actions.
Without proper guardrails, an AI agent may act in unpredictable ways.
The rapid proliferation of Large Language Models (LLMs) and their integration into various applications, particularly AI agents, has introduced a new class of security vulnerabilities. To address these emerging risks, the OWASP Top 10 for LLMs was created. OWASP (Open Worldwide Application Security Project) is a non-profit foundation that works to improve the security of software. Their “Top 10” lists are widely recognized as a standard awareness document for developers and web application security. The OWASP Top 10 for LLMs specifically identifies the most critical security weaknesses in applications that use LLMs, providing a crucial framework for understanding and mitigating these novel threats.
While the OWASP Top 10 for LLMs provides a critical starting point, its application to AI agents requires a deeper interpretation due to their expanded capabilities and autonomous nature. For agentic AI systems built on pre-trained LLMs, three security weaknesses stand out as particularly critical:
1. LLM01: Prompt Injection (and its Agentic Evolution)
Traditional Understanding: In traditional LLM applications, prompt injection involves crafting malicious input that manipulates the LLM’s output, often coercing it to reveal sensitive information or perform unintended actions. This is like tricking the LLM into going “off-script.”
Agentic Evolution: For AI agents, prompt injection becomes significantly more dangerous. Beyond merely influencing an LLM’s output, malicious input can now manipulate an agent’s goals, plans, or tool usage. This can lead to the agent executing unauthorized actions, escalating privileges within a system, or even turning the agent against its intended purpose. The agent’s ability to maintain memory of past interactions and access external tools greatly amplifies this risk, as a single successful injection can have cascading effects across multiple systems and over time. For example, an agent designed to manage cloud resources could be tricked into deleting critical data or granting unauthorized access to an attacker.
Traditional Understanding: This vulnerability typically refers to weaknesses in plugins or extensions that broaden an LLM’s capabilities, where insecure design could lead to data leakage or execution of arbitrary code.
Agentic Implications: AI agents heavily rely on “tools” or plugins to interact with the external world. These tools enable agents to perform actions like sending emails, accessing databases, or executing code. Insecure tool design, misconfigurations, or improper permissioning for these tools can allow an attacker to hijack the agent and misuse its legitimate functionalities. An agent with access to a payment processing tool, if compromised through insecure plugin design, could be manipulated to initiate fraudulent transactions. The risk isn’t just in the tool itself, but in how the agent is allowed to interact with and command it, potentially leveraging legitimate functionalities for malicious purposes.
3. LLM05: Excessive Agency (The Core Agentic Risk)
Traditional Understanding: While not explicitly an “LLM-only” vulnerability in the traditional sense, the concept of an LLM generating responses beyond its intended scope or safety guidelines can be loosely related.
Agentic Implications: This becomes paramount for AI agents. “Excessive Agency” means an agent’s autonomy and ability to act without adequate human-in-the-loop oversight can lead to severe and unintended consequences if it deviates from its alignment or is manipulated. This is the ultimate “runaway agent” scenario. An agent designed to optimize logistics could, if its agency is excessive and it’s subtly compromised, autonomously reroute critical shipments to an unauthorized location, or even overload a system in an attempt to “optimize” in a harmful way. This vulnerability underscores the critical need for robust guardrails, continuous monitoring of agent behavior, and clear kill switches to prevent an agent from taking actions that are detrimental or outside its defined boundaries.
An example of excessive agency
Many LLM based chat applications allow the integration of tools. Le Chat from Mistral now has a preview where you can grant the LLM access to Gmail and Google Calendar. As a safeguard, the LLM is not capable of directly writing and sending emails, but it can create drafts that you as a human will need to read and manually send.
The model can also look at your Google calendar, and it can schedule appointments. For this the same safeguard is not in place, so you can ask the agent to read your emails, and respond automatically to any requests for meeting with a meeting invite. You can also ask it to include any email addresses included in that request in the meeting invite. This allows the agent quite a lot of agency, and potentially makes it also vulnerable to prompt injection.
To test this, I send myself an email from another email account, asking for a meeting to discuss purchase of soap, and included a few more email addresses to also invite to the meeting. Then I made a prompt where I asked the agent to check if I have any requests for meetings, and use the instructions in the text to create a reasonable agenda and to invite people to a meeting directly without seeking confirmation from me.
It did that – but not with th email I just sent myself: it found a request for meeting from a discussion about a trial run of the software Cyber Triage (a digital forensics tool) from several years ago, and set up a meeting invite with their customer service email and several colleagues from the firm I worked with at the time.
Excessive agency: direct action, with access to old data irrelevant to the current situation.
The AI agent called for a meeting – it just picked the wrong email!
What can we do about unpredictable agent behavior?
To limit prompt injection risk in AI agents, especially given their autonomous nature and ability to utilize tools, consider the following OWASP-aligned recommendations:
Prompt injection
These safeguards are basic controls for any LLM-based interaction but more important for agents that can execute their own actions.
Isolate External Content: Never directly concatenate untrusted user input with system prompts. Instead, send external content to the LLM as a separate, clearly delineated input. For agents, this means ensuring that any data or instructions received from external sources are treated as data, not as executable commands for the LLM’s core directives.
Implement Privilege Control: Apply the principle of least privilege to the agent and its tools. An agent should only have access to the minimum necessary functions and data to perform its designated tasks. If an agent is compromised, limiting its privileges restricts the scope of damage an attacker can inflict through prompt injection. This is crucial for agents that can interact with external systems.
Establish Human-in-the-Loop Approval for Critical Actions: For sensitive or high-impact actions, introduce a human review and approval step. This acts as a final safeguard against a successful prompt injection that might try to coerce the agent into unauthorized or destructive behaviors. For agents, this could mean requiring explicit confirmation for actions that modify critical data, send emails to external addresses, or trigger financial transactions.
The human-in-the-loop control was built into the Gmail based tool from Le Chat, but not in the Google Calendar one. Such controls will reduce the risk of the agent performing unpredictable actions, including based on malicious prompts in user input (in this case, emails sent to my Gmail).
Agents can be unpredictable – both secret ones and artificial ones
Improper output handling
To address improper output handling and the risk of malicious API calls in AI agents, follow these OWASP-aligned recommendations, with an added focus on validating API calls:
Sanitize and Validate LLM Outputs: Always sanitize and validate LLM outputs before they are processed by downstream systems or displayed to users. This is crucial to prevent the LLM’s output from being misinterpreted as executable code or commands by other components of the agent system or external tools. For agents, this means rigorously checking outputs that might be fed into APIs, databases, or other applications, to ensure they conform to expected formats and do not contain malicious payloads.
Implement Strict Content Security Policies (CSP) and Output Encoding: When LLM output is displayed in a user interface, implement robust Content Security Policies (CSPs) and ensure proper output encoding. This helps mitigate risks like Cross-Site Scripting (XSS) attacks, where malicious scripts from the LLM’s output could execute in a user’s browser. While agents often operate without a direct UI, if their outputs are ever rendered for human review or incorporated into reports, these measures remain vital.
Enforce Type and Schema Validation for Tool Outputs and API Calls: For agentic systems that use tools, rigorously validate the data types and schemas of all outputs generated by the LLM before they are passed to external tools or APIs, and critically, validate the API calls themselves. If an LLM is expected to output a JSON object with specific fields for a tool, ensure that the actual output matches this schema. Furthermore, when the LLM constructs an API call (e.g., specifying endpoint, parameters, headers), validate that the entire API call adheres to the expected structure and permissible values for that specific tool. This prevents the agent from sending malformed or malicious data or initiating unintended actions to external systems, which could lead to errors, denial of service, or unauthorized operations.
Limit External Access Based on Output Intent: Carefully control what external systems or functionalities an agent can access based on the expected intent of its output. If an agent’s output is only meant for informational purposes, it should not have the capability to trigger sensitive operations. This reinforces the principle of least privilege, ensuring that even if an output is maliciously crafted, its potential for harm is contained.
Excessive agency
To manage the risk of excessive agency in AI agents, which can lead to unintended or harmful autonomous actions, consider these OWASP-aligned recommendations:
Implement Strict Function and Tool Use Control: Design the agent with fine-grained control over which functions and tools it can access and how it uses them. The agent should only have the capabilities necessary for its designated tasks, adhering to the principle of least privilege. This prevents an agent from initiating actions outside its intended scope, even if internally misaligned.
Define Clear Boundaries and Constraints: Explicitly define the operational boundaries and constraints within which the agent must operate. This includes setting limits on the types of actions it can take, the data it can access, and the resources it can consume. These constraints should be enforced both at the LLM level (e.g., via system prompts) and at the application level (e.g., via authorization mechanisms).
Incorporate Human Oversight and Intervention Points: For critical tasks or scenarios involving significant impact, design the agent system with clear human-in-the-loop intervention points. This allows for human review and approval before the agent executes high-risk actions or proceeds with a plan that deviates from expected behavior. This serves as a safety net against autonomous actions with severe consequences.
Monitor Agent Behavior for Anomalies: Continuously monitor the agent’s behavior for any deviations from its intended purpose or established norms. Anomaly detection systems can flag unusual tool usage, excessive resource consumption, or attempts to access unauthorized data, indicating potential excessive agency or compromise.
Implement “Emergency Stop” Mechanisms: Ensure that there are robust and easily accessible “kill switches” or emergency stop mechanisms that can halt the agent’s operation immediately if it exhibits uncontrolled or harmful behavior. This is a critical last resort to prevent a runaway agent from causing widespread damage.
Where traditional security tooling falls short with AI agent integrations
Static analysis (SAST), dynamic analysis (DAST) and other traditional security practices remain important. They can help us detect insecure implementation of integrations, lacking validation and other key elements of code security that apply equally well to AI related code as to more static data contexts.
Where traditional tools fall short, are for safeguarding the unpredictable agent part:
Securing AI agents requires a multi-layered approach to testing, acknowledging both traditional software vulnerabilities and the unique risks introduced by autonomous AI. While traditional security testing tools play a role, they must be augmented with AI-specific strategies.
The Role and Limits of Traditional Security Testing Tools:
Static Application Security Testing (SAST): SAST tools analyze source code without executing it. They are valuable for catching vulnerabilities in the “glue code” that integrates the AI agent with the rest of the application, such as SQL injection, XSS, or insecure API calls within the traditional software components. SAST can also help identify insecure configurations or hardcoded credentials within the agent’s environment. However, SAST struggles with prompt injection as it’s a semantic vulnerability, not a static code pattern. It also cannot predict excessive agency or other dynamic, behavioral flaws of the agent, nor can it analyze model-specific vulnerabilities like training data poisoning.
Dynamic Application Security Testing (DAST): DAST tools test applications by executing them and observing their behavior. For AI agents in web contexts, DAST can effectively identify common web vulnerabilities like XSS if the LLM’s output is rendered unsanitized on a web page. It can also help with generic API security testing. However, DAST lacks the semantic understanding needed to directly detect prompt injection, as it focuses on web protocols rather than the LLM’s interpretation of input. It also falls short in uncovering excessive agency or other internal, behavioral logic of the agent, as its primary focus is on external web interfaces.
Designing AI-Specific Testing for Comprehensive Coverage:
Given the shortcomings of traditional tools, a robust testing strategy for AI agents must include specialized runtime tests, organized across different levels:
Unit Testing (Focus on Agent Components): At this level, focus on testing individual components of the AI agent, such as specific tools, prompt templates, and output parsing logic. For example, test individual tools with a wide range of valid and invalid inputs to ensure they handle data securely and predictably. Critically, unit tests should include adversarial examples to test the resilience of prompt templates against prompt injection attempts. Test output validation routines rigorously to ensure they catch malicious payloads or malformed data before it’s passed to other systems or API calls.
Integration Testing (Focus on Agent Flow and Tool Chaining): This level assesses how different components of the agent work together, particularly the agent’s ability to select and chain tools, and its interaction with external APIs. Integration tests should simulate real-world scenarios, including attempts to manipulate the agent’s decision-making process through prompt injection across multiple turns or by feeding malicious data through one tool that affects the agent’s subsequent use of another tool. Validate that the API calls the LLM generates for tools are correctly structured and within permissible bounds, catching any attempts by the LLM to create malicious or unwanted API calls. Test for excessive agency by pushing the agent’s boundaries and observing if it attempts unauthorized actions when integrated with real (or simulated) external systems.
End-to-End Testing (Focus on Abuse Cases and Behavioral Security): This involves testing the entire AI agent system from the user’s perspective, simulating real-world abuse cases. This is where red teaming and adversarial prompting become critical. Testers (human or automated) actively try to bypass the agent’s safeguards, exploit prompt injections, and trigger excessive agency to achieve malicious goals. This includes testing for data exfiltration, privilege escalation, denial of service, and unintended real-world consequences from the agent’s autonomous actions. Continuous monitoring of agent behavior in pre-production or even production environments is also vital to detect anomalies that suggest a compromise or an emerging vulnerability.
Finding the right test cases can be quite difficult, but threat modeling is still useful as a framework to find possible agent related vulnerabilities and possible generation of unwanted states:
Threat modeling is an indispensable practice for securing AI agents, serving as a proactive and structured approach to identify potential abuse cases and inform test planning. Unlike traditional software, AI agents introduce unique attack vectors stemming from their autonomy, interaction with tools, and reliance on LLMs.
The process involves systematically analyzing the agent’s design, its data flows, its interactions with users and other systems, and its underlying LLM. For AI agents, threat modeling should specifically consider:
Agent Goals and Capabilities: What is the agent designed to do? What tools does it have access to? This helps define its legitimate boundaries and identify where “excessive agency” might manifest.
Input Channels: How does the agent receive information (user prompts, API inputs, sensor data)? Each input channel is a potential prompt injection vector.
Output Channels and Downstream Systems: Where does the agent’s output go? How is it used by other systems or displayed to users? This identifies potential “improper output handling” risks, including the generation of malicious API calls to tools.
Tools and External Integrations: What external tools or APIs does the agent interact with? What are the security implications of these interactions, especially concerning “insecure plugin design” and potential misuse?
By walking through these aspects, security teams can brainstorm potential adversaries, their motivations, and the specific attack techniques they might employ (e.g., crafting prompts to trick the agent, poisoning training data, or exploiting a vulnerable tool). This structured approach helps in detailing concrete abuse cases – specific scenarios of malicious or unintended behavior – that can then be translated directly into test cases for unit, integration, and end-to-end testing, ensuring that the security validation efforts directly address the most critical risks.
Key take-aways
Agents with excessive privilege can be dangerous – don’t grant them more access and authority than you need
Use threat modeling to understand what can go wrong. This is input to your safeguards and test cases.
Expand your test approach to cover agentic AI specific abuse cases – traditional tools won’t cover this for you out of the box
Context is critical for LLM behavior – make the effort to create good system prompts when using pre-trained models to drive the agent behavior
We need close partnerships with key suppliers and customers to maintain a strong cybersecurity posture for our business processes. Most supply-chain cybersecurity practices are far from being real partnerships.
Most business processes are digitally connected today. How do we manage warehouse inventory?
Organizations understand that the supply chain affects cyber risk. Supply chains are often integrated through software today, and some of your attack surface may be invisible to you, but visible to and managed by one or more suppliers. At the same time, your customers depend on your ability to manage your cybersecurity posture to protect their business processes. Yet, our approach to supply-chain security is often immature. Many organizations have no organized activity to manage supply chain cyber risk. Some have a vendor qualification scheme, often based on security questionnaires. A vendor qualification process is useful to avoid purchasing services and products from companies with very poor security performance, but it is not enough to ensure a robust defense against supply-chain attacks.
Why is a vendor qualification not enough?
Cyber threats are constantly evolving, and relying solely on vendor qualification can leave your supply chain vulnerable. Qualification processes often focus on static criteria that may not adapt quickly enough to new and emerging threats. This reactive approach can result in security gaps that malicious actors can exploit.
Vendors may meet initial qualification criteria, but their performance can vary over time. Factors such as changes in management, updates to technology, or shifts in market conditions can impact a vendor’s ability to maintain security standards. Without ongoing collaboration, these variations can go unnoticed, posing significant risks to the supply chain.
Effective cybersecurity requires timely and accurate information sharing. However, vendor qualification processes often lack mechanisms for continuous information exchange. This siloed approach can hinder the ability to detect and respond to threats promptly, leaving the entire supply chain at risk.
In the event of a security incident, a coordinated response is crucial. Vendor qualification alone does not foster the trust and communication needed for effective incident response. Without a collaborative framework, responding to incidents can be chaotic and inefficient, prolonging downtime and increasing the impact of breaches.
The solution: security partnerships with important supply-chain partners
To address these challenges, organizations must shift from a vendor qualification mindset to a collaborative partnership approach. This involves establishing strong relationships with key suppliers and customers, built on trust, information sharing, and shared situational awareness.
By fostering open communication channels, organizations can share threat intelligence, best practices, and lessons learned. This collaborative exchange of information enables all parties to stay ahead of emerging threats and respond more effectively to incidents.
Building trust through transparency is essential for successful collaboration. Partners should be open about their security practices, vulnerabilities, and incident response plans. This transparency fosters a culture of mutual support and accountability, strengthening the overall security posture of the supply chain.
Shared situational awareness enables partners to have a collective understanding of the security landscape. This involves regular updates on threats, vulnerabilities, and incidents affecting the supply chain. By maintaining a shared view, organizations can better anticipate and mitigate risks, enhancing the resilience of the supply chain.
Collaborative partnerships allow organizations to align on best practices and standards. By working together, partners can develop and implement robust security measures that are consistent across the supply chain. This alignment helps to minimize vulnerabilities and ensures that all parties are committed to maintaining high security standards.
A business-continuity focused approach to security partnerships
Not all suppliers are equally important, and not all customers are critical to your business. There are also differences in how digitally integrated the supplier-buyer relationship is. Imagine that you are security responsible for a company leasing coffee machines to businesses and supplying them with coffee beans. The company has a lean operation and is highly dependent on digital systems for managing their business processes. They have conducted a business impact assessment of their key processes, and marked the “bean procurement”, “bean distribution” and “machine maintenance and support” as the most critical processes that also have the most digital dependencies. You want to make sure you have a good approach to cybersecuriyt for these processes, starting with bean procurement. To get started on the assessment, you and your colleagues perform a business process mapping and dependency exercise.
1. Source pre-packed coffee beans from wholesale sellers in three qualities.
Packaged coffee beans (by quality)
Offices leasing coffee machines
Logistics providers
Transportation services
2. Arrange transportation from wholesaler to warehouse.
Delivery confirmations
Internal stakeholders
Quality control labs
Quality test results
3. Conduct quality control tests for each quality type.
Inventory reports (by quality)
4. Store pre-packed coffee beans in a warehouse.
5. Distribute coffee beans to offices based on quality requirements.
6. Monitor inventory levels by quality and reorder as needed.
After discussing with some of the suppliers, the procurement division and going through the systems used with both end-users and IT, you have landed on a relatively involved data flow diagram for the procurement of coffee beans (including storage and readiness for distribution, based on the SIPOC):
We are now focusing on the wholesale sellers. There may be multiple interfaces between these companes, but for now let’s consider how a partnership would differ from a pure qualification approach to vendor security here.
Default approach: qualify the vendor, no direct follow-up unless there is an incident.
Provide a list of technical security requirements
Provide a questionnaire in Excel about policies, security controls and capabilities
This will help select a vendor that has a baseline security level at the point in time when the contract is signed. It will not make the companies ready to respond together if there is a cyber attack affecting both, or requiring support from the other. It will not provide proactive steps to improved cyber defense, such as sharing informaiton about threats, vulnerabilities and best practices. But the biggest weakness is: good cybersecurity posture over time depends on evolving practices, innovation and shared situational awareness. A point-in-time qualification does not help with that.
Partnership approach: a partnership will help evolve cybersecurity and can “patch the weaknesses” of the qualification-only approach to supplier security management. Here are 3 key practices to consider for building a strong cybersecurity partnership:
Establish clear expectations and responsibilities for the partnership, and include these in the contract. Make sure the cybersecurity practices included in the contract are mutually beneficial.
Establish a way to share information and build joint situational awareness. This can be achieved through a range of activities, from having quarterly information-sharing video calls to fully integrated threat intellgence and response exchange systems.
Be intentional about making security people from both organizations meet and build relationships. There are many ways to do this, from joining community organizations and conferences, to having regular status meetings and workshops together. Even meeting socially can help build those releationships. People who trust each other work much better together during a crisis, such as cyber incident response.
It is worth noting that regulatory requirements to supply chain security is increasing in many sectors. In Europe, key cyberscurity regulations such as DORA (for financial institutions), NIS2 (critical infrastructure), CRA (for suppliers of digital products) and even the AI Act all have requirements for supply-chain cybersecurity. The views in this blog post don’t post a complete list of activities a good supply chain program must have, it is more in addition to established practices. For an overview of traditional practices that should go into your supply-chain cybersecurity management, this guideline from ENISA is a good starting point: Guideline for supply-chian security (ENISA).
Multifactor authentication is a great security control that makes breaking into user accounts much more difficult. But what do you do if you lose your MFA device? You need to set up recovery methods in advance so that you will be able of doing this. Different SaaS providers offer different levels of convenience and security for these use cases. At work, your IT department will be able to help, so we will focus on services we use in our personal lives here.
Prepare for losing your device: set up your backup options
The most common MFA authentication patterns today involve using a cell phone:
A text message (SMS) with a one-time code (this is probably the least secure MFA option)
An authenticator app with either a one-time code, or a push notification
If you lose access to the phone, you will be locked out of your MFA accounts. There are two main ways to avoid this:
Download static recovery codes and store them in a secure location. These codes can be used to get access when your MFA device is lost.
Set up multiple MFA channels, so that you can use an alternative channel if your primary MFA device is gone. Make sure they don’t both depend on the same physical device.
Security Consideration
When setting up backup MFA methods, make sure you don’t set up an insecure method that will allow hackers to easily bypass your MFA step. One such option is to use e-mail for one-time tokens, if the same e-mail address can also be used for password reset. If your e-mail address is compromised, the attacker will have full access to your account.
Example 1: Google Account
Google offers multiple logon choices when you try to log on to your account, including passkeys (Google’s description). Setting up a passkey is a good idea, it improves security and usability at once.
Google offers many MFA options to choose from (I aborted the default way, and clicked “try another way” on the first MFA prompt screen). It allows you to use:
A physical security key
Use a one time code from another device where you are logged into your account
Click “yes” to a pop-up on your phone
Use your phone or tablet to get a one-time code
Use your passkey
The SMS based option is blocked because more secure options have been configured. Most of these depend on my phone, so if I lose that one, I have much less options. I do have an Android tablet I can use as backup.
Example 2: Facebook account
A lot of people use Meta’s apps, including Facebook. Being locked out of a social media account is not a fun experience. I have created a demo Facebook account, and turned on MFA on this account using an authenticator app. Let’s say I have lost my phone, and need to log in. In the below picture I have entered my account’s e-mail address and password, and it is asking for a one-time code from my authenticator.
If you click the “Need another way to confirm it’s you?” link, you get two options:
Approve on a device where you are already logged in
Upload a government ID to get manual help to reclaim the account
You can also set up multiple authentication methods for MFA on Facebook (and most other big consumer sites). They also offer creating recovery codes that you can save for the rainy day when you lose your phone.
Now, let’s try to log in again and pretend we have lost the authenticator. We don’t get an option to use recovery codes, it looks like we still have to upload an ID to support. But: if you enter one of the 8-digit recovery codes in the field asking for the 6-digit one-time code, it works and you are logged in!
MFA Anti-Lockout Recipe
OK, so if you enable MFA without doing any preparations for losing your device, you will be in trouble the day your phone is lost. Here’s what to do:
Set up MFA with your primary method. Use the most secure option available that you are able to use.
Set up a backup MFA method. Try to avoid e-mail and SMS if you can.
Download and store recovery codes somewhere safe if offered in the app. The best place is probably a password manager.
Set up notifications for unknown logins, for example from new devices or new countries, if offered. This will help you react quickly if something unexpected happens.
Happy surfing without getting locked out of your account because MFA got in the way!
We have connected everything to the Internet – from power plants to washing machines, from watches with fitness trackers to self-driving cars and even self-driving gigantic ships. At the same time, we struggle to defend our IT systems from criminals and spies. Every day we read about data breaches and cyber attacks. Why are we then not more afraid of cyber attacks on the physical things we have put into our networks?
Autonomous cars getting hacked – what if they crash into someone?
Autonomous ships getting hacked – what if they lose stability and sink due to a cyber attack or run over a small fishing boat?
Autonomous light rail systems – what if they are derailed at high speed due to a cyber attack?
Luckily, we are not reading about things like this in the news, at least not very often. There have been some car hacking mentioned, usually demos of possibilities. But when we build more and more of these smart systems that can cause disasters of control is lost, shouldn’t we think more about security when we build and operate them? Perhaps you think that someone must surely be taking care of that. But fact is, in many cases, it isn’t really handled very well.
How can an autonomuos vessel defend against cyber attacks?
What is the attack surface of an autonomous system?
The attack surface of an autonomous system may of course vary, but they tend to have some things in common:
They have sensors and actuators communicating with a “brain” to make decisions about the environment they operate in
They have some form of remote access and support from a (mostly) human operated control center
They require systems, software and parts from a high number of vendors with varying degree of security maturity
If we for the sake of the example consider an autonomous battery powered vessel at sea, such as ferry. Such a vessel will have multiple operating modes:
Docking to the quay
Undocking from the quay
Loading and offloading at quay
Journey at sea
Autonomous safety maneuvers (collision avoidance)
Autonomous support systems (bilge, ballast, etc)
In addition there will typically be a number of operations that are to some degree human led, such as search and rescue if there is a man over board situation, firefighting, and other operations, depending on the operating concept.
To support the operations required in the different modes, the vessel will need an autonomous bridge system, an engine room able to operate without a human engineer in place to maintain propulsion, and various support systems for charging, mooring, cargo handling, etc. This will require a number of IT components in place:
Redundant connectivity with sufficient bandwidth (5G, satellite)
Local networking
Servers to run the required software for the ship to operate
Sensors to ensure the ship’s autonomous system has good situational awareness (and the human onshore operators in the support center)
The attack surface is likely to be quite large, including a number of suppliers, remote access systems, people and systems in the remote control center, and remote software services that may run in private data centers, or in the cloud. The main keyword here is: complexity.
Defending against cyber piracy at high seas
With normal operation of the vessel, its propulsion and bridge systems would not depend on external connectivity. Although cyber attacks can also hit conventional vessels, much of the damage can be counteracted by seafarers onboard taking more manual control of the systems and turning off much of the “smartness”. With autonomous systems this is not always an option, although there are degrees of autonomy and it is possible to use similar mechanisms if the systems are semi-autonomous with people present to take over in case of unusual situations. Let’s assume the systems are fully autonomous and there is nobody onboard to take control of them.
Since there are no people to compensate for digital systems working against us, we need to teach the digital systems to defend themselves. We can apply the same structural approach to securing autonomous systems, as we do to other IT and OT systems; but we cannot rely on risk reduction from human local intervention. If we follow “NSM’s Grunnprinsipper for IKT-sikkerhet” (the Norwegian government’s recommendations for IT security, very similar to NIST’s cybersecurity framework), we have the following key phases:
Identify: know what you have and the security posture of your system
Protect: harden your systems and use security technologies to stop attackers
Detect: set up systems so that cyber attacks can be detected
Respond: respond to contain compromised systems, evict intruders, recover capabilities, improve hardening and return to normal operations
These systems are also operational technologies (OT). It may therefore be useful also to refer to IEC 62443 in the analysis of the systems, especially to assess the risk to the system, assign requires security levels and define requirements. Also the IEC 62443 reference architecture is useful.
It is not so that all security systems have to be working completely autonomously for an autonomous system, but it has to be more automated in a normal OT system, and also in most IT systems. Let’s consider what that could mean for a collision avoidance system on an autonomous vessel. The job of the collision avoidance system can be defined as follows:
Detect other vessels and other objects that we are on collision course with
Detect other objects close-by
Choose action to take (turn, stop, reverse, alert on-shore control center, communicate to other vessels over radio, etc)
Execute action
Evaluate effect and make corrections if needed
In order to do this, the ship has a number of sensors to provide the necessary situational awareness. There has been a lot of research into such systems, especially collaborative systems with information exchange between vessels. There have also been pilot developments, such as this one https://www.maritimerobotics.com/news/seasight-situational-awareness-and-collision-avoidance by the Norwegian firm Maritime Robotics.
We consider a simplified view of how the collision avoidance system works. Sensors tell the anti collision system server about what it sees. The traffic is transmitted over proprietary protocols, some over tcp, some over udp (camera feeds). Some of the traffic is not encrypted, but all is transferred over the local network. The main system server is processing the data onboard the ship and making decisions. Those decisions go to functions in the autonomous bridge to take action, including sending radio messages to nearby ships or onshore. Data is also transmitted to onshore control via the bridge system. Onshore can use remote connection to connect to the collision avoidance server directly richer data, as well as overriding or configuring the system.
Identify
The system should automatically create a complete inventory of its hardware, software, networks, and users. This inventory must be available for automated decision making about security but also for human and AI agents working as security operators from onshore.
The system should also automatically keep track of all temporary exceptions and changes, as well as any known vulnerabilities in the system.
In other words: a real-time security posture management system must be put in place.
Protect
An attacker may wish to perform different types of actions on this vessel. Since we are only looking at the collision avoidance system here we only consider an adversary that wants to cause an accident. Using a kill-chain approach to our analysis, the threat actor thus has the following tasks to complete:
Recon: get an overview of the attack surface
Weaponization: create or obtain payloads suiteable for the target system
Delivery: deliver the payloads to the systems. Here the adversary may find weaknesses in remote access, perform a supply-chain attack to deliver a flawed update, use an insider to gain access, or compromise an on-shore operator with remote access privileges.
Execution: if a technical attack, automated execution will be necessary. For human based attacks, operator executed commands will likely be the way to perform malware execution.
Installation: valid accounts on systems, malware running on Windows server
Command and control: use internet connection to remotely control the system using installed malware
Actions on objectives: reconfigure sensors or collision avoidance system by changing parameters, uploading changed software versions, or turning the system off
If we want to protect against this, we should harden our systems as much as possible.
All access should require MFA
Segregate networks as much as possible
Use least privilege as far as possible (run software as non-privileged users)
Write-protect all sensors
Run up-to-date security technologies that block known malware (firewalls, antivirus, etc)
Run only pre-approved and signed code, block everything else
Remote all unused software from all systems, and disable built-in functionality that is not needed
Block all non-approved protocols and links on the firewall
Block internet egress from endpoints, and only make exceptions for what is needed
Doing this will make it very hard to compromise the system using regular malware, unless operations are run as an administrator that can change the hardening rules. It will most likely protect against most malware being run as an administrator too, if the threat actor is not anticipating the hardening steps. Blocking traffic both on the main firewall and on host based firewalls, makes it unlikely that the threat actor will be able to remove both security controls.
Detect
If an attacker manages to break into the anti-collision system on our vessel, we need to be able of detecting this fast, and responding to it. The autonomous system should ideally perform the detection on its own, without the need for a human analyst due to the need for fast response. Using human (or AI agents) onshore in addition is also a good idea. As a minimum the system should:
Log all access requests and authorization requests
Apply UEBA (user entity behavior analysis) to detect an unusual activity
Use advanced detection technologies such as security features of a NGFW, a SIEM with robust detection rules, thorough audit logging on all network equipment and endpoints
Use EDR technology to provide improved endpoint visibility
Receive and use threat intelligence in relevant technologies
Use deep packet inspection systems with protocol interpreters for any OT systems part of the anti-collision system
Map threat models to detection coverage to ensure anticipated attacks are detectable
By using a comprehensive detection approach to cyber events, combined with a well-hardened system, it will be very difficult for a threat actor to take control of the system unnoticed.
Respond and recover
If an attack is detected, it should be dealt with before it can cause any damage. It may be a good idea to conservatively plan for physical response also for an autonomous ship with a cybersecurity intrusion detection, even if the detection is not 100% reliable, especially for a safety critical system. A possible response could be:
Isolate the collision avoidance system from the local network automatically
Stop the vessel and maintain position (using DP if available and without security detections, and as a backup to drop anchor)
Alert nearby ships over radio that “Autonomous ship has lost anti-collision system availability and is maintaining position. Please keep distance. “
Alert onshore control of the situation.
Run system recovery
System recovery could entail securing forensic data, automatically analysing data for indicators of compromise and identify patient zero and exploitation path, expanding blast radius to continue analysis through pivots, reinstall all affected systems from trusted backups, update configurations and harden against exploitation path if possible, perform system validation, transfer back to operations with approval from onshore operations. Establishing a response system like this would require considerable engineering effort.
An alternative approach is to maintain position, and wait for humans to manually recover the system and approve returning to normal operation.
The development of autonomous ships, cars and other high-risk applications are subject to regulatory approval. Yet, the focus of authorities may not be on cybersecurity, and the competence of those designing the systems as well as the ones approving them may be stronger in other areas than cyber. This is especially true for sectors where cybersecurity has not traditionally been a big priority due to more manual operations.
A cyber risk recipe for people developing autonomous cyber-physical systems
If we are going to make a recipe for development of responsible autonomous systems, we can summarize this in 5 main steps:
Maintain good cyber situational awareness. Know what you have in your systems, how it works, and where you are vulnerable – and also keep track of the adversary’s intentions and capabilities. Use this to plan your system designs and operations. Adapt as the situation changes.
Rely on good practice. Use IEC 62443 and other know IT/OT security practices to guide both design and operation.
Involve the suppliers and collaborate on defending the systems, from design to operations. We only win through joint efforts.
Test continuously. Test your assumptions, your systems, your attack surface. Update defenses and capabilities accordingly.
Consider changing operating mode based on threat level. With good situational awareness you can take precautions when the threat level is high by reducing connectivity to a minimum, moving to lower degree of autonomy, etc. Plan for high-threat situations, and you will be better equipped to meet challenging times.
When we talk about cybersecurity, we tend to focus on the interests of businesses, governments, or other organizations. But what about our personal lives, are we at risk from cyber attacks? We definitely are, and we don’t talk enough about it. When people ask cybersecurity experts about what they should do to protect themselves, the answer is often “it depends on your threat model”. This is not false, but also not very helpful. Most people don’t relate to terminology such as threat models, and they have likely never given it much thought. This article is really meant for professionals who need to have discussions with individuals about security, to provide a realistic starting point for the risks we face as individuals, rather than companies.
A threat model is simply a description of the attacks you should expect to be a target of. A good threat model gives you an understanding of:
Who is the attacker (at least a category)
What is the motivation of the attacker
What will the attacker likely do?
Let’s summarize some typical attacks in a table, and then discuss how we can better protect ourselves, or help friends and family protect their digital lives. This is not intended for people who are being targeted by intelligence agencies or professional spies: it is a description of threats that can hit anyone with a digital life.
Attack
Friends, relatives and service persons
Criminals on the Internet
Identity theft
Theft of banking ID used to steal money.
Signing agreements on behalf of the victim (credit/loans)
User account takeover, and banking ID theft if possible.
Spyware on phone or computer
Jealous partners wanting to track your activities, including physical location.
Criminals wanting to steal banking credentials or credit card data.
Data theft
Theft of photos, or they may also take the photos and abuse them later for extortion.
Exfiltration of personal data, especially photos. Primary motivation is extortion.
Credit card fraud
Use of stored credit card data in web browser
Phishing with the aim to steal credit card information.
Hacked web pages, where credit card data is stolen.
Cyber extortion
Threats to release private pictures, or sending them to friends and relatives. Less common among people who know each other from before.
Direct threats, typically related to porn habits they claim to have evidence of (in 99% of the cases these are empty threats).
Threats about sending stolen pictures to relatives or releasing them on the Internet (more realistic threats).
Threats to reveal compromising information to employer or spouse, for blackmail.
Malware
Mostly spyware, but also remote access tools to allow remote control of a computer can be used be jealous partners.
Ransomware can still hit individuals, but less attractive as targets for criminals.
Malware can be used as a stepping stone to attack corporate networks.
Network attack
Not relevant
Criminals attacking vulnerable routers exposed to the Internet, making them part of a global botnet.
Typical attacks we should consider for our personal threat models
Identity theft
Delegate banking access when needed, don’t share login details, use DNS filtering, install security products with browser protection on phone and computer. Use multifactor authentication everywhere.
Identity theft is a big problem, and is costing individuals large sums of money every year. Particularly the elderly are vulnerable to dishonest relatives and service persons, but this can also happen with younger people. The attacker will then:
Attempt to steal one-time code dongles, still used by many banks. They may also just use them when not seen by the owner, to avoid causing suspicion.
Use of a phone app on a borrowed phone to confirm transactions
Ask for the password to such services with the excuse of being helpful. They may also be given the password to perform online banking on behalf of an elderly person.
The typical result of this type of attack, is that the attacker will transfer money from the victim’s account to their own account. They may also take out a loan, and then transfer the money. Often the loss will not be covered by insurance, because giving access to passwords and access codes is seen as negligence from the victim.
The obvious defense here is to not give out passwords or allow other people to control your bank account. For elderly who need this, access can be delegated by the bank, allowing the helper to use their own identity to perform this work. That is a strong deterrent if the helper is the criminal, as it would be traceable who is performing the transactions. That would also remove the negligence argument from the insurance company, increasing the chance of getting the money back.
For criminals from the Internet, account take-over most often occurs as a phishing attack. The target these days is typically banking details. Common sense cyber hygiene can help, but we all know that people are not always that vigilant. Because of this, it is a good idea to use security products and services to block phishing links. This is not a 100% effective protection but it will remove many threats. If your ISP offers a DNS based filtering service that uses threat intelligence to block threats, turn it on. Alternatively, you may want to set up a similar local service if you don’t trust the ISP. In addition, installing a security product with “safe browsing” features will help block known phishing links. This defense should also be considered for smartphones, as most people surf the Internet more from their phones than computers when at home.
Spyware on phone or computer
Install security software on your phone to detect spyware. Keep the phone up to date. Avoid installing software from unofficial sources. Check if apps are requesting unreasonable permissions or if they tend to drain your battery.
Spyware is often used by jealous and abusive partners. If you are in a relationship like this, the best course of action is obviously to leave. But even if you do, you would not like the ex to have control over your phone and computer. There are 3 categories of abusive ex trackers to think about:
Joint user accounts that allow tracking the other person. This can be smartphone apps linked to your car, allowing the other person to track your position, it could be shared access to cloud file storage such as OneDrive or Dropbox, and shared calendars. This can also be family sharing features on iPhone and Android phones, that allow tracking location.
Directly shared passwords. Many partners will share their passwords and pin codes because they trust each other and it is convenient. Others share such details due to social control and negative pressure. In a conflict situation this will be dangerous, and important to get out of as soon as it is safe to do so.
Actual spyware being installed, often called stalkerware (wikipedia) that allows the attacker to read text messages, track location, etc.
The two first bullet points are the most difficult. We never want to believe that our closest family and partners would abuse trust given to them, but fact is they often do. The best defense here is to be very selective with what is shared, and wherever possible use sharing features that can be turned off instead of sharing a user account.
For the spyware case, security software can be effective in detecting and removing the spyware. In addition, such spyware tends to drain the battery fast because it is always active in the background. Check for apps with high battery usage. Spyware will often masquerade as legitimate apps. If you have apps with an unreasonable number of permissions, this is also a good reason to take a closer look at it, and remove it if you do not know why it needs those permissions.
It is therefore a good idea to regularly go through app permissions to make sure you have not granted apps unreasonable access. The permissions that can be granted to apps on smartphones can be quite granular. Spyware will typically want to have access to your calendar, contacts, location, microphone, photos and videos, phone log, and your text messages. If an app asks for any of that without any real reason to do so, be careful.
The last piece of defense here would be to keep your phone up-to-date. Not only does this help avoid exploitation of vulnerable software, it will also make sure you have the latest built-in security features your phone’s operating system has to offer.
Data theft
Use multifactor authentication on all accounts used to share or store sensitive data. Also, store the most sensitive files in extra secure locations. Cloud storage providers may have vault functions with extra security for sensitive data.
For companies, data theft is either about intellectual property, or it is details the company don’t want to be public, that will be abused in extortion schemes. For individuals, it is mostly about extortion, and very ofte private photos. To reduce the risk of theft of your most personal files, it is a good idea to take some extra steps to protect them.
If you use cloud accounts to save your files, several providers offer a vault with extra protection for your most sensitive data. For example, OneDrive offers a Personal Vault, which enforces MFA, has extra restrictions on sharing, and avoids saving local unprotected copies on disk when you access the files. Dropbox also has a Vault feature with similar features.
Many users who have gotten personal files stolen, have experienced this from Snapchat or other social media accounts. Such accounts should be secured with multi-factor authentication. If you have shared very personal photos or files through social media accounts, it is also good to use time-expiring links, as well as preferring secure messaging services if possible. Signal is a good solution.
Credit card fraud
Use credit cards instead of debit cards online. Review the transaction list before paying the bill. Always store credit card data in secure locations.
Credit card fraud is common, both from relatives and service persons, as well as from criminals on the Internet. The people with local access to your cards, can steal the physical card, or use card data stored on your computer. Make sure to only store data in secure locations, such as a password manager, or a vault that requires strong authentication to access. Storing credit card data in text files or spreadsheets is very risky.
It can be a good idea to use credit cards when paying for things online. This way, your bank account cannot be directly drained by criminals, and you can report the fraudulent transactions to your bank quickly. Make it a habit to review all transactions before paying the bill, and contact your bank immediately if you see unknown transactions. Note that many criminals will use a series of smaller transactions instead of one big one, to avoid easy discovery or raising red flags in automated fraud detection systems.
Cyber extortion
Avoid paying criminals as far as possible. Report blackmail attempts to the police. Be vigilant with security of your own files, and be careful with what kind of photos you let other people take of you.
Both criminals and people close to you may use real or fake data to try to blackmail you. A common type of online fraud here, is porn related extortion. A phishing e-mail is sent to you, claiming to have video of you enjoying some adult content, that they will release to the public, or to your friends, if you do not pay them money. This is a scary enough threat for people that many will pay up, even if they know very well that there is no way for the criminals to have such videos of them. Knowing that this is a common scare tactic and fraud, can help people ignore such threats without causing unnecessary anxiety.
Another type of extortion is based on photos. The risk of getting photos stolen is of course lower if you have taken precautions, but there is no way to be completely secure. Of course, other people may also have taken pictures, or even generated them using AI tools or photo editing. In this case, you might experience that the photos are actually published or shared. If this happens, having a plan to cope with it is good. It should also be reported to the police.
Any blackmail attempts should be reported to the police.
Malware
Be careful with messages and links, keep your devices up to date, and use antivirus software.
Malware is any kind of software created for evil purposes, such as data theft, remote controlling a computer, or using your computer as a bot to attack others. You computer in this case can be any of your Internet connected devices, such as your PC, your Wi-Fi router, your smartphone, your connected EV, or even your washing machine.
Most malware is spread through e-mail and social media chats. Being careful with messages is a good starting point. Further, keeping computers and equipment up to date, and running antivirus software where possible is a good way to protect oneself from malware.
Network attack
Remember to update your network devices, and shield them from direct Internet exposure as far as possible.
Criminals on the Internet will run automated attacks on routers. Avoid exposing management ports to the Internet to reduce the risk of this. When a vulnerability that can be exploited automatically is made known, network devices are common targeted in mass exploitation attacks, quickly compromising a large number of devices. This can then be used to attack other companies, or your own workplace. To avoid this, make sure the network devices at home are patched as soon as possible when updates are published.
You can still be hacked
If you consider your threat model, and you make reasonable attempts to be more secure like discussed above, you considerably reduce your risk from cyber attacks, whether they are family member insider threats or bad guys on the Internet. Doing so will, however, not make you invulnerable. You can still get hacked. Because of this, it is also a good idea to have a personal incident response plan. We won’t dive into a detailed story on that, but we should all consider the following:
What should I have offline backups of, for example on a USB drive, in case all online data is lost/destroyed?
Who do I need to call if my accounts are compromised? Make a list of your most important contact points for banks, people you frequently interact with, your insurance company, and perhaps others that can help or will need to know.
Keep some offline emergency resources, such as cash, a notebook with contact information, and perhaps a dumb phone with an extra SIM card
Having all of this in place is the digital equivalent of having smoke detectors and fire extinguishers in your home. It can make a very bad day somewhat less bad. And that has a lot of value in the moment.
safecontrols 