Colin Murphy, CIO at KnowBe4, tells us how with the shift to using third-party, public cloud service providers there follows an urgency to update security policies. He asks: “Today, organizations must introduce a modern security policy that extends to SaaS providers as well. But what does that mean?”
For years, the world has been advancing towards greater interconnectivity on what has seemed to be an inevitable trajectory. The pandemic has expedited this, but equally, it has driven the use of interconnected applications outside of company perimeters.
Most companies are now outsourcing their needs to third-party, public cloud service providers; be it Software-as-a-Service (SaaS), Platform-as-a-Service (PaaS) or Infrastructure-as-a-Service (IaaS). With this shift, follows an urgency to update security policies.
As everything becomes delegated externally, we have to consider how we are interacting with these applications. Traditionally, it was up to the organizations themselves to enforce the rules that would govern how security events are logged, how data should be backed up, what devices are authorized to connect to one’s network, how user access is granted and removed etc.
Today, organizations must introduce a modern security policy that extends to SaaS providers as well. But what does that mean?
Defining the modern security policy
The modern security policy should ensure that all applications utilized incorporate a number of basic features and integrations.
This should include things like access/change log shipping to guarantee that user activity can be monitored; review of the tenant environment, whereby the software and its supporting infrastructure is dedicated to a single or multiple customers; along with granular settings such as IP-based sessions and cookie lifespan.
More importantly, however, is the implementation of SAML (Security Assertion Markup Language) capabilities often leveraged to execute Single Sign-on (SSO) authentication. If anything should be prioritized, it is this.
Through SSO alone, businesses can substantially reduce risk because you only have to rely on this one provider to grant IP-based controls, strong multi-factor authentication (MFA) and a lot of the logging required. Moreover, it encompasses a multitude of applications that may not have such controls natively built into their own service.
The importance of implementing a modern security policy
Whatever the case, either your third-party providers must maintain assurances that this security baseline is being met or you need to take matters into your own hands. Failing to do so, or making exceptions, essentially means relinquishing control of one’s security posture; thus, opening the company up to significant risk.
For instance, without SSO enabled, one loses the ability to reinforce compliance with password best practices; confirming that they are long and complex enough and are not being reused across accounts. It also means losing visibility into user behavior to detect anomalies that suggest account compromise, or if data is being exfiltrated from one of the SaaS products.
Although this may seem rudimentary, in my experience, even the largest, most equipped enterprises fail to conduct the necessary checks.
In addition to being the CIO of KnowBe4, I work extensively with security pentesting companies as a contractor, testing hundreds of companies including those within the Fortune 500.
My job is to identify weaknesses and infiltrate the organization’s network or services without being discovered. Frequently, we will find a gap because the company in question has not verified that security controls are in place on at least one of the many SaaS tools in use.
This allows the team and I to gain access and add our own MFA. In other words, we no longer need to social engineer a user or have them log in to the system. Instead, we create our own backdoor. Due to the lack of visibility, we can generally do so undetected as no one would pick up on the use of a new IP address.
A case for exceptions?
That’s not to say that there are no plausible exceptions. Not all software providers are going to meet all of your requirements – perhaps they cannot offer single sign on. Yet, if they can still provide the same security through other controls then that is okay.
It really also comes down to risk acceptance and a cost-benefit analysis. For example, a survey product that does not store customer data or anything that could be used or manipulated by an attacker might be considered low or no risk. In this case, stringent measures may not be as essential.
Building your playbook
On top of creating the policies, businesses should also devise a playbook: something that you can reference every time an incident or the like, occurs. It is a manual that provides the action items against policies, determining the next steps, requirements, what analysis should be conducted etc.
Frequently, once policy is written, it does not get followed or teams pick and choose when they are applied meaning products are being adopted without as much scrutiny. By having a playbook on hand, we can make sure that all new products are being treated in the same way to lessen the attack surface.
In order to properly design this and secure buy-in, it is crucial that business stakeholders understand the risks that exist and what the policy is trying to accomplish. Considering all the headlines we see today about cyberattacks, this should be a fairly straight-forward undertaking.
The next step is looking at what business processes are at work. How do things flow into the organization? How are requests made to procure new services? This might mean working closely with procurement, finance and information security teams, so that any time someone wants to bring in a new service, it goes through the process dictated by the playbook.
If the product does not meet the policy, then it’s time to set up a call with the vendor to work with them on plans to mitigate risk.
Then, we need to test that the playbook is serving its purpose. This is the tricky part but one of the first things to do is understand your attack surface: identifying your inventory, all the applications and services in your portfolio and being aware of each of their capabilities.
Examining SOC 2 reports and pulling together a centralized repository of what each application is capable of, is critical. From there, you organize each application by risk based on the type of information or services they provide and store.
Usually, this can be broken up into distinct groups of risk and analyzed in turn starting with the riskiest: the first being the applications that contain sales or customer information and other confidential business processes.
Looking to the future
Though we have looked at the need for a modern security policy to meet today’s challenges, it is important to remember that the landscape continues to evolve even as we speak, and policies must adapt accordingly.
Looking forward to the next year or two, I believe we will need to further the use of products like the YubiKey. This is a piece of hardware, a physical MFA device, with WebAuthn technology built into it.
It will help in eradicating social engineering attacks that target credentials; as even if they are stolen, the attacker will need access to this physical device. Granted, this does introduce an element of physical security but the risk and subsequent cost of a breach conducted online is magnitudes larger than that presented by a stolen device.
Indeed, an attacker would have to individually steal each of these devices and find the correct combination of access levels to succeed in a breach, that today, can be completed remotely with just a few clicks.
Concluding thoughts
Though our technologies have evolved to meet our hybrid working needs, security policies appear to have remained stagnant. In fact, many enterprises, both large and small, are neglecting to extend security baseline checks to the third-party service providers they are choosing to work with.
It is time this changed and one of the best methods of making sure policies work in practice is by creating a playbook. Exceptions should also be held to the bare minimum and only permitted following a thorough cost-benefit assessment. Having too many exceptions introduces risk. And over time, you will end up having to play catch up: juggling to clean up the applications you have as well as controlling the flow of new products.
