As Federal agencies continue the long march away from on-premise networks to the world of cloud and SaaS, the payoff of that migration remains evident, as do a daunting range of complexities that come with the new network architectures. MeriTalk sat down with two Cisco veterans – Distinguished Architect Craig Hill, and Systems Architect Chris Hocker – to talk about cloud ready networks and how Federal agencies can best approach the network architectures necessary to realize the full potential of the cloud paradigm.
MeriTalk: First, tell us about the cloud ready network (CRN) architecture?
Cisco: First, let’s take a step back and think about agency network designs in the past. Typically, the applications and data resided within a facility (e.g. headquarters), on-premises, and owned by the agency. This was the gateway to the public networks (i.e. Internet, partner networks) so the security components resided at this location as well.
Now, consider the impact with the introduction of cloud – as the applications move from the on-premises data center to remote, less controlled public cloud, Infrastructure as a Service/Software as a Service (IaaS/SaaS). This transformation of application “location” is having an impact on several indirect factors, Specifically, how agencies approach next-generation wide area network (WAN) design requirements, but also security – controlling the access to applications that reside in locations with far less visibility and control (in the public cloud) than in their localized on-premises data centers.
This is where the concept of a new architecture called the Cloud Ready Network (CRN) comes in. CRN provides a new framework for IT organizations and architects to define a “cloud edge” demarcation. This is an architecture that targets a secure and intelligent WAN domain, typically through a Software Defined WAN (SD-WAN) fabric. And it defines a new “meet me” point or “cloud edge” – most efficiently through the use of co-location centers – to establish that security control point for any traffic leaving the agency.
MeriTalk: With the growing numbers of cyber threats, how can CRN protect the public sector from the ground up?
Cisco: The premise of CRN is a secure intelligent branch with SD-WAN. To clearly establish this new “cloud edge” point within an agency’s network – dictating a controlled security access point to/from the external networks – requires not only Internet access, but access to public cloud providers. Aside from securing the identity of users and things, CRN targets securing the branch, WAN transport, and establishing a resilient security stack at the cloud edge demarcation.
As the branch sites evolve, they will continue to provide intelligence routing not just for IP packets, but also intelligence policy control. For example, certain traffic may require direct forwarding to a particular SaaS application whose lowest-latency path is via direct internet access. But an agency’s mission applications policy intent may be to send the traffic through a cloud-based security stack, that is hosted in the cloud, through the agency’s private WAN, prior to its final destination that is hosted in the public cloud. The intelligent branch will require a full security stack and embedded intelligence like we have not seen in the past, and with the introduction of TIC 3.0, the need will strengthen.
Finally, as this new “cloud edge” meet-me point is established outside of an agency’s facilities, a resilient security stack (local, cloud-based, or both) is required for encryption peer termination, firewall rules, and policy, as well as the proper visibility and audit controls – specifically for traffic destined to/from the public cloud providers.
MeriTalk: What is the buzz about leveraging Co-Location facilities rather than using existing data centers and agency facilities?
Cisco: As mentioned earlier, the shift of application workloads to the cloud has changed the fundamental way we design enterprise architectures. The “cloud edge” could certainly be established in an agency’s facility, but the more effective method is to leverage Co-Location (Co-Lo) facilities, for example, what Equinix offers.
Why a Co-Lo? Because the most popular Co-Lo facilities offer multiple benefits that align with the “cloud edge” requirements highlighted in CRN. Specifically, hosting facilities, their partnerships with hundreds of transport carriers, and most importantly their proximity and partnerships with the cloud providers. These benefits make Co-Lo centers the obvious choice as the new “cloud edge” and WAN node designation and location for establishing in-depth security controls for traffic to and from the public cloud.
MeriTalk: Why is it important for agencies to prepare for cloud on the network level?
Cisco: Good question. Let’s consider one of the most obvious concepts around cloud – the data and applications have moved from on-premises agency facilities, to the cloud. So, the only way to access those applications is via the network. No matter how powerful the cloud provider platform is, the end-user experience of those applications will be predicated on a solid, deterministic network connection from the end-user to the cloud.
Furthermore, the network transport from end-user to application must be secure – from accurately identifying the user (or thing) entering the network (from any device), to securing the transport end-to-end, into the application residing in the public cloud. So, a reliable, deterministic (and low latency for some applications) network connection that is secure end-to-end is the fundamental requirement for maintaining the same look and feel for application performance residing in the cloud.
MeriTalk: What are the current barriers to cloud implementation in the public sector? How does a CRN mitigate these challenges?
Cisco: Scalable and secure connectivity from on-premise environments to cloud service providers is a huge barrier to adoption that is critical to the success of cloud projects. For instance, establishing new connections or increasing bandwidth of existing connections as cloud usage grows, can mean months of lead time and significant project delays. Additionally, there is a steep leading curve to connecting to each cloud service provider that can provide a unique set of requirements and challenges.
The CRN framework provides validated architecture principles that can be leveraged to build secure, agile, and scalable connections to multiple cloud providers. Specifically, the “cloud edge” architecture extends the existing agency on-premise networks to Co-Lo sites that are adjacent to the cloud service providers. This makes connecting to each provider a “local connection,” which ensures low latency, scalability, and lower lead times.
The “cloud edge” also allows each cloud environment to be assigned a different level of trust, then segmented and isolated into their own domains with the appropriate security controls. This provides the needed agility, control, and visibility for the agencies to be responsive to cloud projects.
MeriTalk: The digital landscape is constantly evolving. How do you see cloud evolving in the next five years?
Cisco: I think five years is too far away to provide an accurate “crystal ball” view into the evolution of cloud. However, I do think there are a few steps in the cloud evolution process we see coming.
What remains to be seen, in the hybrid model, is what percentage of workloads will reside in the public cloud verses on-premises. Economics will play a key role in determining this. Second, SaaS applications will continue to grow, allowing agencies to focus more on meeting their mission. Third, looking at this from a network operations perspective, network functions that typically reside in sheet metal boxes on-premises will now reside in the cloud.
This means a shift in business models to service providers and to more cloud-native architectures, even specific elements such as network controllers, firewalls, and IDS/IPS. Tie in machine learning (ML) – that also resides in the cloud – in coordination with this virtual security stack, and the cloud will act as a sensor for security service options that exist today with things like Cisco Talos to proactively detect and react to security vulnerabilities and threats at a scale we previously thought impossible.
MeriTalk: How can agencies ensure a smooth transition from a legacy network to CRN?
Cisco: This is a good question and a challenging one as well. Transitions are always predicated on good planning that allows a transition to occur at a pace comfortable for an agency’s IT team, with each transition step containing a fallback plan. Taking the CRN architecture approach as the baseline, agencies that have started the transition of applications to the cloud are already traversing a Co-Lo center that is peering with the cloud provider. So, purchasing Co-Lo cage space and establishing the new “cloud edge” meet-me point is an excellent starting place.
The transition can start small as well. Early adopters have leveraged private WAN links into the cloud that originate in the Co-Lo center, so they extend their agency WAN into the Co-Lo with single or dual-routers and co-locate a firewall for policy control and visibility. In most of these cases the WAN link from the agency into the Co-Lo center leverages WAN MACsec for high speed encryption. These early transitions have been simple but allow an agency to establish a “cloud edge” security demarcation point for exit/entry into the cloud provider’s infrastructure.
MeriTalk: What, if anything, needs to happen on the Federal IT policy front to help agencies speed the transition to cloud infrastructure and CRN?
Cisco: The Trusted Internet Connections 3.0 (TIC 3.0) initiative is a big step forward in terms of modernizing network and security architectures for cloud. It recognizes that as more applications move off-premise and are primarily reachable through internet connection paths, the current TIC 2.2 architecture has the potential to be a performance bottleneck and can introduce non-optimal traffic patterns. This is especially true for users that are off the agency network and have access to local internet connections that provide a direct path to cloud applications. A prime example of this would be a mobile user accessing a cloud-based SaaS email, sales tool, or database service. Today, this user has to VPN back to the on-premise network so that this application traffic can be inspected at a TIC 2.2 access point. TIC 3.0 will evaluate alternate security models for these types of users.
Another use case that TIC 3.0 is targeting involves agency branch sites that have implemented SD-WAN technologies. SD-WANs frequently leverage broadband internet connections as a cost-effective complement to traditional private MPLS-based services. SD-WANs then use a combination of application intelligence and policy to efficiently steer traffic over the desired and optimal network path. This local internet connection that is used for WAN transport can also be leveraged as a potential direct path to internet and cloud services. TIC 3.0 will also evaluate alternate security architectures for agency branch users, in addition to the mobile user use case.
In practice, agencies will need a variety of methods to meet their needs for connecting to cloud services. The connection methods and security models will vary based on the user, application, device, and network location. And this will continue to evolve over time as technologies like IoT, edge computing, and 5G are more broadly adopted.
MeriTalk: What have we not asked about CRN that is important for Federal IT leaders to know?
Cisco: Assuming we have all gotten past the acceptance that cloud will be vital to any agency, commercial, or enterprise entity moving forward, the network is crucial now more than ever. It is the bridge from user to applications. The quality of that network will dictate the user experience with respect to applications.
To reiterate, establishing a software defined, programmable, branch router that is more application aware and capable of leveraging lower-cost WAN links while routing traffic to those applications based on best-quality paths (latency, loss) verses shortest paths, will be vital. Additionally, offering the ability to apply a specific security policy, per destination, will be key moving forward as agency applications reside in multiple places with variations of WAN link quality.
Finally, establish and invest in new distributed “cloud edge” demarcation point(s), specifically Co-Lo centers, that provide the most deterministic paths to those applications residing in the public cloud (IaaS, PaaS, SaaS) while providing security and visibility given these new PoPs are no longer on-premises.
