PCI DSS v3.0

This November has been realised the third version of PCI DSS. The amendments include a few changes from the previous version in both the introductory paragraphs and in requirements and test procedures.

Most of the changes are aimed to clarify issues in the previous version were open to misinterpretation or had raised important questions for organizations or even QSAs.

However, we also find some more fundamental changes, such as new requirements, modified to make requirements more stringent, or also (in less cases) modified to provide greater flexibility in compliance.

We will analyse all these major changes including the new version:

• We found a new section called "Implementing PCI DSS into Business-as-Usual" in which a series of best practices and recommendations on how it should be implemented so that PCI DSS is integrated into the processes of organizations are presented. Note that this is just a series of good practice and therefore are not binding or supersede any of the requirements of PCI DSS.
• Modified the table in which the requirements, so that now a column in which the motivation of each requirement. I think it is a very positive change, and that this explanation will often understand more fully exactly is being requested in each standard requirement without going to see any additional document.
• Requirement 2.4 which states that the organization must maintain an inventory of the components included in the scope of PCI DSS to assist in the use of configuration standards.
• As is known, the PCI DSS Requirement 5 requires the use of anti-virus on all systems except reach those who are deemed unaffected by malware (Mainframe, AS400, UNIX, etc.). The new version 5.1.2 requirement stablish the need to follow the evolution of risks due to malware on systems that are not normally affected by malware and remove them from this category if it is necessary.
• Another new requirement included in the sub-requirement 5.3 has been requesting anti-virus solutions remain activated and can not be disabled or altered by users.
• 6.5.10 requirement is considered good practice not mandatory until June 1, 2015. This requirement states that the procedures and policies should include measures to prevent attacks against authentication frameworks and web management sessions, including the following:
  • Bookmark session tokens (eg cookies) with the flag "secure".
  • Do not expose the session ID in the URL.
  • Incorporate appropriate timeouts and rotation for the session ID after successful login.
• Changed the requirement 8.2.3 so now that this requirement sets minimum in complexity and size of the password but allows greater flexibility in compliance. Although still requires you to use a password of 7 or more characters and include both numeric and alphabetic characters, is given the possibility to use other sizes or complexities whatever remains the same or greater strength in the password to use.
• New requirement (8.5.1) apply only to service providers and requiring these to use different credentials for remote access to systems of each of its customers. This requirement will be considered a good practice not mandatory until July 1, 2015.
• The new requirement 8.6 mandates that, when using authentication mechanisms other than username / password, these mechanisms are univocally linked to individual user accounts and ensure that only the appropriate users can make use of these mechanisms.
• Requirement 9.3 is also new in this release and appearance establishes the need to control physical access to sensitive areas by onsite personal. Also, it must have procedures for authorizing access and revoke such access immediately in termination.
• Other new requirements in this release are ranging from 9.9 to 9.9.3. These requirements require to protect devices that capture the card data directly through physical interaction with them (card readers, etc. ..). Specifically, the requirements asking for a list of existing devices, which were visually inspected periodically to detect anomalies in the same and that is to train staff to detect if devices have been replaced or tampered keeps.
• Requirement 10.5.2 reinforces the generation and review of logs by recording changes in identification and authentication mechanisms, including the creation of new accounts or privilege scalation, such as use the "su" command.
• The 10.2.6 has also been amended to require that the events corresponding to the stop or pause the audit logs are included, in addition to resetting or deleting the logs that already required in the previous version.
• Requirement 11.1.1 now requests that the inventory of authorized wireless access points and their corresponding business justification is documented. Meanwhile, the newly created requirement 11.1.2 establishes the need for incident response procedures detailing the course of action to follow in case of detecting unauthorized wireless networks in the quarterly reviews.
• Requirement 11.3 is one of the most significant changes in this new version. Considered just a good practice until next July 1, 2015 date on which shall be considered mandatory. The requirement mandates that organizations have an annual pentest methodology. This methodology must to consider, almost, the next topics:
• Based on industry-accepted penetration testing approaches.
• Includes coverage for the entire Cardholder data Enviroment perimeter and critical systems.
• Includes testing from both inside and outside the network.
• Includes testing to validate any segmentation and scope-reduction controls.
• Defines application-layer penetration tests to include, at a minimum, the vulnerabilities listed in Requirement 6.5 of PCI DSS.
• Defines network-layer penetration tests to include components that support network functions as well as operating systems.
• Includes review and consideration of threats and vulnerabilities experienced in the last 12 months
• Specifies retention of penetration testing results and remediation activities results.
• Requirement 11.5 has also been modified to provide greater flexibility in compliance. Now, instead of requiring you install a FIM, it is requested that any mechanism that allows change detection to alert personnel of unauthorized critical system files, configuration files or content files modifications.
• Changed the requirement 12.2 (old 12.1.2) so that now not only the execution of an annual risk analysis is required, but also after any significant change in the environment (eg, acquisitions, mergers, relocations, etc. ..).
• New 12.8.5 requires to maintain information about which PCI DSS requirements are managed by each service provider, and which are managed by the entity.
• And finally, the new requirement 12.9 apply only to service providers and will be considered a best practice until July 1, 2015. This requirement will force service providers to provide their customers and sign specific clauses which explicitly recognize their responsibility in managing the security of cardholder data from their customers. 

In conclusion, I think all the changes included in the new version of the standard are positive and that we have a clear standard, with less indefined areas and that permits those organizations that implements PCI DSS not just be compliant but also highly increment the security of card-holder data that is stored, transmitted or processed by the organization.

PCI_DSS_v3_Summary_of_Changes.pdf
PCI_DSS_v3.pdf

Twitter: @omarbenjumea

Linkedin: http://www.linkedin.com/in/omarbenjumea

New ISO27001:2013

Since last quarter of 2013 it is available the new version of ISO27001. This version 2013 includes many changes and the purpose of this post is to take a high-level look over them.
First, the new version fits the ISO Annex SL. This means that the distribution of sections and phases of the standard will be extremely similar to the rest of ISO standards that are also adapting to this Annex. In practice, what is proposed is that organizations can have a common management framework in which they are integrated the different ISO that have implemented.The following will list other significant changes introduced by the new version:

• The definition of context will have a key importance as the beginning of the ISMS planning.
• A new specific section to deal with the Leadership in the ISMS. Therefore, this concept will be particularly important in the transitions to the 2013 version.
• "Preventive actions" concept is replaced by "management of risks and opportunities". 
• ISO31000 is referred to as the risk management framework. Aligned with Annex SL it is intended that risk management will become homogeneous at the corporate level. In this way, organizations could compare risks of different types ( information, people, financial, etc.). 
• The adoption of ISO31000 as risk analysis framework causes that the requirements of risk analysis turn more generic and less detail than those defined in ISO27001:2005 and ISO27005. The purpose is to facilitate the implementation of risk analysis in other management systems that not incorporated it (such as environmental management, quality or IT services ). 
• Security objectives must be approved by business and should allocate the necessary resources to achieve them. There will be special emphasis on this aspect, so that the allocation of resources should be appropriately evidenced .
• Appears a new concept of great importance will be the communication to interested parts.
• Another important change is that it abandons the concept of asset owner and is replaced by risk owner. 
• It passes the 133 controls in Annex A to 114 controls. Actually controls are not removed, only a rearrangement proceeds to reformulate many of them.

Althought PDCA is not mandatory in this new version you can easily match the clauses with the PDCA scheme (note that the structure is identical for all standards that are adopting ISO Annex SL): 
PLAN

• Clause 4 Context: In the new version becomes of paramount importance to properly define the context, both internal and external to the organization. That is, bear in mind the ecosystem in which we live for the rest of decisions taken in the ISMS. Furthermore, the concept of context is perfectly aligned with the ISO31000 regarding context definition to be performed on risk analysis. 
• Section 5 Leadership: As mentioned earlier, this is an entirely new clause. In this new version the definition of leadership and responsibilities will be central, with the aim of ensuring that the necessary resources are allocated to ensure the achievement of the security objectives. 
• Clause 6 Planning: This clause defines the requirements of risk analysis using ISO31000 as a framework and define the requirements to be met in terms of goal setting and planning. The applicability statement remains almost unchanged . 
• Clause 7 Support: This clause defines the requirements in terms of training , resource allocation, awareness, communication and document management. Also, as mentioned before, is given great importance to the management of communication to interested parts, to be established what should be reported, to whom to communicate and how to communicate it.

DO 
Clause 8: This is the clause of Annex SL more change for each ISO as the DO of the 27001 will be totally different to the DO on environmental management, quality or any other ISO. This clause is where, based on the declaration of applicability must be implemented the relevant controls.
CHECK
Clause 9: The ninth clause define the requirements for the ISMS metrics and indicators. In this new version reinforces the requirement in terms of definition and implementation of metrics. 
ACT
Clause 10: The last clause puts the focus on continuous improvement. In this respect, the changes from version 27001:2005 are minimal.

Finally, I must say that after my experience working in the transition from an ISMS based on ISO27001:2005 to the new version  ISO27001:2013 I am convinced that the changes are very positive and that will result in improved efficiency for those ISMS that uses this standard as a basis for implementation.
I hope you've enjoyed this post and have found it useful.
twitter: @omarbenjumea
linkedin: http://www.linkedin.com/in/omarbenjumea

Nueva ISO27001:2013

Por fin tenemos disponible la nueva versión de la 27001. Está versión 2013 incluye bastantes cambios y el propósito de este post es echarles una ojeada de alto nivel a las principales novedades.

En primer lugar, la nueva versión se adapta al Anexo SL de ISO. Esto significa, que la distribución de apartados y fases de la norma será extremadamente similar con el resto de normas que también se están adaptando a este anexo. En la práctica, lo que se propone es que las organizaciones puedan contar con un único marco de gestión común en el que se encuentren integradas las diferentes ISO que tengan implementadas.

A continuación listaremos otros cambios significativos introducidos por la nueva versión:

• La definición del contexto pasará a tener una importancia clave como inicio de la planificación del SGSI. 
• Aparece una nueva cláusula específica para tratar del Liderazgo en el SGSI. Por lo tanto, este concepto cobrará especial importancia en las transiciones a la versión de 2013.
• Se elimina el concepto de acciones preventivas siendo sustituido por el de gestión de riesgos y oportunidades.
• Se referencia la ISO31000 como marco de gestión de riesgos, por lo que, alineado con el anexo SL, se busca que la gestión de riesgos también sea homogénea a nivel corporativo. De esta manera las organizaciones podrán comparar riesgos de diferentes tipologías (de la información, riesgos laborales, riesgos financieros, etc..).
• El hecho de alinearse con la ISO31000 provoca a su vez que los requisitos del análisis de riesgos sean más genéricos y con menor detalle que los que se definínan en ISO27001:2005 e ISO27005. El propósito es facilitar la realización de análisis de riesgos en otros sistemas de gestión que hasta la fecha no lo incorporan (como la gestión medioambiental, la de calidad o la de servicios TI).
• Los objetivos de seguridad deberán ser aprobados por negocio y se deberán destinar los recursos necesarios para su consecución. Se realizará especial hincapié en este aspecto, por lo que la asignación de recursos deberá quedar debidamente evidenciada.
• Aparece un concepto nuevo de gran importancia que será el de comunicación a las partes interesadas.
• Otro cambio relevante es que se abandona el concepto de propietario del activo y se reemplaza por propietario del riesgo.
• Se pasa de los 133 controles del anexo A a 114 controles. En realidad no se eliminan controles, tan sólo se procede a una reordenación reformulando buena parte de ellos.

La nueva versión mantiene el esquema PDCA. La distribución de cláusulas en el esquema será la siguiente (cabe señalar que la estructura es idéntica para todas las ISO que van adoptando el anexo SL):

PLAN

• Cláusula 4 Contexto: En la nueva versión cobra una importancia capital definir adecuadamente el contexto, tanto interno como externo de la organización. Es decir, tener bien presente el ecosistema en el que nos movemos para que el resto de decisiones que se adopten en el SGSI hayan considerado adecuadamente la realidad actual. Además, el concepto de contexto se alinea perfectamente con el de la ISO31000 en cuanto a definición del contexto en el que se debe realizar en análisis de riesgos.
• Cláusula 5 Liderazgo: Como hemos comentado con anterioridad, se trata de una cláusula totalmente nueva. En esta nueva versión la definición de liderazgo y responsabilidades será central, con el objetivo de garantizar que se destinan los recursos necesarios para garantizar la consecución de los objetivos definidos.
• Cláusula 6  Planificación: En esta cláusula se definen los requisitos de realizar un análisis de riesgos usando la ISO31000 como marco de referencia y se definen los requisitos a cumplir en cuanto a definición de objetivos y su planificación. La declaración de aplicabilidad se mantiene sin apenas cambios.
• Cláusula 7 Soporte/Apoyo: En esta cláusula se definen los requisitos en cuanto a formación, asignación de recursos, concienciación, comunicación y gestión documental. Además, se exigirá que las tareas de mantenimiento del SGSI se deban realizar de forma distribuida durante el año. Así mismo, como hemos comentado antes, se da gran importancia a la gestión de la comunicación a las partes interesadas, debiendo definirse qué se debe comunicar, a quien se de comunicar y cómo se debe comunicar.

DO

• Cláusula 8: Esta es la cláusula del anexo SL que más cambiará para cada ISO ya que el DO de la 27001 será totalmente diferente al DO de la ISO de gestión medioambiental, de calidad o cualquier otra ISO. En esta cláusula es donde, en base a la declaración de aplicabilidad realizada se deberá llevar a cabo la implantación de los controles pertinentes.

CHECK

• Cláusula 9: La cláusula novena definirá los requisitos en cuanto a métricas e indicadores del SGSI. En esta nueva versión se refuerza la exigencia en cuanto a definición e implantación de métricas.

ACT

• Cláusula 10: La última cláusula pone el foco en la mejora continua. En este aspecto, los cambios respecto a la versión 27001:2005 son mínimos.

En conclusión, aunque sigue siendo la ISO27001, su adaptación al anexo SL y los cambios incluidos en la nueva versión van a exigir un esfuerzo importante de adaptación a realizar en 2014 por parte de las empresas que quieran mantener su certificación. Después de esta primera revisión a alto nivel de las novedades que incluye la ISO estoy convencido que los cambios son a mejor y que redundarán en una mejora de la eficiencia de los SGSI que utilicen esta norma como base para su implementación.


twitter: @omarbenjumea
linkedin: http://www.linkedin.com/in/omarbenjumea

¿Vale la pena certificar nuestro SGSI?

De un tiempo a esta parte le he estado dando vueltas a la utilidad de certificarse en ISO27001. Conozco el estándar desde hace muchos años, tanto desde el punto de vista de consultor como de auditor interno, de implantador y de operador/administrador del SGSI (Sistema de Gestión de la Seguridad de la Información). La teoría está clara; estar certificado te permite contar con la confirmación de un tercero “independiente” que garantiza que el sistema de gestión de la información de tu organización cumple con los requisitos del estándar. Esto se supone que ha de ser una ventaja competitiva frente a otros competidores no certificados debido al aumento de confianza que el sello debería proporcionar en clientes y proveedores.

Y aunque puede que esto sea cierto en algunos casos, pero en mi opinión, no lo es en la mayoría. La ISO27001 sigue siendo una gran desconocida fuera del sector de TI y en muchos casos también dentro del propio sector. Así mismo, es muy raro el caso en el que un pliego o una RFP exijan que los proveedores estén certificados e incluso son raros los casos en los que se indica que la certificación será tenida en cuenta en la adjudicación del proyecto o servicio.

Estoy de acuerdo en que hoy en día es indispensable para toda empresa contar con un SGSI si se desean mitigar los riesgos que afectan a su información de una forma eficiente, y la ISO27001 es una excelente opción (aunque no la única) en la que basarlo. La ISO permite racionalizar los esfuerzos que se dedican a la seguridad, de manera que se optimiza la reducción de riesgo para una determinada inversión en seguridad. Además, establece un ciclo de mejora continua que también es indispensable para mantener unos niveles de seguridad aceptables a lo largo del tiempo.

Sin embargo, debería ponderarse con cuidado la decisión de abordar un proceso de certificación, teniendo en cuenta los beneficios y los esfuerzos que de ello se derivará. Dado que los auditores de certificación se focalizan en formalismos (no puede ser de otra manera en una auditoría de pocos días), puede ocurrir que los mayores esfuerzos en la implantación del SGSI no se dediquen estrictamente a montar el Sistema de Gestión más adecuado a nuestra organización, si no que es frecuente que los mayores esfuerzos se dediquen a cumplir con todos los formalismos documentales que exige la norma. Esto significa además, que nuestro SGSI perderá flexibilidad, ya que una vez adquirida la certificación no querremos arriesgarnos a perderla.

También hay que tener en cuenta que todo el tinglado de la certificación y los certificadores puede resultar en sí mismo perjudicial para el cumplimiento efectivo del estándar. Por un lado tenemos empresas certificadoras que se ganan la vida acreditando a las organizaciones y, especialmente, recertificándolas año tras año. Además, son competencias unas de las otras, por lo que cada una toma su rol. Tenemos las empresas en las que todo el mundo sabe que es fácil certificarse, y las empresas en las que se supone que es más difícil hacerlo. En cualquier caso, todas comparten el mismo objetivo (y no es mejorar la seguridad de sus clientes); certificar a tantas empresas como sea posible y fidelizarlas para continuar recertificándolas año tras año. Por otro lado, tenemos a los auditores, autónomos subcontratados por las certificadoras, que en muchas ocasiones realizan una interpretación extremadamente subjetiva del estándar llegando a establecer no conformidades u observaciones que en nada ayudan a mejorar la seguridad de la Organización. Sin embargo, deben ser acometidas si se quiere mantener la certificación. Creo que coincidiréis conmigo en que no es el ecosistema más propicio para la mejora

En conclusión, aunque puede ser muy beneficioso en determinadas circunstancias o para determinadas organizaciones, pienso que se debe considerar detalladamente hasta que punto los esfuerzos destinados a implantar o mantener un SGSI certificable merecen la pena en la mayoría de los casos. Si no tenemos claro que el hecho de certificar nuestro SGSI vaya a tener un ROI aceptable, pienso que es mejor dedicar los principales esfuerzos a tener un SGSI lo más eficaz y alineado con nuestra organización posible aunque no cumpla todos los requisitos necesarios para que la empresa certificadora de turno nos conceda su sello.

Mitigar ataques Pass-the-Hash by Microsoft

El otro día me topé con un documento de Microsoft que desconocía sobre cómo mitigar los riesgos de sufrir un ataque de tipo "Pass the Hash". El documento se puede descargar haciendo click aquí.

En primer lugar, recordemos qué es un ataque de tipo Pass-the-Hash. Este tipo de ataque consiste en capturar las credenciales de acceso a un equipo y usar dichas credenciales para autenticarse en otros equipos de la red. El concepto es muy similar al de un robo de contraseña, pero en este caso lo que se roba en lugar de ser la contraseña es el hash de una contraseña o bien un ticket de sesión válido.

Para llevar a cabo este tipo de ataque se necesita tener acceso con permisos de administración local en el equipo en el que se haya logado el usuario del que queremos obtener las credenciales. El caso más típico es el de obtener acceso con privilegios de administrador local en un equipo con pocas medidas de seguridad, por ejemplo una estación de usuario o un servidor de desarrollo y utilizar este acceso para hacerse con las credenciales de otro usuario con mayores privilegios que se haya logado recientemente en ese equipo, por ejemplo, un controlador de dominio que haya accedido para llevar a cabo taréas administrativas.

El documento de Microsoft propone considerar las siguientes medidas de seguridad para mitigar el riesgo de sufrir un ataque de este tipo:

• Restringir y proteger las cuentas de dominio que cuenten con privilegios elevados:
• Evitar usar los usuarios administradores de dominio para logarse en equipos con un nivel bajo de seguridad que puedan ser comprometidos, como por ejemplo, equipos de usuarios, servidores no productivos, etc..
• Proveer a los administradores de sistemas de usuarios con privilegios de administración separados de sus cuentas de usuario normales.
• Utilizar sólo determinadas estaciones de trabajo para realizar las tareas administrativas.
• En el Directorio Activo, asegurarnos que las cuentas privilegiadas estén marcadas con la opción "Sensitive and cannot be delegated".
• No configurar servicios o tareas programadas que utilicen usuarios con privilegios en el dominio en equipos con un bajo nivel de seguridad, como las estaciones de trabajo o entornos no productivos.
• Restringir y proteger las cuentas locales con privilegios de administrador:
• Evitar que las cuentas locales con privilegios administrativos puedan ser utilizadas para la administración remota de los equipos.
• Denegar explícitamente el logon de red y el uso de Escritorio Remoto para todas las cuentas locales con privilegios administrativos.
• Usar passwords únicos en cada máquina para las cuentas locales con privilegios administrativos.
• Usar firewalls de sistema para restringir el tráfico entrante a los sistemas:
• Usar el firewall de windows u otro firewall de Host para restringir al mínimo indispensable el tráfico entrante (y saliente) de todos los servidores y estaciones de trabajo.
• Quitar los privilegios de administrador local a los usuarios normales:
• Para evitar que el compromiso de una cuenta de usuario permita realizar un ataque de este tipo, es necesario que los usuarios no cuenten con privilegios de administrador local de sus estaciones de trabajo.
• Configurar un proxy de salida para denegar el acceso a Internet a cuentas privilegiadas. En el propio documento de Microsoft viene el detalle de cómo realizar esta configuración.
• Garantizar que las cuentas privilegiadas no tengan asignados buzones de Exchange o de otros servicios de correo electrónico.
• Usar herramientas de administración remota que no dejen hashes o tickets guardados en las estaciones remotas a las que se accede. (Si alguien sabe qué herramientas de administración remota cumplen esta premisa se agradecerán los comentarios ya que es algo que aún no me he puesto a analizar.. ;) )
• Evitar acceder con cuentas privilegiadas a entornos de menor seguridad como estaciones de trabajo o equipos no productivos para evitar que el compromiso de estos equipos comprometa a su vez los equipos más críticos. Para evitar esto sería recomendable que los administradores contaran incluso con diversas cuentas de usuarios en función de la sensibilidad de los equipos a administrar. Por ejemplo, Administrador_Desarrollo, Administrador_Workstations, Administrador_DMZ y Administrador_Servidores.
• Mantener actualizados sistemas operativos y aplicaciones de forma que el usuario no pueda conseguir comprometer una cuenta con privilegios locales de administración y por lo tanto no pueda comprometer a su vez cuentas con privilegios en el dominio.
• Bastionar y gestionar adecuadamente la seguridad de los controladores de dominio. Si el atacante directamente compromete un controlador de dominio, ya no necesitará llevar a cabo un ataque PassTheHash...
• Eliminar los hashes LM. Para ello es necesario que todos los controladores de dominio sean al menos Windows Server 2008.

Y por último, aunque no se menciona en el documento de Microsoft, yo añadiría la necesidad de contar con una adecuada segmentación de red que permita garantizar que, aunque se comprometa una credencial de administrador de dominio en un determinado servidor o estación de trabajo, el atacante no pueda logarse directamente en el resto de servidores de la estación. Con una segmentación adecuada limitaríamos el impacto del compromiso a la VLAN de la máquina comprometida.

Consejos para un Análisis de Riesgos Útil y Sencillo

Después de analizar, probar y sufrir numerosas metodologías de análisis de riesgos he llegado a una conclusión definitiva; cuanto más sencilla sea la metodología a emplear tanto más útil será el análisis de riesgos, ya que con poco esfuerzo podremos obtener una información interesante y útil para la gestión de la seguridad de nuestra organización.

Para ello, mi propuesta de decálogo es la siguiente:

1. Utiliza siempre un modelo cualitativo y con pocas dimensiones a valorar.
2. Explica bien a los directivos de tu organización qué es el nivel de riesgo residual, es decir, el nivel de riesgo aceptable por la organización y que sean ellos los que lo definan de una manera consciente.
3. Dedica esfuerzos a tener bien definido el mapa de activos de tu organización:

• Define una primera capa con los procesos de negocio y los procesos de soporte.
• Por debajo de estos, define la capa de aplicaciones.
• Por debajo de la capa de aplicaciones, los sistemas y bases de datos.
• Y finalmente, de una manera lo más agregada posible, los dispositivos de comunicaciones.
1. Prepara bien los criterios para valorar los impactos y realiza un BIA valorando por separado los impactos en cuanto a disponibilidad, integridad y confidencialidad. 
2. Entre los criterios para la valoración de impactos, ten en cuenta como mínimo, los impactos legales, financieros y de imagen.
3. Siempre que ea posible, agrupa los activos tecnológicos cuando estos estén en una misma ubicación de red y sean administrados de una manera homogénea. Esto simplificará en gran medida tu análisis de riesgos.
4. Selecciona un catálogo de amenazas lo más sencillo posible. Básate en Magerit o en cualquiera de otro catálogo existente y simplifícalo para adaptarlo a la realidad de tu organización.
5. No te compliques en la definición de controles y contramedidas. Básate en algún estándar como la ISO27002 o la NIST.
6. Prepara un plan de tratamiento de riesgos coherente teniendo en cuenta una estimación de esfuerzos lo más realista posible.
7. Cuando presentes los resultados del análisis de riesgos a la Dirección, traduce los resultados para que sean lo más inteligibles posible.

Finalmente, saca provecho a tu análisis de riesgos. No lo hagas simplemente para cumplir con el trámite exigido por el ENS, la ISO27001 o PCI DSS.

Un análisis de riesgos bien hecho no tiene porqué ser complejo ni necesita dedicar meses para su ejecución. Sin embargo, se le puede sacar mucho partido ya que permite:

• Identificar qué activos son los que están más expuestos.
• Cuales son las amenazas más relevantes para tu organización.
• Qué proyectos o medias de seguridad se deben priorizar.
• Qué proyectos o medias de seguridad no son necesarias y por lo tanto nos podemos ahorrar sus costes y esfuerzos.
• Es una excelente herramienta para justificar la necesidad de presupuesto, especialmente si el riesgo residual ha sido definido por la Dirección.

Quiero ser Consultor de Seguridad

He pasado la mayor parte de mi carrera profesional dedicándome a la consultoría de seguridad de la información. La verdad es que llegué a este mundillo más por casualidad que por auténtica vocación, aunque ahora me cueste imaginarme dedicándome a otra cosa!

Y es que es difícil despertarse un día siendo un adolescente y pensar, ¡Quiero ser un consultor de seguridad! Futbolista, abogado, periodista, actor, programador, diseñador, arquitecto o incluso Hacker... quizá. Pero no Consultor de Seguridad. Y es que la mayoría de la gente que no trabaja directamente en este sector (incluso algunos que sí lo hacen) ignora a qué nos dedicamos.

Así pues, quiero empezar este post por explicar, según mi punto de vista...

En qué consiste ser Consultor de Seguridad

Dentro del ámbito de la consultoría de seguridad existen multitud de tipologías de proyectos diferentes que pueden llevarse a cabo. A saber:

• Proyectos relacionados con la Gestión de la seguridad: Implantaciones o auditorías de ISO27001, de Esquema Nacional de Seguridad en el caso de administraciones públicas, análisis de riesgos, planes directores de seguridad, etc...
• Proyectos relacionados con la continuidad de negocio: Implantación o auditorías de sistemas de gestión de la continuidad de negocio, definición o auditorías de planes de continuidad de negocio, planes de contingencia y recuperación ante desastres, etc
• Proyectos relacionados con el cumplimiento normativo: proyectos relacionados con la LOPD, Firma Electrónica, la LSSI, con PCI DSS, con la SOX, las HIPAA,etc
• Proyectos de desarrollo normativo: Políticas de seguridad, normativas de seguridad, procedimientos de seguridad, procedimientos de gestión de incidentes de seguridad, etc..
• Otros proyectos: Proyectos de PKI, asesoramiento en materia de seguridad, formaciones, planes de concienciación, etc...

¿Por qué dedicarse a la Consultoría de Seguridad?

Pues podría dar multitud de razones, pero quizá la principal para alguien que ahora esté empezando su carrera profesional sea que este es uno de los pocos sectores que aún siguen creciendo y generando trabajo a buen ritmo. Y esto por si sólo y con la que está cayendo ya es una razón de peso.

Por otro lado, se puede conseguir un nivel salarial aceptable a los pocos años de experiencia. Para ilustrarlo, voy a indicar a continuación una tabla para reflejar salario bruto anual vs años de experiencia. Cójase con pinzas, ya que puede variar tremendamente en función de la ciudad, el empleador, la valía, la capacidad de negociación y la suerte de cada cual. Además, no hay que perder de vista que los sueldos en general y por desgracia están en un proceso de retroceso:

• de 0 a 2 años de experiencia; 18.000€ a 24.000€
• 2 a 3 años de experiencia; 24.000€ a 30.000€
• 4 a 5 años de experiencia; 30.000€ a 40.000€
• + 5 años de experiencia; 36.000€ a 44.000€ (o incluso más si te contrata una empresa extranjera...)

Pero además, como hemos visto en la sección anterior, es una profesión que te permite adquirir conocimientos multidisciplinares, colaborar con grandes empresas y vivir en carnes propias el vertiginoso avance de las tecnologías relacionadas con la seguridad.

El Perfil del buen Consultor de Seguridad de la Información

La característica principal de un buen consultor ha de ser (en mi opinión) su capacidad para entender una determinada problemática, analizarla y obtener conclusiones óptimas para solucionarla, siendo capaz de exponerlas y defenderlas de una manera inteligible, coherente y justificada.

Por ello, el consultor de seguridad debe disponer de, al menos, las siguientes aptitudes y habilidades:

• Escucha activa.
• Capacidad de análisis.
• Empatía.
• Capacidad de síntesis.
• Excelente expresión escrita.
• Capacidad para negociar con los clientes.
• Capacidad para realizar presentaciones eficaces.
• Buen gestor del tiempo.
• Capacidad e interés en la auto-formación continua.

Se puede llegar a la consultoría de seguridad desde estudios tecnológicos (Informática, Telecos...) o incluso desde otros tipos de estudios (conozco a consultores con formación en Derecho, Económicas, etc.) aunque siempre contando un buen complemento de formación y experiencia tecnológicos.

Por otro lado, en cuanto a las principales certificaciones profesionales que pueden ser de utilidad en esta profesión son las siguientes:

• Lead Auditor en ISO27001 (Imprescindible).
• Certificaciones de ISACA como CISA o CISM.
• Certificación CISSP.
• Lead Auditor en ISO22301.
• Certificaciones técnicas de seguridad de SANS.
• Certificaciones en privacidad de datos.