How to optimise cloud security without budget blowout
[ad_1]
With Gartner forecasting another 20% jump in public cloud services spending and a 7% rise in overall IT spending for 2024, keeping the lid on budget sub-categories such as security for cloud applications and DevOps looks increasingly painful.
Neil Clark, cloud services director at managed services provider (MSP) QuoStar, says organisations often have not kept up, pointing to last year’s NetScaler breaches and unpatched vulnerabilities as an example.
Choosing from the array of tools is not easy, and some buy too many, often incompatible, offerings. Others simply pick a solution from the Gartner Magic Quadrant and spend six months trying to fine-tune it before realising it’s the wrong thing for their circumstances.
In the worst cases, organisations may simply continue like this until hit by an attack. So what’s the solution?
For Clark, it is about planning properly to pinpoint, implement and optimise appropriate solutions. An expert to understand it all – the wider perspective and then which bits fit together – can be necessary. No solution will stop everything or fit all, and cloud security cannot be a “tick-box” exercise if productivity is to be maintained and costs controlled.
“You need to be agnostically weighing up risk and aligning security need against operational need,” he notes. “It’s pointless having security overtake operations, not making money – but if you focus on operations too much, you expose yourself.”
Security sprawl can be caused more by “weird, convoluted” implementations of three to five tools where potentially one might have done the job, sometimes because the cloud environment has changed, or the organisation has at some point rushed away from on-premise rather than going deeper on cloud planning.
What’s needed is to clean all that up, reworking and layering security according to best practice, and adding essential mitigations, like backup. Getting transparency of the data environment can also prove crucial, Clark suggests.
“We’ve spent quite a bit of time rectifying that kind of thing for customers. Funnily enough, they don’t end up spending much more monthly,” says Clark. “Don’t just move your security problems into the cloud … not everything will work cloud-native. [Think about] what needs to access your applications and what doesn’t.”
Andrew Green, research analyst for networking and security at GigaOm, recommends choosing cloud-native security services from an appropriate stack as key to optimising cloud security from a cost perspective.
Open source container network interfaces (CNIs) for Kubernetes and containers, like Calico and Cilium, have “excellent” security capabilities for access controls and traffic filtering, all done at the network layer without any other agents or components.
“When you do networking in Kubernetes, they don’t offer native capabilities,” Green points out.
Although CNIs can be rather technical solutions requiring configuration and potentially an augmented skillset, they can handle communications within bots or clusters and across clusters, and can help define policies, determining what needs to talk to each other’s access controls, doing security based on identity.
“Rather than saying, ‘I want to block this IP resource from access’, you can assign a label to a workload,” says Green. “And you do it very close to the Linux kernel. It’s lightweight, you get a lot of control, and you can do a bunch of stuff.”
If configuring CNIs with the command-line interface or through an integration is too challenging, perhaps opt for working via the graphical user interface (GUI). Calico et al offer good technical documentation, labs and training to assist, he says.
Alternatively, closed-source capabilities can be part of a wider solution such as F5, if that’s already in-house, Green suggests.
Reduce exposure
Be aware of and limit exposed and vulnerable resources. If not exposed to the public internet, the organisation may only need “simple and straightforward” ingress filtering. Web and public internet-exposed services for consumers or third parties require more sophisticated ingress filtering features that come at a price.
Protection from Yahoo! filter bots or shopper traffic distributed denial of service (DDoS) can require a “heavy investment”, Green points out.
“This is not specifically for compliance, but for the general security posture,” he adds. “If everything you’re exposed to is just maybe a partner API [application programming interface], you may just need some API protection that can validate requests.”
Also, do not lift and shift on-prem thinking. For example, deploying a full firewall or next-gen firewalling appliances to create cloud segments is expensive and inefficient. It’s better to look for technologies that use cloud-native attributes like labels or tags that can migrate with the workload, says Green.
Kris Lovejoy, global security and resilience leader at Kyndryl, opines that cloud security has often been held back by legacy-related challenges, and that is partly why the years-ago talk of “massive security benefits”, alongside performance and scalability of cloud, have not played out as predicted.
The need to refactor applications to be cloud-native has often been neglected.
“Refactoring can be a very difficult discussion with boards and executive management,” she says. “But legacy apps contain hard-coded credentials, insecure configurations, outdated encryption methods and, often when you move into cloud, containerisation.“
Legacy applications can often present the same vulnerabilities as they would have in an on-prem environment, on top of which is layered the encapsulated complexity of containerisation. Containerisation is itself a source of “massive amounts” of potential configuration-related exposures, Lovejoy explains.
While organisations recognise the security issues, how applications – often poorly performing legacy solutions – and environments have been built and deployed has often left huge amounts of technical debt.
How far behind are some? When it comes to cloud development processes, Enterprise Strategy Group polling found a third of respondents’ security teams had insufficient visibility and control, missed security checks and testing of releases, lacked consistent cross-team security processes, skipped security to meet deadlines, or deployed with misconfigurations, vulnerabilities and “other security issues”.
Ensure sound basics
Lovejoy notes that multiple hybrid cloud environments need integration to deliver the portability and interoperability that’s needed. Often, even the dream of advanced analytics suffers as a result.
“That complexity has resulted in costs that were utterly unexpected. However, it was not optimised for cloud,” says Lovejoy. “They have resource inefficiency, poor utilisation, and higher cloud and hosting costs, because of huge consumption.”
They are in a kind of IT poverty trap, if you will. Spending on security can, in such circumstances, feel like an unwanted extra.
For Lovejoy, the best fix might involve rowing back on what is often termed modernisation – going backwards – for the sake of building a stronger foundation on which to ultimately build. Even if that means going to private cloud or on-prem, then restarting the big cloud moves down the track.
“Cloud can provide benefits, security and resiliency, but the organisation may need to apply appropriate investment in actual refactoring of applications,” she says, “as opposed to cobbling together lots of security controls, for example.”
This is “particularly relevant” considering the expansion and scope of emerging regulation, including on data use and transparency.
Instead of narrowly focusing on security separate from the rest, Lovejoy suggests, organisations must think through what their “minimum viable business services” are to enable their operation of organisations, data and systems. Map all that out, then prioritise security resilience around that.
That’s where organisations should invest to ultimately optimise cloud costs, including security, she emphasises.
“While zero trust is great, it really should be implemented within the context of more modern architecture. Consider the basics – do you have multifactor authentication (MFA), training and good patching? – before you get to ZTNA [zero-trust network access].”
[ad_2]
Source link
