Create and Validate a Security Policy
Create and Validate a Security Policy
You have almost finished your Netskope deployment and are now ready to test the enforcement of a basic policy.
All policies within Netskope, regardless of the feature (CASB, SWG, Firewall, ZTNA, etc) all follow the same structure:
- Source Attributes: User, AD Group, OS, Device Posture, Country, etc.
- Destination Attributes: Category, App, Instance, etc.
- Destination Contraints
- Activities/Actions: Browse, Download, Upload, Share, Like, Delete, Edit, etc.
- Application Tag: Sanctioned, Unsanctioned, Test, etc.
- App Instance Tag: Production, QA, 3rd Party, etc.
- Destination Country: China, Russia, etc.
- App Risk / Cloud Confidence Level (CCL): Low, High, Medium, etc.
- Action: Block, Allow, Coach, Isolate, Alert, etc.
- Profile: DLP, Threat Scan.
Netskope policies operate on the principle of first match, top-to-bottom.
To learn more:
When configuring policies, you should start with your very broad/organization-wide rules before creating deeper and more specific rules.
The more constraints/attributes that a rule has, the trickier it can be to validate. It is important that your organization has a number of baseline rules in place that will affect every user regardless of attributes (for example, globally block adult sites and P2P).
Create a Test Policy
Go to Policies > Real-time Protection. Your Netskope tenant will already have some policies in place by default (such as malware scanning).
Click New Policy, and then either Web Access, or Cloud App Access (depending on what is available to you based on your subscription).
Selecting Web Access, Cloud App Access, Firewall, Private App, or any other option, only presets the destination field in the policy creation workflow, and you can change this as you see fit. In reality, it does not matter what you select as long as your selected destination on the policy creation workflow is accurate.
Create a new policy under Policies > Real-time Protection. As an example:
- For the Source field, set the user to be yourself.
- Note that you can also add other Source criteria that must be validated during policy evaluation, such as the source country the user is connecting from, the operating system of their device, or whether the device is classified as managed or unmanaged.
- For the Destination field, either set it to Category or Cloud App (depending on your subscription).
- If Category, set the targeted category as Gambling.
- If Cloud App, set the targeted application as WeTransfer.
- For Activities, select Browse.
- For Profile & Action, set the action to User Alert.
- The template you are prompted to select what the notification that is displayed to the user will say. You can customize these as you see fit under Policies > User Notifications.
- The User Alert action is a “coaching” prompt. The user is allowed to proceed through the warning that is displayed, and (depending on the template used) may be forced to enter a justification reason as to why they need to proceed.
- Name the policy: [Access Control] Test Policy Coaching on Gambling Sites
- Ensure the Status is set to Enabled and click Save at the top-right.
- When prompted, save the policy at the top.
It is a good idea to prefix a label/tag to your policies that describes the type of policy it is or feature that is used. For example: [DLP] Prevent Download of Sharepoint Data, or [Access Control] Block access to non-business sites.
Back on the Real-time Protection page, you should now see your new policy at the top of the list. Click Apply Changes at the top right to commit and push the policy to production. Changes will only take a few seconds to apply globally to all users.
Policies do not take effect until your changes are applied. This is to prevent adverse impacts to your production environment as you create and edit policies.
Test your policy
You should receive a Netskope notification page that allows you to proceed (as the action selected in the policy was User Alert and not Block). The contents of the notification page will depend on the template you selected in the policy.
If you don’t receive a user notification when navigating to the above sites, try again using an Incognito or Private Browser window. If this fixes the issue, then the problem was related to the Browser Cache.
If the notification fails to display even inside a private window, check that the traffic is being SSL inspected correctly by examining the certificate of the site. You will see an intermediate certificate with the name
ca.<tenant-name>.goskope.com if inspection is working correctly. If this certificate is missing, then it is likely that the site is bypassed from steering or SSL Inspection. In this case, you should review your bypasses (Add Bypasses in Netskope).
You should also confirm that you applied the configuration changes you made under Policies > Real-time Protection. If any of your rules have a yellow exclamation warning icon next to them, or if the Apply Changes button at the top-right is not grayed out, then you have not committed your changes and your policy won’t have applied.