1 Raindrop

Economic Modeling and Security

The Economist online (subscription not required in this case) has a special report on Economic Models, "We cannot live without big and ambitious economic models. But neither can we entirely trust them". This surely could apply to most IT security and risk management processes.

Economists today use computers and software not perspex and piping, but they share Phillips's itch to build models that faithfully mirror the real economy. For each of the big economic questions facing the world (What do we stand to gain from a global trade deal? By how much has expensive oil retarded growth? What might be the economic costs of an avian flu pandemic?) there is a model that will provide a big numerical answer ($520 billion, 1.5% of world GDP, and $4.4 trillion, respectively). Such figures are trotted out far and wide. But can we entirely trust them?

IT security and Risk management seek to understand the relationships between the system's threats, vulnerabilities, countermeasures and assets. Each of these areas has a set of domain specific assumptions baked into them that may reflect a) reality, b) the limitation of the data available, c) the limitations of the analyst in the space.

Economic models fall into two broad genres. Macroeconomic models, the distant descendants of Phillips's machine, belong mostly in central banks. They capture the economy's ups and downs, providing a compass for the folks with their hands on the monetary tiller. The second species, known as computable general equilibrium (CGE) models, largely ignore the vagaries of the business cycle. They concentrate instead on the underlying structure of production, shedding light on the long-term repercussions of such things as the Doha trade round, a big tax reform or climate change.

IT security and risk management has to deal with the fundamental impedance mismatch between the datasets available. Try to equate financial metrics like Annual Loss Expectancy and unpatched vulns for example. One problem in this area is hinted at above, asset-related metrics are likely to be viewed, by the business anyhow, as a macroeconomic concern. The data around countermeasures, threats, and vulnerabilities are likely to micro-focused. Both the datasets themselves and their relationships must be modeled.

Why does this matter? If you have 100 security dollars to spend, you likely want to spend them in such a way that you mitigate attacks on the most valuable assets, this requies that the macro view and the micro view work together.

Rise and Fall of CORBA

This article has some good content on what emerging technologies like SOAP may learn from past successes and failures, but it appears to be more commercially motivated than anything else. The usual suspects (complexity, bloated specs, lack of features, and Microsoft) are rounded up as conspiring to constrain CORBA's growth. Of course, the reality is that CORBA serves lots of mission critical functions today.

The lack of features section contains this:

CORBA provides quite rich functionality, but fails to provide(....):

Security. CORBA's unencrypted traffic is subject to eavesdropping and man-in-the-middle attacks, and it requires a port to be opened in the corporate firewall for each service. This conflicts with the reality of corporate security policies. (Incidentally, this shortcoming of CORBA was a major factor in the rise of SOAP. Not having to open a port in the corporate firewall and sending everything via port 80 was seen as a major advantage, despite the naïvete of that idea.) The OMG made several attempts at specifying security and firewall traversal for CORBA, but they were abandoned as a result of technical shortcomings and lack of interest from firewall vendors.

Now I am not a "let the network firewall solve all your app security problems" guy, but I am sure it will come as quite a surprise to pundits like Schneier ("SOAP is designed as firewall friendly protocol, this is like a skull friendly bullet"), et. al. that SOAP's ability to traverse firewalls is actually a boon for security. Schneier circa 2000:

That's right. Those pesky firewalls prevent applications from sending commands to each other, so SOAP lets vendors hide those commands as HTTP so the firewall won't notice.

Let's continue the DCOM example. So what if DCOM runs over a firewall?

DCOM is Microsoft's main protocol for inter-application communication. It's not just used by programs that are intended to be servers; it's used for all sorts of desktop communication and remote access. The result is that an average machine has dozens of programs using DCOM. Mine shows 48, ranging from "Microsoft PowerPoint Presentation" to "logagent" and including the catchily named "{000C101C-0000-0000-C000-000000000046}"; you may be able to list yours by bringing up a Command Prompt and typing "dcomcnfg".

Now, there are lots and lots of ways to secure DCOM applications, so maybe all of those applications are happily responding only to authenticated requests from the local machine. On the other hand, there are lots and lots of ways to make DCOM applications insecure, so maybe one of them is just waiting for somebody to send it an entirely unauthenticated request to overwrite selected files on my hard disk.

Firewalls have good reasons for blocking protocols like DCOM coming from untrusted sources. Protocols that sneak them through are not what's wanted.

SOAP was also not generally seen, at the time the ACM article refers to, as an improvement over DCOM and CORBA security, quite the opposite. So anyway, SOAP is not the death of distributed security either or even the death of firewalls, and I think WS-*, SAML, et. al. contain some valuable improvements for security but these nothing to do with firewalls, and I have not seen security as a reason for organizations moving to SOAP Web Services and away from CORBA. And in either case, the tricky bits like IAM and input validation remain.

Intro to Identity Management Risk Metrics

In this issue of the IEEE Security & Privacy Journal, I have an article on Introduction to Identity Management Risk Metrics it is in the "Build Security In" column that I co-edit with John Steven. The article looks at ways to use metrics to measure and monitor identity's distribution, quality, affiliation, and governance in the enterprise. There are specific tips for identity and security architects on how to locate and use metrics in their identity management processes and systems.

The Crystal Identity Assurance Bar

Ok, it may well be diseconomic for businesses to build systems that have enough security assurance to withstand targeted attacks from a determined, well funded foe, like say, a foreign spy service. But shouldn't our identity systems be at least strong enough to fend off meth heads?

NY Times Meth Users, Attuned to Detail, Add Another Habit: ID Theft:

Meth users — awake for days at a time and able to fixate on small details — were looking for checks or credit card numbers, then converting the stolen identities to money, drugs or ingredients to make more methamphetamine. For these drug users, Mr. Morales said, identity theft was the perfect support system.

While public concern about identity theft has largely focused on elaborate computer schemes, for law enforcement officials in Denver and other Western areas, meth users have become the everyday face of identity theft. Like crack cocaine in the 1980’s, officials say, the rise of methamphetamine has been accompanied by a specific set of crimes and skills that are shared among users and dealers....

“Anybody I knew that did meth was also doing fraud, identity theft or stealing mail,” Ms. Carroll said. “We helped each other out, whatever we needed to do that day. They all had their own little role.“

Mr. Morales, director of the Denver district attorney’s economic crime unit, said 60 percent to 70 percent of his office’s identity theft cases involved methamphetamine users or dealers, often in rings of 10 or more.

“Look at the states that have the highest rates of identity theft — Arizona, Nevada, California, Texas and Colorado,’’ Mr. Morales said. “The two things they all have in common are illegal immigration and meth.”...

In a survey of 500 county sheriffs, 27 percent said methamphetamine had contributed to a rise in identity theft in their areas. Even more — 62 percent and 68 percent, respectively — noted that it contributed to increases in domestic abuse or robberies and burglaries...

“Crack users and heroin users are so disorganized and get in these frantic binges, they’re not going to sit still and do anything in an organized way for very long,” Dr. Rawson said. “Meth users, on the other hand, that’s all they have, is time. The drug stimulates the part of the brain that perseverates on things. So you get people perseverating on things, and if you sit down at a computer terminal you can go for hours and hours.”...

Often identity theft rings organize like meth labs, where one person has the technical skills and others gather the raw materials. In an identity theft ring, one person might work the computer and the others steal identities or use the fraudulent checks or credit cards to get cash.

In Minnesota, meth laboratories and users developed a barter economy of washed checks, stolen checkbooks, drugs, ingredients and equipment, said Carol Falkowski, a spokeswoman for Hazelden, a drug treatment center in Center City.

In rural parts of Salt Lake County, Utah, meth addicts take their stolen identities onto the Internet because it has more targets than the local area, said Pat Fleming, director of county substance abuse services. “Meth is one of the major things driving identity theft in Utah,” Mr. Fleming said.

Cocaine and heroin bypassed these areas because importers took the drugs directly to Salt Lake City, where addicts commit different crimes to pay for them....

“I still see people put the little red flags up on their mailboxes when they’re mailing their bills,” she said. “It amazes me. They still put their checks in their own mailboxes, and that was one of the biggest things we did was watch for red flags on mailboxes. You’re sending your electricity bill, you have a check in there, that’s all the information we needed.”

People underestimate the resourcefulness of thieves, she said.

“Five days a week we did it,” Ms. Carroll said. “It was like a job.”

Proposed Amendment to the Laws: The identity metasystem should be resilient to attacks by meth heads. Law 2 which is of course minimal disclosure for a constrained use, is one of the main laws violated that provides the opening for the identity thieves.

One of the major problems in security today is the ability to deliver solutions that are sufficient to stop even attackers with low skill at this scale. The "its perfect or its broken" mentality that permeates so much of infosec leads to the situation we are in today with partial solutions that offer little protection to people...

SOA, Web Services, and XML Security class in Twin Cities

I will be teaching a public one day class in the Twin Cities on SOA, Web Services, and XML security. The date is 9/21/06. The training is focused on identity, messages, services, deployment, and transaction security in SOA & Web Services systems. The class is designed for people who are building SOA & Web Services and want to build security into the system from the design and development stages. The focus is on the real risks in SOA and Web Services, what security standards and protocols are there to help, how to use them, and finally where you still need to code and configure to address security issues. I also gave a version of this class at OWASP AppSec Europe and on-site for a variety of clients. The content is aimed at security practitioners, developers, and architects.

Nothing like iteration

...to improve solutions, and it sure pays to pay attention. Who is more open when it comes to identity solutions: Google or Microsoft? Who woulda thunk it? Eric Norlin:

Microsoft's Live ID *is* the old Passport — with a few key changes. Kim Cameron's work around the identity metasystem has driven the concept of InfoCards (now called CardSpace) deep inside of Microsoft. In essence, Kim's idea is that there is a "metasystem" which utilizes WS-Trust to translate tokens, so that all identity systems can interact with each other.

Of extreme importance is the fact that Windows Live ID will support WS-Trust, WS-Federation, CardSpace and ADFS (active directory federation server). This means that A) Windows Live ID can interact with other identity metasystem implementations (Open Source versions, for example); B) that your corporate active directory environment can be federated into Windows Live ID; and C) the closed system that was Passport has now effectively been transformed into an open (standards-based) and transparent system that is Live ID.

Contrast all of this with Google's announcement: create Google account, store user information at Google, get authentication from Google — are we sensing a trend? While Microsoft is now making it easy to interact with other (competing) identity systems, Google is making it nearly impossible. All of which leads one to ask - why?

I honestly believe that Microsoft is ahead of Google on this one for a very simple reason: Passport taught Microsoft some very painful, first-hand lessons. Passport forced Microsoft (over a period of years) to re-examine their fundamental approach to identity. Further, it forced them to figure out how to monetize the idea of identity applications — and not simply the aggregation of identity itself. Conversely, Google's business is now built on the aggregation of identity data, and they have yet to walk the painful Passport path.

Will the market force Google to learn the same lesson? I don't know. On the other hand, one company is clearly advancing the cause of "identity 2.0", "web 2.0", "Net 2.0" — call it what you will — and that company is Microsoft. The other company is deepening the silo and building the walled garden — and that is *so* late 90s.

This reminded me of the OWASP panel at AppSec Europe. The debate was chaired by Johan Peeters was on whether or not companies should/could adopt Microsoft's Secure Development lifecycle. What was interesting was the response was no, but not for the reason you might expect:

Microsoft Under Attack
Not by angry customers suing for damages after security breaches, or by governments breaking up monopolies, but by open source developers and security professionals accusing them of being obsessed by security. Microsoft is a company we love to hate. In particular, the security of Microsoft products has been the target of fierce criticism. However, in the last few years, Microsoft has made a concerted effort to improve the security of their products. The Windows Security Push was launched in 2002 in the run up to the release of Windows Server 2003. At that time, the seeds of the Security Development Lifecycle (SDL) were sown. This process has since been refined by many more security pushes. I had the pleasure to moderate a panel discussion "Should companies be emulating Microsoft’s Security Development Lifecycle?" on Tuesday at the OWASP Europe conference in Leuven.
...

OWASP's motivation for organizing the panel discussion was the announcement of the release of an OWASP process guide: CLASP (Comprehensive Lightweight Application Security Process) was donated by Secure Software to OWASP for distribution and further elaboration. Pravir will lead the OWASP CLASP project.

CLASP addresses the same problem space as Microsoft's SDL. Would it not have been simpler to just adopt the SDL? According to Pravir, the distinguishing feature of CLASP is the opportunity to tailor the process to the needs of the organization. SDL is seen as too heavyweight. Alex Lucas points out the irony of the SDL description fitting into a book of fewer than 300 pages, while the supposedly more lightweight CLASP requires around 600. However, Pravir stresses that the SDL is too rigorous for small organizations who may not be able to afford to work to the same exacting security standards that Microsoft is currently setting. This statement seemed to be endorsed by a significant number of the audience.

...

Alex emphasizes the importance of security awareness, and beyond awareness, openness and willingness to discuss security problems.

In closing Johan poses an interesting question:

Has Open Source lost the security edge and is it now being superseeded by the products and practices Microsoft is introducing?

Competition is good for everyone, Microsoft and other large vendors have made some major improvements over standard issue open source security. Hopefully, open source will catch up in these areas and make improvements in the security space and the industry as a whole will rev ahead again. However, are we maybe seeing an achilles heel in open source where some security stuff is not seen as plain fun enough to work on and/or interfering with features developers would rather work on? I know of several widely used open source security package maintainers who struggle to get any help to develop security features for the systems...

Pragmatic Speculation

Arctec's own Patrick Christiansen just released a paper on Pragmatic Speculation (...or, what the @#%# is a Technical Use Case?), which looks at ways to model cross cutting concerns across a number of use cases.

Metricon 1.0 Approaches

Just a couple more weeks til Metricon 1.0. The lead in is dueling keynotes/parliamentary debates:

Resolved: Metrics are too hard - Steve Bellovin, Columbia University
Resolved: Metrics are nifty - Andrew Jaquith, Yankee Group

Then I am chairing a panel on nailing jello to the wall...err...Software Security Metrics, the track currently looks this way:

"Static Analysis Tool Metrics" - Brian Chess & Katrina Tsipenyuk, Fortify Software
Software Security Patterns and Risk - Christophe Huygens
"Good enough" Metrics - Jeremy Epstein, WebMethods
Metrics for App Flaws in Client Systems - Joel Wallenstrom & Scott Stender, iSec Partners
Attack Surface Metrics - P. Manadhata & Jeannette Wing, Carnegie-Mellon

We look to have a good mix of academic and practitioner views represented. I am looking forward to the conversations. Full agenda

Practical SOA Book

"Understanding SOA with Web Services" by Eric Newcomer and Greg Lomow is one of the main books I recommend to clients on SOA and Web Services. Several parts of the book that stand out from what I have seen in the rest of the field including the section on Advanced Messaging and Transactions. The work is particularly strong in the "why are we here and how did we get here" with regard to web service evolving from various technologies like MQ, Tx systems, and mainframes, and describes where Web services has advantages and disadvantages over those technologies in a non-religious format. In Chapter 3, for example, MQ, CORBA, and XML web Services are compared across a set of criteria including: service contracts, data management, registration and discovery, security, interaction patterns, communication, and QoS. These objective analyses are some of the most valuable resources in the book, because when looking at Web Services' integration it helps the architect see where the strengthes and weaknesses lie.

The only nit is section on security is good by normal programming books standards, but more emphasis on the gaps in the standards would be useful, for example input validation, and security exceptions which are a fact of life in distributed security, but are not dealt with by standards are not covered.

This book describes what gaps SOA/Web Services address and why, where the technology is going, and what you can do about it today. Very valuable.