Lightboard Lessons: Secure Data Tokenization

Great john ! Very interesting . Waiting for irules that does the job . One question : any decryption mechanism occurs server side to meet PCI DSS require, right ? So if the sensitive data reach the server in an obfuscated or even encrypted format , nothing could be done to this data in terms of validation / transactions /verification, i mean these data are finally useless . So why do some organisation or website require users to post it.

Sorry if i misunderstand something john .

Hi John! I have been looking at the example in the SDT white paper and if I'm not wrong there seems to be some pieces missing in the code examples. In the Extractor iRule there is a connect but no send/recieve... Any comments to that?

@Fulmetal, great question! In this scenario, a company that processes sensitive data (credit card numbers, personal information, etc) would need to ensure that all their web servers are compliant with all the PCI/DSS requirements. That can be a daunting task. Because of the nature of what these companies do (banks, online marketplaces, etc), they have a valid business requirement to ensure their users can post this sensitive data. The solution outlined here allows these same companies the ability to move all the PCI/DSS compliance off their web servers and onto the BIG-IP. This significantly streamlines all the compliance requirements they have to do.

@Mats Nystrom, I reached out to the guys who contributed to the code and here's some feedback from them:

We are not supposed to have a send or receive, the request is being parsed and we are simply releasing the TCP connection:

TCP::payload replace 0 [TCP::payload length] $newdata3 
TCP::release

Then parsing it back in the response from voltage:
when HTTP_RESPONSE {  Collect HTTP response data

by the way, there is a small typo there in the example as you are saying you are ending CLIENT_DATA and you are only ending the IF statement … that might throw people off:


when CLIENT_DATA { 
if {[TCP::payload] contains "GET /tokenize?"} { 
 Optional logging for debugging log local0. "Tokenization GET request" 
} else { log local0. "Some other request - let it through" TCP::release return 

} end when CLIENT_DATA 

 get the query string: this what we want to encrypt set plaintext [findstr [TCP::payload] "data=" 5 "&"]

Let me know if you have any other questions. Thanks!

Hi John!

Thanks for your answer!

I was refering to the Intercept_CC iRule that does the extraction and the sideband connection to the encryptor. I still think it needs send and recv. But on the other hand I might be wrong!

(Adding some lines of code to make it more understandable)

 Build simple GET request to encrypt credit card number
set tokenizationRequest "GET /tokenize?data=$ccNum HTTP/1.1\r\nUserAgent: AlmostCurl!\r\nHost: ${static::HostString}\r\nAccept: */*\r\n\
r\n"

 Connect to encryptor virtual server
set TokenServer [connect -protocol TCP -myaddr $static::myaddr -timeout
100 -idle 5 -status connect_status $static::TokenizationVirtualServer]


 Adding "send and recv" that I think is missing in whitepaper
set send_info [send -timeout 3000 -status send_status $TokenServer $tokenizationRequest]
 Not a very robust recv, needs adjustments...
set recv_data [recv -timeout 3000 $TokenServer]


set Token [findstr $recv_data "" 7 ""]
set TokenizedData "$FirstPartOfInboundRequest$Token$SecondPartOfInbound
Request"