Summary and background

Google Cloud Platform (GCP) Cloud Functions are event-triggered, serverless functions that automatically scale and execute code in response to specific events like Hypertext Transfer Protocol (HTTP) requests or data changes. Tenable Research published an article discussing a vulnerability they discovered within GCP’s Cloud Functions serverless compute service and its Cloud Build continuous integration and continuous delivery or deployment (CI/CD) pipeline service.

“When a GCP user creates or updates a Cloud Function, a multi-step backend process is triggered,” Tenable author Liv Matan writes. “This process, among other things, attaches a default Cloud Build service account to the Cloud Build instance that is created as part of the function’s deployment.” This default Cloud Build Service Account (SA) previously gave users excessive Cloud Function permissions. An attacker who has gained the ability to create or update a cloud function could utilize the function’s deployment process to escalate privileges to the default Cloud Build service account or assign a higher privileged SA. Google has since partially addressed Tenable’s discovery to ensure the default Cloud Build service account no longer provides users with excessive permissions.

Based on Tenable’s research, Cisco Talos conducted a series of offensive tests within Cisco’s Google Cloud Platform (GCP) to identify additional threats that may affect customer environments.

During its research, Talos discovered that the technique Tenable identified could be adapted to perform other malicious activities. By implementing different malicious console commands into the Node Package Manager (NPM) ‘package.json’ file used in this technique, threat actors could execute behaviors such as environment enumeration.

Talos furthered this research by attempting to replicate similar behaviors in Amazon Web Services (AWS) and Microsoft Azure to determine if these techniques could be employed to perform similar malicious activities in other cloud-based environments.

Research

Prerequisites

To utilize this attack vector, certain prerequisites must be met. Talos set up a Debian Linux server within the GCP environment with Node Package Manager (NPM) and Ngrok installed. However, the virtual machine for this research can be created in any cloud environment.

After installing NPM and Ngrok, Talos configured both tools to function as intended.

Once NPM and Ngrok were configured, a Python server was created to output the data received from the cloud function.

With NPM, Ngrok, and the Python server set up and configured, the next step was to create and modify the NPM package.

Talos then replaced the content of the package.json file with the following code:

Finally, once all the necessary files are created and configured, Talos set up the environment to visually display the data output from deploying the functions. To achieve this, Talos activated both the Ngrok server and the Python server created earlier.

To replicate the GCP behavior discussed in Tenable’s article, Talos created/updated an SA with function build and cloud build permissions. This SA was then assigned to the GCP Cloud Run Function to allow the code to be executed with privileged access.

Once the servers and service accounts were online and configured to receive and output data, the emulation of the behavior could begin.

Emulation

With the package.json file configured to be utilized by the build function, Talos began emulating the technique described in Tenable’s research article.

The first step in Talos’ replication involved the utilizing a misconfigured GCP function to extract the default Cloud Build service account token. To initiate this process, the “malicious” package.json was updated on the virtual machine, ensuring that it contains code similar to that used by Tenable.

Once the package.json file was modified as desired, it needed to be published to the public NPM registry. To do this, Talos executed the following command:

With the package.json file uploaded to the NPM public registry, it was time to deploy the GCP Cloud Run Function so that the package.json can execute the provided code. To do this, the user must to navigate to their GCP Cloud Run Functions page and select or create a Cloud Run Function, ensuring it is assigned a service account with Cloud Build permissions.

As Talos created or selected our existing GCP Cloud Run Function, we navigated to the source page of the cloud function. Here, Talos modified the package.json file to install the malicious package uploaded to NPM.

Once Talos updated the package.json file with the correct name and version of the NPM package, we selected “Deploy” or “Save and Redeploy” to initiate the build process. During this process, the function sends the requested data to the Ngrok server, which was then output on the Python server.

Talos confirmed that the exfiltration of GCP service account access tokens can no longer be achieved using this method, due to Google’s response and patching of the issue. We further verified this by executing the same command provided to our NPM-uploaded package.json from a separate virtual machine. The command executed successfully, confirming our suspicion that this specific technique for obtaining privileged service account tokens has been patched out.

Original Research

Cisco Talos’ research extended Tenable’s original behavior concept by applying it to other cloud environments through modifications to their respective cloud services. AWS Lambda and Azure Functions are serverless compute services that allow users to run code without provisioning or managing servers. By creating a Lambda function or an Azure function with a Node.js 20.x runtime, a package.json file can be created with dependencies set to execute a malicious package uploaded to NPM’s public repository. These malicious packages may contain harmful console commands that provide a threat actor with valuable enumeration information.

Although this specific vector of threat actor behavior is no longer possible, other commands have proven useful in providing adversaries with valuable enumeration capabilities. These commands can be used on cloud platforms beyond GCP Cloud Build Function, such as AWS Lambda and Azure Functions.

Some examples of the types of enumeration a threat actor can perform using this method include the following.

ICMP Discovery

Internet Control Message Protocol (ICMP) Discovery is utilized to gather information about network devices and their configurations. By analyzing ICMP responses, adversaries can infer the network’s structure, including the presence of routers, gateways, and the pathways between devices. This information can be crucial for planning attacks.

Existence of .dockerenv

Identifying the presence of a .dockerenv file indicates that a process is running inside a Docker container. By checking for this file, threat actors can confirm whether they are operating within a Docker environment. This information can influence their selection of tools and techniques, as containers often possess different security boundaries compared to host systems.

CPU Scheduling

Enumerating CPU Scheduling provides detailed scheduling and status information about the process with process identifier (PID) 1, which is typically the init system or main process in a containerized environment. Threat actors can determine the init system in use, such as systemd or sysvinit. This information helps them understand the system’s configuration and identify potential vulnerabilities associated with the specific init system.

CPU Scheduling Data Output Plain Text

Control Group Container ID

Enumerating Control Group Container ID provides detailed information about current mount points. Threat actors can use this information to identify critical or sensitive filesystems that might be targeted for data exfiltration. By examining mount options, they can look for insecure configurations, such as filesystems mounted with exec permissions in directories where malicious binaries could be introduced. In containerized environments, understanding mount namespaces can aid in developing container escape techniques, enabling attackers to break out of the container and access the host system.

Control Group Container ID Plain Text 1 & Control Group Container ID Plain Text 2

Initial Server Overview

For Initial Server Overview enumeration, combining the following commands provides comprehensive details about the system’s kernel, architecture and distribution, which are critical for understanding the environment and planning potential exploits. Knowing the exact OS and kernel version enables threat actors to choose the most effective exploits, as many vulnerabilities are version-specific.

User and Permission Enumeration

The following User and Permission commands provides insights into user accounts, privileges and group memberships, which are crucial for planning privilege escalation and lateral movement within a system.

Network Discovery

The following Network and Discovery commands help gather detailed insights into the system’s operating environment and network setup, which can be used to identify vulnerabilities and plan attacks.

Detailed System Commands

The ‘cat /etc/os-release’ command reveals the operating system distribution and version. Knowing the exact OS helps attackers identify specific vulnerabilities and tailor their exploits to the target’s environment.

User Related Commands

The ‘/etc/shadow’ file contains hashed passwords for user accounts, which, if accessed, can be used to crack passwords and gain elevated access to the system.

User Related Commands Data Output Plain Text

AWS Lambda Functions

The following example demonstrates Talos using the same commands previously mentioned within a Google Cloud Platform (GCP) environment, now applied in an Amazon Web Services (AWS) environment using Lambda functions. This illustrates that the method utilized by the Tenable lab can be adapted for other cloud-based environments, such as AWS.

Azure Functions

The following example demonstrates the same process performed with an AWS Lambda function, but instead utilizing Azure Functions within the Azure environment. This further proves that the method can be employed across various cloud-based environments.

Conclusion and Defense Summary

Google’s Response

As described in Tenable’s article, Google responded to their research by creating a remediation patch. This update altered the default behavior of Cloud Build and the default Cloud Build SA. Additionally, new organization policies were released to give organizations full control over which SA Cloud Build uses by default. While Google has implemented this remediation, Cloud Build services can still be used to execute non-privileged commands as a means of enumerating an environment.

Mitigation Summary

The most effective mitigation strategy to protect your environment from similar threat actor behavior is to ensure that all SAs within your cloud environment adhere to the principle of least privilege and that no legacy cloud SAs are still in use. Ensure that all cloud services and dependencies are up to date with the latest security patches. If legacy SAs are present, replace them with least-privilege SAs. 

Additionally, users with access to Cloud Functions should not have IAM permissions to the services included in the function’s orchestration.

Threat Hunting Recommendations

1. Audit and monitor SA permissions: Regularly audit and monitor SA permissions, with a particular focus on the default Cloud Build SA. Adhere to the principle of least privilege by removing any excessive permissions that are not essential for the SA’s operations.
2. Alert setup for Cloud Functions: Establish alerts for any unusual or unauthorized creation or modification of Cloud Functions. Identify potentially malicious activities where an attacker may be attempting to exploit function deployments for privilege escalation.
3. Inspect network traffic: Analyze network traffic for unusual patterns or connections that might indicate data exfiltration attempts. Pay attention to data being sent to unknown or unauthorized external endpoints, such as those using Ngrok or similar tunneling services.
4. Verify NPM package integrity: Ensure the integrity and authenticity of NPM packages used within Cloud Functions. Prevent the execution of malicious scripts embedded in package.json files that could facilitate environment enumeration or other malicious activities.
5. Detect environment enumeration: Detect and respond to signs of environment enumeration, such as ICMP discovery or system information gathering.

Cisco Talos Blog – ​Read More

Researchers have discovered a series of major security flaws in Apple AirPlay. They’ve dubbed this family of vulnerabilities – and the potential exploits based on them – “AirBorne”. The bugs can be leveraged individually or in combinations to carry out wireless attacks on a wide range of AirPlay-enabled hardware.

We’re mainly talking about Apple devices here, but there are also a number of gadgets from other vendors that have this tech built in – from smart speakers to cars. Let’s dive into what makes these vulnerabilities dangerous, and how to protect your AirPlay-enabled devices from potential attacks.

What is Apple AirPlay?

First, a little background. AirPlay is an Apple-developed suite of protocols used for streaming audio and, increasingly, video between consumer devices. For example, you can use AirPlay to stream music from your smartphone to a smart speaker, or mirror your laptop screen on a TV.

All this happens wirelessly: streaming typically uses Wi-Fi, or, as a fallback, a wired local network. It’s worth noting that AirPlay can also operate without a centralized network – be it wired or wireless – by relying on Wi-Fi Direct, which establishes a direct connection between devices.

Initially, only certain specialized devices could act as AirPlay receivers. These were AirPort Express routers, which could stream music from iTunes through the built-in audio output. Later, Apple TV set-top boxes, HomePod smart speakers, and similar devices from third-party manufacturers joined the party.

However, in 2021, Apple decided to take things a step further – integrating an AirPlay receiver into macOS. This gave users the ability to mirror their iPhone or iPad screens on their Macs. iOS and iPadOS were next to get AirPlay receiver functionality – this time to display the image from Apple Vision Pro mixed-reality headsets.

CarPlay, too, deserves a mention, being essentially a version of AirPlay that’s been adapted for use in motor vehicles. As you might guess, the vehicle’s infotainment system is what receives the stream in the case of CarPlay.

So, over two decades, AirPlay has gone from a niche iTunes feature to one of Apple’s core technologies that underpins a whole bunch of features in the ecosystem. And, most importantly, AirPlay is currently supported by hundreds of millions, if not billions, of devices, and many of them can act as receivers.

What’s AirBorne, and why are these vulnerabilities a big deal?

AirBorne is a whole family of security flaws in the AirPlay protocol and the associated developer toolkit – the AirPlay SDK. Researchers have found a total of 23 vulnerabilities, which, after review, resulted in 17 CVE entries being registered. Here’s the list, just to give you a sense of the scale of the problem:

1. CVE-2025-24126
2. CVE-2025-24129
3. CVE-2025-24131
4. CVE-2025-24132
5. CVE-2025-24137
6. CVE-2025-24177
7. CVE-2025-24179
8. CVE-2025-24206
9. CVE-2025-24251
10. CVE-2025-24252
11. CVE-2025-24270
12. CVE-2025-24271
13. CVE-2025-30422
14. CVE-2025-30445
15. CVE-2025-31197
16. CVE-2025-31202
17. CVE-2025-31203

These vulnerabilities are quite diverse: from remote code execution (RCE) to authentication bypass. They can be exploited individually or chained together. So, by exploiting AirBorne, attackers can carry out the following types of attacks:

• RCE – even without user interaction (zero-click attacks)
• Man-in-the-middle (MitM) attacks
• Denial of service (DoS) attacks
• Sensitive information disclosure

Example of an attack that exploits the AirBorne vulnerabilities

The most dangerous of the AirBorne security flaws is the combination of CVE-2025-24252 with CVE-2025-24206. In concert, these two can be used to successfully attack macOS devices and enable RCE without any user interaction.

To pull off the attack, the adversary needs to be on the same network as the victim, which is realistic if, for example, the victim is connected to public Wi-Fi. In addition, the AirPlay receiver has to be enabled in macOS settings, with Allow AirPlay for set to either Anyone on the Same Network or Everyone.

What’s most troubling is that this attack can spawn a network worm. In other words, the attackers can execute malicious code on an infected system, which will then automatically spread to other vulnerable Macs on any network patient zero connects to. So, someone connecting to free Wi-Fi could inadvertently bring the infection into their work or home network.

The researchers also looked into and were able to execute other attacks that leveraged AirBorne. These include another attack on macOS allowing RCE, which requires a single user action but works even if Allow AirPlay for is set to the more restrictive Current User option.

The researchers also managed to attack a smart speaker through AirPlay, achieving RCE without any user interaction and regardless of any settings. This attack could also turn into a network worm, where the malicious code spreads from one device to another on its own.

Finally, the researchers explored and tested out several attack scenarios on car infotainment units through CarPlay. Again, they were able to achieve arbitrary code execution without the car owner doing anything. This type of attack could be used to track someone’s movements or eavesdrop on conversations inside the car. Then again, you might remember that there are simpler ways to track and hack cars.

Staying safe from AirBorne attacks

The most important thing you can do to protect yourself from AirBorne attacks is to update all your AirPlay-enabled devices. In particular, do this:

• Update iOS to version 18.4 or later.
• Update macOS to Sequoia 15.4, Sonoma 14.7.5, Ventura 13.7.5, or later.
• Update iPadOS to version 17.7.6 (for older iPads), 18.4, or later.
• Update tvOS to version 18.4 or later.
• Update visionOS to version 2.4 or later.

As an extra precaution, or if you can’t update for some reason, it’s also a good idea to do the following:

1. Disable the AirPlay receiver on your devices when you’re not using it. You can find the required setting by searching for “AirPlay”.

2. Restrict who can stream to your Apple devices in the AirPlay settings on each of them. To do this, set Allow AirPlay for to Current User. This won’t rule out AirBorne attacks completely, but it’ll make them harder to pull off.

Install a reliable security solution on all your devices. Despite the popular myth, Apple devices aren’t cyber-bulletproof and need protection too.

What other vulnerabilities can Apple users run into? These are just a few examples:

• SparkCat trojan stealer infiltrates App Store and Google Play, steals data from photos
• Banshee: A stealer targeting macOS users
• How to snoop on Apple Vision Pro user passwords
• Are Macs safe? Threats to macOS users
• A matter of triangulation

Kaspersky official blog – ​Read More

When Microsoft first announced its “photographic memory” Recall feature for Copilot+ PCs a year ago, cybersecurity experts were swift in sounding the alarm. Recall’s many flaws posed a serious threat to privacy, prompting Microsoft to postpone its release for further refinement. The updated Recall came to Windows Insider Preview builds in April 2025, and was rolled out widely in May on devices equipped with the necessary hardware. The essence remains the same: Recall memorizes all your actions by continuously taking screenshots and using OCR to analyze their content. However, with the latest update, the security of this data has been significantly enhanced. How much difference does this actually make? And is the convenience of Recall really worth the potential loss of control over your personal data?

What’s new in Recall’s second coming

Since the initial announcement, which we covered in detail, Microsoft has addressed several key criticisms raised by cybersecurity professionals.

First, Recall now only activates with user permission during the initial system setup. The interface doesn’t manipulate users into agreeing with visual tricks like highlighting the “Yes” button.

Second, Recall’s database files are now encrypted, with key storage and cryptographic operations handled by the hardware-based TPM (Trusted Platform Module), making their extraction significantly more difficult.

Third, a special filter attempts to prevent saving screenshots or text when the screen contains potentially sensitive information — a private browser window, a payment data input form, password manager cards, and so on. Note it only “attempts”: testers have already reported numerous instances where confidential data slipped through the filter and ended up in the OCR database.

Ars Technica highlights several other positive changes:

• Recall is enabled for each PC user individually, rather than everyone at once.
• Recall can be uninstalled completely.
• A Microsoft account isn’t required.
• No internet connection is needed — all data is processed locally.
• To initially launch Recall, BitLocker disk encryption and Windows Hello biometric authentication (face or fingerprint recognition) must be enabled.
• Windows Hello authentication is required every time the Recall search is used.

Why Recall still poses risks

Microsoft has indeed put some effort into responding to the criticism. However, the current version of Recall still has a number of issues.

First, biometric authentication is only required during the initial setup of Recall. For subsequent launches, the AI assistant will also ask to confirm your identity, but presenting your face or fingerprint is no longer necessary. A regular Windows PIN will suffice, and it’s relatively easy for someone to take a peek at, or guess, your PIN, no matter whether you’re at home or at work. One reviewer admits to asking his girlfriend to find a screenshot of a specific Signal chat on his computer — she guessed the password and found the screenshot in just five minutes.

Second, Recall can also be re-activated without biometrics. If the account owner tried Recall but then disabled it, anyone who knows the PIN can re-enable screenshot capture and smart search. All that’s left is to wait a little while, log back in, and browse the results.

Third, as mentioned, automatic filtering of sensitive data is unreliable. In theory, Recall doesn’t take screenshots in many high-risk scenarios: when a browser window is opened in private mode, when remote access to another desktop is active, when entering payment info or passwords, and also on additional inactive displays and desktops. In practice, these situations aren’t always recognized — for example, the filter fails to detect the private mode in not-so-common browsers (such as Vivaldi) and remote desktops, including those accessed with the hugely popular AnyDesk.

Finally — and this deserves a whole category of its own — Recall meticulously logs the computer owner’s interactions with other users, potentially violating both their privacy rights and the data retention policies of messaging and collaboration tools. For example, if the computer owner is in a Zoom or Teams call with automatic transcription enabled, Recall will save a full recording of the call with a transcript of who said what. If a self-destructing WhatsApp or Signal chat is open on screen, Recall will save it anyway, despite the chat’s privacy policies. Photos and videos intended for one-time viewing will also be stored if just one person in the conversation uses Recall.

All of this matters in two dangerous scenarios: (i) when someone who knows (or can guess) the PIN gains unauthorized physical access to the computer; and (ii) when an attacker exploiting Windows vulnerabilities gains remote access to it. Year after year, despite the tightening of security measures, hackers keep finding ways to elevate privileges on compromised machines and exfiltrate information — even encrypted data.

Impact on performance and battery life

Although Recall was originally designed for high-performance PCs equipped with a dedicated chip for AI computing (NPU) — only found in models released over the past 12 months — the capture and processing of screenshots can still sometimes interfere with the user experience in such powerful PCs. This is particularly noticeable when playing games, as Recall diligently takes screenshots and records in-game dialogue, consuming significant memory and computing resources, thus loading the NPU by up to 80%! Even when the device isn’t plugged in (but the battery is almost fully charged), Recall continues working, draining the battery much faster than usual.

Who should disable or remove Recall?

Microsoft is now offering users a fair choice: enable Recall, ignore it, or completely remove it from the computer. This is a much better approach than previous campaigns to push Edge, Cortana, or Windows Media Player. If you see a screen prompting enabling Recall, consider whether you fall into one of these categories:

• Anyone working with trade secrets, other people’s confidential data, or personal data in general (e.g., lawyers, doctors, and other professionals).
• Active users of video conferencing, remote tech-support services, or other tech involving the handling of others’ information.
• People engaged in particularly private correspondence — especially using secure messengers and disappearing chats/messages.
• Individuals living with jealous or nosy family members, or working in an office with overly curious colleagues.

For all these users, we recommend steering clear of Recall — or, better yet, removing it entirely.

How to disable or remove Recall

To disable Recall:

1. Open Settings in the Windows Start menu and select Privacy & security.
2. Within Privacy & security, find the Recall & snapshots subsection.
3. In this subsection, toggle off Save snapshots, and click Delete snapshots to erase any data already collected.

To remove Recall completely:

1. In the Windows Start menu search bar, type Turn Windows features on or off.
2. In the retro-looking window that opens, locate the Recall entry.
3. Uncheck the box next to this item and click OK.

After this, Recall will be removed from your PC, and its settings will no longer appear under Privacy & security.

How to configure Recall if you decide to try it anyway

If you don’t fall into any of the categories above and really want to Recall something like “the photo where Jane’s cat is lying on the blue sofa”, we recommend taking a few precautions and adjusting your settings for better security:

• Disable less secure sign-in methods in Windows, such as pattern locks and PINs. Use only a strong password and biometric authentication.
• Manually add to Recall’s exclusion list all messengers you use for confidential correspondence, password managers, finance apps and websites, and any other apps or websites that may contain private information. For ethical reasons, it’s a good idea to exclude all video conferencing apps. For performance reasons, exclude all games.
• Set a screenshot retention period that suits your needs, keeping it to a minimum. Possible options range from 30 to 180 days.
• Periodically — ideally a few times a week — check Recall to see which apps and sites were recently captured. This will help you identify and manually delete or filter out any sources of sensitive information you may have missed earlier.

Regardless of your Recall settings or whether it’s installed at all, the two most common data leak scenarios are direct theft from your device by infostealer malware, and entering your credentials on a phishing site. To guard against these risks, be sure to use a comprehensive cybersecurity solution, such as Kaspersky Premium.

Under the pretense of user convenience — and sometimes without any pretense at all — various organizations collect information about you that you may not even be aware of. How? Read here:

• Turning purple: how visited links threaten your privacy
• How to track anyone via the Find My network
• How smartphones build a dossier on you
• Geolocation data brokers: What they do and what happens when they leak
• How to protect yourself from Bluetooth stalking and more

Kaspersky official blog – ​Read More

This year marks the 15^th anniversary of the first guide to implementing the zero trust security concept, which, according to a Gartner survey, almost two-thirds of surveyed organizations have adopted to some extent. Admittedly (in the same Gartner survey), for 58% of them this transition is far from complete, with zero trust covering less than half of infrastructure. Most organizations are still at the stage of piloting solutions and building the necessary infrastructure. To join the vanguard, you need to plan the transition to zero trust with eyes wide open to the obstacles that lie ahead, and to understand how to overcome them.

Zero trust best practices

Zero trust is a security architecture that views all connections, devices, and applications as untrusted and potentially compromised — even if they’re part of the organization’s internal infrastructure. Zero trust solutions deliver continuous adaptive protection by re-verifying every connection and transaction based on a potentially changed security context. This way, companies can mold their information security to the real-world conditions of hybrid cloud infrastructures and remote working.

In addition to the oldest and best-known guidelines, such as Forrester’s first report and Google’s BeyondCorp, the components of zero trust are detailed in NIST SP 800-207 (Zero Trust Architecture), while the separate NIST SP 1800-35B offers implementation recommendations. There are also guidelines that map specific infosec measures and tools to the zero trust methodology, such as CIS Controls v8. CISA offers a handy maturity model, though it’s primarily optimized for government agencies.

In practice, zero trust implementation rarely follows the rule book, and many CISOs end up having to mix and match recommendations from these guidance documents with the guidelines of their key IT suppliers (for example, Microsoft), prioritizing and selecting measures based on their specific situation.

What’s more, all these guides are less than forthcoming in describing the complexities of implementation.

Executive buy-in

Zero trust migration isn’t purely a technical project, and therefore requires substantial support on the administrative and executive levels. In addition to investing in software, hardware, and user training, it demands significant effort from various departments, including HR. Company leadership needs to understand why the changes are needed and what they’ll bring to the business.

To get across the value and importance of a project, the “incident cost” or “value at risk” needs to be clearly communicated on the one hand, as do the new business opportunities on the other. For example, zero trust protection can enable broader use of SaaS services, employee-owned devices, and cost-effective network organization solutions.

Alongside on-topic meetings, this idea should be reinforced through specialized cybersecurity training for executives. Not only does such training instill specific infosec skills, it also allows your company to run through crisis management and other scenarios in a cyberattack situation — often using specially designed business games.

Defining priorities

To understand where and what zero trust measures to apply in your infrastructure, you’ll need a detailed analysis of the network, applications, accounts, identities, and workloads. It’s also crucial to identify critical IT assets. Typically making up just a tiny part of the overall IT fleet, these “crown jewels” either contain sensitive and highly valuable information, or support critical business processes. Consolidating information about IT assets and their value will make it easier to decide which components are most in need of zero trust migration, and which infosec measures will facilitate it. This inventory will also unearth outdated segments of the infrastructure for which migration to zero trust would be impractical or technically infeasible.

You need to plan in advance for the interaction of diverse infrastructure elements, and the coexistence of different infosec measures to protect them. A typical problem goes as follows: a company has already implemented some zero trust components (for example, MFA and network segmentation), but these operate completely independently, and no processes and technologies are planned to enable these components to work together within a unified security scenario.

Phased implementation

Although planning for zero trust architecture is done holistically, its practical implementation should begin with small, specific steps. To win managerial support and to test processes and technologies in a controlled environment, start with measures and processes that are easier to implement and monitor. For example, introduce multi-factor authentication and conditional access just for office computers and the office Wi-Fi. Roll out tools starting with specific departments and their unique IT systems, testing both user scenarios and the performance of infosec tools, all while adjusting settings and policies accordingly.

Which zero trust architecture components are easier to implement, and what will help you achieve the first quick wins depends on your specific organization. But each of these quick wins should be scalable to new departments and infrastructure segments; and where zero trust has already been implemented, additional elements of the zero trust architecture can be piloted.

While a phased implementation may seem to increase the risk of getting stuck at the migration stage and never completing the transition, experience shows that a “big bang” approach — a simultaneous shift of the entire infrastructure and all processes to zero trust — fails in most cases. It creates too many points of failure in IT processes, snowballs the load on IT, alienates users, and makes it impossible to correct any planning and implementation errors in a timely and minimally disruptive manner.

Phased implementation isn’t limited to first steps and pilots. Many companies align the transition to zero trust with adopting new IT projects and opening new offices; they divide the migration of infrastructure into stages — essentially implementing zero trust in short sprints while constantly monitoring performance and process complexity.

Managing identities… and personnel

The cornerstone of zero trust is a mature Identity Access Management (IAM) system, which needs to be not only technically sound but also supported administratively at all times. Data on employees, their positions, roles, and resources available to them must be kept constantly up-to-date, requiring significant support from HR, IT, and the leadership of other key departments. It’s imperative to involve them in building formal processes around identity management, taking care to ensure that they feel personally responsible for these processes. It must be stressed that this isn’t a one-off job — the data needs to be checked and updated frequently to prevent situations such as access creep (when permissions issued to an employee for a one-time project are never revoked).

To improve information security and make zero trust implementation a truly team effort, sometimes it’s even necessary to change the organizational structure and areas of responsibility of employees — breaking down silos that confine people within narrow job descriptions. For example, one large construction company shifted from job titles such as “Network Engineer” and “Server Administrator” to the more generic “Process Engineer” to underscore the interconnectivity of the roles.

Training and feedback

Zero trust migration doesn’t pass unnoticed by employees. They have to adapt to new authentication procedures and MFA tools, learn how to request access to systems that don’t grant it by default be aware that they might occasionally need to re-authenticate to a system they logged in to just an hour ago, and that previously unseen tools like ZTNA, MDM, or EDR (often bundled in a single agent, but sometimes separate), may suddenly appear on their computers. All this requires training and practice.

For each phase of implementation, it’s worth forming a “focus group” of business users. These users will be the first to undergo training and can help refine training materials in terms of language and content, as well as provide feedback on how the new processes and tools are working. Communication with users should be a two-way street: it’s important to convey the value of the new approach, while actively listening to complaints and recommendations to adjust policies (both technical and administrative), address shortcomings, and improve the user experience.

Kaspersky official blog – ​Read More