From Waterfall to Scrum

The purpose of this post is to share my personal experience implementing Agile and DevOps methodologies on a development department that was working on waterfall approach.

Around one year ago the organization decided to move to agile development methodologies using a DevOps approach, with the help and guidance from an external company.

At first it was not easy to change the habits acquired over several years of project and was required a re-learning process for all project stakeholders; starting by the developers, following by the business and ending by the middle management.

For me personally, it supposed to start playing the role of Product Owner being my main task to help business owners on the definition of the goals and priorities for the medium and long terms and, on the other hand, I was carrying those objectives and priorities to the DevOps team creating and maintaining a prioritized backlog of user stories to be implemented.

Another important point was the adoption of the scrum rituals, from the 15’ daily scrum meeting to the bi-weekly demo in which the team can receive direct feedback from business about the new features developed. But I think the most important one was the retrospective where the team meets once every two weeks to make self-criticism devising and testing changes on the way they work with the objective of improving their results. Is this ritual the one that guarantees the continuous improvement for the DevOps team.

On the other hand, the move to DevOps supposed to add into the team infrastructure profiles so the team was fully autonomous to work without requiring other teams to provide systems, databases or other infra or technology pieces. So now, on each DevOps squad we can find a mix of developers, systems engineers, DBAs and other profiles. It has also meant that is the same team who provides the support on 24/7, so they are really motivated to deliver tested and quality code/systems.

Now, over a year after the start of this trip from waterfall to DevOps I really think it was a great success. I would summarize the greatest benefits as:

• Every Squad in the team is empowered and autonomous enough so teams are more motivated resulting in a clear productivity increase.
• There is a very big reduction of waste in managing teams and interactions between development and operation/infrastructure teams.
• The business receives more frequently deliverables and can provide feedback more regularly.
• There is an important reduction of the waste in drafting complex functional requirements that will eventually be changed in the future. Instead, user stories occur at the last moment, dedicating the necessary time and just before the team really start working on them (just on time stories creation).

As conclusion, I will say that to move to an agile way of working is the right decision if you need to run long projects with a big chance of having changing requirements but the main point is to have the support and commitment of the management for do such kind of big cultural and organizational change.

Mitigating Pass the Hash attacks

Pass the hash is not a new attack but a really old lateral movement kind of attack that has been exploited by attackers during the last 15 years. However, still today is really effective in Windows networks.

The purpose of this post is to give you an overview of how this attack works and what are the main security controls that you could put in place to prevent or mitigate it.

The attack consist on getting the password hashes from a compromised system and reuse it to get access into other systems of the network. This attack is possible in Windows due to how the NTLM protocol works; attackers can use the hash of a password to authenticate to remote services without needing the plaintext password or without having to undertake dictionary or brute-force attacks on the hash itself.

It’s not possible to prevent completely attackers using this technique in our Windows infrastructure, but there are some mitigation controls that we can put in place. These are the security controls recommended by Microsoft for that purpose:

• Restrict and protect high privileged domain accounts
• Restrict and protect local accounts with administrative privileges
• Restrict inbound traffic using host-based firewall

Let’s review each of them.

Mitigation 1: Restrict and protect high-privileged domain accounts

This mitigation reduces the risk of administrators inadvertently exposing privileged credentials to higher risk computers.

The idea is to restrict high-privileged accounts like domain and enterprise admin accounts from being used to authenticating to less trusted computers. So the admins should use less privileged admin accounts to perform their regular tasks instead of using high-privileged accounts. It’s important as well not schedule tasks or configure services with privileged accounts on lower trust computers.

The rationale behind this control is that an attacker cannot steal credentials for an account if the credentials are never used on the compromised computer.

This mitigation can only be technically enforced from Windows Server 2012 R2. Prior to this version, could only be enforced by policy or procedures.

Mitigacion 2: Restrict local accounts with administrative privileges

This mitigation restricts the ability of attackers to use local administrator accounts for lateral movement PtH attacks.

The idea is to enforce the restrictions available to prevent local accounts from being used for remote administration by explicitly deny network and Remote Desktop logon rights for all administrative local accounts.

On the other hand, as Windows is not using Salt for calculating the hashes or the passwords, local accounts with administrative privileges should have a unique password for each system.

With this control in place, an attacker who successfully obtains local account credential from a compromised computer will not be able to reuse those credentials in other computers on the organization’s network.

Mitigation 3: Restrict inbound traffic using a host Firewall

This mitigation restricts the ability of attackers to initiate lateral movement from a compromised workstation by blocking inbound connections.

The idea is to restrict all inbound connections to all workstation except for those with expected traffic originating from trusted sources. Using a ‘whitelisting’ approach in terms of sources and protocols will prevent an attacker who successfully obtains any type of account credentials to be able to connect to other workstations.

Other windows features that can help

Other windows features that could be useful to prevent an attacker from stealing or using stolen credentials are:

• Enforce credential removal after logoff
• Remove LAN Manager hashes from LSASS
• Remove plaintext credentials from LSASS for domain accounts
• Protected Users security group
• Authentication Policies and Silos
• LSA protection-theft
• Disable Automatic Restart Sign-on (ARSO) Routine

More info and conclusion

In that link: https://technet.microsoft.com/en-us/security/dn785092, you can find extensive information and more details about those MS features as well as deeper information about how and why the PtH attack works and how to prevent or mitigate it.

It’s important to keep in mind that there is no silver bullet for the PtH attacks. Technology alone cannot solve that problem, so people and processes become critical elements in any corporate defense program. The proposed security controls must be enforced and integrated into a comprehensive security approach that should include security awareness, security monitoring and incident response readiness.

Risk Assessment for Critical Infrastructures

The problem

In the past I did several risk assessments for different type of companies, including some that could be considered as critical infrastructures. For this reason I’ve spent some time reviewing different approaches to perform risk assessments in this kind of infrastructures and I found most of them maintain the classical approach of identify threat and vulnerabilities to estimate the likelihood, using the product of likelihood and impact to get the risk.

I think it’s the right approach for the Known risks, I mean the risks that we can easily think about. However, these approaches have a big weakness since if you can’t imagine a possible treat source or you don’t consider a given vulnerability you won’t take into consideration some important risks.

The cause

And this is because when we analyze the risks of Critical infrastructures, and it could happen in other organizations as well, we should consider some risks that may have an enormous impact but it’s really difficult to think about it since it haven’t happened never before.

Yes, we are talking about the risks defined by the Black Swan Theory, so these risks that are so hard to predict because they are beyond the realm of normal expectations.

Some well-known real examples could be the terrorist attacks of 11/09 in NY or the 11/03 in Madrid, but we can find also some nice technologic examples such the ‘Equation Group’. Who could imagine such kind of advanced malware in our hard disks firmware? I never consider this kind of risks when I did risk assessments because I couldn’t anticipate it, but it’s something that was happening during years!

So it’s clear that if you want to have a heuristic approach to risk assessment, and I really think we must have this kind of approach if we talk of critical infrastructures, we can’t use only the classic risk assessment methodologies because it’s impossible to consider all the possible threats or all the possible risk scenarios. Doesn’t matter how experts we are. Even if you could use all the experts in the world and you get all the time and budget to do your risk assessment you will ever forget some risks because the possible risks are nearly infinite.

The solution (or at least my proposal)

My proposal to solve this problem is to complement any of the classical methodologies (the one that you prefer) with a holistic approach. As we said, the problem is that we can’t imagine all the threats and we can’t define their likelihood so let’s stop to loss time trying to get it. I propose to forget these vectors and perform our risk assessments only based in the impact. Let’s forget about threats and vulnerabilities since we can’t identify all of it and we can’t quantify their probability.

Examples and conclusion

Let’s illustrate the idea with some examples.

Example 1: In a classical risk assessment you will think about how your competitors could try to enter in your network to get your strategic and confidential information. This exercise of ‘think as your enemies’ could be really useful to detect the ‘known risks’ and prepare controls and countermeasures and prioritize their implementation according to the cost-benefit analysis.

But you can go beyond this and on top of this classic approach assume that your network has been already powned and your confidential information has been stolen by your competitors. Don’t waste time thinking how, you already did it in your classical approach. Doesn’t matter how, the fact is that it already happen. So the risk is that your confidential information is in your competitor’s hands and then my proposal is to focus in countermeasures and controls to mitigate the impact. In this example, some controls could be strong encryption, honey-documentation (fake documentation to introduce noise..), etc..

Example 2: Other example can be a nuclear plant. They can use the traditional risk assessment approach to prevent and mitigate the known risks, but for sure, they must establish controls to prevent their industrial system being exploited by a threat that wasn’t taken into consideration in their risk assessment. They need to establish controls to prevent security incidents if their controls to segment their IT network and their industrial network are compromised.

They must consider any unexpected unknown risks and the only way that I can see to do that is to be totally focus in the possible impacts avoiding considering the classic threat-vulnerability approach for that unknown risks.

For sure you will find a lot of additional examples where this ‘impact only’ approach could be useful to complement the traditional risk assessment and try to manage these black-swans in your organization.

I really hope you enjoy this post and I’ll be interested in heard your feedback and thoughts about it.

Algunos "Quickwins" en seguridad de la información

En algunas organizaciones existe una fe ciega en que el mejor camino para mejorar la seguridad es gastar más y más dinero en hierro y licencias. Más firewalls, más IDS y el WAF más caro. Sin embargo, en este post me gustaría repasar tres actividades básicas para mejorar la seguridad de una organización, que no necesariamente requieren comprar ningún hardware o software adicional.

La primera de estas actividades es el bastionado de los sistemas. Bastionar o asegurar correctamente un sistema no es una tarea complicada. Existen multitud de guías específicas sobre cómo bastionar sistemas concretos, pero incluso realizando un bastionado básico se puede incrementar en gran medida la seguridad de una infraestructura sin tener que invertir un esfuerzo desmesurado en ello. Los pasos básicos a seguir para bastionar un sistema son:

• Elimina o al menos deshabilita los servicios de red y los programas innecesarios, dejando únicamente habilitados aquellos que son necesarios para que el sistema desempeñe su labor. De esta manera se reduce drásticamente la superficie de exposición del sistema.
• Revisa los usuarios existentes en el sistema, cambiando contraseñas por defecto y minimizando los permisos de cada usuario de manera que tengan los mínimos necesarios para desarrollar sus actividades.
• Documenta los servicios de red necesarios y los puertos usados por cada uno de estos servicios. Esta documentación será de mucha utilidad para diseñar las reglas a implementar en los firewalls de red.
• Mantén el sistema actualizado al último nivel de parches de seguridad publicados por el fabricante. Esta actividad es básica para prevenir que un atacante utilice vulnerabilidades conocidas para comprometer la seguridad del sistema.
• Instala y mantén un firewall en el servidor (puede ser el propio firewall de Windows o un IPtables en el caso de linux) permitiendo únicamente el tráfico entrante y saliente que sea estrictamente necesario. Filtrar el tráfico entrante permite garantizar que aunque algún servicio no necesario se haya dejado habilitado por error, éste no será accesible desde la red. Filtrar el tráfico saliente puede permitir mitigar el impacto causado por una infección de malware que intente abrir conexiones salientes, y prevenir la fuga de datos usando conexiones de red a servicios que el servidor realmente no requiere.

Otra actividad básica a desarrollar es definir, implementar y mantener un programa de gestión de vulnerabilidades adecuado para la organización.

Si queremos gestionar las vulnerabilidades de nuestros sistemas, debemos seguir los siguientes pasos básicos para su correcta gestión: detectarlas, clasificarlas, priorizarlas, asignarlas, resolverlas y verificar su correcta resolución: 

1. Detectar: Hay múltiples fuentes o vías que debemos usar para detectar las vulnerabilidades existentes en nuestros sistemas. Las más comunes serán los avisos de alerta temprana de CERTs o de los propios fabricantes, los resultados de los escaneos de vulnerabilidades periódicos que se deberían realizar sobre la infraestructura y las aplicaciones y los resultados de las pruebas de penetración que se realicen.
2. Clasificar: Una vez detectada una vulnerabilidad, el siguiente paso a realizar debería ser clasificarla según el riesgo que suponga para nuestra organización. Para ello, se deberían considerar factores como el impacto que podría suponer, y la facilidad de explotación. Dado que la resolución de vulnerabilidades es un proceso que puede llevar días, semanas o incluso meses, aquellas vulnerabilidades que sean consideradas más críticas deberían ir acompañadas de un plan de acciones compensatorias para mitigar el riesgo que suponen hasta que sean definitivamente solventadas.
3. Priorizar: Una vez clasificadas según su riesgo, deberán priorizarse. Estos es, definir un tiempo límite en el que cada vulnerabilidad debería estar resuelta. El estándar de seguridad en datos de tarjetas de pago PCI DSS propone un mes de tiempo límite para las vulnerabilidades más críticas y tres meses de tiempo límite para el resto. En cualquier caso, tanto los niveles de clasificación como los tiempos de resolución deberían adaptarse a la realidad de cada organización.
4. Asignar: El siguiente paso es asignarlas. Es decir, determinar de quien es la responsabilidad de resolver cada una de las vulnerabilidades dentro del plazo correspondiente.
5. Resolver: El responsable de resolver cada vulnerabilidad deberá encontrar la solución a la misma, seguir el proceso de la organización para la gestión de cambios, es decir, probarla adecuadamente para descartar cualquier impacto negativo derivado de ésta y proceder a su resolución.
6. Verificar: Por último, se debe verificar que la solución resuelva la vulnerabilidad de manera eficaz.

Por último, quisiera hablar de la concienciación en seguridad de la información dirigida a los empleados y proveedores de la organización.

Más de una vez he oído a profesionales de seguridad argumentando que las acciones de concienciación no son efectivas y que por mucha concienciación que se realice, el factor humano seguirá siendo el principal riesgo de cualquier organización. Mi opinión al respecto es que la concienciación sí es efectiva e indispensable,  aunque no por ello suficiente. Dicho de otro modo, es cierto que concienciar al personal no elimina los riesgos de seguridad que provienen de errores humanos pero sin duda los mitiga y en todo caso evita que los usuarios puedan escudarse tras el desconocimiento al perpetrar ciertos tipos de acciones que comprometan la seguridad de los activos de información de la organización.

Por supuesto, existen más acciones que se pueden llevar a cabo sin una gran inversión económica para aumentar el nivel de seguridad de las organizaciones, como por ejemplo segmentar correctamente la red, establecer procesos de desarrollo seguro, de gestión de cambios, de respuesta ante incidentes, etc. Sin embargo, los tres propuestos considero que son una excelente base por la que empezar a mejorar la seguridad de nuestra organización.

[Some] Challeges for today's CISOs

The life of CISO could be really hard. His responsibilities include to predict and to protect the organization of all the risks that may affect the security of their information assets, detect and respond appropriately to security incidents, manage security infrastructure of their organization, manage all lifecycle of technical vulnerabilities and ensure compliance with laws, regulations and standards of information security.

If all this is not complex enough, they must to do it with a short budget because is really difficult to predict or even to calculate the ROI of security investments. And it’s here where we can find the ‘security paradox’: if there are no security incidents in the company, it’s because the good job of the CISO or just because there are not real threats and the company is wasting money in security? And in this crisis times, if senior management does this question, we can imagine how it will finish the most of the times.

In my opinion, the best way those CISOs can justify its budgets if by doing a risk analysis presenting the ROI as risk reduction. However, the result of the risk analysis should be presented in the senior management language; $$$. They need to establish a financial quantitative value to each risk, justifying it correctly and considering the business context of the risk. And this is other complicate point because not ever is easy for the CISO to have the information and knowledge about the business context to correctly translate security risks into business risks. And this drives us to another problematic topic in the CISOs world; too much data but lack of information. CISOs (or their teams) must to manage a lot of events from security devices, systems and applications, vulnerability scanning results, Pentest results, new vulnerabilities, new techniques, new technologies, new vendors, new standards, regulations and laws, etc..

Be able of manage all this amount of data and convert it in useful information is one of the big challenges that must afford information security departments today. To centralize, correlate and analyze on time this data is an important first step to convert it in useful security information.

Generate alerts to react on time when security incidents happen or to analyze the trends to detect anomalies is going one step further and we can say the security information is becoming security intelligence.

But this is not enough. CISOs need to do one additional step and transform the security information and intelligence into business intelligence, being able of establish quick and correct relationships between security risks and business risks. So, the true challenge for the CISO is be able to report on real time to senior management what are the business risks providing update information to them to make correct decisions having information about all the risks of their business (information security, physical security, financial risks, operational risks, etc..).

Once CISOs will have solutions to make this transformation of security data into business intelligence in an efficient way their life will be easier since their budgets will be self-justified. Or looking it from the other perspective, the senior management will have enough information to establish proper information security objectives and so, the will be able to assign the appropriate budget for the achievement of this goals.

So, in conclusion, a good CISO must be correctly balanced between technical and management skills, as well as to have a good understanding of the business being able to communicate with technical and business people meanwhile he is responsible or the information security topics where what happens today has nothing to do with what will happen next year, or what is the same, in two weeks.

[Algunos] Retos de un CISO en el mundo actual

La vida del CISO (Chief Information Security Officer) o responsable de Seguridad de la Información antes de que nos invadieran las siglas anglosajonas, es una vida realmente dura. Entre sus responsabilidades se encuentran prever y proteger a la organización de todos los riesgos que puedan afectar a la seguridad de sus activos de información, detectar y responder de manera adecuada ante los incidentes de seguridad, gestionar la infraestructura de seguridad de su organización, gestionar todo el ciclo de vida de las vulnerabilidades técnicas y garantizar el cumplimiento con las leyes, regulaciones y estándares pertinentes en materia de seguridad de la información.

Pero si todo esto no os parece un reto suficientemente complicado, hay que añadir que el CISO tiene que afrontarlo con presupuestos generalmente muy ajustados o por debajo de lo necesario debido a lo difícil que es predecir el ROI de las inversiones en seguridad. Y no sólo es difícil predecirlo, sino que en muchos casos también es harto complicado medirlo una vez la inversión se ha realizado. Y es que aquí nos encontramos con la llamada ‘paradoja de la seguridad’ y que se da cuando en una organización no se están produciendo incidentes de seguridad. Cuando esto ocurre, la dirección de la empresa puede dudar si la falta de incidentes se debe a la inversión realizada o si seguirían sin tener incidentes aunque redujeran el presupuesto dedicado a seguridad. Y este tipo de dudas, en los tiempos de crisis que vivimos, ya sabemos cómo suelen acabar.

En mi opinión, la mejor manera que tiene un CISO de justificar sus presupuestos es realizar un análisis de riesgos presentando el ROI de la inversión de seguridad en forma de reducción del riesgo. Sin embargo, el resultado de estos análisis de riesgos se debe presentar en el idioma que la dirección entiende: $$. Hay que poner un valor cuantitativo y económico a cada riesgo, justificándolo adecuadamente y teniendo en cuenta el contexto del negocio. Y este es otro punto realmente complicado, ya que en muchas ocasiones el CISO no dispone de la información y el conocimiento del contexto de negocio para poder trasladar correctamente los riesgos de seguridad a impactos económicos para el negocio. Y esto nos lleva a una nueva paradoja del mundo de los CISO; les sobran los datos pero les falta información. Y es que el exceso de datos es otro de los mayores problemas con los que tiene que lidiar un CISO (o su equipo); eventos generados por multitud de dispositivos de seguridad y sistemas, resultados de escaneos de vulnerabilidad y pruebas de penetración, nuevas vulnerabilidades, nuevas amenazas, nuevas técnicas y tecnologías aparecidas en el ámbito de la seguridad de la información, etc...

Ser capaces de lidiar con toda esta cantidad de datos y ser capaces de transformarla en información útil, es uno de los grandes desafíos a los que se enfrentan los departamentos de seguridad de la inforamción. Ser capaces de centralizar, correlacionar y analizar a tiempo la información es un primer paso sin duda importante para ser capaces de convertir los datos en información. Generar alertas que permitan reaccionar a tiempo ante incidentes de seguridad, o análisis de tendencias que permitan detectar anomalías va un paso más allá y permite convertir esa información en inteligencia de seguridad. Pero el auténtico reto para el CISO es dar aún un paso adicional y ser capaz de transformar esa información y esa inteligencia de seguridad en inteligencia de negocio, siendo capaz de relacionar de una manera rápida y acertada esos riesgos e incidentes de seguridad con el impacto real que tenga para el negocio. Es decir, el auténtico desafío que deben encarar ahora los responsables de seguridad de la información es el de ser capaces de reportar en tiempo real a su dirección cual es el riesgo para el negocio que se está derivando de los riesgos de seguridad de la información, de manera que la dirección pueda contar con información actualizada e integral de los riesgos que afectan a su organización, independientemente de su origen (financieros, de seguridad física o de la información, de cumplimiento, de evolución de los mercados, de evolución de la competencia, etc..). Una vez los CISO puedan contar con herramientas que les permitan realizar esa transformación de datos a inteligencia de negocio de una manera eficiente, su vida será un poco más sencilla puesto que la justificación de sus presupuestos caerá por su propio peso. O visto desde la otra perspectiva, la Dirección del negocio contará con la información suficiente a la hora de tomar decisiones sobre qué objetivos concretos de seguridad exigirán al departamento de seguridad de la organización y, por lo tanto, que partida presupuestaria le asignarán para el cumplimiento de esos objetivos.

Así pues, en resumen, un buen CISO debe disponer de un correcto equilibrio entre habilidades técnicas y habilidades de gestión y conocimiento del negocio, teniendo capacidad para lidiar tanto con el personal técnico como con la dirección de la compañía mientras mantiene bajo su paraguas un alcance realmente amplio de responsabilidades en este apasionante mundo de la seguridad de la información dónde lo que ocurre hoy nada tiene que ver con lo que estará pasando el año que viene, o lo que es prácticamente lo mismo, de aquí a dos semanas. J