Code (or Scripts) Everywhere

I’ve had this article open in my browser since two days after starting BackBox (November 3rd). I knew there was something relatable between the software development and the scripts firewall and network administrators write to be better at their craft. Both are undeniably useful, but can be a risk to the org. I wasn’t quite sure how to express the picture forming in my mind.

Forrester warns that low-code development will lead to a major data breach in 2023. (source SDX Central)

It’s one thing to write an iOS shortcut, as I have, so that when I get near an “out of network” doctor’s office, it asks if I want to create a to-do to file an insurance claim. It’s a whole other thing to write a shortcut to compare password security across my network devices and firewalls and fix any that are “out of compliance” (lower-case ‘c’, meaning simply, different than my company expects or requires).

And, it’s one thing to write one shortcut because I’m lazy. Another to write a whole library of them to manage my network more efficiently and effectively.

There’s no doubt that automating repetitive manual tasks saves money, is more efficient use of skills, and lets network administrators to more in a day. Still, it has to be done with an eye towards security and risk management.

The Forrester Warning

Chris Gardner at Forrester (who I only know through the article, this post is not in any way related to, or sponsored by Forrester) warns smartly about the risk of citizen developers.

His warning is for a different audience. Frankly, the audience I joined BackBox from. That of enterprise development.

I’m guilty of wanting to do a better job faster and eliminate manual and repetitive work. Early in my career I tricked out Excel to create proposals in exactly the way I need to get the right sign-offs and print copies for delivery to customers. I was always tweaking it. If somehow that master spreadsheet disappeared, our ability to bid for new business would have been considerably reduced.

Today, there are low code platforms, open APIs, and even personal tools like Shortcuts on iOS to help people who grew up around this technology (and to whom enterprise technology is archaic) do better work.

Who can blame them for wanting to do better work?

Citizen development is a clear security and operational risk to organizations if it’s not with a similar attention to the craft that software development teams employ.

And that same risk translates to network and firewall administration teams that have done wonderful work automating administrative tasks on their own without a framework for managing risk.

Scripts are a Risk to Networks

I like to minimize risk. There’s enough bad stuff waiting in the shadows, no need to invite more in. Right?

Off the top of my head, coming from software development, I thought it could be useful to point out some of the risks of unconstrained scripting:

• Risks of development error. Are you testing your scripts as rigorously as you’d test software? Likely not. Do you have rich logging of script activity for investigation and comparison with desired outputs? Are your scripts all running the same version of Python or whatever tool(s) you’re using?
• Risk of development tool. Let’s face it, your scripting tool itself can be compromised. It happens often enough it should be a concern. Do you know what libraries the team is using to get their job done? If there were an audit in your organization, could you easily and quickly know where newly discovered vulnerabilities were? I saw this first hand at a few banks who were customers of mine, and it shut them down for weeks as they scrambled to do code reviews to understand where they were vulnerable after a library was compromised.
• Risk of developer dependency. I saw a funny thing once at a customer. They had a business process that worked great, except a few times a year when it took days. Turned out, there was one manual step and when that person was on vacation, worked piled up. You may have everything automated, but who knows how it all works? The person who wrote it to save time (and by definition won’t likely be documenting it until they pass it on to their replacement)? Are you 100% confident that there’s not a human hidden in your automation keeping it all working smoothly?
• Risk of chaos and inconsistency. If you’re not tracking as a team, different people will do things different ways. They’ll use different, but overlapping libraries with similar functionality. Their own skills will drift over time as will the scripts they produce.
• Risk of loss of tooling. Are you backing up your scripts, the schedule that run them, the entire set of things that needs to make everything work right? When was the last time you threw it all out and restored from backup? Yeah, if you haven’t done that, you’re not going to convince me it’s restorable.
• Are the scripts running as they should be? What, you wrote a script to make sure it all runs as expected… head right back to the top of this list.

A Quick Story

Writing this post reminded me of a story from early in my career. I’ll share it quickly. I was working for Box Hill Systems, a maker of hard drive systems for Unix Workstations used by financial service organizations. We got a call from a customer that a system had failed. Could we get a replacement over there?

I grabbed something and was there in 20 minutes or so.

Then I waited for about two hours. They knew their system had failed. There was one problem. They didn’t know where it was.

It was a long time ago, but if they could lose hardware, you can lose software.

Final Observation

Network and firewall administrators scripting without any guardrails at all is a risk.

They approach scripting as a way to solve their current problem (which is good) but without always considering best practices or larger context (not so good). They script-and-forget, and don’t always consider any lifecycle management. How are the scripts maintained? How are they updated to allow for new devices? How are they kept consistent across teams or even individuals?

Want to see how you can do it all? How you can have your scripts and protect your organization from risks pointed out by Forrester?

Let’s schedule a demo?