Veza’s Post

1/2 There were some amazing states in there: 1. 17:1 for non human vs human accounts is alarming. Most people that login to infra, platform and applications are users and they may be using their named accounts, shared accounts, bootstrap accounts, privileged accounts — they are all human. Non human to me are the accounts created for scripts and apps to make calls like terraform scripts creating infra or TVM product doing scan and/or patching or cross application API calls or the application code using platform APIs. If they are 17x more that means that the API first architecture combined with the microservices patterns are using an undisciplined process to cause non human account explosion 2. I agree with all the stats and concerns raised for privileged accounts. These are the key accounts that make a vulnerability significantly more exploitable when blindly excessive privileges are stuffed in them using casual “cloning” with the mindset that a highly trusted admin or an app is using them and ignoring that a burned with not in trusted boundary can take them over and cause privilege escalation to cause a major attack. I also agree that just the RBAC, access request and monitoring of SoD or backchannel grants is just not enough.

There were some amazing states in there: 1. 17:1 for non human vs human accounts is alarming. Most people that login to infra, platform and applications are users and they may be using their named accounts, shared accounts, bootstrap accounts, privileged accounts — they are all human. Non human to me are the accounts created for scripts and apps to make calls like terraform scripts creating infra or TVM product doing scan and/or patching or cross application API calls or the application code using platform APIs. If they are 17x more that means that the API first architecture combined with the microservices patterns are using an undisciplined process to cause non human account explosion 2. I agree with all the stats and concerns raised for privileged accounts. These are the key accounts that make a vulnerability significantly more exploitable when blindly excessive privileges are stuffed in them using casual “cloning” with the mindset that a highly trusted admin or an app is using them and ignoring that a burned with not in trusted boundary can take them over and cause privilege escalation to cause a major attack. I also agree that just the RBAC, access request and monitoring of SoD or backchannel grants is just not enough.

— 2/2 More controls are required to constantly remove excessive privileges. My favorite for this are (1) job change time privilege creep review (2) backcchannrl assignment exception review and (3) access activity for inactive grant reviews I had envisioned a world in which the impact will be associated with each grant. For example, if you are requesting a grant, you must specify the business metrics that you envision to deliver this it ( revenue, margin, more customers, better satisfaction, loyalty etc — I wrote a paper identifying 25 of them). Every grant increases risk and this must be balanced by understanding the business benefit. The topic that needs further discussion is how to measure “planned vs actual” for impact so that if the stipulated impact is not delivered, a revoke may eventually be considered. Would be interesting to take the “access activity correlation” concept to “effectiveness of access activity”

Please ensure your network joins the Non-Human Indentity Mgmt Group (https://lnkd.in/dbJiJyXU) and visits our supporting portal www.nhimg.org