Antivirus automatic update, automatic disaster.

Uno de los errores mas comunes en la organización de la seguridad informática, es la de presuponer situaciones y características, con la consiguiente marcha hacia el desastre.
Es curioso, como cuando vas ha realizar una auditoria de seguridad a cualquier empresa de supuesto alto nivel (Mucha Pasting Bank, Ministerio de Desastres Varios, etc), y en el cual se cumplen muchos de los procedimientos de seguridad, encriptación de contraseñas y comunicaciones, control de acceso, gestión y monitorización de las comunicaciones a través de los múltiples firewal, DMZ, etc, nos encontramos de repente con un error básico, que es la confianza ciega en un producto.
Y ese producto, es ni más ni menos, que nuestros flamantes antivirus.
Cuando instalamos un antivirus en nuestra red corporativa, pensamos que con mantenerlo actualizado y monitorizado ya se terminaron nuestros problemas. Pero las ultimas experiencias de la industria y algún que otro susto, provocado por los chicos del Dep. de Desarrollo nos han devuelto a la cruda realidad, y esta no es otra, que si nuestro flamante antivirus mete la pata de manera intencionado o por error , la situación, es que estamos en un buen lió!.
Como es esto posible?
Pues muy sencillo, los antivirus se instalan con permisos de administración local, con lo cual tienen acceso a todos los ficheros del S.O. y pueden hacer con ellos lo que les plazca (como moverlos a cuarentena o borrarlos!) se supone que solo harán estas cosas con ficheros malos (infectados), pero en la realidad la cosa cambia.
Si una empresa de antivirus, en su ultima actualización, , publica por error una firma la cual se corresponda con alguna que otra función del sistema operativo, al actualizar automáticamente los clientes antivirus, esto ejecutaran la cuarentena a los ficheros sospechosos y se llevaran por delante la mayor parte de nuestros queridos clientes, estaciones de trabajo y servidores, tanto los de explotación como los de pruebas, base de datos etc. Así que, en el lapso de varios minutos, nuestra infraestructura quedara completamente liquidada como si hubiese sido atacada por el más eficaz de los virus (y estos errores ya han pasado y volverán a pasar!).
Esta situación es optimista (dentro del desastre, que es, todos los sistemas fritos y bien fritos, y a reinstalar todo) pero, ¿que pasaría si este error fuese planificado y utilizado en un ataque premeditado?.
La forma de actuación podría ser así de sencilla, se desarrolla un virus nuevo y a “medida” para la empresa objetivo, este al no estar catalogado se podría infiltran dentro del sistema sin problemas y reproducirse y asentarse, modificando los ficheros críticos que nos interesasen, claves de registro, etc. y una vez finalizado su “implantación” nuestro amigo se quedaría a la espera, sin hacer nada, ya que su función es no hacer nada.
Luego en el momento elegido se publicaría un virus señuelo para las empresas de antivirus, que contiene las claves o cadenas criticas que ya implanto nuestro anterior amigo. La empresa antivirus publica la nueva firma, la distribuye y los clientes infectados por la modificación, inserción de las anteriores cadenas son identificados automáticamente por el antivirus como peligrosos y son puestos en cuarentena tumbando automáticamente todo la infraestructura de la empresa en cuestión.
La simplicidad de este plan y su elegancia, radica en que dejamos que otros realicen todo el trabajo duro por nosotros. Ya que la mayoría de las grandes empresas no se molestan en tener servidores o entornos de validación y pruebas de actualizaciones y parches.
Así que tras realizar una auditoria y revisar que todo esta correcto y se cumplen las recomendaciones, no encontramos con que depositamos toda nuestra confianza y seguridad en una empresa tercera, en cuyo contrato de licencia nos indica claramente que no se responsabilizan de los daños que su producto pueda causar.

Auditorias IV. Los Logs, esos desconocidos!

Quizás a algunos les sorprenda, pero en una auditoria bien hecha, una de las cosas importantes es, como se gestionan los logs de actividad de los distintos sistemas, asi de como se utiliza la información que proporcionan a la monitorización y gestión de los procesos y como deben de auditarse estos.
Así que, aquí van unas cuestiones!

Esto es lo basico, basico que debe de cumplir una politica aceptable referente a los Logs.

1. Registrar todos los errores, fallos del los sistemas involucrados
(Esto de por sí es una cantidad de información ingente!)
2. Registrar los eventos de accesos exitosos.
3. Registrar los eventos de accesos fallidos.
4. Registrar los cambios de permisos, en cualquier objeto del sistema.
5. Registrar accesos fallidos a ficheros.
6. Registrar creación de usuarios, objetos.
7. Registrar borrado y modificación de ficheros del sistema operativo.
8. Registrar modificaciones en las políticas de generación de los propios logs

Toda esta información deberá de estar disponible para su análisis en caso de ser necesaria, tanto para análisis forense, para auditorias de seguridad, asi como para estudio de optimización de los procesos de explotación de IT.
También, todos estos logs deberán estar incluidos en los planes de backupss!
Así que si se gestionan de una manera eficaz, los log resultan ser una parte imprescindible en la explotación de nuestras IT.

Auditorias III, Políticas de Backuuups ¡

Y con más de lo mismo Auditoria, Auditoria. Quien no se ha preguntado qué políticas y procedimientos debe de aplicar a la gestión de sus backuups! (vale! Aparte de hacer las copias diarias, mensuales y anuales, en diferencial, diferencial incremental y total). Pues estas son las preguntas que ese auditor tan simpático que tienes en tu CPD desde hace una semana, te va ha hacer y puntuar por tus respuestas. Como en el cole!


1. Planificación de horarios de copias, más conocidos como ventanas de copia.
Un documento en el cual se indican las horas o rangos de copia asignadas a las distintas aplicaciones, BBDD, ficheros y todo lo que se te ocurra copiar.

2. Ubicación y plan de almacenamiento de los soporte físicos y sus políticas de acceso y gestión.
Esto es, cumplimiento de la OLPD, procedimientos de almacenaje, seguridad del mismo, procedimientos de destrucción de soportes defectuosos, inventariado de los soportes y gestión de los mismos, etc.

3. Plan de personal.
Descripción del personal y depto. Involucrados en la gestión de las actividades de Backuuups, así como la descripción de roles y responsabilidades asignadas a cada uno.

4. Presentación del plan y políticas de actuación anuales.
Procedimientos anuales referidos a la gestión y realización de las políticas de backups aplicables durante el periodo anual.

5. Plan de formación de personal anual.
Planes de formación del personal en las aéreas de actuación o influencia relacionadas con la realización de las actividades de Backuups.

6. Políticas de la gestión de la información.
Desarrollo de una política centralizada de gestión de información, esto es, asegurarse que en las distintas políticas y soportes exista una integridad en la información almacenada, no se debe permitir que en un mismo soporte o política coexistan datos de distintas categorías o familias. (Ejemplo, no copiar en un mismo soporte, bases de datos y ficheros de actividades departamentales).

y eso es todo, aunque no poco, ya que la realizacion de la documentacion relativa a las ventanas de copia y sus procedimientos, son una buena cantidad de papel.

Auditorias II, Como pedir las cosas o formularios de acceso al sistema IT

Estos son 16 campos básicos que debería de tener cualquier petición de acceso a los recursos de nuestra IT.

1. Tipo de petición. (alta, modificación, cancelación).

2. Nombre del sistema, recurso.
Cuál es la denominacion o nomenclatura que voy a utilizar.

3. Localización del sistema, recurso.
Donde se encuentra lo que se va utilizar, web, red, aplicación, etc.

4. Fecha y hora de la petición.
Pues eso la, la fecha y la hora de la petición.

5. Identificacion del empleado.
Un identificador único de empleado en la empresa.

6. Organización a la que pertenece.
A que depto. Pertenece el empleado.

7. Número de teléfono.
Nº de teléfono, extensión.

8. Dirección de correo electrónico.
Dirección del correo electrónico del empleado en la empresa u organización.

9. Cargo en la organización.
Tipo de responsabilidad que ocupa el empleado.

10. Ubicación física (más conocida como dirección).
O donde se encuentra, el puesto físico del empleado.

11. Justificación, explicación del requerimiento de acceso.
Un pequeño informe de porque se solicita este acceso y para que se va utilizar.

12. Tipo de acceso al recurso (total, parcial, temporal).
Si es una aplicación tipo de usuario que requiere, acceso a recursos de red tipo de permisos, etc.

13. Aceptación de usuario.
Referido a que el usuario conoce y acepta, el acceso al recurso solicitado.

14. Autorización de un superior (que cargo autoriza este acceso).
La solicitud de acceso al recurso por parte, del responsable correspondiente.

15. Autorización del responsable de seguridad.
Autorización o validación del acceso por parte del Dept de seguridad.

16. Verificación del “Need to Know”, o "como saber utilizar lo que se ha solicitado".
Se verifica que el usuario conoce como utilizar este recurso.

Y esto es todo. Solo lo básico, al desarrollar estos conceptos suelen quedar unos preciosos formularios y los procedimientos de gestión administrativa correspondientes.

VMWORD 2007, ya esta aquí! (mas o menos)

El congreso de virtualizacion de nuestros amigos virtuales de VMware ya está aquí.

Los temas de las jornadas son variados y muy interesantes, así que ya sabéis si os encontráis cerca y os interesa el tema, podéis pasaros por El “Moscone Convention Center, San Francisco California”. Y Se encuentra patrocinado por las más grandes de las grandes (excepto Micro, ellos tienen a R5), HP, EMC, Nec, APP, AMD, etc.

Y te puedes registrar aquí.

El contenido de las jornadas!

Infrastructure Planning Topics
Optimizing Infrastructure with Assessment & Deployment Best Practices

I n frastructure Operations
Optimizing Infrastructure with Management & Operations Best Practices

Workloads & Virtual Appliances
Optimizing Infrastructure with Workload Best Practices and Virtual Appliances

Business Continuity & Disaster Recovery
Enhancing Business Continuity & Disaster Recovery through Virtualization

Software Lifecycle Automation
Developing, Testing and Deploying Systems through Virtualization

Desktop Virtualization
Delivering Manageable & Secure Desktops through Virtualization

Technology & Architecture
Exploring Virtual Infrastructure Technology & Architecture in Depth

B Business Metrics & Results
Understanding, Measuring & Communicating the Business Value of Virtualization

Lo dicho, si tienes tiempo, dinero y un vuelo transoceanico a california, no dejes de pasarte!

Auditorias IT, 19 Documentos que no vas a tener!

Esta es un aproximación a la documentación que te pedirá ese sonriente Consultor-Audior Tecnico-Less salido del infierno ,y que tu no, tienes ni repajolera idea de donde está!

1-Un manifiesto sobre los propósitos de explotación de tu IT

(Ósea esto para que a servir y que se supone que va hacer)

2-Estructuras organizativa de tu organización

(Redundante, pero que hace la señora de la limpieza aqui)

3-Documentación sobre la seguridad física

(La relativa al Centro de Proceso de Datos, ubicación de foso de cocodrilos, campos de minas y maldiciones arameas varias)

4-Procedimientos de finalización, cancelación de trabajos, proyectos y protocolos de gestión y anulado de cuentas.

(Cuando un amigo se va, algo se muere en el alma! Vale! pero tenemos que desactivar su login y su cuenta de correo)

5-Clasificación y tipos de datos con los que operas.

(Que tipos de BBDD, docs, etc, tienes, y la categoría de la información que contienen, algo sobre una tal OLPD)

6-Gestión del control de acceso.

(Que horas son estas de llegar!)

7-Gestión de los S.O.

(Un Gindows Que? Linuss que?)

8-Gestión de Hardware

(Y eso grande y negró que es?)

9-Funciones del Uso de Internet.

(mejor no comentar, se aceptan sugerencias)

10-Políticas de utilización del Correo de la empresa y sus cuentas asociadas.

(Ni un ppt mas!)

11-Documentación referente al todo tipo de soporte técnico utilizado por el Dept.

(Telepizza dígame?)

12-Planes y políticas de gestión y seguridad referente a virus, firewalls,VPNs, accesos remotos, etc.

(No! no te puedes conectar desde casa, al cluster)

13-Políticas de Backups

(Has copiado eso?)

14-Políticas de recuperación ante desastres

(La cagamos!)

15-Planes de contingencia ante detección y medidas a tomar en coso de intrusiones no autorizas en el sistema.

(Mierda un Bicho! Mariano trae el bazooka)

16-Listado del personal de seguridad asignado al sistema y sus funciones.

(Y tu! a que dices que te dedicas?)

17-Gestión de la explotación de aplicaciones mantenimiento de las mismas y objetivos.

(Niño, actualízame el Word!)

18-Control Del “OutSourcing” of course!

(Para quien dices que trabajas? y que dices que haces!)

19-Gestión del soporte a los usuarios.

(Socorro, mi Windows dice que se va a apagar, en Linux ni siquiera sé cómo se apaga)

COMPARATIVAS APACHE, IIS EN EL 2007. ¡UNOS SUBEN Y OTROS BAJAN!

Como hoy es viernes; unos datos de la agencia de Netfcraft los cuales son un referente en cuanto a los tipos de servidores instalados en internet.

Ósea que cuantos Apaches e IIS andan pinchados a la red.

Así que un grafico de muchos colores y en el que se ven las tendencias de la industria

Azul Apache

Rojo Microsoft

Supongo que estos datos en kriptopolis.org serán interpretados de otra manera. Pero, al menos en este blog, no se filtran ni se censuran los comentarios.

“/* Nos gustaría cambiar el mundo, pero no tenemos el código fuente */” y luego hacerlo propietario.

Saludos!