Credit card check
If you have an application that accepts credit cards, or your websites have access to database servers that store credit card numbers, you must use Data Leak Prevention (DLP) measures and configure protection for each type of credit card that you accept.
The NetScaler Web App Firewall Credit Card check prevents attackers from exploiting Data Leak Prevention flaws to obtain credit card numbers of your customers. By following simple configuration steps, you can enforce protection of one or more of the following credit cards: 1) Visa, 2) Master Card, 3) Discover, 4) American Express (Amex), 5) JCB, and 6) Diners Club.
The Credit Card security check examines server responses to identify instances of the target credit card numbers, and applies a specified action when such a number is found. The action can be to transform the response by X’ing out all but the last group of digits in the credit card number, or to block the response if it contains more than a specified number of credit card numbers. If you specify both, the block action takes precedence. The Maximum credit cards allowed per page setting determines when the block action is invoked. The default setting, 0 (no credit card numbers allowed on the page), is the safest, but you can allow up to 255. Depending on where the violation is detected in the response and the block action gets triggered, you might get fewer than the maximum allowed number of credit cards in the response.
To avoid false positives, you can apply relaxations to exempt specific numbers from the Credit Card check. For example, a social security number, purchase order number, or Google account number might be similar to a credit card number. You can specify individual numbers or use a regular expression to indicate the string of digits to be bypassed when processing the response URL for credit card inspection.
If you’re not sure which credit card numbers to exempt, you can use the learn feature to generate recommendations based on the learned data. To get optimal benefit without compromising performance, you might want to enable this option for a short time to get a representative sample of the rules, and then deploy the relaxations and disable learning.
If you enable the log feature, the Credit Card check generates log messages indicating the actions that it takes. You can monitor the logs to determine whether responses to legitimate requests are getting blocked. A large increase in the number of log messages can indicate thwarted attempts to gain access. By default, the doSecureCreditCardLogging parameter is ON, so the credit card number is not included in the log message generated by the safe commerce (Credit Card) violation.
The stats feature gathers statistics about violations and logs. An unexpected surge in the stats counter might indicate that your application is under attack.
To configure the Credit Card security check for protecting your application, configure the profile that governs inspecting the traffic to and from this application.
Note:
A website that does not access a SQL database usually does not have access to sensitive private information such as credit card numbers.
Using the command line to configure the credit card check
In the command line interface, you can use either the set appfw profile command or the add appfw profile command to activate credit-card checking and specify which actions to perform. You can use the unset appfw profile command to revert back to the default settings. To specify relaxations, use the bind appfw command to bind credit card numbers to the profile.
To configure a credit card check by using the command line
Use either the set appfw profile command or the add appfw profile command, as follows:
set appfw profile <name> -creditCardAction ( ([block][learn] [log][stats]) | [none])set appfw profile <name> -creditCard (VISA | MASTERCARD | DISCOVER | AMEX | JCB | DINERSCLUB)set appfw profile <name> -creditCardMaxAllowed <integer>-
set appfw profile <name> -creditCardXOut ([ON] | [OFF])<name> -doSecureCreditCardLogging ([ON] | [OFF]) -
To configure a Credit Card relaxation rule by using the command line
Use the bind command to bind the credit card number to the profile. To remove a credit card number from a profile, use the unbind command, with the same arguments that you used for the bind command. You can use the show command to display the credit card numbers bound to a profile.
-
To bind a credit card number a profile
bind appfw profile <profile-name> -creditCardNumber <any number/regex> “<url>”Example: bind appfw profile test_profile -creditCardNumber 378282246310005
http://www.example.com/credit\_card\_test.html-
To unbind a credit card number from a profile
unbind appfw profile <profile-name> -creditCardNumber <credit card number / regex> <url> -
To show the list of credit card numbers bound to a profile.
show appfw profile <profile>
-
Using the GUI to configure the credit card check
In the GUI, you configure the credit card security check in the pane for the profile associated with your application.
To add or modify the Credit Card security check by using the GUI
-
Navigate to Web App Firewall > Profiles, highlight the target profile, and click Edit.
-
In the Advanced Settings pane, click Security Checks.
The security check table displays the currently configured action settings for all the security checks. You have 2 options for configuration:
- If you just want to enable or disable Block, Log, Stats, and Learn actions for Credit Card, you can select or clear check boxes in the table, click OK, and then click Save and Close to close the Security Check pane.
- If you want to configure additional options for this security check, double click Credit Card, or select the row and click Action Settings to display additional options as follows:
-
Out—Mask any credit card number detected in a response by replacing each digit, except the digits in the final group, with the letter “X.
-
Maximum credit cards allowed per page—Specify the number of credit cards that can be forwarded to the client without triggering a block action.
-
Protected Credit Cards. Select or clear a check box to enable or disable protection for each type of credit card.
-
You can also edit the Block, Log, Stats and Learn actions in the Credit Card Settings pane.
After making any of the above changes, click OK to save the changes and return to the Security Checks table. You can proceed to configure other security checks if needed. Click OK to save all the changes you have made in the Security Checks section and then click Save and Close to close the Security Check pane.
-
-
In the Advanced Settings pane, click Profile settings. To enable or disable secure logging of credit card Numbers, select or clear the Secure Credit Card Logging check box. (By default, it is selected).
Click OK to save the changes.
-
To configure a Credit Card relaxation rule by using the GUI
- Navigate to Web App Firewall > Profiles, highlight the target profile, and click Edit.
- In the Advanced Settings pane, click Relaxation Rules. The Relaxation Rules table has a Credit Card entry. You can double click, or select this row and click Edit to access the Credit Card Relaxation Rules dialogue. You can perform Add, Edit, Delete, Enable, or Disable operations for relaxation rules.
Using the learn feature with the credit card check
When the learn action is enabled, the Web App Firewall learning engine monitors the traffic and learns the triggered violations. You can periodically inspect these learned rules. After due consideration, if you want to exempt a specific string of digits from the Credit Card security check, you can by deploy the learned rule as a relaxation rule.
-
To view or use learned data by using the command line interface
show appfw learningdata <profilename> creditCardNumberrm appfw learningdata <profilename> -creditcardNumber <credit card number> "<url>"export appfw learningdata <profilename> creditCardNumber -
To view or use learned data by using the GUI
- Navigate to Web App Firewall > Profiles, highlight the target profile, and click Edit.
- In the Advanced Settings pane, click Learned Rules. You can select the Credit Card entry in the Learned Rules table and double-click it to access the learned rules. You can deploy the learned rules or edit a rule before deploying it as a relaxation rule. To discard a rule, you can select it and click the Skip button. You can edit only one rule at a time, but you can select multiple rules to deploy or skip.
You also have the option to show a summarized view of the learned relaxations by selecting the Credit Card entry in the Learned Rules table and clicking Visualizer to get a consolidated view of all the learned violations. The visualizer makes it very easy to manage the learned rules. It presents a comprehensive view of the data on one screen and facilitates taking action on a group of rules with one click. The biggest advantage of the visualizer is that it recommends regular expressions to consolidate multiple rules. You can select a subset of these rules, based on the delimiter and Action URL. You can display 25, 50, or 75 rules in the visualizer, by selecting the number from a drop-down list. The visualizer for learned rules offers the option to edit the rules and deploy them as relaxations. Or you can skip the rules to ignore them.
Using the log feature with the credit card check
When the log action is enabled, the Credit Card security check violations are logged in the audit log as APPFW_SAFECOMMERCE or APPFW_SAFECOMMERCE_XFORM violations. The Web App Firewall supports both Native and CEF log formats. You can also send the logs to a remote syslog server.
The default setting for doSecureCreditCardLogging is ON. If you change it to OFF, both credit card number and type are included in the log message.
Depending on the settings configured for the Credit Card checks, the application-firewall generated log messages might include the following information:
- Response was blocked or not blocked.
- Credit card numbers were transformed (X’d out). A separate log message is generated for each transformed credit card number, so multiple log messages might be generated during processing of a single response.
- Response contained the maximum number of potential credit card numbers.
-
Credit card numbers and their corresponding types.
-
To access the log messages by using the command line
Switch to the shell and tail the ns.logs in the /var/log/ folder to access the log messages pertaining to the Credit Card violations:
- Shell
-
tail -f /var/log/ns.log grep SAFECOMMERCE
-
To access the log messages by using the GUI
-
The GUI includes a very useful tool (Syslog Viewer) for analyzing the log messages. You have a couple of options for accessing the Syslog Viewer: Navigate to the target profile > Security Checks. Highlight the Credit Card row and click Logs. When you access the logs directly from the Credit Card security check of the profile, it filters out the log messages and displays only the logs pertaining to these security check violations.
-
You can also access the Syslog Viewer by navigating to NetScaler > System > Auditing. In the Audit Messages section, click the Syslog messages link to display the Syslog Viewer, which displays all log messages, including other security check violation logs. This is useful for debugging when multiple security check violations might be triggered during request processing.
The HTML based Syslog Viewer provides various filter options for selecting only the log messages that are of interest to you. To access Credit Card security check violation log messages, filter by selecting APPFW in the dropdown options for Module. The Event Type displays a rich set of options to further refine your selection. For example, if you select the APPFW_SAFECOMMERCE and APPFW_SAFECOMMERCE_XFORM check boxes and click the Apply button, only log messages pertaining to the Credit Card security check violations appear in the Syslog Viewer.
If you place the cursor in the row for a specific log message, multiple options, such as Module and EventType, appear below the log message. You can select any of these options to highlight the corresponding information in the logs.
-
Example of a Native format log message when the response is not blocked
May 29 01:26:31 <local0.info> 10.217.31.98 05/29/2015:01:26:31 GMT ns 0-PPE-0 :
default APPFW APPFW_SAFECOMMERCE 2181 0 : 10.217.253.62 1098-PPE0
4erNfkaHy0IeGP+nv2S9Rsdu77I0000 pr_ffc http://aaron.stratum8.net/FFC/CreditCardMind.html
Maximum number of potential credit card numbers seen <not blocked>
<!--NeedCopy-->
Example of a CEF format log message when the response is transformed
May 28 23:42:48 <local0.info> 10.217.31.98
CEF:0|Citrix|NetScaler|NS11.0|APPFW|APPFW_SAFECOMMERCE_XFORM|6|src=10.217.253.62
spt=25314 method=GET request=http://aaron.stratum8.net/FFC/CreditCardMind.html
msg=Transformed (xout) potential credit card numbers seen in server response
cn1=66 cn2=1095 cs1=pr_ffc cs2=PPE2 cs3=xzE7M0g9bovAtG/zLCrLd2zkVl80002
cs4=ALERT cs5=2015 act=transformed
<!--NeedCopy-->
Example of a CEF format log message when the response is blocked. The credit card number and type can be seen in the log, because the doSecureCreditCardLogging parameter is disabled.
May 28 23:42:48 <local0.info> 10.217.31.98
CEF:0|Citrix|NetScaler|NS11.0|APPFW|APPFW_SAFECOMMERCE|6|src=10.217.253.62
spt=25314 method=GET request=http://aaron.stratum8.net/FFC/CreditCardMind.html
msg=Credit Card number 4505050504030302 of type Visa is seen in response cn1=68
cn2=1095 cs1=pr_ffc cs2=PPE2 cs3=xzE7M0g9bovAtG/zLCrLd2zkVl80002 cs4=ALERT cs5=2015
act=blocked
<!--NeedCopy-->
Statistics for the credit card violations
When the stats action is enabled, the corresponding counter for the Credit Card check is incremented when the Web App Firewall takes any action for this security check. The statistics are collected for Rate and Total count for Traffic, Violations, and Logs. The increment of the log counter can vary depending on the configured settings. For example, if the block action is enabled and the Max Allowed credit card setting is 0, the request for a page that contains 20 credit card numbers increments the stats counter by one when the page is blocked as soon as the first credit card number is detected. However, if block is disabled and transform is enabled, processing the same request increments the statistics counter for logs by 20, because each credit card transformation generates a separate log message.
-
To display Credit Card statistics by using command line
At the command prompt, type:
sh appfw statsTo display stats for a specific profile, use the following command:
stat appfw profile <profile name>To display Credit Card statistics by using GUI
- Navigate to System > Security > Web App Firewall.
- In the right pane, access the Statistics Link.
- Use the scroll bar to view the statistics about Credit Card violations and logs. The statistics table provides real-time data and is updated every 7 seconds.
Highlights
Note the following points about the Credit Card security check:
- The Web App Firewall enables you to protect credit card information and detect any attempts to access this sensitive data.
- To use the Credit Card protection check, you must specify at least one type of credit card and an action. The check is then applied to HTML, XML, and Web 2.0 profiles.
-
You can pipe the output of sh appfw profile command and grep for CreditCard to see all the Credit Card specific configuration. For example, sh appfw profile my_profile grep CreditCard displays the configured settings of various parameters as well as the relaxation rules pertaining to the Credit Card check for the Web App Firewall profile named my_profile. - You can exclude specific numbers from Credit Card inspection without bypassing the security check inspection for the rest of the credit card numbers.
- Relaxation is available for all Web App Firewall protected credit card patterns. In the GUI, you can use the visualizer to specify Add, Edit, Delete, Enable, or Disable operations on relaxation rules.
- The Web App Firewall learning engine can monitor the outgoing traffic to recommend rules based on observed violations. Visualizer support is also available for managing the learned credit card rules in the GUI. You can edit and deploy the learned rules, or skip them after careful inspection.
- The setting for number of allowed credit cards applies to each response. It does not pertain to the cumulative total of credit card numbers observed during the entire user session.
- The number of X’d out digits depends on the length of the credit card numbers. Ten digits are X’d out for credit cards that have 13 through 15 digits. Twelve digits are X’d out for credit cards that have 16 digits. If your application does not require sending the entire credit card number in the response, Citrix recommends that you enable this action to mask the digits in the credit card numbers.
- The X-out operation transforms all the credit cards and works independently of the configured settings for the maximum number of allowed credit cards. For example, if there are 4 credit cards in the response and the creditCardMaxAllowed parameter is set to 10, all 4 credit cards are X’d-out, but they are not blocked. If the credit card numbers are spread out in the document, a partial response with X’d-out numbers might be sent to the client before the response is blocked.
- Do not disable the doSecureCreditCardLogging parameter before due consideration. When this parameter is turned off, the credit card numbers are displayed and are accessible in the log messages. These numbers are not masked in the logs, even if the X-out action is enabled. If you are sending logs to a remote syslog server, and the logs are compromised, the credit card numbers can be exposed.
- When the response page is blocked because of a Credit Card violation, the Web App Firewall does not redirect to the error page.