Most successful people I have known in the past have shared a common characteristic - that is the willingness to accomplish a set task with 'available' resources rather than buying a ready-to-use customized easy-to-use box-packed kit. Though this approach makes a task complex, time-consuming and more effort requiring but saves the most crucial factor: resources in most cases. There are various fields wherein people take this approach & I'm going to attempt this with PCI 3.0 & DLP today.
The PCI 3.0 Standards touches the lives of hundreds of millions of people worldwide (as stated by the Security Standards Council themselves). A global organization, it maintains, evolves and promotes Payment Card Industry standards for the safety of cardholder data across the globe. There are numerous drawbacks of not being PCI compliant which includes, but not limited to brand degradation, reduced customer base, loss of Competitive advantage and more.
The PCI 3.0 is such Standard where there is no definite path to achieve compliance. This Standard to me, is an open framework NOT implemented with a pre-planned agenda (crafted skillfully) to benefit a few chosen vendors with its roll-out. A Data Loss Prevention (DLP) tool I feel could play a key role if architect-ed to its potential. Though I am yet to experience such efficient use of the DLP tool itself specific in the PCI compliance domain, but I'm sure many DLP experts are already thinking about it, during this evolving PCI phase.
The below are some PCI DSS requirements which I feel DLP can meet effectively. To me these are certainly the ones wherein DLP could play a lead role in achieving compliance but I'm sure with further thoughtful use of the DLP solution we could meet more requirements than the list below.
The PCI 3.0 Standards touches the lives of hundreds of millions of people worldwide (as stated by the Security Standards Council themselves). A global organization, it maintains, evolves and promotes Payment Card Industry standards for the safety of cardholder data across the globe. There are numerous drawbacks of not being PCI compliant which includes, but not limited to brand degradation, reduced customer base, loss of Competitive advantage and more.
The PCI 3.0 is such Standard where there is no definite path to achieve compliance. This Standard to me, is an open framework NOT implemented with a pre-planned agenda (crafted skillfully) to benefit a few chosen vendors with its roll-out. A Data Loss Prevention (DLP) tool I feel could play a key role if architect-ed to its potential. Though I am yet to experience such efficient use of the DLP tool itself specific in the PCI compliance domain, but I'm sure many DLP experts are already thinking about it, during this evolving PCI phase.
The below are some PCI DSS requirements which I feel DLP can meet effectively. To me these are certainly the ones wherein DLP could play a lead role in achieving compliance but I'm sure with further thoughtful use of the DLP solution we could meet more requirements than the list below.
- 4.2 Never send unprotected PANs by end-user messaging technologies (for example, e-mail, instant messaging, chat, etc.).
[DLP Feature]: Create Regex for PANs and Block using DLP - 4.1 Use strong cryptography and security protocols (for example,
SSL/TLS, IPSEC, SSH, etc.) to safeguard sensitive cardholder data during
transmission over open, public networks,
[DLP Feature]: Set all traffic to Block Mode except the above protocols when PCI data is identified using PCI data identifiers. - 3.2 Do not store sensitive authentication data after authorization
(even if encrypted). If sensitive authentication data is received,
render all data unrecoverable upon completion of the authorization
process.
[DLP Feature]: DLP Discover scan, all using Network Discover (with agent & agentless) and Endpoint Discover can scan and quarantine/notify PCI Data - 3.2.1 Do not store the full contents of any track (from the magnetic
stripe located on the back of a card, equivalent data contained on a
chip, or elsewhere).
[DLP Feature]: There are pre-existent templates in most DLP tools to detect PCI data captured using a "magnetic-stripe" in specific which could be useful - 3.2.2 Do not store the card verification code or value (three-digit
or four-digit number printed on the front or back of a payment card)
used to verify card-not-present transactions.
[DLP Feature]: DLP Discover scan, all using Network Discover (with agent & agentless) and Endpoint Discover can scan and quarantine/notify PCI Data - 3.2.3 Do not store the personal identification number (PIN) or the encrypted PIN block.
[DLP Feature]: DLP Discover scan, all using Network Discover (with agent & agentless) and Endpoint Discover can scan and quarantine/notify PCI Data
- 3.3 Mask PAN when displayed (the first six and last four digits are
the maximum number of digits to be displayed), such that only personnel
with a legitimate business need can see the full PAN.
[DLP Feature]: Use Flag for encryption response created in sync with your gateway encryption solution OR use Endpoint Flex response to trigger custom script based encryption - 3.4 Render PAN unreadable anywhere it is stored (including on
portable digital media, backup media, and in logs) by using any of the
following approaches:
[DLP Feature]: Use Flag for encryption response created in sync with your gateway encryption solution OR use Endpoint Flex response to trigger custom script based encryption - 3.5.1 Restrict access to cryptographic keys to the fewest number of custodians necessary.
[DLP Feature]: Monitor Permissions using Discover scans on all files with a cryptographic extension. - 1.2.1 Restrict inbound and outbound traffic to that which is
necessary for the cardholder data environment, and specifically deny all
other traffic.
[DLP Feature]: Web and SMPT Prevent functionality to be implemented along with Block Policies when PCI data is detected - 1.3.5 Do not allow unauthorized outbound traffic from the cardholder data environment to the Internet.
[DLP Feature]: Block Web and SMTP data when attempted to be sent or uploaded to an external domain/location/IP - 2.2.3 Implement additional security features for any required
services, protocols, or daemons that are considered to be insecure—for
example, use secured technologies such as SSH, S-FTP, SSL, or IPsec VPN
to protect insecure services such as NetBIOS, file-sharing, Telnet, FTP,
etc.
[DLP Feature]: Web and SMPT Prevent functionality to be implemented along with Block Policies when PCI data is detected - 2.2.5 Remove all unnecessary functionality, such as scripts,
drivers, features, subsystems, file systems, and unnecessary web
servers.
[DLP Feature]: Extension based DLP Policies - 2.3 Encrypt all non-console administrative access using strong
cryptography. Use technologies such as SSH, VPN, or SSL/TLS for
web-based management and other non-console administrative access.
[DLP Feature]: Use Flag for encryption response created in sync with your gateway encryption solution OR use Endpoint Flex response to trigger custom script based encryption - 7.1 Limit access to system components and cardholder data to only those individuals whose job requires such access.
[DLP Feature]: Review Permissions using Discover Scan, might as well use Data Insight Functionality
No comments:
Post a Comment