Cloud Security: 6 “Musts” for Protecting Identities
Identity, or more specifically, user log in accounts, have been historically one of the weakest links in the security chain in IT systems. Log ins and the users who own them are a necessary evil that systems administrators have had to deal with for decades. And as these systems leave the comfort of the on premise world and move into the Cloud, those log ins are an even bigger threat to your company’s security. How do you keep your data, systems, and ultimately your customers safe but still give your employees access to their systems when they – your employees – are now one of your biggest security risks on the open public Cloud? Because now your systems are available to anyone on the planet if they know a simple user name and password!
Surprisingly, the solutions are fairly straight forward and have been around for a very long time – yet many companies refuse to adopt them or implement them. The excuses I have heard throughout my career continue to blow my mind. Here are some I have heard just this week…
“My employees won’t use the system if they need to remember yet another user name and password.”
“The passwords are too complex and change too frequently – so security needs to be relaxed for my users. If the password isn’t a real word, but just a jumble of characters, who is going to remember that—e specially if you change the password every month?”
“What’s that paper taped to my wall? Oh, that’s the log ins to our web site content management system and the ftp IDs to the web server.”
“I want my Google ID or FaceBook ID to be my user name for everything, including my CRM system. Can you configure my CRM system to use those or any other social media ID we can identify that our users are asking for?”
“Billy needed the log in so he could change some production settings, so I gave him my username and password…I trust Billy.”
Are you freaking out yet? If you aren’t worried for your own company, then at least worry about your customer’s data. Ultimately, if these scenarios don’t sound scary, keep reading and I’ll explain why they are.
What’s the real risk with cloud security?
Here is the deal: If you pull it back to basics, what we are really talking about is secrets – single-factor authentication. We use secrets all the time, going back to the days of our childhood where we demanded a secret password for entry to our fort. When we wanted another friend to come to our fort, we simply told them the password and then they were let in. But the problem was always what happened if our friends “leaked” the password to other people (because their concerns about admittance to your fort were not the same as your concerns) – soon we had kids in our fort that we didn’t want. Sound familiar?
When we got older, we moved on to credit cards that had a credit card number on them. This was our “secret” to being able to spend money. If we wanted it, we swiped, but in reality the card was not the important bit – it was another secret. And we freely entered that secret – our account number – on forms with pens! This was so convenient, until the same people we gave the form to copied that secret, and now they were buying stuff for themselves with our credit card.
These are just two simple examples of what happens when you use a “secret” approach to security. This approach has a major risk: people. So, why, then, would anyone think that the same approach would work to secure their incredibly valuable IT systems…a secret that can be shared, copied, “cracked”, or any other of a number of nefarious means to breaching your security?
We invented processes and policies to prevent people from sharing the password with others. This was a good start, but it ultimately has the same issue – trust. I knew of a company where the corporate culture had extreme trust in its employees, and the employees earned it every day. These were service professionals who were the company’s product, so trust was required. Ultimately, however, the company was hacked because an employee’s password was used by customer that employee just serviced. You see, that “customer” was actually hoping that the employee would try to help them and knew that the employee would need to log into their computer to access data. That “customer” saw the password the employee typed and remembered it. Five minutes after the employee left, that “customer” had access to everything…a data breach occurred…and account data (including PII) for 100,000+ customers was lost. But the company had trust!
Ok, that is an extreme case. Let’s use something more practical – Facebook. You know it. You love it. You likely use it every day. I’m sure you don’t share your Facebook log-in credentials with anyone. Ever been hacked? Know anyone that has? Chances are the answer is yes. So why would you ever trust those systems to secure your IT? Because Facebook said they were sorry? I know, I know, you use Google Docs and Gmail, so that has got to be better, right? Wrong. Those systems are data breached just as often, except the difference is Google+ isn’t as popular of a social platform as Twitter or Facebook, so the world doesn’t hear about it instantly.
Setting up secure identity in the Cloud
Ok – enough doom and gloom. What do we do about this? How do we set up identity in the Cloud, because it is still the cornerstone of our identification in our systems? Here are 5 steps to get you there
Must Do #1: Use an identity management system
If you are a company, you are likely using some form of an identity management system like Active Directory (AD). If you are not, then you NEED to. These systems are basic for identity management and control. It is how you control a user’s access to network resources, computer systems, applications, sometimes even access to buildings. Don’t stop using them just because you move to the Cloud.
Must Do #2: Use the same identity management system in the Cloud
You need to have that same identity management system reflected in the Cloud to secure those same resources. In Azure, that is Azure Active Directory. It is critical for access to things like Office 365 or Dynamics 365; Azure Active Directory is built into the products, and is expected that you will use it for security. But that doesn’t mean that you need to have a “second” system of record for your users. Microsoft has developed Active Directory Sync, which will allow you to sync your on premise AD with Azure AD. That means single sign-on across on premise and Cloud systems!
Must Do #3: Enforce password policies
Sorry, but it needs to happen. Your on premise AD administrators need to implement even more complex security rules than you had before. That means that Fluffy123! is not an acceptable password anymore – because chances are that there is a hacker out there that loves cats more than you and will guess your password. In addition, your AD administrator needs require you to change your passwords much more frequently to limit the amount of time you could be exposed. If that hacker does figure out your password, but you are forced to change it every 30 days, then at least exposure will be limited to 30 days.
Must Do #4: Become a protectionist
We are getting better, but there is more…we need to be protectionists. We need to work under the conditions that access is denied unless explicitly given. That means you need to configure all your systems to deny access unless that person has been given explicit rights to access them. This may seem like a no brainer, but the number of times I have seen the entire company AD added to Azure as the “Owner” makes me cringe. The front desk greeter had the same rights as CIO when it came to controlling Azure—and all of the organization’s Cloud systems.
Must Do #5: Implement a zero-tolerance password policy
Next – no sharing of usernames and passwords EVER! Make it ground for termination. This may sound harsh, but it’s the only way you can guarantee that the person using that password is who they say they are.
Must Do #6: Enforce multi factor authentication
Earlier I said that security is based on secrets, and the first 5 steps are designed to make the secret hard to guess, as well as limiting exposure be changing the secret frequently. They are intended to give the company control over the secret and define the rules, while letting employees control the value of the secret. This can be a win-win for everyone, but we can do even better.
Secrets are single-factor authentication – something you know. The problem, as I outlined before, is someone else may know, too! So, you need multi factor authentication. Multi factor authentication is where you need more than one form of identification to gain access. Those forms could be:
- Something you know: User name and password. Special secret. API key. Favorite fruit. You get the picture.
- Something you are: Finger print. Retinal scan. Facial recognition. DNA. Gattaca!!
- Something you physically have: Chip in your credit card. Mobile phone. A key fob. Keys!
- A time element: Attempting access at a specific moment in time. Time-based safes employ this for businesses that handle large sums of money.
- A location element: Access is only allowable from certain geographies. Or specific IP address ranges.
Can we do even better with cloud security? Absolutely!
There are many more that could be employed, but these are the basics. Today’s Azure Active Directory is geared to participate in whatever approach you desire. We can configure Azure Active Directory to leverage multi factor authentication with a few configuration adjustments. You as an AD administrator require all employees to install the Microsoft Authenticator onto their mobile smart phone. Then, when a user wants access to your Dynamics 365, Azure AD asks for…
- Something they know: Username and password.
- Something they physically have: A passcode from Microsoft Authenticator, running on your phone. This is keyed to a code that only you possess on your phone.
- Something they physically are: If your users are using modern smart phones with modern finger print or facial recognition (and you can require this via mobile device management in Azure), then the only one gaining access to the Microsoft Authenticator is your employee!
- A time element: The passcode changes every 30 seconds! So, if the employee doesn’t enter it within the 30-second window, the passcode changes.
Once employed, you can almost guarantee that the employee is actually who they say they are. There is no risk of sharing passwords because chances are, the employee isn’t going to give their smart phone to someone else. And if you require modern finger print or facial recognition, it won’t work (perhaps it would if you were twins – but even then I am told it won’t). And when you log out of your system (or time out), you need to go through the process all over again!
Strike a balance between cloud security and accessibility
Organizations need to strike a good balance of security and accessibility. We need to empower our employees to take advantage of the Cloud, but we need to be smart about how we do it. We need to make sure that the access steps we require are easy to do without being a massive burden on our employees. And we need to keep the promise to our customers that we have done everything we can to keep them safe!
The Cloud experts at AKA can help. Azure AD, integration with your on premise AD systems, is part of our AKA Cloud Essentials offering that will help you get set up correctly. Are you ready to implement multi-factor authentication? We can help… our Cloud experts can demonstrate the technology and the controls you can employ to stay safe, and we can help you along your journey get it up and running.
To learn more about how we can help you with your journey from ground to cloud, download this AKA Cloud At-A-Glance.