Posts tagged system
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 was distracted earlier this week by a thread on the SIRA mailing list. I found myself reacting to an comment that suggested maybe quantitative risk mgmt seems is “just” plain ol’ SIEMs plus some stats/machine learning. That ended up being a bit of a hot button for a few folks on the list, because then there was a very interesting discussion that got going about data architecture options versus how common security-industry tuned tools work, which is worth a whole dedicated discussion. In any case it put me into a contemplative mood about SIEMs, since I am of two minds about them depending on what environment I’m working in: it’s the “any port in a storm” vs “when you have a hammer everything looks like a nail” thing. But regarding SIEM vs databases, or anomaly detection vs ML, or whatever:
- While acknowledging that apples and pears are both fruit, some people prefer to cut their fruit (agnostic to apple-ness or pear-ness) with very sharp ceramic knives vs, say, good ol’ paring knives, depending on dish being prepared.
- That said, the bowl you put fruit salad into may need to be different (waterproof, airtight, bigger) than a bowl one puts whole fruits in.
- Also, in an even more Zen-like tangent: no matter what bowl or what fruit or what knife is being selected, if you’re making fruit salad you’re going to have to spend some time cleaning the fruit before cutting and mixing it. If the bowl the whole fruits were in is especially dirty, or say, a crate – or a rusty bucket – you may want to spend more time cleaning.
I was going for something Zen.
But I’m not very Zen, I’m pedantic, so here’s some explanation of the analogy:
Apples & Pears are both fruit
- System logs are data that is usually stored in logfiles. Security devices generate system logs, and so do other devices. Errors are often logged, or system usage/capacity. Servers, clients, applications, routers, switches, firewalls, anti-virus systems — all kinds of systems generate logs.
- Financial records, human resource records, customer relationship management records are data that are usually stored in databases. Some may be generic databases, others may be built specifically for the application in question.
- There are also data types that are kind of a cross between the two, for example – a large consumer facing website may have account data. You are a customer, you can login and see information associated with your account – if it’s an email service, previous emails. If it’s an e-commerce site, maybe you can see previous transactions. You can check to make sure your alma mater or favorite funny kitten gif is listed correctly on your account profile. It’s not system logs, and it’s not internal corporate records – it’s data that’s part of the service/application. This type of data is usually stored in a database, though there might be metadata associated with the activity stored in logs.
- In another mood, I might delve further into this criss-cross category, which often results in a “you’ve got your chocolate in my peanut butter…you’ve got your peanut butter in my chocolate” level of fisticuffs.
- But, it’s all DATA.
People have different tool preferences when it comes to cutting fruit
Some capabilities of data-related tools/capabilities:
- Comparing across tables
- Pattern analysis / visualization
- Frequency analysis
- Simple mathematical operations (addition, subtraction, ranking)
- More advanced mathematical operations (exponential functions, regressions, statistical tests, quantile analysis)
- Sentiment analysis or text/string mining
- Blah blah etcer-blah
Basic capabilities tend to be common, or directly comparable, across tools. For example, here’s an article that compares some of the commands that can be used in a traditional SQL database to similar functions in Splunk, a popular SIEM.
The point is, while many tools have many of the desired features, there may be tradeoffs. A product might make it really easy to conduct filtering (via an awesome GUI and pseudocode) and still have limitations when it comes to extracting a set of events across multiple tables that meets ad hoc-developed, but still quite technically specific, criteria. Or, a tool might excel in rapid access to recent records, but crash if there’s a long-term historical trend to analyze. Or, it can be a gem if you’re trying to do some statistical analysis of phenomena but too resource intensive to be used in a production environment.
People have different use cases for cutting fruit
- In some cases data is kept only to diagnose and resolve a problem later
- In some cases data is kept in order to satisfy retention requirements in case someone else wants to diagnose/confirm an event later
- In some cases data is kept because we’re trying to populate a historic baseline so that in the future we have something against which to compare current data
- in some cases data is kept so that we can analyze it and predict future activity/behavior/usage
- In some cases data is kept because it is part of the service / product being supported
Ops is different from Marketing. Statisticians are not often the same people doing system maintenance on a network. Etc.
The container for your data only matters if the container has special properties that facilitate the tools you’re going to apply, your use case for storing the data, or your use cases for processing/manipulating the data. A big use case in the era of always-on web-based services is special containers designed to allow for rapid manipulation and recall of Very Large amounts of data.
- SIEM architecture – “SIEM” is a product category vs a description of architecture, different products may have different architectures, here are a few examples. Typically a SIEM accepts feeds from devices generating logs, and then have functions to consolidate, sort, search, and filter. Here’s how Spunk describes itself:
“Splunk is a distributed, non-relational, semi-structured database with an implicit time dimension. Splunk is not a database in the normative sense …but there are analogs to many of the concepts in the database world.”
Which architecture is the best is a silly question; they are architected differently on purpose. Pick a favorite if you must, but if you work with data, be prepared: you’ll probably not often find yourself in homogenous environments.
About working with data
No matter where your data is sourced, if you want to do something snazzy like use it to train a neural net, or do a fun outlier analysis, then you’re going to have to spend a great deal of time prepping your data, including cleaning it. Some many database architectures claim to make this process easier (I’ve yet to meet an analyst that’s ever described this part of analysis as fun or easy), what’s definitely true is some data storage formats / practices make it harder.
- If your data unstructured – like you might find in key-value pair or document stores – you might have significant work to get it into a more structured format, depending on what research methods you are going to use to conduct your analysis.
- Even with relatively structured data you might find that for one purpose formatting is relevant but when you get to the analysis stage you need to further simplify.
The cooler things we might discover require working with more complex (i.e. less structured) data, which is why advances in manipulation of less structured data, and algorithms that are forgiving of different types of complexity are fun. Sometimes it’s the analytic technique that’s new, sometimes it’s the technology for applying it, but often the “coolness”, or at least the nerdy enthusiasm, is from applying existing techniques & tech to a new data source, OUR data source, to answer OUR question – in a way that hasn’t quite been done before. That’s kind of how research is.
Stop worrying so much about your bowls. Unless the lid is on so tight that you can’t get your fruit salad out.
Author: George Orwell (i.e. Eric Arthur Blair) (1903-1950)
Challenge status: #9 on Radcliffe Publishing Course Top 100 Novels of the 20th Century and frequent target of banning attempts according to the ALA’s Office for Intellectual Freedom. Book #4 on Summer of Banned Books ’13.
Why: Well, when challenged in Florida in 1981 the reasons given were that the book was “pro-communist and contained explicit sexual matter.”
First line: “It was a bright cold day in April, and the clocks were striking thirteen.”
Synopsis: The foreboding classic view of a future that is now partially here: a totalitarian regime that effectively controls not only the behavior but the very thoughts and memories of it’s citizens. Winston Smith is not a loyal member of the party: he has questions and doubts that end up pulling him into a theoretical resistance movement and into the arms of a fellow disbeliever (his lover Julia), both from which he is eventually saved via an active re-education that takes place deep in his heart and within the Ministry of Love (Miniluv).
Thanks to Orwell we now have some amazing vocabulary (thoughtcrime, Big Brother, newspeak, doublethink, unpersons) and concepts (entertainment screens that broadcast while conducting surveillance, mini-helicopters and microphones hidden in plain sight – always collecting data, office workers who’s whole function is to “correct” the news to reflect the current truth, party practices destabilizing bonds between family members as a method of distributing policy enforcement, a government that creates tabloids, lotteries, and pornography to keep the proletariat subdued, armies that bomb their own citizens to further the image that the country is at war, politicians that expend all surplus resources as part of useless skirmishes to keep the populace hungry and angry – never really seeking to change balances-of-power between the primary competing nation-states).
Over the last year I’ve started reviewing game theory in more depth, looking for some models I can use to understand system management (vis a vis risk) better. Game theory is one of the more interesting branches of economics for me, but I don’t actually have a great intuition for it yet (I really have to work at absorbing the material). Since it doesn’t come super-naturally to me, I’m particularly proud of the presentation I gave at SOURCE Boston last year: Games We Play: Defenses and Disincentives (description here). Luckily, there is a good video of the presentation, because when I wanted to expand out the presentation a few months later, my notes were totally undecipherable. 🙂
Since I am still a proponent of applied risk analytics (as in my talk at Brucon this year: A Million Mousetraps: Using Big Data and Little Loops to Build Better Defenses (description here), I’ll never be able to escape behaviorally-driven defenses, but even with the power of big data behind us it feels like we defenders often find ourselves playing the wrong game. I don’t disagree the deck might be stacked against us, but we might be able to at least take control of the game board a little better.
Essentially — I am interested in we how might be able to adjust incentives in order to improve both risk reduction, whether from a fraud, security, or general operational dynamics perspective. Fraud reduction typically considers incentives and system design rather vaguely (not in a systematic way, except maybe in the case of authentication), and instead relies almost exclusively on behavioralist approaches (as typified by the complex predictive models launched looking for patterns in real time. I have been wondering for a while if we can “change the game” and get improved results.
Risk management at a systemic level is complicated enough that many organizations deem it practically impossible. The mistake many risk managers make is to try to identify every potential exposure in the system, every possible scenario that could lead to loss. This is how risk managers go crazy, since not even Kafka can describe every potential possibility. Risk management as a discipline does line up nicely with probability theory, but holistic approaches to risk management deviate from the sister science of insurance.
Insurance presents expected value of specific events taking place: what is the probability this car and this driver will be involved in a collision — and how much will the resulting damage cost to replace/fix? Factors include the age and quality of the car as well as the age and quality of the driver, average distance driven per day, geographic area and traffic conditions. The value of the vehicle is estimated, ranges of collision costs assumed. Flood insurance is similarly specific: what is the probability this property will sustain damage in flood conditions — and how much will it cost to protect/fix the property? Average precipitation, elevation, foundation quality, assessed property value are all factored into the decision.
As complicated as actuarial science is, insurance can be written because insurance is specific. Risk management is not specific: it is systemic.