Below is a casual, informative interview with Jeff Doyle, VP of Research at our partner, Fishtech Labs. For those who don’t know Fishtech, they’re a technology accelerator focused on security and networking and with a lot of expertise in the cloud. Their leadership comprises many of the leaders from Fishnet Security, which you may know merged with Accuvant last year and became Optiv. Fishtech recently released its Certified Cloud Ramp Framework (CRF), of which Netskope is the Cloud Access Security Broker of target technologies facilitating Fishtech’s new cloud migration and operating model. I caught up with Jeff last week to understand his views and thinking behind the CRF.
Jamie: What is Fishtech’s goal with this framework?
Jeff: I think there are a couple of ways to look at this framework. First, our intention was to give customers a proven, tested migration path to the cloud. People talk a lot about migrating to the cloud, and what the business benefits and risks of cloud are, but there’s a real gap in the conversation about how to get there.
We want to help our customers come up with not just a methodology or architecture, but a tested path and integrated operating model. We want to help them ensure that what they’re creating isn’t a snowflake, or one-off architectural approach. The more they custom-build their cloud infrastructure, the more one-off their ongoing operations become. That’s not efficient for anyone. We also want to help them ensure that the architecture they choose is well-vetted against their requirements, in the market, and also in our own labs. This way they know fully what they need, what they’re getting with the components they are choosing, and what to expect from the overall solution.
Moreover, while our customers have a good set of tools for operating in a physical environment, as they move into cloud those tools may not be well suited or are less relevant. Besides helping them identify new gaps based on their business requirements, we want to help them ensure they’re not force-fitting tools into their environment because they solve an immediate need but instead to look at the overall set of tools that work together, are well suited for their needs, and are made for cloud environments.
Getting a little more brass-tacks, we have four goals for addressing our customers’ needs:
- Help them achieve operational efficiency with the cloud services they’re using and the way they secure them.
- Provide them visibility so they understand their cloud environment, usage, and data.
- Enable them to control data sprawl to corral and protect sensitive or regulated data.
- Help them build business continuity into their overall model, an overall objective of cloud but one that’s not always thought about in the security context.
Jamie: What are some of the core requirements in your mind as Fishtech came up with this framework?
Jeff: One thing to note about this framework is that we try to steer customers from choosing a single solution in a vacuum and without looking at or thinking about their architecture as a whole. Even if they sequence their technology purchases one at a time, we encourage them to think from an overall architecture point-of-view based on their business requirements and where they’re going. So when they evaluate a particular tool (or we evaluate it on their behalf), besides looking at the goals of the product, does the tool fit the overall architecture. This is key for cloud migration so essential pieces don’t get left behind.
An important part of ensuring this is our own labs. When we say these solutions are vetted or proven, the whole idea is that we’ve taken selected and carefully chosen technology partners like Netskope and looked at not just what the solution does, but how well it works with all of the other elements within an architecture. We’re testing in our lab and even eating our own dog food by using that architecture as Fishtech Labs!
Jamie: What technologies did you select and why?
Jeff: We took a hard look at what was needed for organizations to consume cloud services securely. Those elements include Cloud Access Security Broker (CASB), Single Sign On (SSO), Data Loss Prevention (DLP), endpoint security, micro-segmentation capabilities, network security, next-generation firewall, orchestration, provisioning, software-defined WAN (SDWAN), security information and event management (SIEM), threat detection, and visualization. We also incorporate cloud providers themselves, such as Amazon Web Services and Microsoft Azure.
We chose those technologies based on the kinds of services our customers have, how well they support them as well as interoperate with them, and finally, how well they interoperate with each other. Take, for example, our environment, which looks a lot like those of our cloud-consuming customers. We use Office 365 apps like SharePoint and OneDrive, as well as Salesforce.com for CRM, Citrix GoToMeeting for collaboration, and Paycor for our HR payroll processing. For SSO, we chose the service that best helped us manage secure access to those apps and also worked well with the other vendors, which turned out to be Okta. Similarly, we chose TITUS because of its robust data classification capabilities and because it integrated well with the rest of the vendors we see often. For CASB, Netskope was a good fit because of its deep cloud app activity monitoring and advanced cloud DLP capabilities. Seeing Netskope interoperate with Okta, TITUS, and the other vendors like Splunk, Cyphort, and Microsoft Office 365 solidified our choices.
Simply knowing that these products interoperate because they have forged marketing and business development partnerships is one thing, and certainly not sufficient for us at Fishtech. We really dig in and validate this interoperability in our lab. We want the confidence that you get from this tight-knit community – that we’re all working together toward our customers’ goals.
Beyond verifying interoperability, we also look at how successful these technologies are in the market. For example, on the SDWAN front, Viptella is a big partner of ours. They’ve done tremendously well in large environments where flexibility is needed to support a rich set of use cases. Beyond customer base, security is in our DNA. Security and governance are huge elements of everything we do. We don’t look just at a security solution, but the overall cloud solution and how we do every piece of that securely. We rely heavily on the Cloud Security Alliance (CSA) Cloud Controls Matrix and Security Trust & Assurance Registry (STAR), the U.S. Department of Commerce’s National Institute of Standards and Technology (NIST) frameworks, as well as the European Union Agency for Network and Information Security (ENISA) models. If you look at our technology evaluation process, you’ll see that these standards influence our thinking a great deal.
Jamie: Tell us a little bit more about how you evaluate technology.
Jeff: One of big challenges our customers face is verifying what is reality out of a vendor’s solution and what is still slideware. The POC becomes a key piece. That’s one of the services we offer beyond our CRF – an independent analysis of how the solution really works. And we try to get beyond the idea of whether the product works as advertised, but really bang on it to know it really well so we can best advise the customer for how to get the most value out of it. Sometimes we actually do find a product that works really well, but just isn’t a fit given the customer’s business objectives.
Here’s an example: We did a project for a customer in which we evaluated an SDN solution. It was really cool and mostly worked as advertised. But one of the things we uncovered was that it was really immature from an operational perspective. The documentation was non-existent and it wasn’t at all clear how the customer should enable certain features when the product became operational. We had to follow up with the company’s support team, and when we did, it took a while to find the person who had the right answer. Similarly, the product versioning was obscure and releases weren’t well-managed. In short, it was just so immature operationally that we had to give the product a “thumbs’ down” because our customer would not be able to be successful with it given the reality of what they were able to take on operationally.
Where we really shine for our customers is not just defining the “how” of implementing new technology, but the “what” and the “why.” A customer can look at a vendor’s marketing materials, and based on their own plans, figure out how to implement. But they don’t always ask “What are the real benefits to my business?” We often start with the whiteboard and map out the customer’s business objectives. Then we strategize what the overall architecture should be to support those objectives. If our customer is going to spend the money, we want to help them think it through so they’re not moving in the direction of expensive dead-ends. From there, we offer our lab as a vendor-independent place to do POCs and solutions analysis, whether it’s a side-by-side with multiple vendors or simply an in-depth analysis of how the solution will work so the customer knows what to prepare for. And finally, we develop a close partnership with the technologies in our portfolio so we can influence the direction of technologies and have a strong impact in the interoperability and effectiveness of those top technologies on behalf of our customers.
Jamie: Given your networking expertise, what do you look for in network design whether you’re looking at a security technology or otherwise? What do you consider a red flag?
Jeff: I look for overall network design. Is it standardized? Is it something we can replicate over and over again in their environment or, if data center-based, in their data centers. Is the architecture proven in other data centers. For example, is the solution compartmentalized in a pod architecture or spread across multiple datacenters. This can matter a great deal for certain solutions. Next, is it designed to support business goals?
Here’s a big consideration, and something I’ve been working on for a while now: Is it designed for failure? This is huge. So many organizations spend time and money to design on ensuring uptime and high-availability of systems rather than acknowledging that failure will happen and build to ensure that any element can fail and the network still stays up. I think Facebook does a good job of this and has a wonderful reference architecture. I also love Netflix’s Chaos Monkey Program, where failure is not only planned for, it is built into the system…in production! It’s a brilliant forcing function for designing for failure!
Finally, I look for “human-proof” elements in systems. Anywhere from 60-75% of network failures are directly attributable to human error. So one thing I look for is whether the solution abstracts operations from physical access, such as what you’d get in a command line interface (CLI). The operational people should play at the policy orchestration layer using an if-then-else programmatic approach, not in the CLI explicitly telling each system element what to do.
Jamie: How do you see the CRF evolving over time?
Jeff: One thing you can expect us to do more of is help our customers evolve from more of a siloed culture to a DevOps one. It’s not just an organization thing, but a cultural transformation within IT and within organizations. A culture of DevOps came from the idea that it doesn’t work well to have a development organization that hands a product off to an operational organization that implements the product in production, and only THEN does security get involved. Having cross-functional teams involved from day one in software development, security (and other operational best practices) will be implemented along the way, the right way. This way, solutions are developed and deployed much more efficiently and customers can shorten their time to value. It requires a complete cultural change, though. The running joke in our industry is that people develop new protocols and start deploying them, and only then ask, “How do I secure this?” In many cases, security has been viewed as enemy – an inhibitor to innovation. Our goal is to help dispel this idea. As we work more with customers and influence and grow with this way of thinking, so too will our framework evolve with that. We will look more and more through this lens in selecting new technology and vendors and in the services we deliver and how we deliver them.
