Things are so bad in China that its gross domestic product growth rate may fall from double digits to the dowdy level of 8%. Eight percent, by the way, is a level at which the United States is unlikely to ever grow again. It can't. Our economy is simply fully developed. Thus the sobriquet "developed economy." I know, not exactly catchy.

..

All of the headlines show China sitting at a crossroads. But the reason I have faith in China is that it has historical proxies. Since 1970, with the exception of a few OPEC members, only four economies have made the transition from emerging to developed markets (meaning their per-capita incomes exceed $15,000 per year): Taiwan, Singapore, Hong Kong, and South Korea.

These four economies have two things in common. First, they have few natural resources; and second, they are dominated by Chinese values and the traditional Chinese work ethic. Mainland China is different only because it got a later start.

“When I wrote the book, I thought I was writing about the future. When it was going to press, I thought it was about current affairs. Now I wish it was about history.”

This part below reminds me a lot of 1995 security architectures used to defend 2008 integrated applications

The present crisis had been triggered because the international financial system had undertaken activities that had “far outpaced the ability of the infrastructure to sustain them”, said El-Erian.

And it was not just the markets that could not cope with their own changes, but governments as well. Significant weaknesses had been exposed “from the firms, to the regulatory agencies, to governments, to multilateral oversight”.

“Turbocharge that with financial innovations, which history tells us we tend to overproduce and overconsume, and it’s inevitable that you will get a series of market accidents,” he said.

On 13 August, jcorey asked about how to deal with those who firmly believe that the only answer to any security problem is to inspect everything at the edge. This is an important question, and I wanted to give Joe an answer. (You might have to scroll down when you click the previous link, it seems that linking to individual comments is broken.)

Today, 15 October, I wrote a little thesis as an answer to his question. I’m calling it out in a separate post because I want to make sure those of you with aggregators that don’t update when posts receive new comments still have a chance to reply with your thoughts. I’ll also repost it here:

jcorey-- You've nailed the biggest obstacle to deploying something like direct connect. Many security professionals have been taught that there simply is, and never will be, a process or technology that allows you to trust anything that originates from outside your corpnet. These professionals cling to this belief, and have been the cause that allowed the whole “detection” market to bloom.

Let me be clear: this total lack of trustworthiness is no longer absolutely true. Of course there will be times when unknown machines will be used by known and unknown people to access your information. But what about one particular subset -- known humans, with known portable computers -- can't we do something better than treat them as toxic invaders?

Indeed we can. And that's what I'm proposing with direct connect. The technology -- managed, of course, with the right processes -- exists so that you can extend the trust to known computers even though you don't trust the network they're connected to. This is because you have mechanisms that:

1. Allow you to configure the machine according to your requirements (domain join, group policy)

2. Dictate computer and user authentication requirements (IPsec policies, smart cards)

3. Limit what the users of these machines can do (UAC, non-admin, Forefront Client Security, Windows Firewall, even software restriction policies)

4. Validate the health of machines initiating incoming connections and remediate if necessary (NAP, System Center Configuration Manager)

5. Limit the threat of attacks against stolen computers (domain logon, smart cards, BitLocker with TPM)

With the robust authentication, validation, configuration, and control mechanisms available to you, I simply don't see that there's any need to fall back to “detection” now. Detection technologies were -- and remain -- necessary for the times when we have no clue about the health of client computers and when we had no way to gauge the intent of the users. But it is truly reflective of a head-in-the-sand mentality to assume that this is a complete description of what's capable today.

You know, someone once asked me what it takes to be a security professional. I answered that there are two primary elements: become a networking/packet wonk, and be willing to change your opinions when the right evidence comes along. Indeed, I suspect that many security folk have forgotten the need to keep their wonikness updated, which in turn makes them resist new ideas regardless of the strength of the evidence. I'm not very proud of what I just wrote, because I loathe generalities, but I'm not sure what else to think here. Sigh.

Joe’s question is important and strikes at the foundation of what it means to be a security professional today. I’m eager to continue this conversation, because it’s reflective of what I sense to be a radical shift in our jobs—we are, or should be, no longer the wolf-crying propeller-head who sits in the basement and twiddles with the firewall. Instead, our job should be defined as one who’s charged with protecting the organization’s information from attack, while maximizing its utility to authorized users, according to the principles of least privilege. Your thoughts?

However, I should briefly clarify Paul’s note that “blackboard systems historically used a single memory model (i.e. multiple threads or processes using a single machine’s memory model)“.

In fact, there were many blackboard systems, some more than a decade old, that used a distributed memory data-model. What I think Paul meant to say, and my apologies to Paul for being so literal, is that “blackboard systems originally used a single memory model (i.e. multiple threads or processes using a single machine’s memory model)”

John McManus, former CTO of NASA, wrote an excellent PhD dissertation in 1992, Design and Analysis Techniques for Concurrent Blackboard Systems. John’s thesis, now more than 16 years old, examined many details of concurrent blackboards where memory is distributed. For example, refer to Figure 2.3. Distributed Blackboard System with Distributed Blackboard Data Structure, page 36 of John’s dissertation.

Quoting directly from page 37 of John’s disseration;

Rice, Aiello and Nii [20] present several options for gaining speedups in a distributed blackboard system.

• 1) Eliminate the centralized scheduling mechanism
• 2) Optimize system design for a distributed memory, message-passing hardware
• 3) Distribute the data across the blackboard to reduce hotspots

Quoting further from the same page;

Poligon [21] is based on a distributed memory hardware model when each processor is viewed as a blackboard node. They define a blackboard node as follows: “a blackboard node is a process on a processor, surrounded by a collection of processors able to service its requests to execute rules.” [22] The implicit assumption in this definition is that all knowledge sources are rule–based systems. This assumption may severely limit the performance of systems implemented using Poligon, and limits the types of problems it is suited to address.

In Blackboards for Complex Event Processing, Paul concludes,

“One suspects the blackboard systems domain and terminology is overdue some updates thanks to developments in the Complex Event Processing space.”

If you look at the historical literature, I would say that the following restatement is more accurate:

“The CEP domain and terminology is overdue some updates because folks working in CEP did not reference or incorporate the advanced event processing prior art in a number of very important areas, blackboard systems being only one.”

On the other hand, commercial off-the-shelf rule-processing technology such as TIBCO’s BusinessEvents (BE), advances the ability to economically implement myriad complex problems that blackboard systems are designed to address.

You can then use the framework to assign priorities and phasing for Information Security actions. So instead of letting the random auditor and their everpresent checklist that the final four assigns you drive your program, use a framework that incorporates the business and its goals. A number of people commented on my post on GRC -

Rich Mogull

Much of what we call GRC should really be features of your ERP and accounting software. ... It’s an additional, very highly priced, reporting layer. ...A GRC tool provides almost no value at the business unit level, since it doesn’t help them get their day to day jobs done.

Mike Rothman succinctly gets to the point with a one liner I am sure will become part of my repertoire:

It's about serving the business, NOT THE AUDITORS. If you protect information effectively (which is a key imperative for the business), then the auditors should be kept reasonably happy. And if not, screw them and fight them. Yes, the auditor can make your life a bit harder, but you don't work for them. Keep that in mind.

So my GRC post seemed to tap into a fair amount of GRC blogohostility , fair enough, but the main point is not slamming GRC, just the overfocus on GRC and substituting misdirected marketecture for real world architecture Hoff got to the heart of the point of what i was saying - its about assets

As I think about it, I'm not sure GRC would be something a typical InfoSec function would purchase or use unless forced which is part of the problem. I see internal audit driving the adoption which given today's pressures (especially in public companies) would first start in establishing gaps against regulatory compliance.

If the InfoSec function is considering an approach that drives protecting the things that matter most and managing risk to an acceptable level and one that is not compliance-driven but rather built upon a business and asset-driven approach

So I submit that you should not start with a compliance checklist, but instead build a security architecture blueprint that captures your stakeholders goals. Assess this against your policy and standards, and your security architecture capabilities. Out of this comes risk management decisions. And off we go into actually building and operating something - hopefully making some profits along the way.

So build blueprints, minimize time spent doing checkbox Olympics. The blueprint I worked on is just generic framework, you may have a different one. I know that the one that I designed is in use in many organizations and in each case I know of it has been tailored to local purposes. So its a beginning not an end, but those two things are more related than you think as someone from the financial services industry once said

In my beginning is my end ... in my end is my beginning

Where you start your security architecture and design matters, and directly effects where you end up.

Anyway, the conference was a lot of fun, I rarely get to do conferences in MN. I got meet Anton Chuvakin for the first time, and went to the presentation on the local OWASP Minnesota chapter - Robert Sullivan, Joe Teff and Kuai Hinojosa did a great job doing an overview of what OWASP is all about, demoing WebGoat and so on.

In any case, this paper presents data that contradicts that thesis:

Abstract--This paper investigates the effects of mandatory seat belt laws on driver behavior and traffic fatalities. Using a unique panel data set on seat belt usage in all U.S. jurisdictions, we analyze how such laws, by influencing seat belt use, affect the incidence of traffic fatalities. Allowing for the endogeneity of seat belt usage, we find that such usage decreases overall traffic fatalities. The magnitude of this effect, however, is significantly smaller than the estimate used by the National Highway Traffic Safety Administration. In addition, we do not find significant support for the compensating-behavior theory, which suggests that seat belt use also has an indirect adverse effect on fatalities by encouraging careless driving. Finally, we identify factors, especially the type of enforcement used, that make seat belt laws more effective in increasing seat belt usage.

In fact, I found the article to be rather upsetting. Not because of the article’s thesis that strong authentication through a national ID program would not necessarily pose a threat to privacy; but rather, because of their naive (and irresponsible) handling of the realities of the biometric authentication challenge. They gloss over the real security challenges with creating a national biometric infrastructure. Here are the two quotes that are most misleading:

• “Confusing privacy with anonymity has delayed implementation of robust, virtually tamper-proof biometric authentication to replace paper-based forms of ID that neither assure privacy nor reliably prove identity.”
• “This emerging technology makes it virtually impossible to assume someone else’s unique identity.”

The problem that the authors are glossing over is that no such technology exists today, and it is unlikely to ever exist. Now, to be fair, I am assuming that a critical success factor for any national biometric program, as described, would be that the authentication devices have to be available, and usable, anyplace paper-based IDs can be used today. This of course implies that the authenticator must be an inexpensive, commodity device, easy to purchase, maintain, and operate. Such a device would have to be even more ubiquitous than the electronic credit card machine.

The problem is that the authenticator itself may be in the possession of the attacker (Perhaps after you authenticate your legitimate purchase the clerk desires to use your identity herself…). In the history of security controls, when the attacker has unsupervised at-will physical access, the attacker wins. Here are a few examples:

• Defeated copy protection on DVDs ( more & more info)
• Cold Boot Crypto Attack on hard disk encryption (more info)
• MiFare RFID Cards (more info)
• Skimming devices attached to ATM machines to steal card and PIN data (more info)

Of course, all of these systems worked in the lab. But when a security system is widely deployed, it has to withstand an enormous amount of scrutiny, and minor flaws will be exploited. And of course, the greater the financial gain, the greater the time and energy attackers invest in trying to defeat the system. The authors of the article ignore these issues, idealistically assuming biometrics will just work.

Now, of course there are lots of examples where biometrics work very effectively. But I would propose that biometric authentication is most useful when the authentication device is physically secure and the authentication itself is supervised. The MiFare example above also demonstrates two other issues:

• The system chose not to implement a reviewed and standard cryptographic algorithm - always a bad idea
• MiFare was able to sell 1 billion cards and authenticators before the system failed

The cost of investing in a national biometric authentication program, and then having the security fail, is enormous. Can you imagine deploying a biometric authentication infrastructure to every bank, police car, restaurant, shop, etc. and then having video on YouTube of it being defeated ?

- Erik

BTW, Maybe the attacker doesn’t even need to tamper with the device -> ftp://ftp.ccc.de/pub/video/Fingerabdruck_Hack/fingerabdruck.mpg

Art of Information Security would love your feedback !

What do the Cold Boot Crypto Attack, DVD Players, and MiFare tell us about the Future of Biometrics?