As I have discussed before, PayPal has published a vulnerability disclosure policy that attempts to remove chilling effects for researchers wishing to responsibly disclose a security vulnerability. Until today I thought that PayPal and Microsoft were alone in having policies that explicitly gave security waivers to security researchers who practiced responsible disclosure.
I was informed of one, and discovered another example of a similar policy and I'm proud to say there are now several more policies like PayPal's:
If anyone knows of others, please let me know as I'd going to try to keep a running list.
Monday, December 28, 2009
Friday, December 18, 2009
Best Security Improvements in 2009?
Taking a cue from Jeremiah's list of new 2009 hacking techniques I thought I'd start a list of best improvements in security in 2009.
So far I haven't come up with many substantial improvements, but I do have a starter list in no particular.
[Updated list based on Jeremiah's recommendations]
Your recommendations welcomed.
So far I haven't come up with many substantial improvements, but I do have a starter list in no particular.
[Updated list based on Jeremiah's recommendations]
- IE8 removed CSS expressions support
- Rails now does output escaping by default?
- The new STS header.
- Firefox checks for updates to plugins
- Mozilla Content Security Policy (CSP)
- Microsoft IE8 X-Frame-Options anti-framing header
Your recommendations welcomed.
Friday, November 06, 2009
Announcing Strict-Transport-Security Support on www.paypal.com
Cross-posting from here from my other blog.
Continued here.....
I'm pleased to announce that PayPal is the first major internet site to implement the draft Strict-Transport-Security standard. As of Friday November 6th, 2009 PayPal is supporting the Strict-Transport-Security (STS) mode on our main website, https://www.paypal.com.
Friday, October 23, 2009
Thursday, October 08, 2009
OWASP Podcast is Online
Jim Manico interviewed me for the OWASP Podcast series and interview has now been posted. It was only the second podcast I've done, hopefully a good listen.
Jim is great to work with btw, and very corporate PR conscious, so if he approaches you don't hesitate.
Jim is great to work with btw, and very corporate PR conscious, so if he approaches you don't hesitate.
Monday, August 31, 2009
Judge officially Reverses Drew Conviction
In case you weren't following the Lori crew case she had been convicted of of misdemeanor for violating the Computer Fraud and Abuse Act (CFAA) by violating the terms of service of MySpace when she created her account.
The judge has just recently overturned the conviction. Analysis and coverage from several places.
Congratulations to one of her Lawyers, Orin Kerr, whose analysis of the Ninth Circuit's opinion I posted about last week.
The judge has just recently overturned the conviction. Analysis and coverage from several places.
Congratulations to one of her Lawyers, Orin Kerr, whose analysis of the Ninth Circuit's opinion I posted about last week.
Friday, August 28, 2009
Important Legal Decision Regarding the Fourth Amendment and the Plain View Exception
Some interesting discussion this week of a case recently decided in the Ninth Circuit. The case is "United States v Comprehensive Drug Testing". The decision is here.
Essentially the Ninth circuit is trying to proactively eliminate the plain view exception to warrant requirements under the fourth amendment when applied to computer searches.
I can't do the decision justice or put it in context. I recommend reading the following posts if you're interested in learning more. Some excellent discussion topics on the first blog post below.
Personally, I think this is a pretty good idea, we'll just have to see whether it passes muster constitutionally.
Essentially the Ninth circuit is trying to proactively eliminate the plain view exception to warrant requirements under the fourth amendment when applied to computer searches.
I can't do the decision justice or put it in context. I recommend reading the following posts if you're interested in learning more. Some excellent discussion topics on the first blog post below.
- How the Ninth Circuit Tried To End Plain View for Computer Searches Without Ending Plain View for Computer Searches.
- Beyond A-Rod and ManRam: Plain Talk on the ‘Plain View Doctrine
Personally, I think this is a pretty good idea, we'll just have to see whether it passes muster constitutionally.
Friday, August 07, 2009
Monday, August 03, 2009
Extortion or Responsible Disclosure?
I was just reading an article in Wired - "Electronic High-Security Locks Easily Defeated at DefCon".
A quote from the article:
It got me thinking - I've never heard of anyone doing this in the software world. For those who just have a website, I suppose this kind of threat isn't too big a deal. Most reasonable software vendors provide patching on an ongoing basis, but for those who don't, is anyone aware of any cases like this? A researcher requiring the vendor to promise to fix the product before they disclose the defect?
A quote from the article:
The lock makers say they can’t respond to the issues Tobias is raising until he tells them exactly how his attacks work. But before he’s willing to give them the details, Tobias has insisted the makers agree to fix the vulnerable locks retroactively with no cost to customers who have already purchased them. Something they refuse.
It got me thinking - I've never heard of anyone doing this in the software world. For those who just have a website, I suppose this kind of threat isn't too big a deal. Most reasonable software vendors provide patching on an ongoing basis, but for those who don't, is anyone aware of any cases like this? A researcher requiring the vendor to promise to fix the product before they disclose the defect?
Software Assumptions Lead to Preventable Errors
Here is a paper I co-wrote with Gunnar Peterson for the IEEE Security and Privacy Magazine. The title is pretty much the subject of the piece - how assumptions in the development process, and the associated lack of documentation and explicit statement of those assumptions, leads to preventable errors. We cover some techniques for documenting assumptions across a number of areas of the product lifecycle. Hopefully there are a few ideas here about formally documenting assumptions that you'll find useful.
Note: This article is Copyright IEEE and was originally published in IEEE Security &
Privacy magazine, vol. 7, no. 4, 2009, pp. 84-87.
Note: This article is Copyright IEEE and was originally published in IEEE Security &
Privacy magazine, vol. 7, no. 4, 2009, pp. 84-87.
Monday, July 20, 2009
Tired of Security Nonsense About URL Shorteners Being Dangerous
Am I the only one who is tired of hearing of the security risks of URL shorteners? It looks like the complaint boils down to:
- When using a shortened URL I can't tell what site I'm visiting before I go there
Which I suppose leads to people thinking:
- If only I knew which site I was going to visit, somehow I could avoid security issues
Who believes this anymore? Except for cases of a site that is clear NSFW, does anyone really believe anymore that if they see a URL before they click on it they can somehow divine whether it is likely malicious, has malware, etc? I mean, seriously?
I've seen no fewer than 5 blog posts this week about how to unshorten URLs for many of the popular URL shortening services. Give it a rest already. This isn't a big risk, threat, exposure, etc.
- When using a shortened URL I can't tell what site I'm visiting before I go there
Which I suppose leads to people thinking:
- If only I knew which site I was going to visit, somehow I could avoid security issues
Who believes this anymore? Except for cases of a site that is clear NSFW, does anyone really believe anymore that if they see a URL before they click on it they can somehow divine whether it is likely malicious, has malware, etc? I mean, seriously?
I've seen no fewer than 5 blog posts this week about how to unshorten URLs for many of the popular URL shortening services. Give it a rest already. This isn't a big risk, threat, exposure, etc.
Sunday, June 14, 2009
Laws of Supply and Demand Still Apply in Software Development
I read Gunnar's post the other day "Still Waiting to Meet a Developer Who Wants to Write Insecure Code" and he echoed something I've also been saying for a long time. In all of the training events I've ever done, times I've worked with developers, I've rarely met a developer who wants to actively write insecure code.
At the same time, there is a lot of bad code out there, and as much as we'd like to just blame managers, users, short timelines, that isn't necessarily the whole story.
Let's take a look at another industry - the home construction business. We see a vast difference in the quality of home construction based sometimes on how much the buyer is willing to pay, but also based on the supply and demand elements of qualified builders, and workers themselves. During regular non-boom times, the construction quality of homes while not excellent, is generally consistently "decent." Regulatory systems in many states (throw out the recent Texas fiascos if you will) are reasonably good at ensuring building code are followed, worker safety isn't compromised, and that the consumer ends up with a decent product.
Compare that to the construction of the last 5-7 years. Especially out here in California where the housing boom was vast, and demand for new housing, and consequently people to build them, far outstripped the supply of workers with experience and skills. The results in terms of quality are quite striking. Looking around at much new construction even when it was brand-new shoed all sorts of shortcuts. Baseboards glued on instead of done with nails. Cheap flooring put down onto uneven subflooring. Carpets coming loose because of shody installation. Paint jobs that don't match-up across a big wall. Showers that crack after 6 months because they we're installed level or with the right bracing. You name it, it happened. Shortcuts were the norm as housing was put up faster than reasoable but unqualified laborers.
How does this happen? The demand for new housing vastly outstripped the supply of those qualified to build them. It was a problem across the whole country, and conseuently we ended up with a lot of poorly bult houses.
Why didn't buyers enforce quality standards? Why didn't their inspectors? Again, a problem of supply and demand. A good home inspector has knowledge in most areas of home construction. They have the same skills you'd expect out of a general contractor. They understand electrical wiring standards, plumbing standards, general carpentry standards, etc. They are also experienced, and know where to sniff out the problems in a house they are inspecting.
So, what happened during the housing boom? We had a shortage of qualified home inspectors. In jurisdictions that don't mandate particular skills, we ended up with lots of unqualified housing inspectors. We probably ended up with a lot of kickbacks and bribery too, though admittedly I haven't seen any direct evidence for that, its just a guess. On the buyer front, we ended up with a bunch of first-time house buyers, who didn't know the kinds of problems to look for in a new home.
So, based on more demand than could be supplied with quality construction, we ended up with substandard product.
Hopefully you see where I'm going with this as it relates to software supply and demand.
In software our demand for software vastly outstrips the supply of qualified workers to build it. Software is worse though because at least in the housing case, in a normall regulated market, we have regulations and inspectors we have to satisfy. When the electrical inspector shows up on your job site, he (or she) is going to ask first for the plans and drawings. If you don't even have those, then you do't pass Go, and you don't collect your $200. You go right back to start, and have to get that fixed before you've even allowed to keep working, whether the work is being done right at all. If you don't have documentation, you're dead in the water. Sure the electrical work might be getting done right. And maybe you had the customer give you feedback on every outlet (agile?) but if you do't have documentation about what you're building, you stop what you're doing, and you on't get to start again until you do.
This isn't to say that I think the way we regulate buildings is the same way we should regulate software or computing. It is merely to point out that when you have a large mismatch between supply and demand, you're probably going to make sacrifices somewhere, and quality is one of those places.
So, maybe I've never met a develoepr who wanted to develop insecure software, but I guess that doesn't always imply that they wanted to, or were acpable of, developing quality software. In fact, given that much software is full of stupid and simple bugs, and that most development processes aren't structured to even make sure those don't slip through (make the subfloor level, make sure 2x4's are spaced right and at 90 degree angles) is it any surprise that we end up with software with lots of quality defects, with lots of security defects?
I remain optimistic that we can solve ths problem through training/education. But it isn't going to happen overnight, and it isn't going to happen until some of our attitudes about building software change from hiring amateur contractors who haven't ever built anything before, to hiring professionals who really know what they are doing.
At the same time, there is a lot of bad code out there, and as much as we'd like to just blame managers, users, short timelines, that isn't necessarily the whole story.
Let's take a look at another industry - the home construction business. We see a vast difference in the quality of home construction based sometimes on how much the buyer is willing to pay, but also based on the supply and demand elements of qualified builders, and workers themselves. During regular non-boom times, the construction quality of homes while not excellent, is generally consistently "decent." Regulatory systems in many states (throw out the recent Texas fiascos if you will) are reasonably good at ensuring building code are followed, worker safety isn't compromised, and that the consumer ends up with a decent product.
Compare that to the construction of the last 5-7 years. Especially out here in California where the housing boom was vast, and demand for new housing, and consequently people to build them, far outstripped the supply of workers with experience and skills. The results in terms of quality are quite striking. Looking around at much new construction even when it was brand-new shoed all sorts of shortcuts. Baseboards glued on instead of done with nails. Cheap flooring put down onto uneven subflooring. Carpets coming loose because of shody installation. Paint jobs that don't match-up across a big wall. Showers that crack after 6 months because they we're installed level or with the right bracing. You name it, it happened. Shortcuts were the norm as housing was put up faster than reasoable but unqualified laborers.
How does this happen? The demand for new housing vastly outstripped the supply of those qualified to build them. It was a problem across the whole country, and conseuently we ended up with a lot of poorly bult houses.
Why didn't buyers enforce quality standards? Why didn't their inspectors? Again, a problem of supply and demand. A good home inspector has knowledge in most areas of home construction. They have the same skills you'd expect out of a general contractor. They understand electrical wiring standards, plumbing standards, general carpentry standards, etc. They are also experienced, and know where to sniff out the problems in a house they are inspecting.
So, what happened during the housing boom? We had a shortage of qualified home inspectors. In jurisdictions that don't mandate particular skills, we ended up with lots of unqualified housing inspectors. We probably ended up with a lot of kickbacks and bribery too, though admittedly I haven't seen any direct evidence for that, its just a guess. On the buyer front, we ended up with a bunch of first-time house buyers, who didn't know the kinds of problems to look for in a new home.
So, based on more demand than could be supplied with quality construction, we ended up with substandard product.
Hopefully you see where I'm going with this as it relates to software supply and demand.
In software our demand for software vastly outstrips the supply of qualified workers to build it. Software is worse though because at least in the housing case, in a normall regulated market, we have regulations and inspectors we have to satisfy. When the electrical inspector shows up on your job site, he (or she) is going to ask first for the plans and drawings. If you don't even have those, then you do't pass Go, and you don't collect your $200. You go right back to start, and have to get that fixed before you've even allowed to keep working, whether the work is being done right at all. If you don't have documentation, you're dead in the water. Sure the electrical work might be getting done right. And maybe you had the customer give you feedback on every outlet (agile?) but if you do't have documentation about what you're building, you stop what you're doing, and you on't get to start again until you do.
This isn't to say that I think the way we regulate buildings is the same way we should regulate software or computing. It is merely to point out that when you have a large mismatch between supply and demand, you're probably going to make sacrifices somewhere, and quality is one of those places.
So, maybe I've never met a develoepr who wanted to develop insecure software, but I guess that doesn't always imply that they wanted to, or were acpable of, developing quality software. In fact, given that much software is full of stupid and simple bugs, and that most development processes aren't structured to even make sure those don't slip through (make the subfloor level, make sure 2x4's are spaced right and at 90 degree angles) is it any surprise that we end up with software with lots of quality defects, with lots of security defects?
I remain optimistic that we can solve ths problem through training/education. But it isn't going to happen overnight, and it isn't going to happen until some of our attitudes about building software change from hiring amateur contractors who haven't ever built anything before, to hiring professionals who really know what they are doing.
Headed South
Starting June 19th I'll be headed to the ICANN meeting in Sydney, and then also off for a little side trip to Auckland, NZ. Its all part of my plans to fix Internet governance, or at the least, stop things from getting worse.
If you're also in Sydney or Auckland and have any good restaurant or tourist recommendations, I'm all ears.
Or, if anyone wants to meet up, that's cool - drop me a line.
If you're also in Sydney or Auckland and have any good restaurant or tourist recommendations, I'm all ears.
Or, if anyone wants to meet up, that's cool - drop me a line.
Tuesday, June 09, 2009
Quick Thoughts on Safari-4 Final
A few quick thoughts on Safari-4 on my Macbook.
- Wow is this thing ridiculously fast. I'm usually a Firefox user and I'm not bogged down with a bunch of extensions/add-ons. Safari-4 feels about 2-3 times faster for 2 major apps - Gmail, and Google Reader.
- I still don't like the EV-Certificate support. I wish I had access to Apple's user testing of the EV-certificate user interface to see about the security usability factors. I don't find it nearly as obvious or useful as the interfaces in IE7, IE8, or Firefox-3. I don't know Chrome that well though, so who knows whether I like it better than than.
- The user interface seems a lot cleaner than the beta releases. Additionally, the hidden close x-marks on tabs that don't reveal until you highlight a tab is a nice feature.
- First impressions of the web-inspector is a lot like the little bit of Chrome I've played with - pretty sure this is a webkit feature. Very positively impressed so far.
So, other than a relatively dismal security track record, I may stick with Safari-4 for a few "trusted" sites just to get some better impressions.
Wednesday, June 03, 2009
A Little Shameless Self Promotion
I was recently interview by Gary McGraw for his Reality Check podcast. Check it out here -
http://www.cigital.com/realitycheck/
http://www.cigital.com/realitycheck/
Tuesday, June 02, 2009
Don't blame the judges
Two California court decisions came down last week that have people making all sorts of crazy claims about our legal system.
The first was the decision by the California Supreme Court affirming Proposition-8, the amendment/revision to the California Constitution.
The second was a decision by a California court ruling that the service offered by LifeLock is illegal under California law. An article on that decision is here.
In the Wired article about the LifeLock decision, we have the following passage:
The first was the decision by the California Supreme Court affirming Proposition-8, the amendment/revision to the California Constitution.
The second was a decision by a California court ruling that the service offered by LifeLock is illegal under California law. An article on that decision is here.
In the Wired article about the LifeLock decision, we have the following passage:
But Chris Hoofnagle, director of information privacy programs for the Berkeley Center for Law and Technology, says the ruling is a disappointment.
“The idea that we could some day see a market where we pay $10 a month to a company to opt us out of junk mail, to monitor our credit, to do all sorts of privacy-enhancing steps that we don’t have time to take … for that market to emerge, LifeLock’s business model and similar ones have to be legal,” Hoofnagle says.
I find this comment puzzling. All the judge did was interpret the law, he didn't make it. Nowhere does Mr. Hofnagle say the judges ruling was wrong on the facts, but he criticizes it anyway.
There was also rather a lot of this same type of commentary about the California Supreme Court's decision ruling that Proposition-8 is legal and will stand. Much of the complaining was along the lines of "but how can they take away our rights like that?" It isn't that I'm not fundamentally sympathetic to this position, but like it or not, the California constitution is a complete mess, the direct democracy system we have is a complete mess, and it all needs reworking.
This all points me to a couple of conclusions.
- If you're not winning under the current rules of the game, change the rules. This can be through getting a law passed, or even through amending the constitution.
- The California direct democracy experiment has gone horrible wrong, and its time to write a new constitution that eliminates this nonsense.
- Richard Friedlander had it right in this perspective piece on KQED.
And lastly, all of this complaining about judges reminds me of a famous Richard J. Daley quote, which I'll tweak here for my own purpose:
The Judges aren't here to cause disorder, they're here to preserve disorder.
Friday, May 29, 2009
Information Overload Syndrome
A nice little video from Xerox about a new neurological disorder :)
http://www.xerox.com/information-overload/enus.html
http://www.xerox.com/information-overload/enus.html
Tuesday, February 24, 2009
Important Ruling on 5th Amendment Case Involving Handling Over Encryption keys to Government
Since I know I won't do it the justice it deserves, please check out this post on the Volokh Conspiracy blog.
Quick summary - the user doesn't have to hand over the keys, but most provide decrypted contents of a hard-drive.
Quick summary - the user doesn't have to hand over the keys, but most provide decrypted contents of a hard-drive.
Thursday, February 19, 2009
What's Old is New Again
What do you call a 14+ year old vulnerability? Sloppy, ridiculous? Not sure....
FreeBSD was just hit by essentially the same bug that was present in a large number of Unix variants back in 1995.
The original vulnerability is here:
CERT® Advisory CA-1995-14 Telnetd Environment Vulnerability
The vulnerability allows a remote user to specify Unix environment variables to the the target system. If they override an environment variable such as LD_LIBRARY_PATH or LD_PRELOAD then they can override the behavior of programs that telnetd calls, such as /bin/login.
Looks like the FreeBSD guys just had a recurrence of almost exactly the same vuln.... Interesting to say the least.
FreeBSD-SA-09:05.telnetd
FreeBSD was just hit by essentially the same bug that was present in a large number of Unix variants back in 1995.
The original vulnerability is here:
CERT® Advisory CA-1995-14 Telnetd Environment Vulnerability
The vulnerability allows a remote user to specify Unix environment variables to the the target system. If they override an environment variable such as LD_LIBRARY_PATH or LD_PRELOAD then they can override the behavior of programs that telnetd calls, such as /bin/login.
Looks like the FreeBSD guys just had a recurrence of almost exactly the same vuln.... Interesting to say the least.
FreeBSD-SA-09:05.telnetd
Friday, February 13, 2009
Job Openings
We're hiring some internal application and project security consultants and a security manager. I'll update this post with a link when I get one I can put up as a URL (silly brassring) but if you go to:
https://www.paypal.com/html/paypal_jobs.html
you can search PayPal jobs with a keyword of "information security" to find the job descriptions.
Update: Here are some easily clickable links:
Manager, Information Security - Phoenix
Principal Information Security Engineer - Phoenix
Principal Information Security Engineer - San Jose
https://www.paypal.com/html/paypal_jobs.html
you can search PayPal jobs with a keyword of "information security" to find the job descriptions.
Update: Here are some easily clickable links:
Manager, Information Security - Phoenix
Principal Information Security Engineer - Phoenix
Principal Information Security Engineer - San Jose
Thursday, January 29, 2009
Quick personal Plug - I'm Speaking at SD West
A quick personal plug that I'm speaking at SD West on Friday March 13th. I'm co-presenting with Brad Hill and Scott Stender of iSec Partners.
Our talk title is "Managing a Software Development Security Program: Tactical Advice for the First 100 Days"
There has been plenty of discussion in forums such as WASC, OWASP, and the SC-L list about how to better evangelize secure development to the broad development community. Having a dedicated security track at a developer conference is a good step in that direction.
Our talk title is "Managing a Software Development Security Program: Tactical Advice for the First 100 Days"
There has been plenty of discussion in forums such as WASC, OWASP, and the SC-L list about how to better evangelize secure development to the broad development community. Having a dedicated security track at a developer conference is a good step in that direction.
Subscribe to:
Posts (Atom)