Strengthening infrastructure services security with cloud technology

As security professionals, we strive to keep up with new attack vectors while cybercriminals look for unnoticed entry points to find their way into more networks. By unnoticed entry points, I don’t mean the identity access management (IAM) tools companies use to protect their network’s front door or the server running their website. I mean the second/third tier services like project management software or even HVAC systems, little-used services that aren’t a top focus for security teams because of limited external visibility. These background infrastructure services have become a significant attack vulnerability, especially for locally-managed services.

There’s a long-standing perception that tools running on an on-premises server are going to be more secure than a cloud-based service. This is a misconception — cloud-based Software as a Service (SaaS) services are the safest and most secure approach today, especially compared to the number of breaches and potential risks from on-prem servers.

Strong security takes a village and a cloud

Managing your own servers, where you can control the physical access, network configuration, and software updates yourself was the safest approach for many years. And it’s still the go-to solution for many vigilant CISOs. But as software systems, APIs, networks and remote access requirements become more widely used, self-managed servers actually expose companies to more risks and make the enterprise more vulnerable.

Sticking with on-prem means you have to track, install and monitor all security updates from any and all vendors you work with that have access to that server. That’s like hiring a security guard to watch the store’s front door for shoplifters but never utilizing modern security technology, like cameras or even a police force, that would deter someone from breaking into the store in the first place.

Giving up direct control of crucial systems like IAM, Confluence, or WAF protection is scary — these services guard your front door and manage your core business. But you want more than one guard keeping watch — you need a full security team standing behind every service you use. 

Safety in numbers

Network environments and infrastructure tools are constantly updated, making them harder to secure. The constant change and maintenance make it easier to let those services linger unprotected when in-house security teams are focused on crucial systems like PII or credit card data. 

With the rate of change for data integration, the number of data sources feeding enterprise systems, and the growing number of data providers your company is probably working with, keeping data pipelines secure and functioning is a growing challenge.

The best solution is to utilize multiple security teams so you can leverage safety in numbers. With SaaS services, you have system experts configuring and maintaining each specific service. With self-hosted systems, a misconfiguration could lead to an unnoticed breach. 

Cloud breaches

I can’t say that cloud breaches don’t happen — even leading SaaS companies and their vendors can be victims of social engineering. Twilio’s recent attack, where hackers used spoofed SMS messages to steal credentials, or Okta’s Lapsus$ hack are both highly visible breaches. But when cloud breaches occur, the entry point is usually shut down rapidly to limit exposure. Often, a notification of a zero-day exploit will go out to major cloud vendors before the exploit is even in the wild. This gives SaaS vendors a chance to address an issue before it even becomes a problem. 

When a SaaS provider experiences a cloud breach, it affects their entire business, and they have an obligation to tell their customers. This makes OpSec a key, revenue-impacting business priority for these companies. And it means you won’t have to find the problem yourself. 

After Twilio was attacked, they identified 125 customers whose data was accessed for a limited time. The company notified those affected customers directly and broadly notified their base of 150,000 total customers. About 19,000 Signal customers (out of 40 million active users) may have been affected, but only one customer account was taken over.  

Public IAM company Okta recently had their first major breach in ten years. The issue was fixed within 25 minutes of the attacker taking control of the workstation of one of Okta’s 3rd party support engineers. Ultimately, only two customer accounts were accessed. 

Compare these numbers to how many self-hosted Active Directory (AD) breaches there are. AD is deployed in about 90% of enterprises today. In 2015, Microsoft estimated that more than 95 million AD accounts come under attack every day, meaning almost 243 trillion AD accounts have been attacked in seven years.

On-prem breaches

Recently, self-hosted infrastructure has become a top target for hackers. Infrastructure tools like network monitoring, authentication, source code repositories and deployment systems have been the entry point for significant breaches. Data pipelines are another potential vector for hackers.

When a local server is breached, the remediation process can be much more destructive than recovering from a cloud breach. By the time a team notices a local issue, their only recourse may be to wipe their domain controllers or completely block specific ports. Deploying a fix takes time when each machine has to be updated one by one. And patching an open-source tool may not even be possible until the community writes and deploys a fix.

Atlassian experienced a critical zero-day vulnerability in Confluence Server and Data Center that allowed unauthenticated attackers to gain remote code execution access to unpatched servers. The federal agency CISA quickly urged customers to block affected ports. Cloudflare also deployed a web application firewall rule that blocked the specific ports and isolated the Confluence servers on site for Cloudflare’s customers, demonstrating the rapid capability to remediate the issue using a managed service. And Atlassian deprecated their on-prem version of Confluence Server and switched to a managed service model when they saw the risks with on-premises servers.

I hope this helps explain some of the comparative risks between hosting services locally versus using a SaaS cloud service to do the heavy lifting. Here are a few steps companies can take to minimize the risk of security breaches. 

Tips to avoid breaches

1. Move everything possible to the cloud, but double-check that everything is configured properly. 

• Most cloud breaches come from misconfigurations. Capitalize on cloud provider tools like AWS Trusted Advisor, Azure Advisor and Google Cloud Platform Security Command Center, or consider third-party tools to ensure everything is configured correctly. 
• Examine and inventory the APIs you use, and assess their security profile. Make sure that authentication keys have regular rotations and that static API keys are avoided whenever possible. 

2.           Secure your AD. Given that every user could facilitate a breach, minimize potential attack surfaces and clean up the number of forests and domains in your network to simplify management. 

• Limit the number of privileged users and permissions to your network — administrative accounts are too valuable to attackers, so reduce your exposure where possible. 
• Make access more granular — some users may only need read-only access, not write permissions for high-value directories or servers.

3.           Deploy multi-factor authentication (MFA). Many users today are familiar with two-factor authentication (2FA), as they often are used by banks, financial advisors, or other secure services. But even SMS messages can be spoofed, so deploy a combination of physical and knowledge-based IAM approaches in your environment. 

• Employ push notifications and device trust certificates that can help identify authorized devices and users. 
• Look into fingerprint biometrics — fingerprints are actually much harder to spoof than most facial recognition systems today, and a fingerprint can’t be stolen as easily as a physical fob or phone.

4.           Closely monitor the data flow on your network to ensure nothing is getting sent out to an unauthorized IP or bad actor. Data will change quickly, but if you have a centralized approach and know your environment, you can minimize the risk.

• It’s very hard to check every place an application may be running, but it’s much easier to monitor email access to see who’s signing up for different products, even if they’re using personal email. 
• There’s one other big challenge with using on-prem servers for data transfer: making sure the data is going where it’s supposed to be going. If there’s a data transfer that’s happening that doesn’t line up to a sync job, say uploading sales data to Snowflake, and I see that data going to a new IP address, I don’t know if the customer just updated their network, or if data is getting stolen — and that’s a risky situation. 

5.           For services that you must run locally, say tied into your core product IP, then evaluate the risk/reward, and look for any vectors that could come in under the radar — those applications and services will drive the biggest risk. 

• Open-source software makes this even harder to monitor, with recurring syncs and multiple scripts. Make sure to maintain an inventory of where secrets are stored and if they are encrypted with a service or stored locally. Make sure to log the tokens for any data integrations that come from open-source software.
• For the services you do need to run on-prem, watch out for vulnerabilities in rarely used infrastructure apps. Look at SolarWinds or even the Target hacks a few years ago — attackers came in from ports opened for the HVAC system and managed to take 40 million customer credit and debit cards. Ensure you do the security equivalent of looking under tables and back corners to catch unnoticed vulnerabilities.