Nov 12 2009

Masking vs. Truncating

Published by at 8:02 pm under General

I don’t get a ton of questions about PCI sent to me, but from time to time someone asks a question that deserves a blog post.  Earlier today I received a question from a reader, Michele, that reflects a common misunderstanding in the PCI sphere:

I was reviewing the PCI DSS 1.2 section 3.4 yesterday, and was surprised to see that “masking” was not an option for PAN at rest / storage.  Am I interpreting it correctly that it must be encrypted while stored, but upon display it would be decrypted and masked?  To further that thought, if we receive PAN already masked and then store it, does that fall under PCI DSS?  My thinking is that technically it does not, as the PAN is already masked when received and there is no ability to trace back to the original clear text PAN.

There’s a basic misunderstanding of what exactly masking is.  Many people either don’t know that there’s such a thing as truncation and assume any time they can’t see the entire card number it’s masking, or they assume masking and truncation are the same thing.  They are not and here’s the definitions of masking and truncation straight from the PCI Council Glossary:

Masking:

Method of concealing a segment of data when displayed. Masking is used
when there is no business requirement to view the entire PAN.

Truncation:

Method of rendering the full PAN unreadable by permanently removing a
segment of PAN data.

Think of the cardholder data as numbers written down on a piece of paper.  Masking the numbers would be similar to taking a piece of correction tape and covering up the majority of the numbers so only the last four would be readable by the next person you hand the paper to.  The data still exists under the correction tape, even though it’s hidden.  But the piece of tape can be peeled back with some amount of effort and therefore that piece of paper still needs to be protected so that no one with malicious intent can recover the cardholder data and use it.

Truncation however can be thought of as never writing the numbers down in the first place or erasing them so completely they’re never recoverable.  You’re not recording the entire data on the sheet of paper and therefore it can never be used as to commit fraud against the credit card companies or consumers.  That piece of paper has no value to the malicious attacker and therefore doesn’t need to be protected, at least not to the same degree that the masked data needs to.  There may still be other data of value associated with the record, but the truncated data itself has no data.

If you’re viewing the data on the screen and you can only see a small portion of the data, you don’t know if you’re viewing truncated or masked data without digging deeper into the process.  Can the data be recovered in some way or is what’s in the database the same thing you’re seeing on the screen.  If you’re on the average sales floor, you can review the tickets for the day and see the last four digits of the card number on the receipts and the reports.  If the application has been built correctly, it won’t matter if you’re a salesperson or the manager, you won’t be able get more than the last four digits since they aren’t being saved in the store and there’s no way for anyone in the store to get the data back from system since it’s been truncated and no longer exists at that location.

Switch to the back office and the accounting or loss prevention departments and it’s a different story.  The default view that the members of these departments should be seeing is only the last four digits of the card number.  However, if there’s a billing issue or a potential fraud situation, company personnel have the ability to unmask the full card number as part of their research.   The data still exists on the server, however the majority of the time it is being hidden (masked); only when someone with legitimate business need reveals it is it shown.  Since the data is available for recall on the servers, they are fully in scope for a PCI assessment and need to be protected appropriately. 

To answer the question, data at rest can never be ‘masked’.  It’s only when it is recalled and presented in part to the user that it is considered masked.  This is why you don’t see masking as an option in requirement 3.4.  If you’re only receiving cardholder data that contains the a subset of the full card number, such as the last four or the first six and the last four, then it’s been truncated.  At that point you don’t have the full card number, it can’t be reconstructed and it doesn’t have to be protected as if it was cardholder data.  That’s not to say the other data associated with that record don’t have value and shouldn’t be protected, however truncated data is not governed by the PCI requirements. 

If your company is receiving the full card number but only displaying the masked to workers, even if no one at your company has access to the card holder data, you’re responsible for protecting the data pursuant to the PCI requirements.  If there’s no need for the data, ask for truncated data in the first place and save your company the effort of dealing with PCI, QSA’s and the entire Report on Compliance process.  I’m a nice guy, but even my biggest fans amongst the clients I deal with will tell you that there’s always a certain level of pain associated with having me come on-site for the annual review. 

[Slashdot] [Digg] [Reddit] [del.icio.us] [Facebook] [Technorati] [Google] [StumbleUpon]

3 responses so far

3 Responses to “Masking vs. Truncating”

  1. […] Masking vs. Truncating – Network Security Blog […]

  2. Securityon 30 Dec 2009 at 1:17 pm

    We have implemented a Dynamic Data Masking solution at the SQL*Net Protocol Layer. In this way we can intercept all inbound SQL while it is still outside of the database.
    We have a Rules Engine that acts as an Oracle listener. The Rules allow us to implement security policies at the enterprise level.

    A Rule can match SQL based on a number of options, not the least of which is SQL text, but also the UserID, Program, Time of Day, IP Address of the origination.

    If the criteria of the rule is matched, we apply an appropriate action. Action include rewrite, block, redirect to mention a few.

    One of the simplest illustrations of this is an application sends in SELECT NAME, we rewrite the statement to SELECT SUBSTR(NAME,1,2)||’***’ which will take the name ‘Tiger’ and display it as “Ti***”. There are a variety of truncation, masking and scrambling algorithms available.

    This has proven to work with any application, including in DWH environments that use a variety of tools, BO, OBIEE, Cognos, etc.
    It also works with Dev Tools such as Toad, DBArtisan, PL/SQL, SQL*Plus and others.

    Also we have implemented this in ERP/CRM applications where we do not have access to the source code.

    The beauty of this solution is that the underlying data is not masked, but it is returned masked at the presentation layer. What this allow us to do is to use this in PRODUCTION as well.

    We have different groups of Production DBA’s. Some are local employees and others are cross-border
    contractors. Both groups use Toad and have SYSDBA. The local employees are permitted to see the real data, but rule identifies requests from the cross-border contractors and they do not get to see the real data when they are browsing. But if we do need to give access, then we can temporarily disable the rule for an hour and then turn the rule back on.

  3. Stephon 07 May 2012 at 7:23 am

    Thanks! This was very helpful and just what I was looking for after reading section 3.4. :)

Trackback URI | Comments RSS

Leave a Reply

%d bloggers like this: