We launched a new blog to share some thoughts about the security practices at my employer.
The blog is here: http://www.thesecuritypractice.com/.
The basic introduction and purpose can be found here: http://www.thesecuritypractice.com/the_security_practice/who-are-we.html
And, a post about Firefox-3.0's handling of self-signed certificates can be found here.
This was in reaction to a piece published on Risks a bit ago - "Firefox 3's Step Backwards For Self-Signed Certificates".
Tuesday, August 12, 2008
Monday, August 11, 2008
Economist.com - Confessions of a Risk Manager
I was reading the Economist this week and came across an excellent article titled "Confessions of a Risk Manager".
In the article a risk manager for a major financial institution talks about managing risks and how the risk department was viewed as an obstacle by the rest of the business. I'll just quote a section here so you can see that governance roles, especially those involving trade-offs of risk vs. return are difficult not just in security.
Every time I read about decision making like this I refer back to an some excellent presentations I've come across by Reidar Bratvold. He has done some excellent presentations on decision making in the face of risks/uncertainty.
In the article a risk manager for a major financial institution talks about managing risks and how the risk department was viewed as an obstacle by the rest of the business. I'll just quote a section here so you can see that governance roles, especially those involving trade-offs of risk vs. return are difficult not just in security.
In their eyes, we were not earning money for the bank. Worse, we had the power to say no and therefore prevent business from being done. Traders saw us as obstructive and a hindrance to their ability to earn higher bonuses. They did not take kindly to this. Sometimes the relationship between the risk department and the business lines ended in arguments. . . .
Tactfully explaining why we said no was not our forte. Traders were often exasperated as much by how they were told as by what they were told.At the root of it all, however, was—and still is—a deeply ingrained flaw in the decision-making process. In contrast to the law, where two sides make an equal-and-opposite argument that is fairly judged, in banks there is always a bias towards one side of the argument. The business line was more focused on getting a transaction approved than on identifying the risks in what it was proposing. The risk factors were a small part of the presentation and always “mitigated”. This made it hard to discourage transactions. If a risk manager said no, he was immediately on a collision course with the business line. The risk thinking therefore leaned towards giving the benefit of the doubt to the risk-takers.
Collective common sense suffered as a result. Often in meetings, our gut reactions as risk managers were negative. But it was difficult to come up with hard-and-fast arguments for why you should decline a transaction, especially when you were sitting opposite a team that had worked for weeks on a proposal, which you had received an hour before the meeting started. In the end, with pressure for earnings and a calm market environment, we reluctantly agreed to marginal transactions.
Every time I read about decision making like this I refer back to an some excellent presentations I've come across by Reidar Bratvold. He has done some excellent presentations on decision making in the face of risks/uncertainty.
Sunday, August 10, 2008
[Offtopic] Beginning Hacker
My daughter and I were playing a little online Dora computer game today. As we got to one of the screens where you're supposed the click the letters Dora tells you to, Elise decided it would be more fun to experiment with the game to see what happens when you click the wrong letters instead. She liked the reaction from the game as it repeatedly tried to tell her the "right" thing to do and she deliberately ignored it.
Makes me pretty proud - don't do what the software expects you to do, break the rules instead and see what happens.
Courtesy of my friends at iSec Partners, here she is dressed in her hacker garb.
Makes me pretty proud - don't do what the software expects you to do, break the rules instead and see what happens.
Courtesy of my friends at iSec Partners, here she is dressed in her hacker garb.
Thursday, May 29, 2008
Offtopic: 0xe0030005
Question: What is the sound of a disk drive crashing?
Answer: Not much.
Question: What does it do?
Answer: It spits out "disk0s2: 0xe0030005 (UNDEFINED) and then it just locks up and won't boot.
Question: When/Why does it do this?
Answer: If its a Macbook whose hard drive just went bad.
Delightfully Apple's Disk Utility still shows the drive as good, as does the S.M.A.R.T. monitoring.
Alas - off to the store for a replacement drive.
Ok, I can't let this post go by without making some sort of web security note....
The above "dialog" would have been much better if your browser supported the draft HTML5 spec. Then I'd have been able to use the
Answer: Not much.
Question: What does it do?
Answer: It spits out "disk0s2: 0xe0030005 (UNDEFINED) and then it just locks up and won't boot.
Question: When/Why does it do this?
Answer: If its a Macbook whose hard drive just went bad.
Delightfully Apple's Disk Utility still shows the drive as good, as does the S.M.A.R.T. monitoring.
Alas - off to the store for a replacement drive.
Ok, I can't let this post go by without making some sort of web security note....
The above "dialog" would have been much better if your browser supported the draft HTML5 spec. Then I'd have been able to use the
Tuesday, May 27, 2008
Notes from IEEE Web 2.0 Security and Privacy Workshop (W2SP2008)
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:
Quick Note: In attending the conference each author presented slides and talked about their paper. I only read a few of the papers so far, so don't take the commentary below too seriously, since I'm sure I missed some things that were covered more fully in the papers than the presentations.
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.
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.
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
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.
Session 4: Mashups and Privacy
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.
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.
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:
Quick Note: In attending the conference each author presented slides and talked about their paper. I only read a few of the papers so far, so don't take the commentary below too seriously, since I'm sure I missed some things that were covered more fully in the papers than the presentations.
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
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.
Monday, May 12, 2008
A Small Rant About Conference/Journal Papers and Timestamps
Why is it that most/all papers published in Journals and/or as part of conferences never have a date/timetamp attached?
Its rather a bit frustrating to read a paper you've been sent, or had a link for, only to have no idea when/where it was published...
Just Friday I was pointed at an article by Dan Geer - http://www.acmqueue.org/modules.php?name=Content&pa=showpage&pid=436
Awesome article, but you won't see any real date information on it. January/February Edition on the ACM Queue. Which year? Hmm, can't tell can you, at least not from that page. Hell, the date at the top is the date you loaded the page, not the date of the article. More than a little frustrating.
Ok, rant mode off. The next post will probably be about the article above.
Its rather a bit frustrating to read a paper you've been sent, or had a link for, only to have no idea when/where it was published...
Just Friday I was pointed at an article by Dan Geer - http://www.acmqueue.org/modules.php?name=Content&pa=showpage&pid=436
Awesome article, but you won't see any real date information on it. January/February Edition on the ACM Queue. Which year? Hmm, can't tell can you, at least not from that page. Hell, the date at the top is the date you loaded the page, not the date of the article. More than a little frustrating.
Ok, rant mode off. The next post will probably be about the article above.
Thursday, May 08, 2008
More on Application Security Metrics
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:
Eric says:
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.
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
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.
Saturday, April 19, 2008
Metrics and Audience
There has been some chatter recently about a post Pete Lindstrom made about Microsoft's SDL and their publicly disclosed metrics. I chimed in on Pete's blog as well as on the Microsoft SDL blog, here is a little more.
The fundamental confusion here is about the audience for the vulnerability numbers, and metrics in general.
There are several audiences here:
Security folks, especially those working on their own software security initiatives find the vulnerabilities metric mostly useless. It gives us no insight into *how* Microsoft has achieved the reduction in vulnerabilities. What we'd all love to know is how much each element of the SDL contributes to reducing vulnerabilities. A percentage break out on how effective each element is, Training, Threat Modeling, Testing, at reducing vulnerability counts, especially as broken out by design/architecture defects and implementation defects.
At the same time, I'm willing to acknowledge that developing these metrics is a full time job for multiple people. And, tracking the metrics over time is difficult, since its hard to normalize the defects between products and across time. New attacks are always surfacing, so how do you track the impact of new attack types across time. How do you track the impact of better code scanning/static-analysis tools over time. As the tool improves you'll find more defects when you run it, but that will skew your metrics somewhat.
The fundamentally unanswered question though is how do we actually measure the security of software. From a general customer standpoint what you care about is how likely you are to get attacked and compromised for one piece of software vs. another, what that software is going to cost to buy and run, etc.
For the security community what we're looking for is a metric that more closely tracks the "real" security properties of a piece of software. How hard it is for the expert to attack, how it does in real world deployments, etc.
Unfortunately no one metric is going to capture this. As I've previously mentioned the QoP workshop is a great place to go if you're looking for answers to the "how do we measure software security" question. But if what you want to know is how much is it generally going to cost me to run/implement a piece of software, looking at things like number of required patches and their frequency/severity, then perhaps Microsoft's vulnerability metric is for you.
The fundamental confusion here is about the audience for the vulnerability numbers, and metrics in general.
There are several audiences here:
- Microsoft's customers, competitors, and the public at large.
- Security folks, especially software security folks that want to improve the quality of their software.
- People who want more metrics about all things generally, the costs of security, etc.
Security folks, especially those working on their own software security initiatives find the vulnerabilities metric mostly useless. It gives us no insight into *how* Microsoft has achieved the reduction in vulnerabilities. What we'd all love to know is how much each element of the SDL contributes to reducing vulnerabilities. A percentage break out on how effective each element is, Training, Threat Modeling, Testing, at reducing vulnerability counts, especially as broken out by design/architecture defects and implementation defects.
At the same time, I'm willing to acknowledge that developing these metrics is a full time job for multiple people. And, tracking the metrics over time is difficult, since its hard to normalize the defects between products and across time. New attacks are always surfacing, so how do you track the impact of new attack types across time. How do you track the impact of better code scanning/static-analysis tools over time. As the tool improves you'll find more defects when you run it, but that will skew your metrics somewhat.
The fundamentally unanswered question though is how do we actually measure the security of software. From a general customer standpoint what you care about is how likely you are to get attacked and compromised for one piece of software vs. another, what that software is going to cost to buy and run, etc.
For the security community what we're looking for is a metric that more closely tracks the "real" security properties of a piece of software. How hard it is for the expert to attack, how it does in real world deployments, etc.
Unfortunately no one metric is going to capture this. As I've previously mentioned the QoP workshop is a great place to go if you're looking for answers to the "how do we measure software security" question. But if what you want to know is how much is it generally going to cost me to run/implement a piece of software, looking at things like number of required patches and their frequency/severity, then perhaps Microsoft's vulnerability metric is for you.
Saturday, April 12, 2008
My Favorite RSA Sessions
I spent the whole week up at the RSA conference including the Monday before attending a few pre-conference activities. If you didn't get to go but know someone who did, I thought I'd recommend a few of the sessions I found most informative. I attended more sessions than the ones below but the talks below seemed to resonate the most for me.
DEV-201 Implementing a Secure SDLC: From Principle to Practice
This session was a fantastic overview of the SDL practices that EMC has been implementing for the last 2 years. A pretty good overview of what it takes to rollout the SDL against a bunch of products.
DEV-301 Effective Integration of Fuzzing into Development Life Cycle
A really good overview of what fuzzing is, how to think about the different types of fuzzing, and what types of applications it works best on.
AUTH-403 Knowledge-Based Authentication (KBA) in Action at Bank of New York Mellon
An excellent overview of what BNY-Mellon went through in implementing KBA for part of their authentication process. They deployed Verid to help customers sign up to the site. If you're not familiar with KBA, think about how the credit reporting agencies authenticate you for getting your credit report. They ask you a bunch of questions about your bills, payments, etc. that they figure only you will know. A KBA system such as Verid can do the same but pulls data from a lot more sources so it can ask things about former addresses, phone numbers, employers, etc. BNY-Mellon has put together a pretty good program, they are collecting great metrics about the success of the program, and the presenters were also excellent. Probably the best session I saw all around, even though it was one of the least technical.
GOV-401 Will Your Web Research Land You in Jail?
Sara Peters, the editor of the 2007 CSI report on web vulnerability research and the law gave an overview presentation of the report. On the one hand I was a little disappointed because this material was actually relatively dated because RSA makes people submit their papers/presentations so early. On the other hand it was nice to revisit this topic since it was this report that prompted the vulnerability disclosure policy I helped author last year.
DEV-201 Implementing a Secure SDLC: From Principle to Practice
This session was a fantastic overview of the SDL practices that EMC has been implementing for the last 2 years. A pretty good overview of what it takes to rollout the SDL against a bunch of products.
DEV-301 Effective Integration of Fuzzing into Development Life Cycle
A really good overview of what fuzzing is, how to think about the different types of fuzzing, and what types of applications it works best on.
AUTH-403 Knowledge-Based Authentication (KBA) in Action at Bank of New York Mellon
An excellent overview of what BNY-Mellon went through in implementing KBA for part of their authentication process. They deployed Verid to help customers sign up to the site. If you're not familiar with KBA, think about how the credit reporting agencies authenticate you for getting your credit report. They ask you a bunch of questions about your bills, payments, etc. that they figure only you will know. A KBA system such as Verid can do the same but pulls data from a lot more sources so it can ask things about former addresses, phone numbers, employers, etc. BNY-Mellon has put together a pretty good program, they are collecting great metrics about the success of the program, and the presenters were also excellent. Probably the best session I saw all around, even though it was one of the least technical.
GOV-401 Will Your Web Research Land You in Jail?
Sara Peters, the editor of the 2007 CSI report on web vulnerability research and the law gave an overview presentation of the report. On the one hand I was a little disappointed because this material was actually relatively dated because RSA makes people submit their papers/presentations so early. On the other hand it was nice to revisit this topic since it was this report that prompted the vulnerability disclosure policy I helped author last year.
Monday, March 24, 2008
Measuring the Wrong Things?
I'm not sure why I'm always finding interesting articles in NPR about medicine that seem to resonate so much in relation to software security. Nonetheless that seems to be how things go, so here comes another one.
NPR ran a story the other day titled "Doctors' 'Treat the Numbers' Approach Challenged". The main idea in the story is that doctors have been treating patients and using the results of certain tests as the metrics by which they judge health. They treat a patient with drugs, therapies, etc. to get to the diagnostic numbers they want, but now we're finding out that perhaps the numbers are not necessarily representing what we'd like them to.
The example from the article was:
NPR ran a story the other day titled "Doctors' 'Treat the Numbers' Approach Challenged". The main idea in the story is that doctors have been treating patients and using the results of certain tests as the metrics by which they judge health. They treat a patient with drugs, therapies, etc. to get to the diagnostic numbers they want, but now we're finding out that perhaps the numbers are not necessarily representing what we'd like them to.
The example from the article was:
Doctors call it "treating the numbers" — trying to get a patient's test results to a certain target, which they assume will treat — or prevent — disease. But earlier this year, a study on a widely used cholesterol drug challenged that assumption.
Vytorin, a combination of two cholesterol-lowering agents, certainly lowers cholesterol. But patients taking it didn't have any less plaque in a major artery than those taking a less-potent drug.
I'm assuming that less plaque generally does translate to fewer adverse events, but the article doesn't cover this. Helpfully, in medicine we generally have a pretty clear definition of an adverse event, and we're not dealing with intelligent active threats. Active threats (virus, bacteria, fungus, parasite), but not intelligent... We don't try to design cholesterol treatments to fend off a malicious food company that has designed a new more dangerous form of cholesterol that our drug can't fight :)
Knowing what to measure in security is hard though. We've covered a little of this before here.
If you're looking for more formal treatments of security metrics - check out the Quality of Protection (QoP) workshop held as part of the ACM CCS Conference.
"The goal of the QoP Workshop is to help security research progress towards a notion of Quality of Protection in Security comparable to the notion of Quality of Service in Networking, Software Reliability, or measures in Empirical Software Engineering."
Over the next few posts I'll take a few of the papers from the workshop and discuss a bit of their results. If you're interested in the TOC for the workshop, you can find it here.
Tuesday, March 18, 2008
Banning function calls, assurance, and retrofitting
I've been working on some C/C++ secure coding standards lately, and trying to mesh those up with the results from the static analyzer I'm using. As it turns out there is a fine line to be drawn between what you consider best practices, what a static analyzer can find, how much context the static analyzer has, and how much manual review you really want to put up with.
Let me give a specific example.
Coverity's Prevent analyzer has a number of built-in "unsafe" functions defined. The list includes the standard cast such as scanf, strcpy, strcat, etc. On top of that though they add some things that didn't make Microsoft's list; for example, rand().
I don't technically have a problem with including rand() in the list of things to be extremely careful about, but whereas it is nearly impossible to guarantee that someone has used strcpy() right, rand() actually has some pretty legitimate uses.
Consider the case where we want to do a randomized delay in processing something, or where we wish to randomly assign work to different people when it comes in, or randomly pull an item off a work queue for a customer service agent. None of these cases requires a cryptographically sound random number generator. For the most part, using rand() is a perfectly reasonable choice in this sort of situation.
When you decide that you want to ban certain function calls, or call them out in findings in a static analyzer, you're treading a fine line with your developers and the people you're going to ask to go and clean up the old code you have around. You can choose to go several routes.
If you choose to file defects against your developers for code that is years old and wasn't necessarily written by them without verifying the vulnerabilities, you run the risk of them not taking the secure coding rules seriously. Many of the items they find are going to be false positives from a currently-exploitable perspective, and they are going to be cranky with you.
If you choose to go through the validate each and every defect and the types of defect are pervasive, you're going to spend almost as much verifying the defect as fixing it. Especially if you're going through and simply replacing strcpy() with strlcpy() for example. For both this and the case above though, developers are going to be going through the code, and with the proper training/awareness, they might actually learn more about some of the old code, or at least start to have a better sense of some real security issues in the code.
If you choose to get a dedicated team together to fix the old code, you're likely to save money in the short run. A dedicated team is going to get used to fixing the coding defects of this type, and you're going to make a lot shorter job of it. The downside being that the regular developers aren't getting some of the code review experience you'd really like.
To top things off, if you go route #2, wherein you only fix things that are currently exploitable, you run the risk of the code being used in a different way elsewhere and causing problems down the road.
Back to my rand() example. In every case where I've found rand() used it hasn't been in a security critical context. Do I want to leave these instances of rand() in my code as examples that others might follow, next time in a security sensitive context? Or, do I want to take a relatively dogmatic approach to this and all other banned/"unsafe" functions and eliminate them entirely from my codebase?
I'm leaning towards some sort of middle ground. If I can find the time for a dedicated team to go through the code to clean up old issues, then I'm likely to remove all instances of things that could be unsafe, just so we don't leave things around that could be copied into an truly unsafe context.
Its a tricky balancing act to determine how dogmatic you want to be about fixing up the use of certain "unsafe" functions. Getting it wrong either way can have long term consequences for your secure development program. As always, the right answer depends on a lot of factors.
Let me give a specific example.
Coverity's Prevent analyzer has a number of built-in "unsafe" functions defined. The list includes the standard cast such as scanf, strcpy, strcat, etc. On top of that though they add some things that didn't make Microsoft's list; for example, rand().
I don't technically have a problem with including rand() in the list of things to be extremely careful about, but whereas it is nearly impossible to guarantee that someone has used strcpy() right, rand() actually has some pretty legitimate uses.
Consider the case where we want to do a randomized delay in processing something, or where we wish to randomly assign work to different people when it comes in, or randomly pull an item off a work queue for a customer service agent. None of these cases requires a cryptographically sound random number generator. For the most part, using rand() is a perfectly reasonable choice in this sort of situation.
When you decide that you want to ban certain function calls, or call them out in findings in a static analyzer, you're treading a fine line with your developers and the people you're going to ask to go and clean up the old code you have around. You can choose to go several routes.
- File defects against the old code for any use of a banned function, without investigating the specific use
- File defects against old code only after verifying that in the context you have a potential vulnerability
- Get a dedicated team together to just go and clean up old code
If you choose to file defects against your developers for code that is years old and wasn't necessarily written by them without verifying the vulnerabilities, you run the risk of them not taking the secure coding rules seriously. Many of the items they find are going to be false positives from a currently-exploitable perspective, and they are going to be cranky with you.
If you choose to go through the validate each and every defect and the types of defect are pervasive, you're going to spend almost as much verifying the defect as fixing it. Especially if you're going through and simply replacing strcpy() with strlcpy() for example. For both this and the case above though, developers are going to be going through the code, and with the proper training/awareness, they might actually learn more about some of the old code, or at least start to have a better sense of some real security issues in the code.
If you choose to get a dedicated team together to fix the old code, you're likely to save money in the short run. A dedicated team is going to get used to fixing the coding defects of this type, and you're going to make a lot shorter job of it. The downside being that the regular developers aren't getting some of the code review experience you'd really like.
To top things off, if you go route #2, wherein you only fix things that are currently exploitable, you run the risk of the code being used in a different way elsewhere and causing problems down the road.
Back to my rand() example. In every case where I've found rand() used it hasn't been in a security critical context. Do I want to leave these instances of rand() in my code as examples that others might follow, next time in a security sensitive context? Or, do I want to take a relatively dogmatic approach to this and all other banned/"unsafe" functions and eliminate them entirely from my codebase?
I'm leaning towards some sort of middle ground. If I can find the time for a dedicated team to go through the code to clean up old issues, then I'm likely to remove all instances of things that could be unsafe, just so we don't leave things around that could be copied into an truly unsafe context.
Its a tricky balancing act to determine how dogmatic you want to be about fixing up the use of certain "unsafe" functions. Getting it wrong either way can have long term consequences for your secure development program. As always, the right answer depends on a lot of factors.
Monday, March 17, 2008
Good Economist Article on Software Security
Last week the Economist ran their Technology Quarterly series and had a great piece on software security, quality. The title was "Software that makes software better."
The Technology Quarterly is a great read that covers quite a number of new/evolving areas of technology such as improvements in battery design/lifetime, new pico-projectors, and this time a great article about software quality and security.
The article is a quick run-through of integrating quality and security concerns into the development process through the judicious use of tools. The two major items of note from the paper were:
1. Integrating the tools with how developers usually work is key
2. We still don't really have any idea what we're doing :)
From a metrics perspective, the most important line was this one from NIST:
I added the emphasis above. That line from Paul is a pretty ambitious statement - though who knows whether the reporter really got the quote right. Overall the SAMATE project is an important aspect of increasing assurance, but I'll be surprised if we manage to boil things down to do this, this, and this, it will cost X, and you'll be Y-secure.
The Technology Quarterly is a great read that covers quite a number of new/evolving areas of technology such as improvements in battery design/lifetime, new pico-projectors, and this time a great article about software quality and security.
The article is a quick run-through of integrating quality and security concerns into the development process through the judicious use of tools. The two major items of note from the paper were:
1. Integrating the tools with how developers usually work is key
2. We still don't really have any idea what we're doing :)
From a metrics perspective, the most important line was this one from NIST:
America's National Institute of Standards and Technology (NIST) is doing its best to create the software equivalent of the “generally accepted accounting principles” used in the financial world. Its Software Assurance Metrics and Tool Evaluation (SAMATE) project is intended to offer companies a way to quantify how much better their code will be if they adopt particular tools and programming languages. Paul Black of NIST says its first report, on static-analysis tools, should be available in April. The purpose of the research is “to get away from the feeling that ‘all software has bugs’ and say ‘it will cost this much time and this much money to make software of this kind of quality’,”
I added the emphasis above. That line from Paul is a pretty ambitious statement - though who knows whether the reporter really got the quote right. Overall the SAMATE project is an important aspect of increasing assurance, but I'll be surprised if we manage to boil things down to do this, this, and this, it will cost X, and you'll be Y-secure.
Thursday, February 07, 2008
The Checklist
Brian Chess wrote about a great article in the New Yorker - "The Checklist." The article is a fantastic read and I highly recommend it, even if you're not interested in medicine. It is well written and quite engaging about how doctors handle a ridiculously complex topic - intensive care.
Like Brian, I was struck by how closely the article can parallel some of the problems we face in trying to develop secure software. I agree with the basic premise of Brian's statement, that a checklist can help in the software development world just like it can in the ICU. I've had great success providing checklists to developers of common areas of concern, areas they need to make sure the document, etc.
I want to focus on two other items from the article that are worth noting.
In the paper the author talks about following the checklist and how it reduced deaths. One thing he never mentions is the cost of following the checklist. I thought it interesting, but I can only assume based on the number of lives saved, and the cost of even a single infection, that the costs of following the checklist are far outweighed by the cost savings. Still, it would have been nice to see a cost comparison between the two.
What is also interesting though is that in the hospital setting its generally quite clear what an adverse event is. We generally know when someone has an infection, we certainly know when someone dies. We do root cause analysis in many cases (though not all) to understand the general cause of death, though when there is an infection for example we don't always get to root cause.
One result of this sort of tracking, is that it occurs within a regulatory framework where hospitals must report their incident rates publicly, and there are agencies within government charged with collecting, monitoring, and even in some cases improving on these measurements and results.
As a result of this public tracking, the key doctor from the paper, Pronovost, was able pretty clearly to tell whether his process changes were having a positive or negative effect. He had lots of public data to draw from, and the incidence rate at any given hospital is large enough that we can start to make valid statistical judgments about the impact of our changes.
Contrast this with software and the differences in both area, and maturity, are quite telling. We don't have any standard measures of success/failure, we don't perform lots of root cause on adverse events, and we don't have public reporting of success and failure. So, we don't have a general body of knowledge that allows us to get better or at least measure how we're doing.
Maybe we ought to have something like that? I wrote about this last year when saying that we ought to have some sort of NTSB for security, or at least for security breaches. Maybe its time we start taking that more seriously?
Processes
I was also struck by one of Pronovost's comments about medicine that I think especially relevant to software security. When asked whether we'd get to the point that checklists are as common as a stethoscope for a Dr, he replied:
For the most part we fail to treat the delivery/creation of software as a science. We do lots of research on languages, we do lots of work on theories of security, and then it all breaks down because we have people implementing the processes, and we don't spend any time on that. Well, at least not in measure to how much we spend on all sorts of other efforts that we don't measure, we aren't sure achieve results, etc.
We know lots about how to theoretically secure things, but we don't know a whole lot about how to get large software development organizations to produce consistently high quality/"secure" software. Heck, we don't even know how to do it if we aren't budget constrained, much less if we are.
To be sure, medicine hasn't solved this problem either, and they aren't dealing with a huge installed base :) They are better at measuring effectiveness, but again they are in a life/death world plus they have the added joy of strict liability. Operating under those conditions they do manage to settle on newer/better techniques pretty quickly, because they are tracking how they are doing, lives are on the line, and they are pretty strongly incented to get it right.
Like Brian, I was struck by how closely the article can parallel some of the problems we face in trying to develop secure software. I agree with the basic premise of Brian's statement, that a checklist can help in the software development world just like it can in the ICU. I've had great success providing checklists to developers of common areas of concern, areas they need to make sure the document, etc.
- Document how you handle authentication. if different from standard X, get a security reviews.
- Document how you're handing input filtering. If not the standard library with declarative syntax, document and get a security review.....
I want to focus on two other items from the article that are worth noting.
- Metrics
- Processes
In the paper the author talks about following the checklist and how it reduced deaths. One thing he never mentions is the cost of following the checklist. I thought it interesting, but I can only assume based on the number of lives saved, and the cost of even a single infection, that the costs of following the checklist are far outweighed by the cost savings. Still, it would have been nice to see a cost comparison between the two.
What is also interesting though is that in the hospital setting its generally quite clear what an adverse event is. We generally know when someone has an infection, we certainly know when someone dies. We do root cause analysis in many cases (though not all) to understand the general cause of death, though when there is an infection for example we don't always get to root cause.
One result of this sort of tracking, is that it occurs within a regulatory framework where hospitals must report their incident rates publicly, and there are agencies within government charged with collecting, monitoring, and even in some cases improving on these measurements and results.
As a result of this public tracking, the key doctor from the paper, Pronovost, was able pretty clearly to tell whether his process changes were having a positive or negative effect. He had lots of public data to draw from, and the incidence rate at any given hospital is large enough that we can start to make valid statistical judgments about the impact of our changes.
Contrast this with software and the differences in both area, and maturity, are quite telling. We don't have any standard measures of success/failure, we don't perform lots of root cause on adverse events, and we don't have public reporting of success and failure. So, we don't have a general body of knowledge that allows us to get better or at least measure how we're doing.
Maybe we ought to have something like that? I wrote about this last year when saying that we ought to have some sort of NTSB for security, or at least for security breaches. Maybe its time we start taking that more seriously?
Processes
I was also struck by one of Pronovost's comments about medicine that I think especially relevant to software security. When asked whether we'd get to the point that checklists are as common as a stethoscope for a Dr, he replied:
"At the current rate, it will never happen,” he said, as monitors beeped in the background. “The fundamental problem with the quality of American medicine is that we’ve failed to view delivery of health care as a science. The tasks of medical science fall into three buckets. One is understanding disease biology. One is finding effective therapies. And one is insuring those therapies are delivered effectively. That third bucket has been almost totally ignored by research funders, government, and academia. It’s viewed as the art of medicine. That’s a mistake, a huge mistake. And from a taxpayer’s perspective it’s outrageous.” We have a thirty-billion-dollar-a-year National Institutes of Health, he pointed out, which has been a remarkable powerhouse of discovery. But we have no billion-dollar National Institute of Health Care Delivery studying how best to incorporate those discoveries into daily practice.I was reminded of Gunnar's response to the Spaf piece - "Solving the Wrong Problems." I think Gunnar hit it on the head with his criticism of Spaf's piece, and I think the situation is quite similar to the one Pronovost finds in medicine.
For the most part we fail to treat the delivery/creation of software as a science. We do lots of research on languages, we do lots of work on theories of security, and then it all breaks down because we have people implementing the processes, and we don't spend any time on that. Well, at least not in measure to how much we spend on all sorts of other efforts that we don't measure, we aren't sure achieve results, etc.
We know lots about how to theoretically secure things, but we don't know a whole lot about how to get large software development organizations to produce consistently high quality/"secure" software. Heck, we don't even know how to do it if we aren't budget constrained, much less if we are.
To be sure, medicine hasn't solved this problem either, and they aren't dealing with a huge installed base :) They are better at measuring effectiveness, but again they are in a life/death world plus they have the added joy of strict liability. Operating under those conditions they do manage to settle on newer/better techniques pretty quickly, because they are tracking how they are doing, lives are on the line, and they are pretty strongly incented to get it right.
Wednesday, January 23, 2008
Mark Rasch Puts Me To Shame
Last Thursday I wrote a piece about the case of Sullivan v. Ritz (and Faulk). I put the word armchair in the title because I'm not a lawyer and so my analysis was both simplistic and rather brief.
Today Mark Rasch released a much longer article on this same subject, "Mother, May I." As usual, Mark gives an excellent explanation of the underlying legal topics - the relation of physical world common law notions and rules concerning trespass. I highly recommend you read Mark's article if you're interested in the intersection of computer security and the law.
Mark also points to an excellent paper by Orin Kerr, - CYBERCRIME’S SCOPE: INTERPRETING "ACCESS” AND “AUTHORIZATION” IN COMPUTER MISUSE STATUTES. I read this paper some time ago and I've been searching for it ever since to no avail. If you're not a lawyer you usually don't have access to the right search engines/tools to find these sorts of things. Kerr's article is also an excellent read if you're not happy with the analysis the Mark gives of the current law, or you understand the analysis and don't like that words like "access" and "authorization" aren't well defined in the statutes.
Today Mark Rasch released a much longer article on this same subject, "Mother, May I." As usual, Mark gives an excellent explanation of the underlying legal topics - the relation of physical world common law notions and rules concerning trespass. I highly recommend you read Mark's article if you're interested in the intersection of computer security and the law.
Mark also points to an excellent paper by Orin Kerr, - CYBERCRIME’S SCOPE: INTERPRETING "ACCESS” AND “AUTHORIZATION” IN COMPUTER MISUSE STATUTES. I read this paper some time ago and I've been searching for it ever since to no avail. If you're not a lawyer you usually don't have access to the right search engines/tools to find these sorts of things. Kerr's article is also an excellent read if you're not happy with the analysis the Mark gives of the current law, or you understand the analysis and don't like that words like "access" and "authorization" aren't well defined in the statutes.
Thursday, January 17, 2008
Armchair Legal Analysis of Sierra v. Ritz
You may have heard about the case of Sierra Corporate Design, Inc. v. David Ritz.
There has been lots of griping and complaining about the fact that doing zone transfers might be illegal. I thought I'd try to give the quick analysis of the case. I'm sure I'm missing a few things here and I'm not a lawyer, but I am a little tired of "hackers" complaining about their rights to do whatever they want being trampled... You can read the judgment here.
In this case David Ritz is being punished for performing unauthorized DNS zone transfers of Sierra Corporate Design's network.
The problem at the federal level is that the CFAA (Computer Fraud and Abuse Act). North Dakota's statute appears to have roughly the same language.
The CFAA has relatively consistently been interpreted so that "Accessing a computer without authorization" hinges on whether the owner of the computer wanted you to perform your action or didn't. The presence or absence of controls to prevent access being generally irrelevant. They have relied on the traditional definition of trespass and attempted to apply it to the electr0nic world.
In the physical world trespass is relatively easy to understand, police, etc. There are obviously corner cases where you can trespass onto unmarked land, not realize you're trespassing, etc. There is a lot of case law for these. At the same time though, if you see a house, you know it isn't your house, and you walk into it, you're trespassing whether or not they locked the door. It is quite clear that you weren't invited and not locking the door doesn't remove the rights of the home owner to prevent trespass.
In the electronic world for example it gets a lot murkier. If I mistype a URL into a tool and attempt to access someone's machine, its pretty clear from both intent and network traffic what was going on. At the same time though, let's say I send a ton of traffic at you, or I start fingerprinting your system. Intent is really the key question here.
Did I knowingly attempt to access your computer without authorization? What was my intent? It is generally the answers to these questions that would be at play in court.
In this specific case a DNS zone transfer isn't the sort of thing you mistakenly do. It isn't isn't the type of data that people generally try to get from other sites as part of browsing the net, etc. In general, and in this case its pretty apparent, you're trying to get data that you wouldn't ordinarily be expecting people to let out. Whether the DNS server was configured to prevent zone transfers isn't really the issue here.
Obviously where this gets tricky is determining whether this is like trespassing onto unmarked land, or walking into someone else's house when they had the door unlocked.
This isn't to say I necessarily agree with the decision, but there is a lot more nuance to this issue than I've seen posted.
There has been lots of griping and complaining about the fact that doing zone transfers might be illegal. I thought I'd try to give the quick analysis of the case. I'm sure I'm missing a few things here and I'm not a lawyer, but I am a little tired of "hackers" complaining about their rights to do whatever they want being trampled... You can read the judgment here.
In this case David Ritz is being punished for performing unauthorized DNS zone transfers of Sierra Corporate Design's network.
The problem at the federal level is that the CFAA (Computer Fraud and Abuse Act). North Dakota's statute appears to have roughly the same language.
The CFAA has relatively consistently been interpreted so that "Accessing a computer without authorization" hinges on whether the owner of the computer wanted you to perform your action or didn't. The presence or absence of controls to prevent access being generally irrelevant. They have relied on the traditional definition of trespass and attempted to apply it to the electr0nic world.
In the physical world trespass is relatively easy to understand, police, etc. There are obviously corner cases where you can trespass onto unmarked land, not realize you're trespassing, etc. There is a lot of case law for these. At the same time though, if you see a house, you know it isn't your house, and you walk into it, you're trespassing whether or not they locked the door. It is quite clear that you weren't invited and not locking the door doesn't remove the rights of the home owner to prevent trespass.
In the electronic world for example it gets a lot murkier. If I mistype a URL into a tool and attempt to access someone's machine, its pretty clear from both intent and network traffic what was going on. At the same time though, let's say I send a ton of traffic at you, or I start fingerprinting your system. Intent is really the key question here.
Did I knowingly attempt to access your computer without authorization? What was my intent? It is generally the answers to these questions that would be at play in court.
In this specific case a DNS zone transfer isn't the sort of thing you mistakenly do. It isn't isn't the type of data that people generally try to get from other sites as part of browsing the net, etc. In general, and in this case its pretty apparent, you're trying to get data that you wouldn't ordinarily be expecting people to let out. Whether the DNS server was configured to prevent zone transfers isn't really the issue here.
Obviously where this gets tricky is determining whether this is like trespassing onto unmarked land, or walking into someone else's house when they had the door unlocked.
This isn't to say I necessarily agree with the decision, but there is a lot more nuance to this issue than I've seen posted.
Wednesday, January 09, 2008
Another Strategy for Getting Started with Application Security
Gary McGraw posted a new article about strategies for getting started with application security and secure coding.
In it he lists 4 approaches for getting started with application security:
I had success with #4, but not using the tools we usually think of for bootstrapping a program, namely static analysis or testing tools.
When I took the position they had already settled on using Netegrity's Siteminder product for a common authentication and authorization scheme across all of the applications. I managed to get them to settle on doing a quasi-RBAC with Siteminder, using it almost as an
identity service as well.
Settling on one common high-quality authentication and authorization tool/framework had three effects:
Just one data point on leading with a tool that focused more on architecture and design than it did on finding defects.
In the end in order to fully implement the program we had to do developer training, build our own frameworks, perform risk assessments against applications, and fully incorporate testing.
The key to getting it started though was adopting a common approach to one area of security via a well-designed tool.
In it he lists 4 approaches for getting started with application security:
- Top-down framework
- Portfolio Risk
- Training First
- Lead with a tool
I had success with #4, but not using the tools we usually think of for bootstrapping a program, namely static analysis or testing tools.
When I took the position they had already settled on using Netegrity's Siteminder product for a common authentication and authorization scheme across all of the applications. I managed to get them to settle on doing a quasi-RBAC with Siteminder, using it almost as an
identity service as well.
Settling on one common high-quality authentication and authorization tool/framework had three effects:
- It removed these services from the realm of development. They just had to integrate with it, but didn't have to figure out all of the corner cases to password changes, etc. that so often crop up, and people mess up in homegrown approaches.
- It convinced developers to build clean interfaces in their code for things like authorization to call out externally and/or have the data provided to them in a standard fashion. By settling on RBAC it also helped a lot with role and permission modeling that did need to happen in the app.
- In a shop that usually wanted to do everything itself, it broke that cycle and people got used to not having to write everything from scratch.
Just one data point on leading with a tool that focused more on architecture and design than it did on finding defects.
In the end in order to fully implement the program we had to do developer training, build our own frameworks, perform risk assessments against applications, and fully incorporate testing.
The key to getting it started though was adopting a common approach to one area of security via a well-designed tool.
Tuesday, November 27, 2007
Some Comments on PayPal's Security Vulnerability Disclosure Policy
Thanks to the several places that have written about this policy in the last few days.
I was personally involved in crafting the policy and while I can't make commitments or speak officially for PayPal I thought I'd take a few minutes to explain our thinking on a few of the items in the policy.
First, a few points. PayPal didn't have a great system for reporting security issues until this new policy came out. Our goals in creating and publishing the policy were several:
A few specific notes are in order:
Chris Shiflett said:
From Don's post:
One final note on the statement - "Allow us reasonable time to respond to the issue before disclosing it publicly." We struggled over the wording on this more than any other element of the policy. It is a tricky business to get the right balance between early disclosure, our commitment to protect our customers and their data, and people's desire to know about the security of a given website or service. That said, we're committed to working with researchers when an issue is reported to us and we'll decide reasonable on a case-by-case basis.
We're hoping that this policy strikes a good balance between our desire for responsible disclosure, and not discouraging researchers from coming forward.
Again, I'm not a spokesperson for PayPal, so this post naturally represents my personal beliefs about this policy not a firm binding statement of company policy. That said - I welcome your comments.
I was personally involved in crafting the policy and while I can't make commitments or speak officially for PayPal I thought I'd take a few minutes to explain our thinking on a few of the items in the policy.
First, a few points. PayPal didn't have a great system for reporting security issues until this new policy came out. Our goals in creating and publishing the policy were several:
- Improve the security of our site by getting security issues disclosed to us responsibly.
- Create an easy mechanism for people to report a security vulnerability to us. We chose email since we figured security researchers would like it better than a form.
- Create incentives for disclosure and remove disincentives (threat of legal liability)
- Make clear our expectations in these areas, since this is a new and evolving area of security vulnerability disclosure with more than a little legal uncertainty.
- Through our policy - set a standard we hope others can follow.
A few specific notes are in order:
- We will revise the policy over time based on user feedback.
- We are serious in our commitment to rapidly address any discovered security issues with the site. Our language around reasonable timeframe is slightly vague because we don't want to over-promise on how quickly we can resolve an issue.
- We do expect to get back to researchers quickly with confirmation of a reported issue and tracking data on how we're doing resolving it.
Chris Shiflett said:
Since data can be anything, how do we know if we view data without authorization? Don't most people assume they're authorized to view something if they're allowed to view it? Does intent matter?While we don't want users to test the security of the PayPal site, should they do so they should be careful to minimize the disruption caused by their testing. If you start tinkering with URLs to see whether you can view certain data, do it between two accounts you control, don't try to view other people's data. There is a fine line between testing responsibly and irresponsibly and we're encouraging people to stay on the more responsible side of the line.
From Don's post:
I got a creepy feeling about actually trusting the statement. I will probably never attempt to test the security of PayPal’s site, but for those who do I would hate for the disclosure statement to change suddenly.As I said earlier, we do believe the policy is a work in progress. We will modify it from time to time to allay concerns, improve its effectiveness, etc. Our goal however is to encourage responsible disclosure. I hope that intent behind the policy is enough to allay people's potential fears.
One final note on the statement - "Allow us reasonable time to respond to the issue before disclosing it publicly." We struggled over the wording on this more than any other element of the policy. It is a tricky business to get the right balance between early disclosure, our commitment to protect our customers and their data, and people's desire to know about the security of a given website or service. That said, we're committed to working with researchers when an issue is reported to us and we'll decide reasonable on a case-by-case basis.
We're hoping that this policy strikes a good balance between our desire for responsible disclosure, and not discouraging researchers from coming forward.
Again, I'm not a spokesperson for PayPal, so this post naturally represents my personal beliefs about this policy not a firm binding statement of company policy. That said - I welcome your comments.
Poll: How Important is a POC When Getting Someone to Fix a Security Issue
Working on security inside a company that takes security seriously sometimes blinds me to how other people work and the challenges they face with getting security issues taken seriously.
I've noticed that lots of people that work as consultants and/or inside companies have to jump through lots of hoops to get a security vulnerability taken seriously.
In many cases I see people spending hours and hours crafting a working proof-of-concept exploit for a vulnerability and needing to actually demonstrate that exploit to get the issue taken seriously.
To understand this better, I set up a small poll to get some data about why people are needing to craft a working POC when demonstrating a vulnerability exists.
I've only ever had to do this once, and yet it seems that every time I read about a penetration test I see people spending lots of time crafting sample exploits rather than spending more time on finding more vulnerabilities, or fixing classes of vulnerabilities that are similar and offering solutions to those.
In my experience the only time a POC has been really useful is when I need to make sure that the person fixing the issue has the necessary information/tests to make sure they've closed the issue.
For those who do penetration tests (network or application) - how often do you feel that you need to create working POCs for exploits in order for the company's management to take it seriously?
I've noticed that lots of people that work as consultants and/or inside companies have to jump through lots of hoops to get a security vulnerability taken seriously.
In many cases I see people spending hours and hours crafting a working proof-of-concept exploit for a vulnerability and needing to actually demonstrate that exploit to get the issue taken seriously.
To understand this better, I set up a small poll to get some data about why people are needing to craft a working POC when demonstrating a vulnerability exists.
I've only ever had to do this once, and yet it seems that every time I read about a penetration test I see people spending lots of time crafting sample exploits rather than spending more time on finding more vulnerabilities, or fixing classes of vulnerabilities that are similar and offering solutions to those.
In my experience the only time a POC has been really useful is when I need to make sure that the person fixing the issue has the necessary information/tests to make sure they've closed the issue.
For those who do penetration tests (network or application) - how often do you feel that you need to create working POCs for exploits in order for the company's management to take it seriously?
Monday, November 26, 2007
New CAPTCHA Systems [HUMOR]
New grammar captcha system :) Quite funny if you ask me. Mostly a joke I suppose, but its Monday, so what the heck.
Tuesday, November 20, 2007
Data Leakage/Linkage Mystery
I have a mystery that came up tonight that I'm hoping someone can help me figure out.
I have a Yahoo! account that I hardly ever use anymore. I check it once every 6 months or so for email, but it remains unused otherwise. I do have my IM client Adium set to log into the account , but I don't ever use it for chatting. I also don't have the account generally associated with any of my other accounts, and it doesn't even have my real name on it.
Tonight I logged into yahoo-mail and checked the mailbox for said account. Delightfully I found several emails from Jayde.com to my unused yahoo mailbox, but with information about this blog.
Somehow I received mail to my unused yahoo account mentioning this blog.
I've never linked the two email addresses, I don't ever log into the yahoo email address, and haven't sent/received mail from it in forever.
The messages were dated back in March...
So, now I'm wondering how these two data items got linked.
I have a Yahoo! account that I hardly ever use anymore. I check it once every 6 months or so for email, but it remains unused otherwise. I do have my IM client Adium set to log into the account , but I don't ever use it for chatting. I also don't have the account generally associated with any of my other accounts, and it doesn't even have my real name on it.
Tonight I logged into yahoo-mail and checked the mailbox for said account. Delightfully I found several emails from Jayde.com to my unused yahoo mailbox, but with information about this blog.
Somehow I received mail to my unused yahoo account mentioning this blog.
I've never linked the two email addresses, I don't ever log into the yahoo email address, and haven't sent/received mail from it in forever.
The messages were dated back in March...
So, now I'm wondering how these two data items got linked.
- Advertising site that is buying data and/or access logs and linking disparate things together?
- Malware?
- Weird CSRF or some-such?
Subscribe to:
Posts (Atom)