The phone call went something like this… “Jason, we want your help. For years we’ve been trying to find some way to proactively intercept our most dangerous computer endpoints. I heard that you build automated processes like this.”
I was intrigued. As a workflow developer, I’ve repeatedly been in this situation (hearing big, wild ideas and being asked to build it)–and I relish every challenge like this. What would result would be a controlled, repeatable, reportable and enterprise-grade process whereby the organization’s riskiest computers would be identified and disabled–automatically.
In this article, I share the foundational considerations in the design of such a process.
If it is your job AND mission to rid your enterprise environment of vulnerable computer endpoints, please read on. It IS possible to identify risks and even disable computers using an automated process.
Try as they might, many organizations have never been able to accomplish this feat. The overall hindrance comes from no single point by itself, but the combined complexity of the data analytics, user communication, and overall end-to-end process management required. Yet, to be successful, each of these points must be strategically addressed.
Now, more than any other time in history, workflow automation platforms are maturing that allow you to build out this kind of process to your exact specifications–even if you are not a traditional developer.
Given the risk that looms and the high stakes involved, the goal represents a worthy pursuit. Now, more than any other time in history, workflow automation platforms are maturing that allow you to build out this kind of process to your exact specifications–even if you are not a traditional developer. These platforms provide a no code or low code paradigm allow rapid creation of business logic, interfaces, and reporting. This new landscape of “build it yourself” software platforms has the potential to change the game when it comes to “outside the box” security-related initiatives.
I’ll outline how such a process could work for you, but won’t focus on any specific workflow technology. (If you want suggestions on which is best, please contact me.)
OBJECTIVE: IDENTIFY VULNERABLE COMPUTERS
If you have any experience managing endpoint patching, you know that a subset of systems (hopefully a small percentage) will, for varied reasons, cease the ability to be patched. The exact causes are numerous but are usually related to some kind of OS dysfunction. Regardless, these systems become dangerous vectors that only accelerate in risk as time passes.
You may have other criteria for identifying risky systems beyond Patch level vulnerabilities. Perhaps the presence of certain software, detected user activities, or some other highly customized criteria.
Data is king when it comes to taking automated actions. You likely already have enterprise systems that store data that can be leveraged. The data provided by your patching system can provide triggers for automated action–whatever the system may be, a database backend is common. Workflow platforms allow for rapid external SQL database integration, which would allow you to watch for certain data events on a routine basis.
For other types of computer risks, such as the presence of certain software, you can leverage endpoint management/systems management platforms (such as SCCM, Ivanti, Altiris/Symantec Management Platform or others). All of these have database backends, along with SDK capabilities in situations where that is a more desirable method of integration.
The most involved part of designing and maintaining the process is discovering the criteria to best identify when to take action. You could target certain specific risky patch vulnerabilities and/or develop a scoring system to rate risk of a given computer’s state based on multiple factors.
Some choose to initiate the PC remediation process manually, after reviewing computer details from multiple systems manually and making a human-driven decision to start the process. This is not a bad approach, especially at first. Starting here would keep you from ‘boiling the ocean’. You can build out the automation (end user communication and remediation) and save the detailed criteria involved in the auto-launch of the process for a later phase of maturing the project. Or, go for the gold and build out the entire end-to-end automated process!
OBJECTIVE: COMMUNICATE WITH THE USER AND/OR SUPPORT
Once you have identified vulnerable or risky systems, taking steps to resolve the issue is of paramount concern. Users are often unaware of the problem and even may have done nothing to cause the problem if, say, patch installation issues are to blame. In other cases such as unauthorized software installation–the user may be to blame. Either way, the key is in taking the most appropriate action to resolve the problem.
It is very important to communicate what is happening to the end user. You could provide a series of warnings that ask the user to take some action. If ignored beyond a specified time period, you could then take more drastic actions, such as disabling the computer in Active Directory. Your workflow process could send a series of emails to users and their managers. Integration with instant messaging systems may also be an option to get a more immediate response. If support desk awareness is also important, you could use APIs to create a support ticket (incident or work order) to assist in resolving the problem. If you are using a risk management system, you could also log the discovery there using API. Good workflow systems have eased the ability to call external systems and make integration a snap.
OBJECTIVE: DISABLING COMPUTERS
Disabling the Active Directory Computer object is a very direct approach that would keep the user from logging into the computer. This is a way to immediately address the issue and cutoff the risk to your environment. It does, naturally come with some business interruption–but often the ends justify the means when it comes to risk reduction. You would want to use this action as a last resort–after other attempts to remediate have been ignored by the user or failed in some way.
Most top-tier workflow platforms come with components that interact with Active Directory. This can be placed in the pathway of your process at the appropriate point. If desired, you could only automatically disable the computer AFTER approval for the action is provided from a custom console.
OBJECTIVE: REPORTING AND DASHBOARDING
Highly flexible workflow platforms allow the easy building of dashboards and pages that could assist with a security organization’s management of the end-to-end processes that actively avoid risks. Tiles can summarize and provide an overview of the system’s current efforts. Reports can show specific details and to take action on specific situations.
Since the next step to remediation after disabling a computer is usually an action by the support desk, it is important for this team to have access to consoles/dashboards that let them confirm that this security-related automation is INDEED the reason why the user cannot log in. Such interfaces are also excellent for the support team to use to RE-ENABLE a computer, so that they can login and resolve the vulnerability/risk issue.
The power of emerging workflow platforms means that you can assemble these processes exactly to your specifications and in a way that can be maintained and adjusted over time as your business needs change.
IN CLOSING…
In this article I gave you an overview of how workflow automation could be leveraged to reduce risk in your organization. The power of emerging workflow platforms means that you can assemble these processes exactly to your specifications and in a way that can be maintained and adjusted over time as your business needs change.
About the Author
Jason Drinen has been building workflows for the enterprise for the last 10 years. He currently lives in St. Louis, Missouri and provides consulting and development assistance for those looking to automate challenging processes
