Wie schaut der Prozess für Customer Insights im weiteren Sinne aus? Welche Aspekte sind dabei zu berücksichtigen? Welche technologischen und Architektur-Ansätze können hierbei unterstützen? Angefangen vom Aufbau einer 360 Grad Sicht auf einen eindeutig identifizierten Kunden unter Berücksichtigung des Datenschutzes über die eigentliche Analyse der Kundeninteraktion – in Echtzeit oder nachgelagert – bis hin zur erfolgreichen Nutzung der erzielten Kundenkenntnis in der Interaktion mit dem Kunden.
10. EU General Data Protection Regulation (GDPR) in a
nutshell, enforced at end of May 2018
Objectives
• harmonize data
protection across
Europe
• strengthen data
protection for EU
Citizens
Scope
• EU citizen’s data
• Entities from all
countries processing
EU citizen’s data
Sensitive Data
• racial, ethnic origin
• political opinions
• philosophical,
religious beliefs
• health or sex life
• sexual orientation
• genetic, biometric
Data Breach
• third party gains
unauthorised access to
personal data
• must be reported
without undue delay
Responsibilities
• data protection officer
• Data protection impact assessment
• workforce privacy awareness training
• data protection policies
• Data protection by design
• Record of data processing activities
Penalties
for non-compliance
• up to 4% of worldwide
turnover or 20 million €
Rights
• Erase records
• Data portability
• Explain automated
decisions
• Dissent data profiling
Consent
• permits types of
processing
• to be provided explicitly
(opt-in)
• can be withdrawn
Principles
• Lawful, fair,
transparent
• Purpose limitation
• Data minimisation
• Accuracy
• Storage limitation
• Integrity, confidential
• Accountability
Data Processing
• Collecting, storing
• Altering , deleting
• Retrieving
• Transmitting
Data Subject
natural person
• Client
• employee
Supervisory authority
Identification
• name, id. number,
location or physical,
physiological,
genetic, mental,
economic, cultural or
social identity factors
Personal Data
• any information
relating to an identified
or identifiable natural
person
Data Controller Data Processor
• Service provider
15. SIEM and GRC can not prevent any type of data breach -
we need a different approach
Anomalous Behavior
Traditional approaches need to be
complemented – SIEM, GRC are still needed
GRC says what is approved – the tasks you
can do, the gates you can go through.
Abnormal Behavior Detection says whether you
should have
Extend using Anomalous Behavior Detection:
This approach:
1. Learns what is normal [the difference between
approved and allowed]
2. Identifies what is anomalous and categorizes
the risk
3. Alerts so you can react before it becomes a
problem.
New Outcomes are Possible
It is an extension of current security
approaches that enables a reduction in GRC
and can identify threats that GRC cannot
It shows where “allowed” is not “normal” and
the scope of the deviation from the norm.
Detect social engineering attacks as well as
network level detections
Minimize the exposure time and loss
Potentially predict the leakage areas ahead of
the attack
This can be applied to both GRC areas
(Snowden) and non-GRC areas (networks,
non-controlled information) to build up a
broader pattern of behavior.
16. Detection of Anomalous Behavior – from Insight to Action
Structured data Machine learning
defines “normal”
across user base
Inform management Adjust policies Lockdown
SIEM
AD
HR
Unstructured data
Images
Social
Email
Video
Automated response based on level of deviation and system criticality
Users accessing key systems within role as defined by GRC
Deviation
from norm
triggers
action
17. 1
Out of policy
access
In policy but
extremely
abnormal access
3
2
In policy but
abnormal access
Examples – SIEM, GRC and Detection of Anomalous
Behavior
User tries to access what
they shouldn’t
GRC says “no”,
notifies SIEM
SIEM collates, alerts, may
reduce privileges via GRC/IAM
User accesses single item out of
norm but in policy
GRC says
“yes”
AB ‘but that isn’t normal’,
alert to SIEM
SIEM collates, alerts, may
reduce privileges via GRC/IAM
User accesses multiple areas
out of ordinary but in policy
GRC says
“yes”
AB ‘this is the ONLY person
EVER to do this!’ alert to SIEM
Shutdown of user
access + manager alerts
Principal data flow is bottom up
Reference architecture is composed of processing steps and deliverables
Principal data flow is bottom up
Reference architecture is composed of processing steps and deliverables
Principal data flow is bottom up
Reference architecture is composed of processing steps and deliverables
“The challenge has always been ‘how to catch up’, the new challenge is ‘how to stay ahead’” that represents the difference of ABSA over GRC. With GRC you change the rules after the horse has bolted, with ABSA you have a better chance of finding people fiddling with the bolts.
It’s not if – it’s when.
Reduce the time an attacker is inside the network.
Other solutions can’t see the entire attack vector.
Traditional SIEM sees logs
GRC does not defend from threat actors “in role”
Move from the mindset of react to prevent.
80% of IT security budget is currently spent on remediation & response to a threat, infection, or breach.
Network/security engineers are generally NOT decision-makers.
Compliance teams have a LOT of influence.
“Audit Teams” and “Security Teams” and “Server Teams” have their own agendas/stakes in the game
The CIO/CISO is looking for a differentiator; something that gives him more than a ‘tunnel view’
The wider business wants to build security and compliance insights – but lack the skills, tools and are over dependent on IT change cycles.
Take a business driven view of the critical assets and build a risk view of:
Asset type and importance
Raw data – e.g. engineering and testing data that has strategic value
IP – source code, methods, algorithms that give competitive advantage
Impact to business of these asset classes
Prioritize the threat approach and anomalous behavior
Need ways to identify the anomalous behavior based on systems access and take automated proportionate
Advanced algorithms that run against holistic data set (including HR, AD, etc.) to identify high risk activities by authorized users
User is acting in role as set by GRC and policy but anomalously against learned “normal”
Triggers automated controls based on system criticality
The building blocks of AI are at different level of maturity from early “research stage” to pragmatic utilization
A technology starts at the research stage, where it is primarily the focus of more “foundational research”. As it matures, organizations start adopting it into the enterprise, typically through a “conceptual phase”. The technology will typically have some early “maturity-issues” as it progresses
Eventually it will be “production ready” and shown to be stable at high volume and for a variety of use-cases
As the different technologies mature, the AI infused processes and “machine” will become more advanced
The number of use-cases for AI infused processes will increase as the technological capabilities mature
The organization must also adapt and select which processes are relevant for integrating AI solutions
Integration of AI components can be done in the process in several ways: incorporated in the applications themselves (SMART-modules), or by a separate solution introduced into the process
6-1 komplett raus ggf
Top 5 zeigen
cloud hervorheben (pfeil dicker)
- text kürzen
- von business getriebenes thema
- kicker
- prioritäten an challenges anpassen
--- skalierbarer, agiler, flexibler (beenfits aus 8 nehmen)
- strategic priorities nur auf clod beziehen
- links rechts schatten