One of the first posts in this FileOpen blog described an attack on Google and other companies, the 2009 “Aurora” hack, which highlighted risks inherent in the centralization of user credentials and data. Since that time it has emerged that this attack was probably a Chinese counterespionage operation designed to identify the targets of US wiretap orders, apparently to determine which agents had been compromised, and that the attackers gained entry to Google’s systems by exploiting the Gmail backdoor that had been built in order to comply with US wiretap orders.

Though enormously sophisticated, the Aurora hack had limited scope; indeed it seems almost minor when viewed against the more recent and broad attack on the 2016 US election. Almost certainly Russian in origin, the 2016 hack included, among other elements, the gathering and distribution of hacked email, the targeted (ab)use of Social Media and perhaps even tampering with the vote itself.

Since 2009 cybersecurity has emerged as a subject of international relations, perhaps even a new method of warfare. But attacks against commercial targets continue with ever increasing severity and sophistication. In many cases the attacks unfold in stages, first the acquisition of user credentials then the leverage of those credentials to perform some other attack, exfiltration, or surveillance. Viewed in this light the recent attack against identity provider OneLogin is likely a harbinger of future wrongdoing against the more than 2,000 enterprise customers affected.

So, how does FileOpen Systems approach this problem?

One common denominator among recent attacks is the use of fake websites to harvest user credentials, a process known as “(spear-)phishing”. This technique enables the attacker to impersonate the user not only at the real site for which the fake login was created, but also at other locations where the same credentials are used. This often works because persuading users to use strong passwords and keep them updated is, of course, a chronic problem in IT security. But efforts to combat this problem, like OneLogin, which work by centralizing credentials into a single site, have the potential to make the problem worse if the central location is itself compromised.

Partly for this reason the FileOpen software is not dependent upon the use of username/password credentials. Rather, the design of the system is that unique characteristics of the user’s device should be used to identify that device. Association of the device with the user can be accomplished by various means, including the distribution of one-time username/password combinations that have no relationship with the user’s other credentials so cannot be used for any follow-on hacking.

More broadly, it was partly to avoid multi-user data breach that the FileOpen software was designed around a distributed architecture, with no single point of failure or co-location of publisher data. Each licensee of our Toolkit or PermissionServer operates a separate, private, wholly-owned implementation of the software: neither FileOpen Systems nor any other entity can monitor or remotely access that implementation without the licensee's permission.

However, some implementations of the framework - including our own FileOpen Hosted offering - operate as multi-publisher systems, so do centralize the data of multiple licensees. The FileOpen Hosted system has some structural features designed to minimize risk of data loss.

Among these are:

• Distributed Document Storage: FileOpen's software operates only as a document permissioning service, not as a portal for the encrypted documents themselves. There is no single location containing all of the documents managed by the system.

• Local encryption: all documents encrypted into the FileOpen Hosted system are processed locally, on the desktops of the licensees. The unencrypted originals are never transmitted to any remote location.

• Database segregation: each licensee of the FileOpen Hosted system is provisioned as a separate instance of the PermissionServer code and a discrete database. This ensures that licensees' data is never comingled, each publisher has unique login credentials that resolve to a private database instance, and also enables migration of the database from the Hosted platform onto a private server upon request.

Using "cloud-based" hosted services is faster and easier than building-out dedicated servers, and in many cases can actually provide more security at lower cost than the same functionality implemented in-house. The safe deposit box at the bank is more secure than the safe in your basement. But at the same time, the crook is more likely to break into the bank vault than to raid hundreds of basements.

FileOpen's different products give you the flexibility to manage your entire secure publishing operation in-house, or outsource the database and authentication processes to us. But either way, your data remains with you and your authorized users--not in a centralized repository vulnerable to attack. Perhaps more importantly, the user identities and other data managed by FileOpen are either system-derived or generated in a way that would make them useless for further exploitation of users even were that data to be exposed.