[SecurityRatty] tag: fundamental

Security Function as a Business Enabler

Fri, 27 Jun 2008 16:50:00 +0000

In one of my earlier blog posts I branded Information Security function (as part of IT) as an overhead of an overhead. It is utmost important for security manager to run the security function in a way that it enables the business.

The various components (sub functions) of security organization should align with the business objectives of the IT and the whole organization. There needs to be a cohesive security strategy in order to align the various comoponents. One good way of understanding the business objective is why is the business parting with money for deploying a specific security component. Why is business giving me money for Compliance? Why is business giving me money to implement IDP? Constitutive questions such as these will help you to understand the fundamental concerns for the business and based on these we can come up with a strategy suitably aligned with the business.

One good example is the area of compliance. Attempting to make each every units of your business complaint with certain standards/legal regulations and so on would be a tall order. First define the scope, draw a circle around the units that need to be compliant, then come up with a strategy to make it compliant by formulating your objective - derived from the business objective of why the business gave you money.

Any security implementation effort should have a well defined focus (scope), business objective and strategy to bind the various components cohesively that aligns with the ultimate business objective. By this business will view security organization with dignity else security organization will end up being a spoke in the wheel of business.

In the past, I was involved in discussion about the ROI of information security and security is insurance and so on. After eating the forbidden apple from the tree of paradise, I realize security has neither ROI nor akin to insurance. Information security is way of doing business with due care. Security is way of enhancing the trust of a business among customers and thus enhancing the identity (or brand image of the company). Few years down the line people won't even question why you do security, it will become a part of your background conversation. Nobody questions why we buy hybrid vehicles anymore right?

If components of security function is not cohesively aligned with business objective it is spoke in the wheel of business else it is a brand enhancer of business.

42 Days In A Hole?

Thu, 12 Jun 2008 09:58:15 +0000

Jeebus. The UK gov’t has apparently been into the Bush White House’s private stash of recreational horticulture.

Being commanded about by the child-monster has slowed down my news consumption. So, big thanks to Portswigger for the heads up. Apparently the UK gov’t wants to set the new detention limit without charges to 42 days. This has triggered a firestorm.

From BBC:

Shadow home secretary David Davis has resigned as an MP.

He is to force a by-election in his Haltemprice and Howden constituency which he will fight on the issue of the new 42-day terror detention limit.

Mr Davis told reporters outside the House of Commons he believed his move was a “noble endeavour” to stop the erosion of British civil liberties.

The 59-year-old is one of the best known Tory MPs and his resignation came as a complete surprise in Westminster.

He told reporters outside the Commons: “I will argue in this by-election against the slow strangulation of fundamental British freedoms by this government.”

BBC Political Editor Nick Robinson said it was an extraordinary move which was almost without precedent in British politics.

Read on.

Article Link

Software and Security Separateness - You're Doing It Wrong

Fri, 30 May 2008 04:55:19 +0000

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

Thu, 29 May 2008 11:26:12 +0000

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.

Vengeance

Thu, 29 May 2008 09:07:04 +0000

Jared Diamond on vengeance and human nature:

This question of state government's recent origins, and, conversely, of its long failure to originate throughout most of human history, is a fundamental concern for social scientists. Until fifty-five hundred years ago, there were no state governments anywhere in the world. Even as late as 1492, all of North America, sub-Saharan Africa, Australia, New Guinea, and the Pacific islands, and most of Central and South America didn't have states and instead operated under simpler forms of societal organization (chiefdoms, tribes, and bands). Today, though, the whole world map is divided into states. Of course, most of that extension of state government has involved existing states from elsewhere imposing their government on stateless societies, as happened in New Guinea. But the first state in world history, at least, must have arisen de novo, and we now know that states arose independently in many parts of the world. How did it happen?
[...]

...anthropologists, historians, and archeologists tell us that state governments have arisen independently under one of two sets of circumstances. Sometimes external pressure from an encroaching state has placed a people under such duress that it ceded individual rights to a government of its own that would be capable of offering effective resistance. For instance, about two centuries ago, the formerly separate Cherokee chiefdoms gradually formed a unified Cherokee government in a desperate attempt to resist pressure from whites. More frequently, chronic competition among warring non-state entities has ended when one gained a military advantage over the others by developing proto-state institutions: one example is the formation of the Zulu state by a particularly talented chief named Dingiswayo, in the early nineteenth century, out of an assortment of chiefdoms fighting each other.

[...]

We regularly ignore the fact that the thirst for vengeance is among the strongest of human emotions. It ranks with love, anger, grief, and fear, about which we talk incessantly. Modern state societies permit and encourage us to express our love, anger, grief, and fear, but not our thirst for vengeance. We grow up being taught that such feelings are primitive, something to be ashamed of and to transcend.

There is no doubt that state acceptance of every individual's right to exact personal vengeance would make it impossible for us to coexist peacefully as fellow-citizens of the same state. Otherwise, we, too, would be living under the conditions of constant warfare prevailing in non-state societies like those of the New Guinea Highlands.

Notes from IEEE Web 2.0 Security and Privacy Workshop (W2SP2008)

Tue, 27 May 2008 18:45:00 +0000

Thursday 5/22 I was at the IEEE Web 2.0 Security and Privacy Workshop. I figured I'd learn a few things, and also make sure that no new exploits were announced against my employer, and/or make sure we weren't the only examples people gave of problems.

I was pretty successful on goal #1, not 100% successful on goal #2.

This post is mostly brain dump of notes about the talks followed by a few things of architectural interest that I think were discussed enough at the workshop. A quick preview - the first half of the conference was spent talking about general security holes in Web-1.0 that we still haven't solved technically/architecturally/culturally. With that in mind its hard to see how we're going to have much success with Web-2.0 security.

I'll start by saying though that I was ever so slightly disappointed with the makeup of the attendees. Conferences and workshops held by the IEEE and ACM do generally tend towards the seriously geeky and academic side of things. You're much more likely to find papers that are suitable for journals with plenty of academic references, peer review, CS technical terms, formulas, etc. At the same time though workshops do tend towards the less academic and more practical side. It was disappointing therefore that, though the workshop focused a lot of time on things like secure mashups, social networks, and Web-2.0 security models, to the best of my knowledge very few of the players in this space were present. I didn't meet anyone from any of the really interesting mashup companies and none of the social networks were there (minus google, who was well represented). Perhaps in the future people attending and organizing workshops like these can actually get the folks at the relevant companies interested, specifically invite them, etc.

Now, onto the papers/presentations themselves:

Session 1: Authentication and Authorization

Daniel Sandler and Dan S. Wallach. must die!
Daniel presented some good idea on how to move password authentication into the browser chrome to improve our defenses against javascript malware such as javascript keyloggers, etc.

While the work Daniel did was quite cool in that it doesn't require any protocol modifications, to be truly useful in implementing authentication inside browser chrome you probably need involvement from the site itself to hint, tweak, etc. Once you start doing that though, you start looking at doing stuff like cardspaces to actually get to a better architectural solution.

Ben Adida. Web Authentication by Email Address

Ben focused on usability concerns in OpenID and the idea that email addresses (or things that look like email addresses) are much better identifiers than URLs. He sketched out how to modify OpenID to use email addresses or lookalikes for authentication rather than URLs. Some of his proposals hinge on using DNS lookups for a domain to find the authentication server much like we use MX records for email. While potentially risky, DNSSEC could theoretically be used to mitigate some of the problems.

I must say I haven't kept up with OpenID as much as I'd like to, and so I'm 99% sure lots of the nuance of Ben's proposal was lost on me.

Session 2: Browser Security Models and Isolation

Collin Jackson and Adam Barth. Beware of Finer-Grained Origins

Collin Jackson presented some work he and Adam have done on how the browser security model, namely the same-origin policy, isn't nearly granular enough to handle most web applications and sites that host them.

For example:

http://cs.stanford.edu/~abarth
http://cs.stanford.edu/~cjackson

both have the same origin from the browsers point of view, but don't necessarily have the same security policy per use intent. Because the web browser can't really distinguish between them, we don't have a clean way of separating the security policies here.

Collin went on to show a multitude of problems in the same origin policy between sites, and problems in the upgrade/downgrade of security indicators in a browser. I won't rehash all of his results but suffice it to say we desperately need things like ForceHTTPS embeded in browsers in the near future to prevent some of these problems.

Kapil Singh and Wenke Lee. On the Design of a Web Browser: Lessons learned from Operating Systems

Kapil presented some research his team has been doing on modeling web browsers more like operating systems. You might have seen some related work recently as part of the OP Browser project. The idea is that the internal implementation of most browsers is pretty dicey from a security perspective. There is no clean separation between policy and mechanism. All code operates at the same privilege level. Plugins cannot be constrained in what they can do, etc.

I haven't seen any analysis yet comparing what MS did with IE7 on Vista in protected mode as compared to OP or Kapil's work. It is pretty clear that MS didn't fully segment IE7, but I wonder how close they got to ideal on the sandboxing side of things.

That said, I think our biggest problem in browser security isn't the implementation and internal segmentation. Our biggest problem is that we don't have any idea what security policies we really want to implement. Sure, having a flexible architecture under the hood makes it easier to implement flexible and finer-grained policies, but unless we have some idea what those are, perhaps we're putting the cart before the horse in terms of robust internal implementation.

Mike Ter Louw, Prithvi Bisht and V.N. Venkatakrishnan. Analysis of Hypertext Markup Isolation Techniques for XSS Prevention

My favorite presentation of the day was this one by Mike Ter Louw. Mike talked all about the multiple ideas circulating out there related to content restrictions. He showed the different failure modes for several of the proposals, showed how some of them can be rescued, and pointed towards areas that need more research.

The idea of content restrictions and server-indicated security policy that clients interpret and enforce is a really hot idea right now, and I'm hoping to catch up with Mike in the not too distant future.

Mike - if you see this, drop me a note :)

Session 3: Social Computing Privacy Issues

Adrienne Felt and David Evans. Privacy Protection for Social Networking Platform

Adrienne presented some work she's done on weaknesses in the security model of social networks and paltforms such as Facebook. She analyzed a bunch of Facebook applications to understand whether they really ought to be granted all of the rights over user data that they are. She proposed some mechanisms for limiting what types of applications get access to what data by enhancing the FBML tags to allow an application to get more data without API access. She also showed how you can solve some data sharing rules with just FBML and a few permissions extensions without resorting to full API access.

What Adrienne didn't come out and say is that in some contexts things like vetting are actually important. Most people in the social networking space and Web-2.0 space don't want to look at things like vetting, legal relationships, etc. as a model for achieving security. While a preventative model looks great on paper, solving some of the data safety/privacy concerns can really only be handled through contracts, vetting, etc. No amount of hoping developers will do the right thing and develop least-privilege applications will solve this problem.

Monica Chew, Dirk Balfanz, and Ben Laurie. (Under)mining Privacy in Social Networks

Monica presented some research on how we can inadvertently leak data from social networks by a multitude of means. While it was an interesting talk on how you can aggregate data from multiple locations to pin down more details than you ought to, since I'm not a heavy user of social networks I found myself less than interested in the general problem. If you're going to post large amounts of personal data online in multiple online sources, you're going to have people aggregating them together. There is only so much we can do to protect ourselves against that sort of aggregation.

Session 4: Mashups and Privacy

D. K. Smetters. Building Secure Mashups

D.K.'s talk was quite short on technical details and yet was one of the better talks of the day. Whereas I had a few complaints about Kapil's talk earlier in the day being a solution looking for a problem, D.K.'s talk was about the problem itself - namely - how do we actually define the security policy we're trying to achieve in the mashup space, what sorts of general rules ought to govern application behavior, security properties, etc.

This was the first talk of the day to really talk about user expectations for security, what we should generally understand to be user intent, and how to actually try and implement that in a mashup application.

Tyler Close. Web-key: Mashing with Permission

Tyler's talk may have been the most entertaining of the day, if only because of his obvious frustration with what the web has become. Tyler's main claim was that we ought to be using capability URLs to handle our authentication and authorization concerns. URLs that encode both authentication and authorization data bring us back to the original intent of the web, where the link is everything.

It was nice to see someone railing against a bit of what the web has become, but it almost felt like an original internet user lamenting the end of the end-to-end internet. A decent architectural argument, and yet one that isn't likely to yield a lot of converts. I don't think I understood a few of Tyler's points about how to prevent these URLs from leaking out and/or how to revoke access should they happen to. There are a multitude of user acceptance, behavior, and expectation questions to be answered. It was a nice twist though on how to perhaps make access-controlled content more in keeping with the spirit of the web.

Mihai Christodorescu. Private Use of Untrusted Web Servers via Opportunistic Encryption

Mihai's presentation was about how to take advantage of networked services/web-applications while proividing them with only opaque data references created with cryptography. His main example was about how to use Google's Calendar product without ever sending them your real data, and sending them only client-side encrypted data instead.

While it seems like a nice idea, and while parts of his solution were technically elegant, I think again it was a solution looking for a problem. If you're so concerned about a networked service having your data that you're willing to reverse engineer the service to make it store your individual data elements encrypted, then perhaps a networked service isn't the one for you. TYhe architectural challenges in achieving what he was able to with Google's calendar are nearly impossible with a more complicated service. And, in order to make it work you have to give up many of the feature's you'd really like from a service - full text searching, etc.

I'm guessing there are a few places where's Mihai's ideas are feasible, but its hard for me to see the value prop in building what he proposed.

Some Final Thoughts:

We haven't come close to solving the security problems in a Web-1.0 world
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.
Browsers are lacking fundamental architecture and policy around security.
Web-2.0 only makes things worse

Apart from all of the unsolved security challenges, the biggest point that struck me from the workshop was the general belief (or I assume belief, I didn't challenge people on it) that mashups are here to stay, and that we're just going to have to back into a security model for them.

I remain unconvinced that a client-side application mashup between datasets is the only way to build new and innovative applications, and that if there were any liability concerns or even contracts that held some of these companies/services even semi-accountable, perhaps we'd have a very different architecture than we're seeing as part of the mashup space.

We're spending time and money working on specs like XDR, HTML5-access-control, and we still haven't solved some of the fundamental security problems of the web. I didn't see anything at this workshop to dissuade me from that perception either.

Its like the old saying goes - "If it ain't fixed - don't break it more". Well, ok, that isn't an old saying, but maybe a few of the people working on mashups and social networks could actually operate with that as their motto we'd make some progress on all of this.

Jericho Forum and the Collaboration Oriented Architecture (COA) position paper

Fri, 09 May 2008 10:16:55 +0000

Blogger: Dan Blum

After discussing the concept of collaboration oriented architecture (COA) for some time, Jericho Forum released its COA position paper last month at the RSA and Infosecurity Europe conferences. The paper is now posted at http://www.opengroup.org/jericho/COA_v1.0.pdf.

For those who may be unfamiliar with Jericho Forum, it started as a user forum for discussing the problem of deperimeterization, wherein centralized firewalls become less effective as the mainstay of corporate security due to mobility, partnering, outsourcing, telecommuting and all those good things that happen as organizations become more geographically distributed and virtual.

The COA paper focuses on the need for business processes to operate across and between multiple organizations, potentially over untrusted networks such as the Internet. Users and endpoints must securely interact with services and applications controlled by multiple security domains.

The COA position paper builds on the Jericho Forum commandments, which are published at http://www.opengroup.org/jericho/commandments_v1.2.pdf. When reading the commandments, by the way, I find it helps to ignore the explanatory paragraphs, and just focus on the 11 statements of principle. This gets me away from nitpicking the explanations to death and into a state where I just accept them as a very good list of principles for operating securely over open networks.

The COA position paper spends much of its space describing the need for secure, open collaboration as well as principles, processes, standards and frameworks through which the collaboration might be achieved. Most of this doesn’t convey much new information to persons who already grasp the notion of deperimeterization and understand that security is about people, process and technology. But there were some really interesting bits in the section Recommended Solution/Response:

"The COA framework generalizes conventional architectures as follows. It provides:

increased emphasis on the requirements listed under ‘principles’ below. These are traditionally only seen as external or ‘boundary’ interface concerns in enterprise architectures.
a user repository (keyed on people identifiers) is generalized into a contract repository (keyed on relationship, or obligation identifiers). A contract repository records agreements, and the obligations and capabilities that ensue from them.
an accounting log (keyed on system events) is generalized into a reputation repository (keyed on business events). A reputation repository records user actions and compares them to applicable contracts, and, depending on whether or not the actions are in accordance with the contract, upgrades or downgrades a reputation.

The architecture formed by combining SOA (Service Oriented Architecture) with available security protocols (SAML or other XML) is insufficient to support COA. The following elements are also valuable: [Here, I shorten and paraphrase the list of bullet points]

attribute brokers
access brokers
contract brokers
policy language (like XACML 3.0)
performance manager (builds audit logs and reputation systems)”

I wish that the COA position paper had spent more space discussing some of its recommended solutions. The notion of a reputation system (not just a repository) is something we’re hearing more and more about. There is also a growing awareness of the importance of intermediaries, or brokers, that can fairly represent the interests of multiple parties. Perhaps we’ll see this covered in some future Jericho Forum work.

PS: The last bit of COA, in the conclusion, was quite entertaining: “A fundamental shift in thinking is required to implement a COA, moving from the thinking of a hedgehog, an animal that rolls into a tight ball at any sign of threat, to that of a Strawberry Plant, which puts all its key genetic material securely on its outside, as well as sending out suckers to extend the plant’s domain

Jericho Forum and the Collaboration Oriented Architecture (COA) position paper

Fri, 09 May 2008 10:16:55 +0000

Blogger: Dan Blum

The COA position paper spends much of its space describing the need for secure, open collaboration as well as principles, processes, standards and frameworks through which the collaboration might be achieved. Most of this doesn???t convey much new information to persons who already grasp the notion of deperimeterization and understand that security is about people, process and technology. But there were some really interesting bits in the section Recommended Solution/Response:

"The COA framework generalizes conventional architectures as follows. It provides:

increased emphasis on the requirements listed under ???principles??? below. These are traditionally only seen as external or ???boundary??? interface concerns in enterprise architectures.
a user repository (keyed on people identifiers) is generalized into a contract repository (keyed on relationship, or obligation identifiers). A contract repository records agreements, and the obligations and capabilities that ensue from them.
an accounting log (keyed on system events) is generalized into a reputation repository (keyed on business events). A reputation repository records user actions and compares them to applicable contracts, and, depending on whether or not the actions are in accordance with the contract, upgrades or downgrades a reputation.

attribute brokers
access brokers
contract brokers
policy language (like XACML 3.0)
performance manager (builds audit logs and reputation systems)???

I wish that the COA position paper had spent more space discussing some of its recommended solutions. The notion of a reputation system (not just a repository) is something we???re hearing more and more about. There is also a growing awareness of the importance of intermediaries, or brokers, that can fairly represent the interests of multiple parties. Perhaps we???ll see this covered in some future Jericho Forum work.

PS: The last bit of COA, in the conclusion, was quite entertaining: ???A fundamental shift in thinking is required to implement a COA, moving from the thinking of a hedgehog, an animal that rolls into a tight ball at any sign of threat, to that of a Strawberry Plant, which puts all its key genetic material securely on its outside, as well as sending out suckers to extend the plant???s domain

More on Application Security Metrics

Thu, 08 May 2008 16:05:00 +0000

Eric Bidstrup of Microsoft has a blog entry up titled "How Secure is Secure?" In it he makes a number of points related, essentially, to measuring the security of software and what the appropriate metrics might be.

I'd been asking the Microsoft guys for a while whether they had any decent metrics to break down the difference between:

Architectural/Design Defects
Implementation Defects

I hadn't gotten good answers up to this point because measuring those internally during the development process is a constantly moving target. If your testing methodology is always changing, then its hard to say whether you're seeing more or fewer defects of a given type than before, especially as a percentage. That is, if you weren't catching a certain class of issue with the previous version of a static analysis tool but now you are, its hard to correlate the results to previous versions of the software.

Eric says:

Microsoft has been releasing security bulletins since 1999. Based on some informal analysis that members of our organization have done, we believe well over 50% of *all* security bulletins have resulted from implementation vulnerabilities and by some estimates as high as 70-80%. (Some cases are questionable and we debate if they are truly “implementation issues” vs. “design issues” – hence this metric isn’t precise, but still useful). I have also heard similar ratios described in casual discussions with other software developers.

In general I think you're likely to find this trend across the board. Part of the reason though is that in general implementation defects are easier to find and exploit. Exploiting input validation failures that result in buffer overflows is a lot easier than complicated business logic attacks, multi-step attacks against distributed systems, etc.

We haven't answered whether there are more Architectural/Design defects or Implementation defects, but from an exploitability standpoint, its fairly clear that implementation defects are probably the first issues we want to fix.

At the same time, we do need to balance that against the damage that can be done by an architectural flaw, and just how difficult they can be to fix, especially in deployed software. Take as an example Lanman authentication. Even if implemented without defects, the security design isn't nearly good enough to resist exploit. Completely removing Lanman authentication from Windows and getting everyone switched over to it has taken an extremely long time in most businesses because of legacy deployment, etc. So, as much as implementation defects are the ones generally exploited and that need patching, architectural defects can in some cases cause a lot more damage and be harder to address/remediate once discovered/exploited.

Another defect to throw into this category would be something like WEP. Standard WEP implementations aren't defect ridden. They don't suffer from buffer overflows, race conditions, etc. They suffer from fundamental design defects that can't be corrected without a fundamental rewrite. The number of attacks resulting from WEP probably isn't known. Even throwing out high profile cases such as TJ Maxx and Home Depot, I'm guessing the damage done is substantial.

So far then things aren't looking good for using implementation defects as a measuring stick of how secure a piece of software is. Especially for widely deployed products that have a long lifetime and complicated architecture.

Though I suppose I can come up counter-examples as well. SQL-Slammer after all was a worm that exploited a buffer overflow in MS-SQL Server via a function that was open by default to the world. It was one of the biggest worms ever (if not the biggest, I stopped paying attention years ago) and it exploited an implementation defect, though one that was exploitable because it was part of the unauthenticated attack surface of the application - a design defect.

All this really proves is that determining which of these types of defects to measure, prioritize, and fix is a tricky business and as always, you mileage may vary.

As Eric clearly points out the threat landscape isn't static either. So, what you think is a priority today might change tomorrow. And, its different for different types of software. The appropriate methodology for assessing and prioritizing defects for a desktop application is substantially different than that for a centrally hosted web application. Differences related to exploitability, time-to-fix, etc.

More on that in a post to follow.

Confidential information sent to PinPay.net and SoftCard.biz is exposed

Thu, 08 May 2008 09:26:03 +0000

Technorati Tag: Security Breach

Date Reported:
4/29/08

Organization:
ACAP Security Inc.

Contractor/Consultant/Branch:
PinPay
SoftCard

Victims:
Merchants, Agents and customers

Number Affected:
Unknown

Types of Data:
Name, mailing address, phone number, email address, date of birth, city of birth, sex, and one or more of the following (chosen from drop-down):

Passport
Voting ID card
PAN card
Driving License card
Government issued ID card
Social Security Card
Military ID card
Consular ID card
Postal ID card
Government Employee ID Card
Credit Card
Debit Card

Breach Description:
ACAP Security and affiliated sites are actively marketing a "secure payment system that allows Internet-based businesses to accept secure PIN-debit card payments and transactions at their online store." The PinPay and SoftCard sign-up pages and account access pages are not adequately secured with encryption, potentially exposing extremely sensitive personal information.

Reference URL:
Merchant 911 Blog

Report Credit:
Tom Mahoney, the Founder and Director of Merchant 911

Response:
From the online source cited above and my own cursory investigation:

Back in January, I had short email dialog with a Kip Long, who claimed to be one of the principles of a company called Softcard out of Huntington Beach, CA. They are not to be confused with SoftCard Systems in Athens, GA. As far as I know, SoftCard Systems is a legitimate company with a legitimate product.

Mr. Long was rather aggressively, but not very successfully, trying to impress me with their product - from what I can make of it, a virtual PIN based card.

The company uses PinPay - to process transactions and both companies are a part of ACAP Security, Inc..

I reviewed their site for possible inclusion in our website’s resource pages, but promptly rejected them.

their insecure sign-up form - was requesting “Identity Card Numbers” and issue dates.
[Evan] The sign-up forms at SoftCard.biz and PinPay.net are not secure. Neither are their respected login pages.

“Identity cards” are selectable from a drop down menu and include such ID information as Passport, Driver’s license, SSN, and Credit Card.

The form also requires a full name and DOB.

I tried using the HTTPS URL but it appears that they do not have a security certificate tied to their site.

The fact that Mr. Long used a hotmail address to pitch the company made me wonder too, given that at Merchant911 we try to instill in our members that a free email address from a customer is a fraud alert.

If a company official can’t use his company’s domain for email, I’m not going to talk to him.

I called their attention to the insecure web form in January. They still have the form up there, happily collecting this information with an insecure form.
[Evan] I also sent emails and heard nothing in return.

I have to wonder how much information has already been sniffed or otherwise compromised. You probably don’t want to fill out this form.
[Evan] My advice would be to NOT fill out the form and NOT conduct business with a company that has not demonstrated a willingness to secure your information.

Commentary:
Tom informed me about this vulnerability (and potentially a breach for anyone that signed-up/in) a couple of weeks ago. I've been a little busy lately, but was finally able to check it out. Let me recap what I found.

First, let's go to www.softcard.biz. This is the site that Tom originally pointed out to me.

The flash home page forwards visitors to a static index (indexaa.html) page. The first paragraph on the page informs visitors about PinPay.

"The PINPAY SoftCard is a wise way to carry and transfer money. It gives you the ability to purchase products at participating stores throughout the world (as well as at online shopping malls), with the security of a PIN that travels the internet via private encrypted tunnels. It also allows you the ability to load money to your card, pay bills, transfer money to merchants, transfer money between cards, and withdraw cash from your card at the store."

See where the page says, "Register for your FREE card HERE!!"? This is a link to the sign-up page that Tom was referring to.

No "https" in the URL. Tom was right on that. The sign-up form asks for a personal information ranging from name and address to identity card information (even information for a "Second Identity Card").

The "Select Identity Card" drop down menu displays the choices for the prospective customer, including Passport, Voting ID card, PAN card, Drivers License card, Government issued ID card, Social Security card, Military ID card, Consular ID card, Postal ID card, Government Employee ID Card, Credit Card and Debit Card

SoftCard (or PinPay or ACAP Security) are asking for some very sensitive personal information! First, this is quite a bit more information than they need to approve a person for a "PINPAY SoftCard". Second, no encryption?! Third, who is ACAP/SoftCard/PinPay and what will they do to secure my information once they have it supposing it wasn't intercepted on the way to them?

Let's dig a little (public) information about ACAP Security. According to Entreprenuer.com, ACAP launched "Personal Private Network" (ppn) technology, commercially available under the trade name ppnPRO, which is described as a "highly secure, and highly private" personal private network. ppnPRO uses "Government approved AES encryption, with strong personalized 256-bit encryption keys, and encrypting all information- network addresses, applications and ports, as well as the confidential data content". Sounds impressive, but it also sounds like the company should know a thing or two about securing web site transactions with encryption.

I want to discuss the risk of sending confidential private information over a public network such as the internet without encryption, in particular. This is not a new topic, but I will take some time to demonstrate the risk.

In order for my information to be compromised, someone (or something) will need to capture the traffic. In order for someone to capture my traffic, they will need to tap into the communication somewhere between me (my computer) and the destination (the web server). My information doesn't travel directly from my computer to the server. There are intermediaries (routers, switches, firewalls, etc.) that have to get (or forward) my information from my computer to the server.

As you can see depicted in the graphic above, there are at least 16 routers (or hops) between this example source and www.softcard.biz. The final few hops are not reported due to filtering. So where could my traffic be captured? At the very least:

Between my computer and my router (or firewall)
Between my firewall and the ISP hand-off
Between all the traversed devices within my ISP's network
Between all the traversed devices through the internet
Between all the traversed devices within the destination ISP's network
Between all the traversed devices within the destination organization's network and the server itself.

Anyone in the communication path can use a simple protocol analyzer like Wireshark and capture the sensitive information:

txtfname=Billy&txtmname=J&txtlname=Madison&txtaddress=123+Main+Street&txtcity=Anywhere&
txtstate=MA&txtzip=87451&txtcountry=United+States&mob_phone=NONE&txtphone=18006218200&
txtemail=billymadison@honky.com&txtdob=04%2F20%2F1988&txtbirthcity=Boston&
txtbirthcountry=United+States&txtgender=M&identity1=Social+Security+Card&txtcardno1=123-45-6789&
txtissuedate1=04%2F20%2F1988&identity2=Driving+License+card&txtcardno2=M-1234567890&
txtissuedate2=04%2F20%2F2006&submit=Accept+Card+Agreement-Submit

This is a very simplistic demonstration about why it is important to encrypt sensitive information. If the communication had been encrypted, none of the data would have been visible without access to the private key.

We could go deeper into the server application and SQL, but I think that this is enough.

A Quote from the ACAP Security CEO:
“The right of privacy is a fundamental and very important right of American society. A right our Nation’s founders fought the American Revolution to obtain and a right many brave American soldiers have fought and continue to fight and die to preserve. As this Nation continues to advance into cyberspace, we have expanded the right of privacy to include the right to electronic privacy. The elements of cyber-crime and cyber-vulnerabilities have begun to seriously erode and destroy this important right of electronic privacy.”

Past Breaches:
Unknown