Aparte de tonto, !Juanker!

El otro día, con los compis de trabajo mientras nos relajábamos en la cafetería, y hablábamos de lo de siempre, ordenadores, bichines viruses malos y timbas al DoD y al EvE online (no nada de warcraft!).
Pillamos la conversación de dos de los genios con corbata y bastón de mando que suelen pulular por las empresas. Si! esos que cuestan una pasta en nominas y en decisiones (cada decisión que toman si que cuesta un buen pico, por la metedura de pata que suele ser ). Pues una de las corbatas le comentaba a otra que había “descubierto” un bug en la instalación de Windows. Humm! Un bug! Estos tios son capaces de instalarse un XPs ellos solitos! Así que nos callamos todos y pusimos la parabólica. Haber si aprendíamos algo interesante!
Así que repitiendo, corbata 1 le decía a corbata 2 , “que he pillado un bug de instalación” y corbata 2 le respondía “jo macho, como mola, y como es? Por que podrías repórtalo” .
Corbata 1 “si pero, no!, por que lo leí el otro día en una pagina de hackers, creo que se llamaba algo como hackers09 o hacks09. Esta muy bien, esos tíos hacen de todo.”
Bueno! Vale! Se descubrió el pastel, lo busco en Google, lo copio de una web de hakers malos y lo pruebo en casita o con el portátil de la empresa.
De esta conversacion deducimos dos cosas! Deberían prohibir Google, es tan eficaz y sencillo que cualquier tonto encuentra lo que quiere aunque no lo busque.
Y la segunda, que cualquier tonto con Google y en una empresa lo suficientemente grande se puede tirar el pegote de que guai y malo malote soy con un guia burros y el copia y pega del IE7.
Como dice nuestro querido mentor en seguridad “no es lo bueno que tu seas, es lo inútiles que sean los demás” y siendo mas finos! Y en un leguaje para corbatas “lo difícil es hacer las cosas bien en tu trabajo, a la primera!”
Lo mas positivo de este tema, es que no me va a faltar trabajo a corto plazo.

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!

Aproximacion al Desarrollo de un Plan de Explotación.

Hoy hablaremos de dos aproximaciones hacia la creación y desarrollo de un plan de explotación de infraestructuras.

Aunque este tema es para llenar un montón de post, lo trataremos a un nivel muy básico, presentando dos aproximaciones sencillas en sus planteamientos. Una primera aproximación hacia una gestión global de los sistemas u otra aproximación mas modular que se refería a la los enumeración de servicios a explotar así como su organización.

Con Cualquiera de estos dos planteamientos, aunque parten de premisas sencillas, al aplicar su desarrollo, se alcanzan niveles bastantes complejos en lo referente a la gestión y actualización documental.

La primera aproximación a un plan de explotación, partiría de la generación de planes de actuación globales, agrupando las principales aéreas de actuación en modelos globales. Esto es simplificando, que crearemos unos planes generales para las diversas areas, ejemplo el plan de seguridad de red, el cual incluiría la configuración de la misma, asegurado de estaciones de trabajo, copias de seguridad, y todo los que se nos ocurra que esté relacionado con la seguridad, luego se pasaría a las demás zonas de actuación, gestión de equipos, explotación de aplicaciones, etc. Lo bonito de esta organización es que con dos o tres planes generales, somos capaces de cubrir todos los aspectos de la gestión, pero el problema de un planteamiento de un plan de batalla tan general, consiste en la necesidad de delegar la generación de una gran cantidad de información y capacidad de decisión a los departamentos involucrados en la gestión de estas aéreas, depto. De soporte, para el asegurado de las estaciones, depto. de comunicaciones para todo tema de red, seguridad lógica para la gestión de políticas de cuentas y permisos de red, y un largo Etc.

Así este modelo es solo aplicable a grandes modelos de explotación con una elevada capacidad de comunicación, coordinación y trabajo en grupo (Justo lo que suele faltar en las empresas).

El segundo modelo de actuación, partiría de una aproximación modular a la gestión de la infraestructura, este es, enumerar individualmente los elementos que la componen y proceder a su gestión de una forma más personalizada. Asi se procede a agrupar las distintas arquitecturas y a elaborar los planes específicos para ellas, eso es se trata la seguridad global de la red, por ejemplo de una manera más modular, así la red está compuesta por swichs, routers y firewall, a los cuales se les aplican políticas de explotación personalizadas, aplicables a elementos de su misma familia. Luego pasaríamos a la configuración de las estaciones, estas se realizarían a través de administración de los S.O. y configuración de aplicaciones, correos, antivirus.

Esta solución aporta que el Depto. involucrado directamente en la explotación y utilización de los mismos y a los cuales se sienten afines y disponen de gran experiencia en su gestión, son responsables de los mismos. Reduciéndose claramente la necesidad de una gran unidad de gestión y coordinación en la empresa, así como la eliminación de incompatibilidades y roces entre depto. por la gestión de uno u otro recurso.

Y eso es todo.

y como queda claro es una aproximacion muy ligera a la gestion de infraestructuas IT

Cuál es el TIER de disponibilidad de tu CPD?

Interesante guía de SITE INFRAESTRUCTURE sobre las clasificaciones y parametrización para averiguar cuál es tu nivel de disponibilidad, de tu Centro de Proceso de Datos.

En ella se describen las características que deben de estar asociadas a los distintos niveles de disponibilidad, así como las capacidades de supervivencia que debes de poseer (más o menos, mientras no pierdas tus unidades de alimentación UPS).

El articulo trata mas profundamente las necesidades de energía que necesitas, que la redundacia de sistemas que puedas poseer. Pero! si no tienes electricidad, no existe cluster, ni storage array que funcione.

Site Infraestructure

Y tú! en que TIER estas?

¿Auditoria de Parches? Una necesidad!

Hoy, una cuestión curiosa sobre un tema que utilizamos todos y que nunca hemos pensado cuáles son sus implicaciones totales (por lo menos ,yo!) y cual es la forma correcta de auditar la gestión de los parches o “pacthes”.

En este articulo de Colin Buecher comenta que con una correcta gestión de los bugs del software y la aplicación de sus correspondientes soluciones, se podría eliminar el 95% de los problemas de seguridad relacionados con las “debilidades” del software. Eso es lo que opinan los chicos del CERT.

Bueno! nunca habría llegado a esa conclusión, si no me lo dicen :).

Así que un servidor o una aplicación parcheada correctamente, es una aplicación feliz y resistente a los bichines de internete!

Siendo mas serios podemos leer esta pequeña aproximación en:

CBuecher

Pd.

Otra cosa es que los administradores dispongamos de tiempo, entornos y documentación apropiada para auditar estos sucesos como quisiésemos.

Aun asi, siempre nos quedaran nuestros queridos Backuuups! Eso me recuerda que tengo que mirar si Veritas ha sido buena esta noche.

Cositas que hacer en verano

Y siguiendo con el verano y las cositas de mantenimiento que se suelen abordar en estas fechas. Tales como, limpiar los bichos de los servidores (los virtuales y los biológicos) revisión de backups (tirar esa mierda de cinta que da errores), liquidar esas conexiones pilladas desde enero (plasta de usuario), etc. Pues para ayudar en todo eso, unos links.

Primero unos cuantos security Cheklist de la IASE (el tio SAM recomienda), para ver todo lo que no cumplimos en nuestro flamante centro de proceso de datos.

Checklist

Continuamos con una apasiónate lectura de SANS, sobre qué es lo que no hago y debería de hacer, cuando han pulsado el botón del pánico.

An Incident Handling Process for Small and Medium Businesses

y finalizaremos con un poco de cañita a los linuxeros, con los post de Jeff Jones (CSO) sobre que de fallos tiene mi Windows, si lo comparamos con mi Linux (eso sí! la versión de pago. Las gratuitas no tienen fallos!)

CSO

Y el que quiera opinar que opine!