Earlier quoted context omitted.
Indeed, and the industry term for this is posture assessment. And many companies take this a step further and permit access only with organization-issued equipment, even if you possess authentication credentials.
Is posture asking the device to tell you it’s ok ? For the ignorant like me it seems a motivated and capable adversary can have an insecure device send an ok posture
Restrict Access to your internal websites on AWS with BeyondCorp
51–59 of 59 posts
Re: Restrict Access to your internal websites on AWS with BeyondCorp
#52Re: Restrict Access to your internal websites on AWS with BeyondCorp
#53Earlier quoted context omitted.
I would be shocked if they don't have a whole team of people keeping up on the threat models for client workstation windows, macos and linux endpoint devices, and creating the equivalent of windows active directory registry pushes+other software loads to guarantee the condition of an endpoint device. Otherwise how do you know an endpoint device (assuming it's on a network segment with a default route out to the inter…
I wonder if there are any big companies that require HDCP and some sort of "trustworthy USB devices only" system.
Re: Restrict Access to your internal websites on AWS with BeyondCorp
#54BeyondCorp sounds so weird, why not use Zero Trust which is the industry (non Google) term?
Re: Restrict Access to your internal websites on AWS with BeyondCorp
#55The BeyondCorp paper explicitly mentions that the device state is taken into consideration when giving access to a user, i.e. that the device is identified and controlled, not just the user. It seems to me like it is an important part in the BeyondCorp access model, otherwise wouldn't this just be a SSO portal?
You are correct. The solution presented is not a BeyondCorp but rather an SSO implementation that adds authentication to the internal application. For BeyondCorp, it essentially: * Must be Layer 7 protocol, access privilege aware (achieved by an identity-aware access proxy). * Promotes authorization as opposed to authentication only. * Should be able to enforce security policies (time, location, context, 2fa). * Must…
Re: Restrict Access to your internal websites on AWS with BeyondCorp
#56This code scares me: https://github.com/transcend-io/beyondcorp-cloudfront/blob/m... This encourages a behavior of copy and pasted authentication javascript from service to service. The ALB approach from the article at least centralizes the SSO dance in one place, but still a typo in terraform would be very hard to detect. The BeyondCorp approach Google uses, as far as I know, relies on sophisticated proxy servers in…
Perhaps I don't see what you see, but this is server-side javascript (cloudfront calling a 'lambda at edge' function - similar to Cloudflare Workers). What's particularly scary about it? As for "a typo in terraform would be very hard to detect" - perhaps, yes, assuming it didn't fail outright. To mitigate that I'd expect anyone deploying this for real to protect anything valuable would ensure unit tests were written…
Re: Restrict Access to your internal websites on AWS with BeyondCorp
#57Earlier quoted context omitted.
You are correct. The solution presented is not a BeyondCorp but rather an SSO implementation that adds authentication to the internal application. For BeyondCorp, it essentially: * Must be Layer 7 protocol, access privilege aware (achieved by an identity-aware access proxy). * Promotes authorization as opposed to authentication only. * Should be able to enforce security policies (time, location, context, 2fa). * Must…
Since you clearly seem to know what your talking about: What would be a good resource for getting started with zero trust networking?
(1) Zero trust access (like BeyondCorp, protects application and services when a user, user credentials, user devices are compromised)
(2) Network micro-segmentation (contain impact when one network segment is compromised, dynamic network assignment)
(3) Zero trust browsing (protection for users from getting infected with malicious contents served by trusted but compromised websites)
Honestly, I am only more familiar with zero trust access, and for this, I can recommend you first read -> BeyondCorp A New Approach to Enterprise Security [0] by Google. The trend was kickstarted from that paper
Re: Restrict Access to your internal websites on AWS with BeyondCorp
#58BeyondCorp sounds so weird, why not use Zero Trust which is the industry (non Google) term?
Zero Trust is about the conditions inside the perimeter; BeyondCorp is about ingress through the perimeter. Things may be wide open on the interior side of the proxy. Or things may be locked down tight even inside the VPN.
Re: Restrict Access to your internal websites on AWS with BeyondCorp
#59Earlier quoted context omitted.
Zero Trust is about the conditions inside the perimeter; BeyondCorp is about ingress through the perimeter. Things may be wide open on the interior side of the proxy. Or things may be locked down tight even inside the VPN.
The point if these concepts is that there is no perimeter I thought?
The network where the services actually sit becomes, in effect, even more private.