Mostrando entradas con la etiqueta CERT. Mostrar todas las entradas
Mostrando entradas con la etiqueta CERT. Mostrar todas las entradas

miércoles, 26 de noviembre de 2008

MISSP en PYMES


¿Qué es un MISSP y por qué puede ser útil? Un Managed Internet Security Service Provider es un proveedor de servicios de internet (ISP), que complementa su oferta al cliente con servicios de seguridad gestionada, como firewalls en red, vpn, detección de spam, o detección de intrusiones.

La idea básica es proteger el acceso a Internet, tanto en tráfico entrante como saliente, desde la propia red del operador en vez de en las instalaciones del cliente. Típicamente será un servicio operado desde un Security Operation Center propiedad del ISP, que deberá contar con soluciones tecnológicas adecuadas y personal especializado.

No es un concepto nuevo, ni mucho menos. Pero tampoco lo conoce todo el mundo ;) . En el FAQ de Sans nos hacen una descripción de qué son, y comentan algunos factores a tener en cuenta antes de decidir si contratar, o no, servicios de estas características. Básicamente:
  • si se dispone de la capacidad de generar firmas propias para los sistemas de detección de intrusiones, o si por el contrario, se depende del fabricante del IDS
  • ¿se dispone de una variedad de soluciones, que permitan operar sobre entornos tecnológicos variados, o se utiliza una solución global para todo?
  • ¿qué medidas de seguridad física se emplean en el SOC?
  • ¿qué medidas se han aplicado con respecto a la tolerancia a fallos? ¿Cuál es el proceso de notificación de fallos? ¿Se revisa periódicamente el funcionamiento de los equipos? ¿Existe un sistema de centralización de logs, que permita revisar los mismos en caso de que un equipo se vea comprometido?
  • ¿se confía el servicio a personal propio o subcontratado? ¿Se investiga a las personas que componen el equipo, antes de contratarlas? ¿Se realizan acuerdos de confidencialidad en todos los casos?
  • ¿qué importancia da el proveedor a las certificaciones en seguridad? ¿El equipo que se ocupa del servicio recibe formación contínua, que le permita seguir al día?
A mí personalmente me parece interesante saber cómo el servicio se va a adaptar a las propias necesidades de mi organización, por ejemplo, si me va a proporcionar algún tipo de consola en la que se pueda parametrizar determinados aspectos del servicio, y si se pueden definir políticas y utilizar el servicio proporcionado para vigilar su cumplimiento de forma externa a la organización. También es interesante saber si el servicio proporciona informes en un formato personalizado o por el contrario es genérico, cuál es el detalle de las explicaciones que se proporcionan, si se incluyen servicios de consultoría que ayuden a comprender bien las características del problema que se haya reportado, la probabilidad de que ocurra y el impacto que podría tener, o si mantienen contacto con equipos CERT oficiales.

Otras cuestiones interesantes no tienen que ver tanto con el propio servicio en sí, como con la manera en que el cliente utilizará este servicio. Es el propio usuario el que tiene un conocimiento exhaustivo de su propia organización, y podrá distinguir amenazas reales de las que no lo son. Su gestión de riesgos es el motor del resto de las tareas a realizar en materia de seguridad, no se debe olvidar esto nunca. Una pequeña o mediana empresa podría pensar que contratando un servicio de seguridad gestionado como este resuelve todas sus necesidades de seguridad. Sin embargo, lo que hace es externalizar los medios técnicos necesarios, pero sigue teniendo necesidades organizativas a las que prestar atención.

Así será necesario que se defina un plan de acción en caso de que se detecte un riesgo real, y esto es algo que sólo el personal interno de una organización puede realizar. Sólo los usuarios pueden priorizar adecuadamente sus riesgos, decidir cuál el plazo fijado para la resolución del problema detectado, o establecer cuáles son las medidas de mitigación y supervisión adecuadas a su entorno y a los medios de que dispongan. Y son ellos los que deben definir sus propios planes de contingencia y de continuidad de negocio. Por eso, por ejemplo, en Inteco existe un plan de impulso a la certificación e implantación de un SGSI en la PYME (hay que decir que una empresa que decida implantarlo, obtiene una subvención del Plan Avanza que cubre un elevado tanto por ciento de los costes de implantación).

Slds!

Si te gustó esta entrada, quizás quieras suscribirte al blog por email o por RSS...

viernes, 25 de abril de 2008

Open Source CERT


De la mano de Google, ha arrancado un nuevo proyecto de CERT, esta vez destinado a proyectos de libre distribución, denominado oCERT (Open source Computer Emergency Response Team).

El equipo que lo compone es ciertamente de excepción, la verdad, por lo que estoy seguro que su trabajo será superbueno. Sin embargo, no puedo evitar una pequeña crítica, y es que entre otros servicios, dispondrán de su propia base de datos de vulnerabilidades, de acceso libre. ¿Por qué no colaborar con otras como OSVDB, y generar una única VDB, que tenga además todos los servicios de un CERT?.

Es mi impresión, vamos: mucho mejor colaborar y ampliar proyectos existentes, que generar de cero completamente proyectos nuevos.

Slds!

Lo leo a través del blog de Sergio Hernando, que amplia más información.

viernes, 21 de marzo de 2008

VI Foro de Seguridad RedIris



Los días 27 y 28 de Marzo, en Barcelona, el IRIS-CERT organiza un ciclo de conferencias, el VI Foro de Seguridad RedIris. Este año está centrado en la seguridad de aplicaciones web, dado que este tipo de problemas son ahora mismo los más explotados (lo dicen ellos mismos, en su informe anual).

Me hago eco de estas conferencias porque hay dos que me parecen particularmente interesantes: las que hablan de seguridad en web services (en particular, del estándar WS-Security y relacionados), y de recolección de evidencias de intrusión en aplicaciones de web.

De las dos conferencias, se dice lo siguiente en el programa:

Restricción y evidencia en infraestructuras 2.0

La definición e implantación de políticas, guías y procedimientos de codificación no supone la eliminación total de los nuevos riesgos de seguridad en el desarrollo de aplicaciones web 2.0.

Así en el proceso de gestión de estos riesgos es importante considerar las posibilidades de detección y prevención proporcionadas por la infraestructura de sistemas de información en la que se procede al despliegue de los desarrollos web 2.0. Estos elementos de infraestructura constituyen tanto posibles puntos de control, como de recolección de actividad.

Ponentes: Miguel Suárez Albares y Alfredo Reino, Symantec Iberia

Protegiendo nuestros servicios web

Web Services Security (WS-SEC) nos proporciona un entorno de seguridad sobre mensajes SOAP permitiendo integridad, confidencialidad y autenticación de mensaje, en los cuales podemos utilizar diferentes modelos de seguridad y técnicas de cifrado. Esta especificación nos define un sistema general extensible para relacionar tokens de seguridad con mensajes SOAP. A través de los diferentes perfiles propuestos en WS-SEC, podemos utilizar tokens binarios (binary security token), aserciones SAML (SAML assertion) y tickets de kerberos, entre otros.
En esta ponencia se mostrará una visión completa del estándar Web Services Security deteniéndose en los perfiles más significativos.


Ponente: Cándido Rodríguez, RedIRIS

Actualización: transparencias

domingo, 16 de marzo de 2008

CERTs, CSIRTs, etc


Al ver los videos del post anterior, pensé en buscar un poco más de información sobre CERTs. He usado muchas veces este término, he tenido noticia de algunos de ellos, pero nunca me había puesto a hurgar para buscar información en profundidad. Este post es una introducción, a modo de artículo, a lo que hacen, cuáles son conocidos, qué organizaciones hay a nivel europeo y mundial, etc.

De qué hablamos

Hoy día se utilizan los términos CERT (Computer Emergency Response Team) y CSIRT (Computer Security and Incident Response Team) de forma indiferente, para denominar a aquellos grupos dedicados a estudiar problemas de seguridad (vulnerabilidades) en Internet, proporcionar servicios a entidades que han sido atacadas, así como divulgar avisos de seguridad. Además, proporcionan información que contribuye a mejorar la seguridad de los equipos y redes de las comunidades a las que prestan servicio.

Los servicios concretos que da un CERT, cómo contactar con él, de quién depende, a qué comunidad se dirigen sus servicios etc, está definido en una "carta de constitución", que tiene cada uno. El RFC 2350 es un modelo a seguir para una organización que constituye un CERT. Se puede ver un ejemplo aquí.

CERTs en España

Existen ya varios de estos centros de este tipo en España, tanto públicos como privados. Entre los públicos, destacan los universitarios IRIS-CERT y esCERT. También dos creados en el año 2007, que son el CCN-CERT del Centro Criptológico Nacional, con el fin de dar servicios a las Administraciones Públicas, y el creado por INTECO (Instituto Nacional de Tecnologías de la Comunicación), dirigido a particulares así como a pequeñas y medianas empresas. También existen centros a nivel autonómico.

Los privados corresponden a empresas del sector de la seguridad informática, o a entidades privadas grandes, como es ejemplo el Cert de La Caixa (e-LC CSIRT). Este cert cubre aquellos problemas que podrían afectar a la propia entidad y a sus clientes, en transacciones realizadas online.

¿Y en el mundo?

La labor de un CERT no sería efectiva sin la colaboración con los demás. Ya en 1989, cuando se creó el primer cert del mundo, el CERT/CC, quedó clara la necesidad del trabajo en equipo, por lo que en 1990 fue creado el Forum of Incident Response and Security Teams (FIRST).



Asociados en el FIRST hay ahora mismo 192 equipos de respuesta a incidentes, en 41 países, principalmente en Europa (Alemania tiene 16, Reino Unido 17) y Estados Unidos (62). La mayoría de los países está más o menos al nivel de España, que tiene registrados 4 equipos.

Con este organismo suele colaborar otro a nivel europeo, TERENA, con varias iniciativas, como son su grupo de trabajo TF-CSIRT, y Trusted Introducer. Esta última proporciona servicios a equipos acreditados, como son foros y listas de discusión, compartición de información, etc.

A nivel gubernamental en la UE, la ENISA (Agencia y Red Europea para la Seguridad de la Información), está planificando la creación de un programa, denominado “Sistema Europeo de Alertas e Información Compartida” (EISAS), que aúne los esfuerzos que realizan los centros de alerta de los países de la UE, así como los hechos por los departamentos de delitos informáticos de la Policía de cada país.

Esta misma organización tiene otros proyectos interesantes, como es una guía para poner en marcha tu propio CERT, ejemplos incluidos.



Conclusión

Los servicios de los centros de respuesta a emergencias son aún poco conocidos por los profesionales de la informática, y menos aún por otros tipos de usuarios, debido a que hasta hace poco tiempo, los únicos que había españoles eran de ámbito universitario. Queda aún mucho trabajo por divulgarlos, por ejemplo entre PYMEs, como es el objetivo de Inteco. Las iniciativas realizadas a nivel español y europeo, hacen pensar que este tipo de servicios tendrá un crecimiento elevado a medio plazo.

Referencias

RFC 2828: Internet Security Glossary
RFC 2350: Expectations for Computer Security Incident Response
Forum of Incident Response and Security Teams (FIRST)
ENISA: European Network and Information Security Agency



Intentaré ampliar la información puesta aquí, con lo que vea en la guía antes mencionada, y con lo que lea en este otro libro que he encontrado: "Handbook for security incident response teams (CSIRTs)".

Slds!