1

Blockchain Risks

   Como hemos aprendido en los dos anteriores posts, blockchain reduce tremendamente la posibilidad de que surjan errores. Además, los registros no pueden ser  modificados por nadie una vez que se han añadido. Debido a que cada transacción se registra y se verifica, la integridad de los registros está garantizada. Por ello, mucha gente del sector IT plantea el hecho de que auditar sistemas basados en blockchain va a ser innecesario. Pero ¿es eso cierto?

Sin duda alguna es totalmente falso.En este post voy a resaltar los principales riesgos que se deben tener en cuenta cara a la auditoría de un sistema con tecnología blockchain. Tal y como hace referencia Deloitte en uno de sus artículos sobre blockchain y sus riesgos, el blockchain se puede dividir en dos tipos: “permissionless and permissioned chains”, esto es, cadenas sin permiso y autorizadas.[1] Blockchain sin permiso permite que  cualquiera sin ningún tipo de verificación participe en la red de transacciones. Sin embargo, las autorizadas están formadas por responsable o responsables que evalúan la participación de una persona u entidad en el entorno blockchain.

La mayoría de los riesgos que hoy en día se plantean no van asociados al tipo de blockchain del que se use. Ya que, es cierto que un riesgo está directamente relacionado con la integridad de los eslabones que componen la cadena blockchain, pero los grandes riesgos que realmente asustan a los expertos son independientes a ello. Después de informarme bien, y leer y releer una enorme cantidad de artículos en lo que refiere a este tema, me gustaría destacar una tabla publicada por ISACA que recopila de manera muy visual los posibles riesgos del blockchain y su relevancia. [2]

 

ISACA Blockchain Risks

Como se puede observar, categorizan los riesgos según su impacto y su probabilidad. Siendo de color verde los riesgos de menos importancia y difuminándose a color rojo los que aumentan su relevancia. En ISACA entienden por críticos, los siguientes riesgos:

  • Plataform Vulnerabilities:

La integridad del blockchain está determinada por la plataforma de software sobre la cual se ejecuta. Si la plataforma se considera poco fiable, ello afecta al blockchain.

  • Targeted Malware:

La infraestructura que admite el blockchain está sujeta a todas las amenazas y vulnerabilidades habituales. Ningún software está exento de ataques, y hay que tenerlo en cuenta.

  • Change control:

Abuso del privilegio de administración y cambio no autorizado en la infraestructura.

 

Además de estos tres posibles riesgos que ISACA destaca como los riesgos con mayor grado de  impacto/probabilidad, me gustaría destacar desde mi punto de vista los principales riesgos weak-chainen cuanto a seguridad se refiere: el acceso o control de acceso, la robustez del cifrado y la seguridad individual de cada nodo. Respecto a la seguridad de cada nodo, hay un dicho que me viene a la cabeza: “una cadena es tan débil, como el eslabón más débil de esta”. En este caso ocurre lo mismo, por ello es imprescindible disponer de planes de contingencia adecuados. A su vez, es cierto que el blockchain se caracteriza por estar cifrado, pero es de destacar que existen infinidad de algoritmos de cifrado. Y, no todos poseen el mismo nivel de seguridad.

En conclusión, puesto que estamos tratando una tecnología emergente, la mayoría de información y opiniones respecto a sus posibles riesgos son meras suposiciones. Suposiciones que se basan en experiencias pasadas, experiencias que se basan en casos  similares. Lo que nadie duda, es que esta tecnología ha venido para quedarse. Sin embargo, hasta que no se quede y se estandarice, no se podrá hacer una lista cerrada de los riesgos que implica. Lo que está claro es que a poca gente le gustan los cambios, y es porque con los cambios surgen riesgos que hasta el momento no se planteaban. El blockchain implica cambios y por lo tanto, implica nuevos riesgos. En lo que auditoría respecta, cualquier gran empresa o profesional que se quiera centrar en auditar esta nueva tecnología debe estar al tanto de los cambios que implica dicha tecnología, tanto de los casos que triunfen como de los que fracasen, y aprender de ellos. Deben ir perfeccionando la técnica de auditar según se vaya perfeccionando la tecnología.


Referencias:

[1]: Blockchain risk management (Prakash Santhana and Abhishek Biswas, 2017),https://www2.deloitte.com/content/dam/Deloitte/us/Documents/financial-services/us-fsi-blockchain-risk-management.pdf

[2]: Blockchain and Risk (Mike Small CEng, abril 2016), https://m.isaca.org/chapters8/Northern-England/Events/Documents/blockchain.pdf

 




¡R.I.E.S.G.O.S en los medios sociales! Ojo avizor!

Tal y como hemos ido introduciendo en capítulos anteriores, el uso de los medios sociales y el mundo IT traen consigo unos riesgos heredados que por lo menos, las empresas debieran de estudiar (en la hora del café al menos, ¡por favor!). Hay voces que afirman que existen dos esferas [1] de riesgos en los medios sociales: una iría por la senda de la imagen pública y otra por la efectividad operacional. Un ejemplo de andar por casa [2] podríamos encontrarlo en el caso de Nestlé con su producto KitKat y el famoso aceite de palma. La negativa y censura por parte de Nestlé de las quejas y comentarios de sus consumidores le trajeron malas pasadas. Al final, la compañía de alimentos lácteos con tilde en la ‘é’, reculó y supo ponerse en el lugar de los consumidores.

A modo de lista, me gustaría resaltar algunos riesgos [1bis] que desde el punto de vista de las corporaciones, podrían ser delicadas:

  • Campaña de desprestigio o ataques de posts negativos (prioridad media): dependiendo de quién y por qué se ha encendido esta llama (culpa de la compañía, malentendidos etc.), la empresa podría verse involucrada en una bola de nieve difícil de escapar de ella, ej. Comentario negativo en Twitter sobre tu empresa o alguna acción realizada.
  • Mal o incorrecto uso de las TIC por parte de los empleados (prioridad alta): los dos pilares que son atizados y por los que los ciberdelincuentes actúan son principalmente: ataques dirigidos (phishing, spoofing, robo de identidad, ingeniería social) y viruses, malwares, etc. En mi humilde opinión, hay que intentar concienciar a la ciudadanía y a los empleados. Para ello habría que intentar reducir los siguientes porcentajes que parece que han salido de una película de Halloween (aprovechando la ocasión y los días que nos rodean en estas fechas): más del 50% de los usuarios de medios sociales permiten a conocidos acceder con sus credenciales, 26% de los usuarios comparten ficheros o documentación de acceso restringido mediante redes sociales, 64% de los usuarios que hacen uso de los medios sociales hacen click en enlaces de los cuales no saben nada de su destino.
  • Falta de control de las cuentas corporativas para los medios sociales (prioridad media-alta): como empresa has de ser consciente de qué sitios tienes bajo tu control e intentar aumentar el grado de madurez de la seguridad de la información de tu empresa.Tendrías que preguntarte: ¿quién controla esos accesos? ¿quién monitoriza el uso del mismo?
  • Riesgo de presencia online (prioridad media): como buen lector/a tecnólogo/a que eres, sabes que hay que reducir la superficie de exposición cuanto más mejor de tu conglomerado (sistema), pero claro, siendo una empresa y de cara a mantener una red de contactos y usuarios satisfechos, has de tener presencia online (página web corporativa, página en las redes sociales: Facebook, Twitter, LinkedIn etc.). Existe un riesgo moderado de que tu presencia online sea atacada masivamente utilizando las últimas y no tan últimas técnicas de hacking.
  • BYOD (prioridad media-alta): quizá no tan relacionado con los medios sociales, pero relevante e importante a la vez. Ojito con las políticas de cada corporación en relación a infiltrar un dispositivo de fuera dentro del sistema de la empresa. ¡Quizá tengamos que ponernos escafandras y analizar al dedillo las tripas del dispositivo que traes! Jeje.

Por otro lado, como empresa has de tener frentes abiertos en todos los aspectos, ser conscientes de analizar los riesgos en diferentes casos de uso, me explico: existe un riesgo alto de ataques que puedes prevenir (mediante un diseño de una arquitectura adecuada, seguir patrones y directrices, aprenderte el informe OWASP (Open Web Application Security Project) cual biblia etc.), y estos efectivamente, sí que puedes combatirlos de antemano. En cambio, otras empresas no tienen en cuenta el riesgo de un ataque, filtración o incidencia relacionada con los medios sociales en el supuesto escenario en el que el ataque en sí es inevitable. Es decir, ¡¿qué hacemos si damos por hecho que hay algo que se nos escapa y que nos va a repercutir en la empresa?! La mentalidad sería algo así como: “Sé que (posiblemente) alguien pueda encontrar una brecha y entrar a nuestro sistema, ¿qué hacemos partiendo de esa premisa? ¿Cómo protegernos?”. Como corporación, logras un nivel de madurez en la seguridad mayor cuando tienes en cuenta ese aspecto.

Un factor, de hecho, que hace que los riesgos asociados a los medios sociales sean diferentes a otros riesgos encontrados en otras áreas IT es la velocidad. La información se extiende más rápido que cuando se te cae el vaso encima del mantel de tu madre en nochevieja. Y el careto (perdón con las licencias con el lenguaje) que se le queda al CIO al ver a la mañana siguiente que uno de tus empleados a picado el anzuelo en un ataque de phishing dirigido, es también proporcional al del 31 de Diciembre que hemos comentado. Muchas veces la ingeniería social puede resultar un arma muy accesible para los ciberdelincuentes.

El lado bueno es que parece que la concienciación y el entrenamiento de los empleados y ejecutivos de la corporación está aumentando poquito a poquito año tras año, un estudio [3] de la FERF (Financial Executives Research Foundation) muestra que mientras que en el 2011, la empresa tenía un conocimiento sobre los medios sociales y sus riesgos de un 21%, en 2013, se trata de un 36%. Así como que solo una de cada cuatro empresas tenían allá por el año 2011 políticas que regularan el uso de los medios sociales entre sus empleados, refleja otra encuesta [4].

SM_Caution_for_Invite_flat

Un estudio del 2014 mostró como un 62% de los usuarios de web, vuelcan su atención en Facebook cuando quieren interesarse o informarse sobre la política. Lo que puede ayudar a elevar la reputación de los políticos u en otras ocasiones a hundirla un poco más, un claro ejemplo de ello es la campaña presidencial [5] que me montó en torno a las elecciones del 2008 a la presidencia en EE.UU.

Varias veces escuche a un profesor del campus de Deusto de Bilbao que el eslabón más débil es la persona, ¡el usuario! Pues ciertamente, en las empresas ocurre otro tanto de lo mismo. No hay que ir mucho más lejos para corroborarlo, el ya archiconocido escándalo de Yahoo reciente donde se obtuvo información confidencial, curiosamente fue debido a la pesca!, Sí, sí, a la pesca! ¡¿Que no sabes lo que es?! Phishing! Vale, perdona, he jugado con las palabras, mea culpa. En definitiva, el phishing es un ataque bastante común y con el que se da acceso a posiblemente las entrañas del sistema con tan solo esas credenciales del empleado. Es una lástima, pero también fácil de evitar si sigues pautas adecuadas y estás ojo avizor y conciencias a tu trabajador.

Dado que un decálogo siempre es más fácil digerir para la vista  leer visualmente, os remito al siguiente enlace [6] de donde he cogido prestado algunos consejos y los he plasmado a lo largo de mi artículo de hoy (por si queréis profundizar más).

Otro aspecto que me gustaría tocar superficialmente para cerrar el telón por hoy definitivamente es un hecho que bien lo plasma Terri H. Chan [7] en su libro “Facebook and its Effects on User’s Empathic Social Skills and Life Satisfaction: A Double-Edged Sword Effect”. Se trata de que en ciertas ocasiones y segmentos de la población, la gente cuanto más tiempo invierte en Facebook, menos satisfacción sienten sobre sus vidas. La imagen que tienes sobre tu persona se deteriora cuando no ves que socialmente eres aceptado. A mi me gusta decir que Facebook, para determinadas cosas, es como un escaparate en el que solo se muestran las cosas bonitas; las otras “cosas” están bajo la alfombra, escondiditos. Muchas veces la definición de “amistad” se tercia un poco difusa en el mundo digital. Se que esta reflexión no tiene un punto de vista empresarial, pero consideré que también estaba relacionado de algún modo u otro.

Y en los próximos episodios… ¡qué hacer para mitigar los riesgos! ¡Cómo contrarrestarlos! Ponga un control en su vida.

????

Referencias:

[1] “What Every IT Auditor Should Know About Auditing Social Media”, ISACA, acceso el 4 de Noviembre de 2016, http://www.isaca.org/Journal/archives/2012/Volume-5/Pages/What-Every-IT-Auditor-Should-Know-About-Auditing-Social-Media.aspx

[2] “Caso KitKat, una mala estrategia de social media”, UVIC,  http://usr.uvic.cat/bloc/2013/04/07/caso-kit-kat-una-mala-estrategia-de-social-media/

[3] ”Social media risk”, IA Internal Auditor, https://iaonline.theiia.org/social-media-risk

[4] Anonymous, Employers are exposed to social media risks, Employers’ Law [1364-9493] 2011, Océano, pág.4

[5] ”Barack Obama presidential campaign”, Wikipedia,  https://en.wikipedia.org/wiki/Barack_Obama_presidential_campaign,_2008

[6] Savell, Lawrence. 15 Tips to Manage Social Media Risks, Risk Management 57, 2010, Océano, no.8

[7] Brian M. Gaff, Corporate Risks from Social Media, IEEE, vol.:47, 2014, pages. 13-15 (Océano)

“Social media”, Wikipedia, acceso el 10 de Octubre de 2016, https://en.wikipedia.org/wiki/Social_media

 




Brief Kanban risk management

Risk-ManagementMost of certified agile masters think that a great deal of explicit risk management becomes unnecessary when a project uses an agile approach. With a short iterations, single-minded focus on working software, heavy emphasis on automated tests, and frequent customer deliveries help teams avoid the biggest risk most projects face—that of eventually delivering nothing. Many agile projects rejects any form of explicit risk management. I think it is better always actively manage risk in any types of methodologies.

As a definition of the risk, it is the “uncertainty that matters” and if this uncertainty happen it impacts one or more objectives in either a negative (threats) or a positive (opportunities) manner. Risk management is about identifying, addressing, and eliminating sources of risk before they become a threat to the company. There is a common agile way how to manage the risks.

Identifying the risk

Risk identification is a process of creating a list of the risks that threaten the project. It is harder that we can imagine but it is still possible. We have to think accurately about uncertainties and its effects.WhyWhat

For identifying the risks, Alan Moran suggests to use the what/why approach. During each iterations you can ask a team members to brainstorm about “what” might happen and write it down. The second step will be identifying several “why’s” for each “what”.

Analyzing and prioritizing the risk

Analyzing the risk is process of assessing the likelihood and impact of each identified risk. In other words the probability of happening each risk and impact of it should be estimated. Normally it will be classified and categorized in several groups and can be based on: environmental impact, developing solutions, project budget, deadline and timelines, security, privacy and resources.

Measuring the risk

Once we have identified and classified our risks it is time to estimate them by some parameters. Normally the method of Impact and Probability is widely used. Impact – can be the number of days to be loosed after having this risk and Probability – is the chance of having that risk in percentage. By using this variable we can create a risk matrix and figure out the level of that risk. Since the impact and probability are given in a different metrics, it is better to normalize them to have exact range of that variables. By having this we can calculate the severity level of the risk. Let’s say divide the probability and impact into five levels:

Risk level matrix

Severity level and risk mitigation

After completing with risk matrix now we can determine the risk ratings (severity levels). For each level we can determine appropriate actions to mitigate the risk. Depending on what you have obtained from the matrix you can create your own severity levels and separate it let’s say to low < 5, 6 < medium < 12, 15 < high < 20 and critical = 25.

Example:
Risk: Dependent systems are incompatible during integration
Impact: 12 days, nominal – Level 2
Probability: 80% – Level 4
Severity: 2 * 4 = 8.

Since 8 is in the middle of 6 and 12 this risk should be leveled as Medium. What actions are required to mitigate this risk? You use general purpose actions from your predefined table for all the levels + some specific actions depending on this risk type, for example, search of new integration partner, research training or hiring. Tracking and monitoring all this kind of risks are called risk register.

Monitoring the risks with Burndown chart

As far as the agile Kanban requires as much as possible visualize everything it is not possible to get into real risk status with traditional models. For this case an interesting technique was introduced by John Brothers in Agile Times in 2004 11. According to this method, we should still have to do something similar like traditional technique but little bit in different way. We still have gather the risk every time and identify for each of them four main attributes: detail, probability of occurrence, the amount of day will be lost if it will occur and exposure just by multiplying the probability with size of loss.

Risk register monitor has to be created in the beginning of the project. This risk register monitor should be updated and reevaluated in every iteration, since the new risk assessments can come or the probability of existing risks can change. After that, finally the risk burndown chart will be created by plotting the sum of the risk exposure values from the iterations.

According to Mice Cohn it is recommended to sum only the top ten risks even if the team has identified more. A sample risk burndown chart can look like this:Burndown chart example

As with a regular release burndown chart, we should see a linear drop in risk over the course of the project, as shown in the red line of this next risk burndown chart.

Regular release burndown chart

When risk is not coming down at the appropriate rate the team and management should have to make some decisions and separate additional time in upcoming iterations in order to reduce the risk. These are some of the bare-minimum approaches that are effective in Agile. They’re simple to manage and align with the iterative process.