1 Raindrop

MetriCon 3.0

Along with OWASP's AppSec conferences, MetriCon is at the top of my list of conferences. MetriCon brings together people with varied background and a common interest in making security more objective and measurable. This year's conference chair is Dan Geer and the agenda and speakers looks like the best yet. MetriCon 3.0 is July 29 in San Jose, along with the Usenix Security conference.

Upcoming Talks and Training

Here is my current list of talks and training

• "Breaking Web Services," Monday July 7: OWASP Twin Cities  - "SOA and Web services promise wonderful interoperability, but distributed systems create lots of room for fantastic failures. This session will explore the gory details of unique vulnerabilities at each layer of the SOA stack - from the WSDL interfaces to XML processing (XSD, XPath and XQuery), to the implementation languages liike Java and C#, to new security standards like WS-Security and SAML.

  I gave a version of  this talk with Brian Chess at the 2008 RSA Conference.

•  "Web Services and SSO: There and Back Again" at Ping's SSO Summit. July 25, Keystone, CO - "What happens to your identity information and business data after you press "SUBMIT" on a website? These bits have a journey as dangerous as Frodo Baggins' travels through Mordor. This talk traces the path from the website through the perils that lurk in the enterprise and legacy systems. We will explore what threats are encountered along the way, and how to design a cost effective security architecture with Security Token Servers using open standards."   
•  "SOA, web services, and XML Security" 1 day training at Usenix Security July 29. This is a public 1 day version of my training see the link for details
• Security for Web Services and SOA - SANS Webcast, July 31 

Can you hear me now?

Verizon released a very interesting Data Breach report that analyzes over 500 forensic reports on their system over a number of years. It is great work by Verizon to gather this data and to publish it. Of course a consultant I go into lots of companies where they could learn a lot just by being more open and talking through issues with peers in other companies. Would be great to see other companies follow Verizon's lead.

I suggest you read their report, and I would like to add a little color to their findings from the perspective of the swamp I spend most of my time in - Web services security. Granted it is just one report, but the data run counter to a lot of conventional security "wisdom":

Who is behind data breaches? 

73% resulted from external sources
18% were caused by insiders 
39% implicated business partners 
30% involved multiple parties

The internal/external divide is pretty silly these days, as is companies' recanting "inside the firewall and outside the firewall", I spend most of time hooking things up together precisely _so_ they intereoperate remotely. The firewall is a speed bump at best. At any rate external sources is a primary concern in Web services security, because - hey look our Web service front end just made your Mainframe/As400/Unix DB/ CICS/whatever accessible remotely. This is great from a functionality standpoint, but the issue is that these back end systems were never designed with anything remotely resembling an Internet threat model. Additionally, the Verizon team's findings around business parties and multiple parties strikes at the heart of a number of popular misconceptions in Web services security - "well its just B2B and its behind a firewall."

How do breaches occur? 

62% were attributed to a significant error

59% resulted from hacking and intrusions  

31% incorporated malicious code 

22% exploited a vulnerability 
15% were due to physical threats 

A couple of things to note here - malicious code in my opinion is likely to be the biggest problem in Web services security going forward. There is a large gap waiting to be exploited here. You have no control over the other end of the pipe plus a massive attack surface, the only thing lacking is the attacker's ability to find and exploit which I strongly suspect is just a matter of time. Wrt hacking an intrusions we have the remote, passive nature of web security to blame here in Web services world. Paraphrasing Jeff Williams, the problem is that an attacker can just try an attack if it doesn't work, try again, again, and so on. This partially because of the loosely coupled nature of the systems, but it is also because commonly used information security protocols have diverged from reality are modeled using an object-centric mentality, where you "own" the object you are protecting and can afford to put passive controls around.

What commonalities exist? 

66%  involved data the victim did not know was on the system
75%  of breaches were not discovered by the victim  
83%  of attacks were not highly difficult 
85%  of breaches were the result of opportunistic attacks 
87%  were considered avoidable through reasonable controls 

Many of the attacks against Web Services are not difficult, in my training class, we'll typically execute 8-10 different attacks in a two day period. But the big one from this list is the first one - the amazing amount of attack surface offered up by Web services. Brad Hill has done a good job articulating these issues in SOAP/XML/WS-*, but at an enterprise its even bigger than those standards - the thing is we use Web services to make stuff interoperate, to make stuff reusable, and to virtualize endpoints. Great stuff if what you want to do is decentralize your business, but this creates oceans of space for attackers to roam. When you look beyond the Visio and the IDE view of web services, and get to the runtime there is an amazing amount of detritus left behind by all these layers.

Mission Statement for Federation

Bruce Sterling (11/20/2001):

You know what I want? I don't want a National ID Card. I want a Global Coalition Visa.

Like it or not, we've got a huge global diaspora now. It is a fact of life. Nations with stupid and corrupt politics have seen their clever people brain- drained away, to places where the cops don't shake you down twice a day. And jet-setters go everywhere. And properly so. If you're in a true global society, then you spend a lot of your time among aliens. Quite often you are the alien. You might notice that even Al Qaeda is a genuinely multinational group. They gravitated to wicked, lawless places like Sudan, Chechnya and Afghanistan, where the locals shoot you if you ask for a badge.

But what about all us bright, shiny, world-trading jet setters, huh? There are thirty percent fewer Yankees in Europe this Christmas, and that is bad. Let me pose the problem this way. If I am going into a Japanese restaurant in Japan, I would rather like to be able to haul out some gizmo and flash it at my fellow civilians, and have these kindly people understand with a high degree of likelihood that I am not a mass murderer. On the contrary, I am quite civilized, and I should be brought a beer immediately.

A platinum VISA card and a five-hundred-dollar suit will almost do that, but those are too easy to forge and steal, plus they are not very democratic. The UN should get together on this. We should have a high level summit about digital hardware support for the crippled tourist economy. Fear and ill treatment shut down tourism faster than anything short of open warfare. That is bad for all of us. Killing off tourism harms our civilization and impoverishes our cultures. People in civilized states shouldn't routinely treat one another as criminal suspects. I don't want to get done-over for three hours every time I get off a plane in London. When I go to London, I go with empty suitcases. I don't plan to stay, but I am better news for the London economy than a lot of the people who live there.

They should know all that that before I get off the plane. My arrival is excellent news for Britain, so I should be treated that way. If this is a new kind of war, I don't want to be the evil guy hunkered down in the bunker; I want to fly with the boys from Air Assault. I want one of those handy crypto-style Friend-or-Foe IDs.

These people who normally meet me whenever I am an alien, they don't need to know my nationality, my home address or my shoe size. They just need to know that, despite being alien, I'm sort-of okay.

I want a democratic, citizen-to-citizen device that will bridge those social barriers and language barriers. I think we could invent devices and means of verification that would strengthen the global social fabric that terrorism wants to rip. It wouldn't be easy or simple, but it's not beyond our ingenuity. Our social capital sustains all civilized societies, and it is all about trust. So let's invent new methods of trust.

I added bold to the last sentence because I think this is the mission statement for building out federation systems.

Mashup of the Titans

Information Security - an Oxymoron for the information age

“Always the beautiful answer who asks a more beautiful question.” e. e. cummings

...or why i am with Gelernter

This is a mashup of Saltzer & Schroeder's famous information security principles with David Gelernter's Manifesto.

The premise of this mashup is to examine the paper by Saltzer and Schroeder which was written in 1975 and serves as the basis for most information security programs against the Gelernter's manifesto as to where computing is actually going. Each of the eight principles in Saltzer and Schroeder's paper is listed in order, and followed by select excerpts of Gelernter's manifesto. This comparison is to examine theoretical information security principles vis a vis the actual utility of modern information systems. I will not make an attempt to reconcile theory and practice, but will point out where the two schools of thought agree. In fairness, Saltzer and Schroeder's paper was written 25 years before Gelernter's, however Saltzer and Schroeder's principles dominate the thinking about information security to this day and so its important to view them side by side with Gelernter's thinking on the direction of computing.

Saltzer and Schroeder:

"a) Economy of mechanism: Keep the design as simple and small as possible. This well-known principle applies to any aspect of a system, but it deserves emphasis for protection mechanisms for this reason: design and implementation errors that result in unwanted access paths will not be noticed during normal use (since normal use usually does not include attempts to exercise improper access paths). As a result, techniques such as line-by-line inspection of software and physical examination of hardware that implements protection mechanisms are necessary. For such techniques to be successful, a small and simple design is essential."

Gelernter:

"9. The computing future is based on "cyberbodies" — self-contained, neatly-ordered, beautifully-laid-out collections of information, like immaculate giant gardens."

Conclusion(gp): So far, so good

**

Saltzer and Schroeder:

"b) Fail-safe defaults: Base access decisions on permission rather than exclusion. This principle, suggested by E. Glaser in 1965,8 means that the default situation is lack of access, and the protection scheme identifies conditions under which access is permitted. The alternative, in which mechanisms attempt to identify conditions under which access should be refused, presents the wrong psychological base for secure system design. A conservative design must be based on arguments why objects should be accessible, rather than why they should not. In a large system some objects will be inadequately considered, so a default of lack of permission is safer. A design or implementation mistake in a mechanism that gives explicit permission tends to fail by refusing permission, a safe situation, since it will be quickly detected. On the other hand, a design or implementation mistake in a mechanism that explicitly excludes access tends to fail by allowing access, a failure which may go unnoticed in normal use. This principle applies both to the outward appearance of the protection mechanism and to its underlying implementation."

Conclusion(gp): A conservative design principle that puts the object's owner in control of permissions. This makes a lot of sense from the object point of view, but does little to address the use case in which it executes.

**

Saltzer and Schroeder:

"c) Complete mediation: Every access to every object must be checked for authority. This principle, when systematically applied, is the primary underpinning of the protection system. It forces a system-wide view of access control, which in addition to normal operation includes initialization, recovery, shutdown, and maintenance. It implies that a foolproof method of identifying the source of every request must be devised. It also requires that proposals to gain performance by remembering the result of an authority check be examined skeptically. If a change in authority occurs, such remembered results must be systematically updated."

Gelernter:

"8. The software systems we depend on most today are operating systems (Unix, the Macintosh OS, Windows et. al.) and browsers (Internet Explorer, Netscape Communicator...). Operating systems are connectors that fasten users to computers; they attach to the computer at one end, the user at the other. Browsers fasten users to remote computers, to "servers" on the internet.

Today's operating systems and browsers are obsolete because people no longer want to be connected to computers — near ones OR remote ones. (They probably never did). They want to be connected to information. In the future, people are connected to cyberbodies; cyberbodies drift in the computational cosmos — also known as the Swarm, the Cybersphere.

13. Any well-designed next-generation electronic gadget will come with a ``Disable Omniscience'' button.

17. A cyberbody can be replicated or distributed over many computers; can inhabit many computers at the same time. If the Cybersphere's computers are tiles in a paved courtyard, a cyberbody is a cloud's drifting shadow covering many tiles simultaneously.

20. If a million people use a Web site simultaneously, doesn't that mean that we must have a heavy-duty remote server to keep them all happy? No; we could move the site onto a million desktops and use the internet for coordination. The "site" is like a military unit in the field, the general moving with his troops (or like a hockey team in constant swarming motion). (We used essentially this technique to build the first tuple space implementations. They seemed to depend on a shared server, but the server was an illusion; there was no server, just a swarm of clients.) Could Amazon.com be an itinerant horde instead of a fixed Central Command Post? Yes."

Conclusion(gp): Complete mediation provides the underpinning for Saltzer and Schroeder's system, but does not appear to scale to the desired itinerant horde at least in common interpretation.

**

Saltzer and Schroeder:

"d) Open design: The design should not be secret. The mechanisms should not depend on the ignorance of potential attackers, but rather on the possession of specific, more easily protected, keys or passwords. This decoupling of protection mechanisms from protection keys permits the mechanisms to be examined by many reviewers without concern that the review may itself compromise the safeguards. In addition, any skeptical user may be allowed to convince himself that the system he is about to use is adequate for his purpose. Finally, it is simply not realistic to attempt to maintain secrecy for any system which receives wide distribution."

Conclusion(gp): both seem to agree, hard to get the itinerant horde moving in a swarm without open standards.

**

Saltzer and Schroeder:

"e) Separation of privilege: Where feasible, a protection mechanism that requires two keys to unlock it is more robust and flexible than one that allows access to the presenter of only a single key. The relevance of this observation to computer systems was pointed out by R. Needham in 1973. The reason is that, once the mechanism is locked, the two keys can be physically separated and distinct programs, organizations, or individuals made responsible for them. From then on, no single accident, deception, or breach of trust is sufficient to compromise the protected information. This principle is often used in bank safe-deposit boxes. It is also at work in the defense system that fires a nuclear weapon only if two different people both give the correct command. In a computer system, separated keys apply to any situation in which two or more conditions must be met before access should be permitted. For example, systems providing user-extendible protected data types usually depend on separation of privilege for their implementation."

Gelernter:

"37. Elements stored in a mind do not have names and are not organized into folders; are retrieved not by name or folder but by contents. (Hear a voice, think of a face: you've retrieved a memory that contains the voice as one component.) You can see everything in your memory from the standpoint of past, present and future. Using a file cabinet, you classify information when you put it in; minds classify information when it is taken out. (Yesterday afternoon at four you stood with Natasha on Fifth Avenue in the rain — as you might recall when you are thinking about "Fifth Avenue," "rain," "Natasha" or many other things. But you attached no such labels to the memory when you acquired it. The classification happened retrospectively.)"

Conclusion(gp): Information Security models tend to look at things statically through information classification lenses, but its how information is used that makes it valuable. In practice this is how information security theory breaks down in the face of reality - what does an access control matrix look like for a mashup? What does it look like for a data mining app?

**

Saltzer and Schroeder:

"f) Least privilege: Every program and every user of the system should operate using the least set of privileges necessary to complete the job. Primarily, this principle limits the damage that can result from an accident or error. It also reduces the number of potential interactions among privileged programs to the minimum for correct operation, so that unintentional, unwanted, or improper uses of privilege are less likely to occur. Thus, if a question arises related to misuse of a privilege, the number of programs that must be audited is minimized. Put another way, if a mechanism can provide "firewalls," the principle of least privilege provides a rationale for where to install the firewalls. The military security rule of "need-to-know" is an example of this principle."

Gelernter:

"28. Metaphors have a profound effect on computing: the file-cabinet metaphor traps us in a "passive" instead of "active" view of information management that is fundamentally wrong for computers.

29. The rigid file and directory system you are stuck with on your Mac or PC was designed by programmers for programmers — and is still a good system for programmers. It is no good for non-programmers. It never was, and was never intended to be.

30. If you have three pet dogs, give them names. If you have 10,000 head of cattle, don't bother. Nowadays the idea of giving a name to every file on your computer is ridiculous."

Conclusion(gp): Least Privilege is the point where the practical matter of applying Saltzer and Schroeder's principles breaks down in modern systems. Its a deployment issue, and a matter of insufficient models and modes.

**

Saltzer and Schroeder:

"g) Least common mechanism: Minimize the amount of mechanism common to more than one user and depended on by all users [28]. Every shared mechanism (especially one involving shared variables) represents a potential information path between users and must be designed with great care to be sure it does not unintentionally compromise security. Further, any mechanism serving all users must be certified to the satisfaction of every user, a job presumably harder than satisfying only one or a few users. For example, given the choice of implementing a new function as a supervisor procedure shared by all users or as a library procedure that can be handled as though it were the user's own, choose the latter course. Then, if one or a few users are not satisfied with the level of certification of the function, they can provide a substitute or not use it at all. Either way, they can avoid being harmed by a mistake in it."

Gelernter:

"6. Miniaturization was the big theme in the first age of computers: rising power, falling prices, computers for everybody. Theme of the Second Age now approaching: computing transcends computers. Information travels through a sea of anonymous, interchangeable computers like a breeze through tall grass. A dekstop computer is a scooped-out hole in the beach where information from the Cybersphere wells up like seawater.

16. The future is dense with computers. They will hang around everywhere in lush growths like Spanish moss. They will swarm like locusts. But a swarm is not merely a big crowd. The individuals in the swarm lose their identities. The computers that make up this global swarm will blend together into the seamless substance of the Cybersphere. Within the swarm, individual computers will be as anonymous as molecules of air.

55. Software can solve hard problems in two ways: by algorithm or by making connections — by delivering the problem to exactly the right human problem-solver. The second technique is just as powerful as the first, but so far we have ignored it.

56. Lifestreams and microcosms are the two most important cyberbody types; they relate to each other as a single musical line relates to a single chord. The stream is a "moment in space," the microcosm a moment in time."

**

Saltzer and Schroeder:

"h) Psychological acceptability: It is essential that the human interface be designed for ease of use, so that users routinely and automatically apply the protection mechanisms correctly. Also, to the extent that the user's mental image of his protection goals matches the mechanisms he must use, mistakes will be minimized. If he must translate his image of his protection needs into a radically different specification language, he will make errors."

Gelernter:

"7. "The network is the computer" — yes; but we're less interested in computers all the time. The real topic in astronomy is the cosmos, not telescopes. The real topic in computing is the Cybersphere and the cyberstructures in it, not the computers we use as telescopes and tuners.

27. Modern computing is based on an analogy between computers and file cabinets that is fundamentally wrong and affects nearly every move we make. (We store "files" on disks, write "records," organize files into "folders" — file-cabinet language.) Computers are fundamentally unlike file cabinets because they can take action.

31. Our standard policy on file names has far-reaching consequences: doesn't merely force us to make up names where no name is called for; also imposes strong limits on our handling of an important class of documents — ones that arrive from the outside world. A newly-arrived email message (for example) can't stand on its own as a separate document — can't show up alongside other files in searches, sit by itself on the desktop, be opened or printed independently; it has no name, so it must be buried on arrival inside some existing file (the mail file) that does have a name. The same holds for incoming photos and faxes, Web bookmarks, scanned images...

32. You shouldn't have to put files in directories. The directories should reach out and take them. If a file belongs in six directories, all six should reach out and grab it automatically, simultaneously.

33. A file should be allowed to have no name, one name or many names. Many files should be allowed to share one name. A file should be allowed to be in no directory, one directory, or many directories. Many files should be allowed to share one directory. Of these eight possibilities, only three are legal and the other five are banned — for no good reason.

53. Your car, your school, your company and yourself are all one-track vehicles moving forward through time, and they will each leave a stream-shaped cyberbody (like an aircraft's contrail) behind them as they go. These vapor-trails of crystallized experience will represent our first concrete answer to a hard question: what is a company, a university, any sort of ongoing organization or institution, if its staff and customers and owners can all change, its buildings be bulldozed, its site relocated — what's left? What is it? The answer: a lifestream in cyberspace."

**

Conclusion(gp):

The Saltzer and Schroeder principles of Open Design and Economy of Mechanism hold up well in the face of modern computing realities, and to a certain extent Fail Safe Defaults does as well; however if we information security people are to be effective we need to re-think the other principles.

**

Last word: Gelernter:

We'll know the system is working when a butterfly wanders into the in-box and (a few wingbeats later) flutters out — and in that brief interval the system has transcribed the creature's appearance and analyzed its way of moving, and the real butterfly leaves a shadow-butterfly behind. Some time soon afterward you'll be examining some tedious electronic document and a cyber-butterfly will appear at the bottom left corner of your screen (maybe a Hamearis lucina) and pause there, briefly hiding the text (and showing its neatly-folded rusty-chocolate wings like Victorian paisley, with orange eyespots) — and moments later will have crossed the screen and be gone.

Security Services Deployment in Federated World

Its easy to get hung up on security protocol design, finding the right fit for your architecture and so on. Its really hard to find security mechanisms that do something useful and scale as well. In my opinion, this is the single biggest issue we face in security today - how do find useful things that solve security problems, that can scale in real world systems.

To that end, my favorite paper in a long time was written by Patrick Harding, Leif Johansson, and Nate Klingenstein called "Dynamic Security Assertion Markup Language: Simplifying Single Sign-On." They begin by asking questions companies face when entering into a federation:

How should trust between providers be managed? 

How should information about providers (metadata) be provisioned? 

Which SAML profiles and bindings should be used? 

Which messages and what part of each message should be signed? 

Which identifiers and attributes should be exchanged? 

What are the semantics of those attributes and identifiers?

Organizations understand the benefits of SSO and federation, but don't always answer the above questions in a way that sets them to scale. Harding, et al.'s work describes a way to partition the architecture into separate layers - a metadata trust fabric,a metadata publishing fabric, and a metadata validation and signing fabric - enabling dynamic federation. If you design stuff for a large scale distributed systems, this is a really big deal. No wonder these guys win all the good awards. 

I have often used Federation as an example of security as a business enabler - improving the brakes, ABS, and airbags so we can drive fast and safe. Federation creates value for the business through more deeply linking it with its customers, partners, and business users; it solves some security architecture problems through encrypted and signed tokens; and it gives the user SSO/SLO. You don't always get a win like this in security architecture, but when you find one its good to ride it for all its worth.

Silver Bullet Security Podcast

I did a podcast with Gary McGraw which is available here. Gary's questions were great, I could have written a ten page whitepaper in response to most of them, but tried to sum up my thoughts on "what is security", and how you might approach security in SOA, Web 2.0, and federation spaces. Gary is always interesting to talk to since he has done a major percentage of the valuable work in security.

One point I raised in the podcast is that I see a common misconception in the industry which I sum up as the "what got you here won't get you there" problem. We have had a long hard slog getting support for software security, and now, thanks to Gary's and others' work, its finally starting to take root. It is taking root especially in financial services. One thing I see though is that vendors commonly make a big sale or three in a financial services player, then they go to an insurance company, a manufacturer, or other large player and say "hey do what Ginormous globobank is doing." Problem is - their business models are different, their IT is different, and so on. We have done a decent job bootstrapping some security practices in financial services, but we need other models for other verticals.

MetriCon 3.0

MetriCon 3.0 — Third Workshop on Security Metrics 

Tuesday,29 July 2008, San Jose, California 

___________________________________________________________________ 

8:45am:Welcome words / housekeeping details - Dan Geer 

___________________________________________________________________ 

9:00am-10:30am - Models proposed and derived 

•Thomas Heyman & Christophe Huygens : "Using Model Checkers to Elicit Security 

Metrics" 

•Adam O’Donnell : "Games, Metrics, and Emergent Threats" 

•Fred Cohen : "Bringing Clarity to Security Decision Making Using Qualitative 

Metrics in 2 Dimensions" 

Discussants:Lloyd Ellam & Elizabeth Nichols 

___________________________________________________________________ 

10:45am-12:15pm - Tools and their application 

•Yolanta Beresnevichiene : "Metrics Driving Security Analytics" 

•Alain Mayer : "Security Risk Metrics: The View From the Trenches" 

•Amrit Williams : "How to Define and Implement Operationally Actionable Security 

Metrics" 

Discussants:Gunnar Peterson & Andrew Jaquith 

___________________________________________________________________ 

12:15pm-1:30pm - In-room lunch, the final 30 minutes jointly from 

•Jennifer Bayuk : "Comparing Metrics Designed for Risk-Management with Metrics 

Designed for Security" 

Discussant:Bryan Ware 

___________________________________________________________________ 

1:30pm-3:00pm - Scoring results and methods 

•James Walden : "Code Complexity and Static Analysis" 

•Karen Scarfone : "Evidence-Based, Good Enough, & Open" 

•Arshad Noor : "Identity Protection Factor" 

Discussants:Fred Cohen & Dan Conway 

___________________________________________________________________ 

3:15pm-4:45pm Enterprise plans and lessons learned 

•Caroline Wong : "eBay’sMetrics Program" 

•Clint Kreitner : "CIS’ Metrics Program" 

•Kevin Peuhkurinen : "Great-West’s Metrics Program" 

Discussants:Christine Whalley&Dan Geer 

___________________________________________________________________ 

5:00pm-5:45pm - Perimeters are the simplest possible thing to measure, right? 

•Sandeep Bhatt : "Metrics-Based Firewall Management" 

•Avishai Wool : "Firewall Configuration Errors Revisited" 

Discussant:Bob Blakley 

___________________________________________________________________ 

5:45pm-whenever:Minimalist closing remarks - Dan Geer 

Drinks & dinner in room, and whatever happens next — which it is hoped includes  lessons learned, volunteers for further episodes of MetriCon, ideas on how we can best further support ourselves jointly,etc. Perhaps we will have someone stand up and lead such a discussion; consider that part of the program still fluid. 

Software and Security Separateness - You're Doing It Wrong

Many years ago, I was a trout bum, and the guy who captured that wonderful experience better than anyone was John Gierach, I was lucky enough to live a few miles up the Frying Pan river from where he stayed when he was fishing up there. In one of his stories he recounted the following

New enthusiastic flyfisherman: "When you get your cast just right, its better than sex!"

Other person: "You are doing one of those things the wrong way."

In the same way that you can get two separate things confused you can also get confused by thinking two things that are joined as being separate - if you think security is one thing and software development is another, you are doing both of them the wrong way. I had a coffee with a marketing person yesterday, he had been to my talk at Secure 360 conference and said he liked it because he could understand it, the others were too technical (a lot of stuff in my talk was fairly technical as well, but I always strive to keep the narrative flow accessible to everyone). He really wanted to understand what I did. After several attempts of my explaining the software security problem, I pointed to one side of the coffee shop and said - the developers sit over there. Hundreds or even thousands of them. The security people sit over there on the opposite side of the coffee shop. They are separate groups, with separate agendas, they rarely collaborate, there is no center. And he got it.

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.

This corresponds to Christopher Alexander's fifteenth and most important fundamental property Not-Separateness

Let me summarize in structural terms what this property is all about. It states that any center which has deep life is connected, in feeling, to what surrounds it, and is not cut off, isolated, or separated. In a center which is deeply coherent there is a lack of separation - instead a profound connection - between that center and other centers which surround it, so that the various centers melt into one another and become inseparable. It is that quality which comes about from each center, to the degree it is connected to the whole world.

Now, let's re-examine infosec and software- we have separate groups of people, separate projects, separate agendas. They don't agree on a center. Alexander's Not-Separateness underscores not only why infosec and security has issues creating value together, but also why we need to look at decentralized software security architectures, not centralized or distributed architectures.

More deeply, so much (all?) of infosec is focused on separation and isolation, its this misguided assumption that has led infosec to a sorry record of non-innovation. A failure to realize that its a building problem, a development problem, a integration problems, and a scalability problem with security properties.

The high priests of infosec talk about protocols and access control models, instead what we need are strong centers. Obsessing about isolation mechanisms that don't scale is the wrong way to go, focusing on ways to build and integrate strong centers is. Its not about access control, its about strong subject-object centers.

Web 2.0 Security - The Beginning of the End or The End of the Beginning

Given past performance of software security, its hard to be optimistic where things are going wrt Web 2.0 security. Granted when Web 1.0 was built out did not have the ability to use static analysis to find vulnerabilities, we didn't have good identity standards and so on. So are we at a new a beginning where new tools and mechanisms will save our bacon? Or will Web 2.0 herald some new some 21st century O'leary cow that burns it all to the ground?

Again, if we take developer innovation as a given we can see that information security has a decade worth of innovation to catch up on, its very hard to argue that infosec will just latch on to Web 2.0 and actually solve this problem when it has not addressed any of the new innovations in the last decade or so.

Andy Steingruebl went to a Web 2.0 security conference and took notes on the ideas and presentations, if you are in infosec and/or developing Web 2.0 apps (that is to say if you are reading this blog), I recommend you read it and chase the links to get an idea of what is viable or not. Now to thoroughly depress/inspire you further let me share Andy's conclusions from listening to this state of the state on Web 2.0 security

We haven't come close to solving the security problems in a Web-1.0 world

So this leaves two possible choices 1) redo Web 1.0 security or 2) leave that bridge burning and try to fix the latest. Unfortunately people are instead choosing option 3 - use the same thing that didn't work in Web 1.0 and try to protect Web 2.0 with it.

We don't know what the security policies really ought to look like for the web, consequently we don't know what the architecture and implementation look like either.

We do know it should come from a security architecture and design not from an auditor's spreadsheet though.

Browsers are lacking fundamental architecture and policy around security.

And everything including administrative functions run in a browser these days

Web-2.0 only makes things worse

The OWASP guide, last I checked is over 300 pages long, when I train and consult with developers, I always ask how many are familiar with OWASP. Less than 20% are in my experience, and of those percentage most only know the OWASP Top Ten. If you have not read the guide and understood the concepts, it is really hard for me to see how your app is going to have anything more than cardboard walls level of security. Sadly, a lot developers think that software security is a solved problem, Tim Bray(*):

Of course some of these get into very sensitive security issues; but actually we’re getting pretty good at providing information on the Web in a secure way.

This type of misconception leads to the worst case scenario where you actually build apps with sensitive data and functionality, link 'em all up through mashups, Rest and whatever; and do all of this without realizing that a root and branch reform is necessary in your web application security model. How'd we get here? Broken processes? Business too demanding? No security support in programming languages? Sure they all play a role, but its not the main problem, allow me to invoke the great Gerald Weinberg:

No matter how it looks at first, its always a people problem

In our case, its quite simple the security people don't know enough about software development and developers don't know enough about security. So you can look at the innovation table and see how far software technologies have advanced and how security technologies have not kept pace, and that is an admittedly terrifying thought; but what's most scary to me is to think about the generation of people that are left behind at each technical evolution working on trivial or low priority issues. 

One of the reasons I teach software security training is to combat this, but in a company with thousands of developers I still may only get to teach 50 or 100. Many times when i teach we have the security people, developers, and architects in the same class; and usually they all know each other, but they don't work together, and a lot of the value in the class is them sitting together for a couple of days - finding some common ground, identifying some things each other are working on and then figuring out ways to make some joint progress. This is why I like teaching the class more at a company than as a public class -because when I am on site at a company they all have to work together. 

So while we go through a ton of cool things in class like threat modeling, SAML, federation, static analysis, WS-Security and so on, the coolest thing is just facilitating interaction and in some small way helping to define some ways the groups can collaborate on tools, practices, and security architecture going forward.

When it works its really great, and sometimes we even get to flip around my earlier statement - architects, software developers and security people work together as a software security team and the software security team finds vulnerabilities we didn't even know about, leverages security capabilities we didn't even know they had and deploys security services that protect the enterprise assets. Putting aside Web 2.0 as a technology; hopefully, Web 2.0 people means that software developers are software security people and security people are software security people. On that basis Web 2.0 may actually get an answer to Andy's concerns, without that Web 2.0 will remain DOA on security until Web 3.0. 

* Note: I pick on Tim Bray not because he is an idiot, quite the opposite, its because I have higher expectations and expect more regard for security out of that community. I fondly recall the days when open source took security more seriously than Microsoft.