IEEE Technology and Society Magazine - December 2020 - 67

GDPR Regulation and Malware/
Stegomalware Detection
There are specific challenges related to GDPR regulation
related to malware/stegomalware detection. A commonsense approach is to be aware that malware/stegomalware, even by its name and sole definition, is a crime that
breaks a number of laws. It is also obvious that malicious
software, when processing users' personal data of any
kind without their consent, is clearly against the GDPR as
well. However, a question arises as to whether malware/
stegomalware detection solutions that process the malicious software that processes personal data do comply
with the GDPR, then. Strictly speaking, there are no specific GDPR malware/stegomalware detection requirements. This results from the fact that being compliant
with the GDPR applies to all the methods of collecting,
processing, sharing, or storing EU citizen's personal data,
not just malicious software detection. However, as a substantial amount of personal data is likely to be processed
as part of cybersecurity solutions, it would be advisable
for the requirements to be considered as if they applied
to malware/stegomalware detection exclusively [23].
GDPR forced companies to actively take steps to
find, evaluate and protect the personally identifiable
information (personal data) of the EU people; if they do,
they must conduct data protection impact assessments
(DPIAs) in order to understand what personal data they
have under control. Tolbert [24] notices that in addition
to this, some companies, after asking themselves the
question of whether they need to keep the data at all,
put data minimization principles into action.
Tolbert [24] then points out the need to inventory
Human Resources (HR), Customer Relationship Management (CRM), Customer Identity Access Management
(CIAM), and Identity and Access Management (IAM) systems; they likely contain personal data. Finally, DPIAs
should be performed on security solutions themselves.
This is so, as Security Information and Event Management (SIEM), Enterprise Mobility Management (EMM),
Endpoint Detection and Response (Endpoint Security/
EDR) tools, etc., are likely to collect a lot of data for
analysis. In fact, the data harvested for ongoing security
and risk analysis may contain:
■
■
■
■
■
■

Usernames
Email addresses
User attributes, including organizational affiliations,
citizenship, group membership,
IP addresses
Geolocation
Data files created by users.

All of the aforementioned types of data are personal
data according to GDPR's definition.
DECEMBER 2020

∕

Does malware/stegomalware
detection software that process the
malicious software that processes
personal data comply with GDPR?
The majority of security solutions allow choosing
between on-premise analysis and cloud-based analysis.
Even the choice of the place where analyses take place
must be made according to GDPR principles. As an example, [24] mentions that the vendor's cloud, from which the
anti-malware solutions " scoop out " the files necessary for
deeper inspection, may be outside of the EU. Part of vendor solutions is configurable when it comes to the selection of attributes that can be collected and/or sent
elsewhere for analysis; some are not. As GDPR controls
any processing of personal data, and the definition of processing is very wide, scanning and analyzing of the data
most probably is included in GDPR as well.
Therefore, and again, in light of the GDPR, any
administrator should bear in mind whether information
has been collected with user consent. In some cases, it
will be necessary to obtain consent. In other cases, the
collection of data may be justified by performing contract or legal obligations, protecting the vital interests of
the data subjects, or performing a task in the public
interest. There are also cases where processing is necessary for the legitimate interest of the controller.
As [24] warns, there situations occur in which personal data must be processed by more than one data
processor. In such joint-processor scenarios, the
responsibility for ensuring that the use of personal data
is authorized under GDPR-specified purposes is placed
upon all the entities involved in the processing.
The following are the additional points that security
administrators should address, preferably with their
DPOs and legal teams: First, they should do DPIAs on
security solutions and thus determine which kinds of
data are being collected by the deployed security solutions. Then it is advisable to ascertain where this data
goes. Is it kept in local storage, or telemetry transmitted
to the cloud? In the latter case, does it stay in the EU or
goes outside it? GDPR has defined the notion of data
protection adequacy with regards to countries and organizations outside the EU. As of February 2019, the European Commission has made a full finding of adequacy
about several countries and territories, including Canada, Israel, Japan, the United States, etc. If there is no
" adequacy decision " about the country, territory or sector for the restricted transfer, it must be checked

IEEE TECHNOLOGY AND SOCIETY MAGAZINE

IEEE Technology and Society Magazine - December 2020

Table of Contents for the Digital Edition of IEEE Technology and Society Magazine - December 2020