If you manage or support cloud SaaS systems like Microsoft Office 365, you have a lot of information coming at you. You may get – security alerts, performance data, and usage reports – from multiple tools whilst trying to stay on top of it all. But as many experienced admins can tell you, it’s often what you don’t know that can hurt your systems.
Here are some hidden threats that can sneak up and cause problems, and that your default reporting tools might not help with. Do you have plans in place to deal with all of these?
If Finance gives a department money without specifying exactly what it’s for, someone in that department is going to have the bright idea to spend that money on IT. Maybe they sign up for a cloud SaaS application that will boost the department’s productivity – for example – or help them monitor a set of processes.
What’s wrong with that? From the department’s perspective—nothing. If they’re spending their own money on it, then it’s not anybody else’s business, right? From an IT perspective…oh my. There’s so much wrong with that. The IT department is tasked with managing, securing, and maintaining all IT systems across the entire organization, but they can’t manage (and more importantly, can’t secure) something they don’t know about. When a department “goes rogue” and purchases its own IT services outside of the purview of the central IT department, they can get into all kinds of trouble. Data can become siloed because the rogue system doesn’t interface with other company-wide systems. Performance can suffer if the department’s needs outgrow the capabilities they can afford to pay for, or they have underestimated the costs involved in the system. Security can be lax because there’s no IT professional to insist on adequate security measures.
To combat Shadow IT purchases, the IT department’s leadership must impress on upper management the importance of letting the IT department do its job and putting policy guardrails in place to ensure that IT at least knows about every IT system in the company.
Bring Your Own (Unsecure) Device
The days when IT departments owned, issued, and controlled all devices is long past; today’s IT is replete with BYOD: bring-your-own-device. Like it or not, employees will be using their own devices to do company business, whether that’s accessing Internet resources via smartphones or connecting to corporate-controlled storage on laptops. Some IT departments have tried to get all Draconian about it and ban employee-owned devices from company resources…and have generally failed miserably. All this does is make employees craftier and more creative about how to get around the barrier.
IT departments must accept the reality that they don’t own every device that’s accessing the company’s resources and stop trying to make that happen. Instead, they must focus on figuring out how to make BYOD safe(r). One way is to require a security check for new devices connecting to the network; another way is to provide free security tools for every platform and operating system that will prevent the most common security problems.
Moving most company apps to the cloud can actually help with this, because cloud SaaS platforms start with zero-trust as the baseline. That means company-owned devices don’t get a security pass in any way; all devices are untrusted until they prove themselves. In such an ecosystem, BYOD becomes less of a vulnerability.
How many people are using each user account? If the answer is anything other than “always only one,” you’ve got a problem. Individual user accounts are a key tool for keeping track of who is doing what, where, and when. If a problem pops up, IT can pull a report that shows which user account(s) were involved in the problem, and can quickly deactivate the account, decrease its permissions, or contact its user to find out what-the-heck-happened.
Ironically enough, it’s not usually standard end-users who share account login information—it’s admins. That’s because, in many SaaS platforms, there are a limited number of admin accounts issued, and if there are more people who need admin privileges than there are accounts available, people end up sharing.
CoreView users don’t have to worry about this because of the Virtual Tenant and granular permissions. Rather than giving all permissions to just a few admin accounts, this feature enables you to assign limited administrative permissions to a subset of user accounts. Properly implemented, this feature virtually eliminates the need for admin account sharing.
Lack of Employee Education
If you ask most IT support people what the greatest threat is to system security, they’ll probably tell you that it’s people. Or, more specifically, naïve, untrained users. Even users who consider themselves technologically sophisticated often fall prey to convincing social engineering attacks. Perhaps they receive a phone call from a desperate-sounding person who claims to urgently need access to a certain account or file in order to satisfy a C-suite boss or a government regulator’s inquiry. Maybe they receive an email that is supposedly from IT asking them to confirm their contact information at a “secure” website. The point is, users fall for all kinds of things, and it’s usually because they haven’t been trained to be skeptical and discerning.
The solution to this, of course, is training. In-person training works well, but so does video training, either live or pre-recorded, and self-paced online training. The more privileges a user’s account has, the more important it is that the person is taught how to recognize and avoid common threats.
Single-Factor Authentication on Accounts with Elevated Privileges
Multi-factor authentication (MFA) can dramatically increase the security of a SaaS system, and most application providers recommend it across-the-board. Users balk sometimes, though, because it’s more work for them. Each time they sign in, they must go through an extra step. For this reason, many companies choose not to require MFA for standard user accounts.
Do you know who should always have MFA enabled logins, though? Administrators. And also, anyone else with any type of elevated permissions above those of an ordinary end user.
To monitor this, you will need to rely on the reports you get from the SaaS provider as an admin that tells you which accounts are using MFA. Then you can “encourage” those who should be using it but aren’t to get with the program. The trouble is, not all SaaS providers include this information in their default reporting. Using a management tool such as CoreView can be one way to get this information.
Did you know that most IT security experts nowadays do not recommend that you require users to change their passwords at regular intervals? They’ve found that there is little upside to doing so, and a significant downside. The biggest downside is that people can’t memorize and re-memorize different passwords, so they end up writing them down and keeping them in outrageously insecure locations. Like on sticky notes attached to their monitors. Or in an insecure text file on their phones or laptops. Yes, really. Walk through any department in your building, and you’re sure to find a few yellow sticky notes in plain sight containing sign-in credentials. This is true for not only local PC passwords but also SaaS sign-ins.
You can’t just tell employees “don’t write down your passwords” because most of them think they don’t have a choice. You tell them to use a unique password for each sign-in, but they can’t remember all those different passwords. So, you need to give them an easy way to do the right thing, such as password management software that enables them to authenticate themselves once—perhaps with a master password, a smartcard, and/or biometric scanning—and then fills in all the securely stored passwords when they are needed.
When an employee leaves the company, what happens to their IT permissions and credentials? The right answer is “they are immediately and completely deactivated.” If there’s any other answer, that’s a security risk you can’t afford. Large companies that you would think would know this have actually suffered million-dollar breaches because this didn’t happen.
You might think it would be easy and simple to deprovision a user’s account on corporate systems, but there are frequently multiple accounts to consider. In addition to the company’s main sign-in, there may be sign-ins for multiple cloud SaaS systems that might or might not be directly connected. The problem is further complicated if there are shadow IT systems, like the ones discussed at the beginning of this article. If the IT department doesn’t know about a cloud SaaS application, and doesn’t have admin control of it, they can’t deprovision the ex-user’s access along with their regular deprovisioning processes.
A management platform like CoreView can go a long way toward helping with this by giving you visibility into all of a user’s various permissions across all company-related IT systems, including cloud SaaS platforms.
In this article, we shared with you some issues that can affect the security and/or performance of your cloud SaaS systems if you aren’t vigilant about monitoring them. You can take many of these issues off your “to worry about” list by using a SaaS management platform like CoreView.
Want to learn more about CoreSuite and how it can help you administer your Microsoft 365 system? Here are some resources: