Even as DevSecOps teams move deeper into infrastructure as code deployments, most orgs still need to allow ops teams to access servers, containers and clusters for incident response, debugging, and forensics. But how should this access be granted?
This talk will cover best practices and risk-benefit tradeoffs of different architectures for secure human access to cloud infrastructure. We do this by first describing each architecture, and then describing a real-life incident that challenges it’s security.
We start with the classic SSH key + VPN architecture. We then discuss ransomware attacks that have exploited this classic architecture to pivot from compromising one target in a victim network, to compromising other targets on that same network. We use NotPetya as an example in this form of lateral pivot, with a nod to attacks from Operation Aurora as well, as well as less-publicized attacks of interest.
Next we cover segmented jumphost architectures (where there is a different jumphost for each segment of the infrastructure). While segmentation is important for decreasing attack surface, we discuss how the jumphost creates a single point of compromise for the segment it protects. We use the example of the “Fluffy Bunny attacks” to illustrate the challenge of this architecture.Next, we introduce zero-trust security architectures, where access to targets is granted via short-lived credentials that are easy to revoke. While these architectures make it harder for an attacker to steal a user’s credentials, they can also introduce insidious and unexpected single points of compromise. We then talk about two classic security incidents that inform the design of zero-trust architectures:
We conclude by discussing why it’s important to deploy architectures for secure human access to cloud infrastructure, that eliminate single points of compromise. We cover some key principles in designing secure architectures, including not trusting single central authorities with root-level credentials, not granting administrative access widely, and strong authentication on all connections.
Even as DevSecOps teams move deeper into infrastructure as code deployments, most orgs still need to allow ops teams to access servers, containers and clusters for incident response, debugging, and forensics. But how should this access be granted?
This talk will cover best practices and risk-benefit tradeoffs of different architectures for secure human access to cloud infrastructure. We do this by first describing each architecture, and then describing a real-life incident that challenges it’s security.
We start with the classic SSH key + VPN architecture. We then discuss ransomware attacks that have exploited this classic architecture to pivot from compromising one target in a victim network, to compromising other targets on that same network. We use NotPetya as an example in this form of lateral pivot, with a nod to attacks from Operation Aurora as well, as well as less-publicized attacks of interest.
Next we cover segmented jumphost architectures (where there is a different jumphost for each segment of the infrastructure). While segmentation is important for decreasing attack surface, we discuss how the jumphost creates a single point of compromise for the segment it protects. We use the example of the “Fluffy Bunny attacks” to illustrate the challenge of this architecture.Next, we introduce zero-trust security architectures, where access to targets is granted via short-lived credentials that are easy to revoke. While these architectures make it harder for an attacker to steal a user’s credentials, they can also introduce insidious and unexpected single points of compromise. We then talk about two classic security incidents that inform the design of zero-trust architectures:
We conclude by discussing why it’s important to deploy architectures for secure human access to cloud infrastructure, that eliminate single points of compromise. We cover some key principles in designing secure architectures, including not trusting single central authorities with root-level credentials, not granting administrative access widely, and strong authentication on all connections.
