Security awareness compliance training refers to a specific training initiative created to educate employees, contractors, and other involved parties within a company regarding the significance of adhering to security measures, guidelines, and mandates. The fundamental aim of this training is to foster a mindset of security awareness and adherence across the entire organization. By doing so, it guarantees that all individuals comprehend their obligations in upholding the confidentiality of delicate data and countering security risks. However, not all users fulfill their training requirements punctually. At Netskope, over the past few years, we have persistently dispatched regular emails to users, urging them to finalize their training. Presently, we are exploring innovative and effective strategies to ensure timely completion of training by users.

Using Netskope, Okta, an LMS with an API, and a SOAR solution, we have created a solution to track users with missing security training and enforce policies on them. With Netskope’s Real Time policies, we can customize policies as per the requirement in a granular manner. Here is a brief explanation on how we did this:

Requirements:

• Netskope and Okta SCIM integration (https://docs.netskope.com/en/netskope-help/videos/microlearning/configuring-okta-scim-with-netskope-scim/)


• LMS with API to check the user enrollment status


• A SOAR or a script to evaluate deadlines and make API calls to your LMS and Okta.

With this in mind, we can start with the basic concepts of the solution. We wanted to make sure there were different restrictions imposed on users that were not completing their yearly security training. We had three policies in mind, the first policy would be for users that needed a reminder that the deadline for their training was coming close, we chose 10 days before the user’s deadline (we will refer to it as the “B10” group). The second policy would be for users that had just hit their due date for their required completion, we called this the “Due Now” group. The third group is for those who have gone long past their deadline, specifically 10+ days past the deadline, we will refer to this one as the “P10” group.

Within Netskope, we created three Web custom categories following the naming convention mentioned above, and added categories to each group based on the severity of the deadline violation. For example, we realized that the B10 and Due Now groups are probably users that just needed reminders about their training, so the categories we added were a bit less disruptive (shopping, games, financial news, etc).

As for the P10 group, since these users are past due, we decided to be as disruptive as possible to get them to do their training sooner rather than later (most, if not all, categories are within this custom category). A web url list was created and populated with the domains to our enterprise login page, our LMS, Slack, and some other domains. This URL list is used as an exclusion list within the three categories, to make sure users can do their training without any policy related disruptions.

Within Netskope we also create two user notifications (for B10 and DueNow) and one block notification (P10). We then created three real-time web based policies and once again named them using the previous naming convention. We used the matching custom categories as the Destination in the policies. The first two policies, B10 and DueNow, should be set to user alert. The third policy, P10, should be set to block.

Within Okta you will have to create three groups that will be used within Netskope as the source for the policies. Using the same naming convention, we created three groups and made sure they were a part of the SCIM synced groups integration.

It will take a couple of minutes (could be less), but eventually you will be able to choose the groups within the source field in the policies. Set the policies to the appropriate groups. We also created an exception group and policy, in the event there were any approved exceptions for users. This policy was placed above the other three policies, to make sure the “Allow” action from the policy wasn’t ignored.

Once this has been set up, we can start to work on the logic for the automation. Create a service account and Okta API key specifically allowing read and write access to the groups created earlier. The next step is to create a service account and API key from your LMS (depending on the LMS, a service account may not be needed). Now that we have both of these, we can play around with the API to see what we can use for determining the user’s group placement. 

Our LMS allowed us to retrieve a user's enrollment and the status of said enrollments, so we looked at the user’s deadline and status for their security training. First, we checked to see if the user has completed their training, if so, we check to see if the user is within any of the affected groups, we remove them if so. Otherwise, if the user has not completed their training, we take the deadline for the enrollment and turn it into a unix timestamp. We then subtract the timestamp from the current time and we see if the enrollment is within 10 days of being due (x<=864000 AND x>=1), is already due (x<=0 AND x>=-863999), or if the enrollment is past 10 days due (x<=-864000).

Some things to take into consideration, if the user is added to a new group, we made sure to check if the user was a part of any of the other groups and removed them if so. We did this by pulling a list of the users within the Okta groups and saving the user id’s within arrays. We then checked the enrolled users Okta id against the list before performing any API calls to remove the user from the group. This helped us save on API calls made to Okta. It is also important to add some rate limiting checks and backoffs, in the event we ever hit Okta’s API limit.

We used the following endpoint to look for users within groups:
GET <OKTA DOMAIN>/api/v1/groups/<GROUP ID>/users?limit=200

This is a paginated call, so we set the limit parameter to 200 per call and checked the call’s response to see if there were more results via the following regex: s+<.*?after=.*>

This is the endpoint we used to add/remove users, depending on the action, the HTTP method used will be PUT to add users, and DELETE to remove users:

To ADD: PUT <OKTA DOMAIN>/api/v1/groups/<GROUP ID>/users/<USER’S OKTA ID>

To REMOVE: DELETE <OKTA DOMAIN>/api/v1/groups/<GROUP ID>/users/<USER’S OKTA  ID>

A successful response for either will give a 204 status code. Here is a link to Okta’s management API to learn more about each endpoint: https://developer.okta.com/docs/reference/core-okta-api/

Considerable flexibility exists for tailoring this solution to your specific needs. You have the ability to customize various actions applied to your policies, as well as adapt deadline infringement consequences to align with your unique compliance requirements. You can also personalize the categories and applications that users can access without triggering alerts, all in accordance with your environment and specifications. We invite you to share any additions or modifications you'd make to this solution – your input and ideas are highly valued and appreciated!