La banca suspende en seguridad

noviembre 1, 2007 § Deja un comentario

De nuevo el problema de la seguridad está encima de la mesa; en este caso en lo que atañe al ámbito de las entidades financieras, tal como refleja un estudio elaborado por Deloitte: 2007 Global Security Survey.

Casi la totalidad de las consultadas (estudio realizado a nivel mundial sobre 100 compañías) indica que aumentan sus presupuestos en seguridad, aunque un 35 por ciento cree que estas inversiones deberían ser superiores.

El hecho es que estas organizaciones son conscientes de que la seguridad es un componente crítico en el seno de sus empresas, aunque al mismo tiempo reconocen que en ocasiones no disponen de las soluciones adecuadas y que también se enfrentan a problemas generados por un componente humano (empleados, clientes, proveedores). Así, en el último año reconocen haber detectado vulnerabilidades en sus sistemas, tanto de carácter interno (31 por ciento) como externo (71 por ciento).

En cualquier caso, lo representativo del estudio es que el 37 por ciento de las entidades financieras afirman que no han perfilado ninguna estrategia en seguridad. Además, sólo un 10 por ciento tiene un director de Seguridad dentro del departamento de TI que reporte al comité ejecutivo.

El aspecto que más preocupa a estas empresas es la seguridad relacionada con los clientes y aquélla que proviene de las operaciones efectuadas por medio de la banca on line. Virus y gusanos, ataques por e-mail y phising son los peligros más observados por estas empresas. Pero hay que mencionar que un 79 por ciento de los encuestados señalan que el factor humano es una causa de los problemas de seguridad informática.

En cuanto a la formación, Deloitte recoge que las empresas afirman cubrir adecuadamente este aspecto: un 84 por ciento asegura que sus empleados ha recibido formación en seguridad en el último año.

Fuente: http://www.computing.es/Actualidad/Noticias/Inform%C3%A1tica_profesional/Empresas/20071031039
http://www.deloitte.com/dtt/research/0,1002,sid=1013&cid=170582,00.html
http://www.deloitte.com/dtt/cda/doc/content/dtt_gfsi_GlobalSecuritySurvey_20070901(1).pdf

Anuncios

Mejores prácticas para evitar la pérdida de información

noviembre 1, 2007 § Deja un comentario

El reporte titulado “Data Loss Prevention Best Practices, Managing Sensitive Data in the Enterprise,” define algunas de las mejores prácticas que pueden aplicar las empresas para prevenir las fugas de información, asegurar el cumplimiento y proteger el valor y la reputación de su marca, dicho reporte es elaborado por IronPort Systems.


La Prevención de la Pérdida de Información (DLP sus siglas en inglés) es un serio problema para las empresas; la cantidad de incidentes (y costos relacionados) continúan aumentando. Puede tratarse de un ataque malintencionado o un error involuntario, pero la pérdida de información puede afectar la marca, disminuir el valor de todas las partes involucradas y dañar el buen nombre y la reputación de una empresa.


Cuando se trata de prevenir la pérdida de información, el aspecto más importante es la falta de control en la comunicación”, comentó Tom Gillis, Vicepresidente Senior de Mercadotecnia de IronPort Systems. “Los comunicados electrónicos y el intercambio de la información constituyen el vector de pérdida de información más importante para las empresas. Actualmente, los firewalls y otras soluciones de seguridad para redes no incluyen capacidades para prevenir la pérdida de información y asegurar el intercambio de datos. Se necesitan controles eficaces como el escaneo de contenido para proteger mensajes que contengan información confidencial y codificada. Cuando se está buscando una solución para controlar la pérdida de información, es necesario que las organizaciones consideren las mejores prácticas de DLP para estructurar una solución que se adapte a sus necesidades específicas”.

La gran mayoría de medios de comunicación electrónicos como los correos electrónicos, mensajes instantáneos, webmails, formatos en sitios web o transferencias de archivos que utiliza una empresa no están sujetos a un control o monitoreo, por lo tanto, siempre existe el riesgo de que la información confidencial caiga en las manos equivocadas. En todos los protocolos básicos de cualquier empresa siempre se debe incluir una solución DLP inteligente y de alto rendimiento. Los líderes deben buscar proveedores con gran experiencia y conocimientos en el escaneo de contenido para seleccionar la mejor solución DLP disponible.


El reporte sobre DLP incluye las siguientes mejores prácticas:
1: Dedicar el tiempo necesario a la definición de los requisitos de DLP
El primer paso importante para resolver el problema de pérdida de información es conocer e identificar los tipos de información confidencial que existen dentro de la organización y las políticas necesarias para controlar y determinar la mejor forma de transmitir dicha información. Para lograr este objetivo, las organizaciones deben analizar el grado de afectación de su empresa o agencia, ocasionado por el cumplimiento regulatorio, la protección de la propiedad intelectual y la implementación de los usos adecuados.

2: Priorizar el enfoque de DLP

La prevención de la pérdida de información es un problema complejo que requiere la combinación de las mejores soluciones para satisfacer de manera adecuada las necesidades específicas de una organización. El hecho de enfocarse primero en las áreas más importantes de DLP, las que representan los principales vectores de pérdida, facilita la definición de soluciones y el bloqueo de fugas.

3: Garantizar una cobertura eficiente e integral

En términos generales, una solución DLP debe tener la capacidad de detectar de manera eficiente e integral las posibles violaciones a las políticas. Esto implica lo siguiente:
– Monitoreo y prevención de protocolos múltiples
– Análisis de contenido de los archivos principales y adjuntos – Bloqueo y/o cuarentena selectiva de mensajes
– Aplicación automática de políticas corporativas de codificación

4: Lograr una solución no intrusiva

La mejor solución DLP es la que no es intrusiva. Para superar el reto de contar con una comunicación efectiva (al mismo tiempo que se garantiza la administración y el control de la información confidencial y de los clientes) es necesario: contar con políticas bien definidas; y procesos para monitorear el contenido de los comunicados. Las organizaciones deben seleccionar una solución DLP para las aplicaciones de correo electrónico y web, capaz de administrar los crecientes volúmenes de mensajes y manejar las necesidades futuras de ancho de banda. Aunque esto parezca una tarea difícil, la buena noticia es que sí existen soluciones optimizadas en cuanto a escalabilidad, desempeño y seguridad.

5: Organizar tareas, administración y elaboración de reportes

Una solución DLP no puede ser eficaz si no produce reportes detallados de todas las supuestas transgresiones. Los administradores y encargados de definir las políticas deben recibir reportes que describan las fallas detectadas y ofrezcan información específica para permitirles tomar las medidas necesarias. Algunos de estos detalles son: el remitente del mensaje, el contenido, los archivos adjuntos, los posibles destinatarios e información sobre el contenido afectado.

6: Combinar las mejores soluciones
Lo que distingue a las mejores soluciones es su capacidad de aumentar y mejorar el nivel de eficacia a través de la integración de otras herramientas de la misma calidad. Las empresas no deberían elegir una solución DLP que no les permita hacer estas integraciones en un futuro. A medida que evolucione la industria, será muy importante contar con la flexibilidad y el respaldo necesario para aprovechar al máximo las soluciones de terceros a través de la conectividad y el intercambio de información.

Tom Gillis, Vicepresidente Senior de Mercadotecnia de IronPort Systems

RFP (Request for Proposal) de seguridad informática

octubre 28, 2007 § 1 comentario

La famosa Solicitud de Propuesta o “Request for Proposal” (RFP) como suele llamársela es uno de los documentos más importantes para los responsables de la seguridad informática de cualquier organización.

Ventajas de usar un RFP

Toda adquisición de servicios o productos debiera basarse siempre en un RFP ya que este documento define las características (obligatorias y deseables) así como las restricciones de cualquier servicio. Un buen RFP evita que:

* Se adquiera un servicio o producto distinto al que se requiere
* El proveedor no cumpla con las expectativas del cliente
* Se genere una propuesta con un costo distinto (muy bajo o muy alto) con respecto a lo que realmente se requiere
* Se pierda tiempo de forma innecesaria en la negociación con proveedores
* Se entreguen requerimientos distintos a diversos proveedores (en el caso de licitaciones o procesos similares de búsqueda de ofertas de varias empresas)

La creación de un RFP ciertamente implica tiempo, pero a la larga el tiempo invertido en su desarrollo evita serios dolores de cabeza y una pérdida de tiempo mayor para ambas partes.

Para no generar un RFP nuevo cada vez que vez que se busca adquirir un nuevo producto o servicio, es conveniente tener a la mano un formato con la estructura y algo de contenido por omisión.

Estructura de un RFP

A continuación les comparto una estructura general del RFP para seguridad informática con base en mi experiencia:

Datos generales de la empresa

Contiene la información relevante del cliente para poner en contexto al proveedor. Incluye entre otras cosas:

* Nombre de la empresa
* Giro/sector de la empresa
* Antecedentes de la empresa (Algunos o todos los siguientes: Cuando fue fundada, presencia en el país, presencia en otras partes del mundo, número de empleados)

Datos del producto o servicio

Información sobre el producto o servicio requerido, incluyendo para el caso de productos:

* Protocolos/ algoritmos (ej. en el caso de requerimientos criptográficos)
* Características técnicas (tamaño, consumo de energía, anchos de banda, puertos, etc.)
* Cantidad requerida
* Compatibilidad (plataformas, bases de datos, consolas de administración)
* Estándares (ej. ISO, FIPS)

En el caso de servicios se suele incluir información como:

* Rangos de tiempo estimados para el inicio y fin del servicio
* Alcance (cantidad de elementos así como nivel de detalle)
* Objetivos
* Habilidades/experiencia/certificaciones de consultores
* Otras restricciones (algunas fechas u horarios, limitaciones técnicas para hacer el trabajo, limitaciones legales como permisos de trabajo para extranjeros, etc.)
* Herramientas
* Metodologías en el caso de algunos servicios (ej. ISSAF, OSSTMM, IAM)

Entre más información se proporcione en esta sección es más fácil para los proveedores determinar un precio adecuado pero sobre todo cumplir con las expectativas del cliente. Por ejemplo, pedir sólo un firewall es muy distinto a pedir un firewall de red capa 7 con capacidad de 4 puertos Gigabit que soporte protocolos HTTP y SMTP.

Criterios de aceptación y selección

Información sobre el proceso para escoger al servicio o producto (en caso de solicitar propuestas de varias empresas) así como las características que debe cumplir para ser aceptado (por ejemplo, entregables para dar como concluido de forma satisfactoria un servicio).

Estos criterios son importantes porque le indican a la empresa los factores más importantes en los que debe hacer énfasis dentro de su propuesta para obtener el contrato (e.g. calidad, precio, experiencia, prestigio). Aquí se incluyen cosas como:

* Tiempos de entrega
* Desempeño (para hardware)
* Experiencia (para software)
* Cumplimiento con requerimientos técnicos
* Reportes de resultados (para servicios)
* Soporte
* Precio

Es muy importante dejar claro el orden de importancia cuando hay varios criterios. Usualmente el criterio de precio se suele dejar al último como criterio de desempate, poniendo primero al de cumplimiento y después de éste a otros criterios de calidad como desempeño y soporte. En otras palabras: primero se suele elegir a aquellas propuestas que cumplen con nuestra expectativas y nos dan mayor calidad, y luego se escoge a la más barata de entre estas propuestas.

Restricciones legales

Algunas empresas como por ejemplo Instituciones Financieras o del Sector Salud tienen que cumplir con ciertas normas. Aquí es donde se detalla este tipo de requerimientos. Por ejemplo, en algunos países existen normas sobre el manejo de información personal, por lo cual el contrato deberá incluir cláusulas que sean congruentes con dicha regulación.

Formato de entrega de propuesta
Si se pretende hacer una selección de entre varios proveedores lo más sano es desarrollar un formato de entrega de información para que los proveedores contesten ahí los requerimientos del RFP. Si no lo hacemos de esta manera tendremos que revisar con detalle la documentación entregada por los proveedores, la cual puede variar significativamente en forma y orden, lo que nos pone en riesgo de omitir algún detalle importante a la hora de hacer la comparación de las propuestas.

Dentro del formato de entrega se suelen incluir requerimientos como:

* Moneda para cotizar (Dólares, Euros, Pesos, etc.)
* Inclusión o no de viáticos e impuestos
* Desglose de cotización por fases de servicios o grupos de productos
* Anexos que debe de traer (en el caso de productos es común que se pida la ficha técnica como un anexo)

Información de contacto

Esta sección contiene la información necesaria para que los proveedores envíen sus propuestas y resuelvan dudas que pudieran tener al respecto. Incluye:

* Nombre del responsable por parte de la empresa
* Puesto del responsable
* Teléfono/ correo electrónico/ fax
* Dirección física de la empresa

Con un buen RFP podemos mejorar nuestro proceso de adquisición de soluciones de seguridad y evitar que algún proveedor se pase de listo al vendernos algo demasiado caro o que no satisfaga nuestras necesidades.

Fuente: http://candadodigital.blogspot.com/2007/10/rfp-de-seguridad-informtica.html

Gestión de cambios

octubre 22, 2007 § Deja un comentario

Uno de los aspectos fundamentales en la gestión de la seguridad (y de cualquier otra cosa) es la gestión de cambios. Todos nos sentimos relativamente cómodos gestionando aquello que no cambia, que es estático. Somos animales de costumbres. El problema es que los cambios son inevitables, y por tanto tenemos que ser capaces de afrontarlos. Una buena gestión de cambios es clave si queremos mantener nuestros niveles de seguridad a lo largo del tiempo…

En primer lugar, es importante identificar los cambios. Cambios que no tienen por qué ser internos o por iniciativa propia, sino que se pueden producir en el entorno. Y el punto crucial es ser capaces de detectarlos. Nuevas amenazas o vulnerabilidades quizás sean el ejemplo más socorrido, pero no tiene por qué ser el único. Cualquier factor del entorno, tanto cercano como lejano, puede cambiar, y nosotros tenemos que ser capaces de identificarlo y evaluarlo.

La segunda parte es, como acabo de indicar, evaluar el impacto de los cambios. Tanto directo como indirecto, tanto inmediato como a largo plazo. Ahora bien, hay que ser prácticos. No podemos evaluar absolutamente todas las consecuencias, muchas veces no sólo es poco rentable sino que es prácticamente imposible. No podemos estar evaluando infinitamente, la gestión de cambios debe seguir. Habrá que evaluar los pros y los contras más evidentes, sopesarlos, y decidir. Que habrá consecuencias que no hayamos previsto? Seguro. Y es que en cualquier decisión estamos asumiendo riesgos. Pero que conste que también lo hacemos si continuamos con nuestra evluación…

Decidir es el punto crítico. Hacer algo, o no hacer nada. Pero debemos tener en cuenta que la decisión de partida es no hacer nada. Mientras estamos evaluando, no estamos reaccionando al cambio. Estamos tomando, de facto, la decisión de no hacer nada. Y esa decisión tiene sus riesgos, al igual que la decisión de reaccionar al cambio. Sea cual sea la decisión, algo debe quedar patente: quién asume la decisión, sus motivos, y sus consecuencias. Y si estos tres factores quedan por escrito, mejor que mejor.

Hasta ahora hemos pensado que nuestra decisión de cambio es como reacción a otro cambio externo. En general suele ser así (reacciones a los cambios del entorno, del negocio, de las estrategias, …), pero aun en caso de que el cambio sea originado internamente, la situación es idéntica: habrá que especificar quién decide (en base a sus funciones y responsabilidades), sus motivos, y las consecuencias previstas por dicha decisión.

Una vez que hemos recorrido el circuito de decisión del cambio, el resto es fácil. Hay que planificar (pensar) el cambio y cómo se va a llevar a cabo, ejecutarlo, verificarlo y registrarlo. El circuito típico. Sin embargo… cuántas veces se cumple por completo? Además, tenemos que tener en cuenta que dentro del ciclo de “ejecución” del cambio pueden aparecer nuevos factores que realimenten a la fase de decisión, y que puedan llegar a motivar su cambio. Esto no es algo que deba asustarnos, o que debamos evitar: una correcta gestión de cambios debe tenerlo en cuenta. Pero debe tenerlo en cuenta de esta forma, sin necesidad de una planificación “virtual” de todo el ciclo en la fase de decisión. Si no, nunca reaccionaremos a los cambios…

Quizás la mejor forma de ilustrar todo este ciclo es con un ejemplo. Pensemos en la publicación de una vulnerabilidad asociada a una aplicación de nuestro servidor central. El entorno ha cambiado. Cuál es la reacción asociada? Parchear. Qué inconvenientes tiene? Inestabilidad, mal funcionamiento, necesidad de una parada programada… Las ventajas también son claras: reducción del nivel de riesgo, que ha aumentado al publicarse la vulnerabilidad. Quién debe decidir? Supongamos que el director de sistemas, con el asesoramiento del responsable de seguridad y de los técnicos expertos en la aplicación y el servidor central. Qué decide?
Hasta este punto, la historia es más o menos sencilla. Pero… qué ocurre si el director de sistemas no cuenta con un entorno de pruebas para verificar la estabilidad del parche? O si el personal no tiene tiempo para realizar las pruebas? O si no cuenta con la asesoría necesaria? Sencillamente, que el riesgo de tomar la decisión aumenta. Pero esto en ningún caso significa que no pueda tomar la decisión. Y vuelvo a decir que mientras se llevan a cabo las pruebas, o se buscan recursos, se está tomando la decisión de no hacer nada, y por tanto asumir el riesgo asociado a la vulnerabilidad que se acaba de publicar.
Si el director de sistemas decide parchear, lo siguiente será planificar la parada, procedimentar el parcheo si es necesario, ejecutarlo, verificar la estabilidad del sistema tras la operación, registrar las tareas realizadas, … Y que conste que todas estas fases son necesarias, no vale sólo con la ejecución. Por supuesto, “con cabeza”: probablemente la instalación de una nueva fuente TrueTipe no requiera la misma profundidad de gestión que el parcheo de la base de datos Oracle. Aunque sí las mismas fases…

En resumen, una buena gestión de los cambios es clave para la seguridad. Tanto a nivel IT como a cualquier otro: documental, operativo, contractual, … Nuestra gestión de cambios deberá ser integral, y asegurar que se cumplen todos los pasos en todos los entornos. Y si no, ser conscientes de que estamos asumiendo el riesgo de no realizar una correcta gestión de cambios. Cómo se cuantifica este riesgo? Eso ya es otra historia…

Gestión de perfiles: la clave de la seguridad

octubre 22, 2007 § Deja un comentario

Es muy habitual encontrar artículos que hablan sobre las bondades de unos u otros productos de seguridad. También es cada vez más habitual ver cómo esos artículos tratan de dar mayor empaque al producto en cuestión relatando lo bueno que es para mejorar un determinado aspecto sobre gestión de la seguridad. Pero lo que echo en falta es la aparición de artículos que vayan en el sentido contrario, que destaquen un determinado aspecto de la gestión de la seguridad en sí mismo sin necesidad de hablar de productos de seguridad, y que como mucho permitan enlazar con determinadas tecnologías o productos de seguridad en caso de que se quiera profundizar en la implementación tecnológica de la solución. Hoy quiero empezar con una nueva categoría que trate de dar pinceladas desde este punto de vista: Gestión práctica de la seguridad.

El primer tema que quiero tratar es la gestión de perfiles como piedra angular de la seguridad ligada al personal. Pero no gestión de perfiles desde un punto de vista técnico, sino gestión de perfiles desde el punto de vista de gestión de los recursos humanos.

El término perfiles puede ser ambiguo, así que prefiero hablar de los distintos aspectos que debemos gestionar en relación a las personas: funciones, roles, responsabilidades y privilegios. Vamos por partes.

La gestión de roles (o cargos, si se prefiere) es un aspecto presente en todas las organizaciones. Al menos, en apariencia. Todas las empresas tienen sus organigramas, mejor o peor definidos, y cada persona tiene su “título” dentro de la organización. Sin embargo, poca “gestión” suele haber en relación a estos roles: en general, los organigramas no se suelen revisar ni retocar demasiado (al menos, no como consecuencia de una revisión sistemática de los mismos).

La gestión de funciones suele ser un aspecto mucho más descuidado. En general, es poco habitual encontrarse con una definición completa de las funciones asociadas a cada rol, y si ni siquiera están escritas difícilmente podrán ser gestionadas adecuadamente. Quizás sea un rasgo cultural, tal como dejaba entrever Samuel Linares en su blog, pero el caso es que la carencia es clave desde el punto de vista de la seguridad. Cómo se pueden articular las medidas adecuadas para que cada persona preserve la integridad, confidencialidad y disponibilidad de la información que maneja en su día a día, si no está definido ese día a día? La solución de “café con leche para todos” acaba volviéndose en contra de la organización, tanto por exceso de presión normativa para unos como por reglas insuficientemente estrictas para otros. Pero no se puede ser más granular si no está establecida la vase sobre la que se deben aplicar las normas de seguridad…

La gestión de responsabilidades es el eterno caballo de batalla. Cuántas veces nos hemos encontrado con “marrones” que nadie quiere asumir? Y todo por que, unido a lo anterior, no se definen los roles encargados de ratificar determinadas decisiones, o de supervisar determinadas acciones. A río revuelto… Y ni siquiera las empresas que más se preocupan por estos temas suelen tener en cuenta dos aspectos clave: las responsabilidades delegadas lo deben estar formalmente (y “aceptadas” documentalmente), y la definición de responsabilidades se debe revisar periódicamente. Cuántas personas siguen siendo “responsables” de una tarea que realizaban en un puesto en el que ya no están?

Por último, tenemos la gestión de permisos o privilegios de acceso. En realidad no debería ser algo con entidad propia, ya que estos permisos no deberían ser más que la articulación tecnológica de los aspectos anteriores, pero desde el punto de vista técnico la tarea tiene un peso específico propio nada desdeñable. Los permisos de los usuarios, o más bien los permisos asociados al identificador lógico de cada persona, deberían ir en consonancia con las funciones y responsabilidades asociadas al rol que cada uno desempeña dentro de la organización. Y su revisión no debería ser más que la constatación de que ambos coinciden. Ahora bien: si todo lo anterior no está formalmente definido, contra qué se van a contrastar estos permisos de acceso? Difícilmente podrá nadie de Sistemas verificar si los permisos son correctos o no. ¿A quién corresponde llevar a cabo esta revisión? Evidentemente, a la empresa. Pero la pregunta es: ¿A quién, dentro de la empresa? Sencillamente, a quien tenga definida esa tarea entre sus funciones. Aunque claro, si el problema es que esa definición es la que falta…

En resumen, la revisión de funciones, roles, responsabilidades y permisos debe ser una tarea propia de la gestión de los recursos humanos, no de los departamentos técnicos. Sólo debería llegar a este área cuando exista una documentación formal, aprobada, revisada y mantenida contra la que contrastar dichos permisos. Y en caso de que no exista, la validación de privilegios de acceso debería ir escalando por el organigrama hasta llegar al máximo órgano competente… siempre que esté definido.

Alguien se preguntará que por qué no he citado ninguna herramienta de gestión de identidades, ni he hablado de metadirectorios, ni he mencionado en ningún momento un LDAP. Sencillamente, porque la gestión de perfiles es previa, y excede a cualquier tecnología, como acabo de señalar. ¿En cuántos proyectos de gestión de identidades se respeta esta premisa? ¿Cuántos proyectos de gestión del conocimiento tienen en cuenta estos aspectos? ¿Cuántos de ellos tienen un trabajo exhaustivo de definición de perfiles previo a la implantación de la herramienta de turno? Y claro, luego suele sorprender que muchas organizaciones sigan teniendo problemas de gestión de perfiles y usuarios tras la implantación de la super-herramienta de turno…

Fuente: http://secugest.blogspot.com/2007/09/gestin-de-perfiles-la-clave-de-la.html

¿Gestionamos o tapamos agujeros?

octubre 19, 2007 § Deja un comentario

El escenario actual de los Sistemas de Información presenta una problemática y unos retos en materia de seguridad distintos de los que tenían los Sistemas de Información centralizados con acceso limitado (mainframe) de hace 15 o 20 años. La complejidad tecnológica existente plantea la compatibilidad e interoperabilidad entre herramientas para minimizar los problemas de gestión, el aumento del volumen de información, las transacciones y accesos que se deben securizar, así como el constante incremento de los riesgos de seguridad de las redes.

Las Organizaciones ven hoy la seguridad de sus activos tecnológicos como un requerimiento imprescindible para mantenerse en el negocio. La seguridad, no obstante, no debe verse como la implantación de unos Sistemas novedosos más o menos complejos, para solventar un problema puntual, sino como un proceso más general de mejora continua, donde se busque la continuidad del negocio y que debe cubrir todas las áreas y departamentos de una Organización. Es necesario disponer de mecanismos que permitan evaluar las soluciones implantadas en su conjunto y determinar el nivel de seguridad alcanzado, ya sea para saber si se está en un nivel de seguridad adecuado o bien si se está degradando el nivel de seguridad con el paso del tiempo.

Esta evaluación continuada permitirá actuar de manera proactiva respecto a la seguridad, siendo conscientes del nivel adquirido y el nivel deseado, siempre desde un punto de vista de un proceso continuado. La mera implantación de herramientas con configuraciones estáticas conducirá al deterioro progresivo de la seguridad, aumentando la diferencia entre el riesgo percibido y el riesgo real. A la inversa, la mera existencia de políticas, controles y revisiones de auditoria no son efectivas si no van acompañadas de herramientas y medidas técnicas que permitan respuestas rápidas y automatizadas y a condiciones de vulnerabilidad en permanente evolución. La seguridad es un proceso, no un producto.

Las políticas corporativas mencionadas anteriormente son también necesarias y éstas deben ser globales, de forma que afecten e impliquen a toda la Organización y que, sobre todo, cuenten con el respaldo de la Dirección. Estas políticas deben desencadenar el desarrollo y la definición de unos procesos y procedimientos basados en metodologías de trabajo, con la implantación de controles organizativos y con el establecimiento de procesos de medición y auditorias para verificar y controlar la implantación de las políticas.

Por concluir: la búsqueda de una solución global que permita la gestión de forma continuada de la seguridad de los Sistemas de Información no es una tarea fácil. Resulta difícil decir cual será la mejor solución o producto global, puesto que las necesidades de las organizaciones pueden ser completamente distintas unas de las otras. Sin embargo, para una correcta coordinación entre las diferentes áreas de actuación comentadas, se deberá considerar como claves los siguientes aspectos:

1.- Coherencia y Equilibrio técnico y funcional: mediante la integración tecnológica y la compatibilidad de las distintas herramientas, así como el uso de estándares y soluciones abiertas frente a plataformas propietarias. Esta coherencia debe ser tanto a nivel tecnológico como funcional, dando soporte a los procedimientos, políticas, controles y auditorias que permita unificar criterios.

2.- Escalabilidad/Disponibilidad: que garantice el rendimiento ante anchos de banda crecientes, que permita el crecimiento e implantación de nuevos módulos, re-usabilidad de componentes y facilidad de gestión y monitorización.

Fuente:
http://blog.s21sec.com/2007/10/gestionamos-o-tapamos-agujeros.html
http://www.sahw.com/wp/archivos/2007/10/21/gestionar-seguridad-y-la-diferencia-con-tapar-agujeros/

La función de Seguridad Informática en la empresa

octubre 18, 2007 § Deja un comentario

Este siempre ha sido un tema complicado porque cada organización es distinta y no hay un acuerdo sobre la mejor manera de organizar un área de seguridad informática en una empresa.

Por lo tanto lo que les expongo aquí no es una mejor práctica, simplemente se trata de algunas sugerencias basadas en mi experiencia.

Componentes principales de un área de seguridad informática

Existen diversas funciones que debe desempeñar un área de seguridad informática y éstas se pueden agrupar de la siguiente manera:


Hay un par de áreas que no son tan comunes y que están en color gris en el diagrama: normatividad y desarrollo. Al revisar las responsabilidades y funciones de cada área quedará más claro el por qué. Por lo pronto les comento que es menos probable encontrar estas 2 áreas en empresas medianas o pequeñas, mientras que en empresas grandes es más común que existan las 4 áreas junto con la figura del líder de área.

Líder de área Esta figura, a la cual se le suele conocer como CISO (Chief Information Security Officer – Oficial de Seguridad informática). Entre sus responsabilidades se encuentran:

* Administración del presupuesto de seguridad informática
* Administración del personal
* Definición de la estrategia de seguridad informática (hacia dónde hay que ir y qué hay que hacer) y objetivos
* Administración de proyectos
* Detección de necesidades y vulnerabilidades de seguridad desde el punto de vista del negocio y su solución

El líder es quien define, de forma general, la forma de resolver y prevenir problemas de seguridad con el mejor costo beneficio para la empresa.

Normatividad

Es el área responsable de la documentación de políticas, procedimientos y estándares de seguridad así como del cumplimiento con estándares internacionales y regulaciones que apliquen a la organización. Dado que debe interactuar de forma directa con otras áreas de seguridad y garantizar cumplimiento, es conveniente que no quede al mismo nivel que el resto de las áreas pero todas reportan al CISO. Por esta razón se le suele ver como un área que asiste al CISO en las labores de cumplimiento.

Operaciones Es el área a cargo de llevar a cabo las acciones congruentes con la estrategia definida por el CISO lograr los objetivos del área (en otras palabras, la “gente que está en la trinchera”). Entre sus responsabilidades se encuentran:

* Implementación, configuración y operación de los controles de seguridad informática (Firewalls, IPS/IDS, antimalware, etc.)
* Monitoreo de indicadores de controles de seguridad
* Primer nivel de respuesta ante incidentes (típicamente a través de acciones en los controles de seguridad que operan)
* Soporte a usuarios
* Alta, baja y modificación de accesos a sistemas y aplicaciones
* Gestión de parches de seguridad informática (pruebas e instalación)

Supervisión Es el área responsable de verificar el correcto funcionamiento de las medidas de seguridad así como del cumplimiento de las normas y leyes correspondientes (en otras palabras, brazo derecho del área de normatividad). Entre sus responsabilidades se encuentran:

* Evaluaciones de efectividad de controles
* Evaluaciones de cumplimiento con normas de seguridad
* Investigación de incidentes de seguridad y cómputo forense (2° nivel de respuesta ante incidentes)
* Atención de auditores y consultores de seguridad

Noten que las actividades de monitoreo las realiza el área de operaciones y no el área de supervisión. Esto es porque el monitoreo se refiere a la vigilancia del estado de la seguridad de la empresa a través de los controles, pero las actividades del área de supervisión se limitan a la vigilancia de las actividades de seguridad que realizan otras áreas. La única excepción es la investigación de incidentes. Operaciones no investiga porque en algunos casos podrían se juez y parte. Por ejemplo, en el caso de una intrusión no es válido que el mismo personal que operaba los controles que protegían el servidor investiguen el suceso porque no puede haber objetividad (aunque no sea el propósito de la investigación, de cierta manera los resultados de la misma podrían calificar indirectamente la efectividad del personal del área de operaciones). La razón por la cual es preferible que esta área sea el punto de contacto con auditores y consultores es porque sus labores son afines y es más probable que tengan a la mano la información que requieran o sepan quién la tiene.

Desarrollo

Es el área responsable del diseño, desarrollo y adecuación de controles de seguridad informática (típicamente controles de software). Entre sus responsabilidades se encuentran:

* Diseño y programación de controles de seguridad (control de acceso, funciones criptográficas, filtros, bitácoras de seguridad de aplicativos, etc.)
* Preparación de librerías con funciones de seguridad para su uso por parte del área de Desarrollo de Sistemas
* Soporte de seguridad para el área de Desarrollo de Sistemas
* Consultoría de desarrollos seguros (integración de seguridad en aplicaciones desarrolladas por Sistemas).

Básicamente se trata de un área de desarrollo enfocada a cuestiones de seguridad. La razón de requerir un área dedicada para esto es que la integración de controles efectivos en software es una tarea muy compleja; el perfil de un programador promedio no incluye experiencia ni conocimientos en seguridad (y particularmente en criptografía). Esta es la razón por la cual sólo las grandes empresas cuentan con un área de desarrollo de seguridad que está formada por especialistas en vez de programadores ordinarios.

¿Dónde debe estar la función de Seguridad Informática? Este es otro problema para el cual no hay una respuesta única. Podemos empezar por listar las áreas o direcciones de las cuales no debe de depender el área de Seguridad Informática:

* Sistemas – Mucho de lo que vigila el área de operaciones de seguridad son precisamente los sistemas y las redes de telecomunicación. El área de sistemas tiene como prioridad la operación, y los controles tienden a impactar de cierta forma el desempeño y flujo operativo (pero no por esto dejan de ser necesarios). El hecho de que Seguridad Informática dependa del Área o Dirección de Sistemas genera conflictos de interés.
* Auditoría Interna – La función de auditoría es verificar la efectividad y existencia de controles en todas las áreas de la organización (incluyendo Seguridad). Auditoría no opera, pero el área de Operaciones de Seguridad sí, por lo que habría conflictos de interés (Auditoría revisaría en parte algo que ella misma hace, lo que la convertiría en juez y parte)
* Unidades operativas del negocio – por la misma razón que para el área de Sistemas

Por supuesto hay algunas áreas que no hace mucho sentido que incluyan la función de Seguridad Informática (Recursos Materiales y Recursos Humanos, por ejemplo), pero hay áreas donde sí puede colocarse esta función, como por ejemplo:

* Cumplimiento – Cumplimiento no es Auditoría. El área de Cumplimiento define establece las normas internas y supervisa su aplicación de la misma manera que las áreas de Normatividad y Supervisión lo hacen dentro de la función de Seguridad Informática.
* Jurídico – Esta área atiende todos los asuntos legales de la empresa. Como tal el tener al área de Seguridad dentro de la misma constituye un excelente apoyo para implementar controles que garanticen el cumplimiento de la ley.
* Finanzas – Esta área se asegura del buen uso del dinero de la empresa. Contar con un área de Seguridad Informática le permite asegurar la implementación adecuada de controles para minimizar riesgos que tengan impacto económico (fraudes, fugas de información, etc.). Dada la dependencia de los sistemas informáticos para el manejo de las finanzas en la actualidad este esquema es una buena opción para algunas empresas.
* Riesgos – El área de Seguridad Informática dependiendo del área de riesgos permite controlar y evaluar la mitigación de aquellos riesgos que afectan a los sistemas informáticos y la información que se almacena, procesa, genera o transmite a través de los mismos. Dada la dependencia que tienen muchos procesos productivos de los sistemas de información en la actualidad, ésta es una buena opción también para muchas empresas.
* Dirección General – Permite tener un estricto control de los recursos informáticos de la Empresa. Desafortunadamente este esquema es difícil por la diferencia de lenguajes y niveles entre ambas áreas así como las prioridades y el poco tiempo que suele tener la Dirección General, pero algunas organizaciones así lo tienen (por ejemplo, algunos Bancos).

Podría parecer que la existencia de las áreas de Operaciones y Desarrollo de Seguridad generan un conflicto de interés en los casos anteriores, pero no es así, ya que el conflicto está controlado por la separación interna de funciones dentro de la misma Área de Seguridad; con respecto al resto de las áreas, no se interfiere con su operación y existe separación de funciones, ya que el área de Operaciones de Seguridad realiza únicamente funciones de soporte al negocio y no interviene de forma directa en dichos procesos. Adicionalmente, la existencia de un área de Auditoría Interna separada permite una revisión imparcial de las funciones de Seguridad que dependa de cualquiera de las 3 áreas mostradas anteriormente. En ninguno de los casos anteriores la implementación y supervisión de controles de seguridad informática es un factor tan importante debido a su orientación a controlar; a diferencia del caso de Sistemas, donde su orientación es a producción.

De todas maneras, no hay un área ideal de dónde colgar al área de Seguridad Informática (si la hubiera, todo mundo lo haría así) quizás la dependencia directa de la Dirección General pero no es viable o fácil de lograrla en muchas empresas.

¿Función Centralizada o Distribuida?

Nuevamente, una pregunta que ha dado origen a interminables discusiones filosóficas sin ningún consenso, pero aquí trataré al menos de definir ventajas y desventajas de ambos esquemas así como algunas estrategias de distribución que han funcionado en algunas organizaciones.

Función centralizada

La función centralizada permite un mejor control y desempeño de las funciones de seguridad informática, sin embargo, este esquema también suele generar algunos roces con otras áreas de la empresa, particularmente con el área de Sistemas.

En mi opinión esta es una mejor opción para áreas donde el control sea esencial (incluso requerido por regulación) y se pueda sacrificar algo de desempeño en producción a costa de una mejor vigilancia. Algunos sectores que donde este esquema puede ser benéfico son: Financiero, Farmacéutico, Salud, Gobierno, Organismos Militares y Organismos Policiales.

Existe también la opinión de muchos especialistas de no sólo mantener una función central de Seguridad informática, sino incluso fusionarla con el área de Seguridad Física. Mi opinión al respecto es que debe existir integración entre ambas funciones de seguridad, pero en mi experiencia la dependencia de una de la otra no genera siempre buenos resultados. Lo ideal en mi opinión es integrar ambas bajo un mismo líder, el famoso CSO (Chief Security Officer).

El único cambio que yo vería en la integración de ambas funciones es el pasar la responsabilidad de implementación de los controles de seguridad física al área de Seguridad Informática (lo mismo con el desarrollo de controles si es el caso). Esto debido a que hoy en día, la mayoría de los controles de seguridad física se basan en sistemas informáticos (control de acceso, CCTV, alarmas de intrusión, etc.) y es más eficiente realizar estas funciones a través de gente con conocimientos y experiencia en sistemas.

En este caso, el área de Seguridad (física e informática) podría distribuirse de la siguiente manera:

Función Distribuida

Para algunas organizaciones hace más sentido distribuir la función de la seguridad ya que esto permite tener un mejor desempeño operativo a costa de menor control y desempeño en la seguridad informática. Algunos ejemplos de sectores de empresas donde esto suele suceder son: Manufactura, Servicios, Consultoría, Telecomunicaciones y Comercial.

En este esquema podemos pasar algunas funciones a áreas que normalmente no deberían contar con toda la función de seguridad informática. Por ejemplo, podríamos pasar las áreas de Operaciones de Seguridad y Desarrollo de Seguridad al área de Sistemas, integrándolas en las funciones correspondientes, siempre y cuando exista un líder de Seguridad Informática separado y que la función de Supervisión también se encuentre separada. El área de Normatividad de Seguridad podría recaer en el área de Cumplimiento y el área de Supervisión de Seguridad podría pasarse al área de Auditoría Interna (igualmente, sólo si las áreas de Operaciones de Seguridad y Desarrollo de Seguridad están en otro lado). Finalmente el CISO puede depender de alguna de las áreas antes mencionadas.

Un ejemplo de una función de Seguridad totalmente distribuida sería el siguiente:


Mi esquema preferido es un esquema parcialmente distribuido, donde el área de Seguridad Informática Depende directamente de la Dirección General y cuenta con áreas de Supervisión y Normatividad, mientras que las áreas de Operaciones de Seguridad y Desarrollo de Seguridad dependen del área de Sistemas.

Una de las razones principales por las que prefiero que estas 2 áreas dependan de Sistemas es por la burocracia que se genera al tenerlas dentro de un área de Seguridad centralizada. Por ejemplo, si un área operativa requiere que se abra un puerto en un firewall para instalar un nuevo sistema que urge (ya saben que en las empresas todo urge) es más rápido que el equipo de Operaciones de Seguridad en el área de sistemas se ponga de acuerdo con el equipo de Telecomunicaciones y aplique el cambio después de una breve revisión de impacto. Si hubiera algún conflicto de interés (ej. que se encontrara algún riesgo pero que el Director de Sistemas ordenara el cambio de todas maneras), eventualmente el área de Seguridad (a través del Equipo de Supervisión de Seguridad) se daría cuenta y tomaría acciones (de forma directa o a través de otra área). Igualmente, para resolver algún problema de Seguridad sencillo (por ejemplo una infección por Virus) es más fácil y rápido si el área de Operación de Seguridad está dentro de sistemas porque en estos casos esta área requiere del apoyo de personal de Sistemas (administradores por ejemplo); en el peor de los casos un Director de Sistemas podría pedir que se retrase la solución para dedicar a su gente a resolver otros problemas que considera más urgentes.

Si bien este tipo de conflictos se llegan a presentar, de acuerdo a mi experiencia son menos frecuentes de lo que mucha gente piensa (en la actualidad, la mayoría de los Directores de Sistemas y el personal de esta área se han sensibilizado ante los problemas de seguridad informática) y el beneficio en términos de tiempos de respuesta y menor roce con el área de Seguridad bien valen la pena. Pero ésta es sólo mi opinión.

Fuente: http://candadodigital.blogspot.com/2007/10/la-funcin-de-seguridad-informtica-en-la.html

¿Dónde estoy?

Actualmente estás explorando la categoría administración en Seguridad Informática.