0-Day - Always, “Just around the corner”

Sounds like something from a Bruce Willis blockbuster, or is Morgan Freeman about to shout down his colleagues? Unfortunately it’s real enough and it is part of everyone’s daily life. Devices like mobile phones, computers, servers and fridge magnets - ah, ok, not yet perhaps, but seriously - nearly everything connected to the WWW. No nuclear submarines or the TARDIS, it’s happening in your pocket through the air you breath.

So what is Zero-day? It is when a flaw in software is discovered by someone, somewhere, before the developers of the software. The zeroeth day of awareness of a vulnerability. There are many grey areas to consider. Let me provide a recent example:- Java is used by billions of devices. It is a cross-platform runtime environment. One development language that works on many different kinds of hardware and operating systems. Java is owned, maintained and supported by the giant, Oracle.

On the 26th of August, a US based security company reported that an unpatched Java vulnerability was being exploited, using the latest version of Java. This was confirmed by other security analysis organisations, including DeepResearch.org and reported globally by the Register. Metasploit, an IT security project, also confirmed. A bug was logged in the National Vulnerability Database as CVE-2012-4681. CVE-2012-4681 allowed an attacker to use a dedicated webpage for users to download and run a payload which could contain a keylogger or network scanner, for example. Oracle finally responded, four days later, on the 30th August. Two other vulnerabilities were discovered; these forced Oracle to make patches available outside of their usual release schedule.

How are users and SysAdmins supposed to respond? Shout, “Disable Java” is a reasonable response. But then that is a big call. Most people took the risk and left Java enabled. Most out of ignorance of the issue. Ignorance is bliss! What is the incentive behind reporting the issue on the public WWW? - leaving the found hole, wide-open. Usually publishing the technical details ready for criminals to exploit. Instead of quietly knocking on Oracle’s door with the problem - then walking away. 

Why is there no agreed standard protocol in place so that discovered vulnerabilities like this are reported in silence? I once dreamed up an acronym; VDAP, Voluntary (or Vulnerability) Discovery Announce Protocol - after a rather nasty experience with a flaw discovered in the Linux kernel during 2009. VDAP may be a secure system that could be deployed and used by all major software developers to communicate, with encryption, vulnerabilities and their details. This relies on the principle of security through obscurity, Microsoft have perfected this principle anyway. It also relies on deep discretion. The kernel flaw was discovered by a Google software scientist, then posted on his personal blog.

The incentive to report newly found vulnerabilities and cause 0-day is many things; including glory, kudos, and sales. Sales of unofficial patches, services or scanning software - amongst others. One the other hand, the pressure on large vendors to provide a patch is automatically increased. Open source vendors and communities are often faster to respond with a patch. An agreed protocol might not work because people will choose, not to use it. The best solution, may not become clear for many years and this chicken and egg scenario will continue. As a Linux SysAdmin and Engineer, I have tools at hand; kernel level security, host based, firewall rules, MAC (mandatory access control) and application level security. Of these, the Firewall with proxy filtering, is the most powerful; the best security is a well balanced combination.

If you're 'sharing' a document, you could be doing it wrong!

A beginner’s guide to basic document management within a business using Google Drive, formerly known as Google Docs.

Sharing by group

It’s obvious really, but consider this example; you have a sales team and there’s some collected information about the sales process you’ve written.  So you share it with salesperson A, B, C, and D - individually.  Seems simple and easy.  However, what happens when one of those people moves department or is replaced?  Are you really going to go through all your documents that you manually shared with salesperson C who has now been replaced with salesperson E, and update the sharing?  I thought not.

What you need to do is share the document with a group and ensure that your normal sysadmin processes include adding new users to the appropriate groups.  That way, whenever anyone joins or leaves the group they will automatically have access to all the documents they should have had - with no effort whatsoever.

However if this is all you’re doing then you’re still doing it wrong, better, but wrong.

Sharing by collection

Sharing by collection is what you want to be doing.  This makes everything much easier, reliable and less error prone.  Basically what you do is set something up akin to how you might manage files in a file server.  Create a single, or few, root collections - perhaps one per department.  Within the collection create sub-collections as appropriate for project or other needs.  Set the sharing permissions, using groups.  You only need to do this once at the start of using Google Drive.  Then any time anyone needs to collaborate on a document, all they need to do is browse to the collection where it needs to sit and click create.  Simple.

No-one needs to actively share again, and all the mess that that entails.  Now you know why, if you’re sharing a document, you’re doing it wrong!

Putting a table of contents on it all using Sites

As well as keeping the documents in some organised, or even one, collection, you are highly likely to want to make a reference to it on your intranet, aka Google Sites.  One reason is covered in a gotchya later but one of the best is that it can be like a table of contents to your collections and sub-collections.  It also can be a convenient place to put your departmental information and procedures and document storage standards.  It’s a good idea to keep all that together in one place for new and old staff.

Sites is completely separate to Google Drive.  Don’t get confused between the two.  Sites is just like a wiki.  Its permission sharing does not suck, unlike Google Drive.

Pitfalls and gotchas

Unfortunately, Google Drive permissions suck.  They offer far too much flexibility to the user that they simply don’t need such as the ability to re-share or, indeed, to share at all - that is not needed.  Ideally it would work like a file server where the sysadmin sets up all the root folders and permissions and no one can change it or need to.  Because of this, follows some things you should do to avoid problems.

The collection has been shared but can’t be found - you have to see it to see it

For some reason Google Drive will not show you collections or documents that have been shared with a group that you are a member of.  Yes it’s that dumb.  Unlike Google Sites which works as you would expect it.

There are some fairly simple steps you can repeat to ensure users can see the collections they need.  The best thing you can do is include links to the document collections on your Google Site home page.  However the user is going to want to put the collection in their My Drive so they can go straight to Google Drive rather than having to go via your Google Site.  To achieve that, set up some simple instructions like this:

To access all department B collaborative documentation, follow these instructions:

1. Click here: <A link to the contents of the collection, i.e. a link to the collection URL>
2. Now click here: <A link to a search with the full collection name in>
3. Right click on "<Full Collection Name>", click Organize.
4. Tick My Drive

Why Google makes users jump through these hoops I don’t know.

Ability to change permission

When creating a root collection or important sub-collection, then change the permission so that only owners can change permissions.  No one should need to change permissions anyway and if you don’t then chaos ensues - often just by people organising folders shared with them.  You end up with incredibly messy permissions.

Files moved in to collections may not inherit the correct permissions

If you’ve created a file and already started sharing it around rather than simply placing it in the collection it needs to be in, then when you move the file there it will not inherit the correct permissions.  The solution is to unshare it with everyone, then move it in there.  Just a little thing but it can cause confusion.

Creating templates in a collection will not place them there

Normally, when you’re in a collection and you create a new document it will ask if you want to create it in the collection.  Very useful.  However when you choose Templates it navigates away from the collection and thus when creating the document it will end up in your My Drive.  You then need to drag it into the collection you intended it for.

Dragging a collection or document from somewhere to My Drive can unshare it

Yes really.  This can be minimised by setting the ability to change permissions and most significantly by training users to use Organize instead.