Estimado NetOps: La regla de seguridad cero también se aplica a usted
Muy bien, NetOps. A medida que se va automatizando y creando scripts con todo su corazón, es hora de un pequeño recordatorio acerca de la seguridad. No me refiero a firewalls y WAF u otros servicios de seguridad que usted pueda ser responsable de implementar y administrar. Me refiero a los scripts y códigos que vas a utilizar mientras te embarcas en el viaje que es la transformación digital.
Hoy me gustaría recordaros la Regla de Seguridad Cero. Para refrescar tus recuerdos:
REGLA DE SEGURIDAD CERO: NO DEBERÁS CONFIAR EN LA APORTACIÓN DEL USUARIO. ALGUNA VEZ.
Una regla bastante simple, ¿verdad?
Debería serlo, pero no lo es. Las infracciones y las posteriores infracciones en el mundo empresarial se pueden remontar a la violación de la Regla de Seguridad Cero. Las violaciones de esta regla son rampantes en los ejemplos de código que se ofrecen a los desarrolladores mientras investigan y aprenden nuevos lenguajes y marcos, y desafortunadamente también se están infiltrando en el nuevo y apasionante reino de NetOps.
¿Puedo presentar el Anexo A?
Ahora bien, para ser justos, al menos este script tiene la decencia de advertirle que los datos no están validados. Eso es bueno, porque este script continúa realizando todo tipo de manipulación remota de las configuraciones del enrutador en función de la entrada.
Mi problema es que el código está diseñado para ayudar a instruir a NetOps sobre cómo comenzar a utilizar scripts para automatizar dispositivos de red de producción y simplemente hace gestos con la cabeza para la validación de datos sin brindar ninguna información útil sobre cómo hacerlo.
Para obtener buenos consejos sobre cómo validar direcciones IP en Python, consulte esta discusión de Stack Overflow .
Pero Lori, esto es un script y estamos haciendo cosas de CLI y, vamos, ¿qué tan riesgoso es eso?
Los malos hábitos son difíciles de romper.
Ignorar la Regla de Seguridad Cero plantea dos problemas.
Primero, los días del CLI están contados, amigo mío. La API es la nueva CLI y la mayoría de los marcos de automatización están adoptando el uso de API RESTful para aprovisionar y administrar dispositivos y servicios de red. Esto significa pilas de aplicaciones y analizadores. Se refiere a dispositivos que son potencialmente vulnerables a la explotación porque su configuración puede cambiarse a través de una API que puede incluir vulnerabilidades.
Ofrezco como prueba de que no soy hiperbólico este aviso de Cisco con respecto a la ampliamente discutida vulnerabilidad de Apache Struts. El consenso es que pasar información no saneada al marco Struts desencadena todo tipo de problemas.
Pero en caso de que el potencial de explotación no le haga preocuparse por aplicar la Regla de seguridad cero, permítame señalar que no desinfectar la entrada puede tener un radio de explosión mucho mayor que un solo dispositivo. Consideremos lo que sabemos sobre la interrupción de Amazon S3 a principios de 2017:
A las 9:37 a. m. PST, un miembro autorizado del equipo S3 que utilizaba un manual establecido ejecutó un comando cuyo objetivo era eliminar una pequeña cantidad de servidores de uno de los subsistemas S3 que utiliza el proceso de facturación S3. Desafortunadamente, una de las entradas del comando se ingresó incorrectamente y se eliminó un conjunto de servidores más grande de lo previsto.
-- Resumen de la interrupción del servicio Amazon S3 en la región del norte de Virginia (US-EAST-1)
El número que introdujo en el guión fue mucho mayor de lo que pretendía. Pero los scripts que aceptan ciegamente todo lo que ofrece el operador (ignorando la Regla de Seguridad Cero) seguramente conducirán eventualmente a este tipo de error. Una simple –aunque ciertamente molesta– verificación por parte del script podría haber evitado que el tema se convirtiera en el tema de conversación de Twitter durante más de una semana.
En la red, en la producción, a menudo vemos la seguridad a través del lente de la autorización. ¿Tiene Bob autoridad para realizar esta acción? ¿Puede Alice ejecutar este script? Y necesitamos eso, todavía es crítico.
Pero a medida que aceleramos nuestro viaje de transformación digital (interna) y adoptamos más marcos y usamos API y scripts para automatizar por completo el aprovisionamiento y la administración, definitivamente debemos considerar la seguridad también desde una perspectiva de desarrollo.
Y la primera de esas reglas es la Regla de Seguridad Cero: NO DEBERÁS CONFIAR EN LA APORTACIÓN DEL USUARIO. ALGUNA VEZ.
Validar siempre la entrada. No solo proporciona seguridad adicional, sino que también puede evitar que una buena automatización falle.