The following is an excerpt from Netskope’s recent white paper How to Design a Cloud Data Protection Strategy written by James Christiansen and David Fairman. In Part 1 of this series, we covered the first two steps related to data discovery and data classification.
Step 3: Know the flow of the data through the ecosystem—be the inspection point between the user and the data.
Data is like water—it seeks to be free. As such, an organization needs visibility and must be able to inspect all traffic flows to identify the following:
- What data is in motion, based on criticality and sensitivity (data classification)?
- Where is it moving from and to? Do these source and destination environments reconcile with the discovery process or have we identified unknown data repositories that need to be investigated? The latter point is one that should not be overlooked. Business processes will change and with that, data flows will change. It’s imperative that an organization continuously monitors for this and takes the appropriate action where new flows are identified. Typically, these actions are:
- Assuring the security controls or posture of the newly identified source or destination which could be a new SaaS application (or instance of that SaaS application) meets the required security standards
- Assuring the security controls or posture of a new third party (and consequently the security of the third parties environment) that now has access to the data meets security and privacy standards
- Confirming that this data flow is appropriate and does not indicate a compromise or identifies a broken business process or user actions that need to be rectified.
- Can we determine any geographical and/or jurisdictional data movement that may introduce privacy or regulatory requirements?
By creating a cloud-native inspection point between the user and the data, that can interpret the language of the cloud, the organization has now created a data discovery capability to identify all cloud-related data and can then leverage those capabilities discussed in step 2 to automate and highly- accurately classify the large volumes of data and doing this in real-time when the data is in use and in motion. Furthermore, an organization needs this same automated classification capability for data at rest. This way, there is a two-pronged approach to ensure that all data is discovered and classified in an automated fashion, and naturally, the automated classification engine needs to be consistently applied over both sets of data, that being at rest and in motion.
This also enhances real-time analytics and visualization, both of which are key to data protection and are fast becoming new instrumentation for Security Operations teams. These analytics are not a replacement for SIEM, but they do help redefine what is needed for effective security analysis, response, and third-party risk management. This capability becomes a foundational component necessary to ensure that an organization has all the information and intelligence at hand, in real-time, to enable it to understand the impact and dependencies for cloud data, making informed decisions and taking action in a timely manner.
Step 4: Know who has access to the data—effect more visibility
Being the inspection point between the user and the data not only allows an organization to understand where the data is flowing to and from but also gives visibility into what identities (machine or user) have access to the data.
Being able to determine this enhances the Identity and Access Management capability of an organization. This information can be used to validate existing IAM practices, such as any Role-Based Access Control definitions, in addition to identifying anomalies that will require investigation and potentially corrective action. This will apply to both end-user and privileged access.
Having this visibility enables an organization to minimize the access to data and applications which in turn minimizes the exposure and thus risk imposed. Fine-grained access control is imperative to minimize opportunities for attacks.
Step 5: Know how well the data is protected—be the policy enforcement point between the user and data
In storage: With respect to loud-related data, it is important that an organization scans and assesses the security posture of cloud environments, such as AWS, Azure, GCP, to verify the security configuration of these environments and assure that data is not arbitrarily left exposed. Misconfiguration of cloud environments is a leading cause of data breaches. Security configuration compliance monitoring has been a common capability for many years for on-prem infrastructure and this naturally needs to extend to the cloud-based IaaS and PaaS services.
In motion: With respect to cloud-related data, an organization needs to establish a capability that creates a Policy Enforcement Point (PEP) between the user and the data. (This is a logical extension to the inspection point described in Step 3.)
The organization is now equipped with a number of data points allowing them to make policy decisions with context, thus enabling a true, fit-for-purpose, risk-based approach to the application of controls. As an example (and recommendation), with an understanding of the criticality and sensitivity of the data (derived from classification), an organization can prioritize the protection of the highest classification level of data and work its way down to the second-lowest classification. Note that the lowest level is typically classified as “Public” and should not warrant many protections if any at all.
If you’d like to learn more about How to Design a Cloud Data Protection Strategy you can read a complimentary copy of the white paper here!
