What your file server has in common with backstage bouncers
When I am not at work serving as Hyland’s Security Evangelist, I can often be found playing guitar for a local band around Cleveland. Occasionally, my band will land a gig opening for an international touring act. On one such warm September evening, we opened for a band from the Netherlands.
An hour or so before the venue’s doors opened, a man in a fedora, notebook in hand, told the security guard at the back door he worked for a rock news website. He said he was there to conduct an interview with the headlining band’s singer. Apparently, the man’s story and fedora were convincing enough, because the security guard let him through.
No more than five minutes later, a second, much larger security guard emerged from that same door, dragging the “reporter” by his shirt and tossing him down some stairs into the parking lot below. While he suffered no injuries, I can’t say the same for that well-placed fedora.
In listening to the two guards argue, I learned the first guard had not bothered to check whether our faux-journalist had a backstage pass. Checking for a pass would have ensured this person was who he claimed to be (authentication) and that he had permission to access the backstage area for an already-scheduled interview (authorization).
Concert venues hire security guards, bouncers, stage managers, and a host of others to protect artists and their expensive equipment from harm. They issue backstage passes to specific interviewers to mitigate risk. No backstage pass? No backstage access. It’s that simple.
You may not carry a flashlight or wear an all-black shirt with the word “SECURITY” on it, but you most likely have assets you need to protect. Are you checking for backstage passes? In the past two blog posts I’ve written, we discussed thwarting attackers by encrypting your files and encrypting the database entries associated with those files.
This time, we’ll put the spotlight on another layer of defense: authentication.
Typical client/server architecture
In the diagram to the right, all workstations have a direct connection to the file server. Because of the nature of this architecture, each workstation needs permission to access the file shares where the files are hosted. In an OnBase environment, an administrator would then configure user group access to the disk groups on the file shares. 
What this means is that if an attacker gains access to one of the workstations, he now has direct access to your server. In this way, we are granting access to the files inside and outside of OnBase.
Think of all the documents in your system. Once an attacker gains control of one workstation in this architecture, all those documents are now vulnerable to corruption, theft or destruction.
However, what if we were to place another layer in between users and the file server? Going back to our concert-venue example, this layer could act as our “digital bouncer,” authenticating users and verifying they are authorized to access the files.
With OnBase, this extra layer of defense is known as Distributed Disk Services. OnBase Distributed Disk Services (DDS) acts as that security guard, keeping fedora-wearing miscreants and any other unauthorized users from accessing file shares.
Controlling access
Let’s re-examine the previous attack scenario, this time with a DDS Server in place to control access to the file server.
The attacker gains control of a workstation on the victim’s network. Since there is no direct access to the file server, the shares are not available or even visible to the attacker. In addition, since the attacker does not have valid OnBase credentials, he would not be able to access the OnBase documents.
The organization’s OnBase documents are secure and inaccessible to the attacker. 
With Distributed Disk Services, administrators set up the OnBase environment so that no users have direct access to the file server. If you think about it, a stage manager or security guard at a concert venue adopts a similar mentality. All persons are denied backstage access by default. They are only allowed backstage if the venue grants them access.
OnBase users authenticate through the DDS Server, which accesses the documents over an encrypted connection. This protects the customer data in three ways:
- Compromising a machine does not automatically mean access to OnBase documents. The user only has access to OnBase documents when using valid login credentials.
- If a user has valid login credentials, the DDS Server handles document permissions, so the attacker would not be able to view or tamper with documents the user’s credentials don’t have access to.
- Even if the attacker were to try to “listen” in on the traffic between the DDS Server and the file server, the connection between the DDS Server and the file server is encrypted. Meaning any traffic the attacker is able to see is useless.
OnBase documents often contain personally identifiable information subject to compliance regulations. Are you protecting this information in as many ways as possible—to guard your customers against theft and prevent loss for your company? Why take the risk?
Hire the OnBase bouncer, Distributed Disk Services, to add that extra layer of defense between imposters and your OnBase documents. And while you’re at it, you might as well have your CTO budget for an all-black “SECURITY” t-shirt and flashlight, too.
