gestión | Seguridad Informática

Clasificación de información e ISO 30301

mayo 3, 2013 § Dejar un comentario

Desde el año pasado existe la norma ISO 30300 sobre la gestión documental que proporciona viento fresco a los que nos dedicamos a su protección. Cada día soy más consciente de que el término “información” engloba un conjunto de definiciones que aun siendo similares, representan conceptos diferentes y de relevancia distinta. Los que nos dedicamos a la “seguridad de la información” según el caso y el tipo de documento podemos ser los garantes del conocimiento y la sabiduría de una empresa. El nivel de comprensión y el contexto en el que son analizados los datos, van elevando su altura y relevancia.

Uno de los grandes retos de la seguridad de la información es que por desgracia, carecemos de cultura de gestión de la información y por tanto, algunas de las medidas a implantar como controles ISO 27002 son duros de llevar a la práctica porque implican un cambio organizativo y cultural importante. Como es un tema que sufro de forma continua he tratado de buscar referencias que pudieran ayudarme y el haber tenido una compañera documentalista ha sido un gran lujo porque me ha tenido siempre bien informado y me ha hecho ver el tremendo papel que juegan los documentalistas en toda organización. Hace meses me habló de la norma ISO 30301 que pretende ser para la gestión documental lo mismo que ISO 27001 es para la seguridad de la información. Además, tenemos la suerte de que esta norma se ha cocinado bastante en España y tenemos a grandes expertos de la materia haciendo difusión de esta norma.

Me han dado la oportunidad de contribuir como redactor en el blog www.iso30300.es y eso esta permitiendo intercambiar enfoques e impresiones respecto a cómo abordar aspectos comunes entre las normas ISO 27001 e ISO 30301 (de diciembre de 2011) Al fin y al cabo no puede haber “gestión de la documentación” sin seguridad, pero tampoco puede haber “seguridad de la información” sin gestión de la documentación. Mi primer articulo está enfocado a plantear cómo puede definirse un criterio de clasificación que contemple los requisitos legales establecidos y a la par sea algo manejable, aplicable y real para una implementación en cualquier tipo de organización. El post por largo ha sido dividido en trozos:

Todavía no hay respuesta en la búsqueda de este santo grial, pero seguro que una solución mixta entre el mundo de la gestión documental y la seguridad de la información será mas completa y acertada que desde una visión parcial donde la protección prima por encima de cuestiones operativas. Ambas normas, ISO 27001 e ISO 30301 deben resolver la cuestión y nos toca ahora plantear un cuadro de clasificación de documentación que pueda servir para resolver el tema. En lo que respecta al marco jurídico, la legislación tanto de protección de datos de carácter personal como de Administración electrónica ya ha puesto nombre y apellidos a los criterios de clasificación, puesto que define 3 niveles: Alto, Medio y Básico. Ahora toca establecer los requisitos para definir todo el ciclo de vida de la información: recogida, clasificación, tratamiento, almacenamiento, transporte, desclasificación y destrucción.

Aquí hay una selección de recursos de referencia sobre la Norma ISO 30300.

Fuente: Blog de Javier Cao Avellaneda

La autenticación en el Compliance de los estándares mundiales

abril 26, 2013 § Dejar un comentario

Garantizar que el usuario establecido sea quien realmente ingrese a la información es imprescindible para garantizar su integridad. Pero cómo encaja este tema en las principales normativas y estándares de seguridad lo veremos a continuación.

Cada empresa de acuerdo a sus necesidades decide gestionar la seguridad de la información de acuerdo a un determinado estándar. El compliance o cumplimiento de estas normatividades es de suma importancia obviamente para garantizar la seguridad de la información más sensible y por otra parte para evitar multas o sanciones legales que pueden darse a partir de su incumplimiento.
El objetivo de estos estándares o regulaciones es garantizar la integridad, disponibilidad y confidencialidad de la información. Uno de los controles más comunes para garantizar estas tres características es la autenticación de usuarios. Veamos qué es lo que las principales normativas piden al respecto de este control.

El PCI DSS es un estándar que aplica donde sea que se almacenen, procesen o transmitan datos de cuentas bancarias. En su requisito 3 pide proteger los datos del titular de la tarjeta que fueron almacenados y en el requisito 7 restringir el acceso a los datos del titular de la tarjeta según la necesidad de saber del negocio, con el objetivo de que se limite el acceso a los componentes del sistema a aquellos individuos cuyas tareas necesitan de ese acceso. Para esto recomienda un sistema de control de acceso automático.

En el requisito 8 pide asignar una ID exclusiva a cada persona que tenga acceso por computadora, empleando al menos uno de los métodos siguientes para autenticar a todos los usuarios: algo que el usuario sepa, algo que el usuario tenga, algo que el usuario sea. Además sugiere incorporar la autenticación de dos factores para el acceso remoto (acceso en el nivel de la red que se origina fuera de la red) a la red de empleados, administradores y terceros.

Los lineamientos del FFIEC (Federal Financial Institutions Examination Council) son recomendaciones para que las entidades financieras evalúen el riesgo en las transacciones electrónicas y como se pueden mitigar con la aplicación de sistemas de autenticación. Este estándar incluye un apartado sobre los programas de seguridad por capas que deberían implementar las entidades financieras para garantizar la seguridad en las transacciones basadas en servicios a través de Internet. Dentro de los controles que sugiere esta norma se encuentra precisamente el uso de sistemas de doble autenticación utilizando diferentes dispositivos.

La Ley Sarbanes–Oxley, regulación impuesta a las empresas que participan en el mercado financiero estadounidense, sugiere que para cumplir con los lineamientos de seguridad se implemente COSO, el cual posee cinco componentes de control. El tercero de estos, Actividades de Control, trata entre otras cosas sobre el control de los sistemas de procesamiento electrónico de datos, dentro de los que destacan los controles sobre la seguridad lógica. Destaca los sistemas de autenticación para proteger los sistemas contra el acceso y uso no autorizados.

El NIST (National Institute of Standards and Technology) provee entre otras, las recomendaciones para implementar sistemas de autenticación. La seguridad en la autenticación, la divide en cuatro niveles, de los cuáles el tercer nivel hace referencia a la protección de acceso a la red de forma remota mediante factor de múltiple autenticación. Este estándar reúne, además, las características que deben tener los sistemas para garantizar la seguridad en la autenticación, describiendo su uso y tipos de acuerdo al factor de protección elegido (credenciales, tokens, procesos de autenticación, assertions).

Finalmente, la norma certificable ISO 27001, quizá la más conocida, es un estándar para implementar y certificar un sistema de gestión de la seguridad de la información. De los pilares básicos de la norma ISO 27001 el dominio de control A.11 está relacionado con el control de acceso. Precisamente el control A.11.4 está asociado con el acceso a la red, cuyo objetivo es prevenir accesos no autorizados.

Fuente: ESET Latinoamérica

Proceso de implantación de un SGSI

abril 15, 2013 § Dejar un comentario

Por Olof Sandstrom, Director de Seguridad de Arsys Internet.

El motivo por el cual decidir desarrollar un sistema de gestión de la seguridad de la información (SGSI), depende en gran parte del objetivo que se haya marcado la empresa. En el caso de Arsys Internet, el principal reto era integrar todos los procesos de las áreas técnicas bajo un marco único que englobara también la seguridad.

Para los procesos puramente técnicos teníamos bastante claro el modelo que íbamos a seguir. En este caso habíamos escogido el modelo ITIL. Sin embargo, no teníamos del todo claro el modelo a seguir a la hora de integrar los procesos de seguridad, ya que los aspectos relacionados con seguridad que se desarrollan en el marco de ITIL eran insuficientes para nosotros.

La Dirección decidió apostar por integrar la seguridad de la información dentro de un sistema de gestión independiente, pero que estuviera integrado con el resto de procesos de la compañía, adoptando así la ISO 27001.

Contenido completo en fuente original Borrmart o documento completo en PDF.

Algunos apuntes jurídicos sobre los contratos en Cloud Computing

abril 10, 2013 § Dejar un comentario

Llevamos una temporada de continuo bombardeo sobre soluciones Cloud Computing, como gran paradigma de soluciones de computación, caracterizado por su pago por uso, virtualización, multiusuario, escalable y de acceso sin restricciones.

Su desarrollo esta fuertemente asociado al fortalecimiento de las redes y de sus capacidades, junto a la aplicación de los principios de economía de escala, que permite reducciones de cotes y permite indiscutiblemente ganar en competitividad.

Contenido completo en fuente original Security by Defult Parte 1 y 2

Plan para la Recuperación de Desastres de TI

marzo 25, 2013 § 1 comentario

Los planes de recuperación de desastres (RD) en tecnologías de la información (TI) proporcionan un enfoque estructurado para responder a los incidentes no previstos que ponen en peligro la infraestructura de TI, compuesta por hardware, software, redes, procesos y personas. Proteger las inversiones realizadas por su firma en la infraestructura tecnológica y garantizar la capacidad empresarial para ejecutar sus operaciones corporativas son las principales razones para poner en marcha un plan de recuperación de desastres en TI.

En esta guía conoceremos todo lo necesario acerca de la elaboración del plan. Aprenderemos a desarrollar paso por paso el plan de RD de TI y los aspectos más importantes a tener en cuenta durante su elaboración.

¿Qué es un plan de recuperación de desastres TI?

Los planes de recuperación de desastres TI proporcionan unos procedimientos detallados a seguir, paso a paso, para recuperar los sistemas y redes que han sufrido disrupciones y ayudar a resumir la normalidad en las operaciones. El objetivo de estos procesos es minimizar cualquier impacto negativo en las operaciones de la compañía. El proceso de recuperación de desastres identifica los sistemas y redes críticos de TI; fija las prioridades para su recuperación y dibuja los pasos necesarios para reiniciar, reconfigurar y recuperar dichos sistemas y redes. Todo plan integral de recuperación de desastres debería incluir también a todos los proveedores relevantes, las fuentes de experiencia para recuperar los sistemas afectados y una secuencia lógica de los pasos a seguir hasta alcanzar una recuperación óptima.

Asumiendo que hemos completado una evaluación de riesgos e identificado amenazas potenciales a nuestra infraestructura de TI, el siguiente paso será determinar qué elementos de dicha infraestructura son los más importantes para las operaciones corporativas. Además, asumiendo que todos los sistemas y redes TI funcionan con normalidad, nuestra empresa debería ser plenamente viable, competitiva y sólida desde el punto de vista financiero. Cuando un incidente —interno o externo— afecta negativamente a la infraestructura de TI, las operaciones corporativas pueden verse amenazadas.

Según la NIST SP 800-34 [PDF], Contingency Planning for Information Technology Systems (Planificación de contingencias para los sistemas de tecnologías de la información), del National Institute for Standards and Technology (NIST, o Instituto Nacional de Estándares y Tecnología) de los Estados Unidos, lo que viene a continuación resume la estructura ideal de un plan de recuperación de desastres TI.

1. Elaboración de la declaración de políticas para el plan de contingencia. Contar con unas directivas formales proporciona la autoridad y orientación necesaria para elaborar un plan de contingencia efectivo.

2. Realización del análisis de impacto sobre el negocio (BIA). El análisis del impacto sobre el negocio ayuda a identificar y priorizar los sistemas y componentes críticos de TI.

3. Identificación de controles preventivos. Medidas que reducen los efectos de las disrupciones al sistema y pueden aumentar su disponibilidad y reducir los costos de contingencia del ciclo de vida.

4. Desarrollo de estrategias de recuperación. Tener una estrategia integral garantiza que el sistema se recuperará de manera rápida y efectiva después de una disrupción.

5. Desarrollo de un plan de contingencia TI. El plan de contingencia debería contener orientaciones y procedimientos detallados para la restauración del sistema dañado.

6. Prueba, formación y ejecución del plan. La prueba del plan identifica lagunas en la planificación, mientras que la formación prepara al personal de recuperación para la activación del plan; ambas actividades mejoran la eficacia del plan y la preparación general de la entidad.

7. Mantenimiento del plan. El plan debería ser un documento vivo que se actualiza regularmente para mantenerlo al día con mejoras al sistema.

Desarrollo paso a paso del plan de recuperación de desastres TI

Utilizando la estructura apuntada en la publicación SP 800-34 del NIST, podemos ampliar esas actividades a la siguiente secuencia estructurada de actividades.

1. El equipo de desarrollo del plan debería reunirse con el equipo interno de tecnología, el equipo de aplicación y los administradores de redes, y establecer el alcance de la acción, como por ejemplo, elementos internos, activos externos, recursos de terceros y enlaces a oficinas/clientes/proveedores; debemos asegurarnos de informar a la dirección del departamento de TI sobre dichas reuniones para que estén bien informados.

2. Recopilar todos los documentos relevantes de la infraestructura de redes, como los diagramas de las redes, la configuración de los equipos y bases de datos.

3. Obtener copias de los planes de recuperación de redes y de TI existentes; si no los hay, proceder con los siguientes pasos.

4. Identificar las amenazas contra la infraestructura de TI que la dirección considere más preocupantes: por ejemplo, incendios, errores humanos, apagones de energía, fallo de los sistemas.

5. Identificar aquello que la dirección considera que son las principales vulnerabilidades de la infraestructura: por ejemplo, inexistencia de sistemas de respaldo en caso de apagón eléctrico, copias de bases de datos obsoletas.

6. Examinar el historial previo de apagones y disrupciones, y cómo fueron gestionados por la empresa.

7. Identificar los activos TI que la dirección considera de importancia crítica. Por ejemplo: centro de llamadas, granjas de servidores, acceso a internet.

8. Determinar el tiempo máximo de apagón eléctrico que está dispuesta a aceptar la dirección en caso de indisponibilidad de los equipos TI.

9. Identificar los procedimientos operativos que se utilizan actualmente para responder a los apagones críticos.

10. Determinar cuándo se probaron estos procedimientos para validar si siguen siendo adecuados o no.

11. Identificar el/los equipo/s de respuesta de emergencia para todas las disrupciones de la infraestructura crítica de TI; determinar su nivel de conocimientos y preparación para manejar los sistemas críticos, especialmente en casos de emergencia.

12. Identificar las capacidades de respuesta de los proveedores en casos de emergencia; si se han utilizado alguna vez; si funcionaron correctamente; cuánto paga la compañía por estos servicios; el estado del contrato de servicio; la existencia del acuerdo de nivel de servicio (SLA) y si se usa alguna vez.

13. Recopilar los resultados de todas las evaluaciones en un reporte de análisis de carencias que identifique lo que se está haciendo frente a lo que debería hacerse, con recomendaciones sobre cómo lograr el nivel requerido de preparación y las inversiones necesarias para ello.

14. Lograr que la dirección lea el repote y acuerde tomar las acciones recomendadas.

15. Preparar un plan de recuperación de desastres IT que cubra los sistemas y las redes esenciales de TI.

16. Realizar pruebas de los planes y activos de recuperación de sistemas para validar su operatividad.

17. Actualizar la documentación del plan de RD para que recoja los cambios efectuados.

18. Programar la próxima revisión/auditoría de capacidades de recuperación de desastres TI.

Aspectos clave a considerar al planificar la recuperación de desastres TI

Apoyo de la alta gerencia. Asegúrese de tener el apoyo de la alta gerencia a fin de lograr alcanzar los objetivos del plan.
Tomarse en serio el proceso de planificación de RD de TI. Aunque la recopilación y análisis de los datos para el plan de RD de TI puede llevar mucho tiempo, no es necesario que tenga docenas de páginas. Los plantes simplemente necesitan la información correcta, y esa información debería ser actual y precisa.
Disponibilidad de estándares. Entre los estándares relevantes que podemos usar a la hora de desarrollar los planes de RD de TI están los siguientes: NIST SP 800-34, ISO/IEC 24762 y BS 25777.
La sencillez es un grado. Es esencial reunir y organizar la información correcta.
Estudiar los resultados con las unidades de negocio. Una vez finalizado el plan de recuperación de desastres, debemos cotejar sus conclusiones con los líderes de las unidades de negocio para comprobar que nuestras premisas son correctas.
Flexibilidad. La plantilla sugerida en este artículo puede ser modificada en lo que sea necesario para conseguir nuestros objetivos.

Análisis de la plantilla del plan de RD de TI

A continuación, examinaremos el índice de la plantilla, señalando las cuestiones clave a tratar y las actividades a desarrollar.

1. Declaración de intenciones del departamento de TI — Marca la pauta y dirección del plan.

2. Declaración de políticas — Es muy importante incluir una declaración aprobada con las políticas relativas a la provisión de servicios de recuperación de desastres.

3. Objetivos — Principales metas del plan.

4. Información de contacto del personal clave — Muy importante tener la información clave de contacto cerca del comienzo del plan. Es la información más susceptible de ser utilizada de inmediato y debería ser fácil de ubicar.

5. Visión general del plan — Describe los aspectos básicos del plan, como la actualización.

6. Respuesta de emergencia — Describe lo que hay que hacer inmediatamente en caso de incidente.

7. Equipo de recuperación de desastres — Miembros y datos de contacto del equipo de RD.

8. Alerta de emergencia, escalada y activación del PRD — Pasos a seguir en las primeras fases del incidente hasta que se activa el plan de RD.

9. Medios — Consejos para tratar con los medios de comunicación.

10. Seguro — Resume la cobertura de seguros asociada con el entorno TI y otras políticas relevantes.

11. Cuestiones legales y financieras — Acciones a tomar para administrar las cuestiones legales y financieras.

12. Ejecución del PRD — Subraya la importancia de ejecutar el plan de recuperación de desastres.

13. Apéndice A — Plantillas del plan de recuperación de desastres tecnológicos — Plantillas modelo para una variedad de recuperaciones por incidentes tecnológicos; es útil tener disponible la documentación técnica de algunos proveedores selectos.

14. Apéndice B — Formularios recomendados — Formularios listos para usar que ayudarán a facilitar la finalización del plan.

Teniendo en cuenta las inversiones que las empresas realizan en infraestructuras TI, sería conveniente que inviertan también tiempo y recursos para proteger dichas inversiones de acontecimientos no previstos y potencialmente destructivos.

Articulos Relacionados

Acerca del autor: Paul Kirvan, CISA, CISSP, FBCI, CBCP, tiene más de 20 años de experiencia en gestión de continuidad del negocio como consultor, autor y educador. Además, es secretario del Instituto de Continuidad del Negocio, capítulo de EE.UU.

Fuente: Search Data Center

Informe e Indice de Riesgo de Privacidad (PRI)

marzo 25, 2013 § Dejar un comentario

A medida que avanza el trabajo portátil, la información corporativa ya no se queda sólo en la empresa y comienza a ser móvil también. Por eso, se vuelve clave contar con políticas que permitan dar movilidad pero sin perder el control de la información.

Hoy la seguridad de los datos almacenados en soportes informáticos está en un punto de quiebre. Organizaciones de todo tipo y de ámbitos diferentes se ven obligadas a tomar medidas que garanticen el cuidado de datos valiosos tanto de su compañía como de sus clientes. Los incidentes relacionados con la privacidad provocan pérdidas de dinero, clientes, interrumpen el negocio y afectan la reputación de las compañías.

Para entender el nivel de riesgo que afrontan las compañías y cómo se preparan para enfrentarlo, la consultora Edelman en colaboración con el Instituto Ponemon, desarrolló el Índice de Riesgo de Privacidad (PRI) [Presentación en Slideshare].

Se trata de un estudio que incluye la opinión de 6.400 ejecutivos, analistas de riesgos, privacidad y profesionales tecnológicos de 29 países, incluyendo la Argentina.

Este documento revela que el 57% de las empresas no ven la protección de los datos personales y la privacidad como prioridades.

A su vez, los profesionales reconocen que hay una falta de preparación frente a los potenciales daños vinculados con la pérdida o mal uso de la información personal, ubicando al riesgo de seguridad respecto de la privacidad en un máximo histórico en todas las industrias.

Junto a este informe, Edelman presentó una herramienta gratuita que permite a las empresas de todos los tamaños encontrar su índice de riego de privacidad frente a firmas similares.

Fuente: iProfesional

Fugas de información en la empresa y controles

marzo 23, 2013 § Dejar un comentario

Hoy vamos a hablar de uno de los problemas más serios y difíciles de tratar que puede haber en entornos que manejen información delicada, como puedan ser expedientes médicos o tarjetas de crédito (hospitales y bancos, por poner dos ejemplos): las fugas de información.

En cualquier empresa, una de las cosas más claras que debe tener el equipo de seguridad es qué es lo que debe proteger, cuál es la información realmente crítica de la empresa. Esta puede ser:

patentes
información personal delicada (marcada como “nivel alto” según la LOPD), como por ejemplo expedientes médicos
contratos con terceros, nóminas, currículums de empleados
números de tarjeta de crédito, operaciones bancarias en general.

Cualquier empresa, por pequeña que sea, tiene información que no desea que llegue a sus competidores.

El robo, y posterior venta, de datos confidenciales de una empresa se debe principalmente a dos cosas: venganza y motivos económicos. Un empleado resentido puede ser la herramienta perfecta para robar contratos de una empresa y pasárselos a una competencia.

Así pues, en primer lugar, debemos tener claro qué estamos protegiendo y, a partir de allí, tomar las medidas técnicas adecuadas para prevenir el robo de información. Estas medidas abarcarian distintas ramas:

A- ALGUNOS PROBLEMAS DE SEGURIDAD EN LAS EMPRESAS

SEGURIDAD FÍSICA

Aquí entrarían temas como el control de acceso al edificio, cerraduras en todas las puertas, cámaras de video vigilancia, extintores, uso de materiales ignífugos en suelos y techos, salidas de emergencia, concesión y revocación de tarjetas de acceso, tornos para controlar el acceso de los empleados de uno en uno … y cualquier otra cosa de ésta índole que evite el robo o pérdida por accidente (incendio, terremoto, …) de la información clave de la empresa.

Hay que hacer especial hincapié en controlar el acceso físico a todos los datos críticos de la empresa, separándolos de los demás y permitiendo sólo su acceso a las personas responsables de ellos, siempre de una forma controlada y guardando un escrupuloso registro de cada acceso.

Respecto de la seguridad física, resultan realmente preocupantes cosas como éstas:

(1) Cabe mencionar que, hoy en día, en casi todas las empresas no sería ningún problema instalar un keylogger por hardware en el teclado y recogerlo días después . Como veis en éste esquema, no son nada fáciles de detectar a simple vista

(2) Nada más fácil que darse una vuelta por la sala de reuniones y dejarles un micrófono instalado. En particular éste que pongo debajo es batante caro, pero los hay muy asequibles.

(3) Huelga decir que un simple pendrive es más que suficiente para llevarse bases de datos en segundos.

SEGURIDAD LÓGICA

Esto es lo que uno entiende por “seguridad” cuando habla de servidores, bases de dato, … Una buena seguridad lógica debe controlar aspectos como una buena gestión de usuarios, hardening de los servidores, política de mantenimiento y parcheado de los servicios, topología de red, restricción de permisos …

COPIAS DE SEGURIDAD

Un error muy típico en las empresas pequeñas es guardar las copias de seguridad de todas las bases de datos en un cajón sin cerradura, encima de un armario o en la mesa del administrador de la red, donde resulta facilísimo llevárselas a casa, copiarlas y volverlas a dejar en su sitio.

No tiene ningún sentido establecer unos durísimos controles de seguridad lógica si luego dejamos los backups tirados encima de un armario.

Como poco, las copias de seguridad deberían estar en un armario ignífugo cerrado, dentro de un despacho también cerrado. Debería hacerse un rigurosísimo control del acceso a las mismas. También es conveniente que estas copias no estuvieran en el mismo edificio que los servidores de la empresa, ya que pudiera haber una catástrofe (incendio, inundación) y se perderían tanto la copia como el original.

Algunas empresas tienen el centro de backup en otra ciudad y graban los datos síncronamente a través de líneas dedicadas.

Otro concepto importante a mencionar en este punto es la continuidad de negocio. Esto viene a ser un plan a seguir ante un desastre natural – pongamos que se quema el edificio. Debe existir un plan detallado que cubra el procedimiento a seguir para levantar el servicio (reinicio de servidores, en qué órden, cabinas de discos, comunicaciones, …) y deben hacerse unas pruebas anuales de dicho plan, con su correspondiente informe. Todo esto lo piden en auditorías como la que hacen para la LOPD.

MOVILIDAD DE USUARIOS

En un mundo globalizado, donde nuestros usuarios se conectan con sus portátiles al CPD, cualquiera, desde cualquier lugar del mundo, puede estar robándonos datos.

Debe existir un estricto control de quién puede conectarse y con qué medios. Debe garantizarse que lo hagan desde un sistema operativo que cumple unos requisitos (firewall, antivirus, parches de seguridad, …),que se valida el usuario de forma segura (certificado + usuario/password), que todos los protocolos de conexión van cifrados.

Pero el problema es que el usuario, desde casa, puede pinchar un pendrive y copiarse toda la información sin dejar casi ningún rastro. Así pues, ante la posibilidad casi nula de controlar lo que hace el usuario, debemos hacer que firme una política de buen uso, donde se especifique la limitación del uso de los equipos de conexión al trabajo, etc, etc …

Aparte de poner difícil que nos roben, nuestra preocupación debería ser que siempre quede rastro de las acciones de los usuarios, y más en un entorno móvil, y tener las herramientas legales necesarias para empapelarle (léase política de buen uso).

REENVÍO DE FICHEROS POR MAIL

Clásico entre los clásicos. Todo usuario puede enviarse documentos por correo, y no habrá ningún tipo de rastro de lo que ha enviado si le pone un nombre cualquiera y lo envía comprimido con contraseña (como mucho el tamaño, y también puede comprimirse junto a otro archivo inútil para variarlo).

El acceso a los logs del servidor de correo no nos servirá de mucho en este caso.

B – AUDITORÍAS OBLIGATORIAS

Con objeto de reducir la posibilidad de un robo de información, las empresas tienen obligación de pasar auditorías obligatorias cada cierto tiempo. Entre ellas, hay dos que merecen mención especial: LOPD y PCI-DSS

La LOPD (Ley Orgánica de Protección de datos) se ocupa de velar por el derecho a la privacidad de las personas. Todas las empresas que manejen archivos (texto u ordenador) con datos personales tienen obligación de declarar estos archivos ante la AEPD (la Agencia de Protección de Datos) y de proteger dicha información. Como ejemplo de estos ficheros estaría el fichero de nóminas de la empresa y los historiales médicos de un hospital.

La auditoría de la LOPD se encarga de revisar el entorno en el que se encuentran dichos ficheros así como la existencia de controles adecuados para garantizar que esa información se trata de forma segura. Se miran cosas como los usuarios que tienen acceso, las políticas de renovación de usuarios, los accesos remotos a la empresa, la auditoría de accesos a dichos ficheros, la descripción de ficheros temporales (papel u ordenador) … y la existencia de una serie de procedimientos que describirían en detalle cómo se realizan todos estos puntos.

Las sanciones por incumplimiento de la LOPD son realmente duras.

Por otro lado, PCI-DSS se encarga de garantizar la seguridad de las operaciones realizadas con tarjetas de crédito. Esta auditoría trata de garantizar que todo punto por donde pasen tarjetas de crédito es seguro: seguridad física, cifrado de las comunicaciones, segmentación de la red, logs centralizados, gestión de usuarios y paswords, formación de empleados, existencia de WAPs, gestión de eventos de seguridad, detectores de intrusos, antivirus, … y un larguísimo etc de cosas.

La sanción por no pasar PCI-DSS es simplemente la retirada de los permisos de VISA, MASTERCARD, etc para procesar sus tarjetas (se les remite a ellos el resultado de la auditoría).

Desde luego, pasar estas auditorías no garantiza que nuestra información no será robada, pero al menos existe un estandard que seguir que pondrá las cosas mucho más difíciles.

Fuente: Hacking Avanzado

Crear un Centro de Respuesta a Incidentes (CSIRT)

marzo 20, 2013 § Dejar un comentario

Es sorprendente ver cómo la tecnología de la información se incorpora cada vez más a nuestras vidas, inclusive atravesando la última frontera. Algunas de las prestaciones de dispositivos, aplicaciones y sistemas de mayor desarrollo en la actualidad ingresan al interior de nuestro cuerpo con singular éxito: sondas, marcapasos, microelectrónica aplicada para la asistencia a personas con discapacidades auditivas o visuales, localización permanente de personas.

En la medida que los servicios de TI y los dispositivos se hacen más baratos, cercanos, difundidos y omnipresentes, la carencia o mal funcionamiento de alguno de ellos provoca impactos más altos y masivos.

Por ejemplo, los sistemas de prepago de celulares involucran a millones de personas y son lo suficientemente complejos como para tener interrupciones o demoras de forma periódica, siendo en general compleja la recuperación de los servicios.

¿Cuánto demora una comunidad de clientes de prepago en saber que el sistema está caído y (en algunas compañías) puede hablar sin límite? Es cuestión de segundos o minutos ¿Cuánto dinero e imagen pierde la compañía?, bastante. Lo peor es que estas pérdidas van en rápido ascenso debido a la masificación de los servicios.

Para dar este tipo de servicios, la complejidad de los equipamientos, redes y administradores de sistemas ha aumentado exponencialmente, por lo que diagnosticar la causa de una interrupción en un proceso de TI se está volviendo cada vez más complejo.

Un Centro de Respuesta a Incidentes de Seguridad Computacionales (CSIRT) es un equipo de técnicos especialmente entrenados para resolver y gestionar incidentes informáticos de alto impacto. Dicho entrenamiento provee capacidades al mencionado equipo para gestionar crisis, coordinar acciones, estar preparado para prevenir y detectar los ataques cibernéticos más comunes, así como para conocer profundamente las debilidades de sistemas, infraestructuras y personas de su organización. El objetivo es dar una efectiva y rápida respuesta a los incidentes que puedan ocurrir.

Dicho equipo es muy parecido a una brigada de bomberos, ellos deben entrenar en forma continua para poder controlar rápidamente los incidentes más comunes. Cuanto más rápidamente mitiguen al incidente, menos impacto sufrirá la organización.

Contenido completo en fuente original UNAM

Calculadora gratuita del tiempo de implementación para ISO 27001/ISO 22301

marzo 15, 2013 § Dejar un comentario

Este calculador le ayudará a estimar el tiempo necesario para su implementación de las normas ISO 27001 o ISO 22301. Como ambas normas presentan el mismo grado de complejidad, los factores que inciden en la duración de la implementación de ambas son similares; es por ello que usted puede utilizar este calculador para cualquiera de las dos.

Por favor, ingrese aquí los datos únicamente para el alcance de su SGSI (Sistema de gestión de seguridad de la información) o SGCN (Sistema de gestión de continuidad del negocio). Si el alcance no abarca a la empresa en su totalidad, no ingrese los datos como para toda la empresa. Por ejemplo, si su empresa tiene 1000 empleados, pero el alcance de la implementación incluye solamente a 30 empleados, su respuesta a la pregunta N.° 1 será “21 a 50”.

Cantidad de empleados

1 a 20
21 a 50
51 a 100
101 a 500
501 o más

Cantidad de departamentos

1 a 3
4 a 10
11 a 25
26 o más

Cantidad de ubicaciones físicas

1
2 a 5
6 a 20
21 o más

¿Ya ha implementado alguna otra norma como PCI DSS, ITIL, ISO 9001 o similar?

No.
Recién estamos comenzando a implementarla.
Solo está implementada formalmente, pero, en realidad, no funciona muy bien.
Está implementada y algo nos ha ayudado, aunque no tanto como debería.
Sí, la norma está implementada y se le realizan tares de mantenimiento y mejoras regularmente.

¿Utilizará un consultor o algún otro especialista en ISO 27001 o ISO 22301 interno o externo?

No.
Solamente para algunas partes del proyecto.
Para todo el proyecto.

¿Utilizará plantillas de documentación para sus políticas, procedimientos, planes, formularios, etc.?

No.
Solamente para algunos documentos.
Utilizaremos el Paquete de documentación completo.

¿Tiene algún empleado que se encargue de coordinar y gestionar este proyecto?

No, no tendremos a nadie a cargo del proyecto; las tareas se determinarán según sea necesario.
Sí, una persona con poca experiencia en gestión de proyectos, y cuando tenga tiempo libre.
Sí, una persona con experiencia en gestión de proyectos, aunque está bastante ocupada.
Sí, un experimentado gerente de proyectos, con tiempo dedicado a este proyecto.

¿Cuenta con el apoyo de la alta gerencia para este proyecto?

No, este proyecto comenzará como una iniciativa de niveles inferiores.
En teoría sí, pero la gerencia no comprende que deberá participar e invertir recursos.
Sí, la gerencia tiene objetivos claros y es consciente del compromiso necesario.

Cantidad estimada de meses necesarios para la implementación:

Tenga en cuenta que esta estimación se calcula en función de una carga de trabajo normal para la implementación; es decir, que la implementación se realiza a un ritmo que no requiere que los empleados deban trabajar durante muchas horas extras.
Es posible ejecutar este tipo de proyectos en menor tiempo que el que muestra la estimación, pero implicaría descuidar algunos otros proyectos y haría que la tensión para el equipo de implementación sea mucho mayor.

Fuente: ISO 27001 Standard