Emerging pci dss v4 data security and privacy for hybrid cloud

1
Emerging PCI DSS v4
Data Security and
Privacy for Hybrid Cloud
Ulf Mattsson
www.TokenEx.com
Parasoft

2
Ulf Mattsson
www.TokenEx.com
Parasoft
Please submit your
questions during our
session!

3
1. Head of Innovation at TokenEx
2. Chief Technology Officer at
• Protegrity
• Atlantic BT
• Compliance Engineering
3. Developer at IBM Research and Development
4. Inventor of more than 70 issued/awarded US Patents
5. Products and Services
• Contributed to the development of PCI DSS and ANSI X9
• Security and Privacy Benchmarking/Gap-analysis for Financial Industry
• Data Encryption, Tokenization, and Data Discovery,
• Robotics and Applications in Manufacturing,
• Cloud Application Security Brokers, and Web Application Firewalls,
• Managed Security Services, and Security Operation Centers
Ulf Mattsson

4
A first draft of PCI DSS v4.0
• The October RFC will include a first draft of PCI DSS v4.0 and a sample of the draft
reporting template for a proposed new validation method to support customized
implementations.
• A Summary of Changes document that outlines the key changes in the draft will be
provided, as well as guidance for stakeholders to help focus their reviews and maximize
the value of their feedback.
• The draft of PCI DSS v4.0 addresses feedback received during the 2017 RFC and reflects
changes in payments environments and security technologies.
• The updates made to the standard focus on strengthening security and adding
flexibility.
• While the 12 core PCI DSS requirements remain fundamentally the same, several new
requirements are proposed to address evolving risks and threats to payment data and to
reinforce security as a continuous process.
• Additionally, all requirements are redesigned to focus on security objectives, and there
is a new validation option that gives more flexibility to organizations using different
methodologies to meet the intent of PCI DSS requirements.
Source: pcisecuritystandards.org

5
How can you get involved in the RFC process?
There are two ways: The PCI SSC is opening up the RFC process only to Participating Organizations, QSAs, and ASVs.
If you are not currently a Participating Organization, consider joining now, so that you can provide feedback on the PCI
DSS and attend future PCI Community Meetings for no additional cost.
Simply contact your LBMC Information Security lead QSA to let us know of your interest in reviewing the draft of PCI
DSS v.4.0.
Reference Links:
https://blog.pcisecuritystandards.org/5-questions-about-pci-dss-v4-0
https://blog.pcisecuritystandards.org/3-things-to-know-about-pci-dss-v4-0-development
https://blog.pcisecuritystandards.org/pci-dss-looking-ahead-to-version-4.0
Source: https://www.lbmc.com

6
PCI DSS has always been technology neutral
• PCI DSS has always been technology neutral, in that requirements are intended to apply
to all type of environments and support whatever technology being used.
• The draft of PCI DSS v4.0 further supports the use of different technologies, such as
cloud, by introducing more flexibility to the wording of requirements and adding intent
statements.
• The standard is also supported by information supplements that provide guidance and
considerations for applying PCI DSS to specific technologies, including cloud
environments.

7
4.0 Supporting a range of evolving payment environments,
technologies, and methodologies
• With version 4.0, the Council is evolving the PCI DSS to support a range of evolving
payment environments, technologies, and methodologies for achieving security.
• The requirements will be written as outcome-based statements focused on
implementation of the security control as the end result.
• For many requirements, this is achieved by simply changing the language from stating
what ‘must’ be implemented to what the resulting security outcome ‘is’.
• The draft of PCI DSS v4.0 also includes intent statements specifically linking each
requirement to a security outcome.
• The intent statements directly support the new, customized validation approach by
clearly identifying the security outcome that customized implementations are required
to meet.
• This will clarify what needs to be achieved with more flexibility in ‘how’ the organization
achieves the desired security outcome.

8
Changes to PCI DSS’s layout and descriptions
The overall structure of the PCI DSS is retained in version 4.0, and will keep the same 12 high level requirements.
Changes to PCI DSS’s layout and descriptions v.4.0 will include:
1. More accurate requirement titles
2. Additional direction and guidance provided in the Overview section
3. Requirements organized into Security Objectives
4. Requirements refocused as objective or outcome-based statements
5. Clear identification of Intent (Objective) for each requirement
6. Expanded Guidance
As with previous iterations of the PCI DSS, LBMC expects that there will be a grace period for organizations to comply
with the newly defined requirements, and PCI DSS version 3.2.1 will remain valid for a period of time to support
organizations transitioning to the new version of the standard.

9
Examples of some of the proposed new requirements
• Examples of some of the proposed new requirements include requirements for
organizations to verify their PCI DSS scope and some additional requirements for service
providers.
• There are also proposed revisions to requirements on passwords to accommodate
different authentication options, and an update to the risk assessment requirement to
provide greater clarity and guidance for organizations on the risk management process.
• The PCI DSS version being provided for RFC is a draft only.
• There may be requirements added, removed, or changed before the standard is finalized
sometime 2020.

10
The next major evolution of the 15-year old PCI DSS
PCI DSS v.4.0 is the next major evolution of the 15-year old PCI DSS framework since the last significant
revision in 2013:
1. Scoping – Increased testing and documentation will be required for confirmation of the accuracy and
completeness of scope of the cardholder data environment (CDE) and periodic scope validation processes.
2. CHD Protection – Card encryption requirements will be expanded to include all transmissions of CHD instead of
only those across public networks.
3. Security awareness training – Requirements for training of end users will be enhanced to include more
information regarding current threats and phishing, social engineering, etc.
4. Risk assessment – The Council recognizes that the current PCI DSS requirement that a risk assessment be
conducted is not always resulting in useful risk analysis and risk management outcomes. This requirement will be
modified to ensure that the risk assessment is not being treated as a “checkbox exercise” by organizations.
5. Authentication – The new version of the DSS will provide more flexibility for the use of authentication techniques
and solutions within the CDE to align them with industry best practices.
6. Cloud environments – Version 4.0 will evolve all requirements to be more accommodating for the use of
technologies such as cloud hosting services.
7. Sampling – Additional direction for assessors on sampling guidance will be included to verify that controls are in
place consistently across the entire population.

11
Two Implementation Options
Source:
Slide from the
2019 PCI North
America
Community
Meeting ,
lbmc.com

12
Flexibility to take a customized approach
• The new validation option gives organizations the flexibility to take a customized
approach to demonstrate how they are meeting the security intent of each PCI DSS
requirement.
• This customized approach supports organizations using security approaches that may be
different than traditional PCI DSS requirements.
• Through customized validation, entities can show how their specific implementation
meets the intent and addresses the risk, providing an alternative way to meeting the
requirement as stated.
• By offering two approaches to PCI DSS validation, entities can identify which approach is
best suited to their security implementation for each PCI DSS requirement.
• Customized validation is a natural evolution of compensating controls, which were
designed as a mechanism for organizations to demonstrate how they meet the intent of
PCI DSS requirements in a different way.
• Unlike compensating controls, customized validation will not require a business or
technical justification for meeting the requirements using alternative methods, as the
requirements will now be outcome-based.
• Compensating controls will be removed

13
The “Defined Implementation” Approach
• The Defined Implementation Approach is based upon the current PCI methodology and
is how entities currently assess and report their compliance with PCI DSS.
• The Customized Implementation Approach provides additional levels of flexibility for
assessing and reporting compliance.
• In this approach, the entity is responsible for understanding the intent of each PCI DSS
requirement and demonstrating how its existing security controls achieve the
requirement (which may deviate from the PCI DSS control specifications).
• Organizations can choose to report their compliance via one of these two options or
choose a blended approach where some of the control requirements may be assessed
under the defined implementation and others using the customized implementation
approach.

14
PCI compliance using the Defined Approach
Entities choosing to validate their PCI compliance using the Defined Approach will continue
to assess and validate their compliance in the same manner that they have previously
done.
These entities will be responsible for implementing and validating all of the PCI DSS v.4.0
requirements as written, and, entities using a QSA will find that the QSA firm continues to
execute the testing procedures as specified in the PCI DSS Report on Compliance. In this
approach:
The Entity:
Implements and operates control(s) that meets the PCI DSS requirement.
The Assessor:
Plans and conducts the assessment.
Follows PCI DSS testing procedures to assess implemented controls.
Documents results of testing in the RoC.

15
Customized Approach requires more steps by QSA and Entity
Source: lbmc.com

16Source: PCI SSC
PCI DSS v4.0 Controls Matrix – Example of Minimum Information

17
PA-DSS and the PCI Software Security Framework (PCI SSF)
The PCI SSF supports a broader array of payment software types, technologies, and development
methodologies. Ultimately PA-DSS and its validation program will be incorporated into the PCI SSF.
Source:
PCI SSC

18
The PCI Software Security Framework (PCI SSF)
SSF series of documents:
1. The Secure Software Lifecycle (Secure SLC or SSLC) Requirements and Assessment Procedures, or the Secure Software
Lifecycle (SLC) Standard
2. The Secure Software Requirements and Assessment Procedures, or the Secure Software Standard
3. The Validation Program, a program for software vendors to validate how they can properly manage the security of
payment software throughout the entire software lifecycle
Example: SD Tool Elements helps with:
1. Minimizing the Attack Surface: confidentiality and integrity of all software
2. Software Protection Mechanisms
3. Secure Software Operations
4. Secure Software Lifecycle Management
5. Account Data Protection
Source:
PCI SSC,
securitycompass.com

19
The new API Economy - Security for Application Microservices
Source: Gartner
Source: Gartner

20
The new API Economy - Products Delivering API Security
Source: Gartner

21
Develop and Test Customized Implementation (Time/$)
The Entity:
Implements control(s) that meet the intent of the PCI DSS requirement.
At a detailed level, the entity will be required to provide documentation that describes the customized
implementation for each control objective to include:
1. The who, what, where, when, and how of the controls
2. Evidence to prove how the controls meet the stated intent
3. Evidence of how controls are maintained, and effectiveness is assured.
The documentation of customized controls must be supported by the entity’s risk assessment to show how the
controls provide equivalent levels of protection.
The Assessor:
1. Plans and conducts the assessment.
2. Reviews information provided by the entity.
3. Develops and derives testing procedures based on controls implemented by the entity and information provided.
4. Documents details of testing procedures and results of testing in the RoC.
5. Assessor firms conducting Customized Approach assessments will need to spend additional time during the RoC
assessment process understanding their clients’ customized control processes and then developing sufficient
testing procedures such that the assessor can confirm the effective implementation and operation of the
customized controls, as well as that those controls do indeed provide equivalent (or better) security as the defined
PCI DSS control.

22
Source:
itnews.com
Trustwave had been contracted to perform yearly checks of Heartland's compliance with the
Payment Card Industry Data Security Standards (PCI-DSS) requirements in 2005, moving on to
monthly security scans, network penetration testing and other security services for the
payments processor.
Despite this, Trustwave did not detect that hackers had installed malware in 2007 through a
structured query language (SQL) attack that allowed the attacker to issue commands to an
internet-exposed database, the insurers allege.
The insurers also claim Trustwave missed a May 2008 installation of malware on Heartland's
systems.
Lexington and Beazley say the security vendor certified Heartland as PCI-DSS compliant during
both 2007 and 2008.
As a result of the data breach, in 2009 Visa removed Heartland from its list of PCI-DSS
compliant payments processors and said Trustwave had incorrectly certified the company as
being compliant with the industry security standard.
Trustwave missed that Heartland did not use a firewall, used default passwords, generally
failed to secure systems and applications as well as protect user data, and had no network
access monitoring in place, Visa said in its list of PCI-DSS requirement breaches at the time.
Liability Aspects with Customized Approach?

23
Understanding the Intent of the Requirements
Source: pcisecuritystandards.org, Verizon 2019 Payment Security Report
Emphasize Security and Risk Management to Attain and Maintain Compliance – Compliance does not equal security.
While PCI DSS provides a solid baseline of security controls, it should not be considered a single source for addressing
all security needs.
The focus should be on building a culture of security and protecting an organization’s information assets and IT
infrastructure, allowing compliance to be achieved as a consequence.

24
Best Practices for Maintaining PCI DSS Compliance
Source: Verizon 2019 Payment Security Report

25
Best Practices for
Maintaining PCI
DSS Compliance
Source: Verizon 2019
Payment Security Report

26
Best
Practices for
Maintaining
PCI DSS
Compliance

27

28
Source: Verizon 2019
Payment Security
Report

29
Shared
responsibilities
across cloud
service models
Source:
Microsoft
Still Customer
Responsibility for:
• User security
• (App security)
• Data security

30
Cloud Models and Risk Aspects
Risk
Elasticity
Out-sourcedIn-house
On-premises
system
On-premises Private
Cloud
Hosted Private Cloud
Public Cloud
Low -
High -
Compute Cost
- High
- Low
Risk Adjusted Computation

31
The Day When 3rd Party Security Providers
Disappear into Cloud
• “Active Directory”
• WAF
• SIEM
• Firewall
• Encryption
• Tokenization
• Key Management
• AV – Anti Virus
• Network Sec
Public Cloud / Multi-
cloud
Example pricing:
10 % of on-premises alternatives
On-premises

32
Payment
Application
Payment Systems
Remote
User
Internal
User
Payment
Application
Data Protection for Multi-cloud
Data Tokenization / encryption
Secure
Cloud
Armor.
Payment
Network
Data Tokens

33Source: Cloudvisory
Where are my Applications and Data?

34
Some Privacy
Regulations
Sweden, The Data Act, a national data
protection law went into effect in 1974
India is in the process of passing a
comprehensive data protection bill that
would include GDPR-like requirements
Japan is ready to
implement changes to
domestic legislation to
strengthen privacy
protection in the
country
Brazil passing a comprehensive
data protection regulation
similar to GDPR
1970, Germany passed the first
national data protection law, first
data protection law in the world
The New York Privacy Act
was introduced in 2019
Source: Forrester, PwC
CCPA's impact is
expected to be
global (12+ %),
given California's
status as the fifth
largest global
economy
68% of American companies are expected to spend between $1 million and $10
million to meet the GDPR requirements, and 9% more than $10 million (PwC)

35
Fines for Privacy Violations
• In 2019, Facebook settled with the Federal Trade Commission in the United
States over privacy violations, a settlement that required the social network to
pay $5 billion
• British Airways was fined £183 million by the UK ICO for a series of data
breaches in 2018, followed by a £99 million fine against the Marriott
International hotel chain.
• French data protection regulator CNIL fined Google €50 million in 2019.
• Some companies narrowly avoided a GDPR-scale fine, as their data incident
occurred prior to GDPR's implementation date.
• Both Equifax and Facebook received the maximum fine possible - £500,000
- as per the previous Data Protection Act 1998.
Source: rsaconference.com

36
• Verizon Data Breach Investigations Report
• Enterprises are losing ground in the fight against persistent cyber-attacks
• We simply cannot catch the bad guys until it is too late. This picture is not
improving
• Verizon reports concluded that less than 14% of breaches are detected by
internal monitoring tools
• JP Morgan Chase data breach
• Hackers were in the bank’s network for months undetected
• Network configuration errors are inevitable, even at the largest banks
• Capital One data breach
• A hacker gained access to 100 million credit card applications and accounts
• Amazon Web Services, the cloud hosting company that Capital One was
using
• Imperva breach
• A security breach which led to the compromise of customer data at
Imperva was caused by a stolen API key for one of its Amazon Web Services
(AWS) accounts, the firm has revealed.
• The firm was notified of the incident, which affected a subset of its Cloud
WAF customers, by a third party at the end August.
Enterprises Losing Ground Against Cyber-attacks

37
PCI Vs. GDPR: What’s The Difference?
Source: securitymetrics.com

38
Pseudonymisation Under the GDPR
Within the text of the GDPR, there are multiple references to
pseudonymisation as an appropriate mechanism for protecting personal
data.
Pseudonymisation—replacing identifying or sensitive data with
pseudonyms, is synonymous with tokenization—replacing identifying or
sensitive data with tokens.
Article 4 – Definitions
• (1) ‘personal data’ means any information relating to an identified
or identifiable natural person (‘data subject’); …such as a name, an
identification number, location data, an online identifier…
• (5) ‘pseudonymisation’ means the processing personal data in such
a manner that the data can no longer be attributed to a specific
data subject without the use of additional information, provided that
such additional information is kept separately…
What is Personal Data according to EU GDPR?

39
Source: IBM
Encryption and
TokenizationDiscover
Data Assets
Security
by Design
EU GDPR Security Requirements – Discovery, Encryption and
Tokenization

40
Data sources
Data
Warehouse
In Italy
Complete policy-
enforced de-
identification of
sensitive data across
all bank entities
Tokenization for Cross Border Data-centric Security (EU GDPR)
• Protecting Personally Identifiable Information
(PII), including names, addresses, phone, email,
policy and account numbers
• Compliance with EU Cross Border Data
Protection Laws
• Utilizing Data Tokenization, and centralized
policy, key management, auditing, and
reporting

41
GDPR and California Consumer Privacy Act (CCPA)
ISSA International

42
GDPR and California Consumer Privacy Act (CCPA)
ISSA International

43
Application of Data Security and Privacy techniques On-premises, in Public, and Private Clouds
Vault-based tokenization
(VBT)
Suitable for cloud deployment and centralized token generation. CPU impact and latency is typically similar
to a database lookup query transaction.
Vault-less tokenization
(VLT)
Suitable for on-premises deployment and distributed token generation. Suitable for high performance
requirements, including transaction switches and Datawarehouse databases. CPU impact is typically similar
to AES encryption.
Format Preserving
Encryption (FPE)
Suitable for any deployment model. CPU impact is typically 10 times more than AES encryption
Homomorphic Encryption
(HE)
Suitable for public cloud based computation with operations on encrypted data values is required. CPU
impact for asymmetric crypto operational can be significant compared to AES and other symmetric crypto
algorithms.
Masking
Since masking is a one-way process, not reversable, it may be less suitable in operational transaction
systems.
Server Model
Suitable for cloud deployment models. CPU impact for cleaning the database similar to a database scan with
change transactions.
Local Model
Suitable for client side of any deployment model. CPU impact for cleaning the database is similar to a
database scan with change transactions.
L-diversity
Suitable for privacy for any deployment model. CPU impact for cleaning the database similar to a database
scan with change transactions.
T-closeness
Suitable for privacy in any deployment model. CPU impact for cleaning the database similar to a database
scan with change transactions.
Tokenization (T)
Privacy enhancing data de-identification terminology and
classification of techniques
Cryptographic
tools (CT)
Formal privacy
measurement models
(PMM)
Differential
Privacy (DP)
K-anonymity
model
De-identification
techniques (DT)
Data Security and Privacy and On-premises and Clouds Models

44
User
Payment
Application
Payment
Network
Payment
Data
Tokenization (VBT),
encryption
and keys
User CASB Salesforce
User
Data
Warehouse
PII Data
Tokenization
(VLT) User
Analytics
Application
User
Call Center
Application
Format Preserving Encryption (FPE) Differential Privacy (DP),
K-anonymity model
User
Dev/test
Systems
Vault-less tokenization (VLT)
Masking
PII
Data
PII Data
Vault-based
tokenization (VBT)
Microsoft
ElectionGuard
development kit
Homomorphic
Encryption (HE)
PII Data
Election
Data
Use Cases in Different Systems

45
New York's Privacy Bill Is Even Bolder Than (CCPA) – Right to Sue,
Companies of All Sizes
The New York Privacy Act introduced in 2019, according to “New York's Privacy Bill Is
Even Bolder Than California's,” at [3], would “give residents there more control over
their data than in any other state.” It would also require businesses to put their
customers’ privacy before their own profits. The New York Privacy Act bears some
similarity to the California law. Like the CCPA, it would allow people to find out what
data companies are collecting on them, see who they’re sharing that data with, request
that it be corrected or deleted, and avoid having their data shared with or sold to third
parties altogether. But the New York bill, as it’s currently written, departs from the
California model in significant ways. While the California law leaves enforcement to the
state’s attorney general, the New York Privacy Act would give New Yorkers the right to
sue companies directly over privacy violations, possibly setting up a barrage of individual
lawsuits. Industry groups vehemently opposed a similar provision—also known as a
private right of action—in California, and they succeeded in driving it out of the bill
when it was finally signed into law last year. And while California’s law applies only to
businesses that make more than $25 million annual gross revenue, the New York bill
would apply to companies of any size.
Source: New York's Privacy Bill Is Even Bolder Than California's,
https://www.wired.com/story/new-york-privacy-act-bolder/

46
PII Inventory
• Locating sensitive PII is essential to protecting it.
• However data maps alone can't provide a complete protection or privacy
picture.
• New privacy protection regulations mandate an individual's right to
access their own data, the right-tobe-forgotten, the right to port their
data and the right to be notified of a breach.
Source: BigID (TokenEx partner)

47
Gartner Hype Cycle for Data Security
Data Classification

48Source: Verizon 2019 DBIR, data-breach-investigations-report
Term clusters in criminal forum and marketplace posts

49
Classify
your
Database
Source: Microsoft
Azure

50
Classify
your
DB
Source:
Microsoft
Azure

51
Gartner Hype Cycle for Data Security
Privacy by Design
(EU GDPR)

54
Type of
Data
Use
Case
I
Structured
How Should I Secure Different Types of Data?
I
Un-structured
Simple –
Complex –
PCI
PHI
PII
Encryption
of Files
Card
Holder
Data
Tokenization
of Fields
Protected
Health
Information
Personally Identifiable Information

55
Minimization Devaluation/Pseudonymisation/
Tokenization
Data Hashing/Masking Encryption
DataUtility
Data Protection
Max
Utility
Min
Utility
Min
Protection
Max
Protection
Source:TokenEx
Comparing Different Data Security Approaches

56
Source:PCI SSC,
TokenEx
What is the threat model for a tokenization system?
• For a vaulted solution, the tokens are mathematically unrelated to the underlying value to the most effective attack
vector is through our customers.
• The tokens themselves cannot successfully be attacked but the ability to detokenize sensitive data is only as strong as
the customer’s environment and the controls put in place to protect the API credentials.
Best practices:
1. The tokenization product should implement monitoring to detect any malfunctions, anomalies, and suspicious
behavior.
2. Mechanisms should be in place to ensure the integrity of the token-generation process.
3. Critical functions (e.g., the API code) within the tokenization application must be protected by integrity-checking
mechanisms
4. Only authenticated users and system components should be allowed access to the tokenization system and
tokenization/detokenization processes.
5. The tokenization product should have access and tokenization/de-tokenization logging functionality.
6. Tokenization and de-tokenization requests should be logged and the logs should not contain PAN.
7. Tokenization product should support multi-factor authentication for all user access.
8. Where the vendor uses cryptographic primitives, those primitives should be based on published national or
international standards—e.g., AES or ECC.

57
International Standardized Encryption Models
Source: INTERNATIONAL STANDARD ISO/IEC 20889
Homomorphic Encryption (HE)
*: Multi Party Computation (MPC)
Oper
(Enc_D1,
Enc_D2)
HE
Dec
HE
Enc
HE
Enc
Clear
12
Protected Key
Clear
D2
Enc
D1
Enc
D2
“Untrusted
Party*”Clear
123
Format Preserving Encryption
(FPE)
FPE
Enc Clear
D1
FPE
Dec
Clear
123
Protected Keys
897

58
International Standardized Privacy Models
Source: INTERNATIONAL STANDARD ISO/IEC 20889
Differential Privacy
(DP)
k-Anonymity
Model
__
__
__
*: Example Apple and Google
Clear
Protected
Curator*
Filter
Clear
Cleanser
Filter
Cleanser
Filter
Clear
__
__
__
Protected
DB DB

59
On Premise tokenization
• Limited PCI DSS scope reduction - must still maintain a
CDE with PCI data
• Higher risk – sensitive data still resident in environment
• Associated personnel and hardware costs
Cloud-Based tokenization
• Significant reduction in PCI DSS scope
• Reduced risk – sensitive data removed from the
environment
• Platform-focused security
• Lower associated costs – cyber insurance, PCI audit,
maintenance
Total Cost and Risk of Tokenization
Example: 50% Lower Total Cost

60
Quantum computing risks
• It will take 3 years for NIST to complete review of quantum safe algorithms (started in November 2017).
• 4-6 year from now for NIST Standards to be released.
• 3-5 years to produce new industry standards based on NIST algorithms from NIST Standards.
• 5-7 years for the industry to fully implement the new industry standards.
• Full industry adoption could take 20 years from now.
• Guidelines for Immediate Steps that can be taken are upgrade to AES, preferably AES-256.
• Use SHA-512 for hashing. Use stateful hash-based signatures for signing, especially for protecting upgrades
of firmware/cryptographic software.
• Use hybrid cryptography to protect against both weaknesses in RSA/ECC and potential weaknesses in post-
quantum algorithms.
• Protecting Data in Transit: No large-scale quantum computers capable of cryptographic attacks.
Source: ANSI X9

61
Thank You!
Ulf Mattsson, TokenEx
www.TokenEx.com

62
50 percent of businesses reported data stealing in 2019, while 26 percent of them have become victims of financial
data theft.
The statistics show a significant increase in the number of IT security Incidents among German companies during the last
two years. Back in 2015, 51 percent of companies were affected by IT security incidents. Two years later, in 2017, the
number of afflicted firms modestly increased to 53 percent. The 2019 survey indicates a significant increase, with 75
percent of companies claiming to be affected by IT security incidents.
During 2019, 32 percent of German companies became victims of theft of IT or communication devices, making it the
most ordinary type of IT security incident. Another 16 percent of them were likely affected by such theft. Analog social
engineering was the second most common IT security incident in the German market, with 30 percent of companies
reporting this problem.
Digital Attacks Caused Total Damage of €205.7 Billion in Two Years
The 2019 statistics show that digital attacks caused damage to seven out of ten German companies. Most of them or 25
percent, to be precise, were exposed to password attacks. Another 23 percent of companies reported malware infection.
Phishing took third place on the list, with 23 percent of German companies reporting this type of digital attack.
Compared to 2017 facts, all types of digital attacks marked an increase, except the malware infection.
Nevertheless, data thieves were primarily interested in communication and financial data. Almost 50 percent of
businesses reported communication data stealing in 2019, while 26 percent of them have become victims of financial
data theft. Digital attacks and IT security incidents in German companies have caused total damage of €205.7 billion
within the last two years.

Emerging pci dss v4 data security and privacy for hybrid cloud

Recommended

Recommended

More Related Content

More from Ulf Mattsson

More from Ulf Mattsson (20)

Recently uploaded

Recently uploaded (20)

Emerging pci dss v4 data security and privacy for hybrid cloud