La gente normal generalmente solo quiere que las cosas funcionen.
por Mike Bursell (Red Hat)
La mayoría de las personas 1 no se dan cuenta de cuán divertida es la seguridad, o de cuán sexy es ltener experiencia de seguridad. 2 Sabemos que es fascinante, atractivo y genial, los demás no. Por esta razón, cuando las personas de seguridad recurren a otras personas (llamémosles “personas normales” para los fines de este artículo) y les dicen que están haciendo algo mal y que no pueden lanzar su producto, o implementen su aplicación, o que dejen de tomar órdenes de venta de inmediato y probablemente durante los próximos días hasta que esto se solucione, entonces esas personas normales no siempre reaccionan con los niveles de agradecimiento que creemos que son apropiados.
A veces, de hecho, mostrarán respuestas negativas, incluso respuestas negativas bastante personales y de seguro invocará a algún pariente femenino.
El problema es este: la gente de seguridad sabe cómo deberían ser las cosas, y eso es seguro. Han asistido a la capacitaciones, asistieron a las sesiones, leyeron los artículos, hojearon libros pesados, 3 y todas estas fuentes son bastante claras: todo debe ser seguro. Y seguro generalmente significa “cerrado“, especialmente si la gente de seguridad no estuvo lo suficientemente involucrada en los procesos de diseño, implementación y operaciones. La gente normal, por otro lado, generalmente solo quiere que las cosas funcionen. Hay una disyuntiva fundamental entre esos dos puntos de vista que no vamos a solucionar hasta que la seguridad sea el requisito más importante para cualquier proyecto desde su inicio hasta su finalización. 4
Ahora, la gente normal no es estúpida. 5 Ellos saben que las cosas no siempre pueden funcionar a la perfección; pero les gustaría que trabajen tan bien como puedan. Esta es la brecha 7 que debemos cruzar. Ya he hablado sobre la degradación administrada como un concepto, y esto es parte de la historia. Una de las cosas que las personas de seguridad deberíamos estar dispuestas a hacer es explicar que existen riesgos que mitigar.
Para las personas de seguridad, esos riesgos deberían mitigarse “cerrando fallas“. Es fácil detener el riesgo: simplemente detienes el funcionamiento del sistemara y ya no existe el riesgo de que pueda utilizarse de forma incorrecta. Pero para muchas personas, existen otros riesgos: un ejemplo es que la organización, de hecho, podría cerrar por completo porque una persona de seguridad _____ 8 desconectó el sistema de pedidos. Si me hubieran ofrecido la opción de equilibrar el riesgo de dejar de tomar órdenes con el riesgo de perder algunos datos internos de la compañía, ¿lo habría tomado? Bueno, sí, podría haberlo hecho. Pero si no me ofrecen la opción, y el riesgo no se explica, entonces no tengo otra opción. Este es el tipo de palabras que me gustaría escuchar si estoy dirigiendo un negocio.
Sin embargo, no es solo este tipo de riesgo. Llegar a una reunión de proyecto dos semanas antes del lanzamiento y anunciar que el proyecto no se puede implementar “porque la API no se está autenticando” no es nada bueno. Para cualquiera. Sin embargo, como desarrollador, tengo un vocabulario diferente, y diferentes preocupaciones, para las del propietario de la empresa. ¿Qué tal si, en lugar de decir: “necesita usar la autenticación en esta API o no puede continuar”, pregunta la persona de seguridad, “qué pasaría si los datos que se proporcionan en esta API son incorrectos o proporcionados por alguien que desea interrumpir el funcionamiento del sistema? “ En mi experiencia, la mayoría de los desarrolladores están interesados, están invertidos en el funcionamiento correcto del sistema que están ejecutando y los datos que procesa. Hacer preguntas que muestran el posible impacto de la falta de seguridad es mucho más probable que genere reacciones positivas que una “discusión” inicial que básicamente equivale a un “no”.
No me malinterpretes; hay momentos en que nosotros, como personas de seguridad, necesitamos ser firmes y mantenernos firmes. 9 Pero al final, son los propietarios de los sistemas, las organizaciones, las unidades de negocios o los recursos los que toman la decisión final. Es nuestro trabajo hablarles con palabras que puedan entender y asegurarnos de que estén tan bien informados como podamos. Sin decir “no”.
1. Con lo que quiero decir “esas pobres almas desafortunadas que no leen estos mensajes, a diferencia de usted, querido lector inteligente”.
2. Mi esposa, por desgracia, parece pertenecer a esta categoría.
3. Que generalmente tienen una imagen de un candado en la tapa.
4. Y buena suerte con eso.
5. Si bien todos hemos conocido a nuestra parte justa de personas estúpidas y normales, apuesto a que también has conocido a la parte de personas estúpidas de seguridad, por lo que se equilibra. 6
6. Probablemente más que saldos. Dejémoslo ahí.
7. abismo
8. Inserta tu exageración adjetival favorita aquí.
9. Figurativamente: no tolero llevar armas, incluidas armas de fuego, a su lugar de trabajo.
Este artículo apareció originalmente en Alice, Eve y Bob, un blog de seguridad y se republica con permiso.
Esperamos que la metafora no pase desapercibida.
La gente normal generalmente solo quiere que las cosas funcionen.
por Mike Bursell (Red Hat)
La mayoría de las personas 1 no se dan cuenta de cuán divertida es la seguridad, o de cuán sexy es ltener experiencia de seguridad. 2 Sabemos que es fascinante, atractivo y genial, los demás no. Por esta razón, cuando las personas de seguridad recurren a otras personas (llamémosles “personas normales” para los fines de este artículo) y les dicen que están haciendo algo mal y que no pueden lanzar su producto, o implementen su aplicación, o que dejen de tomar órdenes de venta de inmediato y probablemente durante los próximos días hasta que esto se solucione, entonces esas personas normales no siempre reaccionan con los niveles de agradecimiento que creemos que son apropiados.
A veces, de hecho, mostrarán respuestas negativas, incluso respuestas negativas bastante personales y de seguro invocará a algún pariente femenino.
El problema es este: la gente de seguridad sabe cómo deberían ser las cosas, y eso es seguro. Han asistido a la capacitaciones, asistieron a las sesiones, leyeron los artículos, hojearon libros pesados, 3 y todas estas fuentes son bastante claras: todo debe ser seguro. Y seguro generalmente significa “cerrado“, especialmente si la gente de seguridad no estuvo lo suficientemente involucrada en los procesos de diseño, implementación y operaciones. La gente normal, por otro lado, generalmente solo quiere que las cosas funcionen. Hay una disyuntiva fundamental entre esos dos puntos de vista que no vamos a solucionar hasta que la seguridad sea el requisito más importante para cualquier proyecto desde su inicio hasta su finalización. 4
Ahora, la gente normal no es estúpida. 5 Ellos saben que las cosas no siempre pueden funcionar a la perfección; pero les gustaría que trabajen tan bien como puedan. Esta es la brecha 7 que debemos cruzar. Ya he hablado sobre la degradación administrada como un concepto, y esto es parte de la historia. Una de las cosas que las personas de seguridad deberíamos estar dispuestas a hacer es explicar que existen riesgos que mitigar.
Para las personas de seguridad, esos riesgos deberían mitigarse “cerrando fallas“. Es fácil detener el riesgo: simplemente detienes el funcionamiento del sistemara y ya no existe el riesgo de que pueda utilizarse de forma incorrecta. Pero para muchas personas, existen otros riesgos: un ejemplo es que la organización, de hecho, podría cerrar por completo porque una persona de seguridad _____ 8 desconectó el sistema de pedidos. Si me hubieran ofrecido la opción de equilibrar el riesgo de dejar de tomar órdenes con el riesgo de perder algunos datos internos de la compañía, ¿lo habría tomado? Bueno, sí, podría haberlo hecho. Pero si no me ofrecen la opción, y el riesgo no se explica, entonces no tengo otra opción. Este es el tipo de palabras que me gustaría escuchar si estoy dirigiendo un negocio.
Sin embargo, no es solo este tipo de riesgo. Llegar a una reunión de proyecto dos semanas antes del lanzamiento y anunciar que el proyecto no se puede implementar “porque la API no se está autenticando” no es nada bueno. Para cualquiera. Sin embargo, como desarrollador, tengo un vocabulario diferente, y diferentes preocupaciones, para las del propietario de la empresa. ¿Qué tal si, en lugar de decir: “necesita usar la autenticación en esta API o no puede continuar”, pregunta la persona de seguridad, “qué pasaría si los datos que se proporcionan en esta API son incorrectos o proporcionados por alguien que desea interrumpir el funcionamiento del sistema? “ En mi experiencia, la mayoría de los desarrolladores están interesados, están invertidos en el funcionamiento correcto del sistema que están ejecutando y los datos que procesa. Hacer preguntas que muestran el posible impacto de la falta de seguridad es mucho más probable que genere reacciones positivas que una “discusión” inicial que básicamente equivale a un “no”.
No me malinterpretes; hay momentos en que nosotros, como personas de seguridad, necesitamos ser firmes y mantenernos firmes. 9 Pero al final, son los propietarios de los sistemas, las organizaciones, las unidades de negocios o los recursos los que toman la decisión final. Es nuestro trabajo hablarles con palabras que puedan entender y asegurarnos de que estén tan bien informados como podamos. Sin decir “no”.
1. Con lo que quiero decir “esas pobres almas desafortunadas que no leen estos mensajes, a diferencia de usted, querido lector inteligente”.
2. Mi esposa, por desgracia, parece pertenecer a esta categoría.
3. Que generalmente tienen una imagen de un candado en la tapa.
4. Y buena suerte con eso.
5. Si bien todos hemos conocido a nuestra parte justa de personas estúpidas y normales, apuesto a que también has conocido a la parte de personas estúpidas de seguridad, por lo que se equilibra. 6
6. Probablemente más que saldos. Dejémoslo ahí.
7. abismo
8. Inserta tu exageración adjetival favorita aquí.
9. Figurativamente: no tolero llevar armas, incluidas armas de fuego, a su lugar de trabajo.
Este artículo apareció originalmente en Alice, Eve y Bob, un blog de seguridad y se republica con permiso.
Esperamos que la metafora no pase desapercibida.
Compartir esto: