Lets migrate to the cloud! Yes, it’ll save us money, its more scalable, it’ll reduce the amount of time we need to spend babysitting infrastructure, we need to adopt SaaS – sound familiar? Nearly every enterprise organization is jumping on the Capex to Opex bandwagon and for good reason. Yes, you’ll be able to optimize certain portions of your IT, Ops budgets. Yes, you’ll be able to re-purpose your technical headcount for different projects than manually overseeing uptime requirements. However, when it comes to compliance processes for PCI, NIST, NERC, SOX, SOC2, ISO, FFIEC and more there is something that is sorely missing. The ability to show sufficient controls for separation of duties and roles on these cloud assets, SaaS apps and servers is proving to be the Achilles heel for enterprises that have championed the move to the cloud.
What is the problem here?
So lets talk about the challenges. Try out this very simple exercise: Ask your financial, accounting team, “Are we using expense tracking applications?” If yes, “How are we showing separation of duties and roles on shared administrative accounts on these applications?”. Its a rather simple question that stems from the fact that more than 90% of enterprises share administrative accounts between employees. This itself is not a problem and often a necessity. Consider the fact that your companies bank account needs to be shared amongst your CFO, auditors, CPA, procurement person, VP of Finance and more. However, all these people are not equally important or are privy to the same amount of information inside the banking application. Your CFO might be allowed to check the current bank balance, but you might not want your procurement person to see that.
Therein lies the problem – how do you layer role based privilege management on top of web applications, SaaS services and servers? Sounds simple doesn’t it? It is actually quite complex to solve because of a very simple reason – repeat after me – You don’t control the code base. Again – You don’t control the code base.
By lieu of “subscribing” to a SaaS service or a server you pay for the right to “use” the service or server. You do not have access to the code that powers this service or server and thereby you are at the mercy of whatever access management policies have been made available by the company or individual that has developed the SaaS application or server.
Why is the problem hard to solve?
This problem will never be solves satisfactorily if the responsibility of privilege management is left to the developer of the application, SaaS service vendor our IaaS provider. Why? – the reason is two fold (1) The vendor does not know what really matters to you, they can guess – sure – but they don’t know. (2) The vendor does not necessarily get paid more for building these fine grained capabilities.
Lets dig in a bit into the two reasons above. You and your company when using an expense tracking application might feel that a certain employee who has access to administrative rights should not see information about type of invoices being filed. Another company might feel that they need to protect another different piece of information inside the same application. Its near impossible to guess all that is important to any and every customer using an application – the only comprehensive solution being, make everything configurable. This also will not happen. Don’t believe me? Can you prevent an employee from clicking on any button you choose on Salesforce – no. This is because salesforce has an IAM model that you need to play well with. Salesforce is not going to modify its IAM platform to play well with you – unless you are a billion dollar customer. The point being making every little button, text, option, form configurable is a massive undertaking.
The second reason is rather simple. Most companies like to have security, they are not going to necessarily pay extra for fine grained control. They often times want the vendor to roll in the capability for free. Again – here is another example – Have you ever been told by a SaaS vendor “If you want to use SSO on our product you need to pay $X more per year for security”? If yes, how many companies do you think say – no, thanks I’ll just use a password manager? A lot actually.
What are your choices?
Not many indeed! Unfortunately. Some options are to use SSO services like Okta, Sailpoint, Oracle IAM and hope to god that the application, SaaS service is sophisticated enough to understand the SAML assertions being thrown at it and knows what to block and what to do. Unfortunately, even then there is a problem – if the SaaS service or application does not have the built in capability to block any and every element like text, links, buttons and more there is little point in throwing SAML assertions at the application. Its like reading Shakespeare to someone who can only comprehend “Goodnight Moon”. Not much good is going to happen here.
When it comes to cloud servers, you are actually in a slightly better position. As an example, AWS IAM allows you to set up various types of fine grained rules and policies to say who can start a server, in which region of the world, who needs to authorize it and so on and so forth. Additionally, for finer grained controls you can try to use existing open source software like Access Control Lists (ACLs) that are commonly available on most Linux machines. The downside though is that you will need to spend significant effort in developing scripts and plumbing to make all this work. An option which is a better one is the use of configuration management software like Chef, Puppet, Ansible. You will still need to “mis-use” these pieces of software to achieve your final goal of tightly controlling who can do what, go where, look at what on your cloud server – but it can be done with some effort and technical expertise.
Does this effect you?
If you and your organization have to comply with regulatory and compliance standards like PCI DSS 3.2, SOX, SOC2, NIST 800 53/171, NERC, FFIEC, NCUA and more – then, yes. You will need to prove one common thread across all compliance and regulatory frameworks: Separation of Duties and Roles.
This affects most companies and their GRC, IT, Security and DevOps teams. Imagine that your teammates have chosen a specific marketing automation product and have started using it, what type of a dent would it make if you were to now tell the team that we need to seriously re-think using this SaaS service as it does not meet any of the controls that are needed for your FedRamp certification. These conversations are painful and too real to ignore.
The unfortunate truth here is that it is hard as heck to layer role based access control and privileged access management on top of cloud services and assets. There are some ways as have been discussed in this article but even they, admittedly, are far from a silver bullet. There is immense scope in this area of dire need for improvement and for a better way to balance the needs for compliance and the ability to adopt cloud solutions.