<![CDATA[[SecurityRatty] tag: mashup]]> http://securityratty.com/tag/mashup Tue, 20 May 2008 14:48:00 +0000 iRatty Engine http://blogs.law.harvard.edu/tech/rss <![CDATA[NAPA Shows How the Government is Using Web 2.0]]> http://securityratty.com/article/c2382eef0b0cdb073ef226ac74ecee5b http://securityratty.com/article/c2382eef0b0cdb073ef226ac74ecee5b Back in April, we attended a session at the FOSE conference that highlighted Web 2.0 usage in the public sector. We also found through a survey of government workers that 65% of government IT workers surveyed said that Web 2.0 tools are important to their operations. The overall message was that all IT, government included, have too many projects they could be taking on for the amount of resources they have. For much of the IT topics we covered in the survey, importance was high but actual deployment was lower.

Dan Munz, project manager of the Collaboration Project commented on the unique work that the National Academy of Public Administration (NAPA) is doing to bring together government leaders. The Collaboration Project seeks to innovate across government not just down the silos and create a safe place for leaders to have discussions around innovation.

ScienceLogic: What is the National Academy of Public Administration?

Dan Munz: The Academy is an independent, non-partisan, non-profit organization dedicated to tackling government’s most complex challenges. We were founded in 1967 by James Webb, the NASA administrator who took us to the moon – he saw that he could consult the National Academy of Sciences for expert technical advice, but had no counterpart in government for expert management advice. That’s been our mission ever since.

ScienceLogic: What is the Collaboration Project? How long has it been around?

Dan Munz: The Collaboration Project is the Academy’s response to two parallel trends we see in government. The first is the government’s need to transform the way it does business. There is a strong demand for change out there driven by a number of challenges that are forcing the government to rethink its mission and structure. Challenges include a public disconnected from government; a multi-sector workforce and increasing reliance on contractors; financial instability; and new types of security threats, just to name a few. More and more, the challenges facing government reach across the traditional boundaries of agency and mission. But government isn’t configured to work that way.

The second trend is the unprecedented opportunity collaborative technology offers to drive transformational change in government. Tools like blogs, wikis, and mashups are changing the way leaders think about problems. They’re focusing not on what they can do just within their offices or agencies, but what voices they need to pull together across government, non-profits, the general citizenry, and other stakeholders to solve these problems. The Collaboration Project’s goal is to encourage this type of thinking and empower leaders committed to use collaborative technology to:

  • strengthen citizen civic engagement;
  • enhance government transparency;
  • improve service delivery and operational efficiency; and
  • facilitate coordination and innovation within and between agencies.

ScienceLogic: Why focus on Web 2.0 in the government?

Dan Munz: The question of how web 2.0 will impact federal IT departments is a critical one. Our view is that “the era of big systems” is basically over. Things like disk space, bandwidth, and computing power are basically shifting from being assets to being commodities.

There’s also a shift in expectations. People both inside and outside government – especially Gen-X and Gen-Y – are incredibly frustrated by being able to use lightning-fast apps like Flickr, YouTube, and Facebook that don’t even live on their hard drives while the government and other large organizations still operate clunky PCs, space-limited e-mail accounts, and sluggish e-mail servers.

So aside from the opportunity for transformative leadership, the idea of web 2.0 at a government level is very appealing in terms of getting the most out of the IT infrastructure we already have, rather than embarking on costly, large-scale projects in an era of diminishing budgets.

ScienceLogic: How do you build a sense of community at the Collaboration Project?

Dan Munz: Some community feel emerges naturally, from a sense that mass collaboration really is a tool for “doing government” in a whole new way.

The more formal community building mechanisms we have include our web page, where we share insights, news, case studies, and other content – The virtual space serves as an anchor for people, whether they’re experts or beginners, to learn about what we do.

Finally, we are conducting an ongoing series of in-person meetings, usually featuring a leader who has harnessed collaborative technology in what we think is a truly revolutionary new way.

ScienceLogic: How do you hear about cool new government Web 2.0 projects?

Dan Munz: That’s a key question, because part of our mission is to inspire action by finding leaders who have succeeded and highlight their accomplishments. We’ve done that with folks like Kip Hawley, TSA, Molly O’Neill, EPA, and Jim Walker, Alabama DHS.

We also feel that the Academy’s position as a “safe space” for leaders means that we’re a place people can turn to when they hear about an emerging trend or project and want some help making sense of it.

ScienceLogic: What are the most innovative uses of Web 2.0 technology you’ve seen in the government?

Dan Munz: It’s important to distinguish between agencies that are simply adjusting to the reality of web 2.0, and those that are “using” it. Getting a YouTube account for your agency, or putting some photos on Flickr, is a great first step, but we want to inspire leaders to really transform their normal ways of doing business. At the moment a few that come to mind are the EPA Puget Sound Mashup, ODNI’s Intellipedia, TSA IdeaFactory, the PTO Peer-to-Patent Project, and Virtual Alabama, to name a few.

The TSA launched the IdeaFactory in February 2008. TSA set up a collaboration platform with commenting, voting, etc. to form communities in a way to bring people to consensus and offer ways to improve the agency’s performance.

ScienceLogic: Do you see a difference between state and local versus federal adoption of Web 2.0?

Dan Munz: That’s a hard generalization to make – at all levels you see leaders who recognize the potential in this technology to bring new voices into the governance process.

ScienceLogic: What are the obstacles to Web 2.0 adoption by government agencies?

Dan Munz: The three main challenges that we see are in the areas of technology, culture, and policy/governance.

The technology issue is probably the simplest to solve – it’s important to choose a technology that fits the problem you’re trying to solve, but these technologies are usually inexpensive and almost never very complex.

The question of culture is harder, particularly given the way that baby boomers, gen-xers, and millenials are beginning to interact in the workforce. How do you gain acceptance and buy-in among groups that have very different comfort levels with collaborative tools and environments?

Finally, the most daunting challenge might be the questions of policy and governance, if only because those are the things that most commonly prevent leaders from even dipping a toe in the waters of collaboration. Most of the policies, regulations, and statutes governing the way government does business don’t anticipate things like wikis, blogs, or instant messaging. One of our most important missions is helping leaders who just want to get to action navigate these obstacles.

ScienceLogic: Is there any advice you can give to government employees getting started with Web 2.0? Or any places you would point them to for more info?

Dan Munz: It’s shameless plug time! I’d of course point them to our web page, collaborationproject.org, where, among other things, we’ve collected a case library of over 40 instances of collaborative technology being used in the government and non-profit sectors. The library is growing every day and is a sort of “database of record” for what is and isn’t working in terms of collaborative government. I think that would be a great place to start for anyone looking to get started but not really knowing the way.

In terms of advice, the best thing to say is that, once you’ve settled on a problem you want to solve and an audience you want to reach out to, just do it! We believe strongly that there are a lot of organizational and leadership issues that still need to be addressed regarding collaboration in government, but our biggest mantra is about getting leaders to action. The most successful projects we’ve seen are ones that try something daring and new, and discover the true power of what they’ve done as it catches on more and more widely.

ShareThis

]]> Wed, 16 Jul 2008 16:45:37 +0000 web government web page government web collaboration mass collaboration collaboration project seeks government employees enhance government transparency NAPA Shows How the Government is Using Web 2.0 <![CDATA[Mashup of the Titans]]> http://securityratty.com/article/6289294023616c0d4219941919c976a5 http://securityratty.com/article/6289294023616c0d4219941919c976a5 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.
]]> Wed, 25 Jun 2008 13:29:25 +0000 protection mechanisms protection mechanisms correctly information security information implements protection mechanisms information travels information security people protection potential information path Mashup of the Titans <![CDATA[Notes from IEEE Web 2.0 Security and Privacy Workshop (W2SP2008)]]> http://securityratty.com/article/52942044add67bfabfce0e3b310191f5 http://securityratty.com/article/52942044add67bfabfce0e3b310191f5 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. <input type="password"> 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.]]> Tue, 27 May 2008 18:45:00 +0000 browser browser security models browser project browser security model security models browser security security web security challenges Notes from IEEE Web 2.0 Security and Privacy Workshop (W2SP2008) <![CDATA[Cloud This, Cloud That...]]> http://securityratty.com/article/de06cbe82dcf0ac0728d2bc3cb79338e http://securityratty.com/article/de06cbe82dcf0ac0728d2bc3cb79338e Ah, weather is nice and warm, fresh wind is cooling the face, security is in the clouds. Security in the cloud? Yup. Or, if you take Mike Rothman here at face value, "lack thereof." Now, we are not talking about "cloud-based security services" here, but about "security of cloud-based services"  - big difference!

If somebody asks you "Can you have a secure cloud-based service?" - you need to ask back "What do you mean by "you"?" Seriously! Let's go back to the old joke that "the only computer that is 'secure' is the one that is turned off, cemented into a big concrete cube and stored in a locked room." But whose room? Do you own the room where the aforementioned concrete cube is stashed? No? Then maybe it is no longer 'secure' ... Think "concrete cube in the clouds - then BAM!" :-)

Joking aside, if you think that a system that is located somewhere remotely (you don't control physical security) + Internet accessible (you don't control network security) + neither written  nor audited by you (you don't control application security) can be secure, than yes, most certainly you can have a secure cloud-based service.  This also reminded me about this post by Richard where he classifies people into "two camps: those who trust their products to operate as expected and those who do not."

Now, let's review some of the issues with security of cloud based services.

First, is there public vulnerability research that made MS IIS and OpenSSH (and OpenBSD) the paragons of software security? No, this part is completely screwed up today as only criminals are "allowed" to do vulnerability research of cloud based-services (and web applications).  Comparison here is not in favor of "the clouds," and "legacy" software approach wins hands down (want trusted apps? go audit them!). To remind yourself what the world looked like without public vulnerability research, think back to early 90s: "hot new exploit - telnet as 'root' without any password" (this is where web security stands today, pretty much).

Second, can you make sure that only you will see the sensitive data (or even regulated data: PHI, credit cards, passwords, financials, etc)? Maybe, if you take care of it. As Mike R  puts it : "Basically, you can't be sure anything is secure in the cloud, so that means you have to secure it yourself. That means building your applications with some semblance of data protection [...] But ultimately if you can't prove your data hasn't been tampered with and that it's open for anyone to steal, then I suspect your auditor may have a bit of an issue with that."

Third,  can you log and audit access to your information, stored and processed somewhere in the cloud? Maybe, if you chose the provider that allows you to do it. For example, I hear that Salesforce.com access logs are good enough to enable most things you can do with OS logs. Otherwise, well, keep begging them to build it; there is no appliance you can buy to plug this hole.

Finally, if we are insane because we use software, what about cloud services?  Sorry, multiply that insanity by 10x. Replace today's mantra "I trust my software vendor" with "I trust my cloud provider, their software developers, their outsourcers (if any), the other vendor they mashup with, my ISP (and its ISP, and its ISP,  and its ISP, etc, etc), my cloud provider's ISP (and its ISP, and its ISP, etc, etc, etc)  and ... oh, wait ... and your software developers who wrote the code that connects to the above in-the-cloud service." Cool, isn't it? :-)

This paper also reminds us about the business angle: "Remember that the storage provider has less to lose than the customer"  [that is you, BTW]. At this point somebody has got to ask "is that dirty C-word hiding somewhere here? Is there a compliance angle?" You bet. And it is "simple", really: just compare a) and b) here:

a) you manage a system that contains financial records (SOX anybody?), you screw up and they are lost OR you don't screw up and they are OK (not lost)

vs

b) you DON'T manage a system that contains financial records (SOX still?) - it is in the cloud, you DON'T screw up and they are still lost since your cloud provider screws up.

Who do you think will go to jail?  And don't even get me started on the breach disclosure law angle here (if they lose your data, than you are in violation of SB1386 - that is at least my guess ...)

By now, it should be painfully obvious to any and all of my readers that "in the cloud services" are indeed the future of IT! :-) Yes, and security is a great career - with no shortage of challenges to overcome or tall peaks to climb ... now and ever. That is why I love it.

Technorati tags: , , , ,
About me: http://www.chuvakin.org
]]> Tue, 20 May 2008 14:48:00 +0000 cloud cloud based services cloud based-services in-the-cloud service service cloud provider screws cloud provider security control physical security Cloud This, Cloud That...