Risk Scenario – Hidden Field / Sensitive Information (Part 4 of 4)

The Summary

It is time to wrap this scenario up. If you are landing here directly with no knowledge of the three previous posts, the hyperlinks are below:

Part 1 – The Scenario
Part 2 – TCOMM A
Part 3 – TCOMM B

The risk assessments for both threat communities (malware and Initech Novelty, Inc.) resulted in risk ratings of MEDIUM. This scenario is different from others in that we performed a risk assessment for two threat communities. Not all scenarios will require this nor is it always practical from a time perspective. When it comes to performing multiple risk assessments for multiple threat communities, the question that usually comes up is: “Which risk rating should I use for the scenario as a whole if the risk rating for each TCOMM is different?”. This is a great question and not one that I will spend a lot of time in this post – but here is how I would reconcile: I would assign the “higher” qualitative risk rating to the scenario. There is a relationship between LEF, PLM and the RISK rating. The risk rating is more reflective on annualized exposure; so I would error on the side of the higher.

Back to this scenario, both FAIR assessments resulted in a risk rating of MEDIUM. Having both of these as MEDIUM somewhat makes gauging the risk for the scenario itself somewhat easier. However we still need to summarize the risk for the decision maker(s) responsible and accountable for the payment application as well as the decision maker accountable for INI’s compliance with PCI-DSS requirements.

Here is how I would summarize the risk:

***

A vulnerability in our e-commerce application was reported to us by one of our customers. The vulnerability was validated by the security group, assessed for risk and has been categorized as a MEDIUM risk. The vulnerability results in the customer’s payment card information being persisted in HTML files that are cached on their PC after making a purchase from our site. It is possible for the payment card information (credit card number, expiration date, and CVV2 code) to be retrieved the HTML files.

There are two threats that we have identified that introduce exposure to the consumer, Initech Novelty Inc., or both. The first is zero day malware, while we believe that most of our customers are Internet security aware, there is not enough information to gauge the effectiveness of the security controls on their PC. We are estimating that our average consumer will encounter a form of zero day malware at least once a year. There is no guarantee that the customer’s cached payment card information would be compromised as a result of the malware but we also cannot guarantee that it would not be compromised. Second, confirming this vulnerability makes INI non-compliant with PCI-DSS requirement 6.5.7; which is related to developing and maintaining secure systems and application. We need to update our Self Assessment Questionnaire to indicate non-compliance with this requirement and report it to our payment processor. Finally, some contributing factors that should be considered as part of this risk assessment are: customer privacy, INI’s obligation to be compliant with PCI-DSS, and INI’s reputation as a result of any incidents related to this vulnerability.

We have estimated INI’s exposure to be between $5,000 and $10,000. This estimate includes both hard and soft dollars encompassing multiple loss forms: our internal response to any reported incidents, costs associated with providing protections to the consumer should there be loss of their payment card information, and the cost to INI to mitigate the risk at a later date if the decision is made to assume the risk. We estimate that the cost to mitigate the risk to an acceptable level (fix the application) is approximately $3,000 soft dollars (internal resource effort).

***

There is one last topic I wanted to write about as part of this scenario series and that is mitigation solutions. Below are some quick hit solutions and recommendations that I would present to an application team.

1.    Use the appropriate HTTP header directives that tell the browser not to store or cache the page being loaded.

2.    Do not use hidden fields to facilitate session management – especially with the confidential information. Use a session database. (BTW, use of hidden fields is not recommended by OWASP – which PCI-DSS references as a source of secure coding guidelines).

3.    Have all payment application changes reviewed by security prior to releasing into production.

***

Feel free to share your thoughts – I welcome the feedback!