hi
everyone once upon a time there was that
big monolith it could be a big computer
consisted of I don't know IBM system z
as400 um VX machine and so on as already
mentioned it was just one big computer
with one big software with some sort of
UI if you can call it that way uh and of
course large data stores where in most
cases were based on
db2 later on you had more Silo systems
and operating system where you could
find some old versions of Linux and Unix
uh operating systems the old Windows
operating systems which were more of an
application than an OS as of today of
course the classic Ms do and data
Stores um later on the year you would
find a lot of different architectures
and multi-tier type of system more
distributed systems in practice where
you could find more siloed type of
systems from your Erp all the way to
your uh client relation Management
systems and go for Content Management
systems and in general data stores again
where the data was stored both on the
server side but also on client side
speaking about client side the client
side was already independent in that
period and then the new era suddenly all
of the two tier three tier four tier end
tier architectures started to show up
API is the king
now uh relatively simple scaleout
capabilities started to be more
popular Cloud well I would say that with
ASAS and pass they have started to
emerge to the public Cloud ecosystem
about SAS I have a different theory that
it was already exist even before the
public Cloud was announced but that's
for another
talk and then data when it comes to data
I would like to cover different type of
dimensions and benchmarks about how it
looks like in cloud and later on I will
touch upon the challenges or the
security challenges so to say and the
potential Solutions related to data
security so I'll start with structure
data structured data could be in the
form of a CSV file um um an a yaml file
uh a Json file a bit Tre and so on and
so forth when it comes to unstructured
data you would find things like
unstructured text or uh unstructured um
audio file
with its analog representation but also
its binary representation as well you
could find uh pictures in their analog
representation by the way those two
adorables are my kids which I'm super
proud of and also their binary
presentation as
well um so that was the structure versus
unstructured data when it comes to
logical versus physical medium on The
Logical side of things you would find
object level data which is managed by an
application in most cases and has custom
metadata which VAR and arbitrary then
you have the file level type of logical
medium which is managed by the operating
system itself you know things like NTFS
extension for and so on and it has fixed
file system
attributes you also have the Block Level
when it comes to storage devices in most
cases where it's also been managed by
the operating system of that storage
device and it also has fixed system
attributes as
well now when it comes to the physical
medium you have the nonvolatile physical
medium from hard drives whether SSD or
magnetic uh you have the flash drives a
USB key mass storage devices or
equivalent and you have like Optical
mediums like DVD which are less in use
at the moment or in these
times and when you we're speaking about
the volatile type of memory then you
have things like Ram random access
memory which are by all means volatile
but you also have processor registers
which also even more volatile when it
comes to the frequency of the data
exchangeability
then we have on premise versus Cloud
where on on-prem you would find you know
the central local disc of a given data
center or an ecosystem it could be also
a Central Storage platform it could be
the the local dis over the different
bare metal uh Services while in
Cloud the way that I put it is the data
is somewhere over the rainbow because
you don't really know where it
resides now there are multiple security
challenges when it comes to Cloud but I
would like to cover specific data
security challenges when it comes to
different Cloud
implementations so I'll start with some
direct uh uh challenges which related to
public Cloud first one would be the fact
that data can leak uh the data leakage
and prevention in Cloud which means how
do you protect your data from being
leaked from your internal environments
within your public Cloud to be
exfiltrated outside of this particular
environment then you also have the data
segregation and protection or in other
words how do you segregate your data in
a by Design multi-tenancy ecosystem also
one of the biggest problems threat and
vulnerability management I think that's
a clear uh uh challenge which also
relevant to on Prem but when it comes to
Cloud uh it's a bit more tricky because
sometimes you do you are using specific
uh systems or middle Wares which you
cannot control all of them and entails
shared responsibility models which
sometimes doesn't adhere with your
service level
expectations identity and access
management here I must say that if
you're using single public Cloud that
problem or that challenge is in a better
State as of today because of the
evolvement of the different public Cloud
um in the space of I am and the
Practical granularity and
implementations but it might be a very
tricky and challenging one when it comes
to multiple public clouds for instance
using AWS with Azure with gcp and then
when you would like to govern them all
it is feasible but more of a challenge
in comparison if you were using a single
Cloud
tenant um I'll skip the application
security for one because I'm going to
touch upon that from a different
perspective later on but the physical
and Personnel security here it's pretty
straightforward here you know it's not
your data center meaning it's not your
controls and in some cases it's also not
your personnel and the fact that it's
not your personnel imposes high risk in
particular cases and in particular
threat
scenarios when it comes to the indirect
risks here it's about different type of
risk which are not directly to the cyber
space or to the uh cyber security misuse
cases but more about the processes and
the people for instance if you need to
have the ability to support business
continuity and Disaster Recovery plans
uh securely that means that in
particular scenarios your organization
might have state-of-the-art highly
mature security implementation for all
the different domains from Access
Control to infrastructure security to
application security to data but then
think about a scenario which is let's
say highly likely to happen for each and
every organization when you have a
problem when you have an incident by the
way not at all cases it would be a
security incident but a incident that
you need to act upon it and in that
incident it might be that some
implementations or some actions required
actions entails with I don't know
sharing sensitive data to specific third
party not in the standard way that the
organization already facilitated now the
business is really vocal about that
particular action that needs to be done
in order to have you know kind of the
business more resilient as a result of
this um um incident but it might be that
this implementation needs to happen fast
and as part of a the need of that uh
implementation to happen fast it might
influence the security level of that
implementation for instance maybe that
data needs to be shared in a different
channels not in a secure manner not with
key exchange not with password with a
secure password sharing and any other
implementations for that so sometimes
that would require a senior leader to
accept the risk of that particular
implementation and that at the end of
the day is going to be a risk or a data
security risk in specific which was only
as a result of we you know H excluding
the security implementation and what can
go wrong in the BCP and DRP specific
plans so that's the first indirect uh
challenge second one is availability of
services and data in the cloud think
about your security implementations or
data stores resides in One Stop Shop I
don't want to name vendors but it could
be that you have your encryption
mechanism your sensitive data detection
mechanism your access control your
infrastructure security your
configuration Benchmark all of your
security implementation ecosystem
alongside the data repositories in one
place or under one vendor is that secure
can something go wrong with that the
answer is yes and highly likely in
comparison to the other way of
Distributing your different
implementations in different vendors and
ecosystems the last one is about
incident response Arrangement if you
remember on the direct physical and
personal security I mentioned the fact
that this is not your data center means
not your controls and also in many cases
not your personnel think about the
shared responsibility model think about
an incident that happened which involves
both the cloud but also maybe potential
either other public clouds or on Prem
other data centers what can go wrong who
is responsible who needs to contact whom
did you set proper slas did you check
that people are able the relevant
Personnel from the different vendors are
able to respond in a timely fashion in
the right expected quality like you have
with your personnel and so on and so
forth so again when it comes to Data
Solutions I think here I would like to
cover the different elements and
benchmarks when it comes to the
different consideration that I would
advise you to take not on all of the
different solutions because it would
take me maybe a week to talk about all
of the different benchmarks per domain
but I'm going to focus today not only on
data security but specifically on the
subdomain of data protection type of
solutions and I'm going to start with
the um data truncation implementation
first of all just to explain it data
truncation is about shorten an object or
piece of datum to a way that it would be
only partial which means it's not going
to disclose any sensitive um element as
a result of being exposed
truncated now the key Pros with that
approach is that you're getting full
protection by all means but it's full
protection because you just cuted the
piece of data that makes it sensitive so
that's why it makes it with full
protection and there is a con as a
result of that which I'm going to touch
upon in a moment it's also relatively
easy to implement trating a piece of
data is something pretty easy to
implement if you know how to code and if
you know how to use specific libraries
to make it feasible and also not less
important it has negligible footprint
when it comes to Performance and that's
very important if you're thinking about
really high scale data stores or data
processing elements you know speaking in
petabytes or hundreds of terabytes when
it comes to daily routines and that's a
very important piece for that now when
we're talk talking about the cons part
here as I've already mentioned the fact
that you get full protection it's nice
as a pro when relevant but sometimes it
also means that you cannot retrieve the
full piece of data it was cuted tranced
so to say from the original datum which
means you cannot get it back and if you
need it back probably truncation is not
going to be your optimal solution the
other con that we have is the that it
doesn't preserve uniqueness at all times
which means think about simple scenario
you have a credit card number and you
haven't masked it you tranced it so it
might be that the tranced part now not
disclosing the full pun which means you
are compliant and you're doing it
securely and you're reducing the risks
but it might be that if you need to
preserve uniqueness for specific
business processes in the organization
and for companies dealing with credit
cards there are many use cases like that
then you can find yourself having the
same piece of data meaning that it's
allegedly duplicated but it's not
because originally it was different and
that's why having not having the
uniqueness part being preserved is a big
cone if you're using
truncation the next data protection
implementation I would like to cover is
data hashing and here it's about mapping
arbitrary size value to fixed size value
and just to be clear I'm assuming for
this particular implementation proper
hashing implementation which meaning
strong salt and strong hashing algorithm
now here the main Pros to use that is
that it's highly impossible to retrieve
the original data from the ash value
Itself by the way I will divide my my my
um statement here into two parts
mathematically scientifically it's
impossible but from practical standpoint
it might be that you hold a dictionary
or a rainbow table in the more
professional language which means you
have some sort of a dictionary with
specific hashes to specific original
text and if someone will have the right
way to put their hands on that rainbow
table and they have enough computing
power to run and query all of the above
they might be able to find a bypass a
workaround to retrieve from the data the
original data from the hash value not
mathematically not scientifically but as
a bypass the other advantage that it has
is that it highly injective hash
preserve uniqueness almost at all times
and we're speaking about
99 many many many NES after the decimal
point of being also impossible to be not
injective and that really helps when you
have the scenario that you need to have
injectives you need to have the
uniqueness of the data but you don't
want to ever disclose the original datum
and the next Advantage would be low
performance impact similarly to the
truncation part even though that takes a
bit more computation power it's still
relatively cheap from performance
perspectives and that's very important
when it comes to large scales uh
applications the main con of that is
that you cannot retrieve the clear taex
data from the hash value and that's
given because that's part of the
attributes and the the qualities of
hashing so as I've already mentioned
it's a con if you need to retrieve the
data eventually from the hash value but
it's a big Pro if it's
unnecessary I'll move now to
tokenization and in tokenization ation
the definition of that is turning a
piece of data to a random unique string
and use the dictionary to bind them all
together here the dictionary is not a
bypass the dictionary is a byproduct
component of tokenization now the main
Pro of tokenization is that tokenized
data is completely pseudo random I would
say I I cannot say completely random
scientifically uh it's meaningless if
the tokenization application done right
and it doesn't provide even a small hint
on the original data or the tokenization
algorithm again assuming proper
tokenization and that means that it's a
big Pro because here it's not about any
encryption Keys which I'm going to
mention in a moment or any other type of
implementations which gives you a
structured um um output which not in all
cases that's the expected result and I'm
going to mention that in some of the
other Pros now the other Pros it's about
help to reduce regulatory scope that one
is not straightforward and I would like
to elaborate about it so you can ask
yourself why oranization help you to
reduce the regulatory scope but I don't
know um hushing doesn't or encryption
doesn't and the main idea for that is
that with encryption if you think about
the idea of being able to retrieve the
data the cipher that you will find in
the allegedly nonre regulated Scope when
it comes to things that you would be
able to retrieve with a given key or
another assistant that would mean that
even though it's protected and it's
secure it doesn't necessarily mean that
it reduces the regulatory scope for
instance with pcidss for card holder
data environment or for gdpr when it
comes to where you store or hold any
privacy related information personal
data in
specific um so that's about that
particular part with tokenization I'll
just mention that if you have a
tokenized data in the so-called out of
scope environment then all you have to
do is to tell all of the relevant
stakeholders how do you protect the
dictionary why the dictionary cannot be
exposed or um let's say licked in a way
that would put that ecosystem or that uh
uh that environment in scope for the
regulated the the relevant regulation so
that's for that particular Pro now
another Pro that it has is that token
can be format preserving now for those
of you which are already expert in that
field you proba
know that encryption can also be format
preserving but it's not the same and for
encryption you are much more limited and
I'm going to touch upon that when it
comes to in which way you would like to
preserve format not at all cases you can
design it like with tokenization
platform which giving you almost any way
to preserve your format when you would
like to implement uh tokenization
strategy for your data protection of
your sensitive data main cons for to
oranization so you need to put extra
measures to protect the token dictionary
as I've already mentioned here the
dictionary is everything if the
dictionary is insecure all of the
implementation of tokenization would
make your sensitive data to be insecure
almost similarly and that keep puts that
particular component in a very high risk
in a very high inherent risk even
without the controls that are going to
be applied another con that we have is
that it requires a lot of high
maintenance and there's a lot of
performance impact as a result of most
of the toiz implementations because when
you're based a system on dictionary type
of um type of implementation that would
be I would say more expensive from
performance perspective than a system
which does things in a minimal
computation implementation like with
encryption tration and other type of
data protection uh tactics and then we
have also the partial
incompatibility because with oranization
this is not a standard way to uh protect
your data like with encryption or like
with hashing you know with hashing you
can say let's use standard protocols
with encryption you can do the same and
I'm going to touch upon that in the next
slide but when it comes to tokenization
most of the tokenization implementations
are proprietary in a way that the
implementation itself and connecting it
to your systems it's not going to be
straightforward and now I'm arriving to
the data encryption topic which is one
of my favorites because because it also
entails very large sub components or sub
implementations and it's very very very
it considers a very rich world and I'm
going to touch upon some of these items
first of all let's start with the
definition of encryption because many
people are getting a bit confused when
they're being asked what do you think is
the definition of data encryption so I
think the essence is turning a piece of
data to something which is absur or
random I'm correcting myself or correct
in the slide a random unique string in a
way that the only way to retrieve it
would be with a key some sort of key and
again there's a many definitions of what
key can be now with all of the
dimensions that I can cover you know
there are like very very large set of
implementation tactics from symmetric to
asymmetric implementation transparent
versus payload the mode of operation the
encryption algorithm the architecture
which is super important and can can be
your weakest link if you're not
implementing it right
but I'm not sure we're going to have
enough time to cover all of them so I'm
going to cover some of these benchmarks
and I'm going to start with the um
symetric versus asymmetric encryption so
first of all just to explain what does
it mean symmetric in the sense of
symmetric key versus asymmetric key
implementation and here it's about um
starting with the symmetric part if I'm
touching upon the main benefit of it so
it has very low performance impact by
the way mainly due to the relatively
small size of the encryption key when it
comes to symmetric encryption the main
con of it is that you use the same key
for both encrypting actions and
decrypting actions which means that that
key is Not only safe to to provide it to
anyone which needs to encrypt only now
you also need to protect that same key
even though it needed for some entities
only for encryption you must protect it
as much as it's the same key that has
the same authorization or the same
privileges to decrypt the data from
Cipher to original text and that's a big
con when it comes to specific
implementation when you need to
distribute some of your encryption only
Keys other cons would be that it imposes
higher risk for the same reasons that I
mentioned in the Pro part because the
key size is shorter than in asymmetric
Keys which I'm going to mention in a
moment which means it's relatively
easier to break it and even if you're
using very strong keys at least for
today's Times don't forget we're in the
era of quantum computing
and we really don't know what time is
going to bring us and by when so other
um I think I I already covered the
symmetric part moving to the asymmetric
part so here the main Pro is that the
encryption key is a public knowledge
only which means if you have a business
scenario or a technical scenario when
you need to share your key for specific
entities even entities that you
partially trust or even don't trust at
all but they are part of the the data
flow or the business process that means
that you can be calm with providing them
only the public key which they can only
encrypt data that only you or other
entities are privileged to decrypt it
but they would never ever be able to
decrypt it with that particular key or
what it calls more commonly a public key
in that setup other Pro of asymmetric is
that you don't need extra controls if
you only need to encrypt as already
mentioned if you need to provide only
the public key you can share it in an
insecure uh medium you can share it in
any other ways you can let that data or
that particular key to be publicly
accessible on the third party premises
without concerning that that key can
also potentially decrypt the data in the
previous scenario with symmetric
is the con of asymmetric implementation
is that it has very high performance
impact because of the key size now for
those of you which might not aware of
the main implementation today for
asymmetric key is mainly for key uh
exchange processes so all of you
probably heard about SSL TLS and in
general you know secure channels which
are based on TLS uh principles in that
principle you're using a symmetric key
only for the initial key exchange of a
symmetric key that would serve that
particular session to encrypt data in
transit again in a nutshell it's a much
more uh complex topic than that but the
main idea is that because it's high it
has high performance uh footprint that's
why it's been used only for the initial
key exchange and not for the whole
session even though it's more secure by
Nature than a symmetric shorter sized
key now other Benchmark that I would
like to cover is transparent versus
payload here first of all maybe it's
good to Define what does it mean
transparent and what does it mean
payload so I'll start with the
transparent part transparent encryption
it's implementation which you're doing
mainly underneath the layer you're
trying to protect so if you would like
to encrypt data in all of your database
you would encrypt all of the DB itself
the DB management platform the file of
the DB if you like if you are you would
like to encrypt all of your laptop dis
you would do it in a full disk
encryption uh implementation that would
be considered as a transparent
encryption so the main Pro of this type
of encryption is that you have low
performance impact because it uses
different mechanism with shorter keys
and other implementations which makes it
with low performance footprint it's
relatively easy to implement in most
cases because in the majority of cases
it's out of the box by different vendors
either operating systems uh um vendors
like Microsoft or apple but it might be
also uh for rbms platforms for instance
uh my SQL mssql or others and it's
relatively easy to implement as a result
of having a standard uh type of
implementation by the vendor it has no
modification needed to done on the L
side because it's supposed to be a
transparent
implementation that's why it's called a
transparent encryption and it's very
effective when you need a low-level
protection think about the scenario of
your laptop being stolen and has a lot
of sensitive data for the scenario of a
the a thief putting their hands on your
laptop I think that's a good
implementation for other scenarios when
someone has an access to your operating
system it's a different story which I'm
going to cover on the cons part so
moving to the cons part it's in a
effective for most of the attack
scenarios as already mentioned if you
have a full dis encryption as an example
or full DB encryption but you have your
DBA or your users having access through
a proxy or through a listener or through
any sort of means which are not
underneath that layer that means that
it's transparent which means you would
not see the data encrypted you would see
it in clear at most cases depends on how
you've implemented it and it's a big con
if you don't understand what you're
doing in that particular implement
mentation now it's also not applicable
for all platforms I already mentioned it
might work with my SQL with mssql with
um windows with Mac OS but you cannot
implement it with each and every
platform so you need to be aware of that
and it's ineffective for OS level if you
don't have a trusted platform model
think about full dis encryption where
you store the key also on your disk so
it's a bit of the Chicken and the Egg
because you cannot encrypt it with the
same key that you're encrypting it you
need a key encryption key that would be
available upon decryption now that can
be done in a very low risk if you have
trusted platform model a TPM which is a
mini HSM equivalent which can be chipped
in each and every platform if you don't
have it it's not effective hence it's a
con when it comes to payload encryption
just to explain here IND different than
transparent we're speaking about
encrypting the piece of data itself and
not the all ecosystem of it and the main
benefit of it is that it's effective for
most attack scenarios if you implement
it right that means that you can have a
scenario where the where the data is
encrypted at all times and it might be
only decrypted while in use either in
the client specifically when it's really
must being decrypted and displayed to
the user or in a backend Ser uh uh type
of processes where you have the um um
the data being decrypted only when it's
need to be processed so that's why it's
highly effective but the main cons of
that is that it has mid high performance
impact sometimes it's mid sometimes it's
high it really depend on the level of
implementation because in most cases
it's a proprietary implementation which
requires specific ways how you're
protecting that particular data and in
which granularity level it doesn't have
to be a field or a value like in AD Json
it could be like a bulk type of or a
table it really depends how you've
implemented it other con that we have it
requires modification on the client side
in most scenarios assuming that you need
that you implemented or applied that uh
a solution in a way that you would like
it to be encrypted end to endend until
the very last mile on the client side
not all organizations or system
designers uh would like to implement it
in that level but you need to be aware
of that because it's highly secure if
you're doing it like that but it
requires a lot of modification which
sometimes can be a pain for the s for
the people which in charge of um of
making the clients to be adher to the
new applications and the last con would
be that for most of the thirdparty
solutions it's not supported by product
you need a library for that you need to
develop something that would literally
take piece of data or bulk of data the
payload itself not the layer underneath
and would effectively apply proper
encryption and proper decryption on the
relevant parties or the and the relevant
Parts where it's mostly
needed so as I've already mentioned we
don't have enough time to cover all of
the different sub components or sub
benchmarks under data encryption or
other domains but I wanted mainly to
give you a taste and more of a look and
feel on topics that even though today we
have many new Cutting Edge innovative
solutions in that field with full
homomorphic encryption and no decryption
at all and using fragmented keys and so
many Innovative things I think that the
basics are still very important for
everyone to be aligned upon because that
what would help people and would help
organizations to apply proper data
protection you know from the essential
parts so a couple of conclusions and
takeaways for this particular talk so
from data security perspective on Prem
is not public Cloud I know that you knew
that but I wanted to emphasize that
particular part when mainly when it
comes to the different misuse cases the
different attack scenarios and the
different solutions you would like to
apply in a given either public cloud
from one kind to another public cloud
and to other on on Prem implementations
which are different the second one is
that there are different motivations for
data protections some organization just
want to take the mark to say we're
compliant with this we're compliant with
that and in some cases they will do the
bare minimum which means it's not going
to be practically a risk reduction
implementation but more of satisfying
the regulatory requirements or
satisfying the Auditors that will sign
off the uh particular attestation for
that organization but there are also
other motivations which I believe are
super important because if you have the
right security maturity level that means
that you can also increase your M your
reputation level with your customers
with your partners I think with
customers it's more likely with B2B type
of organizations where your business
customers expecting you to show higher
maturity levels when it comes to
security especially when you're
processing their sensitive data and the
other one is would be that you know you
have different constraints to consider
while applying different data Security
Solutions for different ecosystems
different business cases and different
type of applications and the very last
takeaway that I would like you to take
is that please please please don't just
take a ticking the mark type of solution
and just you know say that you've done
and applied data protection I've already
mentioned a transparent encryption
earlier I think that's a good example of
things that if you're doing it for
things like laptops or other type of
scenarios be very clear with yourself
about why this type of solution with
that type of implementation helps and
addressing this particular threat or
misuse case otherwise you're just taking
marks and you're not doing it right at
least in the way that I see
things thank you very
much which is data security solution do
you think is the best in case that I
need to retrieve the data and to be cost
effective
so of course there are a lot of unknowns
for me to answer that question more
structured but I would mention mainly
data encryption I'm taking the cost-
effective part and I already mentioned
that tokenization might not be the most
cost-effective one using or applying
proper encryption for your solution with
the right key management platforms using
hsms Hardware security models or other
implementations followed by the right
key archit Ure which means you have
local master key underneath you have
Zone keys for different entities and
underneath you have data Keys which are
being rotated frequently and being
audited and being monitored using that
and applying it right I think without
having more knowledge on the ecosystem
you're probably asking about that would
be probably the most close answer I can
provide to you thank you related to the
data yeah could we apply or should we uh
get into labeling the data somehow so we
can uh maybe uh improve some some of the
cost or we should trade the data the
same data a great question and I have
long dedicated talk only about data
visibility classification labeling and
tagging only on that topic so to provide
you a concise response to your question
yes you're highly likely in the
following sequence to classify to to
discover your data okay to classify your
data
then to label your data either
internally in a designated system or in
the relevant data store and to tag the
data for other users when someone else
will consume the data because you know
today we're in the era of data
production data consumption Kafka
architectures the these type of things
so to repeat my uh response concisely
you are highly request or expected to um
discover your data there are many
mechanisms to do that that on Prem Cloud
unst structure structure there are many
solutions for that today discover your
data classify your data with minimum
force positives and maximum Precision
rates then labeling the data and
afterwards if and where possible tagging
the data because then it would strongly
help you to have better data governance
but also better data security is a
result of that because you know where
your sensitive data resides how it's
been protected how it's been in use who
has access to it and how you you can Pro
how you can effectively control the
security level of that data