In the last part of this blog series, we expand upon our previous discussion of utilizing a Zero Trust Operating Model and Trust Profile Technology to build Aporeto’s application-aware security solution. Our post this week addresses how these components work together in one centralized management system, the Aporeto Platform, alongside procedures for both authentication protocol and Transmission Control Protocol (TCP) to establish a secure connection.
Aporeto runs in a fully distributed fashion across physical and virtual hosts to deliver fast, scalable performance that scales as hosts are added, and to provide high availability while enforcing end-to-end application security. Aporeto is centrally managed, provides comprehensive control and visibility, is easy to implement, and provides veriﬁable security, even for very large scale applications. Operations and Security personnel beneﬁt from improved visibility and control over mission-critical applications that are in production. Management of the Aporeto Platform can be achieved through the Web-based GUI, CLI or REST APIs.
Aporeto utilizes a lean, clean, extensible architecture that builds upon a foundation of trusted identities operating in a zero trust environment. The Aporeto Enforcer uses modular, pluggable modules to permit or deny access to the network, services, encryption, APIs of the platform itself, ﬁle system, and secrets services. The system is extensible, so other 3rd party modules can be added. The analytics and policy management layer ensures that operations are running smoothly, manages policies and provides end-to-end visibility of the security posture of the cloud-native application. Enforcer is provided as an open source project (Trireme) to provide guidance about how to write 3rd party Enforcers to extend the platform.
The Aporeto Platform can federate with existing Identity and Access Management (IAM) systems in order to authenticate Enforcers running on hosts, so they can become trusted participants. For Google’s IAM, OAuth2 is used. For Amazon Web Services, the AWS Identity Document is used. For a corporate IAM, LDAP is used. In all cases, the host provides credentials to the Aporeto Platform and, upon successful authentication, receives a time-based token that is periodically refreshed to ensure tight security.
TCP Traffic Communication Protocol
The Aporeto Enforcer on the initiating host will work with the Aporeto Enforcer on the receiving host to establish the TCP connection if the Trust Proﬁle of both PUs are known and the Network Policy permits it. All TCP traffic goes through the Aporeto Enforcers to ensure that only PU interactions that are explicitly permitted by an appropriate Policy get through.
As described in RFC 793, two hosts running TCP/IP establish a connection using a three-way handshake protocol. First, the initiating TCP client sends a SYN (synchronize sequence numbers so later packets can be kept track of) message to the listening TCP server. Second, the listening TCP server acknowledges this request by sending a SYN-ACK back to the initiating TCP client. Finally, the initiating TCP client responds with an ACK and the connection is established. SYN ﬂooding attacks and effective countermeasures are well known and are described in detail in RFC 4987.
The Aporeto Enforcers which run on each host use a similar three-way protocol to establish a secure connection and take similar measures to foil SYN ﬂooding attacks. Additional information is attached to the SYN, SYN-ACK and ACK messages as a signed JSON data structure to facilitate mutual authentication of the PUs that wish to participate in an interaction.
View our blog here to better understand Aporeto’s platform, and how it protects cloud applications from attack by authenticating and authorizing all communications with a cryptographically signed identity assigned to every workload. In case you missed the previous phases, view part one here and part two here.