Create a Secure Intranet Web Application

By Rob Nikkel
February 5, 2015
6 min read
search security - enterprise search

In my last post, my aim was to provide value to IT administrators supporting their intranets and discuss how to optimize performance, covering topics around browsers, server hardware, and configuration options available to you within the IC platform. Continuing along that path, I would like to share security, the common vulnerabilities found in intranet applications, and the features available to you within IC Thrive, including how to address these.

Last week, I had an interesting conversation with a prospective intranet customer who broached the subject of securing our intranet application and asked how we address known web application security threats as published in the top 10 list from the Open Web Application Security Project (OWASP). So, lets’ do a broad overview of the collaboration tools available to you to protect your intranet and the critical data it houses.

Creating a secure intranet application in 5 ways

Creating a secure intranet application
  1. Intranet or Extranet

An important point to cover is whether your company intranet is exposed to the internet. Some of our customers do allow access to the intranet for mobile employees without the requirement of a VPN or equivalent connection to their LAN. In this scenario, it is much more vital to consider how you configure access to your server and what security features to implement. If you’re entirely behind a firewall, clearly you will be much more protected than if you’ve opened up to the web.

  1. Stay Updated for a Secure Intranet

The first thing to look at, which is entirely in your control, is making sure you’re not open to known vulnerabilities in the software pieces used to run your intranet. Are you on a modern OS (2012 R2) or at least the very latest service pack with Windows Updates occurring routinely? Similarly, with your database server, is SQL up to date? IC can comfortably run on SQL 2014 Express, with roughly half of our customers running Express editions of SQL.

Is your intranet application server up to date? Do you use SSL encryption to protect your client/server traffic? If yes, are you using a 256-bit Secure Sockets Layer (SSL) certificate? 

Most browsers will begin reporting to end-users sites with less secure connections (128-bit). Finally, on the client-side, make sure you are applying security updates and upgrading browsers regularly.

  1. Keep Intranet Intruders Out

IC supports two authentication mechanisms, built-in Windows Authentication, and Form authentication. You can enable both (mixed mode) or one, and you can also select whether you want to allow anonymous access (Site Secure option). If you only want people with valid Windows credentials, then make sure you configure it that way in the product and the Internet Information Server (IIS).

If you want to use Form logins, use the features available to prevent session hijacking, password guessing, brute force attacks, dictionary attacks, and so on. You can implement strong passwords, password expiry, a CAPTCHA on login, lockout for repeated failed logins, session IP checking, and short session timeouts, all of which can be done on the administration screen under the Security section on your intranet software.

By design, IC securely encrypts all stored passwords, rotates sessions on login, and checks the validity of sessions on every request. With session cookies, IC also makes sure they are only accessible over HTTP (not JavaScript), are secured if operating over SSL, and only exist throughout the browser session (deleted upon closing the browser).

External to your intranet application, make sure you also use strong passwords for your SQL logins and application server logins. These typically come with stock passwords, and it would be prudent to alter them for your environment. If you do, make sure you update your data source so the application can connect with the database, and keep track of your passwords somewhere safe internally. The last thing you want to do is bring down your intranet accidentally!

  1. Manage Access for a Secure Intranet

In general, permissions are granted based on roles (elevated rights) for users, or standard view/add/update/delete