Increase Security by Becoming a 'Control' Freak in 7 Steps (Pt. 2 of 2)

*This post originally appeared on the AppSense blog prior to the rebrand in January 2017, when AppSense, LANDESK, Shavlik, Wavelink, and HEAT Software merged under the new name Ivanti.

This is Part 2 of Increase Security by Becoming a ‘Control’ Freak in 7 Steps (Pt. 1 of 2).

3. Enforce when ready.

Once these trials have been completed and improvements made, management should announce that these features will be enabled on a certain date, but you should not enable enforcement on that date. Wait at least a week to see what complaints come in. You will be able to identify to management where organizational issues lie because enforcement has not even been activated. Only after resolving those issues should enforcement be enabled.

4. Minimize business disruption.

There will always be cases where risks need to be taken—an unknown executable absolutely has to be installed or a new user or business partner absolutely must have access. Processes and products should be chosen that support temporary exceptions, user self-service with alerting, enhanced monitoring of exceptions, etc.

5. Start smart.

Both “Application Control” and “Privilege Management” can be disruptive to business if implemented abruptly. Prior to any deployment of these controls, inventories of business-critical applications and access needs should be documented and understood. The first phase of deployment should be “monitor only”: allow all operations to proceed without enforcement for at least a week, while potential enforcement actions are analyzed for potential disruption. The next step should be a small-scale prototype test with enforcement enabled,

using only security and IT personnel and any motivated external volunteers. Once any process issues are shaken out, some problem users such as developers, managers and super-admins should be added to the trial.

6. Enforce when ready.

Once these trials have been completed and improvements made, management should announce that these features will be enabled on a certain date, but you should not enable enforcement on that date. Wait at least a week to see what complaints come in. You will be able to identify to management where organizational issues lie because enforcement has not even been activated. Only after resolving those issues should enforcement be enabled.

7. Minimize business disruption.

There will always be cases where risks need to be taken—an unknown executable absolutely has to be installed or a new user or business partner absolutely must have access. Processes and products should be chosen that support temporary exceptions, user self-service with alerting, enhanced monitoring of exceptions, etc.

Taking an incremental approach to deploying “Application Control” and “Privilege Management” fits the success pattern. Focus initial efforts on knowing which applications access critical business data, then tighten up access rights at the user level and application control at the server level. Use the lessons learned from there to assure a broader rollout that mitigates risk without causing unacceptable levels of business disruption.