CyberArk Leveraging CyberArk for Traditional and Ephemeral Application Secrets Management

so hello everyone my name is brandon trap instead i'm an engineer with with cyber-ark and in this session we'll be talking about application secrets management the removal of hard-coded secrets from traditional apps as well as ones that exist in a more ephemeral state and we'll be doing this as a truncated session so it won't take too long to kind of go through and and watch so if you've not heard of cyber-ark we perform privileged access security that is the vaulting and rotation isolation monitoring and analytics a very powerful accounts and in many cases when we think about a powerful account our minds go to beautiful smiling human faces but with more frequency breaches are occurring because not of humans well humans of course are the Nexus of a breach but hard-coded secrets existing in code are being uncovered by third actors and rightfully so they're all over the place we need them to fuel our automation to fuel our database transactions to fuel our businesses and if we don't think about it beforehand the urge to put it inside of a file or within our code it's just too great to ignore I'll submit to you though what has changed is we now see more and more of these artifacts and secrets existing in public repositories the internet never forgets the internet is also a great mechanism for finding these types of Secrets if you're looking for a fun way to look into this go to github type in your favorite secret named cloud provider underscore secret underscore key service principal DB password just password if you really feel like it and sort by recent code commits I guarantee you or I'll flip over and eat a bucket of scorpions I probably won't do that but within a certain amount of time twenty minutes thirty minutes five minutes you'll find somebody's secret right there in a public repo so cyberarts goal is we want to make sure we're removing them and we want to be sure that we're dealing with we can do this for both more legacy applications but also more more common ones today that are ephemeral cloud based things like that so we handle that in two ways the first is using what we call the application identity manager a provider or agent based model that sits right with an application think websphere WebLogic tomcat JBoss on prim application servers now site Roark does not approach the use of the local stuff lightly there needs to be a good reason why I'm dropping something on to a system the reason here is twofold the first is for availability if a production application is authenticating hundreds of times every second even has to wait for a moment because of a hiccup that's potential SLA violation fees that a corporation will need to pay if an application is down that serving web-based store traffic on Black Friday Christmas has now literally been ruined because of downtime so we want to be sure that it's available but the second piece and the one that's more compelling for me is authentication Sidewalk is a vault if we pull secrets from a vault we need to authenticate somehow but if I authenticate to evolved to pull a hard coded secret with a hard coded secret I really haven't done very much of anything have I've done a lot of work for very little value so the other cool part about being local is I authenticate an application based on what it is not what it knows things like whitelisted host run as user file path of the calling stack Wyatt listed hash for instance so that application changes or class changes authentication fails these are all things that I can do using this attribute based off locally so those the two benefits of being local but what if we don't want something local what if we have a more distributed stack well for us that start a number of years ago by doing the same thing locally on just a very specific server and then allowing applications to communicate using web services so if you wanted the old school or restful api now we can still authenticate using attributes here we lose things like hash and a file path because we're not there to validate it but we gain things like the mutual SSL or TLS handshake as well as certificate serial number valid so these two things these two elements allow us to remove those secrets and we support things locally like java.net c and c++ comm and then have a command line catch-all for all things non compiled and if you're not using that restful api and this works really well for a decade and then stuff started to change five years ago six years ago virtualization became the hot item so our application structure got a little bit smaller then containerization happened and again a little bit smaller too now with the move to containerization microservices all those things that make attribute authentication great mean nothing so we had to look at better ways of authenticating applications and processes that are ephemeral based on where they live who brew Nettie's authenticators openshift authenticators AWS I am authenticators as well as azure these things can be used to establish identity and while they aren't as robust as full-on attribute off they get us closer to a desired state without having to use some sort of baked in secret now if you look at a pretty simple pipeline there are a number of credential transactions that occur here starting with the dev ops domain controller Jenkins so if Jenkins is doing one simple push it authenticates in this case what six times that's Skynet right there we're empowering these non-human processes with privilege and then thinking about it later on down the line so our goal is to be more proactive with that I want Jenkins to have an identity I want it to authenticate strongly somehow and only be able to pull certain secrets that are applied with that identity applications should have lease privilege too it's the difference between me offering you to come and vacuum your house every Thursday in exchange for your door key you may say oh that's great yeah wait a minute I don't know if I want Brandon at my house but somehow we allow applications to authenticate using the keys to our kingdom every single day without a second thought applications should be viewed as people now speaking of the Terminator reference I'm a big fan of terminator if you've not seen it skip over Terminator 1 and go to Terminator number 2 now this guy was in Terminator 2 that called miles Dyson miles was one of the engineers who created Skynet the artificial intelligence that decided in order to protect humans it would destroy humans but somebody miles and his team said that's a good idea hit the button turn scan it on bad things happen Arnold Schwarzenegger shows up that all goes down the point here is that we should not forget about human access to the same automation tools that are building up our RPA and our DevOps pipelines human access should be controlled in a similar vein that you saw previous access in our sessions around Windows systems NIC systems - if you want a good example of this popping on to showdown and searching for something like Jenkins will likely pull back very similar results here I found over what is it twenty two hundred fourteen thousand instances of Jenkins over thirty three thousand of them had port 8080 open I connected to ten and found that seven of them didn't even have authentication enabled so boom I was there I could see the project's the jobs the hard-coded secrets within of the three that had authentication enabled two of them we're just admin admin admin password no big deal but these are privileged operators these are privileged things that have tons and tons of secrets in them we want to make sure human access is controlled just as well as non-human to otherwise our carts come before the horse and we're just being dragged around in all kinds of different directions - the other thing is centralization becomes key many many platforms offer secret storage capabilities and as a security practitioner in order to keep up with development you would have to either a let developers manage these and eventually they're gonna say hey maybe security you should help me manage them you have to become an expert or be look at a way to bridge all of these together so for us being sure that we were ephemeral using native application authentication in a more elastic state but also bridging islands of trust together was key the other element for us that changed was we had more community-driven those agent-based models were enterprise level stuff you'd have to use cyber-ark subscribe to cyber-ark and then you would deploy them but that doesn't help if you've got a project just now starting it doesn't help if you're a start-up looking for an integration point so we developed and release well we actually acquired a solution called conjurer that handles secrets management we then open sourced it after acquisition so while there's an enterprise component you can get started with secrets management for ephemeral applications as well as the removal of leveraging API through the use of an open source tool called summon or even the brokering of applications without passing secret secrets rather using our secret 'less project so the past two years have been key in cyber-ark to actually becoming more community driven it's one reason why we look at applications kind of the architecture is well it's kind of a rainbow isn't it traditional ephemeral various companies will fall somewhere on that magical rainbow I just drew you want to be sure we can handle application authentication there now I mentioned Kandra was containerized so while we do want to leverage the core platform the enterprise password vault the thing you saw the source of secret truth we need to be able to deploy as a container in to kubernetes in to openshift so it's why we containerize this element secrets are replicated out as needed of course the conjurer container itself has a concept of redundancy standbys with Auto promotion and failover as well as distributed elements called followers which help us scale out and scale up so just like those Sadie our vaults earlier just like those providers we want the element of secret storage and retrieval to exist close to our applications we don't want to have to traverse a ton of different network boundaries to get our jobs done it slows down our developers it introduces risk and challenge into that process too now with the last couple of minutes of this session I do want to show you a couple of demonstrations and we'll look at it two-fold we'll look at it from the concept of a more more traditional application and then we'll also look at a containerized application provisioning process is part of the session here welcome you as I will flip over here I'm gonna connect to a a Knicks based application server in my environment just as myself I can get my IP right inside I have a very very simple toy set of Python scripts once called that once called call it good again we're really great at naming stuff this is this is me personally being great at naming stuff in in the bad example all we're doing is authenticating to a node and then catting a file it's a simple process using using a px SSH however you'll notice in the third line here in order to do that authentication we're referencing a file actually yeah you're resting a file called password let's take a look at that file really quick ah cool the hard coded secret well it's not in the code though right it's an external file and that makes it a little safer well it's in the same directory so if I hit this system I can find it too now if I run it q python is just an alias to ignore any any security checking I'm actually passing this over HTTP s but with an self-signed certificate probably should use a signed certificate in your environments but I'll go ahead and run it and apparently fail maybe well go ahead and fail running it but what I will do is I'll tell you what happens it doesn't work because I've actually changed password the demo account password is no longer that value anymore your unicode yeah I should probably put in the appropriate unicode character there that time I'll do that but but for now let me redirect you looking at the good script now yes there's some more logic here but what you'll see first is we're actually calling cyber-ark and we're using rest to do this so we're using our centralized secrets management our central credential provider we call it so to do this there are a couple of things you need to pass who you are what you want and sometimes how you want it in this case it doesn't matter here so I'm saying cyber-ark my name is demo app this is what we call an application identity it has privileges in cyber-ark just like a person does it can only access these secrets and only at this specific time or these times and only if it passes these authentication attributes where it's coming from who it's running as what hash it may exist as so we're stringing those off of an app ID just like we would a flesh-and-blood person from there I'm constructing a query to pull back a unique secret in this case it's one called demo account but you can use any number of vaulted attributes user name address database vty awesomeness vector favorite color doesn't matter you store it with it you can query upon it and then in this case we're turning everything back is a JSON formatted dictionary so all I've got to use its parse out the appropriate stuff and then pass it in to that same connection string as before no secret here right I don't see any kind of secrets well I see a secret of Brandon's bad coding but that's really it's not a secret everybody knows that so if I run this good we actually reach up the sidewalk grab that secret use it to authenticate and cat our happy little moose file showing that things nicely worked for us it shouldn't be friction full we should be able to allow our application to keep authenticating all day long without any sort of mishap if we're doing hash based authentication use the API to programmatically update those hashes as part of your sdlc but what if this was coming from a container well that would work too but the issue here is how I dull out identity and how I actually define the identity in general so this was using aim I'm gonna switch over and show you something open source for the last portion well pop back to one of my little little cloud-based demo environments here get our maximization on now just to give you a quick look at the environment we'll do a quick refresh of this so this is a solution called we've scoped its container visualization container it's open source technology it's not cyber-ark but I have all of this stuff this pipeline running on a docker host you see things like Jenkins is here an Sable's here as well as a number of other elements too but what you'll also see is a conjurer master we have conjurer open source deployed in the C environment it's actually storing secrets for me so I'll be pulling from there and now that can of course pull secrets from the cyber core platform it can be put together it should be put together but we'll get it going now I've got all of my build script stuff like that existing in Jenkins I'll go ahead and log out here first of all I mentioned earlier unauthenticated Jenkins instances mine is authenticated cool part here is Ava doesn't know what her secret is it's so privileged that we're storing it within cyber-ark we're rotating it so just like in previous sessions Ava's gonna use the old-school method she'll log into the console find the account she wants to use click connects will then programmatically connect her without exposing the secret so that human access into my pipeline it's very very present here now cool part here is where browser-based stuff that you want to use from the console we use selenium on the back end so you can create new plugins incredibly quickly and not use some sort of cyber art proprietary scripting flow for this so we want to make sure that you as administrators have the ability to add more plugins that aren't supported as part of our Alliance programs and stuff like that but what I'll do is part of my my little flow here is I'm gonna need to spin up new containers so I'll take the role of an operations engineer my task is to build an auto scaling process for a containerized application and in this process what I'll do is I'll generate what's called a host factory token so a little identity granting ticket that can be cited or restricted or time-based to when I spin up these containers as part of the docker onboarding process through variables I'll provide that Tok when the container is ready to authenticate back to Conger for an identity it'll trade it in get at least privileged identity and begin to pull a secret every five seconds with a little toy application but I've automated all of this so it'll happen on the back end so I'll go ahead and run my little container spin up guy pop back into my loo visualizer and you'll learn to see stuffs happening out there new containers are beginning to spin up each of them getting an identity inside of cyber-ark getting lease privilege authenticating in this case using an artifact of that host factory process but also this could be done using say a kubernetes Authenticator and openshift one or AWS as I mentioned earlier if I pop into one of these guys here maybe we'll do web app hit the attach I've just got a little script pulling a vaulted and rotating secret here so you've got that access all from running one job if I want to trigger say a rotation it's as easy as either a letting it happen automatically or be lettin Jenkins do the work so Jenkins is actually via API saying hey cyber art rotate this and then we impose that upon the next one if it's kind of hard to see the first one was eight three something something something second one was B seven something something something now policy here is also handled as code so if I wanted a version two of my policy that could all exist inside of my code repository so Jenkins is actually pulling everything right here from my Maya God's instance which is OSS github so it's all existing here is code dog has an identity Jenkins has an identity ansible has one two as well as the things the containers themselves that are doing the work so regardless of how you look at it on prim traditional to ephemeral you want to make sure we've got something to manage and better yet everything I've shown you here as part of this part of the demonstration not the Python script that was close source but all this is available in an open source state in fact this is a repository called C demo that anyone can deploy with all the same elements the entire pipeline of the users that I showed as part of the demonstration here the human access through DevOps environments vastly important as well as of course replacing hard-coded secrets with strongly authenticated calls back to a solution like cyber-ark oh yes sir so or an organization that maybe already has built out a pretty mature single sign-on infrastructure what's your value to them if they're more or less happy with what they've got on single sign-on and maybe they've got some good credential management in-house like what where weird why would they want to look at your product excellent question I'll handle in two parts the first is if we've got a mature single sign-on strategy use that as an element of authenticating into cyber-ark um we talked a little bit about more traditional multi-factor earlier but any sam'l 2.0 identity provider and be used for Federation into cyber-ark okay on the other side if secrets are being federated least privilege level secrets keep doing what you're doing right leverage the controls you have look at us for cases where that doesn't extend out so the shared credentials application based stuff that isn't using Federation first and then assess where you stand but don't defeat controls that are working fine for the sake of deploying something new that's a really good way to create more effort for yourselves and get very little security value okay can you talk a little bit about like what what kind of relationship you have with office 365 or or a DFS you said it doesn't work with a DFS yep yep so when it comes to things like office 365 for instance Maui we have users who could potentially federate in but we also have privileged systems we've potentially looking at Azure Active Directory stuff like that we manage those exactly as we would with the non prim ad instance what changes is the location of the assets with a DFS if we're using that as an identity provider then that can simply create the ok users allowed to sign in here's who they are but even then we still want to integrate with some directory to provide the auth in so in this case a DFS would provide the auth Leslie I'm sorry a TFS we provide the off in the directory will provide the author Z one thing in particular about on Krim sam'l implementations is there are inherent risks to the fact that the identity provider doesn't talk with the service provider on Prem can be an element of breach so we want to make sure if we're looking at that to do you the appropriate hardening and Trust on something like our a DFS instance right we cyber-ark labs put out a paper on what we're calling gold and sam'l that looks specifically at a DFS layer compromises because of the disconnect between IDP and SP it's definitely a good read if you've got time to check it out on the blog thank you my pleasure

Channel: Tech Field Day

Views: 2,219

Rating: 5 out of 5

Keywords: Tech Field Day, TFD, Security Field Day, XFD, XFD1, CyberArk, Privileged Access Management, PAM, Passwords, Hashes, Reuse

Id: W6KPmc65kcc

Length: 23min 0sec (1380 seconds)

Published: Wed Dec 12 2018