IT security isn’t anything like the movies: staring intently at the screen and yelling a lot isn’t going to solve anything. In reality, IT security is intertwined with all aspects of IT, from the end-user experience to choices made in implementing automation tasks as simple as a shell script.
Business needs drive much of IT automation, but the mark of a veteran sysadmin is a carefully cultivated paranoia. The mark of a master sysadmin is that the paranoia is undetectable to the end user.
IT automation at work
One of the most common IT automation tasks a sysadmin might encounter is that of moving a file from one place to another. There are any number of ways to go about this, but let’s examine security considerations, including some that aren’t obvious at first glance.
First, consider the systems administrator writing the script. If you got hit by a bus the day after you wrote it, could the next sysadmin make changes without going mad? Documenting code isn’t just politeness: it means that all the security considerations you build in today are likely to be retained when the code is reviewed tomorrow.
In the specific case of moving a file from one place to another, you would want to avoid hard-coding paths in. It’s good to make these variables so that if a future sysadmin needs to change some other aspect of the infrastructure—say renaming shares because a merger with another company has caused a naming conflict—they don’t have to rewrite core code.
Similarly, this limits the kinds of string manipulation you can use. In turn, this can influence language choice—it’s a lot easier to work with variable strings in some languages than others—which can influence execution environment and so forth.
From a practical standpoint, you probably want to make a backup copy of files that have been moved in case something goes wrong with the move. This means writing another script to archive or delete these backup copies lest you end up with a directory full of 10 million files, all of which potentially contain sensitive information that nobody except IT staff (which may or may not still work there) know about. These backup copies are also useful for verifying that the move was successful, usually by comparing hashes.
The backup files are important because something will fail at some point and you will be asked to “replay” some file moves. If you don’t have the backups, staff will start to build their own work-arounds and now, instead of two problems you control, you have one problem you control, and an unknown number that you don’t.
The type of information being copied matters. If the information is sensitive and you’re operating in a regulated environment, you might have to have your script check that the target system is security compliant each time before you copy data over.
IT security can’t be an afterthought
These, and other considerations are the sort of thing that are often ignored, but shouldn’t be. And we’re talking here only about basic IT automation involving copying files from A to B. Think of the planning required for creating a properly secured, automated endpoint-imaging system, mobile document management, or printer access for workers outside the corporate firewall.
There isn’t a whole lot of “doing” in IT security. It’s mostly a lot of thinking, planning, and trying to find ways to break whatever it is that you’re designing.
What’s more important is that IT security and IT automation are inextricably intertwined. Given that all of IT is about automating something, this means that IT security must stop being an afterthought or something we hope the purchase of some third party software will solve.
All businesses today are IT companies, dependent on scripts and management software, robots, and clouds for basic functionality—like most sysadmins working in IT automation and, by extension, IT security.