CyberArk Vaulting, Rotation, and Native Access Control Overview

hello everyone my name is Brandon traffic stats I'm an engineer with cyber-ark and in this session we'll be talking more about the cyber-ark technology so we'll be diving down into the elements of our core platform things like vaulting rotation native access controls making sure that users don't completely have to change the way they do things in order to leverage the security as part of the platform now this session will be in two parts will of course have the general overviews showing you kind of how the tech works at the high level and then my favorite part will show you a demonstration of how the solution works as well a typical day in the life of a number of different user personas so credential vaults where we're going to put all of our secrets once we've discovered them either programmatically or we've done it automatically or integrated with things like cloud watch and AWS to find new easy to whatever way we did it we put the secrets somewhere so for our user here Brandon Bob Tim Phil John IVA beau Nina for instance they need to access cyber-ark somehow now there's an old-school way of doing that and a new-school way of doing it I'll show you both there's something wrong with old-school it's just what's been around the longest that old-school way is for our user here to pop open a web browser inside once they've authenticated to cyber-ark hopefully using strong authentication you'll see this in the demonstration they'll have access to all the credentials they care about based on who they are Active Directory group membership LDAP group membership any LDAP v3 compliant directory is gonna work ok here doesn't have to be specifically Microsoft ad but they've got access to a bunch of stuff and in the most basic of workflows they check out one of those passwords just pull it out now that can be placed behind ticketing systems place behind internal approval flows however you want to do it but they now have access by managing these secrets though I can now change them I can wash those credentials based on a policy that you said whether that's super aggressive like after every use or a little bit more permissive every month two months whatever it may be we're actually doing chain now the cool part about the rotation is we do it using native protocols we change passwords just like a human would and it's because of this we don't use any agents agents are bad and gross but we do use them in some places and they're not bad and gross they're for the core I really want to limit the amount of agents I throw out there I think I just heard a collective relief sigh of relief over the internet there maybe it was just my stomach in any case we try and stay away from that but by using a native protocol for instance if I'm rotating a root account I programmatically connect over port 22 run passwd or whatever command I need to if I'm updating an AWS access key secret key pair I launch AWS CLI remove an old access key regenerate a new one and then committed but by doing it using those native protocols in addition to not having an agent it also means that any secret that a person or non person can rotate I can bring under management and while in many cases we've seen them on yes we're just gonna ask about password rotation and that I'll trade Commission stated that there's actually more risk existed with rotating passwords frequently and versus strong passwords like their research to back that up from my experience I know there is issues in people creating the strong passwords because they have to do it so often they'll generally just redo the same password or out of one or change it so many times they can go back to the original but when it comes to like actually having it automated is there an issue with it and changing so often that actually starts to be predictable excellent question and very good point when we're looking at human generated secrets if you're anything like me your corporate policy is to regenerate your password every two weeks they're gonna be a lot of Mexico exclamation points at the end of that when we see users who have privileged alternate accounts brandon underscore admin for instance a lot of times that's a permutation of my lower-level account - so while there is risk there when we look at the technical kind of risks of programmatic password generation what can happen is if we rotate so incredibly often every five minutes for instance operating systems will need to keep up we've got a pool of accounts that also need to be rotated too so we see more operational risk there and less of the security rest side of things as well so I think the the FTC's guidance was primarily for human generated stuff but most of the time our customers are our recommendations are around either a byte uh no twice a day rotation for some accounts that maybe after every use but for privileged ones the powerful ones but most folks are dealing with regulated rotations once a month once every hundred eighty days but I'll submit to you that even if we're looking at multiple changes the very best thing to do is just rotate it once all you got to do just one time they said that you should really only rotate it in the event that it has potentially been compromised well I can't say I agree with that logic if we always acts if we've completely 100% valuated we've been compromised it's like going to the dentist only let me know we've had okay something reactive if you want to be more preventive but at the very least that's what you should do that's that's the low end right at the very least you should brush your teeth once a day you should probably do it more than once and floss too but I think that the recommendation frameworks are they're simple to do that to provide us something to build upon some way to improve our security for sure and consult their users on how often to rotate passwords based upon like users and compromises absolutely so in addition to folks who are actually leveraging cyber-ark itself also the organization's who create the policies framework auditors folks like that there's actually a large pool of folks that will consult with in terms of generating our baseline recommendations as I mentioned earlier a lot of times will come in because there's been either a a REO of compliance being audit now there's a lot of best practices too but those helped us establish a baseline that we can then create additional security on top of for sure to more yes I have follow-up question that so one of the reasons I see organizations rotating passwords is because they on the IT side have a on-call administration model or on the DevOps side are following the sheriff pattern where only one DevOps guy should have that si at any one point in time or only one admin should have access that da at any given time and then they rotate the password when that session you know ends right so there aren't call for a week they have access for a week so I question you is this on the providing of credentials does cyber-ark incorporate or support scheduling so we got 12 people in here I've access to the password this week next week Zoey has access and so on down the line absolutely there are a couple of different models that we let me look at this the first is simply giving users access to that secret based upon say limited access group membership but it can extend to Zoey being able to use that password for a week and and only Zoey once the password is checked back in again rotation is triggered automatically this extends to where maybe the check-in occurs but the password change can't happen until 2 a.m. on Thursday so maintenance windows 2 but in cases where users need to see that password it needs to hit their eyes yes we want to make sure we're scheduling and doing things like exclusive access especially when we're dealing with built-ins for instance if you have access to the built-in administrative account on the system at 1.2.3.4 my local logs will say oh well admin did this well who was admin at that time well it was Brandon for instance so yes that's something we want to do but to extend that my goal my nirvana state is for those same users to never see what the password is and we'll expand on that idea here in the in the next couple minutes for sure yes could you speak to organizations that might have an internal radius server and whether or not your product would complement that it will and it should if we're using an internal radius server are you speaking like tak ax their ACS specifically or just in general I can pretend there's a network switch and it's got a Rooter admin account that your product could manage over SSH but I've already provisioned access to that switch by a radius and Active Directory groups yeah so what would your products just manage the rudik root account essentially at that point or your natal radius yeah definitely so when we look at at kind of the two layers of access we've got the users that are probably authenticating through radius of the ACS server using their standard accounts in many cases part of phase one is not to manage a users standard account those if done properly are typically least privileged and then they elevate to whatever privileged account we're dealing with root or enable or sis DB or whatever it may be so our goal these in phase one is to manage those place the authentication into cyber-ark behind that strong radius or multi-factor solutions so that even for the shared accounts you've now got multi-factor being inherited so we do see it being a compliment but when we're dealing with kind of low-level accounts that are using multi-factor a lot of times in phase one even phase two or three we don't change that if these are least privileged accounts if they do have scopes difference or Knope radius to a publish group and absolutely okay and the same would be true for us so for instance a lot of companies are using multiple levels of multi-factor so certain groups may be leveraging radius other groups may be performing federation some groups might have grid cards for those of you who never seen a grid card it's like security bingo so you to log in you have to enter the number in B 1 C 9 da then bingo but different groups might have different requirements we want to make sure that we're respecting that when you're logging into the cyber-ark platform 2 and can you incorporate some of the same type of principles on that for when you have certificate based type authentication to switches and routers and stuff flowing the 802 11x absolutely and our goal is we want to be able to inherit the multi-factor that you're leveraging today not supplant it not replace it and this is one of the reasons why all those partnerships that you may have seen at cyber-ark we want to do a protocol base 2 so for instance if a certificate has passed for authentication and cyber-ark needs to communicate with the appropriate authority then that's done that protocol layer not specifically at vendor integration layer well thank you for the question sure so first day user logs in checks out a password they use it on the back end we're rotating it based on a policy that's been specified as complex's you want to 85 characters long with half of those being special characters it's okay doesn't matter to us as long as the system accepts all those characters now in many cases like with databases we don't allow you to pass semicolons it's it's for good reason so we can handle those forbidden characters too so we're not dropping production databases connection happens users happy life is good but let's expand on that idea when you're using a vault it's pretty important for that vault to be secure if it's just a system hanging out there with a database that anybody could access all day long you've actually made yourself worse than having passwords existing in the minds of your users so for us security is and must be uncompromising our vault itself the cornerstone and we operate in a hub-and-spoke type architecture so the vaults only job is storing secrets but this vault itself is hardened with a number of different security layers some of what you're seeing here within that vault we have these logical containers called safes safes are what is our element of role based access in a safe you have multiple objects credentials files secrets grandma's cookie recipe whatever you choose to store inside that safe one of my favorite parts of the solution itself is a hierarchical encryption model each of those objects those thingies in a safe are encrypted the saves themselves also have an encryption key the both itself also has a baseline encryption key to server say an object so every access within cyber-ark requires three decryption challenges to occur we design it this way to help with brute forcing now cyber work does not store these secrets inside of a database it's a proprietary flat file system we do have a database for storing metadata and facilitating fast replication it is self-managed DBAs do not need access it simply do not want them accessing the vault but there is that server key right the becoming a base of the encryption spec now you can't store it in memory right when the vault starts it's hanging out there in memory what most of our customers use if they have access to a pkcs 11 compliant hardware security module is they'll store the key there to offload encrypt decrypt operation so we've got partners like like jamal totalis but like i said any pkcs 11 will work there now the vault if you're into that was originally designed to exceed microsoft's SSL eff recommendations for high security low functionality Bashan servers we've added a number of other elements to the ball platform too so vault security absolutely key the vault should be locked down the vault should be an island of security and you'll see that it's the more the architecture a little bit later so users can check out passwords but they see those passwords and if you're anything like me when you see a password the first thing you do is you write it down and then you put it on a sticky note and that sticky note goes under the keyboard or you give it to someone that someone takes it sells it on the darknet bad things happen so for me being able to connect a user without showing them that secret is a security benefit it's also an access benefit too because who likes to copy and paste and passwords it's just it's kind of old-school we shouldn't need to do it so what cyber-ark has done is we've created a process we call it privileged session management that allows for a user to log in through the browser or using their own tools modify their connection string identify themselves pull down that secret and then connect and the secret transfer happens inside a cyber arc so it never reaches the end users system so all the creepy stuff out there can't get access to the credential so it goes through the process session is isolated we launch whatever client the user cares about whatever you've configured so things like sequel server management studio putty RDP secure CRT toad crusty old mainframe emulator for instance or a built in one as browser for instance to a web client to as long as it can be driven programmatically it can be launched new cyber-ark as an added artifact of this we're monitoring everything that users are doing video keystrokes as well as windows title capture is all coming back so we can take those shared accounts I mentioned earlier and say well Brandon was the one who did stuff with that shared account we can also apply analytics to this too and I'll talk about that in a later session but connecting users by leveraging their own native tools or the browser but mostly the own native tools it's a it's a it's a pretty happy state but there's still something missing there what if it's a browser-based connection that would mean a user would have to launch some connection aggregator to then connect through and then cyber-ark internally would programmatically launch a browser that's not very native is it it's more native on the putti side the RDP side but for browser stuff things like AWS Twitter Salesforce LinkedIn cyber-ark has recently created something new relatively new we call it privileged session management for cloud where user can open up the same browser window they would log into the client so we exist as as either an explicit or reverse proxy here we'll intercept the authentication check out the secret from the vault if we choose to have it vaulted or use it as just kind of a jump and then connect the user to whatever end point that is frictionless connectivity while instantiating security should be the goal for every company yes so do you have a mechanism for identifying and detecting and then managing and changing passwords for assets that people may not even be aware of like intel amt is admin admin you know and how many people knew they were running that until they were compromised absolutely so there is kind of two areas to look at it there's the programmatic discovery that can be done as part of the core platform itself but the downside there is you actually have to deploy cyber-ark to do that discovery so later on I'll talk about a free discovery tool we have called DNA or discovery and audit that allows you to perform those scans well in advance of a project and mitigate risk immediately so yes we want to be sure we're reaching out programmatically to find the built in accounts as well as the counts that we just hadn't thought of partially because the accounts may have been there longer than our security thing yes I'm on this slide are you is this are you using a TLS intercept and and then to manage the credential in a browser so in this case what's happening is our our proxy is simply existing and filtering the web traffic so it's just like using any external proxy all right which is being filtered we're then pulling it down based on rules on the backend you need a hardware device on on your on your premises to do that or and and the secondary question is you obviously need to put certificates on the endpoints right yes yeah so there is an element of certificate trust here typically our customers were use their own internal signing CA but any trust can be built there and yes this does require a an OVA so just a virtual appliance that exists either a on Prem or B in a mutually accessible network location so in the cloud wherever it may okay are you planning and are you doing an inspection on the HTTPS or also about other protocol great question for this this example here it is HTTP inspection the goal is to increase that to other protocols but we want to make sure we're keeping the focus that's for specific tool sets and not serving as a full on say web application or use their access proxy as there are a number other folks out there that will do that for a wider scale so we want to make sure we're focusing down and on the stuff that has the most writes in Access thank you yes sir back to the the right that you're shading for the proxy does that mean that this solution would only work for internal users how do you support people who are working from home work from a coffee shop road warriors it was a road warriors so if we've got the proxy that's only proxying traffic through on-prem so we're not using a VPN or anything like that and this would only work for people who are connected to that Network when we're dealing with road warriors we do have options for leveraging DMZ based communication external VPNs as well as other aspects of our solutions so this isn't the be-all end-all of proxying I might have a user who may connect in using say an html5 gateway in order to get access through the same console they might use the more kind of video bash and based connection than this more native flow but there are options there depending on how our external users are connecting in however we do assume that they'll be able to access through network some element of the solution now if we go super super far into the more kind of aggressive layer of security you may set up the traffic for say that login to only go through the cyber-ark approach in that sense the user must gain access through and by nature of not knowing their secrets they won't be able to access the solution within so one of the biggest controls we can kind of provide not being malicious with controls but if a user doesn't know a password that means they simply must go through the prescribed connection process that we've set out as a security best practices so talk about high availability reliability if it fails they'll open fail close or you know what happens when you know the entire farm to sons to die on you great question now I will address this more a little bit later on the terms of how we look at failover but if we simply have one cyber-ark node and that one cyber-ark node goes down well we may as well go home for the day so we want to be sure that no matter what we're instantiating good redundancy and it's one of the things we include as part of our platform there's not like oh well you can you can go out and buy an extra layer of redundancy we want to make sure that the core the stuff that matters is there and available for users regardless of network connectivity issues at the DC a whole DC being down all the way up till the Sun explodes in which case we have other issues at that point so I will talk more about redundancy in a bit for sharpens yes here's have a TLS 1.3 plan we do yes absolutely as it stands today internally within cyber-ark we use a proprietary protocol that however can be moved to TLS we're also making sure that our RN D is porting that making sure we have best practices around TLS 1.3 switch over even for your even for your intercept proxy that's right yeah so again for us we follow two things number one security best practices in general but number two what our customers are doing what they're adopting we have to make sure that yes if we're on the forefront we're also able to support custom that may not have met that with our recommendations it's one of the reasons why for instance for our SSH key management I will all day long not recommend you to use DSA formatted keys but in some areas it has to be used so at the very least we want to be sure to rotate aggressively and provide strong key links there so yes the short answer the question so for me this is better but most importantly of all these different options they're just that their options were being sure that no matter what the workflow might be we've got a mechanism to connect users that's as close to how they normally do things now a lot of this you may be thinking on friends now with the with the cloud proxy you may be thinking some cloud stuff too and I talked about the breach flow in the previous session but if we look at compromised old-school way is to do that land and expand right Fisher user get internal move laterally compromise however with more and more infrastructure existing as a service that's one school now I have a confession if you haven't noticed I am a millennial I'm proud of being a millennial but but I am one and think about Millennials is that folks will tend to there's a word for it when you when you don't want to do more than is required when you want to do the least amount of steps there's some word efficient I'm off of the face of the threat actors too we're efficient not lazy I know some of you were thinking lazy it's not lazy it's efficient but as a threat actor if I simply need to compromise one level and I can do it from the comfort of my own home apartment mother's basement wherever it may be of course I'm gonna choose that mechanism it's because of the more public facing element of infrastructure-as-a-service we're seeing a lot more compromises take advantage of this now cyber-ark has a red team we do a number of engagements both internal and external and we've seen this flow play out in a number of different cases where we're able to compromise an end user then on their desktop I kid you not there are flat files that say access key remember a decade ago and for passwords in text files and they stopped doing that well now we're seeing the same thing with privileged access by leveraging this access key we were able to connect the end users storage to our RA AWS instance and found PII this happened over the course of three to five hours three hours all it took to perform the compromise so we want to make sure that we also were managing human and non-human access in the cloud - it's one of the reasons why you see some of those improvements previously now last part not mentioned before moving into a into a demonstration here is the general architecture of the solution itself now I won't go too in depth but it starts with a vault multiple vaults maybe not just one vault if that vault goes down you want to have redundancy now whether you choose to cluster those vaults like you've seen here or do single nodes we want to make sure we've got elements of failover this exists is what we call a disaster recovery vault which is to becoming a distributed vault as we enable more services for this we could have a DR vault or d'art cluster and another data center or three data centers or five data centers or one that exists in AWS or Azure with a core existing on print that D our vaults is replicating the primary constantly so synchronous and asynchronous replication synchronous for little things password changes audit stuff like that asynchronous for large things like sessions that are recording if my primary vault should go down or the D our vault loses connection after a period of retries interval between we automatically perform failover now RTO between clustering and D are fairly similar so most the time we'll see clustering for local based availability but also if there's like a corporate requirement to have a have a cluster in the environment again have multiple vault nodes so that should all the infrastructure go down we still have some vault and if all of your active infrastructure goes down make backups full incremental as many as you'd like to now outside of the vault itself is where our distributed components live so these are the spokes of that hub-and-spoke weird kind of model I mentioned earlier it's weird because I describe it in a weird way things like the the user portal have as many as it makes sense load balance and make them available the junk servers place them close to devices place them in the cloud the piece that changes passwords all these things should be played into those partially air-gapped environments into the environment of a company that was based on an acquisition without having to open up firewalls Swiss cheese all over the place from your centralized fault while we designed this for things like ICS networks and mountainous ones it's really come in handy when dealing with more and more hybrid based approaches in the cloud stuff like that and while this is one of everything a more common deployment strategy is something that looks like this where we have a core stuff existing in at a primary data center maybe a cloud DC maybe a distributed one whatever fits we want to make sure we've got redundant models that can live out there too and also more importantly users should not experience that weird stomach cramp when they can't access their stuff so it's not just business continuity it's also keeping our users happy productive too because the time it takes someone to send you an email to let you know it's down is time well spent doing other things actually being productive to the companies we work for a question and I've worked in the past with them hi I'll try profile high net-worth individuals metro and when they things like this when they're remote employees and/or there are people that work for them or remote and they're traveling and is there any like things that you can do like you know one password has that thing were like when you're traveling you can put it in like traveling mode so you can't actually access anything it's there like a quick turning in travel mode and it can turn off quickly or do you have to manually remove permission to have access to all of these things and then really had it after look at that old manual can you do like timelines if that makes sense good question um so there isn't a concept of a travel mode within cyber-ark our assumption is if a user is able to connect into the appropriate environment they should really be able to access their secrets however um this is implicit on the fact that they've authenticated into cyber-ark appropriately that they're multi factors working they're in the correct group stuff like that could you do like an emergency turn off like that joke we've got like the this switch that you can like cut the network cable but do you have like something like you can just shut down somebody's account really quickly or is it absolutely so that can be done in either based on approvals like an emergency button it's most commonly done through a disabling of the Active Directory user or removal from the group the same corporate policy that you would do if you had a rogue employee will also cut their access into the cyber-ark platform and this extends to like if you're using like an identity management platform like RSA via or a sale point it's also the same thing right as soon as you remove their access it then ripples down into removing access to cyber work - do you have any limitation I guess is it still based on like I'm the way there was I guess that make sense it's like a locational like you know how ants bunk you can like if you log in at this time at this place and then you log in at this time at this place as well it does it track those sort of things as well absolutely we look at that as a trusted Network area for instance if a user exists outside of the trusted Network area the authentication can occur it's also an element that we apply analytics on top of - so if Brandon logs in Monday through Friday from 9:00 to 5:00 and then logs in at 4:00 a.m. that's weird it's an anomaly I should be able to notify you I always set those off actually but the thing is that as you do it it builds a behavioral baseline eventually your forte 4 a.m. night out will work it's ok until you start trying to say check out thousands of passwords at once that's also weird you do you also have like an ability to capture his metrics and like present them to kind of both the technical team but also another version you can present to like high level yes yeah and then the other question I had was I can't remember everything right now I think that and ask again sorry I'm just one last question that falls on the same vein we were discussing before as well is do you have any kind of function of like a vault export because I've been in this situation before it's like we've have our password it's great we need to write these down and place them physically in a vault which sounds all fine like you don't need to do that it's great until all the protection mechanisms you have in place are great and then they all lost and the entire system's down because of various ways we can shut the the whole credentialing system down and now you can't get into it effects because you don't know the password a break glass for your break glass when cases like that and this is this is maybe a little bit of a branded adage but um in cases where everything is down all the redundancies we are just up the creek I'm the one credential that cyber-ark isn't managing is the one that isn't in cyber-ark so in just um let me tell me yeah don't throw things at me yet but um when we pull in a number of these secrets we begin automatic rotation it frees us up on an oversight side of things so I can have say a domain administrative credential that exists outside a cyber arc that I can then perform manual rotation operations on yes it exists inside of a vault but if it's being used out of band it's leaving hashes too so I want to be sure that yes if I'm gonna do break glass I have this other secret in the vault but I'm updating it and that's what people will typically throw things that mean I have to go to the vault open it and then add a new account yes you probably should the same is true safe for the cyber-ark master account too there will be accounts that exist outside for break glass scenarios please put them in a safe put them in a secure location but also change light is there an easy way to export out the vault as yes yes absolutely so there is an export process while it's not something we see very often it is certainly possible to export the data in the vault yes I asked just because I have had literal vaults I have to place the passwords into and it's but Sehnsucht handwriting out 100 character passwords because it has to be handwritten and on you know carbon paper yeah so when we do our deployments for our master password I don't know if we do the pomp and circumstance anymore but it used to be where we would have users generate separate strings who then provided the cyber-ark engineer who would order them in a certain way put them into an envelope and might do this whole ceremony where we put in the safe so the same is true there but just not a hundred characters on one sheet of paper that is well I would probably mess it up because my handwriting is excellent point and I was asking about that envelope ceremony because I know some of your competitors offer that and to me as an IT Pro that's really attractive because I can take that symbol and it to the business to legal compliance they could put it in a safe yep they have ultimate control not me so you have something similar to that yes yes and wallet I don't know if it's much as a ceremony anymore you can always request it to be a ceremony in lights Malone's ritual tiki torches Commodore tis inside of a building but yeah the question so stepping back for just a minute oh you mentioned sale point I'm assuming that with your integration you got a lot of automation there so my question to you is is twofold one can you talk briefly about what can or cannot be automated and two can you give it like a high-level overview of what the API would look like definitely so in terms of the API there there are two functions sale point leverages are a restful administrative API okay I can as well as our skim server to actually pull in data locally to the sale point side of things while the skim server is publicly documented most of our customers will leverage our admin API and I'll be sure to show it as part of the session here so you can actually see what it looks like but for the sale point side of things there or just really any identity platform they're pulling in entitlements from cyber-ark so you can see what accounts are privileged what are managed what does user access look like but also using that same API to programmatically vault new privileged identities or entities that are showing up outside of our discovery process too but it is all based on primarily the admin API that's available to every customer as well as the skim service which is also available but this is mostly an element of integration beautiful and as a follow-up to what Zoe was saying with that admin API while my customers are now adopting sore right I want to you know orchestrate and automate and everything blah blah blah so with something perhaps like ServiceNow our ticketing system could I say a submit a ticket because we noticed this malicious behavior some other instrumentation has alerted go ahead and perform these actions disable counts rotate passwords oh yeah oh yeah now for ServiceNow specifically as you mentioned of course taken integration there too but also this extends to managing the secrets they use for their discovery and orchestration being sure we're handling it on both sides but yes as long as there's an externally facing API I can tag into them as long as they have access to our API they can automate tasks within cyber-ark - it should be that way no need to instantiate more automation so security teams can do other stuff that befits a human

Channel: Tech Field Day

Views: 10,643

Rating: 4.8421054 out of 5

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

Id: rdKuJy3SRVw

Length: 35min 57sec (2157 seconds)

Published: Wed Dec 12 2018