Scripting enables automation, speed, and a more streamlined security posture. In this video, you’ll learn about automation benefits, cases for automation, and scripting consideration.
Scripting allows for the automation of functions that normally you would have to perform manually. This means, when situations occur, you don’t necessarily have to be there to resolve the problems. You have a script that does that for you. This also means that you don’t have to receive a phone call in the middle of the night disrupting your sleep as you’re trying to resolve a problem manually, and you can sometimes identify problems before they occur and automate the process of resolving them before anyone knows an issue was even there.
Another great advantage of scripting is that it’s fast. It runs as fast as the computing systems that it resides on, and you don’t have to worry about somebody typing things in or misspelling anything. Once you’ve set up a script and tested it, it can run without any type of delay or errors. And if we have a script that’s performing processes for us, we can do other things that are much more interesting than typing at a command line.
Scripting certainly saves a lot of time. We can run these scripts whenever we might need them. They can perform their functions over and over again. And you won’t have to provide any type of human intervention. Automation can also help us enforce security baselines. We might have a script that is providing an update or upgrade with security patches, and that script waits for the patch to arrive in a particular folder, identifies that a new patch exists, and then automatically deploys that patch to all of the systems that need it.
I’ve also configured scripts for infrastructure configurations, especially when setting up multiple systems that all need to have exactly the same security. You might set up a script that automatically builds a default router configuration with all the unique settings that your organization requires. Maybe you have a script that creates firewall rules any time you deploy a new firewall to a remote site. Or maybe there’s a script that runs configurations, sets security rules, or configures standard configuration options within a single device. By using a script to provide this configuration, we not only know that we’re putting in a correct configuration, but it’s one that includes all of the security controls required.
You’re probably familiar with the process of scaling up or scaling down a cloud-based application infrastructure. When you’re scaling these systems up, you’re adding new servers and new databases. But you also need to add new security features. And you can scale up the security along with everything else for that application in the cloud. You just have to make sure that you build your scripts to not only include the servers and databases but also the firewalls and other security devices along with it.
This is also great for members of your information technology staff. Instead of everyone manually typing in and dealing with problems on an ad-hoc basis, you can create scripts that perform many of those functions automatically, and they can move away from the boring tasks and concentrate on something that’s much more interesting.
Automation has the ability to react very quickly when a problem is identified. We can set up constant monitoring of a system. And if anything changes in that system that needs to be addressed, we can automatically apply those changes. For example, we might monitor a server for available disk space.
And if we identify that the disk space is becoming low, we can have a script go into temporary files and clear out some of that space so that the system remains up and running. And since these scripts run 24 hours a day and 7 days a week, we don’t have to have an individual manually monitoring a server for disk space. We can simply have the scripts take care of all of that for us.
Many organizations will automate the process of onboarding and offboarding. When you’re onboarding, there are a core set of resources that almost every employee needs access to. For example, they will need their own home directory. They’ll need access to a printer that’s near them. And they’ll need access to email.
An onboarding script can automatically create the user’s account, assign them to the correct groups, and make sure they have access to the files and resources they need. Automation can also be used two stop payments from making mistakes. We refer to these as guardrails. The guardrail is an automated verification of information going into a system. So a human might be typing into a server, but an automated script is going to verify the information that’s being input and make sure that the information is not going to cause a problem with that destination system.
For example, a technician may try to delete a folder on a server but mistakenly chooses a much larger area of the server to delete. By using guardrails, we can have this automation monitor that process and block anything that would cause critical files to be deleted.
Throughout a normal workday, there may be constant changes to the security groups associated with the employees in your organization. And because of that, you might want an automated system to be able to add and remove users from particular security groups. This can also be very useful for monitoring security groups. For example, you may want to create a report or an alert that monitors the administrator group. And if a person is added to the administrator group, you would be informed immediately.
If you work in an organization with a help desk, you may be already using automation. Many help desks support the ability to email the help desk. The automation can take an email submission, turn that email into a help desk ticket, and, based on the information that’s in the email, can even assign that ticket to the appropriate person.
And if we’re monitoring the right resources with our scripts, we can identify problems before they become an issue. Normally, this issue would occur, and we’d have to escalate the problem to a higher level technician. But if we’re constantly monitoring these resources, we may be able to have the script resolve the problem for us without any human intervention. If the script is not able to resolve this problem, it can automatically escalate the issue to the technician who’s on call.
Automation can also be used to enable or disable services. For example, if a service needs to be used for a certain amount of time, you can have the script enable the service. And then after that time frame is complete, it can then disable the service without any human intervention. Application developers can use scripting to provide constant development and code updates and push those code updates automatically out to systems.
And when you’re working with a cloud-based infrastructure, a firewall, or almost any other device in your infrastructure, you may want to use automation to speak directly to the application programming interfaces, or APIs, on those devices. This allows you to programmatically control those devices without manually having to log in and click things on the screen. The script handles the process of communicating to the API and making any changes necessary on that device.
But, of course, scripting is not a panacea, and there are important concerns when implementing any type of automation. For example, scripts are relatively complex, and they have to interact with other devices and other systems. This requires a great deal of testing to make sure that all of these will work well together.
These scripts also don’t create themselves. Someone does have to sit down and go through the process of coding out all of these different scripts. That means that there’s not only time involved but also a cost associated with that script creation. And like any other device that may be in your network, that script could be a single point of failure. If that script stops working, there could be a significant problem with the devices that rely on that automation.
I’ve personally worked with organizations that spend a lot of time working on issues that come up throughout the day. And a lot of this work seems to revolve around solving the symptoms that have been created instead of addressing the core root of the problems. We refer to this as technical debt, and sometimes creating a script to hide a much bigger problem can increase the amount of technical debt in your organization.
And of course, someone has to support this script going forward. This script may be working fine today. But later on, you might change the type of operating system associated with the service, the scripting language might have modifications, and someone will need to update these scripts to bring them up to the latest versions.