Finding a modern solution to secure multicloud infrastructure
One of Dr. Lanier's cloud security architects came across Cisco Multicloud Defense while researching new cloud security solutions. Initially, the team signed up to address their high-level requirements. As they dug in, they were pleased with the benefits of Cisco Multicloud Defense and could deploy into a test environment without issue.
"Before we even talked to the Cisco team, we could see the potential fit of their platform with our needs. It was a good sign that we could sign up in minutes on their website."
"The 'a-ha' moment for us was that we could deploy cloud security gateways in minutes, which meant we could remove the bottleneck to customer provisioning. Similarly, security gateway updates could be automated with little downtime and minimal maintenance windows," said Dr. Lanier.
Dr. Lanier and his team set up a meeting with Cisco to discuss architecture and run a proof-of-concept trial.
"Once we met with the Cisco team, we were impressed by what we found. The Cisco Multicloud Defense architecture was differentiated from other options and our existing solution. This meant that it would not only meet our needs but could grow as the business grew in the future," Dr. Lanier added.
To complete their due diligence, Dr. Lanier's team also compared Cisco Multicloud Defense with a solution from a next-generation firewall (NGFW) vendor. What they found further confirmed their direction with Cisco:
- The competing appliance took 30 minutes to boot up— an issue for a dynamic and changing environment.
- The management and controller architecture would require Dr. Lanier's team to manage and maintain another piece of controller software, which was less desirable.
- The cloud network orchestration required placing the NGFW in the traffic path and would create additional implementation and operational burdens on Dr. Lanier's cloud engineering team.
- High availability (HA) and scale did not meet the operational requirements. The competing appliance required multiple virtual machines (VMs) for HA, which increased cost and complexity, versus a single Multicloud Defense Gateway that could be restarted quickly. In the team's tests, the NGFW failed to deliver at Teradata's scale requirement, thus creating a potential business bottleneck.
The Cisco solution: Cloud-native architecture to achieve agility for multicloud networking and security
After extensive evaluation, Dr. Lanier and his team chose Cisco Multicloud Defense to address their needs. It will provide an agile, scalable, and robust solution to address their secure cloud networking requirements—now and in the future.
"Cisco Multicloud Defense gives us the best of both worlds. We will be enabled to standardize for consistency across each cloud deployment, reduce operational overhead, and increase our business agility," said Dr. Lanier. "Cisco enables us to do in minutes what previously took hours. When you multiply the many tasks to update gateways, change rules, and support new customers, Cisco Multicloud Defense has the potential to save Teradata in terms of both dollars and hours."
Dr. Lanier's team worked with Cisco to build a distributed cloud security architecture to support multicloud while keeping data local to each customer account. As a result of the Multicloud Defense Controller and Cloud Gateway architecture, they could meet their business requirements to keep data local to each customer while maintaining consistency and centralized policy management across clouds.
The software as a service (SaaS) Multicloud Defense Controller increased efficiency for Teradata by eliminating maintenance and scale management. Also, proactive monitoring provided by the Multicloud Defense Controller through integration with Slack, Datadog, and other monitoring tools enabled critical escalations and accelerated workflow.
The Multicloud Defense Gateway provided Teradata with architectural flexibility for distributed and centralized security. This flexibility was essential to support a variety of use cases, including multi-tenant and single-tenant data clouds.
Infrastructure as Code (IaC) and Policy as Code (PaC) enabled complete automation through Terraform and REST-based API integrations. With Cisco Multicloud Defense, Teradata could achieve the separation of infrastructure and policies that gave them the desired agility.
As a result, Teradata was able to meet its business goals with the following outcomes:
- Decreased customer provisioning time—Cisco provided Teradata with an approach to achieve their security and compliance goals without slowing down business delivery.
- Increased agility—Policy updates were applied in minutes across hundreds of security control points using a centralized multicloud security architecture, accelerating incident response.
- Reduced maintenance and troubleshooting—Time saved by automating routine maintenance and troubleshooting tasks allowed the team to focus on more important security and compliance needs.
"Cisco Multicloud Defense was the right solution to modernize our secure cloud networking infrastructure. They enabled a first-class architecture centralizing multicloud visibility and control across our customer accounts. We're excited to partner with Cisco," said Dr. Lanier.
Opportunities for the future
While starting with egress security, Dr. Lanier was excited about the other opportunities that Cisco Multicloud Defense, as a security platform, opened up for his team. IPS/IDS was of special interest to help block exploit attempts and other threats. The ability to remove other tools and consolidate policy management provides significant agility and economic benefits.
Additionally, Dr. Lanier's team needed to create a more centralized security model for both ingress and egress traffic for a new multi-tenant offering. Cisco Multicloud Defense's architectural flexibility for centralized and distributed use cases allowed Teradata to maintain centralized security visibility and control regardless of the security architecture.
What is cloud egress filtering and why is it important?
Having control over outbound destinations from your cloud workloads and data stores is a fundamental best practice. However, few organizations implement this practice in their environment. For those that do, it often proves ineffective for their organization.
FQDN filtering—FQDN (fully qualified domain name) filtering operates on the destination name to either allow or deny an outbound request based on a set of parameters. Outbound connections can be allowed or denied based on a list of known good domains (allowlisting) or known bad domains (blocklisting).
URL filtering—URL filtering works by analyzing web traffic and filtering it based on the URLs (for example, https://domain.com/URL) accessed. This involves identifying the URLs accessed by your applications and then comparing those URLs to a list of known malicious or potentially harmful URLs or known good URLs. URL filtering requires transport layer security (TLS) decryption since the URL is part of the TLS-encrypted HTTP traffic. FQDN domain filtering doesn't require decryption, although it does require category-based domain intelligence that most solutions don't provide. A great example of a domain where you also need to consider the URL is github.com. Whether the URL is github.com/MyOrganization vs. github.com/MaliciousSite, is important when implementing a secure egress strategy. Clearly, FQDN filtering will not help in this case. You need to filter based on the URL.
Domain and URL category classification is provided by a service built into your security platform that can classify any domain/site and URL in real time. This means that you don't have to explicitly list the specific ones you want in your policy out of the millions of domains and billions of URLs.
As a result, you can:
- Block all malicious categories like malware, phishing, botnets, etc.
- Allow only approved pre-defined categories like Financial Services, AWS Cloud Services, etc.
- Permit only approved customer-defined categories: My Payment Processors, My Third-Party Vendors
