Dear NetOps: Security Rule Zero Applies to You Too
Okay, NetOps. As you’re getting all automated up and scripting your hearts out, it’s time for a gentle reminder about security. I’m not talking about firewalls and WAF or other security services you may be responsible for deploying and managing. I’m talking about the scripting and code you’re going to be doing as you embark on the journey that is digital transformation.
Today I’d like to remind you about Security Rule Zero. To refresh your memories:
SECURITY RULE ZERO: THOU SHALT NOT TRUST USER INPUT. EVER.
Pretty simple rule, right?
It should be, but it isn’t. Breach and after breach in the business world can be traced back to Security Rule Zero being violated. Violations of this rule is rampant in the example code you see offered up to developersas they research and learn new languages and frameworks, and unfortunately it’s also creeping into the exciting new realm that is NetOps.
May I present Exhibit A:
Now, to be fair, at least this script has the decency to warn you that data is not validated. That’s good, because this script goes on to do all sorts of remote manipulation of router configurations based on the input.
My nit with this is that the code is designed to help instruct NetOps how to get started with scripting to automate production network devices and merely head nods to data validation without providing any helpful information on how to do that.
For some good advice on validating IP addresses in Python, check out this Stack Overflow discussion.
But Lori, this is scripting and we’re doing CLI stuff and come on, how risky is that?
Bad habits are hard to break.
There are two issues with ignoring Security Rule Zero.
First, the days of the CLI are numbered, my friend. The API is the new CLI, and most automation frameworks are embracing the use of RESTful APIs to provision and manage networky devices and services. That means app stacks and parsers. It means devices that are potentially vulnerable to exploitation because their configuration can be changed via an API that may include vulnerabilities.
I offer as evidence I am not hyperbolic this Cisco advisory with respect to the widely discussed Apache Struts vulnerability. Consensus is passing unsanitized input to the Struts framework triggers all sorts of badness.
But just in case the potential for exploitation doesn’t move you to worry about enforcing Security Rule Zero, let me point out that failure to sanitize input can have a much larger blast radius than a single device. Consider what we know about the Amazon S3 outage in early 2017:
At 9:37AM PST, an authorized S3 team member using an established playbook executed a command which was intended to remove a small number of servers for one of the S3 subsystems that is used by the S3 billing process. Unfortunately, one of the inputs to the command was entered incorrectly and a larger set of servers was removed than intended.
-- Summary of the Amazon S3 Service Disruption in the Northern Virginia (US-EAST-1) Region
The number he input to the script was much larger than he intended. But scripts that blindly accept whatever the operator offers (ignoring Security Rule Zero) are bound to eventually lead to this kind of mistake. A simple – though admittedly annoying – verification by the script might have prevented the issue from becoming the talk of Twitter for more than a week.
In the network, in production, we often view security through the lenses of authorization. Does Bob have authority to perform this action? Can Alice execute this script? And we need that, it’s still critical.
But as we pick up speed on our (internal) digital transformation journey and adopt more frameworks and use APIs and scripts to automate the heck out of provisioning and management, we absolutely have to consider security from a development perspective, too.
And first among those rules is Security Rule Zero: THOU SHALT NOT TRUST USER INPUT. EVER.
Always validate input. Not only does it provide additional security but it can also prevent good automation from going bad.