With password theft a leading cause of data breaches, the University of San Diego has implemented a secret server vault solution to secure shared IT credentials.
The University of San Deigo (USD), like most universities, isn’t expecting a cash windfall anytime soon; so they’ve turned to a simple data protection solution: passwords.
Every day, hackers target colleges and universities across the country. And, as a rising number of schools can attest, higher education is finding it tough to defend itself. Preventing such attacks is never easy, but universities may be particularly vulnerable because of budget constraints. In the words of one critic, lack of money often leads to an approach of “if it ain’t broke, don’t fix it.” As a result, schools tend to run old software that lacks the security features of later upgrades, or they may simply fail to patch software that contains exploitable bugs.
While few IT administrators are expecting a budget windfall anytime soon, schools can nevertheless take affordable steps to reduce the chances of a data breach. At the University of San Diego, for example, IT has focused its attention on an unglamorous security vulnerability—passwords—that is one of the leading causes of data breaches.
“Everyone was doing their own thing with passwords,” recalled Jordan Anderson, systems administrator at USD, which utilizes a centralized IT setup that is organized into several subgroups. “The networking team was storing passwords one way, we had our own solution in systems administration, while another team was using freeware to do localized encryption of passwords. We weren’t doing anything too outlandish—no Excel document with passwords in it, for example—but it was all sporadic.”
A scattershot approach like that can lead to increased vulnerability. Staffers who are required to remember passwords for a variety of systems, for example, are often reluctant to change them on a regular basis. Even worse, they might write the passwords down—sticky notes are a favorite medium.
While USD’s password setup never led to a breach, security-conscious staffers realized there had to be a better way.
(Next page: Harnessing a password “vault”)
USD ultimately selected Thycotic’s Secret Server, a web-based password vault that can store shared credentials across a group, a department, or an entire institution. These passwords, known as secrets in the parlance of Thycotic, can range from administrator and root logins for servers to access credentials for core routers and switchers—any system to which access is restricted.
Instead of logging directly into these systems, IT staffers at USD now log into Secret Server with their Active Directory (AD) credentials. Once inside, they can browse or search for the system passwords they need. For Anderson, the system has enabled IT to attain many of its goals for password security:
Controlled Access: As systems administrator, Anderson holds the keys to the castle. For each password, he uses a template to establish who has access as well as other criteria. “We do all the basic access via AD group,” he explained. “I can share a secret with an entire group or with a specific person.”
The end goal is flexible security. Most of the time, the database team doesn’t need access to the systems used by the networking team, for example, and vice-versa. There are instances, however, when subgroups need to work together.
“Security was a big reason why we wanted to implement Secret Server, but the other portion of it was the collaboration,” said Anderson. “If the systems team builds up a server with password protection, how am I getting that password to my programmers? Before, we didn’t have a good way to do that. Now I can share passwords with whoever needs them throughout the entire organization.” Once a team project is complete, Anderson can simply pare down the access list for the relevant systems and change the passwords.
Automation: There’s always the danger that users will log into Secret Server, retrieve the root and administrator passwords, and then go back to their old way of storing passwords. To combat this—and to keep passwords from circulating too long—the password template allows Anderson to automate changes. “The template allows me to auto-change the password on a schedule, whether daily, weekly, or monthly,” he said. “We also have some systems that change their passwords after they’ve been looked at once—like a check-in, check-out thing.”
In some cases, staffers never even see the passwords they’re using. A feature called Launcher allows staff to click on an icon within Secret Server to launch systems without ever seeing a password. This approach makes it impossible for IT staffers to access systems from anywhere except Secret Server, making compliance with security policies much easier.
According to Kevin Jones, senior security architect at Thycotic, this kind of automation should be central to every IT shop’s security setup. “The biggest flaw we have in IT systems and technology today is the human side of it,” he said. “When people get involved is typically when things begin to break down.”
Password security in higher education is particularly tricky, he added, because many IT shops employ a lot of part-time student workers. “Students have an incredibly high turnover rate: Are universities changing passwords when students go on break, or leave, or graduate?” queried Jones. “You can try to keep a paper list, but if you have a way to automate that process, you’ve addressed the issue at a whole new level.”
Audit Controls: Even with controls in place, a breach is still possible, which makes an audit trail a vital component of any forensic follow-up. Since its implementation of Secret Server, USD can now review exactly how and when its systems were accessed. “We can see who’s coming in, who’s looking at what, and when,” said Anderson. “That’s a level of visibility that we didn’t have when people were logging directly into the machines.”
The Launcher feature even provides administrators a live screen view of what staffers are doing. “That’s a very helpful tool when you are working with part-time people who have high turnover, when you don’t necessarily have the same level of trust as you do with fulltime employees,” noted Jones.
It was the threat of internal mischief that prompted USD to use AD credentials as the Secret Server login. “Some people set up Secret Server with local passwords,” said Anderson. “We have ours so we can lock their AD account, which will then lock them out of Secret Server. Our Active Directory is tied in with HR, so when people leaves or are fired, their AD accounts will get disabled.”
It’s also feasible that someone might steal an employee’s AD credentials and gain access to all the systems for which that staffer has permission. “All of your eggs are in one basket, right?” said Anderson, who is already working to counter this threat. “We’ve started to use two-factor authentication, rolling that out to certain groups who have more sensitive passwords.”
Andrew Barbour is an editorial freelancer with eCampus News.