¿Qué tan involucrado debería estar un desarrollador en el diseño de una política de seguridad?

También soy un desarrollador, y mi pasión por la seguridad a menudo hace que la dinámica sea un poco inusual al tratar con otros desarrolladores que no se centran en la seguridad.

Hay tres áreas principales de restricción cuando se trata de la política de seguridad:

• Usabilidad: asegurarse de que el usuario pueda usar el software y de que no se irriten o retrasen demasiado por las medidas de seguridad.
• Técnico: asegurarse de que los mecanismos de seguridad se implementen correctamente y de que no afecten el tiempo de actividad, la capacidad de mantenimiento u otros factores técnicos críticos.
• Financiero: asegurarse de que las medidas de seguridad no cuestan demasiado, ya sea a través de costos financieros directos (por ejemplo, comprar cajas negras con luces parpadeantes) u horas de trabajo adicionales.

Su trabajo debe involucrar el asesoramiento sobre los factores técnicos y sugerir las formas en que podría mitigar cualquier impacto de usabilidad. Sin embargo, debe casi siempre someterse al juicio técnico de un consultor de seguridad competente (siendo la palabra operativa competente) si no están de acuerdo con usted en un asunto de seguridad técnica. Es su trabajo integrar las necesidades en un producto de manera óptima, mientras se superan los difíciles obstáculos.

En términos de la participación directa en la política de seguridad para el desarrollo de software, depende en gran medida de:

• Si tiene una persona o equipo de seguridad dedicado.
• En qué sector trabaja (significa que podría necesitar lidiar con datos de PII o HIPAA)
• Dónde se encuentra en la organización y si está en condiciones de efectuar cambios.
• Cómo se enfoca la seguridad en la empresa.

La parte interesante de esta pregunta surge cuando considera que la mayoría de las organizaciones de software no tienen una persona de seguridad dedicada, y mucho menos un departamento. Independientemente de si su empresa lo hace o no, usted tiene el deber de conocer los tipos de problemas y mecanismos de seguridad que se aplican a su trabajo. Si su compañía no tiene un "tipo de seguridad", esa responsabilidad es aún mayor. Parte de su trabajo es implementar software de trabajo y confiable, que incluya seguridad, pero otra parte implica transmitir información técnica a la administración de manera que puedan entender. No puede hacerlo de manera efectiva a menos que entienda los problemas a mano.

En resumen, no hay una respuesta simple. Debe tomar algunas decisiones de seguridad e implementar ciertos mecanismos como parte de su trabajo, porque eso es lo que hace un desarrollador. En lo que respecta a a qué distancia va, depende completamente de usted como persona y de la organización en la que trabaja. Para emitir juicios razonables cuando no se proporciona una directiva de anulación, usted Necesito poner en el trabajo para entender los problemas.

Estoy a favor de impulsar a las personas a mejores estándares de seguridad, sin embargo, me gusta controlar mi propio destino. Mi preferencia sería que usted desarrolle opciones para darles a los administradores la flexibilidad de tomar sus propias decisiones, pero establecer los valores predeterminados a un alto nivel de seguridad. De esa manera, si alguien se interesa, puede hacer que las cosas se ajusten a su propia política de seguridad interna, y si lo utilizan de manera inmediata, tiene altos estándares.

OMI, incluso en un "mundo perfecto", un programador debería participar. El programador debe tener los conocimientos suficientes para traducir los requisitos empresariales y la jerga de seguridad en lenguaje de desarrollador y viceversa.

En pocas palabras, solo un desarrollador entiende exactamente cómo funciona el software, y es posible que algo se haya "perdido en la traducción". Como mínimo, un desarrollador (o revisor de código, alguien que esté familiarizado con el código real) debe participar y asegurarse de que las personas que formulan las políticas no lo hacen por un malentendido de cómo se implementa algo bajo el capó. p>

No solo ayuda a garantizar que los demás integrantes del equipo comprendan y eviten los errores, sino que el establecimiento de una política / estrategia de este tipo ayuda a garantizar que el programador esté totalmente comprometido con la seguridad de su sistema. Simplemente no enseñan prácticas seguras de codificación como deberían. Las escuelas, o los tutoriales en línea, comienzan enseñándote cómo hacer las cosas, y hay tanto que aprender que rara vez se molestan en cómo no hacer las cosas.

Cada falla de seguridad en el mundo de TI es el resultado del software en alguna parte. En el nivel del sistema operativo, en las API que está llamando, su propio código, en algún lugar hay una falla que permite que ocurra el mal comportamiento. Podría ser un error en el código, o un requisito absurdo, pero incluso los requisitos deficientes son fallas en el código que se construye según la especificación de esos requisitos.

Por lo tanto, tiene sentido asegurarse de que los desarrolladores estén involucrados, hacer que piensen en la seguridad, y para asegurarse de que no haya malentendidos que puedan causar problemas.

Como desarrollador, diría que depende del usuario final definir cuáles deberían ser los requisitos de seguridad del producto. Deben ser el mejor lugar para comprender el panorama de amenazas que enfrentan y los riesgos con los que deben lidiar.

Dicho esto ... es poco probable que encuentre un cliente perfecto que conozca de inmediato sus requisitos de seguridad, momento en el que busca analistas de negocios (que pueden incluir desarrolladores, en particular arquitectos con un conocimiento profundo de la producto) para ayudar a derivar esos requisitos.

Desde el punto de vista del desarrollador, conocer la mejor manera de implementar esos requisitos será la clave. Y, lo más importante, al saber cómo escribir software seguro, lo último que necesita es un desbordamiento de búfer / inyección de SQL que rompa todos los requisitos y el diseño agradable.

En términos de configuración de seguridad, me suscribo a la mentalidad de seguridad por defecto, de modo que se implementa de la forma más segura posible con la opción de relajar los controles de seguridad según sea necesario.

Como arquitecto de software y profesional de seguridad, lo que pienso de esto es que si bien es fundamental para los desarrolladores tener una mentalidad centrada en la seguridad para diseñar software seguro de alta calidad, la configuración en última instancia debe estar a la altura de las necesidades empresariales del final. Empresa o usuario. El software debe diseñarse de tal manera que resguarde contra el comportamiento malicioso y para que sea compatible con un sistema de seguridad tan riguroso como se espera que sea necesario, pero la seguridad también es un acto de equilibrio entre la necesidad de usabilidad y la seguridad. Como desarrollador, a menudo no es posible que tomemos la mejor decisión con respecto a los detalles de configuración exactos que satisfagan mejor las necesidades de cualquier empresa o usuario que termine de usar el producto.

Esta respuesta cambia si está diseñando software para uso interno y, por supuesto, se conoce el nivel de seguridad necesario antes de implementar el software, aunque tener la capacidad de ajustar la configuración más adelante no es necesariamente algo malo si no causa riesgo de nuevos agujeros de seguridad por exceso de complejidad.

Escribí algunas líneas de base para un cliente, una de las cosas más importantes que debe hacer es asegurarse de que las personas que lo implementarán también estén involucradas en la creación. Independientemente de si son desarrolladores o administradores, ... debería haber una política de seguridad (parcial) similar, especialmente cuando se trata de contraseñas.

Cuando los involucres, deberás:

• Obtenga información y los problemas a los que se enfrentan regularmente, de esta manera, puede definir fácilmente el alcance, brindarles nuevos conocimientos y ayudarlos a resolver los problemas desde una perspectiva de seguridad
• Lo ven un poco como su propio proyecto y adoptarán y aceptarán la política más fácilmente
• Si tienen preguntas, les preguntarán mucho más rápido y usted podrá darles consejos.
• Debido a que aceptan y entienden por qué está creando una política de seguridad, incluso podrían promover o solicitar proyectos de seguridad similares con mayor facilidad

En un mundo perfecto, su equipo / compañía seguiría pautas como el ciclo de vida de desarrollo seguro, combinado con restricciones adicionales según su campo de trabajo (influenciado por la ley / restricciones de cumplimiento, por ejemplo).

Si echa un vistazo aquí: enlace lo verá con una base muy técnica donde todos PODRÍAS estar involucrados en.

Por lo general, Scrum Masters supervisa la implementación de estas directrices y recopila comentarios de los desarrolladores. Pero probablemente esa no sea la "solución perfecta del mundo".

Para ir con su ejemplo de la contraseña: el responsable de supervisar la implementación de la política de seguridad le dirá a usted / a su jefe de equipo / al propietario del producto, que la contraseña debe tener 16 números alfa y volver a verificar si fue implementado Definitivamente no es tu trabajo investigar sobre esto (mundo perfecto). Tendría una lista muy larga de estas cosas, en realidad :)