Emergent Chaos

Supreme Court Narrows "Money Laundering"

The Supreme Court narrowed the application of the federal money-laundering statute on Monday, ruling for criminal defendants in two cases in which prosecutors had employed broad definitions of two of the law’s major provisions.

The two rulings are likely to crimp the government’s ability to bring money-laundering cases, although not necessarily to the degree that an initial reading of either might suggest. ("Justices Narrow Money-Laundering Law," New York Times.)

The money laundering laws are a great example of bad law, and I'm glad to see them narrowed. They're bad law because they include tremendous prosecutorial discretion, because they're exceptionally expensive to enforce, and they infringe on the privacy and liberty of normal people.

Recently, I talked about "The Costs of Security and Algorithms" and the link between these silly laws and a how banks had shifted their risk-management dollars from looking for bad loans to looking for money launderers. Sometimes this goes to a ridiculous extent.

When I was moving to Montreal, I didn't have enough ID to purchase a Canadian dollar cashiers check to reserve my apartment and satisfy Bank of Boston's AML regulations. The check was for some nominal sum, like $1000. Fortunately, Zero-Knowledge was willing to loan me the money, and cut my landlord a cheque that day.

I'm glad they've narrowed the law, and I hope this will be the first of many chips that bring down the edifice.

The Costs of Security and Algorithms

I was struck by this quote in the Economist special report on international banking:

There were navigational aids to help investors but they often gave false comfort. FICO scores, the most widely used credit score in America, were designed to assess the creditworthiness of individual borrowers, not the quality of pools of mortgages. “'Know your customer' is a staple of banking that has largely been forgotten because of the disaggregation of the supply chain,” says Mark Greene, the chief executive of Fair Isaac, the company behind FICO scores. ("Ruptured credit)

"Know your customer" actually hasn't been forgotten, it's been co-opted. It's been co-opted by the "AML" (Anti-Money Laundering) crowd. (The Google search is also fascinating. Look at all those ads!) But "know your customer" has been co-opted by the surveillance state. The people who want to know where your money is going in case they need to investigate you.

Bruce Schneier has a 5 step process for evaluating security:

1. What problem does it solve?
2. How well does it solve the problem?
3. What new problems does it add?
4. What are the economic and social costs?
5. Given the above, is it worth the costs?

To be clear, the whole idea of AML doesn't pass this test. But let's set that aside, and test the re-definition of knowing your customer. We can then look at step 2 and 3, and ask "is re-defining a known element of good advice worthwhile?" I don't think it is. I think it's an example of how we let process and algorithms replace clear thinking.

It used to be that part of getting a mortgage was talking to a banker. You talked to an officer of the bank who was going to be collecting money from you for twenty years. And he made a call. That's been replaced by the FICO algorithms and checking your ID. There's now a process and an audit trail. And there's no common sense. There's no senior person who can see trends. To be fair, with common sense, it's become harder to impose racist lending standards. That senior person can't imagine trends.

Back to the topic at hand, we've moved from "know your customer" as sage advice to trite bits of checklist faux diligence. We've lost something important.

Really, what we've done is substituted a knowing a person with a knowing their data shadow. That's not the only problem, but it's one of a set of synergistic changes that will cost us hundreds of billions to clean up.

(Data shadows is a great term, defined by Alan Westin. Bruce Schneier used it recently in his excellent essay "Our Data, Ourselves," which I hope to shadow shortly.)

Image: "Sinister," by Adactio.

HSPD-12 Does Not Require JPL Background Checks

Adam writes about the brouhaha at NASA over HSPD-12 background checks.

A friend of a friend who is in the business of implementing HSPD-12 sent me a tidbit about it, along with a link so that you can read the primary source — something always needed when you get emails from FOAFs.

In paragraph 3, there is the interesting statement:

The Standard will include graduated criteria, from least secure to most secure, to ensure flexibility in selecting the appropriate level of security for each application.

The FOAF was incredulous at the report, because there it is in paragraph three that it's okay to have different levels of security, and that which was good enough to defend us against the Godless Commies oughta be good enough to defend us against the Godful Beard-Dyers.

Let's look down a little further. HSPD-12 is short, it's only eight paragraphs. What's that in paragraph 6?

(6) This directive shall be implemented in a manner consistent with the Constitution and applicable laws, including the Privacy Act (5 U.S.C. 552a) and other statutes protecting the rights of Americans.

Which gives the protesters a lot of ammo right there. But wait, there's more. The HSPD-12 FOAFs say that the hardware JPL has ordered can only support a low-security ID system anyway, not a high-security one, so even if it were reasonable, they can't implement the high-value security checks anyway. The FOAF gives this site as a reference.

So there you have it, not only abuse at JPL, but waste, too.

Wretched Term of the Week: Best Practice

This is a peeve I learned from the great Donn Parker. The term "Best Practice" should be avoided. It is inaccurate. misleading, and self-defeating. Here's why:

1. Best is a superlative. By using it, one implies that there a single choice that surpasses all others. Rarely is this the case in real life. Security gurus are known for asking probing questions like "What's your threat model?" or "What goal do you wish to achieve?" Different goals yield different practices.

   Shortly after 9/11, some physical security people I know put some physical security plans in place that many people, including me, sneered at. Harumph, harumph, it doesn't actually improve security. It's there just to look like you're doing something. Some time later, one of them took me quietly aside and told me that the reason they did it was to lower insurance costs. If you're faced with your insurance bills going up by a million bucks and you can avert that with fifty grand of security theatre, out comes the greasepaint and tap shoes followed shortly by an amateur production of songs from Chicago.

2. Something that is best doesn't actually have to be good. If you're faced with having to choose between a number of bad alternatives, you still look for the best. But best implies good. Admittedly, using best allows you to weasel out of the fact that the decision sucks. In such a dilemma, least bad is better than best because it's honest.
3. A superlative implies that it cannot be surpassed. That makes it hard to replace a best practice with one even better. Smart people know that best is always within context and often the life of it being superlative is shorter than the implementation time. But that word works in favor of the clichpoop with the budget. Why set yourself up be on the defensive?

What do you say, then? Parker recommended "Good Practices," but noted that many best practices need improvement before they can get to good. This the problem -- we're always having to do things that may not be quite so good. Grading on the curve is an old technique, and the same budget holder who will question improving a best practice may not appreciate honesty. Some organizations use "Best Current Practices" which manages to keep from tacitly chiseling them in stone, but still keeps the superlative, and I believe that the superlative is a problem. I think I can count practices that are truly best on one hand once they get more complex than, "look both ways before crossing the street" or "cook the popcorn for only two minutes."

I recently heard Stephen R. Katz, another pioneer of computer security -- the world's first CISO, mention the same peeve and suggest the term "Standard Acceptable Practice." The great thing about a term like "Standard Acceptable Practice" is that no one is going to disagree with either, "We have to get this organization to follow Standard Acceptable Practices," or "We need to improve our Standard Acceptable Practices." Photo by andai.

U.S. versus E.U. Audits

Speaking of the differences between how security gets managed in the U.S. versus the E.U., CSO magazine has a light-hearted and somewhat irreverent article on the differing goals and priorities of audits on either side of the Atlantic. In spite of its tone, it does highlight some important issues to keep in mind. In particular:

But it also illustrated a fundamental difference in the way audits are conducted on both continents. In the United States, audits are about ensuring that sufficient controls are in place to mitigate risks. Thus, the audit findings tend to emphasize lapses in application and network security. In Europe, audits tend to focus on following a predefined process, being transparent in the actions taken, precisely defining policies and procedures, and adhering to international standards.

I'd love to see a much deeper analysis of managing compliance in the U.S. versus the E.U. from someone who has a lot experience working in both domains. Does this already exist? Or are folks interested in collaborating on writing something like this?