Separation of duties: una ilusión en TI?

El concepto de separación de responsabilidades/asignaciones en una idea que revolotea casi de cajón en libros de texto de SegInfo, en textos de las llamadas "buenas prácticas" y hasta en conferencias. Pero si vamos un poco más allá del texto, realmente cómo podemos contar con una "separation of duties" en TI?

La separación de tareas significa evitar que una sola persona tenga control de una transacción de inicio a fin; significa también que más de una persona es requerida para completar una tarea. En TI, exactamente cómo funciona? ¿Funciona?

Por ejemplo, tenemos al administrador del directorio activo (DA), una persona muy poderosa en la infraestructura de TI tomando en cuenta que todos los equipos estuvieran conectados a este DA. Si esta persona crea una cuenta de usuario en una PC VIP para tener acceso no autorizado, dónde entra la separación de actividades? ¿Cómo le hacemos para que no la pueda crear sin la intervención de otra persona? Si bien podemos tener dos administradores de este DA, si la propia herramienta no te da la posibilidad de una "separation of duties", tendremos a un administrador que podrá hacer y deshacer a su antojo cuentas y contraseñas; podrá tener accesos por aquí y por allá. Se tendría que tener una bitácora para en dado caso revisar estas actividades en el DA, pero eso no es una separación de actividades.

Vayamos a una consola de antivirus donde se administran los mata-bichos perimetrales y/o locales en cada equipo. ¿Cómo podemos implementar el concepto de "que un cheque tenga dos firmas para que sea válido"? Si la herramienta permite al administrador (y de hecho lo hace) tener un control total, pues puede completar cualquier tarea sin necesidad de que alguien más lo valide.

Me podrán decir que la segregación de tareas es un control administrativo, en papel: un administrador lista cambios y otro más agrega su firma para dar su VoBo. Pues es totalmente irreal porque simplemente el cambio ilícito que se desea hacer no se escribe en esta hoja y listo. También me podrían decir que la segregación se puede hacer mediante bitácoras del sistema, sin embargo hacerlo de esta manera no es segregar y además el administrador podría alterarlas.

Lo que finalmente quiero expresar es que la segregación/separación de tareas  en muchas situaciones de TI es una mera ilusión ya que no se puede llevar a cabo porque la propia herramienta no lo permite. En el ejemplo del cheque con dos firmas, el que va a canjear dicho cheque verifica que las dos personas hayan firmado. El problema es que la mayoría de las herramientas me permiten como administrador hacer toda una actividad de principio a fin sin necesidad de intermediarios o verificadores, porque para eso se es administrador del sistema, de un directorio activo o de una consola de antivirus.

En ambientes de desarrollo de software se puede llevar a cabo esta segregación por ejemplo entre los que diseñan, los que codifican y los que dan mantenimiento al software en producción. Pero esta segregación se logra porque estos ambientes son sufrientemente diferentes para tener una separación de tareas; son actividades/procesos independientes. A diferencia de un administrador de ruteadores, donde es un solo proceso y el administrador puede enrutar a voluntad y depende de él avisar/informar de los cambios y pedir autorización.

En conclusión, la separación o segregación de actividades es una buena idea y que muchos libros escupen, pero en la vida real de TI no siempre se puede llevar a cabo en cualquier situación. Los roles de muchas herramientas no están pensados para tener "verificadores" o "autorizadores" que sean necesarios para completar una actividad dada. La segregación se tiene que hacer en procesos y las herramientas tener la funcionalidad de segregación.

¡Cuidado, ahí viene el lobo!

Un pastor que vivía en un lejano pueblo (pero con conexión a Internet porque era un pueblo moderno, claro) se relajaba después de una larga jornada visitando sitios con su navegador a quien de cariño le llamaba "Juanito". Este mentado "Juanito" le avisaba al pastor de sitios "peligrosos" por tener certificados digitales inválidos. Tanto advertía "Juanito", que el pastor simplemente acabó ignorándolo. ¿Les suena conocida la historia?

En un estudio de la Universidad Carnegie Mellon, la historia se torna en análisis, ya que decidieron hacer un ensayo y ver qué tanto hacían caso los usuarios a las advertencias arrojadas por el navegador cuando se accedía a un sitio con problemas en sus certificados digitales. ¿Y cuál fue la conclusión?

El resultado fue de cierta forma predecible: los usuarios ignoran estas advertencias ya que de hecho, la gran mayoría avisa de cuestiones benignas como certificados fuera de la fecha de validez (al administrador se le olvidó renovar), o sitios legítimos que tenían certificados auto-firmados; todo esto claro, "revuelto" con algunos sitios ciertamente maliciosos.

Arrojar "n" avisos al pastor deriva en ignorar a "Juanito", y simplemente el pastor acaba por decir "ok, deseo entrar a este sitio potencialmente peligroso porque creo que es poco riesgoso; de todas maneras no entiendo bien los mensajes de este Juanito". ¿No sería mejor avisar realmente de situaciones riesgosas? ¿Mejor aún, valdría le pena simplemente no dejar que el usuario entre al sitio y no dejarle opción? ¿Sería mejor simplemente eliminar las advertencias benignas que sólo estorban?

Esto me da pie para aprovechar el tema y poner sobre la mesa otra cuestión al reflexionar sobre las advertencias que recibe un usuario en una organización, ya que podría ser que el área de seguridad esté jugando a ser Juanito y advierta una y otra vez sobre todo tipo de riesgos menores, riesgos inexistentes y peligros verdaderos. Los usuarios no sabrán distinguir al lobo entre las ovejas (y por cierto, su trabajo no es saber distinguirlo).

En el caso por ejemplo de un antivirus, vale la pena advertir al usuario que no tendrá acceso a "x" y "y" archivos porque están infectados? ¿O simplemente es mejor bloquear el acceso a esos archivos sin avisar? Después de revisar los discos duros de una computadora, le debemos de advertir al usuario que tiene "x" cantidad de malware y que decida si desea tratar de restaurarlos, eliminarlos o ignorarlos?

Al usuario (de un equipo, de un navegador o de un antivirus) no hay que bombardearlo con avisos innecesarios y sólo avisar de peligros comprobados, verdaderos y de los que realmente valga la pena que esté enterado. En las otras ocasiones, la aplicación tiene que decidir por él, seleccionando las acciones que lo protejan.

En una organización, los controles de seguridad deben de decidir por el usuario en base a configuraciones pre-establecidas, no hay opciones y hay pocas advertencias, pocos "pop-ups" del navegador, del antivirus, del firewall personal o del filtrado de contenido a sitios web. Estamos hablando de una dictadura.

Nota final: el estudio de la Universidad Carnegie Mellon está interesante, lectura recomendable ciertamente, con bastantes datos de su análisis.

2010 budgets to fund app security and DLP, study shows

Interesante noticia de SCMagazine.

¿Quiere decir que es una tendencia? ¿Es lo que debemos comprar en 2010?

¿Quien tiene ya “algo” para darle seguridad al código? ¿Y un DLP?

 

Looking to the rest of 2009 and the first half of 2010, the respondents -- from Fortune 100 and midsized companies in North America and Europe -- said application security technologies are likely to receive increased budget dollars.

 

“Organizations are now realizing applications are the weakest link in the chain, so to speak,”

The TheInfoPro study also showed that respondents plan to earmark additional money to data leakage prevention solutions that contain encryption capabilities.

 

http://www.scmagazineus.com/2010-budgets-to-fund-app-security-and-DLP-study-shows/article/141179/

 

Twitter abajo

Pues son las 22:40 y Twitter sigue abajo parcialmente o de plano es mi navegador que algo le pasa. Pero se me hace raro que la página sí responda y se actualice pero no puedo mandar ninguna entrada. Además a quienes sigo, su última actualización fue hace una hora y ya no hay nada más...sospechoso.

Por ahí leí que este ataque de DoS había sido alguna especie de venganza contra un blogger que tiene cuentas en FaceBook y Twitter enytre otros, pero lo cierto es que creo que todavía no hay información al respecto. Yo que pensaba que estos DoS habían pasado a la historia pero sigen más vigentes que nunca los condenados.

Bueno, les comparto una cita que iba a poner en Twitter pero que no pude poner:

"According to a tale, the allies further disabled Iraqi military computer systems with a computer virus, shipped to Iraq in printers [...] The virus was said to have been developed by the NSA and installed by the CIA.".- Denning

Por cierto, una de las referencias del DoS en Twitter:
CiscoSecurityWas a Psychopath attacking twitter? http://is.gd/25DUs

Veinte Controles Críticos

De nueva cuenta el SANS publica información que jala mi atención. Esta vez han listado los 20 controles críticos que pueden llevar a una “seguridad efectiva”. Podemos quitar y/o incluir controles en esta lista, pero bien vale la pena darle un vistazo ya que a mi parecer suenan razonables. A continuación dicha lista y algunos comentarios de mi propia cosecha.

 

1.- Inventario de dispositivos autorizados y no autorizados: si no tenemos una lista de nuestras pertenencias, cómo sabremos entonces protegerlas adecuadamente? Y si sabemos lo que tenemos, también podemos hacer una lista de lo que no deseamos tener en nuestro entorno (ejemplos: iPhone –robo de datos-, USB –malwre-, etc.).

2.- Inventario de software autorizado y no autorizado: básicamente lo que se haría con un firewall personal (corporativo).

3.- Configuraciones seguras para el hardware y software de laptops, máquinas de escritorio y servidores: más sencillo de decir que hacer, pero una configuración segura es una buena medida preventiva.

4.- Configuraciones seguras de dispositivos de red (ruteadores, firewalls): un poco repetitivo del punto anterior, pero bueno, la idea es la misma.

5.- Defensa perimetral: los dos puntos anteriores se enfocan en la prevención y en el interior del huevo; aquí hay que encargarse del cascarón.

6.- Mantenimiento y análisis de los logs de auditoría de seguridad: de qué sirve que se estén llenando las bitácoras de los diferentes dispositivos si nadie los revisa y atiende?

7.- Seguridad en aplicaciones: otro control preventivo; se trata de escribir código tomando en cuenta la seguridad y no sólo la funcionalidad de las aplicaciones.

8.- Uso controlado de los privilegios de administrador: si cualquier “hijo de vecino” es administrador, estaremos bajo su control. Las TI son una dictadura, y no todo mundo debe de ser rey de su (o sus) equipos/servidores.

9.- Acceso controlado basado en quien realmente lo requiere para su trabajo (need to know): si no tengo por qué entrar a un servidor o no tengo que saber los pormenores de esa base datos, por qué se me deberían de otorgar esos permisos?

10.- Análisis y remediación continuo de vulnerabilidades: pues creo que está demasiado claro; sin comentarios.

11.- Monitoreo y control de cuentas: seguramente el SANS se refiere a tener un control de la cuentas de los usuarios, sobre todo para los que se cambian de adscripción o que se van de la empresa, resulta importante modificar o eliminar permisos ante el movimiento de los recursos humanos.

12.-Defensas contra el código malicioso: antivirus local (y perimetral) y en servidores; control de acceso a páginas web; ambos pueden ser controles (entre muchos) eficientes.

13.- Limitación y control de puertos de red, protocolos y servicios: ¿Realmente es necesario permitir comunicación en todos esos puertos? ¿Se siguen permitiendo protocolos inseguros como telnet? ¿Resulta imprescindible que se tengan habilitados todos esos servicios o se pueden apagar varios sin dañar la operación?

14.- Control de dispositivos inalámbricos: el dolor de cabeza de muchas empresas podría ser el riesgo que representan las redes inalámbricas que carecen del cobijo físico de las alámbricas.

15.- Prevención de pérdida de datos: ¿y si el día de mañana se le ocurre a un usuario publicar o enviar datos confidenciales? ¿Y si un intruso entra al edificio y saca documentación sin autorización?

16.- Ingeniería de seguridad para redes: seguramente a lo que se refiere el SANS es a diseñar las redes con seguridad en mente y mantener una arquitectura no sólo operacional sino segura. Meterle materia gris al asunto, pues.

17.- Pruebas de penetración: nada como probar la llanta sobre el asfalto para ver si estamos tan bien protegidos como pensamos.

18.- Capacidad de respuesta a incidentes: si ya pasó lo peor, podemos responder rápida y eficientemente para mitigar los efectos adversos de una situación?

19.- Capacidad de recuperación de datos: ligado al punto anterior, si ya pasó algo malo, es posible recuperar los datos perdidos o afectados?

20.- Capacitación en seguridad: ¿los encargados de seguridad se mantienen al día? ¿Reciben capacitación adecuada y mantienen sus habilidades técnicas? ¿Y el resto de la organización tiene las reglas básicas para mantener un entorno seguro?

En fin, basta que le den un vistazo a la página del SANS para completar la información o por si mi traducción les pareció, ejem, defectuosa. Lo importante es que cada uno viera esta lista y se preguntara qué tantos de estos controles se aplican en la realidad en la empresa (no es una auditoría, podemos decir la verdad!). Si no aplicamos algunos, hay alguna justificación? En fin, ahora que es época de vacaciones se pueden llevar la lista para meditarlo en la playa.