You. Last year, the average cost of a data breach was a staggering $4.35 million. As exorbitant as this number is, it represents a 2.6% increase from the previous year. These findings are from IBM's cost of data breach report. The serve as a reminder on the importance of secure architecture welcome to Conf 42 platform Engineering conference and thank you for attending this session. I'm Arthur Siddiki, senior principal software engineer at Silicon Valley bank, division of First Citizens bank. This talk will be split over three sections, starting off with zero Trust and why it requires our attention. The next topic will be network segmentation and how AWS transit Gateway is a key enabler. The third and the last session will do a walkthrough on the cloud design coupled with traffic inspection. The term Zero trust dates all the way back to 1994. Yep, it is that old. 1994 Stephen Paul Marsh, a computer science professor, was studying trust as part of his doctoral thesis. As part of his research, he was quantifying trust as a finite entity, that cloud be described mathematically. It is in this thesis that he's first credited with using the term zero trust. Fast forward to 2010. The term zero trust model was coined by John Kinderbag. He wrote a paper for Forrester research titled Build Security into your network's dna. The Zero Trust Network architecture it is safe to say that the emergence of zero trust model has been gradual. While there are other data points indicating the industry acceptance, in my view the impactful endorsement came in August 2020. That was a time when National Institute of Standards and Technology, commonly known as NIST, published a document titled Zero Trust Architecture. Zero Trust at its core rejects the trust but verify approach and proposes the motto never trust, always verify principle include explicit verification, least privileged access and minimizing blast radius. The focus of this presentation will be on segmentation known by multiple names, isolation partition or segmentation. This network architecture approach divides the network into smaller networks. This is especially an effective approach in organizations that traditionally have had flat networks. It reduces the attack plane because lateral movement in the network is being restricted in AWS cloud, transit gateway can be used to create sophisticated network architectures. Security posture can be further elevated by introducing traffic inspection appliances. Transit Gateway was announced during reinvent of 2018 as a software defined cloud router. It employs a hub and spoke model. A popular deployment model is to provision transit gateway in an account designated as a foundational network account. Transit gateway can then be shared via resource access manager to all other spoke accounts. To better understand how transit gateway works, let's understand some of the fundamentals transit gateway attachment is what allows resources example a VPC or direct connect gateway to connect to transit gateway, therefore, in every spoke account, attachment needs to be provisioned. An attachment manifests itself as an elastic network interface, or Eni, while a single Eni can be created for resilience. Multiple subnets should be specified which will correspond to enis across multiple availability zones. It should be mentioned there are other types of transit gateway attachments, VPN pairing, connection and connect. However, this session will concentrate only on the VPC attachment type. When a transit gateway is created, it also provisions a default transit gateway route table. As required, this default table can be purged and new ones created to isolate the attachments. All routing decisions done by transit gateway rely on transit gateway route tables. Coupling of a transit gateway attachment to a transit gateway route table is what's called an association. A given attachment can only be associated with one transit gateway route table. Propagation is what allows transit gateway to learn routes dynamically from its attachments. For example, in this picture, since propagation is enabled on the next slide, there's an automatic entry under routes. Aside from propagated routes, static routes can also be created. In terms of route evaluation order, static routes have higher precedents than propagated routes. Additionally, the more specific a route, the higher is its priority. Having done a quick walkthrough on the fundamentals, how do we distill these learnings into the design while keeping in view of these considerations an AWS ecosystem that uses AWS organizations to implement multi account strategy. One of the best practices is to have separate accounts for each environment to limit the blast radius. Therefore, if an application has four environments, dev, QA, UAT, and Prod, there will be four AWS accounts. Cross account routing will be managed by a combination of VPC and transit gateway route tables. In regard to transit gateway route tables, there will be two tables configured, spoke and inspection. The last consideration is identifying the traffic flow that is of interest to us on prem is the traffic from AWS ecosystem to on prem data centers, and vice versa. Inline is espresso traffic traversing from one AWS account to another. Egress is outbound connectivity to the Internet. For example, an application workload hosted an AWS account that needs access to the Internet. Traffic inspection relies on a centralized deployment model. As shown in the diagram, there are three sets of firewalls deployed in separate vpcs. These firewall appliances reside in the same foundational account where transit gateway is provisioned. The strict control that is being enforced is that all traffic crossing a VPC boundary must be inspected. In fact, even in a multi VPC account, traffic from one VPC to another VPC in the same account must still go through a firewall. I realized there's a conspicuous absence of ingress, which is traffic coming into an AWS account from the Internet. I chose to descope it as it requires additional controls that can end up being a topic on its own. Similarly, implementation details for on prem connectivity have also not been discussed. Again, the depth of topic to include direct connect VPN or SD WAN overlay with transit gateway Connect are topic on its own. The design being presented here references two application accounts with highly creative names, app one and app two. App one has a VPC cider of ten 124 00:23 while app two has a VPC cider of ten 128 00:23 the second picture depicts corresponding ciders for vpcs in which the firewalls have been provisioned. Default transit Gateway route table has been pursed and two new ones created to isolate the attachments. Spoke and inspection on the spoke route table is where the spoke vpcs are connected. Therefore, under associations are listed the transit gateway attachments of app one and app two within this spoke route table under routes static routes have been configured. The design assumes that ten is a super block for AWS ecosystem. Therefore, if target IP is from the 16 super block, the third route is in play as it is the most specific route. In this case, the next hop is the attachment for inline firewall UPC. If the target IP is not from 16 super block but still from the 100 zero eight range, it is treated as on prem traffic. In this case, the second route is in play and next hop is the attachment for on prem firewall VPC. Finally, if cardio IP is not part of the ten eight range, then the least specific route comes into play. This is treated as egress traffic and next hop becomes the attachment for egress firewall VPC as per the first route, moving on to the second transit gateway route. Table name inspection this is where the firewall vpcs are connected. Therefore, under associations are listed the attachments for egress inline and on prem firewall vpcs. After application traffic has been inspected, final hop of the network path has to be determined. Let's say app one was talking to app two, which means that the destination IP will be within ten 128 00:23 range. That is because this is the VBG cider of app two. Therefore, the last route is in play and corresponds to the transit gateway attachment of app two for completeness. If app two was talking to app one. Then the destination IP will be within ten 124 00:23 range, because that is the VPC cider of App one. In this case, the second last route is in play and corresponds to the transit gateway attachment of app one down the line. As new application accounts are onboarded, specific routes will be appended here for app two, three, four, et cetera. Let's briefly talk about VPC routes to understand how routing decisions happen at the origination point. This diagram shows VPC route table for app one, the first route has been inserted, which states that for any non local route, destination is specified as a transit gateway, which then gets full control of transit routing circling back the goal of this presentation has been to look at network architecture approach under the purview of zero trust. What if we wanted to take this a step further? What if a Dev account shouldn't talk to UAT? What if dev environment shouldn't even have a network path to UAT? What if QA cannot talk to production? What if the control state that environments cannot mix? Dev environments are only allowed to have a network path to other dev environments, QA environments are only allowed to have a path to other QA environments, and so forth to cater to this additional requirement. This is how the design can be enhanced. Instead of a single spoke route table, design will extend to four transit gateway route tables, Devspoke QA spoke, UAT spoke, and prod spoke. With this approach, transit gateway attachments of Dev vpcs will be attached to Devspoke transit gateway attachments of QA will be attached to QA spoke table, and so forth. By raising the number of transit gateway route tables, higher granularity of routing control is permitted. In addition to existing routes that force traffic to firewalls, a fourth route can be inserted of type black hole. Therefore, on a despoke route table if the destination IP is from a sided range of QA, UAT or production vpcs, it will be directed to a black hole. This will ensure there's no network path from a dev account to any other non dev account. Similarly, black hole routes can be inserted on the QA spoke, UAT spoke and prod spoke route tables. I will leave with one final food for thought. What if there is a new incremental requirement to have separate inspection appliances production firewalls being separate from nonproduction firewall appliances? The design remains extensible for this requirement. A new set of firewalls egress inline and on prem will have to be deployed in their own vpcs and a second inspection transit gateway route table will need to be introduced. There is a rising cost of data breach that we started off the discussion with. Even more impactful is the hit to the brand reputation and a loss of customer confidence when data breach occurs. Importance of security architecture cannot be overstated. Zero Trust provides an excellent reference architecture that allows organizations to incrementally improve their enterprise architectures. Thank you all.