Mostrando entradas con la etiqueta Gobierno de la Informacion. Mostrar todas las entradas
Mostrando entradas con la etiqueta Gobierno de la Informacion. Mostrar todas las entradas

16 de febrero de 2011

Controles de Seguridad en la nube.

¡Buenos días!, hoy os traigo un pequeño documento que puede ser las delicias de muchos consultores de seguridad. Seguramente en vuestra empresa también estén migrando “a la nube”, no precisamente por que la gente esté en la parra, sino que por que es una moda tecnológica con consabidos beneficios económicos y de rendimiento que no analizaré. El problema es como adecuar la seguridad de nuestros sistemas tradicionales a la nube, ¿cómo debo modificar mis controles de seguridad?, ¿Qué nuevos requisitos debo considerar?, bueno los análisis más simplistas dirán “todo es igual” solo que virtualizado, aplica los mismos controles que tenías antes, eso nos puede dejar medianamente satisfechos pero no es del todo cierto. Para que lo comprobéis os dejo este Excel que, aunque se queda a muy alto nivel, os puede ser de mucha utilidad. Os explico por qué:

Control DG-07

“Security mechanisms shall be implementd to prevente data leakage”.

Áreas de Implementación:

SaaS, IaaS, PaaS, Service Provider

  • COBIT à COBIT 4.1 DS 11.6
  • ISO/IEC 27001:2005 à A.10.6.2, A.12.5.4
  • NIST à NIST SP800-53 R3 AC-2, NIST SP800-53 R3 AC-3, NIST SP800-53 R3 AC-4, NIST SP800-53 R3 AC-6, NIST SP800-53 R3 AC-11, NIST SP800-53 R3 AU-13, NIST SP800-53 R3 PE-19, NIST SP800-53 R3 SC-28, NIST SP800-53 R3 SA-8, NIST SP800-53 R3 SI-7
  • PCI-DSS à PCI DSS v2.0 3.1, PCI DSS v2.0 3.1.1, PCI DSS v2.0 3.2, PCI DSS v2.0 9.9.1, PCI DSS v2.0 9.5, PCI DSS v2.0 9.6, PCI DSS v2.0 10.7

En la lista de 100 controles propuestos, mapeados con diferentes dominios (que no coinciden con los de la ISO 27000, aunque son parecidos), te indica donde es obligatorios que lo implantes si quieres cumplir a su vez con los controles del resto de normativas o estándares de referencia. Por tanto desde el punto de vista del Gobierno de la Información así como de garantizar el cumplimiento con las distintas auditorías este Excel que tan bien se ha trabajado la Cloud Security Alliance puede ser el maná.

Salu2

PD: No dejéis de ver otros documentos como la guía de la nube o las amenazas sobre esta (por ejemplo, que los chinos te bombardeen para sacarte el agua).

16 de agosto de 2010

Payment Card Industry Data Security Standard v2

Buenos días,

Para empezar la semana una de evolución normativa / regulatoria. En Octubre se va a publicar la siguiente versión del estándar de seguridad de la industria de pago con tarjeta (la del dinero de plástico, vamos), algunos cambios ya se han adelantado a alto nivel, los cuales os pego por aquí. Todo ello dentro de un ciclo de vida que se ha extendido de 2 a 3 años, más acorde con los criterios de madurez en el gobierno de la información actuales:

Requirement Impact

Reason for Change

Proposed Change

Category

PCI DSS Intro

Clarify Applicability of PCI DSS and cardholder data.

Clarify that PCI DSS Requirements 3.3 and 3.4 apply only to PAN.

Align language with PTS Secure Reading and Exchange of Data (SRED) module.

Clarification

Scope of Assessment

Ensure all locations of cardholder data are included in scope of PCI DSS assessments

Clarify that all locations and flows of cardholder data should be identified and documented to ensure accurate scoping of cardholder data environment.

Additional Guidance

PCI DSS Intro and various requirements

Provide guidance on virtualization.

Expanded definition of system components to include virtual components.

Updated requirement 2.2.1 to clarify intent of “one primary function per server” and use of virtualization.

Additional Guidance

PCI DSS

Requirement 1

Further clarification of the DMZ.

Provide clarification on secure boundaries between internet and card holder data environment.

Clarification

PCI DSS

Requirement 3.2

Clarify applicability of PCI DSS to Issuers or Issuer Processors.

Recognize that Issuers have a legitimate business need to store Sensitive Authentication Data.

Clarification

PCI DSS

Requirement 3.6

Clarify key management processes.

Clarify processes and increase flexibility for cryptographic key changes, retired or replaced keys, and use of split control and dual knowledge.

Clarification

PCI DSS

Requirement 6.2

Apply a risk based approach for addressing vulnerabilities.

Update requirement to allow vulnerabilities to be ranked and prioritized according to risk.

Evolving Requirement

PCI DSS

Requirement 6.5

Merge requirements to eliminate redundancy and Expand examples of secure coding standards to include more than OWASP.

Merge requirement 6.3.1 into 6.5 to eliminate redundancy for secure coding for internal and Web-facing applications.

Include examples of additional secure coding standards, such as CWE and CERT.

Clarification

PCI DSS

Requirement 12.3.10

Clarify remote copy, move, and storage of CHD.

Update requirement to allow business justification for copy, move, and storage of CHD during remote access.

Clarification

PA DSS

General

Payment Applications on Hardware Terminals.

Provide further guidance on PA-DSS applicability to hardware terminals.

Additional Guidance

PA-DSS

Requirement 4.4

Payment applications should facilitate centralized logging.

Add sub-requirement for payment applications to support centralized logging, in alignment with PCI DSS requirement 10.5.3.

Evolving Requirement

PA-DSS

Requirements

10 & 11

Merge PA-DSS Requirements 10 and 11

Combine requirements 10 and 11 (remote update and access requirements) to remove redundancies.

Clarification


Esto se traducirá en Objetivos de Control, Controles y requisitos de seguridad. Hay cosas curiosas como no basarse solo en OWASP para los test de intrusión de aplicaciones web, gestión del ciclo de vida de claves criptográficas, mayor separación de capas y clara definición de las DMZ, etc.

Habrá que estar atentos en los próximos meses. Más información aquí.

5 de febrero de 2010

Cursos de Seguridad gratuitos

Un año más el CEIM ha publicado su lista de cursos disponibles para formación en este 2010, al igual que ocurría en el 2009 son varios los cursos centrados en Seguridad de la Información, los más interesantes son los siguientes:


1.Conceptos TCP/IP.
1.1.Pila de protocolos TCP/IP.
1.2.Direccionamiento.
1.3.Sockets.
2.Hacking Ético.
2.1.Rol de un Hacker Ético.
2.2.Qué puedes realizar dentro de la legalidad.
2.3.Qué no se puede realizar dentro del marco de la legalidad.
2.4.Actividades previas a la realización de un ataque.
2.5.Escaneos ( herramientas Sam Spade, SuperScan).
3.Tipos de ataques.
3.1.Ataques de DoS (Smurf, SYN FlOOD, Detour, DDOS.).
3.2.Ataques de reconocimiento Prácticas con wireshark.
3.3.Ataques de Spoofing (Replay, Man in the Middle, TCP Hijacking).
3.4.Código Malicioso (Virus, Troyanos y Gusanos).
4.Mecanismos de Protección.
4.1.Introducción y configuración del Firewall PIX.
4.2.Zonas desmilitarizadas.
4.3.Securización con IPS.
4.4.Identificación de equipos conectados a las red (NAC).
5.Securización de equipos de red.
5.1.Seguridad en dispositivos Cisco.
5.2.Deshabilitar Servicios de Red e Interfaces no empleadas.
5.3.Configuración correcta de los protocolos de gestión.
5.4.Mitigación de ataques con ACL.
5.5.Mitigación de ataques de Nivel 2.
6.Redes privadas virtuales.
6.1.Protección a nivel de transporte SSL, TLS.
6.2.Protección a nivel de red IPSEC.
7.AAA.
7.1.Qué es la Autenticación. Métodos de Autenticado.
7.2.Qué es la Autorización.
7.3.Qué es la Auditoria.
8.Buenas Prácticas y resumen.


Módulo 1. Gestión de la seguridad y de los riesgos.
1.1. Objetivo de la seguridad.
1.2. Plan de implantación. Amenazas.
1.3. Atacante externo e interno.
1.4. Tipos de ataque.
1.5. Mecanismos de protección.
1.6. Proceso de gestión de riesgos.
1.7. Métodos de identificación y análisis de riesgos.
1.8. Reducción del riesgo.

Módulo 2. Seguridad Física y lógica del sistema.
2.1. Protección del sistema informático.
2.2. Protección de los datos.
2.3. Sistemas de ficheros.
2.4. Permisos de archivos.
2.5. Listas de control de acceso (ACLs) a ficheros.
2.6. Registros de actividad del sistema.
2.7. Autentificación de usuarios.

Módulo 3. Acceso remoto al sistema.
3.1. Mecanismos del sistema operativo para control de accesos.
3.2. Cortafuegos de servidor.


1.Objetivos de la seguridad en el sistema de información.
2.Sistema de seguridad robusto: RSN.
3.Métodos de autentificación.
3.1.EAP
3.2.IEEE 802.1X.
3.3.RADIUS.
3.4.Protocolo IEEE 802.11i.
4.Arquitectura.
5.Jerarquía de claves.
5.1.RC4
5.2.TKIP
5.3.AES
5.4.CCMP
6.Cifrado de los datos
6.1.RC4-TKIP
6.2.AES-CCMP

También hay cursos más orientados a la gestión de la seguridad como IT Gobernance o ITIL v3. Si estáis pensando en reciclar conocimientos no dudéis en solicitar estos cursos gratuitos que, por otra parte, los pagamos todos con un pequeño porcentaje de nuestro salario.

Volvemos pronto, ¡Salu2!

22 de enero de 2010

Metricas Seguras

Cumplidas las tres primeras semanas del año en muchas empresas la cúpula directiva se sienta, prepara los proyectos del 2010 y entre otras muchas preguntas, a los que nos dedicamos a la seguridad nos dicen, “bueno, ¿cómo estamos este año?, ¿hemos mejorado en seguridad?, ¿se ha invertido suficiente?, ¿estamos mejor que la competencia?”

Desde que la seguridad dejó de ser una asignatura pendiente a convertirse en un “must do it” ya sea por requisitos legales, por que tus servicios han tenido verdaderos problemas para ofrecerse con normalidad o por que se ha visto oportunidad de negocio la inversión en la misma se ha parecido a la siguiente gráfica:

Retorno de la Inversión en Seguridad

Muy propia de aquellos campos donde la incertidumbre es alta, o dicho de otra forma, donde la madurez del gobierno de la información es baja. Más inversión solo puede significar a ojos de la dirección más seguridad o más negocio o ambas, y nunca se entenderá otra cosa (como es lógico). De ahí que ante las preguntas de ¿como estamos este año? Tengamos que presentar unos datos que si no hemos hecho los deberes parecerán magia borras. Si, estamos hablando de METRICAS DE SEGURIDAD.

When you can measure what you are speaking about, and express it in numbers, you know something about it; but when you cannot measure it, when you cannot express it in numbers, your knowledge is a meager and unsatisfactory kind; it may be the beginning of knowledge, but you have scarcely, in your thoughts, advanced to the state of science.

—William Thomson, Lord Kelvin, 1883

Esta acertada frase de William Thomson (quien por cierto, jamás vio un ordenador) viene a decirnos, si tu conocimiento sobre una materia es tal que lo puedes expresar en cifras, entonces es que sabes algo, pero si no puedes medir aquello de lo que estás hablando entonces te queda mucho por aprender,,, perfecto. ¿Como medimos un concepto tan abstracto como la seguridad?, ¿por número de ataques?, ¿por número de incidentes de seguridad?, ¿como sabrá nuestra dirección si está invirtiendo bien? Es necesario caracterizar nuestras métricas:

1.- ¿Cuál es el objeto a medir? → Nivel de conformidad LOPD (atributo) de un sistema (objeto), grado de riesgo de mis sistemas, etc.
2.- ¿Por qué quiero medir ese objeto?, ¿cuál es la necesidad? → Tenemos un mayor control sobre mis servicios, mejorar la gestión de la seguridad, etc.
3.- ¿Con respecto a qué voy a medir? → Toda métrica necesita de un objeto contra el que comparar, por ejemplo, un estándar de buenas prácticas, los controles de mi Normativa, etc.

Es imprescindible que lo que se mida sea importante, y no solo eso, sino que los datos que nos muestren las mediciones sean significativos, teniendo claros estos principios y una vez identificados los tres puntos básicos, podemos abordar otros asuntos propios del proceso, qué método voy a utilizar para obtener esos datos (entrevistas, auditorías, obtención de logs, etc.), cada cuanto tiempo voy a recoger los datos (muchos datos pueden generar ruido, pocos datos inexactos), responsables de proporcionar los datos, personal involucrado, etc.

Como veis, una tarea cuanto menos ardua. Es parte imprescindible de un Sistema de Gestión de la Seguridad de la Información (SGSI) disponer de esta serie de datos (indicadores) que te diga como estás en lo que a seguridad se refiere, hasta hace unos años esto no estaba siquiera regulado, por suerte con la serie 27000 de ISO apareció la 27004. Este será nuestro cuaderno de consulta obligatorio si este año no hemos hecho los deberes y tenemos que decir, ¡estamos mejor que el año pasado! Mientras cruzamos los dedos por detrás y esperamos que no pase nada y haber sido convincentes :-p

Una vez que empezamos a recoger esos valiosos indicadores, sabemos el grado en que vamos cumpliendo con los objetivos estratégicos surge el concepto de “Cuadro de Mando”, que no es más que una herramienta para poder tener en todo momento una foto del estado de la seguridad y del grado de cumplimiento con respecto a los objetivos a medio y largo plazo.

Esta entrada es un pequeño resumen y recordatorio de lo que hace 3 años se homologó y regularizó dentro de la serie 27000, curiosamente en la actualidad surge con fuerzas renovadas dada la necesidad imperiosa de producir con eficiencia. Nuestros jefes, gerentes y directores ya saben que hay que invertir en seguridad (lo ven en las noticias a diario), pero también quieren saber que lo están haciendo bien.

Sin duda un campo muy interesante.

Salu2!

17 de enero de 2010

Beautiful Security

Lo primero es lo primero, bienvenidos 1 añito después a todo es seguro (all is sec, como dicen mis colegas), espero que al igual que yo estéis descansados y con ganas de leer cositas interesantes, desde aquí trataré de aportar mi granito de arena.

Comenzamos esta nueva temporada con un libro, y no va a ser el único ya que inauguro una nueva categoría, “Libros Seguros”, donde os contaré un poquito lo que aporta la literatura de la Seguridad Informática (de ayer y hoy) y qué libros son “must read” y cuales no tanto.

Beautiful Security no es un libro para hackers, ni siquiera puede serlo para consultores de seguridad o informáticos. Es un libro para quien puede estar dudando sobre si trabajar en Seguridad de la Información (¿merece la pena, no la merece?, ¿me dedico a otras áreas?) o para aquel que trabajando dentro de Seguridad (como consultor, auditor, hacker, comercial, etc.) se encuentra desencantado y siente que su trabajo es duro, agotador, que tapa un agujero y le salen 10 más, que discute y discute con otras áreas tratando de concienciar en vano. Es un libro bonito, que ayudará a ver a través de otros ojos la belleza de esta profesión. Un must read.

El libro se divide en 16 capítulos, el orden no tiene mucho sentido ya que son independientes, cada uno está escrito por un experto distinto en seguridad que va desde los creadores de PGP o L0pthcrack hasta profesores de Harvard y cada uno aborda un tema distinto explicando brevemente el estado del arte, qué no funciona, qué habría que mejorar y hacia donde avanza la Seguridad en ese campo, casi todos los capítulos aportan alguna idea refrescante donde muchas veces diréis, ¡ey!, esto no se me había ocurrido:

1.- Psychological Security Traps: El nombre es muy descriptivo, el creador de L0pthcrack cuenta como se le ocurrió la idea, cómo se revolucionó el gobierno americano y cómo pasó a estar sentado con los principales responsables de seguridad del estado tras hacer esta herramienta.
2.- Wireless Networking: Fertile Ground for Social Engineering: Probablemente estéis aburridos de seguridad wifi, en este capítulo se puede ver como un problema de seguridad inalámbrica originó el mayor robo de tarjetas de crédito de la historia (en un principio 30 millones, hoy se estima que fueron más de 100), el caso de TJX.
3.- Beautifull Security Metrics: Un soplo de aire fresco en el siempre complicado mundo de las métricas de seguridad, una analogía con la sanidad nos muestra que no somos los únicos con ese problema y como ellos lo resolvieron.
4.- The underground economy of security breaches: Aquí veremos con cifras y letras lo que mueve la industria del mal, la complejidad de las botnets, etc.
5.- Beautiful Trade: Rethinking E-Commerce Security: Análisis de los sistemas de comercio electrónico actuales y las operaciones que implica comprar por internet, propone un sistema de comercio electrónico alternativo.
6.- Securing Online Advertising: Rustlers and Sheriffs in the New Wild West. ¿Qué ocurre en ese mundo que sustenta Internet, llamado publicidad?, ¿podemos fiarnos?, ¿pueden infectarnos?, ¿es legal la publicidad engañosa? Aquí responderemos todas estas cuestiones.
7.- The Evolution of PGP's: Web Of Trust. El creador de PGP nos cuenta como funciona y qué aspectos siguen siendo problemáticos. Por ejemplo, la caducidad de las firma de una clave.
8.- Open Source Honeyclient: Proactive Detection of Client-side exploits. El creador del primer honeyclient cuenta como se le ocurrió la idea y cómo utilizó este software junto con tripware para evaluar la seguridad de visitar una página web.
9.- Tomorrow's Security Cogs and Levers: Este capítulo aborda la seguridad en la nube y los webservices. Quizás uno de los más flojos del libro.
10.- Security by Design: Todos sabemos que abordar la seguridad en las fases tempranas de un proyecto supone un importante ahorro con respecto a futuros cambios y vulnerabilidades.
11.- Forcing Firms to Focus: Is Secure Software in Your Future. ¡Un sistema debe ser seguro igual que una hamburguesa debe estar caliente! Esa frase creo que explica muchas cosas, aunque aquí viene otra de impacto: “Los mejores desarrolladores del mundo crean código vulnerable” Este capítulo es una continuación del anterior, se muestra el caso de una empresa de desarrollo (de nombre ficticio ACME) que realmente incorporó este atributo y de cómo ahorró tiempo y dinero aumentando la calidad de sus productos.
12.- Oh No, Here Come the Infosecurity Lawyers. Los abogados junto con la alta dirección son los mejores amigos de un experto en Seguridad, en este capítulo muestra leyes americanas, si las sustituimos por las españolas (o las que os apliquen) veremos como obtener un fuerte respaldo a nuestros requisitos.
13.- Beautifull Log Handling. El sistema de logs puede ser un auténtico problema, crear logs que proporcionen datos importantes, que sean válidos, que no den demasiada información ni tampoco eliminen la necesaria puede ser un quebradero de cabeza. La falta de estándares al respecto es un verdadero problema, pero incluso con el se pueden realizar análisis forenses con éxito.
14.- Incident Detection: Finding the other 68%. Este capítulo no me convenció mucho, asume que solo el 32% de las amenazas y ataques son detectados por nuestros antivirus, IDS, etc. y da ciertas soluciones para aumentar ese ratio. Nada nuevo para los tiempos que corren.
15.- Doing Real Work Without Real Data: Este capítulo presenta el caso de las bases de datos translúcidas, un interesante concepto sobre el que habrá que profundizar. Must read.
16.- Casting Spells: PC Security Theater. Un análisis de las tradicionales soluciones de seguridad y sus fallos, muestra la tendencia actual a unificar sandboxes (virtualización) + chequeo de firma antivirus + análisis de amenaza por inteligencia artificial.

Y con esto cerramos Beautiful Security, 300 páginas para refrescar tu visión de la Seguridad Informática :)

Salu2!

24 de octubre de 2009

Sello Europeo de Privacidad

El proyecto para definir un programa de certificación de productos en lo que a seguridad y protección de datos a nivel europeo se refiere está a punto de terminar. A grandes rasgos este proyecto establece un proceso de certificación para que cualquier entidad que trabaje con sistemas o servicios que traten datos de carácter personal pueda certificar los mismos (sea una aplicación, sea un producto hardware, etc.), con un sello de confianza reconocido dentro de la Unión Europea, este proceso de certificación incluye:

- Evaluación del producto por expertos jurídicos.
- Auditoría del producto por expertos TI.
- Informe de conformidad con los criterios de evaluación del catálogo de criterios europeos.
- Aceptación del producto bajo el sello de privacidad europeo.

Como os podeis imaginar la definición y puesta en vigor del European Privacy Seal (Europrise) supondrá un valor añadido al que muchas empresas querrán subirse para certificar sus productos y servicios, exactamente igual como ya ocurrió con la ISO 9000 de calidad. En España el informe de auditoría y evaluación del producto técnica y legal será revisado por la Agencia de Protección de Datos de la Comunidad de Madrid, quien por ahora es la única entidad nacional que puede homologar el Europrise.

En la llamada "Sociedad de la Información" donde la penetración de las tecnologías en los ciudadanos es cada vez mayor, es absolutamente necesario la presencia de un producto como este que proporcione confianza a los ciudadanos en el uso de las TIC. Por si a alguien le quedan dudas por aquí tenéis el último barómetro de la Agencia Española de Protección de Datos de Septiembre 2009, en el figuran los siguientes datos:

- El 46% no conoce de la existencia de la AEPD.
- El 43% le preocupa bastane la protección de datos y el uso por terceras personas, al 30% mucho.
- El 56% considera que la privacidad de sus datos en Internet es baja o muy baja.
- Al 77% le da poca seguridad dar su número de tarjeta de crédito por Internet para hacer sus compras.

Contra estas cifras iniciativas como el Europrise son de agradecer, no obstante nunca podemos dejar las necesarias campañas de Sensibilización y Formación al ciudadano en lo que al buen uso y seguridad de Internet se refiere.

Si queréis profundizar en este tema el 3 de Noviembre se va a dar un seminario en la Casa de Correos en Madrid, la entrada es gratuita, solo limitada al número de plazas.

Buen fin de semana :)

26 de agosto de 2009

De la importancia de Ofuscar

Este Software no arranca ni a la de 3.
Respuesta: Espera un momento que levante el capó y vemos el código.

A raíz de alguna de las entradas que Eduardo Abril publicó sobre ofuscación de exploits javascript y php recordé que una vez me bajé un interesante juego de cartas (bastante adictivo, añado) el cual exigía 10 eurazos por poder disputar las partidas completas, sino se te cortaban a la mitad de forma “casi” aleatoria.

Ni corto ni perezoso y dado que la interfaz me era familiar indagué, volví a indagar y descubrí que era un Visual Basic 6.0, la cosa me sonaba mucho así que me dije este código se puede de-compilar de un plumazo, y ahí está:

Visual Basic decompiler es una sencillísima herramienta de las muchas que hay para decompilar código, este caso en Visual Basic. Da igual que trabajeis con C#, C++, Java o php, salvo que el código esté protegido será posible sacarlo. Esto es especialmente problemático en Software distribuido como cliente pesado y si no es bien atajado surgen cracks como setas, solo hay que tener paciencia repasar el código… en este caso encontré que la casilla de introducción de clave del producto era un textbox donde se apilaba su valor y se invocaba a otra librería bien conocida:

….

loc_0096942B: call msvbvm60.dll.__vbaFreeVar

loc_0096942D: lea edx, var_24

loc_00969430: push 00430D74h ; "clave"

loc_00969435: push edx

loc_00969436: call 00925A50h

…

Las librerías también pueden ser de-compiladas, por lo que ya fue coser y cantar. Este pequeño ejemplo debe hacernos valorar si es necesario revisar el ciclo de vida de nuestros proyectos para implementar estos requisitos de seguridad, liberar un producto sin ofuscar puede ser una piedra lanzada contra nuestro propio tejado.

Un sector que tiene gran experiencia en este tema es el de los videojuegos, donde muchas empresas se han decantado por obligarte a “autenticarte” contra sus servidores cada vez que inicias el juego (aunque no juegues por Internet), es el caso de Half Life 2 o el futuro Command & Conquer 4.

Salu2

14 de agosto de 2009

NIST: Security Controls for Information Systems

“…Through the process of risk management, leaders must consider risk to US interests from adversaries using cyberspace to their advantage and from our own efforts to employ the global nature of cyberspace to achieve objectives in military, intelligence, and business operations… “

“…For operational plans development, the combination of threats, vulnerabilities, and impacts must be evaluated in order to identify important trends and decide where effort should be applied to eliminate or reduce threat capabilities; eliminate or reduce vulnerabilities; and assess, coordinate, and deconflict all cyberspace operations…”

“…Leaders at all levels are accountable for ensuring readiness and security to the same degree as in any other domain…"

-- THE NATIONAL STRATEGY FOR CYBERSPACE OPERATIONS

OFFICE OF THE CHAIRMAN, JOINT CHIEFS OF STAFF, U.S. DEPARTMENT OF DEFENSE

De esta guisa están los americanos en lo que a seguridad en los sistemas de la información respecta. Hace unos días el NIST publicó un interesante documento (NIST Special Publication 800-53) que describe a grandes rasgos los principales controles de seguridad que empresas de todos los sectores (banca, salud, defensa, etc.) deberían implementar en sus sistemas de información si quieren eliminar o mitigar las múltiples amenazas que su uso generan. La publicación de este paper me llama particularmente la atención ya que apenas hace 3 meses Obama anunciaba a bombo y platillo la comisión de un cuerpo militar especializado para el ciberespacio liderado por el "cyberzar" (si bien el NIST lleva muchos años publicando documentos de Seguridad, este en concreto parece enfocado para los Estados Unidos).

El paper habla y habla sobre controles de seguridad, sus clases (técnicos, operacionales, de gestión, mixtos), a que familia se pueden asociar (a mi me ha dado la impresión de que eran subfamilias de los 11 grandes dominios de la ISO 17799 - ISO 27000), habla de la calidad de los controles, su ciclo de vida, su gestión e indicadores así como las tareas de día a día a las que hay que dar especial relevancia para que el “proceso de la seguridad” no se nos quede atrás:

- Evaluación de lo que los controles nos aportan (o nos dejan de aportar).

- Requisitos de seguridad cambiantes.

- Nuevas amenazas, vulnerabilidades y vectores de ataque.

- Nuevas tecnologías.

Todo ello con un único objetivo, gestionar el riesgo. Para ello proponen un proceso muy familiar:

Que incluye un punto bastante interesante, “la autorización de los sistemas de información”, esto significaría que no permitiríamos entrar en producción sistemas que carecen de controles de seguridad o que representan un nivel de riesgo no aceptable. Si, esto es tan lógico que no se cumple en casi ninguna organización, por eso me llama la atención.

En resumen un documento al que merece la pena echar un vistazo, si eliminamos los Anexos son apenas 60 folios y de los anexos los más interesantes son:

- Anexo F: Catálogo de Controles de Seguridad (amplísimo)

- Anexo I: Controles en Sistemas Industriales (controles de seguridad para sistemas SCADA, recomendable también)

Lecturas para la playita :)

14 de julio de 2009

Secure Updates

Es de conocimiento general que a pesar de las innumerables medidas de seguridad que aplicamos en servicios, bastionado máquinas, redes, etc. El estado de riesgo conseguido es solo momentáneo, de ahí el viejo dicho de “la seguridad es un proceso”. Como tal debe ser dinámico y adaptarse a las circunstancias del momento, eso también se incluye para las actualizaciones que aplicamos sobre el software con que trabajamos (esté en la capa que esté). Un correcto protocolo de actualización de software es vital en cualquier organización hoy en día, y a las pruebas me remito:

Esto que hoy ha ocurrido para una actualización de BlackBerry en Dubai podría representar que todos nuestros agentes comerciales (y unos cuantos Directores) con sus flamantes BB se quedasen sin teléfono durante varios días. ¿Está este riesgo contemplado en nuestro análisis de riesgos? Es probable que no para los teléfonos, pero si para nuestros servidores, workstation, dispositivos de red, etc.

La política de aplicación de parches es sin duda una de las más importantes para nuestros sistemas de información, si bien los informáticos tenemos tendencia a tener la “ultima moda” tendremos que controlarnos un poco, aunque eso signifique tener nuestros servicios expuestos unos días más a ciertas vulnerabilidades. Es importante mantener una horquilla de tiempo desde la publicación del parche hasta su aplicación, en ese tiempo tampoco debemos estar de brazos cruzados esperando que alguien reporte posibles problemas. Como administradores podemos aprovechar para probar las actualizaciones en entornos controlados, por ejemplo uno donde se Certifique que el cambio no provoca impactos no deseados en los servicios que soportan el sistema parcheado. Una vez que se certifica que la aplicación de un parche es segura (en todos los sentidos) hay que generar un proceso de gestión del cambio apoyado en nuestra Base de Datos de Gestión de la Configuración (CMDB) que contemple un proceso de marcha atrás en caso de que algún incidente no contemplado, de igual forma debe hacerse de forma escalada y controlada. En líneas generales, estas son algunas recomendaciones que no debemos olvidar:

- Todo el software debe estar inventariado.

- Debe existir una política de actualización y control de software.

- Las actualizaciones se obtendrán directamente desde el fabricante, nunca desde terceros.

- Todo parche y actualización debe ser probado en entornos controlados y aislados antes de su aplicación.

- En caso de que la aplicación de un parche genere un riesgo mayor que la exposición a las vulnerabilidades, no se aplicará. No obstante se deberán estudiar medidas compensatorias.

- Las actualizaciones se aplicarán de forma escalada y controlada.

- Se creará un procedimiento de marcha atrás.

Los parches y actualizaciones son importantes para mantener e incrementar el nivel de seguridad de nuestros servicios y sistemas, y al fin y al cabo de nuestro negocio. Pero también pueden ser un riesgo si no se aplican correctamente (ya sea por exceso o por defecto).

Actualizad con moderación! :-)

10 de julio de 2009

Sarbanex Oxley


Cuando hablamos de cumplimiento legal de los sistemas de información en España el 99% del tiempo estamos hablando de la Ley Organica de Protección de Datos (L.O.P.D.) y de la Ley de Servicios de Sociedad de Información y Comercio Electrónico (L.S.S.I.). Estas son las 2 leyes de mayor relevancia que rigen aspectos tan importantes como los derechos que los ciudadanos tienen sobre sus datos así como la forma en que deben realizarse las acciones comerciales por Internet con garantía y seguridad.

Sin embargo estas no son las únicas referencias al cumplimiento legal con las que los Consultores debemos tratar en nuestro día a día. En un mundo global con relaciones comerciales globales y empresas multinacionales no debemos descuidar la legislación de aquellos otros países en los que operamos. Por ejemplo, dentro del mundo de la banca existe un estándar bajo el que deben regirse las operaciones con tarjeta de crédito, es el Estándar de Seguridad de Datos para la Industria de Tarjeta de Crédito (PCI-DSS). En un sector totalmente opuesto tenemos la Health Insurance Portability and Accountability Act (H.I.P.P.A.), grosso modo es una LOPD de datos médicos, este es un pequeño informe en español de un centro médico con el que encontrareis parecidos razonables fácilmente.

Finalmente tenemos la Sarbanex Oxley (SOX), ley que titula esta entrada y por la cual deben regirse todas las empresas que coticen en la Bolsa de Estados Unidos, eso incluye a las extranjeras y sus filiales. En España corporaciones como REPSOL, el Banco Santander, BBVA o Telefonica pueden ser sometidas a auditorias SOX.

¿Por qué surge SOX? La Sarbanex Oxley surge como respuesta ante una serie de escándalos financieros de finales del siglo XX y principios del XXI, siendo el más famoso de ellos el caso ENRON. Esta empresa fue ejemplo de corrupción y fraude fiscal “a pesar” de que los informes de auditoria no mostraban nada de ello. Quizás en estos días de “crisis” y especulación es cuando más podemos acordarnos de SOX, y es que sin una ley similar aprobada por consenso internacional será difícil que esta situación no vuelva a repetirse, aunque esa es otra historia.

¿Por qué aplica SOX a los Sistemas de Información? Actualmente el enorme avance de la tecnología ha propiciado que los sistemas financieros se apoyen sobre los sistemas de información para acometer sus funciones. En tal sentido, los SdI deben garantizar la fiabilidad de la información financiera, por lo que se deben implementar controles específicos para garantizar la fiabilidad de este tipo de información. ¿Cómo implantar controles internos? Volvemos aun más atrás en el tiempo, mucho antes de la aparición de SOX, allá por el año 92 surgió el informe COSO, el cual tenéis disponible aquí y que es punto de referencia para la implantación de controles internos sobre la información financiera:

Sin embargo organizaciones como ISACA tampoco se han quedado atrás y han adaptado COBIT a la SOX. A primera vista parece difícil mapear controles, tengamos una visión holística centrándonos en las aplicaciones que soportan los procesos financieros:

Seguramente ahora os parezca más sencillo, las aplicaciones financieras no son un tipo especial de aplicaciones, los controles que aplicaremos serán bien conocidos, cambio en los programas, control de acceso, registros de auditoria, etc. Partiendo de esta base el “Road Map” que nos lleve a tener un IT Compliance en una auditoria SOX queda bien reflejado en la siguiente imagen:

Aun así siempre quedarán cositas, todo auditor debe hacer un informe al fin y al cabo, pero no debemos tirarnos de los pelos. A grandes rasgos los controles generales a aplicar sobre los SI se centrarán en:

- Control de Accesos: Control de lectura, alta y modificación, perfiles de acceso, procedimientos documentados, registros de auditoría).

- Pruebas de desarrollo y modificación de los SI.

- Control sobre el funcionamiento de los SI (validación de E/S, comprobación de calculos, gestión de errores).

La forma de implantar controles para estas 3 áreas no viene especificada en la SOX (ya sabemos que las leyes no se mojan mucho). Sin embargo podríamos apoyarnos en estándar internacionales, como la ISO 17799 para extender estos puntos o directamente tirar de la lista de controles de Cobit para la SOX, un interesante artículo de Tech Target que profundiza en esta idea lo tenemos aquí .

Y esta ha sido la lectura “veraniega”, espero que os haya gustado.

Salu2!

1 de junio de 2009

Market Report: Information Security

Póngame un pentest, una auditoría SOX y,,, ¿a cuánto dice que tiene la de LOPD?

Respuesta: Señora que esto es una fruteria,,, ¿qué tipo de negocio dice que tiene?

Creo que puedo afirmar sin temor a equivocarme que el “staff” de seguridad de la información es probablemente el personal que menos preocupado debe estar por su puesto de trabajo hoy en día. ¡Ojo! Esto no quiero decir que seamos los l-casei inmunitas de la empresa, nadie es indispensable (bueno, quizás Florentino Perez :-p) pero dentro del terremoto que actualmente sufren las economías del planeta y la sangría de paro que especialmente nos afecta podemos mantener una “cierta calma”.

Ahora bien, no parece compatible que el negocio que protegemos / defendemos las esté pasando canutas y que por ejemplo nos suban el sueldo un 20%, algo así comentaban desde Security Art Work hace unos días, hoy nos llega un interesante informe de Barclays Simpson titulado “Market Report: Information Security”, en él se dejan pinceladas bastante interesantes, como la fuerte ralentización de demanda de personal de seguridad en el segundo semestre de 2008, y es que hemos vivido años de relativa abundancia donde directamente las empresas no disponían de personal de seguridad, no sabían lo que era un análisis de riesgos o la dirección de informática, sistemas de información o similares aparecía en los primeros peldaños del organigrama de las empresas. Esto se ha ido transformando por un montón de razones, cumplimiento legal, certificación ISO, lucha contra el fraude o incluso por la visión de un mercado en el que también se podía ganar dinero: La venta de seguridad como servicio.

Si el número de vacantes en seguridad ha disminuido, si se ha incrementado el paro, ¿qué tenemos? Por primera vez desde el 2002 tenemos personal de Seguridad sin trabajo. El informe detalla muy bien por sectores qué estado tenemos, así como cual es el sueldo medio en el Reino Unido y Londres, ¿puede este informe extrapolarse a España? En mi opinión si bien los salarios son sustancialmente más altos allí que aquí, el mercado laboral es muy similar:

El texto viene acompañado de muchas más gráficas e información que apoya estos datos, la sensación que me queda es que la Seguridad ya no vive su época dorada, es un sector tan competitivo como otro (si cabe más) y en líneas generales todos los sectores (tanto públicos como privados) han tomado o comenzado a tomar concienciación sobre la necesidad de Seguridad.

Evidentemente estamos más cerca de las vacas “rellenitas” que de las vacas flacas, ¿no creéis?

Salu2