 |
This posting is dedicated to all those VCs who were traumatized by their IT security investments.
Here is an application of threat modeling in the pharmaceutical industry. Not Web applications. Not network security. |
This level of threat damage always stimulates a big business in countermeasure technologies. There are hundreds of products and methods from RFID tagging to nano-particles that are being proposed as solutions (not even risk mitigation) to the threat of drug counterfeiting. Most of these technologies are not cost-effective and can be easily sidestepped (to make a fake product, a counterfeiter only has to make it look real - he doesn't have to do the original research, development and manufacturing process).
Not surprisingly, because of the public health implications (how many men die from fake Viagra or women die from fake silicon breast implants), regulators like the FDA are stepping in. California is setting the gold standard like they did with consumer privacy protection - this time with a bill that would require a drug "e-Pedigree".
The California e-Pedigree law (SB 1370) specifies pharmaceutical product serialization which “require the pedigree to contain the drug's unique identification number established at the point of drug manufacture.”
When used through the supply chain, the e-Pedigree will help track and trace product, identify counterfeiters and enable consumers to authenticate the products they buy at the point of sale.
It's impossible for me to estimate how much e-Pedigree will eventually cost (it only becomes mandatory in California in 2011) but it's pretty clear that with all the packaging and information technology it's going to be a pretty steep price for the drug supply chain.
Instead of trying to solve an impossible problem, I decided to model a subset of the e-Pedigree. i.e. use of product serialization at the point of sale to the consumer in a pharmacy. My simple-minded threat model ignores supply chain integration and analyzes the risk associated consumers self-authenticating product.
The notion of having consumers call in a numeric token in order to authenticate a drug they purchased, was first proposed by Johnston, a researcher at Los Alamos Laboratories. There are commercial implementations, available from companies like Dintag and Algoril and Verify Brand. Dintag in particular appears to have the most complete implementation.
How does it work?
Pharmaceutical end user customers would be able to authenticate the validity of a random, ID number printed on packages via a simple Web search query similar to the Google search page. Other channels might also be used – for example: sending a text message with a cell phone or a making a phone call to an automated voice response service. Customers with cell phone cameras could send a picture of the label over the Web to the system, which would extract the ID number using OCR and return a text message to the consumer.
When used by consumers at the point of sale, or at home; product serialization becomes a relatively low-cost, low-tech way to authenticate a product, since there is no supply chain integration required and the large number of consumer eyeballs calling in tokens is free to the manufacturer. I believe that there is also a viral marketing effect as people tell their friends about the system.
I performed a threat analysis of the call-in numeric token method. In a later posting, I plan to publish the actual PTA threat model that was developed.
The threat analysis of the call in numeric token system was performed using the
PTA (Practical Threat Analysis) methodology . The analysis shows that by implementing the right security countermeasures, we can effectively mitigate risk and ensure confidentiality, availability and integrity of system assets.
Threats are denoted (T-XX) and corresponding security countemeasures are denoted (C-XX)
T1 – Attackers may attempt to guess tokens
C01 – Make it difficult to guess by using a large, unpredictable collection of numbers; assure that there are at least 1000x more possible serial numbers than in a typical lot.
C02- Require additional data in the authentication query, for example, lot number.
C03 – Throttle multiple requests from a particular IP address
C16 – Block requests from known spammers using blocklists such as spamhaus.
T2 - Malicious outsiders may attempt to obtain tokens and reuse them on counterfeited products
C02 - Require additional data in the authentication query, for example, lot number.
C04 - The cost of buying legitimate products for the tokens is an economic disincentive
C10 – Use tamper-evident packaging, don't print the token on external package.
C11 - Use query threshold of 3-4 that will prevent attackers from recycling stolen tokens
T3 - Trusted insiders may collude with criminals or competitors to obtain bottle numbers
C05 – Use a diskless interface box to feed the variable printer
C06 – Limit internal network access to the token database
C09 – Enforce strong passwords for system maintainers and recycle regularly
C15 - Require supply chain partners to sign NDA
T4 - Attackers may attempt to cause the service to become unavailable with a DDOS attack
C03 – Throttle multiple requests from a particular IP address
C08 – Do proactive patch management on token query server operating systems
C12 – Use commercial DDOS appliance above a certain query volume
T5 - Attackers may attempt to discredit the token query service with spoofing and/or phishing
C16 – Block requests from known spammers using blocklists such as spamhaus.
C17 - Operate the Web search site under the manfucturer's corporate domain
C18 – Use HTTPS and provide a valid digital certificate for token query server
C19 - Provide branded and digitally signed widget for iGoogle
C20 – Provide consumer protection policy on query Web site
C01 - Make it difficult to guess by using a large, unpredictable collection of numbers, assuring that there are at least 1000x more tokens than in a typical lot size.
