The migration of data and infrastructure to the cloud over the last couple of decades has exploded the scale, scope and complexity of identity security. Meanwhile, the tools we use for identity security and governance haven’t fundamentally changed from the on-prem era, leaving security and governance teams struggling to keep up. With identity-based attacks on the rise every year, organizations need new approaches to identify and control risky and dangerous permissions that can empower an attacker when (and it really is when, not if) an identity is compromised.
To that end, we’ve prepared a field guide to the major types of bad permissions you need to be aware of in order to keep your critical apps and data. We’ll examine common bad permissions, how they happen, and how you can rid yourself of them for good.
This is the fourth of a series of four posts, looking at policy-violating permissions. Policy-violating permissions are those that violate aspects of a company’s data or security policies and may threaten the organization’s compliance with regulatory frameworks, risking fines or other sanctions as well as the potential for fraud or data theft. Some examples include:
- Segregation of duties violations: Segregation of duties is a best practice designed to prevent fraud and error, especially in finance and information security, requiring that no single identity be able to control an entire process alone. For example, the same person should not be able to create new vendor records and also approve payment of invoices. As well as being a best practice, some compliance frameworks, including Sarbanes-Oxley (SOX) require companies to be able to demonstrate that they have implemented segregation of duties for key processes.
- Sovereignty violations: organizations that operate globally often need to comply with different sets of local laws and regulations governing privacy and data, such as the General Data Protection Regulation (GDPR) in the EU, and China’s Data Security Law (DSL). These regulations often require that data collected in a particular region not be stored or accessed outside it. For example, a multinational company operating in China may need to ensure that only employees located within China can access data about Chinese customers.
- Misconfigured identities: organizations may require all users, or at least all privileged accounts, to use multi-factor authentication, or to change their password at set intervals. Any permissions held by accounts that don’t adhere to internal rules can also be understood as policy-violating permissions.
How policy-violating permissions hurt you
Companies found not to be complying with frameworks like SOX face a range of consequences. Most obvious are penalties from enforcing agencies like the Securities and Exchange Commission (SEC), which can impose fines into the millions of dollars, or even undertake criminal prosecution, resulting in imprisonment for company officers. Beyond the immediate regulatory consequences, companies may suffer a loss of current business as customers lose trust, as well as reputational damage, making it harder to lure customers, investors, or employees. In addition, there may be a time and money cost resulting from increased scrutiny from regulators in the aftermath of a compliance failure.
It’s also important to remember that security and privacy policies are in place for a reason! Failing to adhere to policies like segregation of duties leaves you vulnerable to fraud and catastrophic data breaches.
Why policy-violating permissions go unnoticed
As with any other kind of bad permission, policy-violating permissions go unnoticed and unremediated because of a fundamental lack of visibility into the true permissions identities have. Organizations that can’t comprehensively answer the question of “Who has what access to what data?” will never be able to effectively enforce their security policies, no matter how carefully thought out the policy is.
A few specific problems that get in the way of detecting policy-violating permissions include:
- Vague or inaccurate group/role names: traditional IGA tools often only have access to the names of groups, roles, or access profiles assigned to a user. Tools for enforcing segregation of duties compliance may be limited to making sure the same person does not have two roles, for example, an “approver” role and a “requester” role. However, naming conventions for groups and roles don’t give you the full story. There may be multiple roles that grant the access you’re trying to prevent.
- Incomplete metadata: in some cases, key facts necessary to uncover policy-violating permissions may be missing. For example, in the case of sovereignty violations, it may be necessary to know where the users behind each identity are located. This information can be missing from the identity provider and, even if present, it might not be accessible in the tools you use to enforce sovereignty compliance.
- Siloed data: the actions governed by a segregation of duties policy may not all take place within the same app or system. For example, business processes begun in the CRM may be fulfilled via your ERP. This means that unless you can fully integrate all of your apps and infrastructure into a single control plane, you will be forced to rely on failable manual processes.
How Veza can help
Enforce segregation of duties
Veza’s Authorization Graph can link any identity to its granular permissions in SaaS apps, cloud infrastructure and custom apps. Most legacy tools for enforcing segregation of duties only allow you to make sure the same user doesn’t have two roles in a particular platform. With Veza you can find the intersection of any two effective permissions across your entire stack, so you can be confident that you’re catching all segregations of duties violations.
Comprehensive identity and resource metadata
Veza pulls in a comprehensive set of metadata from your identity provider and all of your data systems, giving you the context that you need to identify policy-violating permissions like sovereignty violations. Veza can also highlight any identities or resources that are missing key metadata like location, department, owner, etc.
Learn more
This is part four in our Field Guide to Bad Permissions series. Check out the other three posts in this series:
In the meantime, to learn more about how Veza can tighten up your identity security, take a self-guided tour of our key integrations, or schedule a personalized demo.
