Do you know who has access to sensitive financial data in your organisation? Or where you should begin if you’re performing an audit to verify only appropriate people have access? These aren’t trick questions, but they are tricky ones. And while it may be a challenge to know where to start addressing them, tackling these issues is vital to the health of your business.
Access may still be granted to users who have switched teams, or to shadow IT systems where access isn’t audited. In fact, there are many scenarios relating to process complexity, silos, and inefficiency that can lead to increased risk to your organisation. While you may think identifying those with access should be as easy as asking a system administrator to run a report, this is often not the case. So, how can you gain access to this vital information?
Find the source
A great place to start is understanding who has access to the system where the data originates. For example, using a financial application, you can pull the list of users who have access to the financial data—this will include users who have access to create and view financial transactions and users who create and view reports.
While this list is an excellent start, it’s not the answer to all your problems, and there are more questions to ask. So, if your organisation manages the financial application, be sure to find out:
- Who has access to the application database?
- Who has access to database backups?
- Who has access to the machine(s) which hosts the application and database?
- Does the system have functionality to automatically export reports? If so, where are reports exported to?
- Who has access to the file systems on those machine(s) where application and database files are stored?
So, for example: exported reports are stored on a file share, and access is granted via Active Directory groups. You need to identify which groups have access and then determine group membership, which may include nested Active Directory (AD) groups, and individual users.
You should also regularly review group memberships to ensure users are removed when they move on or change teams. In doing so, your list of users will include application users, database administrators, system administrators, those with access to the reports on the file share, and more. Speak to the administrators of those applications to understand what types of access there are to understand what you need to look for. For instance, the dbowner role in Microsoft SQL has full access to that database but isn’t a database administrator. To know what to look for, it’s key to understand the nuances of these configurations.
Database access
Financial data offers value for many people in an organisation, from product managers to department managers, operations groups, and more. As a result, this sensitive data will likely have gone beyond the financial application—indeed, your organisation probably has a data warehouse.
You now need to get the list of users with access to your organisation’s databases, including database and system administrators. Not only that, but you need the list of users with access to the database backups from the data warehouse.
And the fun doesn’t stop there. Your organisation may have a separate financial planning system, with a process to import data from the financial system to the planning system. Where the financial system was tied to AD users, the planning system doesn’t integrate with AD. What does this mean? Well, now you need to link the planning application users to the actual people using those credentials.
Your organisation may use multiple reporting tools on top of your data warehouse, and users connect to the data warehouse using their AD credentials while building reports. However, a service account is used to execute queries when datasets are refreshed, or reports are run by reporting applications. Yes, this means you’ll need to go into each reporting application to get information on which users have access to the reports containing this information.
The rabbit hole goes ever deeper. With countless other scenarios, your view of those with access to sensitive information is muddied. So, how can you cut through the murk?
Access control management
A proactive approach to access control management is vital to ensuring you avoid unravelling these mysteries. Access control management isn’t just a technology to be implemented—you’ll need to involve people and process—but technologies assisting in access control management across the silos of individual systems can play a critical role in clarifying a once-opaque view.
What does a proactive approach look like? First, access should be regularly audited for both regulatory compliance and organisational security. Remember: without a strategy on access control and how it integrates with identity management and each application your organisation adopts, your organisation is exposed to potentially damaging data security risks. This data is important to the efficiency of your business, so there’s no use locking it away, but everyone needs to play their part in ensuring it’s appropriately handled.
Why zero trust should replace ‘trust but verify’ to make your business more secure
Finally, it’s vital for IT pros to embrace a holistic approach to access control management when managing data as it flows throughout an organisation. With an access control management tool, used correctly, you can quickly identify who has access to what, improve compliance by detecting changes, and understand and act on high-risk access—all vital to the ongoing health of your business.
