Not Obvious |
Intended to be Interesting, Intriguing & Insightful. Most Likely Mundane. |
I pulled out the (to me) relevant fields of the HHS "Breaches Affecting 500 or More Individuals" from the HHS breach site and posted it to Google Docs in the event folks would like to work with more structured data. I removed the institution and normalized it to State-level and removed the "associated party" field.
If folks want the other fields, I'll add them. Just ping me.
In the event you don't also follow the personal blog, I've switched ecosystems and abandoned my iPhone in favor of an Android mobile device (the HTC Incredible). While I may continue to tinker in iPhone OS development, I'm diving into Android 2 development in the little free time I have and picked up Professional Android 2 Application Development (Wrox Programmer to Programmer)
While I was enjoying a freshly made americano this morning, I started to peruse the near-boilerplate first few chapters when I came across the following precious nugget:
If you have images disabled, the text reads:
"For reasons of clarity and simplicity, many of the examples in this book take a fairly relaxed approach to security. When you're creating your own applications, particularly ones you plan to distribute, this is an area that should not be overlooked."
I posted a quick tweet about it, but felt the need to expand upon it in a post.
For starters, I find it difficult to even continue reading the material given that I would expect a book about "professional" development techniques to absolutely include security concepts throughout the topics being presented - even at the "Hello, world!"-level examples. Given the current state of digital security and privacy, I believe it to be highly irresponsible by the publisher of the book (Wrox) to release a title such as this without security being baked into the finished product. I would not be as critical if the title was "Just Checking Out Android 2 SDK Basics". Adding the word "professional" should mean that it provides all the fundamental tools and techniques to make solid & secure Android apps.
While I have yet to progress further into the text, if it does not thoroughly cover at least the need for comprehensive input validation and local and in-transit encryption techniques, I would highly recommend budding Android programmers to avoid this book and find a forum where you can learn the ins-and-outs of this SDK with a security hat firmly in place. The Android platform puts too much power into the hands of the applications to not code responsibly.
Take a side-step over to Rugged Software site and make a promise to yourself - and your users/customers - to stay true the manifesto and carve out a moment or two to review some core security concerns on the Android platform from ReadWriteWeb's Sarah Perez.
A recent PCWorld article by Ellen Messmer on the topic of browser cache-poisoning (as discussed by Mike Kershaw) led me to pondering a "solution" to the problem
"What is the problem?", you ask? To re-state it as simply as possible, when you jump on a public wireless network, anything you do over that network can be - at a minimum - captured and viewed by miscreants intent on prying into your affairs and, perhaps, absconding with some of your secrets. Kershaw's remarks pointed out that these malcontents can also do far worse and actually inject their own data into, say, your web-browsing activities. While such activity has many negative possibilities, Mike focused on one called "cache poisoning".
Whenever you visit a web site, your browser - unless you have specifically configured it not to - will attempt to cache (store) anything it can to help speed up your browsing experience and reduce bandwidth usage. This cache can be "poisoned" by an attacker injecting his/her own content into, say a javascript or css file and modifying the server responses to indicate that your browser should not bother trying to re-get those resources for a very long time. This will have the effect of your browser pulling the content from your local cache the next time it is asked for and will then activate the malicious bits along with the expected payload (so you think nothing is wrong).
Apart from always running with the cache off, you can clear the cache manually after you disconnect from a public access point. Most people will not know how to do the former (or just not want to do it) and - for the latter - I would ask you when was the last time you cleared your cache...at all? If you have cleared it, the reason was probably to fix a problem or clear up a page rendering issue.
My "solution" entails writing a small Windows service or OS X event watcher that:
I've already built the framework for both the Windows service and an OS X process and plan to post both the code and binaries as soon as I get them tied up in a nice, neat bow. However, I wanted to point out some of the complexities involved while they are fresh on my mind.
Focusing on OS X, the default browser - Safari - stores cached data in a sqlite database in ~/Library/Caches/com.apple.Safari/Cache.db. The schema is very basic and the SQL to remove all elements after a given TIMESTAMP is trivial. But, I would wager that most intrepid readers are not aware that any app that makes use of WebKit will get their own Cache.db. With a browser-to-app tool such as Fluid, this means each created app will have its own cache database (and be vulnerable to the poisoning).
Extending this a bit further, many users will have multiple browsers installed (Chrome, Firefox, Opera, etc). Each has their own method of dealing with web caches, and there really is no way to be confident which ones should be cleared without tracking application usage as well. This is also true on the Windows platform and made even a bit worse by the fact that you can customize where IE and other browsers store their cached data (on almost any platform).
It turns out this is one case where the Windows .NET API trumps OS X/Cocoa in that I can easily watch for WLAN adapter disassociation events and then act upon them. On OS X, it takes a bit more work arrive at the disassociation conclusion, but - once you have the event - the cleaning process code is very similar.
As the article points out:
The few defenses Kershaw suggested were continuously manually clearing the cache, or using private-browser mode. "Who knows how to clear the browser cache in an iPhone?" he asked.
I thought of also adding an option to prompt the user to switch to "private mode" browsing when the program detects association with an unknown or public access point. If you want to know how to clear the Mobile Safari cache, just follow Apple's directions.
I will (hopefully) have some time to finish up a rough beta version of each service and get it out for review. In the interim, I would love to hear thoughts on the approaches and suggestions for new/alternate ones.
I really do not want to give Adobe any more publicity in their Flash campaign, but felt compelled to blog-respond to Dave McAllister's "Following the open trail" post on his Open at Adobe blog.
Flash is not open.
Dave takes a shot at groups like the W3C, whom I'll focus on for part of this bit. No standard is "perfect", but standards themselves benefit greatly from a decent-sized, diverse, unbiased (in the generic sense of the term...we all have biases) collection of individuals. If this were not the case, XML, SOAP would have been a complete failure and HTML 5 & CSS 3 would not embraced by so many designers and high profile sites. Even if we move into IETF territory, what would OAuth, IMAP or our beloved RFC 2616 (HTTP :-) look like if it were all controlled by one business with it's own agenda?
I don't need closed tools to build web sites, craft data repositories or design code to access web services. I can use (if I had any graphic or design talent) thoughtfully-debated, cross-platform markup to build incredibly useful services that are accessible from practically any device. And I can pass credentials, check my e-mail and surf the internet to dribble like this post knowing that Very Smart People have discussed the efficacy of each protocol.
Given that the target audience for Dave's post were those that are not exactly Flash proponents, I do find it semi-amusing that he did not bother to ensure the availabity of an HTML 5 compatible YouTube page for the "Open at Adobe" link (or that it did not link directly to an HTML 5 representation).
With regard to open sourcing the Flash player, I'm not sure what that would really buy the "community". Publishing the Flash SWF, RTMP & other file formats does not make Flash "open". Microsoft published their Office XML file formats with the intent to keep you locked in to their products. Not exactly a compelling argument. Furthermore, if they were truly being honest about the open source Player argument, they could take the route of Paint.NET and utilize creative licensing for some of the code and not release other components that would be in violation of their contractual obligations.
I will admit that the list of truly open source frameworks is accurate and should be lauded, even though the ultimate destination is the Flash platform for most of them. It should be ironic to all (except for, perhaps, Adobe staff) that they have built reliance on WebKit: the open source rendering engine that powers Safari, Chrome and a few other browsers and apps.
Flash is not and will not be "open". Adobe wants you feeding from their trough and buying their expensive tools for as long as possible. It is no different (except for the fact they made versions for multiple platforms) than Microsoft ActiveX or browser-specific tags (how many of you are in an enteprise where internal apps just do not work under Gecko- or WebKit-based browsers?). It is this same lack of openness, combined with the creativity, ingenuity and collaboration of countless smart folks on knock-down-drag-out standards bodies that will ultimately mean the end of Flash.
Right on the heels of my Poderosa post comes another handy SSH++ connection tool: Terminals.
Rob Chartier has a good breakdown of some of the connection types Terminals supports and tools that it has built in (that is from version 1.6...the most current as of this post is 1.8), plus a ton of screen shots.
If you are a fan of the tree-view-on-the-left and tabbed-pane-on-the-right presentation style then this will be heaven for you. I just appreciate it since it has RDP, VNC, VMRC, SSH, HTTP/S + many more protocols (including Windows 2008 remote console access) all in one interface (with robust configuration options for each) and has integrated tools such as ping (with graphs), traceroute, whois and internal system information.
All connection tabs can be made into full-screen entities and it even appears to support capture output to Flickr (cannot verify that until later). You can even save your connections as a group to re-engage in one fell swoop later.
Like Poderosa, Terminals is free and open source (download link for source). While it may be a tad unpolished, it is a solid addition to my Windows toolbox.
Anyone who needs to ssh to or script scp copies from Windows to *nix hosts knows about putty. It is practically the de-facto standard since it works flawlessly (insofar as a software program can be flawless) and is not just free to use, but is also open source.
While the individual programs provide high-utility, it does not meet everyone's needs. In the past, I have tended to use Xshell from NetSarang when connecting to my Linux, Solaris, FreeBSD and OS X hosts from my Windows boxes, but haven't kept up with the license purchases and have defaulted to putty ever since, all the while missing my tabbed terminal window.
Enter: Poderosa. Since it is at version 4, I have no idea how I missed up until now, but it is a full-features ssh terminal (with tabs!) that does almost everything you might need. It supports ssh keys (and has a decent keygen interface) and has a decent selection of terminal preferences. It has built-in support for cygwin shells and provides some nifty extra features (command auto-complete, command-output pop-up display) in the event you do any work with cygwin.
Poderosa, like it's putty cousin, is fully open source as well as free to use and is extensible through a fairly robust plug-in architecture. It lacks ssh port forwarding and the ability to scp files, but it has enough features that it will supplement the putty utilities for me (how can I *not* keep putty with me on my USB thumb drive) quite well from now on.
Fellow Security Twit @innismir asked for input on places to go on the web - besides Google - to test the security efficacy of URLs. Here's a short list (stole one from @ABCSecurity) of places you can copy/paste links into:
Would love to know of more sources if you have them. Just drop a note in the comments and I'll add to the main post as they come in.
I interjected myself into a Twitter conversation between @natevw and @hjon tonight which ultimately led to me rummaging through a couple of the "miscellaneous" bins from the past couple moves to find Audrey. (No, it's not the skeletal remains of a relative or cat, nor is it a stuffed version of either either).
Audrey is/was a $500.00 USD "Internet appliance" released by 3Com in 2000 that ran QNX - a popular embedded *nix-like OS. You could surf the web, listen to music and e-mail folks (plus run a few other apps that came with it). It had a touchscreen (tho, you needed a stylus) with a virtual keyboard, but you could also use a wireless keyboard. My setup is a bit worse for the wear, but she still works:
The device failed because it was too expensive and just a bit ahead of it's time (you have to remember, the Internet was a different place back then, with the intended, primary means of connecting the Audrey being dial-up). I believe it also failed because there was no good way to develop for it, thus snubbing early adopters who might have been able to get 3Com over the 1st gen hump and provide it a stream of cool apps to make it worth the money for the general public.
I grabbed my device after it was discontinued because it then became hackable. Ah, the days of crafting CF cards just-so in order to bend the device to my will and adding the USB-to-Ethernet adapter to surf via the lame excuse for broadband back then.
The iPad is not new. Audrey had a great deal of the iPad goodness going on a decade ago. It had decent industrial design and the non-hacked device worked very well for the intended purpose given that it used a 200 MHz Geode processor (no "cores" back then) with a whopping 16 MB of flash ROM and 32 MB of RAM (all in a 9x12 package). It packed two USB ports and a CF card slot as well, making it far more open than Apple's offering.
But, 3Com had to go and be the gatekeeper. It had to dictate what you could use the device for. And, it failed.
I have no problem abstracting the innards of the OS from the end-user. In fact, Microsoft and Apple do that every day with the Windows Explorer and the Finder. If the average Joe sticks to relatively benign software (iWork, Safari, Mail - for OS X), there is little chance of things going awry.
But, if you desire to dig deeper or even make your own stuff, you can. Gratis (kinda...as I've said, you do pay for the OS). With dozens of tools both provided by Apple and other entities.
I had a chance to show Jarrod - now 9 - Terminal.app on Sunday (we built his blog - Jarrod's Place). While we were setting up various elements, I showed him how I could do everything he was used to doing via dragging & clicking by typing. Seeing his eyes light up at the understanding of the power contained in there was really cool. He is a bit away from Unix command-line hacking (he still needs to practice typing :-), but he wouldn't be able to do that at all if I just handed him an iPad. He'd be a surfing, viewing, tapping, gesturing, average person. I'm glad he wants to be more, and I cannot wait to show him Audrey working tomorrow.
As I said to @hjon & @natevw, we are heading down a path where tinkering will be equated with terrorism and where the government, media conglomerates and companies like Apple, Microsoft and Google will be the gatekeepers into what we see, hear and experience. Given the economic hole the West got itself into, there is little other choice. We don't make anything but bits that fly across screens and those who deliver that content will have to find a way to bleed every dime out of us to keep making gobs of money. The only way to do that is control. What were you doing opening up that case? Trying to circumvent copyright restrictions? Oh, you want to watch that video? Not on that device...you might be able to copy it! You want to use that cool app? I'm afraid it will cost you $0.99. Oh, you want to make an app for that? Please hand over your developer fee and purchase this overpriced development workstation and make sure you don't do anything too crazy since we will be reviewing what you post (oh, wait...there's already a platform like that).
Focusing on the current fad for a moment, Apple - the gatekeeper - has deemed no Flash on their device (or, so it seems). What is really stopping them from ensuring your feature-rich web app designed for their mobile environment doesn't work so well (because it competes with an app you would normally have to pay for)? One answer will be "because you'll switch to the Android/Windows Mobile 7/etc device instead". And, when they begin the lock-in, or when all the carriers start getting miffed at all the upgrades they need to do that they start charging more for access or just restrict what you can do in general?
Be very wary about the technologies you embrace, whether it be iPads or iPhones or Blu-ray players (you know you are one update away from not being alb to play your movies any more, right?) or video screens with really scary connectivity options (you know DVI and HDMI connections can have HDCP enabled to prevent you from viewing content on unauthorized devices, right?).
Perhaps my paranoia is unfounded (I'm old and curmudgeony, so I get to be paranoid). In a way, I hope the iPad is a complete failure, if only to delay what I see as the inevitable. If I am right, you better start accumulating spare parts for the open and pseudo-open devices you want to keep working and using and make sure you keep a few linux/BSD distros on many media types. You never know when you are going to need them again.
Nick Wangler (@SweetTea023) asked me why people hate Flash (no doubt referred to me by @Wygle or one of my Seattle cohorts). The answer is far more than 140 and has been answered posited and pondered by many more qualified than me. I will, however, endeavour to round out the corners of the various arguments against it and be as non-duplicative as possible.
Security
A very quick search on NVD shows 77 vulnerabilities for "Flash Player". Flash is an add-on for your browser; an expansion that you install (or have installed for you by an OS distribution or computer manufacturer) in addition to the base components. By default, that creates yet-another vector for attackers and even levels the playing field a bit for them since they can target multiple platforms and multiple browser configurations with roughly the same exploit. Believe me, Microsoft & Apple do not need any more help making their browsers or their systems more vulnerable to attack and we certainly do not need to give the malware writers more soft targets.
Flash is also one of the few items on my system (yes, I have it installed despite loathing it) where I actually need to hit an external site to configure it. If you've never been to one of those settings screens, they've been around in one form or another since ~2004. Even those settings could not stop a pretty nasty attack vector that Adobe had to close by removing functionality (that it should never had added in the first place).
From an enterprise perspective (the whole world does not revolve around home users), it is a royal pain to manage Flash versions across even a moderate large user-base, especially since Adobe has removed or munged functionality enough that some divisons or workgroups actually need to keep older versions installed. That means I have vulnerable target systems that I have to account for when I do a risk/threat profile. If such an institution is, say, a bank, that unpatched endpoint becomes one means for the "bad guys" to get to your data. (And, if you think that isn't likely, you have never been employed by a large financial institution).
Performance
Before I start this section I need to do a full disclosure: I am primarily an OS X user but have two Windows 7 boxes, a Windows 7 VM, a dedicated linux server at home, a linux VPS in Cali and countless linux VMs). I have to do that because - invariably - I will get the "you're just a whining Mac user" comment.
Flash browser performance - in general - sucks, just like Java applet performance - in general - sucks. This is primarily due to bad programming If Adobe (and before them, Macromedia) asks me to extend my browser, the least they could do would be to provide tools and a deployment process to ensure that inept programmers have to pass some sort of test before crashing my browsers (well, not Chrome, thanks to the process model Google uses, which I'll bet is due - in part - to Flash).
I know when Flash kicks in on a site because my fans start whirring, the CPU starts spiking and the batter starts draining much faster. Most Flash-heavy sites are even a dog on my Mini 9 with 2GB of RAM running Windows 7! And, forget about full-screen Flash video on linux. Adobe will swear it's not their problem, but they should have either not lowered the entry bar or figured out a way to truly optimize their code. They chose to make the plug-in and it not the responsibility of the OS builders to help them out.
Design
For those who have been around this Internet of ours for a while will understand the following: Flash is the modern equivalent of the <blink> tag and animated gifs. The minute I see Flash content (on a non-dedicated gaming site [kongregate/armor games] or non-dedicated movie site [hulu/youtube]), here's what goes through my head:
Not exactly two things I'd want associated with my site.
Granted, there are exceptions (I've seen some brilliant data visualizations in the New York Times and other sources), but in general, Flash == ugly and is there only in a pathetic attempt to grab my attention away from what I really want to see on a site (hence the continued growth of ClickToFlash usage by OS X Safari users).
Gatekeepers
While there may be some open source means of cranking out Flash, expensive Adobe tools are the primary means to develop these beasts and I am not fond of gatekeepers (I promise to not turn this into an iPad rant). In my infrequent programming ventures, I really shy away from closed frameworks because I do not want to be locked in. Until they made .NET a tad more open (e.g. the Mono project), this was the primary reason I stopped trying to make Windows software. While I consider myself a semi-proficient OS X developer, I loathe the fact my apps cannot run on any other platform (except the iPhone...and talk about gate-keeping!). At least Apple's tools are relatively free (I do pay for the OS, which is fine since I'm getting a much better experience than desktop linux). I can even make first-rate apps with relatively free (though a bit more expensive than Apple) Microsoft tools (SharpDevelop & IronPython).
While the majority of end-users do not care, I do and I refuse to learn Adobe's insidious incantations just to make bits fly about in a browser window. It's the same reason folks do not just make PDFs of their Word documents and put them up as web pages (and this is coming from someone who used to code PostScript by hand). Generally speaking, we want the freedom to express our creativity without lock-in which is one reason I'm really looking forward to ubiquitous implementation of HTML 5.
Concluding
It turns out I ranted a bit and did, in fact, re-hash some well-worn arguments. Just as it's applet, tag and animated counterparts, Flash had it's day and will - hopefully - be a fading memory as open standards start to become more rich and versatile. Until then, I will enjoy my Flash-placeholder-boxes in Safari and the blue Lego block of ambiguity on my iPhone.
Quick summary - it protects you from:
Grab it via auto-update or from Apple's site
A landing zone for infosec, tech & OS X bits
