By Jason Baden, Regional VP ANZ, F5.
Multi-cloud environments are on the rise across enterprises in Australia; whether this phenomenon was caused by the pandemic and a need to shift remotely and fast, or whether it’s just a natural evolution, enterprises are adopting multiple clouds to cater to the quick ramp up of business productivity applications, the implementation of IaaS offerings, remote access and compute for data analytics, and more.
Some research estimates have adopted multi-cloud technologies, while across the APAC region its estimated a whopping 93 per cent of companies are embracing a multi-cloud strategy – so the trajectory of multi-cloud adoption is, quite clearly, on the up.
The use cases in doing so make sense, hence the rush to the multi-cloud. Yet many organisations, are unwittingly creating a complex system of clouds in doing so, which leads to challenges post-adoption. With organisations expanding their cloud environments with disparate providers and applications, suddenly the perimeter companies need to protect has exponentially grown.
While these challenges are unlikely to stop the shift to multiple cloud environments, there are some key considerations any organisations should take before adding another cloud.
Visibility or lack thereof
With so many cloud environments, each with their own operating platform, it’s easy to lose sight of the applications each is hosting. Research estimates an average of 3.4 public clouds and 3.9 private clouds are being deployed or tested per organisation, each with the potential to be hosting multiple applications at any one time.
At any point, that’s over seven cloud environments the IT and security team need visibility over, as well as any non-cloud environments. End-to-end visibility and policy control across all apps, for many organisations, is rarely considered at the time of sign-up, but it poses risks if not addressed.
Finding a single dashboard to attain and maintain visibility over these environments is paramount to understanding the level of activity across the entire network – as well as the additional security required to protect it.
Batting Back the Bots
Bots are relentless. They don’t fatigue, and they can retool their attacks to overcome many common defence mechanisms, which puts security teams under strain and draws on additional resources. And that’s if you only rely on one cloud or one application. Add more and the risk surface widens with them.
With an average of seven cloud environments used or in testing by businesses, there are suddenly more applications, more users, and more room for a bot army to swarm those applications at any one time. This can have an impact on the typical business, its application performance, and customer experience. And because of the distributed nature of the multi-cloud, it can happen more regularly.
Having visibility across applications is one thing but protecting all of those applications – from IaaS services to payment applications – from relentless bot swarms is another thing entirely.
Artificial Intelligence (AI) needs to be considered to ensure that the security can go where the eyes and non-automated defences can’t. AI has evolved and is now more than capable of detecting anomalies, no matter the network size, at the point of attack.
Protecting the Application Comms Channels
Most organisations will find a way to at least enable applications to communicate with one another, usually through API development.
However, since APIs are designed for machine-to-machine communications, many represent a direct route to sensitive data, meaning that most API endpoints need at least the same degree of risk control as end-user machines and conventional servers.
Yet security of these is often forgotten and it’s increasingly becoming a common threat vector. The most common incidents we see at the API level include no authentication at API endpoints (in an API world many are web-accessible, making them an end point), broken API authentication, and broken API authorisation.
Organisations need to consider security controls to protect at the API level, through:
- established libraries and best practices for API authentication, such as OpenID Connect;
- an API gateway to manage API authentication and authorisation;
- conducting frequent inventories to maintain awareness of attack surface; and
- undertaking external scans of the environment to identify vulnerabilities in practice, especially in complex environments.
Complex Cloud, Complex Security?
Distributed, multiple clouds often lead to distributed security, which in turn also brings challenges. Distributed security has traditionally meant different technologies, stacks, and controls for different environments.
But widespread use of too many tools may contribute to an inability not only to detect, but also to defend from active attacks.
Recent research found that, on average, enterprises deploy 45 cybersecurity-related tools on their networks; enterprises that deploy over 50 tools ranked themselves eight per cent lower in their ability to detect threats, and seven per cent lower in their defensive capabilities, than companies employing fewer toolsets.
Ideally, security can be deployed in a uniform stack wherever possible. The stack needs to be suitable for modern environments, and support rapid deploy and decommission. It should also include security controls that are enterprise grade and mature.
Multi-cloud environments are going to become more commonplace as the years progress. With applications, services and analytics moving to the cloud at an exponential pace, the move to take advantage of the ease of access to these services will increase in kind.
But ease of access should not come at the cost of security and visibility, so when adding another cloud, organisations would do well to concurrently consider how they’re going to secure and maintain visibility over it, and everything else it touches.
Jason Baden is the Regional Vice President, ANZ for multi-cloud security and application delivery company F5.
