[BR_forum] Masking Sensitive Data - SSN, Bank account #'s

Doug Meenen · Post by **Doug Meenen** » Fri Jun 05, 2009 7:40 am

Masking SSN #'s, Bank Account #'s, Bank Routing #'s is now required by the Federal Govt, as I understand it, to prevent identity theft.

So in practice, instead of printing an SSN # on a report or other public document, you are required to print only the last 4 digits of the number.

if the SSN = 510-67-1234, you need to print ***-**-1234
same for other sensitive data.
The question is:
Is there a Pic statement or some other form statement that does this automatically?

If this is not in BR yet, then I am requesting it now.SPIC = Secure Pic statement

1. What are you doing to mask the sensitive data on bank deposit slips given out to payroll employees on direct deposit or other forms generated from a BR App that have this data on them?

2. How did you implement that?
Is there a function to do this?

Any help would be appreciated.
Thanks,
Doug Meenen

Doug Meenen

George Tisdale · Post by **George Tisdale** » Fri Jun 05, 2009 8:38 am

Attached is a function FNSPIC$ that will do as you suggest. The MASK statement is simply a normal PIC statement where the #### figures at the end are the only ones to show. The rest of the PIC statement gets turned into a character string and prepended to the number of digits specified.

George L. Tisdale, CPA
Tisdale CPA
75 Junction Square Drive
Concord, MA 01742
(978) 369-5585

GomezL · Post by **GomezL** » Fri Jun 05, 2009 9:20 am

SPIC sounds like an interest “new Feature”.

TAKE SSN$=”123-45-6789”

RINPUT FIELDS “10,10,SPIC(**-**-####)”:SSN$

The point is SSN$ would be displayed as **-**-6789 and allow the operator to view/edit the data without actually knowing the original value.

If the operator wanted, they could type an entire SSN #, and that would be accepted, they could also edit the last 4 digit if they wanted. The SSN$ would not display “123-45-“, but the operator could for example enter a new SSN #.

This would provide very secure data entry.

GomezL@CollectionSoftware.com (GomezL@CollectionSoftware.com)
http://www.CollectionSoftware.com

Doug Meenen · Post by **Doug Meenen** » Fri Jun 05, 2009 9:30 am

Susan, all interested parties,

I have attached 2 documents.
The first is from the Federal Trade Commission. - Guide for Business
The second talks about both Federal and California standards.

Doug Meenen

Gabriel · Post by **Gabriel** » Fri Jun 05, 2009 10:14 am

I guess it would be useful if it also handled input. But wouldn't this be a new "Special Character" in the regular PIC statement, not a new SPIC statement?

It seems like it would be pretty easy to write your own function to do something like this...

gabriel

GomezL · Post by **GomezL** » Fri Jun 05, 2009 10:36 am

Now that you mention it, yes, just a new “Mask Symbol” would work fine.

GomezL@CollectionSoftware.com (GomezL@CollectionSoftware.com)
http://www.CollectionSoftware.com

From: br_forum-bounces@ads.net [mailto:br_forum-bounces@ads.net] On Behalf Of Gabriel Bakker
Sent: Friday, June 05, 2009 12:14 PM
To: Business Rules Forum
Subject: Re: [BR_forum] Masking Sensitive Data - SSN, Bank account #'s

I guess it would be useful if it also handled input. But wouldn't this be a new "Special Character" in the regular PIC statement, not a new SPIC statement?

It seems like it would be pretty easy to write your own function to do something like this...

gabriel

Guest · Post by **Guest** » Fri Jun 05, 2009 11:02 am

According to what I understand, the display of data on a monitor is also required to be masked as an SSN, credit card, bank account, whole number displayed is also a security risk.

So having Rinput fields "x,x,SPIC(***-**-####)" - like Louis's example would handle that.

With BR now:
ssn$="123-45-6789"
Rinput fields "10,10,PIC(***-**-###)": SSN$ - shows the whole number on the screen

Presently, There is no insertion or replacement character to mask these numbers that I am aware of.

The important thing is not how it is implemented, but that IT IS put into the BR Language, as our competing software vendors already have this, and our clients are now asking us about it.

This is not only important, it is required.

Doug Meenen

George Tisdale · Post by **George Tisdale** » Fri Jun 05, 2009 11:28 am

If a special character is to be added to the PIC statement I vote for â€œIâ€

Post by **gordon** » Thu Jun 25, 2009 7:11 am

After discussing this with Dan, I am of the opinion that providing a partially blocked edit feature would be unwise. Entering partially blocked fields can be tricky, particularly if the user arrows across or hits the delete key. It would be a mistake to allow single entry of sensitive blocked information. Either the data in the field should be entered twice, or it should be protected.

We already have the ability to enter data without displaying it as in password entry.

As for displaying partially blocked information, that is another matter.
That can be done a number of ways depending on how the data is stored.