A CISO at a major customer of ours recently shared a reflection that really resonated, so we wanted to expand on the thinking and share the quote with you:
“Cloud is the data center. The Internet is the network. Identity is the perimeter and any device is a work device.”
Let’s unpack each of the four statements to understand a bit more about them.
#1 Cloud is the data center
Two major points jump out here. The first is that unless you have specific regulatory requirements, or can be highly confident in both the quality and cost of running a service or infrastructure yourself, you should try to take advantage of pre-built cloud SaaS, PaaS, or IaaS offerings.
The larger point here is that you should not care where your service or applications are running or who is running them. Your applications should not care if it’s a local MySQL or MariaDB instance, an AWS Aurora MySQL instance, or Azure Database for MySQL.
#2 The Internet is the network
Everything should be connected and reachable. Users should not be required to be physically at a location, or required to use a VPN to access “internal only” applications. The three-tier model of Internet, DMZ, and then protected internal network does not allow anytime anywhere access, and does not work well when trying to tie together applications and services running in a mix of internal data centers and multiple cloud providers.
It is also bad practice to assume that every application and system behind a firewall can be trusted. In a scenario such as this, if one application is compromised it can be used as a pivot to attack other applications and systems. If you recall, this is exactly what has happened during several major breaches.
So, if you don’t have a defensible perimeter that can protect your applications and data, what do you do?
The next phrase in the CISO’s communication points the way:
This leads to incredibly secure and flexible environments, as every application and service is potentially reachable by every other one, regardless of location: on premises, private cloud, public cloud.
However, this flexibility does not come for free. To ensure a safe ecosystem, several things need to happen:
The identities, whether human or application, need to be established or validated in a secure manner. This can be via identity proofing, secure issuance of certificates, Istio service identity, etc. The point is to be confident that the actor is who they claim to be.
The identity needs to be securely authenticated at runtime. This can be via multi-factor authentication (MFA), certificate authentication, OAuth client secret, etc. If using MFA, be sure that the recovery channel is not the same for the different factors. If provisioning credentials to services via devops, ensure that the credentials are never stored in the clear, and that the entire delivery pipeline is secure.
Don’t let the identities be stolen or given away. Identities are typically stolen via credential stuffing attacks where bots use lists of stolen usernames and passwords to find and steal identities. If this doesn’t concern you, it should—since most studies report these attacks are between 2% to 3% effective. This means that if you have more than 50 accounts, you are likely vulnerable.
MFA can prevent credential stuffing but MFA does not automatically prevent users giving away their credentials via phishing attacks. To prevent phishing attacks, we recommend both anti-phishing training as well as adopting FIDO2 as your MFA solution. FIDO2 prevents phishing by having you initially register your authenticator. It will then only accept authentication requests from registered sites, preventing look-alike phishing sites from harvesting your password and OTP code and then hijacking your session.
There needs to be an explicit authorization check between any two points in the system. This applies to users, applications and services. Authorization should default to “no” unless there is an explicit permission or role that says the caller, whether human or application, is allowed to access the specific data, service or application.
Rather than relying solely on rigid, statically defined rules, consider moving to a more adaptive, machine learning powered solution to enhance your authentication and authorization. These solutions reduce friction by removing unnecessary authentication steps when there is high confidence the user is who they say they are. They can also analyze access patterns to detect botnet or data exfiltration attacks and deny access in situations where static rules would let the traffic through.
#4 Any device is a work device
This final statement is a positive outgrowth of all the preceding work.
Allowing access to applications and information only via corporate devices is a management nightmare and limits employee productivity. In this 24x7 world, employees need to be able to access information and applications from any location with whatever device is at hand.
This does not mean that you shouldn’t validate the device to ensure that the device has not been compromised. In enterprise scenarios you can use MDM or CASB solutions to control the spread of data. Intelligence can help you in both enterprise and consumer scenarios by providing anomaly detection based on factors such as geolocation and access patterns.
The important objective is to build the controls up to the point where your security team is comfortable with BYOD for both enterprise and consumer use cases.
Access anywhere, anytime, anyhow
To summarize: We want people to invert their thinking. Instead of trying to lock applications and data away in secure closets, work to allow access to these assets from anywhere.
By adopting the policy of access to anything, from anywhere, with any device, and implementing the necessary procedures and controls to make that a secure reality, you reduce employee friction and improve productivity. You also give yourself a flexible infrastructure that will allow you to easily adapt to rapid changes in both business needs and underlying infrastructure without constantly having to rework your systems.