Cybersecurity incidents aren’t something that happens to other people. Organizations today accept that it’s not about whether a breach will occur but when. But while board members have moved from disinterest in security to acceptance that it must be addressed, that doesn’t mean the cybersecurity problem is solved. The landscape continues to change, and new threats emerge daily. Plus, and here’s the big one, the cloud redefines the threat surface from a “keep the bad guys out” philosophy to a must provide end-to-end protection across a massively distributed architecture.
Decision-makers planning to build or migrate workloads to the cloud require a range of (potentially new) security capabilities, operating in tandem to maximize protection and enable early detection and response to security threats. Next-generation cloud firewalls and software-defined wide area networks (SD-WANs) need to be defined, deployed, and managed alongside existing solutions such as virtual private networking (VPN) and endpoint protection. So, where to start and what to consider?
Three alternatives exist: rely on security capabilities in existing cloud platforms, buy direct from the hyperscalers (AWS, Azure, or GCP) and see what these platforms offer in terms of value-add or “premium” features, or bring in a third-party solution designed for the job. Many organizations look at the second (value-add) approach as a way of upgrading from the lowest common denominator. These offerings are often considered the easy button, as they can be deployed at the flick of a switch (or the check of a box).
Assessing Need
But do they provide the security that you need? As a company that evaluates products according to defined criteria, we would advocate for starting with a list of requirements rather than just assuming hyperscaler capabilities will deliver. While they cover a good proportion of what you want, remember that security breaches happen by exploiting the gaps in your architecture. So it’s up to you and your organization to review these gaps and mitigate the risks they cause. Assumptions are dangerous at the best of times and even more so when it comes to cybersecurity.
So, yes, review your use cases, check the problem considerations on your desk, and put together a checklist for what security solutions need to deliver. For example, do you need the application awareness offered by next-generation firewalls or the selective routing to different SaaS services according to role? Do you need inbound traffic scanning or botnet detection? Does your staff need mobile access to services, and if so, what endpoint capabilities? You should also consider future proofing—using security tools with the features you need today and anticipate needing in the future. For example, many firms plan to move to a zero-trust approach to application access, so they should consider security solutions that offer zero-trust enforcement. No two organizations are the same, so answering these questions will give you a solid starting point for decisions.
The next issue many may already be familiar with is skills and staffing. A big challenge for organizations today—which I, too, have faced as a buyer—is hiring for security. I simply can’t hire unless I’m in Silicon Valley because nobody is open for work. While this may look like a more temporary challenge, it has a bearing on the security solution and approach I may take (again, security is about risk mitigation: a lack of expertise is a significant source of exploitable risk).
For example, suppose I can assemble a team (or have one already) with skills associated with a particular vendor; I should stick with that and deploy across my cloud workloads and data centers rather than bringing in yet another one-off security tool. Alternatively, I could outsource my security capabilities to a specialist third party and work with the tooling they recommend.
Note that the checklist of capabilities your business needs remains yours. The process starts with defining the problem, then the criteria, and how to test against them. What are your mission-critical workloads in the cloud, and what protection do they need? How is the threat landscape evolving, and what do potential solution vendors need on their roadmaps to mitigate against new threats? If you’re unable to get this far, it is a sign that you lack sufficient expertise. As a first step, talk to your existing vendors about what problem you’re looking to solve, given your architecture.
In terms of options, you can start with the “easy button”—you don’t want to rule out what may be the most straightforward solution. Even if you don’t go for what the hyperscalers provide, you’ll still be looking for a first-party cloud offering, delivered as a service and operating seamlessly with your provider platform. Whatever you have on your shortlist, the next step is to run a proof of concept (PoC). To repeat, you create unnecessary risk if you just assume a solution delivers. Plus, running a PoC enables you to assess real costs across the service, staffing, configuration, and operations.
Elements of Trust
Closing off these considerations, you should think about who you trust, not only to deliver but to partner with along the next stages of your journey. As a CISO, I don’t buy features. If you managed to get into my office, I assume that you meet the feature/function requirements of my engineering teams. By the time we speak directly, the question is: can I trust you? While I may have a picture of costs, I don’t want to reduce this to a marketplace decision. More importantly, if things go wrong, if I have a zero-day breach or a bug that causes the service to go down, will you be there, working alongside my engineers to solve it? I’ve had that experience with vendors, including Fortinet, and that builds a lot of trust.
Elements of trust can be configured and encapsulated in policies, but it also includes credibility and reputation based on partner knowledge and, indeed, analyst reports but, even more so, personal experience. A level of trust might be offered to a new provider, but full trust requires time, and it is tough to get back if it’s lost. Trust is a fundamental thing we’ve had since living in caves.
A final thought to remember is that you will constantly be iterating. The technology landscape isn’t done evolving, creating new threats that must be continuously considered and addressed. That checklist of requirements you created? You’ll need to keep that under constant review, using it to hold your vendors to account for their existing features and product roadmaps. It’s not your job to accept the status quo; rather, you’ll need to adopt a proactive approach to how you partner, with an open, collaborative, honest vendor dialog based on trust. Only on this path forward can you continue protecting your data assets, your stakeholders, and your business.