Determining “Need to share vs. Need to know” is a Cornerstone of a Data Protection Strategy
There is a paradox that lies at the heart of data security. Data itself only has real value if an organization can share it with stakeholders that need it to perform their roles. However, the more widely an organization shares data the greater the risks of the data being compromised.
Data security professionals wrestle every day with the variables that impact their ability to achieve the optimal balance between adequate sharing of sensitive information and effective data security. This is often referred to as the “sweet spot” between sharing and protecting data. Affording too much privileged access may result in risking data exposure, too much restriction on data access may result in dramatically lower productivity and quality; or worse, it could compel people to develop “workarounds” that could result in the very data exposure that the organization’s privilege restrictions are designed to thwart. Establishing appropriate “need to share” and “need-to-know” security policies that govern whom and to what degree people have access to sensitive data is critical to an organization’s overall data security strategy.
Even in the best of circumstances, creating appropriate “need to share” and “need to know” security policies that have only a negligible impact on overall business performance is a significant challenge. Establishing policies for the safe, effective handling of sensitive data is a complex and dynamic exercise. In this post, we’ll look at the principal challenge organizations typically face when determining privilege access. We’ll also provide insight into what you can do to create an environment suitable for the application of effective privileged user access policies.
“The Great Resignation” and the remote work revolution
The recent past has seen the IT employment landscape shift dramatically. This is due, in part, to low unemployment, people leaving jobs at unusually high rates, and many baby boomers and older Gen X IT professionals exiting the workforce. The media refers to this phenomenon as The Great Resignation. This development has created a crisis for many organizations whose security teams simply confer the same privileged access held by departed employees to the people that replaced them. While expedient, this is a poor practice because incoming employees may not have the experience or skill set to protect the data to which they now have access. Also, in many cases, new employees’ roles do not cover the scope of the responsibilities of the people who left but they still have the predecessor’s privileges. Then when the “new” person leaves the organization, the process is played out again and even more people have more privileged access than they need, to data they don’t have the skill set to secure. This can be a particular problem for data in cloud-native environments if new people are not familiar with how to properly configure specific cloud architectures.
Another trend that has taken hold is a new work-at-home culture, with dramatically higher proportions of skilled IT professionals fulfilling their roles remotely. Here again, conferring the same privileged access held by departed employees to the people that replaced them can expose sensitive data to even more risk. Sixty-one percent of CISOs are more concerned about security risks targeting employees than they were pre-COVID, and much of that is due to staff working remotely. This is largely due to many remote employees not understanding the benefits of following company-wide security directions or the pitfalls of ignoring them. Having so many people working out on the perimeter highlights the importance of data-centric data security. For more on this, my colleague Nik Hewitt has an excellent blog on creating a security-first culture on remote teams.
Take steps to establish what is normal behavior
You can’t determine what is abnormal behavior without first establishing what normal behavior is for privileged users. First, you must determine the privileged access level of every user in your organization and compare it to the access they actually need to the specific resources required to fulfill their roles and responsibilities and be sensitive to the time, location, and nature of their activities.
Security teams must properly manage privileges and monitor the activity of privileged users
Security teams must execute ongoing discovery and management of privileged accounts and sensitive assets to maintain complete visibility and control. This enables them to profile all known and unknown assets, privileged user accounts, shared accounts, and service accounts.
The discovery and monitoring system must regularly check which users have privileged access and ensure the privileged user:
- Requires that privilege for their role
- Has appropriate credentials, such as a strong password expected of a privileged user
- Has his own unique account, not shared with others
- Has only the access required for his role (For example, the privileged user might require read access, but that can be limited to exclude sensitive data or to only access a small number of records.)
Monitor privileged users’ data usage
While it might be reasonable to monitor and log only certain actions, or a sample of actions, from non-privileged users, security teams must monitor all privileged users’ data usage. Include in the log all information that would be required to trace actions, including the user ID, time, database object, exact action executed, and list of records accessed or altered. Ensure that the logs cannot be modified by the users that are being monitored, by hosting the log separate from the databases, and restricting write access for those users. Establish policies that define legitimate behavior for the privileged user, and then in real-time identify actions that violate the policy. Identify all sensitive actions and verify they are authorized. When violations occur, block the suspicious activity or send an alert.
Analyze privileged users’ behavior
Analysis of anomalous behavior helps security teams determine malicious user activity or a database attack that causes the atypical behavior. An example would be a privileged user account that normally reads a few records a day from certain tables, as part of regular maintenance, and then unexpectedly reads many times that number of records. For this purpose, employ machine learning (ML) that will baseline typical access for the privileged user and send alerts on deviations from that behavior. Machine learning analytics can also learn what data is business-critical and see if a privileged user can access that data (even though they should focus on metadata). This allows the identification of the highest security risk activity identified in the monitoring alerts. With the potentially large number of alerts from large database systems, it is crucial to ensure immediate focus on those highest risk alerts.
Security teams must have the autonomy to restrict a privileged user if their work doesn’t require they have access to critical systems and data. Besides the possibility that the privileged user will inadvertently or maliciously impact the database through their actions, an attacker can attempt to gain access via the privileged user account. Those accounts are a prime target for attackers who wish to hijack the account to access data or introduce malware.
Real-world consequences of security teams not having a handle on “need to share” and “need to know”
Here are two examples:
- Compromised access to restricted data – One Scandinavian transport agency outsourced its database administration to a third party vendor without restricting access to database records. Administrators in Eastern Europe had access to all data, including infrastructure details, personal data, and classified information about the nation’s military vehicles.
- Compromised through role-specific access – Attackers in the massive data breach of credit card data of 40 million US-based department store customers gained access to the system with credentials stolen from a service company. From there the attackers were able to move about in the system and upload malware to store’s point of sale systems. The service company’s access was required to carry out tasks like monitoring energy consumption and should have been segregated to not allow access to other segments of the system.
How to get started
Done thoughtfully, security teams can make “need to share” and “need to know” a cornerstone of their data security strategy without negatively impacting business performance. Common sense rules, full visibility into data repositories, and an automated response process to anomalous behavior can make it a seamless function. Once you have a strategy in place, you can also apply it to other stakeholders like business and technology partners as well as service integrators.
Learn what the industry experts at Gartner recommend in a strategic roadmap for data security from their latest report, 2022 Strategic Roadmap for Data Security Platform Convergence. When you are ready to find out how the Imperva Data Security Fabric can help your organization achieve its data security goals, contact a solutions representative.
The post Determining “Need to share vs. Need to know” is a Cornerstone of a Data Protection Strategy appeared first on Blog.
*** This is a Security Bloggers Network syndicated blog from Blog authored by Bruce Lynch. Read the original post at: https://www.imperva.com/blog/determining-need-to-share-vs-need-to-know-is-a-cornerstone-of-a-data-protection-strategy/