PW - Practical Perimeter-less authentication solutions for Startups using AWS native solutions

all right so I asked chat GPT why did the attackers Target do well they wanted to brew up some trouble and leave everyone hopping mad with that thank you B zel for the opportunity to present today uh I'll share approaches for implementing authentication for internal applications uh specifically targeting small and medium Enterprises uh using AWS and zero trust principles the slide deck is on the QR code so please feel free to scan it download it I'll give you 5

Seconds all right here's our agenda for talk today I also want to disclaim that any of this work is not affiliated with my current or previous employers um it's the result of my work that I've done since beginning of this year with small and smaller companies as a consultant adviser with over 16 years of experience in security industry I've had privilege to work with large Enterprises like PayPal and Robin Hood um however my recent focus on solving security challenges for small and small and medium businesses has sparked this new passion of researching scalable cost cost effective and time efficient Solutions while we did not know what happened with all the breaches that we saw in the

first slide I didn't go into every detail of the breach because I don't know all the details uh I hope you you got draw some commonalities uh the data that was breached is obviously I can bet on it it was not publicly available that wasn't not expected to be publicly available um it meant that attackers could probably have hijacked the private networks or SL vpns in some cases or they've have they may have a malware on the device from where the users were trying to access the data or there are a lot of different ways of of attacking the uh the scenarios one clear thing is that the protections provided by traditional vpns are no longer

sufficient due to the use of cloud on top of that we have vulnerabilities in the VPN software itself that are worth noting so what's zero trust do we have a solve here let's see zerust is a framework for performing continuous authentication and authorization of actors based on different signals as you see in this diagram you have device signals from where the what's the device and what's the posture of the device you have Network signals geography region IPS um you have actor Authentication which is either password based o MFA enabled or not you have permission signals of the authenticated user what permissions they have to access the resource or not and depending on all of that there's this Central thing allowed

to access enforcement Point says whether I can access the resource or not and that it happens on a continuous basis that's the framework guideline and depending on the criticality of the resource the policy can be twined and configured it's sounds great from security perspective that we are doing this continuous Au and and OD Z but implementing it could require a lot much lot of work for the company and specifically we're talking about small and medium businesses here the question is how do they prioritize security over business goal of survival I had an opportunity early this year to work with a company that a smaller company that had team members in us and India the staff

members were encouraged to buy their own laptops use it for work the the company also employed Consultants um they can work from their personal laptops no no restrictions whatsoever as a malicious actor my motivations to to compromise a smaller company could be that I want to attack abuse their infrastructure and use it for my own gain that is pay my bills on the company's dime let the company pay my bills lck their in intellectual property and hold it for ransom uh get hands on the sensitive data that the company has and use it use it for my financial gains if an attacker locks down a database of a company and a company is large enough they can always negotiate

or pay the ransom so a smaller company like mine that I interacted with uh it could be catastrophic it could simply Just sh their business in this particular case our company's infrastructure is all in AWS which is a good thing uh I'll tell you why I'm simplifying the setup here there's a Dev account uh Dev AWS account and then there's a produ production AWS account we have a VPC that has public subnet and private subnets the public subnets holds a web server which holds a we web application uh private subnet has application servers databases and things of that nature but when we talk about a malicious actor I have multiple entry points into the company the multiple entry points are it

could be application vulnerabilities on the VPN servers or the app servers uh or on the right on the left side of this you have long live credentials SSH Keys user M passwords for internal apps uh VPN configs that don't really change the private keys on don't really change uh and that's a lot I can I as an attacker can abuse that and use it for my advantage uh I'll talk in the next slide I'll talk about approaches how to minimize the need of these static credentials and use zero trust principles I'd like to touch upon a capability from AWS called AWS systems manager um I'm I'm hoping some of you have already heard about it uh this

capability when clubbed with uh components like IM identity Center permission sets IM policies session manager can actually provide a formal access to the infrastructure to private resources without the need of a VPN the sample policy on the right that we see here uh it just says that an actor who assigned this policy can access resources tagged as development using eal access what that means to our diagram here from an attacker perspective now the yellow the red box is turned into yellow which means that there's only limited period of limited window of time where these credentials are valid when an attacker can actually use it but only for use it for limited time we certainly have uh

vulnerabilities or possibilities on the public subnet of production hosts but that's going to be the case um let's jump into a demo into how that actually looks in

action all right as I go into the IM identity Center okay hopefully this works okay um and I authenticate using my IDP credentials and MFA I go land into the AWS console and from there I can get temporary credential to log on to AWS and these temporary credentials I use an environment variable to just do my job I have rapid scripts here which are which are basically s into instance using um SSM and as a developer I'm just going in SSH and do my job what I need to do uh on the host itself the second example that's going to come here next is how to access the internal web server itself um that that's a port forwarding capability

of SSM that allows us to uh forward a port local port on the Local Host to a remote port and that that's how you can just simply access the web server uh through port forwarding so it's just going to come here access the web server using Local Host engine server up but when I terminate the connection uh the tannel is down I can no longer access the web server third uh example is accessing the RDS database or my SQL database using SSM I have a private database I want to access it do my job run some commands how do I do it um and that uses the remote board forwarding capability of SSM that was

recent uh that was released in I believe 2022 um I just connect to the tunnel and that using the tunnel I open a t terminal use my SQL uh command line utility and then boom I can can actually access uh the database directly what not what I have to

do so once the ter once session is terminated I can no longer access the

database all right so we saw what SSM can do but there are needs in an application or in an Enterprise where these web applications cruising port forwarding is is considered a friction um and accessing across multiple applications users may be tricky that's where AWS verified access uh comes in handy aw verified access is a zero trust implementation by AWS to access internal web apps without a VPN the components here are listed here let's just talk about how do they overlay with a previous architecture with the previous framework that we talked about the the user trust providers listed here are the ones that are going to be enforcing authentication strong authentication and authorization the device trust providers give us device

signals um and then we have verified Network signals and permissions assigned to the individuals uh are grouped here as verified access groups and they can be configured using Cedar policy Cedar is a policy definition Language by AWS verified access point is the actual public endpoint through which the resource is exposed and verified access instances are just an aggregation of all these different components together let's jump right into a demo the beauty of a AWS verified access is that you would access the resource as if you're accessing the resource directly on the internet here I am accessing the resource I'm redirected automatically to the uh IM identity Center the we application that you saw it didn't have any authentication I

authenticate using my MFA and once authenticated the it runs the DAT verified access runs a policy check to allow access to the app or

not how does it work in in function uh how is configured behind the scenes so we saw here that the the domain application engine. sb. today is actually mapped to an EC to instant on Bo 0 which is insecure Port as security professional we would not want anything to be rning on Port 80 but in our cases it's possible because it's all it's all in the public private subnet um and it's all behind the security group that allows uh Port 80 to be exposed only to this particular service here and then we have verified access group that is allowing a policy saying that anybody who has email address like SBD today can access the resource or once they

authenticated you can have much more complex policies based on principle actor and resource here the policy is being referenced as this is the trust provider that we talked about a user trust provider it's being referenced by a name called Dev blog instance okay before I come there uh while all that sounds fantastic there are some practical considerations we need to be aware of um one of the things that I specifically with ver verified access is a relatively costly service and why is it costly what what the cost implications are it's actually AWS charges it by every endpoint or every app exposed per app hour um there are charges of amount of data that is being transferred back and

forth using the endpoint take a look at the monthly and yearly costs of if you have 1 10 and 50 applications exposed using verified access it's worth noting that it's not a pay as you use model from a a user interaction standpoint but pay as active ST cost model um the following two slides discuss on different approaches on how we can minimize the cost while keeping Security in Balance um one particular approach that I can think about and and we used is we can put similar trust level applications behind an application load balancer and then ALB is the one that is in is front ended by uh verified access endpoint this is good from a cost

optimization point of view but it also limits our policy rules that the policy rules cannot be differentiated based on app one or app two resource access the policy will only know the ALB endpoint other approaches is to terminate the verified AIS and point when not in used this can be achieved by implementing um bring up and bring down kind of architectures uh using automation uh in this example we just talk about the endpoint verified access endpoint coming up at the beginning of the day um and when when the work is done when we are sleeping when the workforce is sleeping just turn destroy this infrastructure it takes around 10 to 15 minutes so if your threshold of bringing

up and bringing down is okay with 10 minutes then you you can implement this strategy and reduce the cost by uh potentially around 50% this concludes my presentation but here a quick recap um in my opinion very uh zero trust principles are must have for even smaller companies um AWS SSM is a good capability to explore and keep in mind without incurring any cost if you can um if you have a smaller team and limited resources uh verified access is the Great mechanism however the cost is a limiting factor uh for smaller companies um AWS at someday will hope I hope that will minimize that cost and we can make it more much more uh

useful if you can remember just one thing and only one thing from this presentation I urge you to take this implementing good security controls is not about money and time it's about [Music] intent however we also need to make sure industry keeps that in mind and makes security controls accessible to companies of all sizes thank you so much for listening to my presentation here are the code references for the de uh for the code demo that was presented earlier you're also welcome to join the slack Community if you want to discuss about how to help smaller companies in making them more secure uh that's all I had open to questions if we can have some time

questions raise your hand go

ahead hi thanks um I didn't understand how the access changed once you had like the verified like cuz you were like sshing into the database or into the on the on the virtual Network then you showed that then you had the verified access and then you logged in like through the UI and the policy was applied and then how did you get access to how could you run your database commands I didn't understand that how that works yeah that's a great question verified access actually works with only HTTP and https endpoints and not with your database access um so when you want to access the databases SSM is the best bet to go forward with uh n SSH into the

containers SSM is the right solution to go forward verified access will not help verified access is is to solve for situations where you have a Dev web server Dev application running and you want to test it out or you have a Jenkins instance that is hosted in the internal Network then you want to test it out uh Without Really um adding a lot of authentication capabilities on the on the app itself any more questions I have honestly to you know I need to be honest with you I never worked with AWS so I can't really think of questions for you on this one so thank you again for being here and doing your talk thank you