tag:blogger.com,1999:blog-289566802024-03-13T05:20:56.365-07:00Security RetentiveAndy Steingrueblhttp://www.blogger.com/profile/07177656204885181542noreply@blogger.comBlogger129125tag:blogger.com,1999:blog-28956680.post-84916008656007669412012-08-07T12:08:00.002-07:002012-08-07T12:09:19.913-07:00Whose credentials are they? Mine, or yours?I've been spending a bunch of time lately thinking about usernames and passwords, and other types of credentials, and concept of "ownership".<br />
<br />
When you get a credit card, on the back it typically says something like - "Your card is issued and serviced by XYZ Bank pursuant to a license from Visa USA. Its use is subject to the terms of your Cardmember agreement".<br />
<br />
The credit card isn't really your property, it is the property of the bank, and you are just being allowed to use it for payments.<br />
<br />
When you sign up for an account online and create a username and password, that website has a decision to make:<br />
<br />
<ol>
<li>Those credentials belong to the website. They aren't the users property, they are the property of the website and their use, etc. is subject entirely to the terms-of-service of that website.</li>
<li>Those credentials belong to the user. Their use, when the user should use them, where else the user uses them, etc. are entirely in control of the customer.</li>
</ol>
<div>
Since users often (always?) reuse credentials across websites, etc. any individual websites attitude towards user credentials is dictated a lot about how they view user credentials.</div>
<div>
<br /></div>
<div>
A website that would like to pretend that credential reuse doesn't occur, or isn't its concern, might not protect them in the same way as a website that believes users maintain a sort of property interest in those credentials, might use them at other sites, and only the user themselves can make a decision about exactly how important those credentials are.</div>
<div>
<br /></div>
<div>
I'm not suggesting that one is right or wrong, but that I think this attitude towards credentials and who owns them can play a major role in how websites view their rights and obligations as it relates to their users.</div>Andy Steingrueblhttp://www.blogger.com/profile/07177656204885181542noreply@blogger.com0tag:blogger.com,1999:blog-28956680.post-11014608314100306852012-01-05T09:24:00.000-08:002012-01-05T09:24:07.754-08:00Why do people expect so much more from mobile platforms?Reading Veracode's recent post: <a href="http://www.veracode.com/blog/2012/01/mobile-security-android-vs-ios/">Mobile Security – Android vs. iOS</a>, which is an infographic comparing Android and iOS security, I'm left with a few questions, some of which I posted as a comment on their site.<br />
<br />
While the graphic does a good job of summarizing the notable differences between these two mobile platforms, I think it approaches the problem with a set of underlying assumptions:<br />
<br />
<br />
<ol>
<li>They assume that mobile platforms are fundamentally different that desktop platforms, in terms of what services/facilities/etc. they should provide.</li>
<li>The assume a different/new/enhanced level of responsibility by the mobile platform vendor for security and privacy than we've typically expected from platform providers.</li>
</ol>
<div>
For example, in the section on basic security capabilities they say - "Security and privacy aren't thoroughly tested and unauthorized access to sensitive data has already occurred in both the App store and Android Marketplace."</div>
<div>
<br /></div>
<div>
While this is undoubtedly true, the same can be said about the PC, the Mac, Linux, and any other software/OS platform that is "open" and doesn't try to control and lock down all third-party software distribution. </div>
<div>
<br /></div>
<div>
Perhaps the underlying argument is that new platforms should come with more security controls and the ecosystem should be more secure and guaranteed to be so by the platform provider. I haven't seen those promises made explicitly by mobile platform vendors though they do make it implicitly a lot of times. </div>
<div>
<br /></div>
<div>
Mostly what I see are people expecting much more from their mobile phone platform than they do from their desktop/laptop platform, and I'm not entirely sure why. Are there a few new threats? Sure. Location privacy, and the ability to perform actions that cost money. The latter not really being new though as malware that used people's modems to call premium phone numbers is a pretty old-school attack.</div>
<div>
<br /></div>
<div>
I'm all for platforms themselves becoming more secure over time. Most/all of the mobile platforms have made huge strides in this area over legacy desktop platforms. </div>
<div>
<br /></div>
<div>
What I don't quite understand is why folks are trying to hold mobile platforms to a higher standard for third-party software that it isn't clear they should be in the business of policing in the first place.</div>
<div>
<br /></div>
<div>
<br /></div>
<div>
<br /></div>Andy Steingrueblhttp://www.blogger.com/profile/07177656204885181542noreply@blogger.com6tag:blogger.com,1999:blog-28956680.post-50881372342547965842011-10-05T12:49:00.000-07:002011-10-05T13:01:19.012-07:00Malware prevalence != Infection ratesThere have been a number of presentations of late that have tried to document howend-users get infected with malware.<br /><br />Both Google's <a href="http://googleonlinesecurity.blogspot.com/2011/08/four-years-of-web-malware.html">malware report </a>and a recent <a href="http://www.csis.dk/en/csis/news/3321/">report</a> from CSIS purport to tell us how people get malware, based on how what malware they detect most frequently online, and what exploits it uses to get onto a client machine.<div><br /></div><div>Google goes so far as to say:</div><div><blockquote></blockquote><span class="Apple-style-span" style="color: rgb(51, 51, 51); font-family: Arial, sans-serif; font-size: 13px; background-color: rgb(255, 255, 255); ">Social engineering has increased in frequency significantly and is still rising. However, it’s important to keep this growth in perspective — sites that rely on social engineering comprise only 2% of all sites that distribute malware.</span></div><div><span class="Apple-style-span"><br /></span></div><div><div><br /></div><div>Google may well be right in the numbers they are reporting (I don't doubt their analysis) but this number tells us nothing about the frequency with which users encounter those malicious sites that employ social engineering to infect users.</div><div><br /></div><div>Percent of sites on the internet is not directly correlated to a sites popularity. As a quick thought experiment, what if facebook.com or twitter.com or even google.com were distributing social-engineering malware. They would represent a very small percent of total websites, and yet a tremendously large number of users.</div><div><br /></div><div>My hope is that companies such as FireEye can provide the world some details on exactly what exploits they are seeing with that frequency (have they already done that?), but even there the numbers in a corporate environment may not align that well with what a home-user sees, as many companies that deploy FireEye also do web-filtering that prevents users from ever visiting certain types of sites.</div><div><br /></div><div>The bottom line is that right now we can approximate what causes infections by looking at what the attackers are doing, but we don't truly know which of those attacks are having success and at what frequency.</div><div><br /></div><div>If someone has more data to provide on that, I'm all ears...</div><div><br /></div><div><br /></div></div>Andy Steingrueblhttp://www.blogger.com/profile/07177656204885181542noreply@blogger.com3tag:blogger.com,1999:blog-28956680.post-29618127141454902342011-05-05T10:14:00.001-07:002011-05-05T10:17:06.616-07:00Combating CybercrimeCross-posting this to my personal blog as I'm sure some folks that see this, don't see the other blog: <a href="http://www.thesecuritypractice.com/">http://www.thesecuritypractice.com/</a><br /><br />We've just published a whitepaper titled <a href="http://bit.ly/mzQLAw"> "Combating Cybercrime: Principles, Policies, and Programs".</a><br /><br />You can read a quick summary at this <a href="http://bit.ly/kQh8dV">blog post</a>, or download and read the paper itself. While we don't believe we have all of the answers to combating crime online, we do believe we've presented a set of principles as well as several workable policy and technology options that will help make progress against this problem.<br /><br />Please do let us know your thoughts.<div><br />Thank you</div>Andy Steingrueblhttp://www.blogger.com/profile/07177656204885181542noreply@blogger.com0tag:blogger.com,1999:blog-28956680.post-91051163691728884692011-03-30T14:00:00.000-07:002011-03-30T14:03:25.765-07:00[Non-Security]Please Help Fight LeukemiaHello,<div><br /></div><div>I don't that often use my blog to talk about non-security topics but today I'm making an exception. Last April Leukemia became a very personal topic for me and my family. If you'd like to learn more, please check out: <a href="http://svmb.heros.llsevent.org/Elise">http://svmb.heros.llsevent.org/Elise</a></div><div><br /></div>Andy Steingrueblhttp://www.blogger.com/profile/07177656204885181542noreply@blogger.com1tag:blogger.com,1999:blog-28956680.post-88043311844546368832011-02-03T09:43:00.001-08:002011-02-03T09:53:42.290-08:00No Browser is an IslandJeremiah wrote today about web browsers and opt-in security. I think he gets it mostly right (and hey, he pointed at a paper I co-authored so I'm biased) but I think it also misses the mark a little.<div><br /></div><div>Once upon a time there were only two major web browsers, and their user bases were large enough, and users didn't switch, that they had outsized influence on exactly how the web worked. Users had very little choice.</div><div><br /></div><div>The situation we find ourselves in today is quite different. Users have multiple choices of web browser, especially at home, and are willing to switch to get what they want, or believe they want.</div><div><br /></div><div>The problem of improving the security of the web, and the security of web browsers, is one of user adoption. For certain classes of security bugs (preventing buffer overflows, etc) the security is mostly transparent to the user. It doesn't change their browsing experience at all. </div><div><br /></div><div>Unfortunately, many of the changes proposed by the web security community (myself included) have the potential to break large numbers of sites if deployed indiscriminately. </div><div><br /></div><div>Unless all browsers make changes at the same time, and make them mandatory, etc. with a mutual suicide pact, it can't and won't happen, because users will choose the tool that lets them view more websites, not one that keeps them safer, at least in the sort term. Some users will install a tool (Noscript) to keep themselves safer, not all will.</div><div><br /></div><div>The upshot is that we aren't going to get universal default security improvements overnight. They are going to continue to be opt-in for the near future, because as Dan Kaminsky is quite fond of saying - "you can't break the web".</div><div><br /></div><div>This isn't just a technical problem, it is also an economics problem. Without incentives by websites and users to opt-in to newer safer web browsers we are never going to solve this problem universally. Me -I'll be happy if we can at least develop some of the tools to keep us safer, and then let those who want to deploy them do so to keep themselves safer. That action will come from both security conscious sites, and users.</div><div><br /></div><div><br /></div>Andy Steingrueblhttp://www.blogger.com/profile/07177656204885181542noreply@blogger.com1tag:blogger.com,1999:blog-28956680.post-75945218884914179992010-12-29T09:56:00.001-08:002010-12-30T08:34:18.661-08:00Poll Time - What One Problem in Web Security Do You Want to Fix?<div><b><br /></b></div>It is poll time. Doing a little planning and trying to figure out what people view as the biggest architectural weaknesses on the web security wise. I'm mainly focused on things within HTTP and HTML/JS/CSS themselves, not things at the TLS layer.<div><br /></div><div>There is a small poll on the right hand side of the blog. If you have other ideas, pleas stick them in the comments. </div><div><br /></div><div>A few things I didn't include as I wasn't sure what to do with them:</div><div><ul><li>Fixing XSS. Change core web protocols/technologies to provide a much cleaner code/data separation. Maybe CSP does this well enough?</li><li>Fixing CA's and how they work. I consider this a related but separate problem.</li><li>Fixing CSRF. It could make the list and there are several options architecturally such as scope-cookies and/or the Origin header.</li></ul><div><div><b>[UPDATE-1]</b> - I'm interested in fixing to webservers, browsers, core protocols, etc. Not what individuals writing web apps should do to make their own apps more secure. So, for example, fixing Struts/Spring/etc. would be out of scope for this survey.</div></div></div><div><br /></div><div><b>[UPDATE-2</b>] - The item in the poll for improving authentication is partially about the HTTP protocol, but also about web browser UI, how auth data gets handled in the Chrome, etc. </div>Andy Steingrueblhttp://www.blogger.com/profile/07177656204885181542noreply@blogger.com5tag:blogger.com,1999:blog-28956680.post-91849916383121655572010-11-21T18:27:00.000-08:002010-11-21T18:36:37.569-08:00A quick clarification on HSTS (HTTP Strict Transport Security) policy on non-standard portsBeen having an interesting blog comment and twitter discussion with John Wilander.<div><br /></div><div>He wrote a <a href="http://appsandsecurity.blogspot.com/2010/11/strict-transport-security-in-struts-2.html">post</a> and <a href="http://twitter.com/#!/johnwilander/">some</a> <a href="http://twitter.com/#!/johnwilander/status/6463602567413760">tweets</a> and even filed a Mozilla <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=613645">bug</a> against the HSTS behavior in FF-4.</div><div><br /></div><div>I posted this to his blog, but thought I'd post it here too.</div><div><br /></div><div>Essentially there is some confusion about how HSTS works, and how it rewrites ports. The spec is a little vague (or earlier versions were, I think <a href="http://identitymeme.org/">=JeffH</a> fixed it, and if not, I know for a fact he has it on his To-Do list) on what to do about port rewriting.</div><div><br /></div><div>A few points.</div><div><br /></div><div>1. HTTP URIs that don't have an explicit port number default to port-80.</div><div>2. HTTPS URIs that don't have an explicit port number default to port-443.</div><div>3. A URI can specify a non-default port, and the browser will use the port specified.</div><div><br /></div><div>When we looked at this in determining the proper behavior of the spec, we had a few decisions to make.</div><div><br /></div><div>HSTS can transparently convert HTTP to HTTPS, and automatically switch from the well-known port-80 to 443 when enforcing TLS.<br /><br />When the URI has a non-standard port, there are only two "reasonable" behaviors:<br /><br />1. Don't force TLS, and access the port with HTTP<br />2. Use the specified port in the URI, but force-TLS on that socket connection<br /><br />An unreasonable behavior would be:</div><div><br />3. Use some random port calculation scheme and convert the chosen port to another port via some non-standard port number manipulation/rewrite scheme.<br /><br />We chose #2 as the desired behavior, because #1 leaks cookies which we specifically don't want to do, and #3 is right out because there is no well-known way to calculate the TLS port that corresponds to any other random "high port".</div><div><br /></div><div>The only way to guarantee that a host is protected on all ports, and a browser refuses to use a cleartext protocol with HTTP, we have to force TLS upgrade on all non-std ports.</div><div><br /></div><div>I'll go re-read the spec, and if this isn't clear, will make sure we address it in a new draft.</div>Andy Steingrueblhttp://www.blogger.com/profile/07177656204885181542noreply@blogger.com3tag:blogger.com,1999:blog-28956680.post-71798032772519010572010-05-11T07:44:00.001-07:002010-10-28T16:05:13.337-07:00Presenting at 2010 Web 2.0 Security and Privacy WorkshopPresenting a position paper with my colleague <a href="http://identitymeme.org/">Jeff Hodges</a>.<div><br /></div><div><span class="Apple-style-span" style="font-family: Univers, 'Helvetica Neue', Helvetica, Arial, sans-serif; font-size: medium; border-collapse: collapse; line-height: 20px; "><p style="margin-top: 0.25em; margin-bottom: 1em; "><a href="http://w2spconf.com/2010/papers/p11.pdf" style="color: rgb(0, 165, 255); ">The Need for Coherent Web Security Policy Framework(s)</a></p><p style="margin-top: 0.25em; margin-bottom: 1em; ">More details on the workshop at: <span class="Apple-style-span" style="border-collapse: separate; font-family: Georgia, serif; line-height: normal; font-size: 16px; "><a href="http://w2spconf.com/2010/">http://w2spconf.com/2010/</a></span></p><p style="margin-top: 0.25em; margin-bottom: 1em; "><br /></p></span></div>Andy Steingrueblhttp://www.blogger.com/profile/07177656204885181542noreply@blogger.com1tag:blogger.com,1999:blog-28956680.post-59012172358500140532010-04-06T15:47:00.000-07:002010-04-06T16:09:37.459-07:00New Role - Internet Standards and GovernanceNot that I expect everyone to watch my job title changes, but I recently made one and figured I'd go ahead and blog about what I'm working on these days.<div><br />For the past 2+ years I've been running the Secure Development Program at PayPal. This involves rolling out secure development methodology, tools, training, etc. I've also been doing a fair bit of internal product management for application security features. This was needless to say more than a fulltime job.</div><div><br />In my spare time (yeah right) I've been doing some work on internet governance. Things like working on web browser security policies and frameworks (<a href="http://www.thesecuritypractice.com/the_security_practice/2009/12/new-rev-of-strict-transport-security-sts-specification.html">Strict-Transport-Security </a>was part of that work) as well as broader internet-governance things like working with ICANN, <a href="http://www.ntia.doc.gov/dns/comments/comment023.pdf">advocating</a> through multiple forums for DNSSEC deployment, etc.</div><div><br />I recently decided that I needed to focus more and despite loving the SDL work I was doing, my overall plans and interests align even more with the internet standards and governance work than they do with SDL work.</div><div><br />So, as of this April I'm now heading up a team responsible for internet standards (mostly security) and internet governance. We'll be focusing a lot on the same types of things above, along with some other things. When asked what my job is I say - "I'm trying to make the internet safer."<br /><br /></div><div>As I wrote the other day - I wouldn't have taken on this new role if I weren't at heart either an optimist, hopelessly naive, or crazy. Only time will tell.<br /><br /></div><div>I'll be doing most of my posting either here on this blog, or on the one for our broader team over at <a href="http://www.thesecuritypractice.com/">http://www.thesecuritypractice.com.</a></div>Andy Steingrueblhttp://www.blogger.com/profile/07177656204885181542noreply@blogger.com0tag:blogger.com,1999:blog-28956680.post-32673447026873365672010-04-02T15:07:00.000-07:002010-04-02T15:10:33.783-07:00More on - freedom to tinkerBen Adida has an interesting blog <a href="http://benlog.com/articles/2010/04/02/the-accidental-tinkerer-unexpected-lock-in-and-fatherhood/">post </a>up about freedom to tinker and the iPad. I wrote a comment there in response that I'll post here in case I want to update it further.<br /><br />Ben laments some of the lack of tinkering/hacking capability in the iPad. I said:<br /><br />Cars are an interesting comparison technology. It used to be that *everyone* had to be a car tinkerer because they just didn't run right and keep running by themselves. You learned how to do maintenance, how to tweak, adjust, etc. And then we put in catalytic converters and to make sure you guaranteed emissions we stopped you from mucking around with timing, etc. We got rid of carburetors and replaced them with fuel injectors. We got rid of timing belts and camshafts and went to electronic valves. We removed a lot of the tinkerable parts. We killed a lot of the innovation in that space. We also reduced auto pollution a ton and made cars safer. <br /><br />Was it a good tradeoff? Are there fewer auto mechanics than there used to be because of this? Have we lost something fundamental to our culture and society? <br /><br />I don't know the answer.Andy Steingrueblhttp://www.blogger.com/profile/07177656204885181542noreply@blogger.com0tag:blogger.com,1999:blog-28956680.post-10021471067222534072010-03-16T09:20:00.000-07:002010-03-16T09:36:19.058-07:00Bank Fraud Detection Must Balance False Positives and False NegativesKrebs <a href="http://www.krebsonsecurity.com/2010/03/ebanking-victim-take-a-number/">posted </a>this morning about commercial bank customers again and <a href="http://1raindrop.typepad.com/1_raindrop/2010/03/hilarious-and-sad.html">Gunnar </a>also picked up on the theme.<br /><br />In Krebs piece he quotes the customer saying:<br /><br /><blockquote>"When I first talked to the bank, my question to them was, ‘We’ve always done the same five payroll transactions a month, this was outside the norm, so why didn’t you flag them?’” Diaz recalled. “They told me because [the thieves] answered the secret questions correctly and because the amount was under $10,000 and their daily limit, they let it go just based on the amount.”</blockquote><br />I totally understand that sentiment, but I'd also like to offer up a counter. The negative customer experience that goes along with a denied transaction, and our expectation that our bank should follow our instructions and not second guess us.<br /><br />A few examples are in order. From the "<a href="http://www.mercurynews.com/action-line/ci_14647686">Mercury News Action Line</a>" this week:<br /><br /><blockquote>Q: For months, Wells Fargo has been harassing me by putting fraud alerts on routine credit card transactions. Wells Fargo declines the transactions outright and blocks my credit cards.</blockquote><br /><br />What do we tell this customer when the bank's fraud blocking is being too ambitious?<br /><br />Or, how about the wonderful story that Gunnar himself <a href="http://1raindrop.typepad.com/1_raindrop/2007/01/integrated_tran.html">recounts </a>about the ATM network and its distributed nature, and how it just works, and did for Robert Morris Sr.<br /><blockquote>There is a triple boundary in this town that I was in between Norway, Finland and Russia.But what I did there, was, I had a card about wallet size, I stuck it into a machine, I punched in four digits, and it gave me about 2,000 krone, whatever the hell that is.</blockquote><br />So, a guy who isn't usually in Norway puts his ATM card into a machine, and it just works. The bank doesn't throw up a frau alert and say - "WTF, you don't usually take money out from Norway, this must be fraud." It says - "You have the ATM card and passed my security test by knowing the PIN, I'm going to give you money."<br /><br />My point is that we can't celebrate the ability of an American to take money out of an ATM in Norway and at the same time say that banks should block all transactions out of the ordinary.<p></p>Where we strike the balance between false positives and false negatives, and who has the liability for that choice is of course an interesting question, but a <a href="http://www.toonpool.com/cartoons/One%20size%20fits%20all_52138">one-size-fits-all</a> solution is going to be ugly.<br /><p></p>Andy Steingrueblhttp://www.blogger.com/profile/07177656204885181542noreply@blogger.com0tag:blogger.com,1999:blog-28956680.post-82301884766158501372009-12-28T15:55:00.001-08:002009-12-28T16:01:32.275-08:00Security Disclosure Policies That Remove Chilling EffectsAs I have discussed <a href="http://securityretentive.blogspot.com/2007/11/some-comments-on-paypals-security.html">before</a>, PayPal has <a href="https://www.paypal.com/us/cgi-bin/webscr?cmd=xpt/cps/securitycenter/general/ReportingSecurityIssues-outside">published </a>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.<br /><br />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:<br /><ul><li><a href="http://www.facebook.com/security#/security?v=app_6009294086">Facebook</a></li><li><a href="http://www.salesforce.com/company/disclosure.jsp">Salesforce</a></li></ul>If anyone knows of others, please let me know as I'd going to try to keep a running list.Andy Steingrueblhttp://www.blogger.com/profile/07177656204885181542noreply@blogger.com2tag:blogger.com,1999:blog-28956680.post-26093380379413859702009-12-18T15:05:00.000-08:002009-12-19T08:55:39.625-08:00Best Security Improvements in 2009?Taking a cue from Jeremiah's <a href="http://jeremiahgrossman.blogspot.com/2009/12/attention-security-researchers-submit.html">list</a> of new 2009 hacking techniques I thought I'd start a list of best improvements in security in 2009.<br /><br />So far I haven't come up with many substantial improvements, but I do have a starter list in no particular.<br />[Updated list based on Jeremiah's recommendations]<br /><ol><li>IE8 removed CSS expressions support</li><li>Rails now does output escaping by <a href="http://www.blogger.com/-%20http://weblog.rubyonrails.org/2009/10/12/what-s-new-in-edge-rails%203.%09STS%20Header">default</a>?</li><li>The new <a href="http://www.thesecuritypractice.com/the_security_practice/2009/12/strict-transport-security-presentation.html">STS header.</a></li><li>Firefox <a href="http://blog.mozilla.com/security/2009/10/13/mozilla-plugin-check-now-live/">checks </a>for updates to plugins</li><li>Mozilla Content Security Policy (<a href="http://blog.mozilla.com/security/2009/09/30/a-glimpse-into-the-future-of-browser-security/">CSP</a>)</li><li>Microsoft IE8 <a href="http://blogs.msdn.com/ie/archive/2009/01/27/ie8-security-part-vii-clickjacking-defenses.aspx">X-Frame-Options</a> anti-framing header<br /></li></ol><br />Your recommendations welcomed.Andy Steingrueblhttp://www.blogger.com/profile/07177656204885181542noreply@blogger.com5tag:blogger.com,1999:blog-28956680.post-85651645331906905612009-11-06T13:32:00.000-08:002009-11-06T13:42:32.600-08:00Announcing Strict-Transport-Security Support on www.paypal.comCross-posting from here from my <a href="http://www.thesecuritypractice.com/">other blog.</a><br /><br /><div class="entry-body"> <p>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, <a href="https://www.paypal.com/">https://www.paypal.com</a>.</p><br /></div>Continued <a href="http://www.thesecuritypractice.com/the_security_practice/2009/11/announcing-stricttransportsecurity-support-on-wwwpaypalcom.html">here</a>.....Andy Steingrueblhttp://www.blogger.com/profile/07177656204885181542noreply@blogger.com2tag:blogger.com,1999:blog-28956680.post-80545159033870680682009-10-23T15:02:00.000-07:002009-10-23T15:03:50.711-07:00Ethics and Security ResearchA post I hope will spur some discussion.<br /><br /><h3 class="entry-header"><a href="http://www.thesecuritypractice.com/the_security_practice/2009/10/an-ethical-framework-for-information-security-research.html">An ethical framework for information security research</a></h3>Andy Steingrueblhttp://www.blogger.com/profile/07177656204885181542noreply@blogger.com0tag:blogger.com,1999:blog-28956680.post-91897301755200800802009-10-08T07:42:00.000-07:002009-10-08T07:44:43.950-07:00OWASP Podcast is OnlineJim Manico interviewed me for the <a href="http://www.owasp.org/index.php/OWASP_Podcast#tab=Latest_Shows">OWASP Podcast series </a>and interview has now been posted. It was only the second podcast I've done, hopefully a good listen.<br /><br />Jim is great to work with btw, and very corporate PR conscious, so if he approaches you don't hesitate.Andy Steingrueblhttp://www.blogger.com/profile/07177656204885181542noreply@blogger.com0tag:blogger.com,1999:blog-28956680.post-89542733457440123822009-08-31T08:52:00.000-07:002009-08-31T09:06:46.930-07:00Judge officially Reverses Drew ConvictionIn 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.<br /><br />The judge has just recently overturned the conviction. Analysis and coverage from several places.<br /><ul><li><a href="http://blogs.wsj.com/law/2009/08/31/judge-officially-reverses-lori-drews-conviction/">Judge Officially Reverses Lori Drew’s Conviction</a></li><li><a href="http://volokh.com/posts/1251601962.shtml">Lori Drew Opinion Handed Down -- Judge Grants Motion To Dismiss on Vagueness Grounds</a></li><li><a href="http://volokh.com/posts/1251606425.shtml">Lori Drew Opinion</a></li></ul>Congratulations to one of her Lawyers, Orin Kerr, whose analysis of the Ninth Circuit's opinion I posted about last week.Andy Steingrueblhttp://www.blogger.com/profile/07177656204885181542noreply@blogger.com0tag:blogger.com,1999:blog-28956680.post-48222204000955315182009-08-28T10:32:00.000-07:002009-08-28T10:42:07.928-07:00Important Legal Decision Regarding the Fourth Amendment and the Plain View ExceptionSome 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 <a href="http://www.ca9.uscourts.gov/datastore/opinions/2009/08/26/05-10067eb.pdf">here</a>.<br /><br />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.<br /><br />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. <br /><br /><ul><li><a href="http://volokh.com/posts/1251325479.shtml">How the Ninth Circuit Tried To End Plain View for Computer Searches Without Ending Plain View for Computer Searches.<br /></a></li><li><a href="http://blogs.wsj.com/law/2009/08/28/beyond-a-rod-and-manram-plain-talk-on-the-plain-view-doctrine/">Beyond A-Rod and ManRam: Plain Talk on the ‘Plain View Doctrine </a></li></ul>The closest analogy I can draw is to the collection minimization requirements of wiretaps. The Ninth-Circuit is essentially imposing collection/search minimization rules on computer searches. Whether they have the authority to do so is an interesting constitutional question. <br /><br />Personally, I think this is a pretty good idea, we'll just have to see whether it passes muster constitutionally.Andy Steingrueblhttp://www.blogger.com/profile/07177656204885181542noreply@blogger.com0tag:blogger.com,1999:blog-28956680.post-16162969834457862932009-08-07T14:43:00.000-07:002009-08-07T14:44:20.119-07:00[Offtopic] Friday Fun - Sheep Art<embed src="http://c.brightcove.com/services/viewer/federated_f8/1137883380" bgcolor="#FFFFFF" flashVars="videoId=17075685001&playerId=1137883380&viewerSecureGatewayURL=https://console.brightcove.com/services/amfgateway&servicesURL=http://services.brightcove.com/services&cdnURL=http://admin.brightcove.com&domain=embed&autoStart=false&" base="http://admin.brightcove.com" name="flashObj" width="486" height="412" seamlesstabbing="false" type="application/x-shockwave-flash" swLiveConnect="true" pluginspage="http://www.macromedia.com/shockwave/download/index.cgi?P1_Prod_Version=ShockwaveFlash"></embed>Andy Steingrueblhttp://www.blogger.com/profile/07177656204885181542noreply@blogger.com0tag:blogger.com,1999:blog-28956680.post-27776008070036371622009-08-03T09:12:00.000-07:002009-08-03T09:18:12.908-07:00Extortion or Responsible Disclosure?I was just reading an article in Wired - <span style="font-weight: bold;">"</span><a href="http://www.wired.com/threatlevel/2009/08/electronic-locks-defeated/">Electronic High-Security Locks Easily Defeated at DefCon</a>".<br /><br />A quote from the article:<br /><blockquote>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.</blockquote><br />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?Andy Steingrueblhttp://www.blogger.com/profile/07177656204885181542noreply@blogger.com1tag:blogger.com,1999:blog-28956680.post-54142536880345167592009-08-03T08:25:00.000-07:002009-08-03T08:38:08.921-07:00Software Assumptions Lead to Preventable Errors<a href="http://www.thesecuritypractice.com/the_security_practice/papers/84-87.pdf">Here </a>is a paper I co-wrote with <a href="http://1raindrop.typepad.com/">Gunnar Peterson</a> 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.<br /><br />Note: This article is Copyright IEEE and was originally published in IEEE Security &<br />Privacy magazine, vol. 7, no. 4, 2009, pp. 84-87.<br /><br /><br /><p></p>Andy Steingrueblhttp://www.blogger.com/profile/07177656204885181542noreply@blogger.com0tag:blogger.com,1999:blog-28956680.post-65256217830556390522009-07-20T08:37:00.001-07:002009-07-21T09:05:09.127-07:00Tired of Security Nonsense About URL Shorteners Being DangerousAm I the only one who is tired of hearing of the security risks of URL shorteners? It looks like the complaint boils down to:<br /><br />- When using a shortened URL I can't tell what site I'm visiting before I go there<br /><br />Which I suppose leads to people thinking:<br /><br /> - If only I knew which site I was going to visit, somehow I could avoid security issues<br /><br />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?<br /><br />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.Andy Steingrueblhttp://www.blogger.com/profile/07177656204885181542noreply@blogger.com12tag:blogger.com,1999:blog-28956680.post-64073355072548612162009-06-14T11:57:00.000-07:002009-06-14T12:50:12.323-07:00Laws of Supply and Demand Still Apply in Software DevelopmentI read Gunnar's post the other day <span style="font-weight: bold;">"</span><a href="http://1raindrop.typepad.com/1_raindrop/2009/06/still-waiting-to-meet-a-developer-who-wants-to-write-insecure-code.html">Still Waiting to Meet a Developer Who Wants to Write Insecure Code</a>" 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.<br /><br />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.<br /><br />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.<br /><br />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.<br /><br />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.<br /><br />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. <br /><br />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. <br /><br />So, based on more demand than could be supplied with quality construction, we ended up with substandard product. <br /><br />Hopefully you see where I'm going with this as it relates to software supply and demand.<br /><br />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.<br /><br />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.<br /><br />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?<br /><br />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.Andy Steingrueblhttp://www.blogger.com/profile/07177656204885181542noreply@blogger.com2tag:blogger.com,1999:blog-28956680.post-87859871031394264642009-06-14T11:52:00.000-07:002009-06-14T11:55:56.967-07:00Headed SouthStarting 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.<br /><br />If you're also in Sydney or Auckland and have any good restaurant or tourist recommendations, I'm all ears.<br /><br />Or, if anyone wants to meet up, that's cool - drop me a line.Andy Steingrueblhttp://www.blogger.com/profile/07177656204885181542noreply@blogger.com0