- La seguridad es una cadena, tan débil como el eslabón más débil... casi siempre los usuarios(entendido en sentido amplio, también los administradores se llevan lo suyo).
Realmente la seguridad no es una cadena, aunque suele serlo. Un paso para aumentar la seguridad es cambiar esta topologia de cadena por una de estrella. Ejemplo:
Si monto un jail o chroot, solo se compromete el servicio afectado que corre en el. Esto es asi, siempre que no se pueda comprometer la jaula o el chroot. Esto me permite tener varios sistemas no demasiado confiables en una maquina, sin que se vea afectada la seguridad de toda la maquina.
Por lo demas, no se me ocurre ninguna puntualización.
Es curioso que hoy en el curro, ha surgido una charla sobre seguridad. Creo que es mas dificil superar las trabas organizativas de una empresa, que las tecnicas para conseguir hacer desarrollos seguros. Hemos llegado a las siguientes conclusiones:
- Necesitamos un framework de trabajo que nos permita (y nos obligue) hacer validaciones de todos los datos. A mas capas mejor, desde la base de datos, hasta la capa de presentación. Nunca hay tiempo para ese framework.
- Necesitamos poder hacer un analisis previo de la aplicación, para estructurarla de una manera ordenada y auditable. Tampoco hay tiempo para esto. Los buenos diseños son auditables y reparables en caso de negligencia.
- Necesitamos poder auditar el codigo de las herramientas que utilizamos. ¿Puedo robar las sessiones de Tomcat, o este asocia la ip del usuario? ¿Que ip asocia a la session (en caso de hacerlo), la del socket o la que te da un posible proxy http?
- Es mejor usar sesiones, que dejarle la información al usuario, por muy encriptada que esta esté. Eso si, desde el punto de vista de la seguridad, no del rendimiento.
- ...
Basicamente, solo llegamos a una regla: "Validar datos". Que sean correctos, confiables, sin desbordamientos de buffers, ... Pero solo eso, validar datos. El problema es saber validarlos, y hacerlo de una manera que requiera el minimo esfuerzo: "Si algo cuesta, ya se hara en una hipotetica segunda fase" (Traduccion: Nunca).
Topologia de la seguridad
(Puntos:1)( http://127.0.0.1/ | Última bitácora: Jueves, 01 Julio de 2010, 03:18h )
Realmente la seguridad no es una cadena, aunque suele serlo. Un paso para aumentar la seguridad es cambiar esta topologia de cadena por una de estrella. Ejemplo:
Si monto un jail o chroot, solo se compromete el servicio afectado que corre en el. Esto es asi, siempre que no se pueda comprometer la jaula o el chroot. Esto me permite tener varios sistemas no demasiado confiables en una maquina, sin que se vea afectada la seguridad de toda la maquina.
Por lo demas, no se me ocurre ninguna puntualización.
Es curioso que hoy en el curro, ha surgido una charla sobre seguridad. Creo que es mas dificil superar las trabas organizativas de una empresa, que las tecnicas para conseguir hacer desarrollos seguros. Hemos llegado a las siguientes conclusiones:
- Necesitamos un framework de trabajo que nos permita (y nos obligue) hacer validaciones de todos los datos. A mas capas mejor, desde la base de datos, hasta la capa de presentación. Nunca hay tiempo para ese framework.
- Necesitamos poder hacer un analisis previo de la aplicación, para estructurarla de una manera ordenada y auditable. Tampoco hay tiempo para esto. Los buenos diseños son auditables y reparables en caso de negligencia.
- Necesitamos poder auditar el codigo de las herramientas que utilizamos. ¿Puedo robar las sessiones de Tomcat, o este asocia la ip del usuario? ¿Que ip asocia a la session (en caso de hacerlo), la del socket o la que te da un posible proxy http?
- Es mejor usar sesiones, que dejarle la información al usuario, por muy encriptada que esta esté. Eso si, desde el punto de vista de la seguridad, no del rendimiento.
- ...
Basicamente, solo llegamos a una regla: "Validar datos". Que sean correctos, confiables, sin desbordamientos de buffers, ... Pero solo eso, validar datos. El problema es saber validarlos, y hacerlo de una manera que requiera el minimo esfuerzo: "Si algo cuesta, ya se hara en una hipotetica segunda fase" (Traduccion: Nunca).
Una vez metido, recordad lo sucedido [laquadrature.net].