Securing Your OnBase Solution

By Ryan Saunders

Securing Your OnBase Solution

Who is this guy?

• Customer Care Team• Senior Software Support Engineer• Employed at Kiriworks since June of 2012

• Part-Time Developer• Avid Security Enthusiast• Is that really a thing?

Topics covered in today’s presentation:• What it means to be secure.

• Q: My solution isn’t completely secure?• Hint: Nope

• Who should care about the security of your solution.• Q: Isn’t that someone else’s job?

• Hint: Nope

• What can be done to increase the security of your solution.• Q: Ok ok, I give. What can I do to fix this?

• Hint: Follow along with the presentation

What it means to be secure

• Completely Secure Solution ->

• Reality:• There is no such thing as a

completely secure solution.• We have to do the best to control

security where we are able.

What should I be concerned about?

• Software Exploits• Defects within the OnBase or any other application that

unintentionally allow access to protected data• Malware• Software which infects other files / processes.

• Phishing• Authentic looking e-mail, webpages, etc that steal information.

• 1000s of additional attacks

How can I minimize risk?• Software Exploits• Ensure that your OnBase solution stays up to date with the current Service Pack

for that version -> Minimize attack surface• Malware• Lock down and isolate your OnBase files -> Minimize attack surface

• Phishing• Train users to spot phishing attacks.• Update spam filters• Require encrypted traffic

Minimize the attack surface

• Principle of Least Privilege• Give a user account (or a service account) only those privileges

which are necessary to perform the work required.• Also known as LUA

• Least User Access• Least-privileged User Account

• Helps improve system security, even if you can’t prevent the attacks (exploits in OnBase or elsewhere).

Why focus on System Security?

• Foundation• Security within OnBase means nothing if the data isn’t secure

from the outside world• Legal• Audits• Personnel Files• HIPAA

Who should care about this?• OnBase Administrators• Business Process Owners

• Confidentiality• IT Security Teams

• Best Practices• Exposure

• End users• Personnel files

• Executives• Financial incentives to expand solution

So what makes up the ‘OnBase System’?

* Default Name

• Application Server(s)• AppServer Application Pool *

• Processing Server (s)• Processing (DIP / COLD / SCAN)• Workflow Timer Service

• Web Server(s)• Public facing / Web Client / Forwarding• AppNet Application Pool *

• Network Traffic

What makes up the ‘OnBase System’?

• Thick Client / Configuration• Database• Autofill from external systems – Static or Dynamic• OnBase Database

• Diskgroups• Network Attached Storage - NAS• Server Shares

Poll Time – User Base

• Who here has a primarily Core-based User Base?(Web Client or Unity Client)

Core-Based Modules

• Unity Client• Outlook /Office Integration• App Enabler• Workflow• Workview Case Manager• Many more…..

Application Server

• Does all the heavy lifting within OnBase• SoA Architecture• Service Oriented Architecture• Controls and provides data to all connected clients and integrations

• Relies on IIS (Internet Information Services)• ‘AppServer’ Application Pool

Application Server

• By default all new Application Pools created in IIS rely on a local account

Available Accounts

OnBase DiskGroups

Network ServiceFILES01

OBAppServer

Available Accounts

• NETWORK SERVICE• Built-in windows account• Presents itself as the

machine the connection is coming from• Network Service (On

OBAPPSERVER) -> SANDBOX\OBAPPSERVER

Available Accounts

OnBase DiskGroups

Network Service

OnBase DiskGroups

Network Service as OBAppServer

OBAppServer

OBAppServer

FILES01

FILES01

Available Accounts

OnBase

InfoStealer.exe

Network Service as OBAppServer

DiskGroups

OBAppServer

FILES01

Available Accounts

OnBaseSANDBOX/PrivilegedUser

DiskGroups

OBAppServerFILES01

Available Accounts

OnBaseSANDBOX/PrivilegedUser

DiskGroups

Well that was a tuuuuuuuurrible idea

• Do not under any circumstances use a privileged Domain Account to run your OnBase Application Pool.

• Here is why:

https://technet.microsoft.com/en-us/library/cc772200%28v=ws.10%29.aspx

Well, what now?

• Network Service• Pros

• Built-in account• Low Privileges by

default• Cons

• Exposes your data to other processes that run as Network Service

• Active Directory (PrivilegedUser)• Pros

• Used Only for OnBase

• Cons• The account

credentials are easily found out.

Well, what now?

• These are concerns every web-based solution faces. • Solution -> Identity Impersonation• Think LUA!

OnBase

PrivilegedUser

DiskGroups

OBAppServer

FILES01

Impersonation – How?

• Best Scenario• Use it for all new deployments. The account setup and

encryption is handled by the Server Side Installer.• Next Best Scenario• Consult the Application Server Module Reference Guide &

MSDN for additional instructions• https://support.microsoft.com/en-us/kb/329290

Poll Time - Impersonation

• If you have a Core-based userbase, are you using Impersonation currently?

Impersonation

•Do It. Use It. The End.

So what makes up the ‘ OnBase System’?

Application Server(s)AppServer Application Pool

• Processing Server (s)• Processing (DIP / COLD / SCAN)• Workflow Timer Service

• Web Server(s)• Public facing / Web Client / Forwarding• AppNet Application Pool

• Network Traffic

Processing Server

• Scheduled Scan Processes• Barcodes / Advanced Capture

• Document Import Processor• Imported ‘As-Is’ with an import file & keywords

• COLD• Text only

• Workflow Timer Service• Moves documents throughout workflow

Processing Server

• Scheduled Scan Processes• Docs on another file server / share?

• Document Import Processor• Docs on another file server/ share?

• COLD• Docs on another file server / share? (Ok you’ve said that enough)

Impersonation & Service Account Guidelines

• Preferably separate accounts, but more important that:• Do not nest account within non OnBase AD User Groups

• Do use domain account ONLY intended for OnBase usage

• Do not make the account on administrator on ANY server

• Do think LUA!


• Do not nest account within non OnBase usergroups• Ideally grant OnBase account permissions explicitly



• Do not make the account an administrator on ANY server

• There is no OnBase service or process that requires administrative privileges on a server.

• Exposes other systems to additional risk for compromise



https://github.com/gentilkiwi/mimikatz


• Do not nest account within non OnBase User Groups



• Do think LUA!


Application Server(s)Processing Server (s)

Workflow (NT Service)Processing (DIP / COLD / SCAN)Workflow Timer Service

•Web Server(s)• Public facing / Web Client / Forwarding

• Network Traffic

Web Server

• ‘AppNet’ Application Pool• Web Client ->• E-Forms

• DocPop• PDFPop• Public Access Viewer• Pass-through to Application Server

Network Traffic

• HTTP – Hypertext Transfer Protocol• Backbone of most internet traffic• Not encrypted• Can be snooped on by anyone listening in between the origin and

destination• This is a problem ^

Network Traffic

• Solution -> HTTPS• Two Main Standards• SSL (3.0) – Secure Sockets Layer• Older• Broken

• TLS (1.2) – Transport Layer Security• Newer

Network Traffic

Blue = Not enabled by default

Poll Time - HTTPS

• Are you using HTTPS on your Web Server?

• Are you using HTTPS on your Application Server?

Web & Application Server Data Security

• Upgrade those Web & App Servers• Use HTTPS• OnBase• To ensure the data you’re receiving is authentic & private.

• System• To protect account credentials & password hashes


• Solutions with DocPop• “The HTTP logon method should not be used in production

environments because it passes the username and password in clear text on the query string”• Source: SecurityBestPractices MRG

• So again, please use HTTPS on Web Servers


• Use HTTPS on Application Servers as well• If you’re concerned about load and are virtualized..• Setup more Application Servers• Use a Load balancer if you have one available• Extremely efficient at decrypting connections


Application Server(s)Processing Server (s)

Workflow (NT Service)Processing (DIP / COLD / SCAN)Workflow Timer Service

Web Server(s)Public facing / Web Client / Forwarding

Network Traffic


• Thick Client / Configuration• Diskgroups• Network Attached Storage - NAS• Server Shares

• Database• Autofill from external systems – Static or Dynamic• OnBase Database

Thick Client Security

• Security Concerns• Clients require direct access to files

• End users responsible for data processing can browse/delete through windows explorer

• Administration nightmare

Message of Doom

Poll Time – Thick Client Security

• If you have a primarily Thick Client userbase, are you using DDS?

• If you aren’t, do you know what DDS is?

Thick Client Security– Solution!

• DDS – Distributed Disk Services• A secure port employs a single access point for OnBase file

retrieval• File servers can be kept behind a firewall. The firewall only

needs access to a secure port, No UNC traffic.• Minimal/No administration needed to control file access• ONLY one account is used to grab documents within OnBase

Diskgroup Security++

• Encrypted Disk Groups• Ensures that even if your OnBase AD Account is compromised,

the attacker won’t have easy access to your data.• 128 or 256 bit AES encryption.• Separate license• Talk to your Account Manager if you have questions regarding pricing


Thick Client / ConfigurationDiskgroups

Network Attached Storage - NASServer Shares

• Database• Autofill from External Systems – Static or Dynamic• OnBase Database

Database Security

• OnBase relies on a connection the database to function

• These database password are hard-coded into the software • HSI, HSINET, HSICORE & VIEWER.

• This can also be a problem ^

Database Security

• When necessary, OnBase can be configured to use non default database account passwords throughout the solution. However, this is not a simple task and requires significant changes in an already deployed solution, especially in a large environment.

• If you have additional questions about this procedure, please come see the Customer Care Team or e-mail us .

Database Security Best Practices

• When creating a new ODBC connection – always use the VIEWER account (rather than HSI) to create it.


• Check -> Use Strong Encryption for Data• Ensures that data is protected while in transit from the OnBase

database and the Application Server or OnBase Client.


• Disable Workstation Account Creation• Users -> Global Client Settings -> Security in OnBase Config

• Allows DBAs to remove the Security Admin role from HSI.


Thick Client / ConfigurationDiskgroups

Network Attached Storage - NASServer Shares

DatabaseAutofill from External Systems – Static or DynamicOnBase Database

Fast forward a year….

• In the beginning, you applied the principle of LUA to your userbase.

• But over time, you didn’t audit your privileges. Time for a story.

Reports Available in OnBase

• OnBase Configuration -> Reports• User Accounts• User Groups & Rights• Active Directory Security

• Stored in SYS – Configuration Reports

Summary• Think LUA – Least User Access

• Every module (process / user / program / etc) must be able to access only the information and resources that are necessary for its legitimate purpose

• Create AD accounts to run the OnBase infrastructure, but only use them for that. Do not repurpose highly privileged accounts.

• Use Impersonation on the Application Pools.• DDS and Encrypted Disk Groups are available for those that require more control over file

access• Use HTTPS whenever and wherever possible.• HSI should only be used by the OnBase application itself, you don’t need to enter its password

anywhere else• If you have any questions, please ask!

Documents

Securing Your OnBase Solution