post

¿Cómo tratar la seguridad de la información con nuestros proveedores? Parte 3

Al fin llegamos a lo que consideraría la tercera y última parte de esta entrega. Aunque no considero sea la última vez que escriba sobre el tema de la seguridad de la información en proveedores.

Recapitulando un poco sobre las primeras dos partes. Hemos entendido la importancia de establecer inicialmente un programa de seguridad propio para en base a ellos definir nuestros propios requerimientos de seguridad hacía terceros. También nos dimos la tarea de conocer más sobre la información que manejamos y compartimos con terceros.

Ha llegado la hora de empezar a cuestionar, levantar información, investigar sobre los controles de los terceros con los que trabajamos. Creo que para la realización de este punto tenemos que tener en cuenta algunas variables u escenarios.

1.- ¿Se trata de un proveedor nuevo? Si la respuesta es afirmativa, en el momento en el que se empieza a establecer la relación es cuando debemos presentarles nuestros requerimientos de seguridad y alinearlos a los alcances de los servicios a contratar. Esto nos permitirá identificar la brecha de manera previa a la firma de contrato y determinar el nivel de riesgo de trabajar con X, Y o Z proveedor.

2.- ¿Se trata de un proveedor ya existente? De ser el caso seguramente este proveedor desconoce en buena parte nuestros requerimientos de seguridad o en dado caso no está a la par con la versión más reciente de los mismos. Tenemos que ser tolerantes en este escenario ya que no es simplemente llegar exigiendo tenemos que entender el lado del proveedor y sus posibles restricciones de tiempo y presupuesto. De igual manera recuerden que también nos podemos topar con restricciones de oferta tanto de proveedores como de servicios.

Muy bien ya logré ubicar al proveedor en uno de los escenarios mencionados. ¿Ahora qué hago?

Es momento de notificarle a ese tercero que necesitamos hacer una revisión sobre sus controles de seguridad. Recuerden que es importante acotar que el alcance de ciertos requerimientos, créanme que esto les facilitará la vida.

¿Qué información le pudo pedir? ¿En qué me puedo basar?

  1. Mi sugerencia es que en primer lugar busquen que sus requerimientos salgan de referencias como Shared Assessments, ISO 27002, COBIT, ENISA, NIST u cualquier otra normatividad/código de práctica/framework. Es importante también que si tomaran una de esas referencias y la repasaran a manera de cuestionario al proveedor tengan el criterio al momento de evaluar las respuestas de considerar también sus propios requisitos definidos junto a propio programa de seguridad.
  2. En segundo lugar establezcan una lista predefinida de documentos/evidencias que pueden ser solicitados o compartidos a manera de dar soporte a las respuestas de los cuestionamientos realizados. Consideren solicitar esto a la par del punto 1.
  3. No olviden que si las respuestas u evidencias no les parecen suficientes son libres y deben de pedir información adicional.

Una vez que tenemos la información solicitada es momento poner las manos a la obra y realizar nuestra evaluación. Es importante considerar que dicha evaluación no necesariamente debe basarse solo en lo que llamamos “desk review”. En muchas ocasiones una visita al proveedor es fundamental para una identificación óptima de riesgos.

Terminado el análisis y teniendo los resultados, llega el momento de entregar las buenas y/o malas noticias. Los resultados se deben informar por un lado al área contratante del proveedor en cuestión en primer lugar. Posteriormente el proveedor debe ser notificado en caso de hallazgos y en base al criterio de tratamiento y/o aceptación definido proveer sus respuestas para el tratamiento de los riesgos identificados. Tomen en cuenta que un riesgo puede ser Mitigado, Evitado, Aceptado o Transferido.

Tomen en cuenta que como negocio es indispensable también definir como actuar ante casos extremos donde los proveedores no pueden mitigar un determinado riesgo o no están dispuestos a cooperar. Un buen proceso de excepciones es indispensable para muchos casos.

Sea cual haya sido la respuesta, el seguimiento al proveedor debe mantenerse hasta que cada riesgo haya sido tratado según lo acordado.

En fin mis queridos amigos, de esta manera doy por terminada esta tercia de textos sobre la seguridad de la información en proveedores. Esta no es una guía definitiva ni mucho un tutorial, simplemente son algunas cuestiones que pueden ayudar en el punto de partida de algo que puede ser bastante amplio para muchas organizaciones y sobre todo muy nuevo en el escenario Latinoamericano.

Como siempre sus comentarios son bienvenidos.

Gracias por haber leído hasta aquí J

Les dejo unas cuantas lecturas recomendadas:

If You’re Only as Strong as Your Allies, Should You Trust Third-Party Code?

¿Cuánto por esa cuenta? El valor de la información en el mercado negro?

Corporations Cite Reputational Damage As Biggest Cyber Risk

A Vendor’s Security Reality: Comply Or Good-Bye

post

¿Por qué pasamos por alto los mensajes de alerta en los sistemas?

Un reciente estudio publicado (http://neurosecurity.byu.edu/) por investigadores de la Brigham Young University y la University of Pittsburgh en conjunto con Google nos presenta interesantes datos sobre la manera en la que se comportan los usuarios ante los mensajes de alertas provenientes de los sistemas de información.

Se trata de un estudio que a mi parecer es muy interesante ya que nos deja en evidencia cuestiones bastante comunes que muchas veces decimos que suceden por estar en “automático” como cuando simplemente al ver un error del sistema operativo presionamos Aceptar o Continuar por mera costumbre sin antes leer de que se trató el error.

El estudio (http://neurosecurity.byu.edu/chi_fmri_habituation/)  denominado How Polymorphic Warnings Reduce Habituation in the Brain—Insights from an fMRI Study consistió en evidenciar como nuestros cerebros tan solo después de un par de exposiciones a una alerta genera un estado mental de hábito disminuyendo su procesamiento en exposiciones posteriores resultando en que muchos pasen por alto mensajes importantes arrojados en por los sistemas. Lo que los autores denominan “habituation” es un proceso que ocurre de manera inconsciente en nuestros cerebros.

Los investigadores desarrollaron dos experimentos para constatar su hipótesis; En el primer estudio diseñaron mensajes de alertas polimórficos los cuales tuvieron como objetivo reducir la resistencia a la creación de hábitos. De tal manera los usuarios terminan mantener un poco más de atención en dichos mensajes. El segundo estudio involucro el rastreo de los movimientos del puntero del mouse para validar que los mensajes polimórficos de verdad generan una mayor resistencia a la creación de hábitos.

Como resultado de ambos estudios pudieron validar que sí existe una reducción en la desatención de los usuarios ante mensajes polimórficos que al mostrarse aleatoriamente diferentes resultan en que los usuarios dediquen segundos adicionales a su lectura antes de tomar alguna acción.

Creo que el involucramiento de la neurociencia para fines prácticos en cuestiones relacionadas a la seguridad de la información puede tener suma importancia si nos ponemos a pensar fríamente que muchas de las brechas en la actualidad tienen alta participación del usuario. Por medio de estudios como este las compañías enfocadas a soluciones de seguridad podrían sacar más provecho al campo de la neuroseguridad o “neurosecurity” y los diseños de sus interfaces gráficas pueden disminuir la velocidad en la que generamos tales hábitos reteniendo por un tiempo mayor la atención de los usuarios, logrando disminuir en algún nivel el índice de vulneraciones por respuestas inconscientes.

¿Qué opinan sobre este tema? ¿Cuántas veces han aceptado o han dado clic en alertas sin antes leer el mensaje?