Most data breaches from inside the organizations are still due to unfettered database access. It is critical for any executive to have a basic understanding of what database controls look like from a practical standpoint and understand off-the-radar areas of data breach risk.
Typical onboarding of an employee or contractor requires assigning database access. This critical company asset contains customer data and other sensitive information. Whether an employee is reporting via Tableau, Looker, Power BI etc or are running business applications over these databases, it’s vital to understand this process for anyone in charge of a team.
What is database access control?
The most common method of Access control is Role Based Access Control (RBAC) that assigns access following security practices such as ‘least privilege’ & ‘separation of privilege’. Simply its easier to define what ‘finance-role’ means in terms of access to financial database and any new hire in finance will essentially be assigned to ‘finance-role’.
RBAC works great in a static environment where typically databases do not evolve fast enough to require changing the Role permissioning. In smaller growth focused organisations such as startups, there is an ever growing need to improve product and offering which in turn means more strain on the database environments.
Attribute Based Access Control (ABAC) is assignment of database access based on user location, time etc. Bespoke and more directed but is a nightmare to maintain.
What permissions can someone have in a database?
At a high level, access can be applied as
- Read only, Read/Write access to a given schema
- One can get assigned Read access to a given schema or entire database
- Or Read access to specific tables within a database
- Column-based access gets tricky with certain kinds of database such as noSQL ones like mySQL or mongoDB. Also, column based access is very cumbersome and only used by less than 10% of enterprises.
Roles Spawn is prevalent in Enterprises with large legacy infrastructure
Features:
- Underlying business CAGR < 15%
- Monthly or Quarterly Software Release cycle.
- Underlying tech is stable but transformation projects are a catalyst for large changes.
- Role-Sprawl due to transient team members is a common reason for changing roles for this cohort. Enterprise wide digital transformation projects usually bring in external consultants who are given access on an ad hoc basis. in most cases.
Weak ‘Roles Management’ controls are a prime factor for ‘ad hoc’ roles being created.
Weak Operational Controls within high growth Enterprises & Startups:
Features:
- Underlying business’ CAGR is >15%
- Weekly or daily Software Release Cycle.
- Fast evolving database environment. With huge focus on product iterations and agile development, database environment is evolving with new tables, processes being built and tinkered with.
- High turnover or hiring spurts create an operationally weak Role based controls. Account Based controls can become even more unwieldy as every person could be having very specific access to certain tables, schemas which can get lost in fluid organization setup.
High growth businesses have a risk of operational deficiencies creating ‘air pockets’ of data access control failing.
Business intelligence software as a back door to accessing sensitive information
You will be surprised how easy it is to access PII, PHI & HIPAA data by any user on an internal BI System such as Looker, Tableau, Power BI, BigQuery and others.
- In low growth businesses, we see a regimented SDLC practice in deploying ‘Read only’ reports. There are a lot of exceptions to this, especially as it relates to Salesforce and other CRM based data stores.
- In high growth businesses, concept of Read Only might be limited to certain users but a higher cross section of users will have ability to create reports-hence access any table within a database.
- “Everyone needs all the data-all the time” is not an uncommon motto in less regulated companies. This is typically due to a lack of solutions that make it easy to create these permissions.
In conclusion, database access can be overlooked when thinking about data breach risks. This piece is not meant to be exhaustive but rather a spotlight on the cobwebs of risk your organization might be accruing.
