Posts tagged business
Thank you, internets, for all the feedback I’ve gotten on BoomTime: Risk As Economics. Of course my slides are nigh indecipherable without my voiceover, and my notes didn’t make it to the slideshare, so here are some notes to fill in (some) of the blanks until the video hits YouTube (SiRA members will get early access to SiRAcon15 videos via the SiRA Discourse forum, BTW). (You will want to look at the notes and the slides side by side, probably, as one doesn’t make sense w/o the other.)
An intro here is that in addition to being a product manager specializing in designing large-scale, data-driven security/anti-fraud/anti-abuse automation (yep, that’s a thing), I’m also an economics nerd. (Currently working on an MS in Applied Econ at JHU). Given my background in payments, and a general penchant for “following the money”, framing technology problems on platforms through an economic/financial lens is second nature.
Themes of Security Economics
A list of typical themes one hears when discussing information security & economics: within businesses we are requested to talk about exposures and threats in terms of financial impact, or consider the financial (money) drivers. Also the theme of information asymmetries (Market for Lemons) is a big theme of information economics and of software markets in general: when information about quality of a product is difficult to find, that lack of transparency drives down prices, and we get less incentives to improve quality. (Ask me questions about market signals as a mechanism for correcting information asymmetries.) “Make it more expensive for the attacker” or “don’t outrun the bear, outrun the guy next to you” is also an idea that gets raised. Game theory, concepts of quantifying “risk” (exposure, tolerance), markets for exploits & vulns is a hot topic at the moment, as is behavioral economics and all things related to incentive design – gamification being the most buzzwordy example, perhaps, but framing as a method for improving consumers’ ability to make good choices related to privacy preferences also something that has come up a bit lately in security economics research. Anyway, these are some themes that tend to be repeated in recent research literature.
I spend a lot of time thinking about how to use economics to create safer, more secure systems. That’s what’s been driving my forays into seeing if how economists deal with grey markets might work in infosec, what we as system designers can learn from game theory, how to connect secure networks using graph theory (haha), why submitted a paper to WEIS, and why, now, I’ve gone back to school (again) to study economics in more depth. I’m taking microeconomic theory now. It’s just like micro the last two times around, with less folksy examples and more calculus.
So. What I want to talk to you about is a little idea I had regarding inferior goods as they may relate to a firm’s level of maturity, and how that might be interesting both on it’s own, and if we had the concept of a CPI (consumer price index) for security. Let’s call this @selenakyle’s Security CPI, in case anyone wants to adopt this idea in the pantheon of the Hutton Security Mendoza line or Corman’s HD Moore’s law.
What’s an inferior good?
The simple answer is: an inferior good is one where when consumer income rises, their demand for the good decreases. (Period. “Inferior goods” as a concept is totally distinct from information asymmetry and conversations about lemon markets)
More detail on inferior goods:
Start with the assumption that consumers seek to maximize their utility given a fixed budget, i.e. they have an income, and they spend it in a way to get the most for their money, given their individual preferences. When consumers experience an increase in income, they will consume *more* of most goods (due to rational utility maximization and non-satiation) but will purchase less “inferior” goods – potentially because they can afford better.
A classic example is potatoes within a food budget; when income goes up many consumers will purchase less potatoes…and more meat, or higher-end food items. So, the effect of changes in prices may also be affected by the mix of normal vs inferior goods in the bundle. An example – when prices go up and income stays flat, a consumer may change their mix to include more inferior goods. Or another example – when prices are flat and income goes up, a consumer may shift their mix to include less inferior goods. In any case, the consumer will shift their consumption to maximize their utility, and adjust to new prices or income levels.
The key here is what happens as income rises: does the mix of products in the bundle consumed change (preferences shift) or is it just *more* of the products (same preferences)?
When it comes to PCI-DSS, it is easy to get confused about whether or not it’s working. And part of the reason why is that it has never been very clear what problem the PCI-DSS is attempting to solve. Is it trying to prevent fraud, or ensure a dependable minimum level of security in the payment system? My answer so far is neither.
Fraud has always been a problem of payment systems. Cards, like cash, can be counterfeited – and as technology to make counterfeiting more difficult advances, so too does the technology with which anti-counterfeiting methods can be defeated. In card payments, liability for fraudulent transactions is defined within their operating rules (for example the Visa Operating Regulations), and tends to be determined on a transaction-by-transaction basis. To prevent fraud the card issuer that authorizes the transactions needs as much information as possible to detect off behavior, and the merchant that accepts the transaction needs to take some basic precautions at the point-of-sale (in the U.S., at the simplest level this is swipe the card and check the signature). Liability for fraud in the face-to-face environment (when the merchant follows the correct operating procedures) usually rests with the Issuing bank. Liability for fraud in the Card Not Present (CNP) world often rests with the merchant, because the merchant *can’t* follow the existing procedures — no signature.
The point here is that liability is determined on a case-by-case basis, applying the operating rules to the details of each transaction, as evidenced by the data that has gone back and forth between the merchant and cardholder, and then from the merchant through their acquirer/processor to the issuing bank and back again. Transactional liability is both well-defined and, given the scenario, relatively easy to assign.
However when payments started going online, something interesting happened. It became fairly obvious that the information needed to process a payment online (16-digit PAN, expiration date, address information of the cardholder) was also (obviously) being transmitted online and (not so obviously, but, in the early 2000’s kind of terrifying) being stored online. This opened up the possibility that an entity could get popped and lose not just a week’s worth of transactions at one point-of-sale — but hundreds, thousands, *millions* of cards in a single swoop, and fraudsters could use those cards downstream.
Let’s review that scenario: an online retailer gets popped and then those cards get used…at OTHER online retailers. Or face-to-face retailers that allow key-entered (manually typed in) transactions. Maybe across many retailers. And across many Issuers. Not a “local” merchant, like a gas station, where it would be fairly obvious to connect the fraud cases that follow. How long would it take to detect it? How many downstream participants in the system, following the operating procedures as designed, would have to deal with the negative aftershocks coming from that one compromise event? And since the party that “should” be accountable is not actually part of the manifesting fraud transactions, how can liability be shifted?
Historical note (fraud prevention infrastructure): In the early 2000’s the discussion was mostly focused on the CNP environment because a) it was new, b) it was the wild west, and c) a number of high profile web companies got hax0red. Payment/fraud geeks can think of this as the era of: Address Verification System (AVS) was *pretty* well established at this point, SET was finally acknowledged as totally DOA, the drumbeat for 3D Secure was on but *nobody* was adopting yet (it was before the big push in the EU)…and early days for chip. Also: still on regular DES in the PIN infrastructure.
Historical note (fraud prevention & security strategy): One may also remember the era in this way: Issuing banks owned authorization strategy (meaning, they were making the approval decisions on transactions) and very few merchants had made investments in fraud screening. All of the banks were getting a little spooked that databases full of juicy card details were sitting outside the payment system and that so many of them were accessible from the internet. Merchants of yore never needed to store card details — just receipts.
Back to the scenario: one of those wild west outposts full of juicy card data gets popped, downstream participants (Issuers, merchants, cardholders) feel the pain, the compromised party may or may not be known. The network operating guidelines’ transactional rules don’t adequately assign liability back to the accountable party: what are the banks going to do? Well, there are pretty much two options: adjust the system to assign liability back to an accountable party OR go outside the system to demand restitution. The former is difficult and the latter takes issues of the payment system outside standard channels which for several reasons is not ideal for the payment systems themselves, who have elaborate systems set up for arbitration and compliance to address issues between participants.
It is out of this alchemy that the card network data protection programs were born. They are liability plays all the way, and I give them the benefit of the doubt that they were meant to be incentives to encourage merchants to “do the right thing” and secure payment card data. MasterCard and Visa developed slightly different programs. My paraphrase is: MasterCard’s SDP essentially said to merchants — we trust you to secure the data, but if you get hacked we are going to levy fines to high heaven. And Visa’s CISP/AIS programs essentially said — we want to see some proof in advance — so get audited by a Qualified Security Assessor (QSA) who will attest you’re cool, and then if something happens but you were compliant, we’ll work with you.
Both approaches are sticks, neither is a carrot. The subsequent merger and morph into the PCI-DSS sort of also merged the compliance program approach. Merchants must both get attestations of compliance AND if breached there are programs for providing remuneration to downstream system participants affected. (BTW: PCI has more than one standard in it’s purview, though most people when referring to PCI mean the Data Security Standard…poor PIN/PED requirements, always subordinated to DSS…)
The PCI-DSS requirements themselves were developed as a set of reasonable industry best practices (I can only speak w/authority on intentions behind the Visa program progenitors but let’s just go with it). At their best, they are meant to provide guidance to merchants who otherwise would have no idea how to protect cardholder data. The criticisms of the DSS itself are wide-ranging but I personally find the DSS simply basic, not bad, and just a narrow view (focused on payment card data and systems) and yet still very general (security is contextual and needs to be tailored). Really the DSS should have been left as guidance, but unfortunately there’s this business of being assessed and a whole industry that has grown-up around QSA-dom. I find the process of getting assessed to be much more objectionable than the requirements themselves: “compensating controls” could be a book in and of itself, but QSA’s are auditors first and foremost (ROC on), and generally asked to interpret or design strategic security as a secondary concern, if at all.
Now, while in the early 2000’s the focus of all this angst was on CNP merchants, since then the scope of the PCI-DSS problem has embiggened. The DSS quickly expanded to include non-CNP, payment processors, and even the banks themselves. So a program of best practices designed to secure payment card data *outside* of the payments infrastructure got some retrofitting to also cover payment card data ostensibly *inside* the payments infrastructure. You can’t see me right now, but I’m raising an eyebrow, because the payment infrastructure is so interdependent, and has so many legacy components – to step-level up the security of payments infrastructure is impossible to manage without some serious planning, a boatload of direct economic impacts, and hell of a lot of specificity. *Upgrade to triple-DES I’m looking at you*. All I’m saying is, if you’ve got payments infrastructure requirements – don’t bring a knife to a gun fight.
Speaking of knife fights, let’s chat about fraud. Yes, fraud may go up after a major compromise. If counterfeiters flood the market with bad cards, it may take a while for the issuer fraud screening to kick in. Card re-issuance is expensive and so some issuers take a risk and leave potentially compromised cards open and then miss some fraud transactions. However, if major compromises go down, will the fraud rate also go down? That is less clear. Motherlode-sized compromises are a recent phenomenon, and while the fraud rates have ticked-up in the past two years, from 2003-2010 they were hovering near historical lows. Note: fraud losses in total dollars continue to climb, but the global fraud rates (i.e. the portions of total payment volume that ends up as fraud) are relatively steady over the past decade, less than 6 basis points (percents of a percent). (If you’re a U.S. CNP merchant you’re laughing out loud that people would be in a huff over 6 bp). The Nilson Report is a good place to get some data. I also like the CyberSource report but I’m writing this all in notepad.
My point here is that major compromises (that have been getting a LOT of press and attention) are only ONE method the fraud economy uses to operate. All of other methods like skimming, social engineering, insider threats, and plain old theft still exist. And so with all of this, how is fraud being kept down below 10bp? That’s a multiple choice answer: some markets have opted for prevention strategies (Europe loves their chip & PIN and 3D Secure is working there), others have opted for more advanced detection strategies (in the U.S., both issuers and merchants have adopted more advanced fraud screening technology). There are a lot of influences, but it’s pretty clear that most entities that get hit with transactional fraud losses are a) not waiting around for a panacea, and b) not depending on upstream security to reduce their exposure to fraud. (Fraud counterpoint: if you’ve got fraud prevention requirements, don’t bother with a gun in a knife fight.)
Thus if we are to ask ourselves what the PCI-DSS program (requirements plus compliance program) is set up to solve, the answer is something along the lines of “to provide a benchmark of *NOT negligent*” for individual system participants. And that might actually be an okay scope, as long as everyone’s clear what problem is being solved and that it is in the industry/community’s best interest to solve it. However, to solve problems like “fraud prevention” or “payments infrastructure security”, stronger — or at least more direct — medicine (and economic incentives) will be required.
This particular post was inspired in part by this Business Week Online article. As an industry, if we are looking to make improvements to infrastructure security or fraud management, we need to be asking the right questions. And as we seek to improve defenses and system strategy in general, it’s useful to clarify the different problem spaces of fraud & security, if only to confirm the variety of solution sets (technology, process, economics, compliance) we have to work with.
I just finishing giving a third version of a presentation that I put together on lessons Infosec/Risk/Platform owners can learn from classic Operations Research/Management Science type work. The talk (“Operating * By the Numbers”) was shared in Reykjavik (Nordic Security Conference), Seattle (SIRACon 2013), and in Silicon Valley (BayThreat). Thanks everyone who attended, especially those of you who asked questions and provided feedback.
A few folks have asked for reading lists. Some asked for the quick run-through sample from my bookshelf, others want some further reading. Here’s the quick run through:
- Introduction to Mathematical Statistics and Its Applications (5th Edition), Richard J. Larsen and Morris L. Marx
- Out of Control: The New Biology of Machines, Social Systems, & the Economic World, Kevin Kelly
- The Illuminatus! Trilogy Robert Shea & Robert Anton Wilson
- How to Protect Yourself from Crime, Ira Lipman (Guardsmark)
- Hackers: Heroes of the Computer Revolution – 25th Anniversary Edition, Steven Levy
- Computer Crime: A Crimefighter’s Handbook, David Icove, Karl Seger, William VonStorch
- Maximum Security: A Hacker’s Guide to Protecting Your Internet Site and Network, Anonymous
- Information Security Risk Analysis, Thomas R Peltier
- A First Course in Probability, Sheldon Ross
- Strategy, Basil H. Liddell Hart
- Mostly Harmless Econometrics: An Empiricist’s Companion, Joshua D. Angrist and Jörn-Steffen Pischke
- The Dilbert Principle, Scott Adams
- Introduction to Topology: Third Edition, Bert Mendelson
- Exploratory Data Analysis (Quantitative Applications in the Social Sciences), Frederick Hartwig with Brian E Dearing
- Game Theory Evolving: A Problem-Centered Introduction to Modeling Strategic Interaction (Second Edition), Herbert Gintis
- Practical Statistics Simply Explained (Dover Books on Mathematics), Russell Langley
- Excel Data Analysis For Dummies, Stephen Nelson
- Operations Management: Contemporary Concepts, Roger Schroeder
And I also want to give another shout-out to Combat Modeling, by Alan Washburn and Moshe Kress, of the Naval Postgraduate School. It’s a pricey text, but take a look at the table of contents & the topics they cover. Really interesting work to consider for control system designers.
Also, I haven’t read these personally but they are on my “to read” list as they came recommended by fellow quant/risk nerds:
- The Principles and Applications of Decision Analysis : 2 Volume Set, Ronald A. Howard and James E. Matheson
- Decision Analysis for the Professional (pdf link), Peter McNamee & John Celona
And here’s a link to one of my blog posts (Quant Ops), which includes a few references and some thinking on the topic from a different angle.
This post is a first in a series I will be exchanging with Ohad Samet (ok, second, he’s a much quicker blogger than I am), one of my esteemed colleagues in Paypal Risk, and the mastermind behind the Fraud Backstage blog. Read Ohad’s article here.
Despite best efforts to protect systems and assets using a defense-in-depth approach, many layers of controls are defeated simply by exploiting access granted to users. Thus the industry is trying to determine not only how we protect our platforms from external threats, but also how we keep user accounts from being attacked. User credentials being the “keys” (haha) guarding valuable access to both user accounts and to our platfoms, a popular topic among the security-minded these days center around alternatives to standard authentication methods. Typically, the discussion centers not around how an enterprise secures its own assets and users, but about arming consumers who come and go across ISPs, search sites, online banking, social networks…and are are vulnerable to identity theft and privacy invasions wherever they roam.
How many information security professionals does it take to keep a secret?
While there are a number of alternatives out there, focusing on authentication as if it’s a silver bullet misses the point. When we assume that keeping our users secure means protecting (only, or above all other things) the shared secret between us, it leaves us over-reliant on simple access control (the fortress mentality) when as an industry we already know that coordinating layers of protection working together is a more effective model for managing risk. To clarify our exposure to this single point of failure, let’s consider:
2) How does our risk model change if we assume all credentials have been compromised?
Shall We Play a Game…of Twenty Questions?
Really all this nonsense started when we started teaching users to use “items that identify us” as “items that authenticate us”. Two examples, SSN and credit card numbers. SSN we know has been used by employers, banks, credit reporting agencies…as well as for its original purpose, to identify participation in social security (this legislation being considered in Georgia may limit use of SSN and DOB as *usernames* or *identifiers*, although it is silent on using SSN/DOB to verify/authenticate identity).