La información confidencial se colocó en una carpeta de acceso público. ¿Quién es responsable y cómo proceder?

Me resistiría a repartir la culpa, particularmente cuando es claramente un error honesto. Demasiado enfoque en la culpa de un incidente puede envenenar el pozo y hacer que las personas se muestren más reacias a reportar incidentes de seguridad en el futuro. Incluso sin ninguna culpa, ya es lo suficientemente embarazoso como para tener que informar que cometiste un error y que puede haber contribuido a una exposición de seguridad. Me gusta que diga "Me interesa principalmente aprender de esta experiencia". Creo que es una actitud muy saludable y constructiva, y lo aliento a que la repita ampliamente para que todos los involucrados lo conozcan y actúen de manera correspondiente.

Por cierto, puedes pensar en esto como una oportunidad para modelar cómo reaccionas ante los problemas de seguridad. La cultura no se establece por las palabras que dicen los líderes de la compañía, sino por la forma en que actúan, especialmente la forma en que actúan cuando se encuentran en una situación difícil. Modelar la actitud de "esto no tiene nada que ver con la culpa, se trata de aprender de la experiencia" parece ser una buena forma de contribuir a una cultura saludable que le sea útil en el futuro.

Vuelve a tu pregunta central. Creo que la respuesta principal a esta pregunta es probablemente: la comunicación. El primer paso es que las personas involucradas hablen sobre esto y se pongan de acuerdo sobre de quién es la responsabilidad. ¿Es responsabilidad del administrador de la web confirmar que todo el contenido que se coloca en el servidor web público realmente pretende ser público? ¿Es responsabilidad de la persona que publica el contenido? ¿Cómo sabrían estas personas de quién es la responsabilidad?

Tal vez una posible lección que podría considerar es: tener cuidado con los sistemas de archivos / puntos de montaje / directorios compartidos que monta en su servidor web público. Es posible que desee tener una regla general de que hay una separación: cada sistema de archivos / directorio compartido es (a) público o (b) interno, y etiqueta el sistema de archivos / directorio compartido en consecuencia. Bajo este enfoque, evitaría tener un sistema de archivos que contenga algunos archivos públicos y algunos archivos que no sean públicos, y cuando agrega un nuevo sistema de archivos / directorio compartido al servidor web público, puede hacer una rápida comprobación de validez para ver si El sistema de archivos está marcado como público. Esta es solo una idea y, por supuesto, puede o no ser adecuada para usted. No se deje atrapar por los detalles de esta idea en particular; Si no suena útil, ignóralo. El punto más importante es pensar un poco en los procesos que pueden ayudarlo a evitar estos errores, sin meterse en una burocracia innecesaria. Usted sabrá mejor cómo es la cultura y los requisitos de su empresa; debe estar en una buena posición para intercambiar ideas y comenzar una conversación con sus compañeros de trabajo.

  

¿Fui culpable por suponer que el personal de TI o el desarrollador web deberían haberlo solucionado?

Por lo general, intenta mantener los asuntos internos inalcanzables del mundo exterior. Cualquier cosa que entre en producción debe ser verificada y verificada (al menos por el administrador). Bueno, y luego verifica dos veces.

  

¿Quién es responsable de asegurarse de que la información confidencial esté bien protegida?

Depende del tamaño de la organización y la política interna. Esto podría ser administrador del sistema, desarrollador de software, director de información, etc.

  

¿Hay pasos más allá de verificar los registros que debo seguir?

¡Sí! Nunca, nunca almacene contraseñas de texto plano o cifrado. Las contraseñas deben ser troceadas y selladas antes de ser persistentes en una base de datos. Notifique a sus clientes sobre la fuga y proporcione medios para cambiar sus datos privados. Esto puede ser muy grave si tiene clientes reales , hable con un abogado.

Cambie su configuración confidencial, si no se ha hecho antes, cifre sus secciones privadas.

Revise los motores de búsqueda para ver si su contenido ha sido cobrado.

¿Hay pasos más allá de verificar los registros que debo seguir?

Aunque estoy seguro de que está preguntando qué cosas operativas específicas se deben hacer para tratar de garantizar que el material sensible no se haya divulgado o alterado, voy a responder esto con un mayor nivel de abstracción.

En casos como este, me gusta preguntarme Five Whys . Trabaje hacia atrás desde el incidente y determine la causa raíz. Parece que has hecho algún progreso, pero todavía no lo has hecho del todo.

Por ejemplo, si está realizando un seguimiento del incidente y ha determinado que su grupo de desarrollo colocó inadvertidamente material de desarrollo sensible en un entorno de producción, esto significa un lapso en los controles de seguridad en torno a su sistema de configuración mgmt.

Instituya un nuevo sistema de administración de configuración (o altere su existente) que garantice que el grupo de desarrollo no pueda alterar su entorno de producción. Se considera una mejor práctica tener un área de desarrollo y un área de producción (como mínimo; otros, como un entorno de prueba, integración o puesta en escena también son entornos posibles). Los desarrolladores no tienen acceso a la producción ni tienen una herramienta que les permita modificar el entorno de producción sin pasar por algún proceso auditable.

También parece que hay un lapso en la auditoría que podría ser un problema de seguridad mucho mayor. Es posible que desee comprender por qué (de nuevo, 5 por qué) no sabe quién lo puso allí. Tal vez sea porque todos usan la cuenta de root. Encuentre otra forma de obtener los privilegios que necesita (por ejemplo, sudo).

Oh. Y cambia tus contraseñas.

Lo primero que hay que entender es que incluso en el mejor de los sistemas se producirán errores. La buena noticia aquí es que su desarrollador web hizo un buen trabajo al identificar el problema e informar de inmediato.

"¿Fui culpable por asumir"? ¿Recuerdas lo que dicen sobre asumir? ass_u_me ....

La protección de los activos corporativos (de todo tipo) es responsabilidad de la administración de alto nivel y debe ser verificada por su departamento de auditoría interna.

"¿Quién es responsable de asegurarse de que la información confidencial esté bien protegida?" El CEO y la junta directiva. Esta es una responsabilidad que no puede ser delegada. Para las empresas que cotizan en bolsa, los días en que un CEO podría alegar que la ignorancia terminó con Sarbanes-Oxley.

"¿Hay pasos más allá de verificar los registros que debo seguir?" La verificación de los registros después del hecho (cualquier cosa después del hecho) es demasiado tarde. Lo que debe hacer es desarrollar políticas y procedimientos para salvaguardar sus activos y la auditoría de cumplimiento.