sunhux
asked on
Justifications for Data Domain encryption (for PCI-DSS & security compliance)
One PCI DSS assessor had suggested that our Data Domain (sort of VTL as we have
replaced tapes with disks which we backup to remotely to our DR site) ought to be
encrypted.
Internally storage team argued that shouldn't we
a) encrypt at source & only selective sensitive data ? Then we have much less
to encrypt
b) encrypting entire data domain will entails more load (tho I've seen EMC's
solution for this)
c) our assessor's justification is there may be sensitive data (eg: PAN or
credit card#) in the logs that get backup from our Prod to DR site thus
the need to encrypt it at destination
d) I know encrypting tapes is highly recommended as tapes are transported
offsite (for storage) during transit, tapes may get lost. But if we are using
point-to-point link between our Prod & DR sites, there's no risk of losing
media in transit. Is this argument valid?
e) Also, should a HDD in a SAN get faulty & is being returned to vendor, what
are the chances anyone or even a determined hacker could read the faulty
(or even if it's not faulty) HDD for sensitive data? Data is spliced randomly
in SAN's HDD, virtually making data in the HDD undecipherable?
f) when data is being backup from our Prod datacentre to DR site using
point-to-point leased line (assuming the line do not have encryption),
what's the risk it could be tapped or subject to MITMA? Any security
guideline that says backup traffic that is not encrypted is not
recommended or non-compliant?
g) Comparatively, encrypting our Prod databases is more difficult or
encrypt the backup traffic + encrypting the data domain is more difficult?
replaced tapes with disks which we backup to remotely to our DR site) ought to be
encrypted.
Internally storage team argued that shouldn't we
a) encrypt at source & only selective sensitive data ? Then we have much less
to encrypt
b) encrypting entire data domain will entails more load (tho I've seen EMC's
solution for this)
c) our assessor's justification is there may be sensitive data (eg: PAN or
credit card#) in the logs that get backup from our Prod to DR site thus
the need to encrypt it at destination
d) I know encrypting tapes is highly recommended as tapes are transported
offsite (for storage) during transit, tapes may get lost. But if we are using
point-to-point link between our Prod & DR sites, there's no risk of losing
media in transit. Is this argument valid?
e) Also, should a HDD in a SAN get faulty & is being returned to vendor, what
are the chances anyone or even a determined hacker could read the faulty
(or even if it's not faulty) HDD for sensitive data? Data is spliced randomly
in SAN's HDD, virtually making data in the HDD undecipherable?
f) when data is being backup from our Prod datacentre to DR site using
point-to-point leased line (assuming the line do not have encryption),
what's the risk it could be tapped or subject to MITMA? Any security
guideline that says backup traffic that is not encrypted is not
recommended or non-compliant?
g) Comparatively, encrypting our Prod databases is more difficult or
encrypt the backup traffic + encrypting the data domain is more difficult?
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
Our Storage colleague raised that when a data domain (& SAN) is encrypted, we risk losing the keys :
valid concern? If so what's the method to ensure we don't lose it?
valid concern? If so what's the method to ensure we don't lose it?
Use second factor. Private key should be in the hardware if it support or uae of HSM. Threat is more of privileged user, assigned 2Fa and have audit trail enable. If budget allow have privilege identity mgmt system, PIMS.
ASKER
Thanks on the tip of storing in uae of HSM (we do have HSM).
I need further justifications for items
a) if we just encrypt at DB (or selective sensitive fields) & considering there are many
apps out there including pre-existing ones, we may miss certain sensitive fields/DBs.
So wouldn't it be better that entire DB sits in the encrypted partition (ie encrypt the
SAN) & the data domain (which houses the backup data) be encrypted as well?
Without the apps teams (& in our case, most of our apps are supported by
external vendors & our internal apps teams who knows little of our coding & rely
heavily on vendors) support, we in IT Security governance will never have full
visibility. Besides the cost to get apps vendors to selectively encrypt certain
data (or is there a tool out there that could seamlessly allow DBAs to do this
without much of the applications knowledge/competency?) could be more
than the cost of simply encrypting the whole partition & data domain?
e) without encryption, if we return a faulty SAN HDD to the vendor (assuming
it's not degaussed), what are the chances data in it could be recovered/read?
I know a couple of storage vendors attempted to repair the HDD (esp if it's
just a faulty sector) & use the HDD as spares to service other customers so
our HDD could land up in another customer's SAN: considering data in SAN
is spliced, is this risk still real? Also, our faulty HDD are sent offsite for
degaussing & one local regulator forbids this ie requires the degaussing
to be done within the same building & not leave a faulty HDD leave the
building undegaussed: is this too paranoid or the risk of a HDD getting
lost while in transit is real?
I need further justifications for items
a) if we just encrypt at DB (or selective sensitive fields) & considering there are many
apps out there including pre-existing ones, we may miss certain sensitive fields/DBs.
So wouldn't it be better that entire DB sits in the encrypted partition (ie encrypt the
SAN) & the data domain (which houses the backup data) be encrypted as well?
Without the apps teams (& in our case, most of our apps are supported by
external vendors & our internal apps teams who knows little of our coding & rely
heavily on vendors) support, we in IT Security governance will never have full
visibility. Besides the cost to get apps vendors to selectively encrypt certain
data (or is there a tool out there that could seamlessly allow DBAs to do this
without much of the applications knowledge/competency?) could be more
than the cost of simply encrypting the whole partition & data domain?
e) without encryption, if we return a faulty SAN HDD to the vendor (assuming
it's not degaussed), what are the chances data in it could be recovered/read?
I know a couple of storage vendors attempted to repair the HDD (esp if it's
just a faulty sector) & use the HDD as spares to service other customers so
our HDD could land up in another customer's SAN: considering data in SAN
is spliced, is this risk still real? Also, our faulty HDD are sent offsite for
degaussing & one local regulator forbids this ie requires the degaussing
to be done within the same building & not leave a faulty HDD leave the
building undegaussed: is this too paranoid or the risk of a HDD getting
lost while in transit is real?
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
"encrypt data in-transit" : this was conveyed by PCI-DSS assessor as required
& in one SWIFT audit: any idea if encrypting Data Domain solution will enable
the backup traffic fr our primary datacentre to DR DC as well?
I the days we use tapes, was told tapes in transit ought to be encrypted but
with point-to-point link (which is not encrypted currently) betw the primary
& DR DCs, is this also a requirement?
& in one SWIFT audit: any idea if encrypting Data Domain solution will enable
the backup traffic fr our primary datacentre to DR DC as well?
I the days we use tapes, was told tapes in transit ought to be encrypted but
with point-to-point link (which is not encrypted currently) betw the primary
& DR DCs, is this also a requirement?
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Seeking author for any further input or clarification please
B. Yes if the load is huge and the extra selective requires more I/O reading of sector and bytes. No if the encryption is once off and on the fly encrypt/decrypt upon access in block of sector.
C. Yes encrypt if log exists to store sensitive PCI and personal data as well as classified data for the transaction records.
D. Dependent where you terminate the point to point. At each point from the source or point to the destinated store, there is still plain data traverse or at rest. They need to be protected end to end.
E. Unlikely if the HDD is encrypted with key in hardware module like TPM. Otherwise forensic means to recover still possible but need specialise tool and cleanroom type of equipment if HDD is in plain. Faulty maybe the spindle, reading seeker and not the actual non volatile store. Better it has been encrupted state if it is faulty then assurance to recover is very much non trivial.
F. End to end is good if you encrypt it from end and decrypt at the other end. Leased line is private and the Mitm is at ISP side hence VPN is still recommended. Non trivial and can be insider to pull off the exfiltration througj Mitm in the ISP network which you be negligent of since you cannot see it..
G. Should have encrypt at rest and in transit. More difficult for end to end as it is more of application to do it. Otherwise it is same effort as it should be tranparent. Read from disk, and encrypt is same work and additional the same data is then pump to store at rest or to wire to send over..Hardware crypto chip or use of HSM makes it even negligible since the hard work is done by hardware.
The store of your crypto key and type of crypto algorithms matters too. These will add in latency if not well choosen esp using properties of own and not well tested in loading environment. You should review past performance report.