Security Justifications for Infrastructure as Code (IaC)

Last week, the Cybersecurity & Infrastructure Security Agency (CISA) put out an emergency directive which ordered federal agencies to pull Ivanti Connect Secure and Ivanti Policy Secure installations from their networks with a deadline within 48 hours.

In order to bring the solutions back on-line, they were required to export the configuration, bring back to factory reset, upgrade to supported software versions, reapply the configurations and then ensure all credentials impacted were revoked and re-issued.

Just thinking about revoking a bunch of credentials, recreating them, and then getting the systems which use said credentials properly updated is a ton of work if all that has to be done manually. We often talk about how Infrastructure as Code (Iac) helps on the front end, with deployments, but if you think about recovering from a security incident, you are likely performing those same deployments again. So if your organization needs another reason to embrace IaC, security incidents is another reason to do so.

1 Comment (+add yours?)

  1. dave wentzel
    Feb 05, 2024 @ 13:33:09

    It’s my understanding this is needed b/c the vulnerability affects EOL versions of their product and there’s no clear upgrade path that maintains all configs. IaC is bigger than just “infrastrucure”…it’s really about logging/audit trail for any changes to any IT system (there really needs to be a more encompassing term for this). And this is something few folks do. GitOps is one way to do this (everything gets checked in and then git implements it) but it requires UH LOT to setup (also maturity).

    Still in 2024 when talking to database professionals I see far too many folks that still “cowboy” a db config change (an index maybe) and don’t properly “check in” the change with a brief synopsis of why they did it. And almost no one is doing these things in a manner where they can just run all of the scripts since the beginning of time and POOF…they have a working database (minus the table data).

    This is appalling to me. For years the Number One reason nobody wanted to upgrade their SQL Server (or apply patches) is they had too many manual config changes and they had no confidence they could rebuild a server if something went south…or the rebuild documentation was 20 pages and no one had confidence it was maintained. This is the exact CISA problem. In the age of the cloud with VMs that were IaC-able and especially containers…this led to the phrase “cats vs cattle”. I viewed my on-prem servers as pets/cats…I loved them, cared for them, and would NEVER hurt them…in the age of the cloud it’s more like “cattle”…if a cow gets a disease I shoot it in the head and go get another cow. (morbid thought, sorry).

    TO THIS DAY I still see network engineers who manually configure VPCs and VNets with hand-crafted love and don’t take the time to script everything. Years ago when folks were migrating to the cloud they’d ask me what are the skills that they really need. Number One: scripting skills. Make sure everything you do is scripted and possibly automated. There aren’t excuses anymore for not doing it.

    Reply

Leave a comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.