1 Raindrop

My Year in Cities

I liked this list, so I made my own list of cities I visited in 2008, * means more than one trip

New York, NY*

San Jose, CA*

San Francisco, CA

Chicago, IL

Woods Hole, MA

Hartford, CT

Fort Myers Beach, FL

Boston, MA

Cypress, CA

Alexandria, VA

Omaha, NE*

Anaheim, CA

Tucson, AZ

Keystone, CO

Boulder, CO

Des Moines, IA

Northampton, MA

Somerset, NJ

Cook, MN

Trying out Twitter

here 

Driving Safely on Snow

Probably the biggest problem in information security is that the people who work in information security are over focused on threats that they can do little about. So much money and resources are wasted by chasing a threat's tailights (usually aided and abetted by a vendor whose product supposedly helps you catch said taillights), a major portion of this energy and resources are better channeled into building more secure system in the first place - finding and fixing vulnerabilities. Rather than building systems that break when you look at them funny and then complaining about threats, build better stuff in the first place.

Because they have a first class threat model, the automakers have figured this out for decades, outside of Microsoft we have not seen any large scale market forces in information security that has improved security in systems, but we sure have in cars.

VOLVO’S new XC60 sport-utility vehicle comes, as you might expect of the safety-conscious Swedish carmaker, with a number of features designed to look after its occupants in the event of a collision. It has airbags, rollover and side-impact protection and so forth. But it is also fitted with mechanisms to help avoid a crash in the first place, including an automated braking system. As more cars acquire features that can assist a driver in a dangerous situation, or even take control, the rules of the road may need rethinking.

The Volvo system, called City Safety, operates at up to 30kph (19mph). This speed range was chosen because it is when most collisions take place, especially rear-end shunts in slow-moving traffic. City Safety uses a laser sensor fitted behind the windscreen to scan the road ahead, calculating relative speeds and distances. It applies the brakes if a collision cannot be avoided. (The system switches off at very low speeds, so that drivers can park close to other vehicles.)

A number of carmakers already have or are introducing automated-braking systems. Germany’s Daimler uses a radar-based one in some of its Mercedes-Benz vehicles. Called Distronic, it also operates at high speed and adjusts both braking and acceleration to maintain a constant distance from other cars. If a collision seems likely a warning is given. When the driver puts his foot on the brake pedal the system automatically applies the optimum pressure required to avoid hitting the car in front. If the driver fails to respond, the brakes come on automatically.

There are a number of great concepts in here for infosec to learn from. Managing risks begins and ends with protecting assets, i.e. passengers. Sure threats are important, but they are not the main focus. You can easily imagine if infosec people were in charge of designing safer cars they would say things like "its snowing in Minnesota!" "people drive too fast in NYC!", instead of focusing on building better brakes, air bags, and safety systems, infosec gets wound around the threat axel far too often.

Eventually these safety systems will make their way from expensive cars to most models, just as anti-lock brakes have. This will make cars much more “aware” of their surroundings. Even smarter stuff is coming. Jan Ivarsson, head of safety at Volvo, believes it should be possible to build a car in which people will not be killed or injured. The company is experimenting with devices that would automatically steer away from an oncoming vehicle. Such a car would also spot a pedestrian stepping into the road and brake.

Walking the unbelievably large vendor floor at RSA this year I experienced fear and loathing at the lame solutions being offered. The excuse used to be that no one spent money on infosec, well the infosec budgets have been growing for years now, but you know what the problem is? Its being invested in the wrong places, instead of protecting assets, the vendors throw out some vague threat model show how their half baked product supposedly deals with it and then people actually buy this stuff. Amazing. 

Whats exciting to me, is stuff that comprised less than 1% of the floor, actual security innovation like SAML, Cardspace, and static analysis. If we are ever going to get to something closer to safer cars these are tools that are going to get us there, not obsessing about threats of snow in Minneapolis.

Federated Guanxi

One of the underexplored areas in Service Oriented Security is what types of federated relationships are valuable, and what new composite identity architectures emerge from these connections. In my view, the main weakness of security architectures is their limited scope and lack of flexibility. Most software is built using composition, but most security protocols do not compose and certainly most lack the ability to deal with multiple namespaces, domains, and symmetric/asymmetric relationships, at least until WS-Security, SAML and friends came along. Further, PKI and X.509 are fine, but most the data you need to assert and make authorization decision lives deep inside a directory or database not in a key store. So we need to be able to bring together multiple elements in security architecture.

Consider the Chinese verb Guanxi:

The Chinese web is notable for a large number of mutually linking web sites. We hypothesize that this is in part a manifestation of a social construct known as guanxi, which can be widely observed in Chinese culture. Guanxi has been described as “an informal … personal connection between two individuals who are bounded by an implicit psychological contract to [maintain] a long term relationship, mutual commitment, loyalty and obligation.” Dyadic relationships are the fundamental units of guanxi networks. To establish guanxi, two parties must first establish a guanxi base: a tie between two individuals, e.g., same birthplace, same workplace, same family, close friendship. Also, two individuals can claim to have guanxi by acquaintance through a third party with whom they both have guanxi. Once a guanxi base is formed, guanxi can be developed through the exchange of resources ranging from moral support and friendship to favors and material goods.

Sure sounds like federation to me, a tie between two parties but not just a simple key exchange a la PKI, the relationship in federation is deeper, and agrees on schema, types, values, and resources (or at least resource identifiers).

56minus1 goes on to look at strong and cheap guanxi based on how nodes are linked and who they are linked to. My guess is that something like is the logical next step for SAML, CBAC and other web facing identity protocols to help service providers distinguish the guanxi and better evaluate the identity claims.

Don't Give Money to Charities This Holiday Season - Loan it to a Business

No I am not talking about bailouts, and I am obviously not suggesting that you not support your favorite charity; microfinance is a way to lend money to entrepreneurs who have good ideas, energy, initiative, and a real business, but lack capital. A relatively small amount of capital can help these businesses grow and thrive. For example, let's say you are a rice farmer in a small village in Cambodia, if you had a motorcycle you could get to the nearest big town and get a much better price for your rice. Only thing missing is the banker to cover the loan for the motorcycle. 

This is where microfinance comes in.Kiva is a site that makes it easy to be a "banker to the poor" and there is even a Team OWASP on Kiva, which has 33 loans in process, note Kiva's repayment rate on loans is over 99%, so to paraphrase Tom Barnett-  you don't have to wait for change from above, just get your own foreign policy.

Know Your Customer

iang:

I think this is why the best engineers who've done great security things start from the top; from the customer, the product, the market. They know that in order to secure something, they had better know what the something is before even attempting to add a cryptosec layer over it.

Which is to say, security cannot be a separate discipline. It can be a separate theory, a bit like statics is a theory from civil engineering, or triage is a part of medicine. You might study it in University, but you don't get a job in it; every practitioner needs some basic security. If you are a specialist in security, your job is more or less to teach it to practitioners. The alternate is to ask the practitioners to teach you about the product, which doesn't seem sensible.

I could not agree more software security are not separate:

Software development is its own culture discipline - processes, scripts, languages, and so on. Security is its own discipline and culture. As long as these remain separate disciplines, separate cultures, we'll see the same results we have seen so far - namely minimal to no security is software. On a basic level things are not going to improve until the practices, tools, and people are unified.

If I were a CISO, I would structure the security team as Security Design & Development, Secure Deployment, and Secure Operations. You are either building something, deploying something, or operating something. Security is just an implicit part of doing one of those things. I would then train and out source as many of those activities outside of the security group as possible. Train developers to write secure code, train architects to design secure systems, and so on. Arm the designers, developers, deployers, and operations with security foo and get out of the way. Study Charlemagne and Garigue for more ideas.

I think what Infosec needs to ask itself is where precisely are they adding the most value, and focus on getting better at those areas and get out of the way on the others.

Asset Focus

Several people emailed me about my talk on Finding and Fixing Vulnerabilities in Distributed Systems, basically commenting - "why do you assume you can fix all the vulns, don't you know threats are really bad, its all about threats," and so on. My answer is basically that no question - what I describe wrt finding and fixing vulnerabilities is not a complete solution. However, it is in my experience the best use of time and money to spend your time and money on the places where you have an unfair advantage. To get an unfair advantage over the attacker we need to play games that we can win.

If we look at risk management as being comprised of threats that exploit some vulnerability against some asset, there is really only one area where the defender has an information advantage - assets. The attacker knows way more about threats than defenders, the attackers know way more about most vulnerabilities as well. The one area where the enterprise security person may have the advantage of more and better information is on the asset side. Hopefully you know your assets better than the attacker does, so how do you beat Garry Kasparov and Michael Jordan? You play basketball against Kasparov and chess against Michael Jordan. I have no idea how good they are at these sports, but I bet you have a better chance at beating them if you pick the game instead of them.

The Economist on Cyberattacks

For many topics, The Economist is my favorite news source. It was really cool to see this story on cyberattacks which quoted four of my favorite security writers all in the same story - Richard Bejtlich, Bruce Schneier, John Robb and Tom Barnett. The reporter picked a good mix because Bejtlich and Schneier come from the digital perspective and Robb and Barnett are more from "physical world" perspective, but the lines are increasingly blurred as the story points out. 

Tom Barnett in particular is worth information security people's time to read because so much of the security industry obsesses about threats, but Barnett shows the importance of understanding the economics and system level concerns like resilience.

What chance do we have?

In the Twin Cities, there is not a lot of good barbecue, but there is one place that is fantastic, its called Big Daddy's barbecue (thanks Dara!) and its only open on Friday and Saturday afternoon, it operates out of a parking lot in St Paul. I try to get there as often as possible. 

We just started to get some snow in Minnesota, and I was planning an outing to Big Daddy's with a fried who is doctor, a hand specialist. So I was asking him what time would work, he said "Well, I should be able to go but I am on call."

So I said, "Well I hope no one hurts their hand on the weekend."

He said,"It just started to snow, so people go out and use their snow blowers, then the snow blowers get jammed on the vent side and the motor is still running, but no snow is blowing out the side. So they stick there hand in the vent and gets chopped by the motor. It happens all the time. They think, well I am pretty quick I can get my hand in and out of there without getting chopped"

To get more secure systems, we need people to understand the risks and then deal with the risks through reducing vulnerabilities, building better countermeasures and so on, but it all starts with some level of risk understanding. If people are willing to take these chances with snowblowers and the risk of losing hands, where does that leave us with communicating risks on something as abstract as software security?

Who do you train and how do you train them?

The Motley Fool's Dave Gardner blogged about Drucker's approach to training:

We've tried to manage our Motley Fool business the Drucker way for 15 years, too. Lemme ask you a question. I'm putting you in charge of your human resources group, in charge of your corporate culture, and you have two choices of how to spend $100,000 -- your call, here, Drucker or Anti-Drucker -- these are the two ways you can invest:

(a) a program to try to get D- employees up to a C, people who have motivational and/or social problems, toxicly bring down the teams they're on, and clearly aren't fit to be hired even by weak competitors in your field, or

(b) a program to invest in your stars -- invest in more training, outside experiences, and leadership opportunities for your best employees

In my swamp of software security training, I have trained both an organization's average developers as well as their top people. I think there is validity to both, because security is a system problem, but the approaches you use are slightly different. In the case of getting the general developer population up to speed you usually want to aim for a checklist type approach and give the developers something like a cookbook full of recipes they can follow. So you are heavier on the prescription of what to do and less about the why.

When I am training the top architects, developers, and security people, then I usually aim to give more of a security architecture framework, so they can then apply the framework depending on the specific problem context.

Developing and delivering training begins by understanding if its a raise the floor effort or a raise the ceiling effort. I think they are both very valid today, so many developers have not had one single day of software security training, and it shows all the way across the software development industry. I did a training class recently, about 15 people in the class at the beginning I asked how many people had been programming at least 5 years, all the hands went up but one. I asked how many people had ever had a single day of software security training. One hand went up. Of course, they had all had multiple week or months of training on j2EE, Weblogic, WAS, SAP, etc. but not a day on security. Software security is easily as complex as programming Weblogic. Would you turn a developer loose on your production Weblogic with no training?

A funny postscript walking out of the room there was one person who had been programming a short time, like 18 months, another had almost 20 years, by the end of the day they both had the same amount of software security training