1 Raindrop

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.

Security Evolution

We have been in a world of faith based security for far too long. Probably the biggest factor is a lack of innovation and dynamism in the discipline of information security. Consider this rough timeline of software development progress since the dawn of the web.

People pretty quickly realized that plain HTML was not enough, so developers invented CGI/PERL for more dynamic sites. Once they wanted to scale and pool they built out ASP and JSP, then to deliver middle tier components they developed EJB, J2EE, and DCOM. After that there were a lot of heterogeneous systems that needed to talk to each other so SOAP and XML came along to address that. This path diverged into ultra-simple (REST) and more powerful but baroque (SOA), and finally, the user side got some love with Web 2.0 technologies. That's a heck of a lot of engineering and innovation by the software development community for plus or minus 8 years.

Now lets' check in with the developer's brethren over in information security. Well, once the web came along the information security community quickly realized that network address translation was going to be important, and further that encrypting the communication channel between the browser and the web server was also crucial. And then, they addressed all the security issues ASP, JSP, EJB, J2EE, DCOM, SOAP, XML, REST, SOA, and Web 2.0 with....umm...more of the same!

That's a pretty poor showing for innovation considering the enterprise investment into information security. Sure the software developers' have a bigger budget, but come on infosec - show some pride!

Infosec types like to throw developers under the bus for security issues, but its a collective failure. Sure developers need to learn more about secure coding, but as the table above shows - security is not keeping pace, and the gap is getting bigger.

Here is another dimension to the problem - attackers *do* evolve. The new technologies provide far greater attack surface (data, method and channels) for the attacker's to exploit and/or launch attacks from.

Because the defenses have not evolved its a simple evolutionary adaptation for attackers to go around or through the 1995 defenses. Its not about SOAP going through the firewall, its about never bothering to secure the apps and the data. Its like saying to your opponent, remember the how the Detroit Lions played defense in a certain game in 1995, we were just going to do that.

So with the software developer's latest evolution we get Mr. O'Reilly's famous Web 2.0 meme map

but where is the co-evolution in infosec? there is non. There is co-evolution in the attacker space. here is a sample web 2.0 attacker meme map

So the firewall offers great protection if your adversary is using Visio, but otherwise its mostly useless.

So we would want to see two things happen - developers start writing more high assurance code and second - infosec needs to evolve its security services to form fit to that which they are protecting. Hint - it ain't a Visio diagram.

The thing is - we are getting getter tools. Static analysis is a very powerful tool to improve your software security from a bottom up perspective and it can scale. These tools continue to get better. We are are getting better standards - WS-Security, WS-Trust, and company enable fundamentally new security architectures. And we're getting better primitives, especially in the identity space - SAML, Cardspace, and friends will one day let us live in a world where users are not typing username and password into a web browser to do online banking.

So maybe the innovation tide is turning, but there is a lot of ground to catch up, infosec about a decade behind the developers and probably close to that far behind the attackers. Its going to take something special to catch up, but is there any other way? I think a big part of catching up is putting together a realistic pragmatic blueprint to evolve your security architecture - a roadmap that addresses your people, processes, and technology. There are standards, primitives, and tools to leverage, but by themselves they are just pieces, they have to be brought together into a cohesive design. Its not an overnight thing to realize this, but the point is for infosec to *begin* the evolutionary process. Now. For real use cases. Using the security protocols, mechanisms, and skills we have available now.

The Road goes ever on and on,

Down from the door where it began.

Now far ahead the Road has gone,

And I must follow, if I can,

Pursuing it with eager feet,

Until it joins some larger way

Where many paths and errands meet.

And whither then? I cannot say.

-J.R.R. Tolkien,The Hobbit

Information Security Reading List

Like information security in the real world, most (all?) information security books are about tactics, but what we also need is to understand where we are and where we are going. To do that, its important to read other fields and understand their ideas. Here is a brief reading list to explore some concepts that are useful, but relatively unexplored in information security.

1. Dhandho Investor by Mohnish Pabrai. I posted on how much I enjoyed this book in the past, and James McGovern did as well. Key thing here for us infosec types is to decouple risk and uncertainty and focus more on the former. I have often said, that I have learned more about security from reading Buffett and Munger than anything in information security literature. Pabrai is a fellow traveler on the Buffett Munger trail.

2. World is Flat - ubiquitous, but the best quote on why this work matters comes from Chris Ceppi he said to me that he thinks this book does a better job at explaining federated identity than any technical work. I agree.

3. Pentagon's New Map and Blueprint for Action by Thomas Barnett - these two books are absolutely critical to understanding 21st century security - how to think horizontally about security, deliver decentralized security services, and enable resiliency for the system as a whole. Barnett gives us a 21st century security builder model. The best work I have seen on the overlap of economic models and security models.

4. Brave New War by John Robb as I mentioned in my review Robb is the Black hat to Barnett's White hat. But when he does get perscriptive about dealing with the asymmetric threat problem that globalization has unleashed on us - the action items are all around survivability and resilience.

5. Starfish and the Spider by Ori Brafman and Rod Beckstrom - again a focus on decentralization, mapping services and skills; identifying and enabling catalysts, through trusted networks. Spiders die, starfish regenerate - think about that next time you are designing access control. Interestingly enough, Rod Beckstrom is now the cyber security czar, and I am very hopeful to see some good things come out of this appointment. Its very interesting to think about OWASP as a starfish organization. Totally decentralized, I believe one employee, a major global impact - the single best source for software security (not just web app security) - OWASP is a living testament to the positive power and impact that starfish organizations can have.

One thing these all have in common is decoupling and decentralization. In the field many times people automatically associate security with centralization, but this is often the wrong approach. Many times, the most cost effective, proportional approach is to take a decentralized path, these books give some ideas on how to do that.

Update: Chapter 5 of The New School of Information Security by Adam Shostack and Andrew Stewart is about this same issue of learning from other fields. I will have a review of this book soon, they go into quite a lot of detail about what Information Security can glean from economics, psychology and other disciplines, and I particularly like their last sentence in that chapter:

Lessons from other sciences allow us to observe the world, ask why, and receive an answer.

More on Fallacy #4

Steve Jones on Rest and Distributed Computing Fallacies

One of the objections I've had about REST for a while is that it appears to ignore Deutsch's fallacies of network computing

1. The network is reliable.

2. Latency is zero.

3. Bandwidth is infinite.

4. The network is secure.

5. Topology doesn't change.

6. There is one administrator.

7. Transport cost is zero.

8. The network is homogeneous.

Now REST specifies 8, assumes 1, 2 and 3 and takes 4 to mean HTTP/S with Basic Authentication. Now to be clear I've seen people doing Web Services who believe in pretty much all 8 of these fallacies and they create crap systems. But with things like WS-RM and WS-Security at least there are answers to a few elements.

That basic auth is bypassable has been known for some time, thanks to Amit Klein. It would be nice to Restafarians move the conversation towards better security models like SAML and WS-Security. The current state for Rest is both disappointing and weak. The response side is pretty solveable using XML Signature and XML Encryption to sign and encrypt the responses (of course someone will need to tell the "you just leverage the existing infrastructure types" that we'll need to be deploying keys and certs to all the endpoints but at least the primitives are there on the response side), the request side remains problematic.

More on the Fallacies by Arnon Rotem-Gal-Oz, who incidentally if you are interested in building a secure service has an interesting Service Firewall pattern, which I refer to as a TIDE firewall - dealing with Tampering, Information Disclosure, Denial of Service, and Elevation of Privilege threats at the edge. I understand why Arnon left Spoofing off his list, but would like to see him add audit logging to deal with Dispute.

Consulting and Size

I have been asked a variant of this question about 5 times in the past 2 weeks - "how many people does arctec group have?"

So in case anyone else out there is wondering...We have been around for 7 years, ranging from 2-3 people. we are like the special forces - get in, get the job done, get out. hence focus on training, architecture, detailed design. Of course, we work on projects that are sometimes very large and if necessary we can help build out larger teams sourced from other places but our focus is excellence in training, architecture, and design not jamming 15 blue suited consultants into your cubes.

Not that there isn't room for larger consulting groups, just not our focus. When we started our company our model was more like a law firm or a real world architecture firm. In most cases, you don't hire a lawyer or architect because they have 30,000 people in their firm, you hire them because they have the expertise in the area you are trying to address. So its not "how many architects in your firm? mroe than a 1,000?" its more "tell me about your other clients/projects. show me some buildings you have helped build."

Building a Security Architecture Blueprint

This week I spoke at the Secure 360 conference on Building A Security Architecture Blueprint (slides). My thesis is that information is a strategic enterprise asset (in many cases it *is* the business), yet the typical enterprise approach to securing the information or even risk management, is rarely strategic. Last year, I wrote a Security Architecture Blueprint paper to describe one framework for putting a strategic context around information security program. The main idea is that instead of starting with security goals (cue the ritual CIA invocation), we start with considering security in the context of the stakeholders - business, development, operations, customers, and so on.

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.

Price is what you pay, value is what you get

Nice work by Francois Paget (hattip Andrew Jaquith) pulling together underground economy's willingness to pay up for quality

Last Friday morning in France, my investigations lead me to visit a site proposing top-quality data for a higher price than usual. But when we look at this data we understand that as everywhere, you have to pay for quality. The first offer concerned bank logons. As you can see in the following screenshot, pricing depends on available balance, bank organization and country. Additional information such as PIN and Transfer Passphrase are also given when necessary:

Since financial services drives a lot of the information security industry it is fair to ask - are they doing a very good job at securing systems and data or are they just moving more risk on to the consumer? In 2008, should we be telling people to type usernames and password into web forms and the use those "secrets" (cough, cough) to make business decisions?

Weak identity = weak claim = weak access control.

From Ross Anderson's book (2nd edition)

Were I designing an online banking system now, I would invest most of the security budget in the back end.

Rote Based Access Control

I think RBAC is, next to firewalls and SSL, the biggest silver bullet misconception in infosec. I cannot count how many times I have heard managers say if we just had rbac all our identity problems would be solved. These same managers work in companies that reorg every 6 months and outsource anything that moves. Not that RBAC is useless, it can solve some problems, but introduces some too, Pamela Dingle

Roles are indeed in the domain of the “identity weenie” — but alone, roles are nothing but a maintenance nightmare - they exist to be leveraged. Rules on the other hand, are the problem of the “authorization weenie” and are written (for example) as a WAM policy that says “All Production Accountant Level II resources can access the accounting SharePoint instance”. When you collect roles into a profile and collect rules into a policy and then evaluate for a given user, resource, and point in time, what you eventually get is an entitlement, ie “Jenny should get into the accounting SharePoint instance”. The goal is to have transitive logic between roles and rules, such that two different people can take on the two different statements being made. Jenny’s Manager can authoritatively state (through a workflow approval) that Jenny is indeed a production accountant. The owner of the Accounting Sharepoint instance can authoritatively state (through an authorization policy) that all production accountants should have access to their site. ... What happens when the system detects the static presence of two conflicting roles? What happens if one role is “truer” than another at some point in time?

The other silver bullet fallacy the RBAC introduces is the idea that objects, subjects, and sessions can be bundled so nicely enterprise wide. People look at their nice org charts and assume that you just plug that into your directory and go. Works great in a domain with hard edges like a call center where discreet groups of people execute the same tasks the same away across many sessions. Not so good once you step above the rote task level. Interestingly "God level" access works well with roles too, but we are not supposed to be building systems with that stuff any more, right?

Learning from Ghana

Its always interesting to see where the developed world can learn from emerging economies. A lot of the best engineering work comes from having to deal with harsh constraints (opposite of architecture astronomics). I blogged awhile ago about using smart cards for digital cash in Africa

Looks like there is a new system in Ghana as well

E-zwhich smart launched

-ZWICH smartcard, a universal electronic system that facilitates easy access to and transfer of money has now become part of financial transactions in Ghana.

The new system which is also designed to remove the cumbersome and insecure processes of using cash, was launched in Accra yesterday by President J.A. Kufuor, with a call on corporate bodies and government agencies to use it to ensure transparency and integrity on payrolls.

E-zwich is an electronic payment system that allows one to make payments for goods and services or transfer money to others without having to carry physical cash.

Available at all banks countrywide, the system involves the loading of money onto the smart card after registering with any bank without necessarily having an accounts with that bank.

President Kufuor said the introduction of the system has the potential of transforming the payments landscape, the financial services industry and the general conduct of business in the country.

He said accessing the technology was an integral part of government’s overall vision of making Ghana the gateway to the West Africa sub-region and transforming her into a major financial hub.

The President said that globalisation has come with a major challenge of adopting best practices in all spheres of endeavour especially within the macro economy in order to survive in the market.

He said it was against that background that the government has pursued polices to develop and modernise the financial sector to enable it to play a key role in resource mobilisation for increased investment.

With the reforms and the stability of the macro-economy, President Kufuor said the nation was witnessing dramatic growth in the banking sector.

He pointed out, however, that inspite of the impressive growth of financial institutions, an estimated 80 per cent of the eligible population was still "un-banked" or "under-banked" and seemed not to have access to financial services.

Wonder when we will see US, UK, and other first world banks and brokerages catch up to Ghana and South Africa on these technologies? Is it really a good idea in 2008 to have everyone type their username and password into a web browser?