According to Microsoft, the blue screen incident caused by a CrowdStrike Falcon security solution update affected more than 8.5 million computers worldwide. This incident has cost many companies dearly, and has also brought up a lot of debate about how to prevent similar situations from happening again.

First of all, no one is immune to errors; it’s simply impossible to guarantee the complete absence of bugs in complex software systems. However, a properly structured process for developing, testing, and delivering products and their updates to users’ devices can significantly minimize the risk of a serious failure. And we’ve had such a process firmly in place for years.

We, too, had incidents directly related to updates for our products. But the last time we had a notable problem of the kind was back way in 2013. After that unpleasant episode, we conducted a thorough analysis of the root causes — leading to a complete overhaul of our approach to the creation and testing of updates both in products for business and home users. And the system we built has proven itself to be very reliable: in 11 years we’ve not had a single failure of a similar magnitude.

We make no secret of the update release mechanisms we’ve built, and are ready to share them with the industry. After all, without the free exchange of best practices and solutions developed by different companies, progress in the cybersecurity industry will be hindered greatly. Among the main update release safeguarding mechanisms are multi-level testing, gradual rollout of updates, and automatic monitoring of anomalies. Let’s talk about them in detail.

Multi-level testing

There are two types of updates for our products — some are used for adding new detection logic, and some are for changing the functionality of a given product. Adding new functions potentially adds more risks, but sometimes logic updates can cause problems as well. Therefore, we carefully test both types of updates at different stages.

Checking for false positives

When creating and releasing detection rules (both those automatically generated and those written by analysts), we test them on an extensive database of legitimate (or “clean”) objects — files, web pages, behavior patterns, and so on. This way, false positives are identified and filtered out. We’ve an extensive and constantly updated collection of legitimate objects — both software and clean web resources — on which all created rules are tested.

One of the ways this collection is replenished is through our Allowlist Program, which allows software developers (both customers that develop and use their own solutions and independent vendors) to provide us with their software. This reduces the number of potential false positives and the risk of incorrect software classification.

Other methods for obtaining files and metadata include exchanging information with technological partners, using our Threat Intelligence Portal, and so on. In total, our database of legitimate objects contains information on around 7.2 billion objects.

Testing on virtual machines

But update testing isn’t limited to checking them on file collections. If no problems are detected at the first stage, all updated components then undergo multi-stage automatic testing on virtual machines with various configurations of security products, software and operating systems. Various scenarios are run related to our products and the operation of security mechanisms and also the imitation of typical user actions.

Regarding specifically product scenarios, these include a through file system scan, the process of the product update’s installation, rebooting after the update, and so on. This allows us to make sure that the product functions normally after the update, and neither crashes nor affects system stability. Each update goes through this check.

User scenarios simulate typical human behavior on a computer — opening a browser, visiting a web page, downloading a file, launching a program. This check allows us to make sure the product doesn’t have a negative impact on the computer’s performance, speed of work or stability.

Separately, updates are automatically tested for compatibility with industrial software (for example, SCADA systems). Any negative impact on solutions related to this sphere may lead to an inadmissible halt in production processes and potential financial damage.

Quality control

In addition to the above-mentioned checks, we also have a separate quality control team. Not a single product update release is delivered to our clients without confirmation of its readiness by its experts. It also, if necessary, adjusts and constantly improves the verification processes, and monitors the emergence of possible operational risks.

Phased release of updates of protective technologies

Of course, we are realists, and admit that this entire multi-level system of checks may still not be enough. For example, some third-party software will be updated at the same time as ours, and this may cause an unforeseen conflict. And in general, it’s impossible to predict all combinations of configurations of different programs and systems. Therefore, after an update affecting the functionality of security solutions is ready and approved, it doesn’t get sent to all our users’ computers at once. Instead, the updates are released in phases.

An update undergoes preliminary testing on machines in our own network before being published on public update servers. If no problems are detected, the update is first received by a very small number of randomly selected users. If no problems or failures are manifested, then the number of computers that receive the update gradually increases at certain intervals, and so on until the update is available to all users.

Automatic anomaly monitoring

So what happens if an update does cause problems? We monitor the behavior of updated solutions using voluntarily transmitted anonymized data through our KSN, and promptly halt update distribution if something goes wrong.

But most importantly, thanks to the combination of automatic anomaly monitoring and phased release of updates, an error would affect only a very small number of computers — hundreds, not millions or even thousands of them.

Testing updates on the client side

Our company provides the ability to check the received updates once again, only this time on the client side through the Kaspersky Security Center management console.

The client’s system administrators can establish an isolated test group of computers (or virtual machines) with the most common configuration and set of software for the organization’s network, and then create a task to check updates — specifying this test group as the target. In this case all incoming updates are first installed only on test machines, tested in action, and only after the test are they distributed across the entire company network. More information on how to set up such a check can be found on our technical support website.

We thoroughly analyze each and every problem related to software updates that may arise (including those identified in preliminary tests), come to understand the reasons for their occurrence, and then take measures to ensure they don’t happen again. In addition, we’ve implemented a practice of proactively identifying and assessing the risks for possible problems, and address them systematically. As a result of doing this throughout the entire lifetime of our company, we’ve established a multi-level system that allows us to significantly reduce the risk of new problems emerging.

Of course, in just one blog post it’s impossible to tell you everything about all the nuances of our multi-level system for checking product updates. However, if this topic arouses interest in the industry, we’re ready to continue sharing details. Only open cooperation of all players in the information security sphere can create an effective barrier to the actions of cybercriminals.

Kaspersky official blog – ​Read More

It’s been a month already since the US Department of Commerce issued its Final Determination with regard to the sales and use of Kaspersky products by US persons. The agency’s decision, if you happen not to be aware of it, in general terms was to ban Kaspersky products – with a few exceptions for informational and educational products and services – from the market. The outcome is the following: users in the US can no longer access the cybersecurity software they choose based on quality and expertise.

Throughout its 27-year history, our company has always been recognized as supplying the best protection on the market from all kinds of cyberthreats – no matter where they come from. Here are a few examples: earlier this year our products once again received the Product of the Year award from a renowned independent testing lab; from year to year our solutions have been demonstrating 100% protection against the most significant threat – ransomware; and it’s Kaspersky’s threat research team – respected both by the global InfoSec community and our users – that discovers, analyzes, and most importantly reveals to the world the biggest and most sophisticated state-sponsored espionage campaigns.

So, what might be the reason for banning best-in-class cybersecurity solutions trusted by millions? Has the problem been defined clearly and objectively? Have you seen any evidence of those risks that the US government has been referring to for years? We haven’t either.

While having to deal with the outcomes of growing protectionism (and its hard-hitting effects) – like zero-evidence claims of misconduct, and accusations based purely on theoretical risks – we’ve been continuously developing a universal methodology for cybersecurity product assessment, while remaining ever true to our key principle: being maximally transparent and open about how we do our work.

We became the first and remain the only major cybersecurity company to provide third parties with access to our source code, and we also allow our stakeholders and trusted partners to check our threat-detection rules and software updates in an unparalleled goodwill gesture. For several years already we’ve had our Global Transparency Initiative in place – unique in its scope and practical value – which once again reflects our cooperative attitude and determination to address any potential concerns regarding how our solutions work. Nevertheless, we still faced apprehensiveness regarding the reliability of our products – usually stemming from external factors like geopolitical conjecture – and so we went the extra mile by suggesting an even more thorough framework, which would assess the integrity of our security solutions throughout their lifecycle.

What I’ll be describing below is a framework we’ve been proactively sharing with the parties expressing concerns about the credibility of Kaspersky solutions – including those in the United States government. We believe the framework is comprehensive enough to address the most commonly expressed concerns, and is capable of forming a dependable chain of trust.

The key pillars of the cybersecurity assessment methodology we’ve been presenting (which, incidentally, we believe has the potential to form the basis of an industry-wide methodology) include: (i) the localization of data processing, (ii) the review of data received, and (iii) the review of both the information and updates delivered to user machines (as part of software and threat-database updates). Just as within our Global Transparency Initiative, the strategy’s core aim is the engagement of an external reviewer for checking the company’s processes and solutions. What, however, is new about this methodology is both the extent and depth of such reviews. Let’s look into the details…

Data processing localization

The matter of data processing and storage has been one of the most sensitive, not only for Kaspersky, but for the entire cybersecurity industry. We frequently get reasonable questions about what data our products can process, how this data is stored and, most fundamentally, why we need this data. The key purpose of data processing for Kaspersky is providing our users and customers with the very best cybersecurity solutions: by gathering data on malicious and suspicious files that we detect on user machines, we can train our algorithms – teaching them how to detect new threats and contain their spread.

The framework we’ve been presenting also implies greater localization of data processing infrastructure, and implementation of technical and administrative controls restricting access to such processing infrastructure for employees outside a given country or region. We already implement such an approach in delivering our Managed Detection and Response (MDR) service in Saudi Arabia, and the same mechanisms have been suggested in our discussions with the US authorities to alleviate their concerns. These measures would ensure that local data is both stored and processed in a physical environment where ultimate control over the data rests with persons under the local jurisdiction, or that of a closely allied country as deemed appropriate by these persons. Just as with the above-mentioned steps, an independent third-party validator might be invited to review the effectiveness of the measures implemented.

Local data processing requires local threat analysis and the development of local malware detection signatures, and our methodology provides for just that. Data processing localization requires expansion of human resources to support local infrastructure, and we’re prepared to further build up our regional R&D and IT teams in given countries. Such teams would be exclusively responsible for supporting the processing of domestic data, managing local data center software, and analyzing malware to identify new APTs specific to the given region. This measure would also ensure there are more international experts involved in the development of future Kaspersky product lines – making our R&D even more decentralized.

Data retrieval process review

We protect the data we gather against potential risks using rigorous internal policies, practices, and controls; we never attribute data gathered to a specific individual or organization, we anonymize it wherever possible, and we also limit access to such data within the company and process 99% of it automatically.

To further mitigate any potential risks to the data of our customers, we’ve suggested engaging a third-party authorized reviewer to periodically review our data retrieval process. Such a real time reviewer would periodically assess data we receive with data analytics tools and data processing platforms to make sure no personally identifiable information or other protected data is being transferred to Kaspersky, and to confirm that data retrieved is used solely for the detection of and protection against threats, and is appropriately handled.

Review of updates and data delivered to user machines

As a next step on the product side, the mitigation framework would be provided for regular third-party reviews of our threat-database updates and product-related software code development to mitigate supply-chain risks for our customers. Importantly, the third-party would be an independent organization reporting directly to a local regulator. This would be on top of Kaspersky’s existing rigorous and secure software development process, which focuses on mitigating risks – including a scenario where there’s an intruder in the system – to ensure no one can add unauthorized code to our products or AV databases.

But to further enhance security guarantees, the engagement of an external real-time reviewer is intended to assess the security of the code developed by Kaspersky engineers, suggest improvements, identify potential risks, and then determine appropriate solutions.

One of the scenarios of how such a check of threat-database updates can be organized is depicted below:

It’s important to emphasize that the third-party review can be either blocking or non-blocking, conducted either on a regular basis or once a critical mass of updates/components for review is accumulated, as well as applied to all or just a selection of components. The most advanced review option proposed involves real-time blocking – enabling reviewers to fully control the code delivered to user machines. A blocking review would stop any code during the review process from getting into a product or updates – and therefore to Kaspersky’s customers.

This comprehensive review process could be further enhanced by requiring the reviewer’s signature on all updates delivered to user machines after the underlying code has been confirmed and built. This would ensure that the code wasn’t altered after being reviewed in real time.

The proposed review not only enables real-time verification of the security of newly developed code, but also provides access to the entire source code – including its history. This allows the reviewer to fully assess the newly developed code, understand its changes over time, and see how it interacts with other product components.

Such an absolute code review would also be accompanied with access to a copy of the company’s software build environment, which mirrors the one used in Kaspersky – including compilation instructions and scripts, detailed design documentation, and technical descriptions of the processes and infrastructure. Hence, the real-time reviewer could build/compile code independently and compare binaries and/or intermediate build objects to shipped versions. The reviewer would also be able to verify build infrastructure and software for changes.

In addition, a trusted independent third-party could be provided with access to the company’s software development practices. Such independent analysis would aim to provide further guarantees that Kaspersky’s applied measures and processes match leading industry practices. The access would cover all relevant security documentation – including but not limited to: defining security requirements, threat modeling, code review, static and dynamic code verification, penetration testing, etc.

The bottom line is that, in our judgement, the aforesaid strategy can address most ICT supply-chain risks relating to product development and distribution in an effective and verifiable manner. And as I mention above, these are in fact the mitigation measures we’ve submitted in a proposal for discussion to the US Department of Commerce – once again confirming our openness to dialogue and determination to provide the ultimate level of security assurances. However, our proposal was simply ignored. This leads me to believe that the reason is based on the Department’s preconceived ideas. It seems that instead of assessing our proposal for its effectiveness in addressing the risks, it was examined to find an excuse to reject it.

While we have to admit that once again we’re having to deal with an act of digital protectionism, I know for a fact that the world is in acute need of a global cybersecurity risk-management strategy. It’s crucial to be able to address the evolving threat landscape effectively and ensure a unified approach to managing cybersecurity risks across diverse IT security domains. This approach could also help prevent short-sighted decisions depriving millions of users of their freedom of choice regarding credible cybersecurity protection and the creation of artificial restrictions on the exchange of data among cybersecurity professionals. Let’s allow these experts to focus on their important work without the additional burden of geopolitics – whose influence only benefits cybercriminals.

In an interconnected world where cyberthreats transcend borders, a global strategy is vital for bolstering cybersecurity defenses, enhancing trust, and promoting a more secure digital ecosystem. Our framework opens the door to a discussion within the industry about what a universal supply-chain cybersecurity assessment should look like – with the ultimate goal of building a reliable shield of trust and, consequently, a safer world.

And finally, for those seeking answers regarding the drastic new limitations on their freedom of choice, don’t forget that you can – and should – still have your say, by asking your questions directly, here.

Kaspersky official blog – ​Read More

Throughout May and June, the IT world watched the unfolding drama of Copilot+ Recall. First came Microsoft’s announcement of the “memory” feature named Recall that takes screenshots of everything happening on a computer every few seconds and extracting all useful information into a shared database. Then, cybersecurity researchers criticized Recall’s implementation by exposing security flaws and demonstrating the potential for data exfiltration — including of the remote kind. This forced Microsoft to backpedal: first stating the feature wouldn’t be enabled by default and promising improved encryption, and then delaying the mass rollout of Recall entirely — opting to first test it in the Windows Insider Program beta. Despite this setback, Redmond remains committed to the project and plans to launch it on a broad range of computers — including those with AMD and Intel CPUs.

Within the context of devices in the workplace — especially if a company allows BYOD — Recall clearly violates corporate data retention policies and significantly amplifies potential damage if a network is compromised by infostealers or ransomware. What’s more concerning is the clear intention of Microsoft’s competitors to follow this trend. The recently announced Apple Intelligence is still shrouded in marketing language, but the company claims that Siri will have “onscreen awareness” when processing requests, and text-handling tools available across all apps will be capable of both local or ChatGPT-powered processing. While Google’s equivalent features remain under wraps, the company has confirmed that Project Astra — the visual assistant announced at Google I/O —  will eventually find its way onto Chromebooks, utilizing screenshots as the input data stream. How should IT and cybersecurity teams prepare for this deluge of AI-powered features?

Risks of visual assistants

We previously discussed how to mitigate the risks of unchecked ChatGPT and other AI assistants’ usage by employees in this article. However, there we focused on the deliberate adoption of additional apps and services by employees themselves — a new and troublesome breed of shadow IT. OS-level assistants present a more complex challenge:

The assistant can take screenshots, recognize text on them, and store any information displayed on an employee’s screen — either locally or in a public cloud. This occurs regardless of the information’s sensitivity, current authentication status, or work context. For instance, an AI assistant could create a local, or even cloud-based, copy of an encrypted email requiring a password.
Captured data might not adhere to corporate data-retention policies; data requiring encryption might be stored without it; data scheduled for deletion might persist in an unaccounted copy; data meant to remain inside the company’s perimeter might end up in a cloud — potentially under an unknown jurisdiction.
The problem of unauthorized access is exacerbated since AI assistants might bypass additional authentication measures implemented for sensitive services within an organization. (Roughly speaking, if you need to view financial transaction data, even after being authorized in the system you need to enable RDP, raise a certificate, log in to the remote system, and enter the password again — or you could simply view it through an AI assistant such as Recall.)
Control over the AI assistant by the user and even IT administrators is limited. Accidental or deliberate activation of additional OS functions at the manufacturer’s command is a known issue. Essentially, Recall, or a similar feature, could appear on a computer unexpectedly and without warning as part of an update.

Although all the tech giants are claiming to be paying close attention to AI security, the practical implementation of security measures must stand the test of reality. Microsoft’s initial claims about data being processed locally and stored in encrypted form proved inaccurate, as the encryption in question was in fact a simple BitLocker, which effectively only protects data when the computer is turned off. Now we have to wait for cybersecurity professionals to assess Microsoft’s updated encryption and whatever Apple eventually releases. Apple claims that some information is processed locally, some within their own cloud using secure computing principles without storing data post-processing, and some — transmitted to OpenAI in anonymized form. While Google’s approach remains to be seen, the company’s track record speaks for itself.

AI assistant implementation policies

Considering the substantial risks and overall lack of maturity in this domain, a conservative strategy is recommended for deploying visual AI assistants:

Collaboratively determine (involving IT, cybersecurity, and business teams) which employee workflows would benefit significantly from visual AI assistants to justify the introduction of additional risks.
Establish a company policy and inform employees that the use of system-level visual AI assistants is prohibited. Grant exceptions on a case-by-case basis for specific uses.
Take measures to block the spontaneous activation of visual AI. Utilize Microsoft group policies and block the execution of AI applications at the EDR or EMM/UEM level. Keep in mind that older computers might not be able to run AI components due to technical limitations, but manufacturers are working to expand their reach to previous system versions.
Ensure that security policies and tools are applied to all devices used by employees for work — including personal computers.
If the first-stage discussion identifies a group of employees that could significantly benefit from visual AI, launch a pilot program with just a few of these employees. IT and cybersecurity teams should develop recommended visual assistant settings tailored to employee roles and company policies. In addition to configuring the assistant, implement enhanced security measures (such as strict user authentication policies and more stringent SIEM and EDR monitoring settings) to prevent data leaks and protect the pilot computers from unwanted/malicious software. Ensure that the available AI assistant is activated by an administrator using these specific settings.
Regularly and thoroughly analyze the pilot program’s group performance compared to a control group, along with the behavior of company computers with the AI assistant activated. Based on this analysis, decide whether to expand or discontinue the pilot program.
Appoint a dedicated resource to monitor cybersecurity research and threat intelligence regarding attacks targeting visual AI assistants and their stored data. This will allow for timely policy adjustments as this technology evolves.

Kaspersky official blog – ​Read More

Ever heard the unspoken rule: “Never release on Friday”? We have, but CrowdStrike hasn’t. They released a tiny driver on an ordinary Friday morning, which became the cause of a huge outage all over the world.

An incorrect update for CrowdStrike’s EDR (Endpoint Detection and Response) solution has affected Windows devices around the world — giving corporate users the Blue Screen of Death (BSOD). The failure has affected, for example, airport information systems in the US, Spain, Germany, the Netherlands and other countries.

Who else was affected by CrowdStrike’s Friday release and how to roll back bricked computers — all in this post…

What happened

It all started early Friday morning with corporate users around the world reporting problems with Windows. At first, a glitch in Microsoft Azure was blamed, but later CrowdStrike confirmed that the root cause was in the csagent.sys or C-00000291*.sys driver for its CrowdStrike EDR. And it was this driver that caused an abundance of silly office photos showing off the (dreaded) blue screens.

If we wanted to list everyone affected by this outage, such a list sure wouldn’t fit into this post – or dozens of them. So instead we’ll briefly cover the main victims of CrowdStrike’s negligence. Airline companies, airports, and people who want to either go home or go off on a long-awaited vacation were the most affected:

London’s Heathrow Airport, like many others, announced flight delays due to a technology glitch;
Scandinavian Airlines posted a notice on its website saying, “Some customers may experience difficulties with their bookings due to an IT issue affecting several countries. SAS is fully operational but delays are expected”;
In New Zealand, banking, communications and transportation systems are experiencing problems.

Various medical centers, chain stores, the New York subway, the largest bank in South Africa and many other organizations that make lives more comfortable and convenient on a daily basis were affected. The fullest list of those affected by the outage we can find is here — and it’s growing by the minute.

How to fix it

At this stage, it’s rather problematic estimating how long it’ll take to fully restore the affected computers around the world. Things are complicated by the fact that users need to manually reboot their computers in Safe Mode. And in large corporations, this is usually impossible to do on your own without the help of a system administrator.

Nevertheless, here are the instructions for how to get rid of the blue screen of death caused by the CrowdStrike driver update:

Boot your computer in Safe Mode;
Go to C:WindowsSystem32driversCrowdStrike;
Locate and delete the csagent.sys or C-00000291*.sys file;
Restart your computer in normal mode.

And while your sysadmins are doing this, you could use a hack that’s come out of India today: employees of one of the country’s airports have started filling out boarding passes… manually.

How the failure could have been avoided

Avoiding this situation should have been straightforward. First, the update shouldn’t have been released on a Friday. This is as per a rule that’s been known to all in the industry since the year dot: if an error occurs, there’s too little time to fix it before the weekend, so the system administrators at all companies affected need to work over the weekend to fix things.

It’s important to be as responsible as possible about the quality of updates released. We at Kaspersky launched a program back in 2009 to prevent mass failures such as this one at our customers, and passed an SOC 2 audit, which confirms the security of our internal processes. For 15 years now, every update has been subjected to multi-level performance testing on various configurations and operating system versions. This allows us to identify potential problems in advance and resolve them on the spot.

The principle of granular releases should be followed. Updates should be distributed gradually, not all at once to all customers. This approach allows us to react instantly and stop an update if necessary. If our users have a problem, we register it, and its solution becomes a priority at all levels of the company.

As with cybersecurity incidents, in addition to fixing the visible damage, you need to find the root cause to prevent these types of problems repeating in the future. It’s necessary to check software updates on test infrastructure for operability and errors before rolling them out to the company’s “combat” infrastructure, and to implement changes gradually — continually monitoring for possible failures.

Incident handling should be based on an integrated approach to building protection from a trusted supplier with the strictest internal requirements for the security, quality and availability of its services. The basis for this work can be the Kaspersky Next line of solutions. This will help your company not only stay afloat — but also increase the efficiency of your information security system. This can be done either gradually — increasing protection step by step — or all in one go. Protect your infrastructure today with us so that the next global outage doesn’t affect your customers.

And we, for our part, can help you make this decision: switch to Kaspersky and unlock two years of Kaspersky Next EDR Optimum for the price of one. Experience the pinnacle of robust, reliable cybersecurity protection!

Kaspersky official blog – ​Read More

In today’s digital age, our social and romantic interactions are increasingly online, and the normalization of both storing and sharing intimate images has reached concerning levels. Our recent global study – one of the largest polls ever conducted on this matter – reveals some alarming trends, and highlights the urgent need for both awareness and education on intimate image abuse, commonly known as “revenge porn”.

The digital age of intimacy

Nearly a quarter of the people surveyed in our poll have explicit images saved on their devices – with the highest rates among younger age groups. Specifically, 34% of 16–24-year-olds and 25–34-year-olds admitted storing such images. Additionally, 25% of respondents have shared intimate images with people they’re dating or chatting with online – with this figure rising to 39% among 25–34-year-olds.

Despite the widespread sharing of intimate images, only 21% of those who’ve shared an image requested its deletion from the recipient’s device. This statistic highlights a troubling lack of awareness about the long-term consequences of sharing intimate images.

The dark side of image sharing

The study also exposes a darker side of intimate image sharing. Shockingly, 8% of those who’ve shared nude or explicit material admitted to doing so for revenge, and 9% – to frighten others. Nearly half of all respondents reported that they’ve either experienced intimate image abuse themselves, or know someone who has. This issue is particularly pronounced among younger generations, with 69% of 16–24-year-olds and 64% of 25–34-year-olds reporting such experiences.

Aaliyah’s story is a stark reminder of this reality; her ex-partner maliciously shared her intimate images online, causing severe emotional and psychological impacts.

Victim blaming: a harmful misconception

One of the most disturbing findings of our study is the prevalence of victim blaming. Precisely half of the respondents believe that if you share an intimate image of yourself, it remains your fault if it ends up in the wrong hands. This harmful misconception contributes to the stigma and isolation victims feel, making it harder for them to seek help and support.

We need to emphasize this: if someone shares your intimate images without your consent, it’s not your fault. The blame lies solely with those who misuse and exploit these images and, by definition – your trust. Alice’s story illustrates this perfectly. After her partner’s death, she found intimate images of herself online — images that were secretly taken while she was sleeping, highlighting that the real culprit is the one who takes and shares these images without explicit permission.

No one should have to suffer the emotional and psychological harm caused by intimate image abuse, and it’s crucial that we all work to change the narrative around this issue.

Protect yourself online

To protect yourself from intimate image abuse, consider the following tips:

Think before you post: be mindful of who you share your data with, and consider the potential risks;
Use secure messengers: opt for messaging services with end-to-end encryption;
Report abuse: if you believe you’re a victim of intimate image abuse, keep evidence and report it to the police and the respective platforms;
Check permissions: regularly review the permission settings on your apps to control data sharing;
Use strong passwords: employ a reliable security solution to create and manage unique passwords for each account;
Utilize resources: take advantage of tools like StopNCII.org to help prevent intimate images being shared online without your consent;
Find an organization in your country to provide you with further support.

The findings from our study make it clear that, while technology has made intimate image sharing easier, it has also increased the risk of abuse. Awareness and education are crucial in mitigating these risks and protecting individuals from the emotional and reputational harm associated with intimate image abuse.

For more information and resources, subscribe to our Telegram channel, and visit our blog and the revenge porn helpline in your country.

Kaspersky official blog – ​Read More