27 April 2008

We Bought A Firewall. Isn't That Good Enough?

I've been reading Jon Udell's print and blog pieces for as long as I can remember. I may not always have a personal interest (this is not the same as having a differing opinion) in some of his topics but when I am interested, I typically find myself in 90+% agreement. He's been blogging about the lack of availability to public - specifically at the local or community level - data in an normalized (or reasonably transformable/convertible) format through standard, programmatic "pulls and pushes" (RSS, SOA, etc.).

While the topic is generally interesting to me, three paragraphs of his post are particularly interesting and germane to the information security and data protection world I play in:

"As I meet with intelligent and well-educated professionals in my community, and talk with them about how to synchronize calendar information from a variety of sources, I realize that they simply have no intuition about the difference between a PDF file and an ICS file that contain the same calendar information. Both are computer files, right? Both can be posted to the web, right? Both can be searched, right? Problem solved.

. . .

These are ways of computational thinking unknown to most people. As a school administrator, librarian, city planner, social worker, or retail store owner, nobody expects you to understand and apply these principles.

And yet almost everybody needs to harmonize personal and organizational calendars. And many individuals and organizations need to flow their calendar data into other contexts to promote and coordinate their activities. "

If you substitute file formats for security controls and calendars for security-related procedures, I feel that the same three paragraphs capture the essence of the reason we still have phishing and spam problems, botnets, etc.: people not involved in "the trade" simply do not have the proper background nor the mindset to think properly about data protection.

Sure, some people and organizations may buy themselves a firewall and antivirus software and may ask, "We just bought a firewall. Isn't that good enough?" The answer, clearly, is "more than likely not." And this should never be presented or perceived as simply a push or a bait-and-switch attempt to push more security products or controls - the need for those elements comes from stated organizational objectives and/or policies and detailed risk analysis where the spend on security and protection controls is aligned with the value of assets being protected.

Who is qualified to make these assessments? How many people or groups are qualified (identification and selection, implementation, on-going maintenance, etc.) to handle major electrical, plumbing or construction work in their home or offices? Bad choices could easily lead to bad happenings, to put it rather simply. Viewed through a similar prism we can ask how many people or groups are qualified to properly assess risk to whatever they're trying to protect or hide or what have you? Same general answer: bad choices easily could lead to bad happenings.

Now, my comments emphasis a specialization or expertise necessary to make intelligent data security and protections decisions. We're all interested in protecting our data or at least assuming the firms we interact with do the same but largely, both cases are not true. On the individual side, a majority or people are willing to share their user IDs and passwords with strangers for a chocolate bar and at the company level, those firms who don't see a drop in stock price (consumer confidence and willingness to spend) often do very little.

This has been a bit of a long-winded way of getting back to Jon Udell's three interesting paragraphs. A few years ago, I led a team of network security staff at a private New England university. One thing I stressed was collaboration with peer groups, visibility to higher decision-makers and a decidedly NON-jackboot thug approach toward requests and assistance; we were to be in the business of analysis of needs (perceived and actual) and distilling them to appropriate security controls that could best support them. I doubt I was successful in this approach as my group largely functioned without mandate but I still to this day try to keep in mind a message I pushed to my staff and to the groups I met with:

I may not know much about medical imaging or financial aid records or your particular area of expertise in computer science, biology, music, etc. What I do know a bit about is data protection and security. We meet and there is a disconnect between us. What is important to you as a researcher or faculty member? What is important to me as a staff member charged with protecting you and your data?

DNA sequencing, firewalls, intellectual property...all of this reduces to knowing and working with your constituents, addressing their needs, listening to their concerns and presenting a common, organizationally based (re: consistent) to risk management and data protection that the groups you ultimately serve can do so in a consistent manner while (hopefully) taking a risk-based approach to assessment, mitigation and remediation.

01 April 2008

Google Gears, Part 1

I didn't quite get Google Gears at first. Do I REALLY need to read my blog feeds offline? As it turns out, Google Docs is getting offline support now.

Do I care? Sort of.

When you consider some other Google properties - Blogger, YouTube, News, Book Search, Picasa - you can see how Gears starts to fit into the Google experience. Working on a blog posting? Do it on the train during your commute, it's stored in the Gears database and automatically posts to Blogger when you get an active net connection. Just capture something newsworthy, Mr. Citizen Photojournalist? Dump it from your camera to your laptop running YouTube offline and the video will be stored in the Gears database until it can sync your content with your YouTube account online. Picasa already has a thick client but there's no reason Picasa web albums could not be connected to Gears for offline work.

Interestingly, these ideas aren't what I care about. It's certainly interesting from a usability point of view and allows for greater permeance of Google in your life (if you think that's a good thing) as well as allowing one to publish their virtual lives out to the Googlesphere from anywhere, connected or not.

What I'm truly in is the security controls that are utilized to protect the Gears database and the general security architecture of Gears and all of the Google properties and tools that are becoming offline-enabled. More to follow after I do some research into this.