When Harvard University began its journey to the cloud, like every other organization it found itself tasked with the monumental job of securing its cloud network. Instead of utilizing an available solution, the team at Harvard decided to build its own, and the Harvard Cloud Shield was born.

On Tuesday, at the 2016 AWS re:Invent conference in Las Vegas, Harvard’s manager of cloud architecture, Thomas Vachon, explained how the university built its solution and the lessons that it learned along the way.

Essentially, the Harvard Cloud Shield is a network security platform that aggregates traffic and acts as an inspection point. It is redundant and geographically diverse. Through it, Vachon said, they filter, audit, and analyze all of their Amazon Web Services (AWS) traffic.

SEE: Security awareness and training policy template (Tech Pro Research)

The original goals of the team at Harvard were multifaceted. First, Vachon said, they wanted to provide highly-available network access to the cloud. Next, they wanted to provide visibility of traffic into, out of, and and in between applications, as well as provide next-generation firewall protection and mitigate denial of service attacks. Additionally, Harvard wanted to enable a simpler configuration through inline filtering.

In the beginning, they looked at security agents and inline virtual firewalls. The security agents were more expensive for their customers and were too focused on a reactive response, Vachon said. The inline firewalls had a high overhead cost and too complex virtual private cloud (VPC) routing for Harvard’s needs. So, they decided to build their own solution.

In terms of network connectivity, the Harvard Cloud Shield has four AWS Direct Connect connections. Each firewall has two Direct Connects at both the primary site and the standby site, and each VPC gets a single firewall partition.

Vachon said they also developed a serverless architecture to act as a manager and their platform was built primarily on Python. It overlays five different network management products and devices, so one of the key challenges was getting all of those to work together, and managing the APIs needed to make it work.

During their journey, they learned much in regards to the business, the network design, and connectivity. In business, Vachon said, network security has to be in place first, as it is the hardest piece to retrofit after you start your cloud journey. Next is to have key business sponsors and make sure that your financial team is involved early, and that you have technical employees who can explain the project to non-technical employees. Also, Vachon said, you must align with your technology partners and vendors, and keep constant communication.

For network design, Vachon said that the Harvard team learned that stateful failover isn’t practical. But, failing over sites periodically is a must. Harvard’s Cloud Shield has two sites and they failover every two months or so, Vachon said. They want to fail a certain percentage of time every two months so they can test their failure mitigation and know that they are ready for a disaster.

In the routing piece of the equation, Vachon said that they found that iBGP and eBGP function quite differently. They also found that graceful restart isn’t always ideal, and BFD should be used on every network hop. For connectivity, path selection is critical, and Vachon noted that the price of a service doesn’t necessarily equate to its quality. He also said that it is important for AWS shops to use multiple Direct Connect endpoints.

The 3 big takeaways for TechRepublic readers

  1. Harvard University built its Harvard Cloud Shield to better protect its cloud network which is built mostly on AWS.
  2. Harvard relies on multiple geographic locations, best of breed equipment, and network automation to secure their cloud, and they perform regular failover of sites to make sure their processes will work during a disaster.
  3. For a big project like this, IT needs business sponsors and technical employees who can properly explain the vision to non-technical employees and key financial leaders.