CISO’s PERSPECTIVE | 2018 1st Edition
It has been a while since I posted my thoughts about cybersecurity issues. We have been very busy in the Office of Cybersecurity and, frankly, my writing time has been directed toward other important projects. So now I can get back to sharing my thoughts on an important topic — multi-factor authentication. But first, a story…
Way back in the last century before I graduated from high school I managed to get a temporary job at the El Katif Shrine Temple in Spokane, Washington. I was looking for an easy job for the summer and not a step up toward a career so I worked as a janitor, cleaning up after events and providing access to groups wanting to use the facilities after hours and on weekends. It was the easiest $1.65 per hour I have ever earned.
One regular weekend chore was to arrive before 8 o’clock in the morning and turn on the air handling equipment. This required a trip into the deepest, darkest corner of the building which was the size of a city block with three stories above ground plus two basement levels. During the trip to the machinery room, I had to unlock a series of four doors, each with a different type of locking mechanism, negotiate a labyrinth of passageways, and then do battle with “The Beast” — an ancient 50,000-cubic-feet-per-minute electric powered blower that moved air throughout the turn-of-the-century (that’s 1800s to 1900s) building that included three large theaters, 25 meeting rooms, two large kitchens, and many bathrooms, offices and closets. Just getting from the main office to The Beast took about 10 minutes and starting the blower another 10 (not unlike starting my laptop in the morning).
Each lock I opened and each leg of the trip were a form of authentication. Negotiating the startup sequence for The Beast was the ultimate authentication factor. There were things I needed to know in order to do my weekend work.
How do we authenticate today?
The most common form of authentication — and, some would argue, the best understood — is also notorious for being cybersecurity’s weakest link. That’s right, we are talking about the simple combination of username and password.
The National Institute for Standards and Technology, also called NIST, addresses passwords in terms of strength based on entropy. Previous guidelines also addressed the length and complexity in specific terms like “at least 10 characters long, including each of four character types — upper and lower case, numbers and special characters.” Some of these requirements are in UW System Administration Policy 1030-Authentication and the accompanying procedure 1030B. But we are still addressing just one single factor of authentication and not the tools, methods and processes that will get us to greater information and data protection by using true multi-factor access and authentication.
Much like the layers of locks and ladders at El Katif Temple, you can think about factors of authentication as layered defenses. Something you know (password, pass phrase, secret word, answers to questions), something you hold (key lock, swipe card, EMV card, rotating password fob, mobile phone application), or something unique to you (fingerprint, retina scan, voiceprint). When you combine two or more of these factors, you start to build a better access control system.
Our Solution
UW-Madison has chosen Duo as the vendor to provide stronger credentials in the coming year. Kudos to Tom Jordan, Charlie Calderon, Stefan Wahe, and Patrick Hare for leading the charge. In the next few months you will be hearing a lot of discussion on how multi-factor authentication, or MFA, works. There will be conversations on how to apply MFA in your IT system and determine the best application of the technology. For example, will both factors be applied so it just works? Or will you need to do something specific such as enter a username and password then add a one-time password from a fob or your mobile phone? Or, will you need to insert a token into a special device reader on your endpoint so that device can open a channel to the data on a server in the cloud?
What are the use cases for MFA? Let’s start with a focus on the data. Existing policy helps us understand that “it’s all about the data,” to quote my colleague and our Chief Data Officer Jason Fishbain. Depending on the classification and sensitivity of the data, access to information and the information system should be limited to users and administrators who have been designated by the appropriate data steward or similar position. This part of the process allows the data steward to determine if the person really needs to have access to the data. We also need to think about the protocols surrounding the data. For example, making sure that your medical research database containing patient information and diagnoses cannot be accessed by users who are not trained in healthcare data protection and privacy.
We should also be thinking about a third-party vendor’s ability to access information systems to provide technical support. Is access limited to authenticated and authorized access via secure protocols? What levels of authorization and authentication are required for access?
We know by policy that multi-factor authentication is required for high risk data like Personally Identifiable Information (PII) and Personal Healthcare Information (PHI). We know we should address confidentiality requirements and that processes and protections must be established and disseminated to appropriate parties. We also know that restricted and sensitive data must be encrypted in transit and at rest.
UW-Madison is working to deploy MFA over the next few years. Our plans include deploying MFA initially to restricted data systems such as SIS, Grad School Application Programs, Financial Systems (Bursar), and Health Information Systems.
Are we really more secure?
Yes, the data is more secure and at a lower cost. The tradeoff is that we are not engineering secured environments where access to one environment provides access to all systems within that environment. There are always tradeoffs in security. Greater security often requires users to take additional time to access data and requires engineering greater redundancy in the system in case that primary avenue is compromised.
One can argue that making data harder to access just drives people to put important information in areas that are easy to access. If we are practicing sound risk management, we need to constantly ask ourselves “Is this the protection I want my data to have?”
If we need better protection, we need more padlocks for the data thieves. We need to put the most efficient tools in place. We need to create that labyrinth of doors, locks and padlocks that protected the rest of that Shriner’s temple by allowing me access to The Beast.
As always, I appreciate your feedback. Simple rules — be nice, be fair and be honest.
Please e-mail your thoughts to cybersecurity@cio.wisc.edu and we will periodically post them with helpful answers.
Next Blog: The Pentateuch (well, sort of)…