Major Security Problem

At some point in time, something that is infinitely useful, such as Single Sign On, becomes a major security risk. While we were dealing with another issue, we were called upon to make a recommendation on how to interrupt this useful service.

After a frenetic series of events, the CSO called us into his office to explain a virus had got into the network. Presumably it came in via a download from an email. Events were being picked up on the outer firewalls that were directing internal data to an external website. They had traced the infection back to a small number of workstations and had been dealt with, but the fact remained it was still possible for a background process to be able to creep round the network, then get out through the proxies and firewalls without any human intervention.

We had to come up with a way that forces re-authentication on the outer edges, while keeping administration overhead to a minimum.

Oh, and we had next to no budget and just three days to come up with a solution.

Given the time constraints, we knew there was no room for getting in any new technology, nor addressing security policies. We had to work with the technology, licences, and software we already had. The client used Microsoft products throughout their enterprise, so finding the outgoing Internet connectivity was easy enough. The gateway was fully integrated with Active Directory, so that made out job easier.

The solution we came up with was as elegant as it was simple. The first thing to look at is the authentication. Users would be royally annoyed if they had to re-authenticate with every service each time they tried to use it. So, only the Internet services would be the focus of attention.

We made the decision to create a totally separate Active Directory domain and moved all the Internet services into it. This had the benefit of not having to change the administration of the proxies and firewalls, plus we didn’t need to change any of the client configurations.

The domain was kept separate, but we developed a simple set of scripts which took the account details of people who were allowed access through a single group membership, and copied them into the Internet domain. Passwords were not copied. The same user identity was used in both domains to ease administration. When the corporate identity was changed, so it was in the Internet domain.

The beauty of this solution was separate password policies can now be applied to the Internet domain. Longer, with shorter times to change, meant the passwords were not the same as the corporate domain. When a password needed to be changed, a web service was delivered that allowed users to set their own password. Certificates positively identified the user and it wasn’t possible for any user to change the password of another’s.

Rollout was straight forward, and while the users did complain about it to begin with, it vastly lowered the chances of exfiltration of data through infected services. To alert this type of issue, the proxies would alert when connections were set up, which were ‘out of character’. For example, if a user who would normally be in during office hours suddenly started making requests out of office hours, this would be alerted and the cause investigated.

Any call to the Internet now needs re-authentication. If a user is on their workstation and suddenly get a box asking for their username and password, this would trigger a call to the service desk for the cause to be investigated.

Due to the automatic copying of account data, there was no need for the Internet domain to be administered separately. Apart from a very small number of password resets and patching, no administration was needed.

Any out of character access was quickly assessed. Rather than security crawling through thousands of logs to find just one, the system presented the anomalies only.

Apart from the password reset web site, there was nothing in the solution which wasn’t a standard product, deployed practically out the box.