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.
About the Author
Related Blog Posts
The everywhere attack surface: EDR in the network is no longer optional
All endpoints can become an attacker’s entry point. That’s why your network needs true endpoint detection and response (EDR), delivered by F5 and CrowdStrike.
F5 NGINX Gateway Fabric is a certified solution for Red Hat OpenShift
F5 collaborates with Red Hat to deliver a solution that combines the high-performance app delivery of F5 NGINX with Red Hat OpenShift’s enterprise Kubernetes capabilities.
F5 accelerates and secures AI inference at scale with NVIDIA Cloud Partner reference architecture
F5’s inclusion within the NVIDIA Cloud Partner (NCP) reference architecture enables secure, high-performance AI infrastructure that scales efficiently to support advanced AI workloads.
F5 Silverline Mitigates Record-Breaking DDoS Attacks
Malicious attacks are increasing in scale and complexity, threatening to overwhelm and breach the internal resources of businesses globally. Often, these attacks combine high-volume traffic with stealthy, low-and-slow, application-targeted attack techniques, powered by either automated botnets or human-driven tools.
Volterra and the Power of the Distributed Cloud (Video)
How can organizations fully harness the power of multi-cloud and edge computing? VPs Mark Weiner and James Feger join the DevCentral team for a video discussion on how F5 and Volterra can help.
Phishing Attacks Soar 220% During COVID-19 Peak as Cybercriminal Opportunism Intensifies
David Warburton, author of the F5 Labs 2020 Phishing and Fraud Report, describes how fraudsters are adapting to the pandemic and maps out the trends ahead in this video, with summary comments.