blog

La Respuesta ante Incidentes (IR) es fundamental para la gestión en seguridad de la información. Existe riesgo de ataque independientemente del nivel de detalle en la planificación y preparación. Toda organización debe decidir como gestionar apropiadamente los incidentes en seguridad al migrar hacia la nube.

La computación en la nube presenta una gran oportunidad para quienes responden ante incidentes sean más eficientes. Los sistemas para vigilancia continua en la nube inician el manejo de incidentes con mayor rapidez, y proporcionan un plan más directo de acción. Las tecnologías para virtualización y la elasticidad inherente a las plataformas en la nube pueden permitir una contención y recuperación más eficientes y eficaces, con menos interrupciones del servicio comparado con tecnologías más tradicionales.

En un entorno de Infraestructura como Servicio (IaaS), un mayor grado de responsabilidad y capacidad para detectar y responder ante incidentes de seguridad, usualmente recae en el cliente. Sin embargo incluso en IaaS existen dependencias significativas sobre el proveedor de la nube. Los datos de hosts físicos, dispositivos de red, servicios compartidos, y dispositivos de seguridad como firewalls deben ser entregados por el proveedor de la nube. Algunos proveedores ya proporcionan la capacidad de entregar esta información hacia sus clientes, y los proveedores de servicios en seguridad gestionada anuncian soluciones basadas en la nube para recibir y procesar este tipo de datos.

Con configuraciones de Infraestructura como Servicio, los cuales tienen incidentes a nivel de software, un cliente puede realizar investigaciones forenses de sus propias instancias virtuales, pero no serán capaces de investigar los componentes de red controlados por el proveedor de la nube.

Las actividades forenses estándar, como revisión de la actividad de red, acceso hacia instantáneas, o la creación de una nueva imagen sobre el disco duro, requieren el soporte del proveedor de la nube para ser exitoso. Ante los incidentes de seguridad en servicios de plataforma y software causados por la infraestructura y hardware subyacentes, el cliente de la nube depende casi completamente sobre soporte analítico del proveedor de la nube. Las roles y responsabilidades en Respuesta ante Incidentes deben acordarse en los SLAs.

Fuentes:

https://www.cisa.gov/topics/cybersecurity-best-practices/organizations-…
 

"The Phoenix Project" de Gene Kim ofrece una de las primeras y más leídas explicaciones sobre los principios clave de DevOps. Basado libremente en "The Goal: A Process of Ongoing Improvement" de Eliyahu M. Golratt, "The Phoenix Project" sigue a un grupo de personajes ficticios a través de las dificultades de un entorno tecnológico y burocrático moderno. En el libro el protagonista, Bill Palmer, asume un rol de liderazgo como nuevo vicepresidente de operaciones, donde debe enderezar el rumbo de una empresa en crisis, además de asegurar el lanzamiento exitoso de un producto para un fabricante de autopartes con dificultades. A través del libro descubre al lograr los equipos de desarrollo y operaciones trabajen en estrecha colaboración, no solo salva el proyecto, sino también impulsa a la compañía hacia niveles de éxito nunca antes descubiertos.

En el libro, Palmer conoce a un mentor misterioso quien lo guía a través de los principios conocidos como las Tres Maneras de DevOps. Estos principios permiten a Palmer y a su equipo superar el desafío.

Estas "Tres Maneras" constituyen algunos de los principios fundamentales de DevOps. En su blog Kim escribe: “Afirmamos las Tres Maneras describen los valores y filosofías enmarcando los procesos, procedimientos, y prácticas de DevOps, así como los pasos prescriptivos”.

La Primera Manera se enfoca en el flujo a través de todo el sistema, lo cual elimina barreras entre departamentos como desarrollo y operaciones, con el propósito de facilitar el flujo desde la ideación hasta la creación de valor para el cliente. Este tipo de pensamiento desplaza el enfoque fuera de ¿Cuál es mi trabajo?" a "¿Cómo se aporta valor hacia el cliente?". Cuando se visualizan sistemas de esta manera, las personas pueden empezar a buscar como maximizar el flujo y eliminar los cuellos de botella.

La Segunda Manera es sobre crear bucles para retroalimentación. Esta manera se enfoca en obtener y amplificar entradas desde los clientes para las personas construyan el producto. La Segunda Manera también incluye buscar maneras para acortar y amplificar estos bucles para retroalimentación.

La tercera manera se enfoca en impulsar la experimentación y el aprendizaje. Esto incluye construir una cultura para aprendizaje la cual reflexione continuamente sobre los errores, aprenda de estos, y utilice este aprendizaje para crecer y mejorar. En una cultura de aprendizaje, el aprendizaje se construye en la manera como la empresa opera diariamente. La Tercera Manera también busca oportunidades para impulsar la maestría a través de la repetición como parte de esta cultura de aprendizaje más amplia.

Fuentes:

http://www.realgenekim.me/blog/
https://itrevolution.com/articles/
 

En 2009 John Allspaw, entonces vicepresidente senior de operaciones técnicas de Flickr, y Paul Hammond, director de ingeniería de Flickr, presentaron su charla “10+ Deploys per Day: Dev and Ops Cooperation at Flickr”, en la conferencia O’Reilly Velocity. Ellos presentaron muchos de los conceptos para despliegue en lotes pequeños y colaboración entre desarrollo y operaciones. El blog “Una breve historia de DevOps” afirma “la charla se convirtió en un referente mundial de aquello lo cual puede lograr la colaboración entre desarrollo y operaciones”. Ese mismo año Patrick Debois introdujo el término DevOps en el evento “Devopsdays” en Gante, Bélgica. El concepto se popularizó, y en 2010 se celebró el primer Devopsdays en Estados Unidos. Posteriormente Devopsdays fue acortado al término DevOps, con el cual actualmente estamos todos familiarizados.

En 2013 Gene Kim, Kevin Behr, y George Spafford escribieron su libro, “The Phoenix Project: A Novel about IT, DevOps, and Helping Your Business Win”, el cual presentó muchos de los conceptos fundamentales conformando DevOps en la actualidad. A la misma vez, se desarrolló el "State of DevOps Report", cuyo objetivo era determinar las mejores prácticas de DevOps y sus resultados. "State of DevOps Report" se ha convertido en una fuente de información esencial para las prácticas de DevOps. En su entrada del blog "A Summary of All the State of DevOps Reports", Tom Geraghty escribe: "El primer reporte se publicó en 2013, y demostró claramente la adopción de prácticas DevOps resultaba en mejors tecnológicas y empresariales".

DevOps continuó creciendo, y en 2014 se observó un mayor crecimiento DevOps en entornos empresariales, marcada por el lanzamiento de la “DevOps Enterprise Summit (DOES)”. DOES buscaba explorar DevOps a gran escala para organizaciones grandes y complejas. Ese mismo año, el grupo el cual posteriormente desarrollaría las métricas para Investigación y Evaluación de DevOps (DORA) se asoció con Puppet Labs, para encontrar nuevas maneras de medir DevOps y sus resultados. Estas métricas se incluyeron en el “State of DevOps Report” de 2014 a 2017. La investigación y los detalles sobre estas métricas se publicaron en “Accelerate: The Science of Lean Software and DevOps: Building and Scaling High Performing Technology Organizations”, de Nicole Forsgren, Jez Humble y Gene Kim, en 2018.

Aunque la ingeniería de confiabilidad de sitios (SRE) existía desde hace algún tiempo, su uso se generalizó mucho más tarde. El término se utilizó por primera vez en Google en 2003. Ganó relevancia en el mundo de DevOps alrededor de 2015, y en 2017 LinkedIn nombró a la SRE como uno de los trabajos más prometedores del año. Solo en los últimos años DevOps ha comenzado a integrarse plenamente con la seguridad, impulsando así el auge de DevSecOps. Los reportes "State of DevOps Report" de 2017 y 2018 demostraron DevOps contribuyó a mejorar los resultados en materia de seguridad.

En la actualidad DevOps es una práctica común en casi todas las empresas, desde startups ágiles hasta compañías Fortune 500. Su alcance se está ampliando cada vez más para abarcar la seguridad, y las empresas están descubriendo como DevSecOps puede potenciar los beneficios de DevOps en el ámbito de la ciberseguridad.

Fuentes:

https://www.everythingdevops.dev/blog/a-brief-history-of-devops-and-its…
 

Las personas, procesos, y tecnología de DevOps mejoran la manera el la cual los ingenieros crean, despliegan, y gestionan sistemas técnicos, cerrando la brecha entre los equipos de desarrollo y operaciones para lanzar productos al mercado rápidamente, mientras se abordan los requisitos no funcionales como la estabilidad y escalabilidad. DevOps es un conjunto de principios para entregar valor hacia los clientes basado en los principios “Lean” y colaboración. Aunque muchas personas piensan de DevOps como una tecnología o un conjunto de tecnologías, estas son realmente un medio para un fin. Esto es, son simplemente herramientas utilizadas para aplicar mejor los principios de DevOps. DevOps incluye personas, procesos, y tecnologías los cuales utilizan para entregar valor hacia los clientes a través de productos y servicios técnicos, basados en los principios de DevOps.

Gene Kim describe DevOps: “Tomar los principios Lean, aplicarlos hacia los flujos de valor tecnológicos, y obtener patrones emergentes permitiendo a las organizaciones realizar decenas, cientos, o incluso cientos de miles de despliegues al día, preservando fiabilidad, seguridad, y estabilidad de primer nivel»”

Si se entiende DevOps como una cultura o conjunto de principios enfocados en la colaboración, se puede entender esto como la interacción o colaboración entre desarrollo, operaciones, y control de calidad.

Aunque existen muchas definiciones de DevOps, los Tres Caminos de DevOps, descritos en El Proyecto Fénix de Gene Kim, así como el modelo CALMS, creado por Jez Humble, constituyen dos de los modelos originales para comprender DevOps. Estos dos modelos explican en gran medida los principios subyacentes de DevOps.

Fuentes:

https://github.com/resources/articles/what-is-devops
https://clickup.com/es-ES/blog/143753/resumen-del-proyecto-phoenix
https://www.atlassian.com/es/devops/frameworks/calms-framework
 

DevSecOps proporciona la capacidad de entregar productos y servicios más seguros hacia el mercado rápidamente. Por décadas los ingenieros en tecnología han buscado el balance entre la velocidad de entrega con seguridad y rendimiento. DevSecOps fundamentalmente altera esta ecuación, permitiendo a las compañías entregar productos rápidamente sin comprometer la seguridad, la privacidad, o el rendimiento del sistema.

Los tecnólogos llevan mucho tiempo lidiando con el balance de calidad y velocidad, intentando responder a la pregunta: "¿Cómo se puede entregar productos al mercado rápidamente sin sacrificar la seguridad?". Con DevSecOps finalmente se tiene la respuesta, y la respuesta reside en la colaboración. DevOps y por extensión DevSecOps ofrecen el santo grial para el desarrollo y entrega de productos tecnológicos: la capacidad para construir productos fiables, seguros, y factibles de ser mantenidos sin sacrificar la velocidad para comercializarlos.

DevSecOps proporciona una fundamentalmente nueva perspectiva para seguridad. Este enfoque se aleja de la perspectiva de control tradicional, trasladando las responsabilidades hacia las primeras etapas del pipeline para desarrollo. Trabajando con los desarrolladores es posible integrar la seguridad a través de las aplicaciones y servicios técnicos más fácilmente. A través de la automatización y educación un ingeniero puede incorporar prácticas de seguridad en muchas aplicaciones. Garantizando estas prácticas de seguridad se incorporan desde las primeras etapas del desarrollo, se puede reducir el esfuerzo necesario para crear productos seguros. En efecto, al adoptar un enfoque DevOps para la seguridad, se puede reducir la fricción de la seguridad y cumplimiento normativo, además se multiplica el trabajo del equipo de seguridad.

La ciberseguridad nunca antes ha sido tan crucial como en la actualidad. El número de ciberamenazas continúa creciendo. Actualmente se enfrenta un número creciente de amenazas, y las brechas de seguridad tienen un impacto aún mayor.

Con la creciente prevalencia del trabajo remoto y los equipos globales, la superficie de ataque continúa expandiéndose. Ya no es posible simplemente proteger el perímetro de la red; se debe proporcionar seguridad en cada nivel conforme se avanza hacia enfoques como la defensa en profundidad y la confianza cero.

Además se observa un número creciente de atacantes y una mayor sofisticación de las técnicas. El número de atacantes continúa creciendo al unísono crece la disponibilidad de herramientas para lanzar ataques. La disponibilidad de estas herramientas implica se requiere menos habilidad para lanzar ataques. Actualmente un atacante novato puede rentar una flota de computadoras zombis en la Dark Web, y lanzar un ataque para denegación de servicio distribuido (DDoS) en cuestión de minutos. En adición a la proliferación de atacantes, también se observa una creciente sofisticación de los atacantes. Actualmente los principales actores de amenazas incluyen el crimen organizado, como también algunos estados o naciones utilizando la ciberdelincuencia como arma de guerra.

Para combatir este panorama de amenazas en crecimiento, no únicamente se necesitan nuevas herramientas, se necesita una fundamentalmente nueva perspectiva. DevSecOps proporciona lo necesario para combatir estas amenazas emergentes. Al adoptar una perspectiva colaborativa de la seguridad, se podrá estar en la capacidad de aprovechar el poder de toda la organización tecnológica para la seguridad, en lugar de depender de un solo equipo dentro de la organización. Adicionalmente tecnologías como integración continua y el desarrollo continuo (CI/CD) permiten integrar la seguridad directamente en el pipeline de despliegue.

Fuentes:

https://developer.ibm.com/articles/devsecops-what-and-why/
 

Las anotaciones y reportes (los cuales deben ser el resultado final desde las anotaciones) son valiosos tanto para el investigador cuanto para los clientes. Estas pueden demostrar el profesionalismo y alto grado de servicio al cliente, proporcionándole únicamente aquello lo cual solicitó (¡o exceder las expectativas del cliente!). Estas son la última impresión lo cual el cliente tendrá sobre el trabajo realizado. Pues no sería agradable un proveedor entregue un reporte creado con plantilla el cual tenga poco valor, además conteniendo errores tipográficos y gramaticales. Esto generaría un gran fastidio y decepción por el dinero desperdiciado en su creación. Esta empresa consecuentemente jamás volvería a realizar un contrato. Se debe elaborar un reporte con el cual el investigador y la compañía se sientan orgullosos, aportando valor al cliente.

Algunas veces OSINT puede ser utilizado como contenido de referencia en un blog o artículo noticioso. Tener los detalles sobre cual contenido fue descubierto, en cual sitio web, y en cual día podría ser importante para la narrativa general de la historia.

Cuando se entregan los reportes, muchas veces es el final del trabajo para un cliente específico. O quizás la investigación de tal persona llegue a su fin y ahora se debe investigar al siguiente objetivo. En tres o seis meses, o incluso un año, el cliente podría indicar lo demandará y utilizará el reporte OSINT como evidencia. Tal vez solicitaron las anotaciones al entregar el reporte, y continuaron el trabajo sin el profesional, o quizás requieran se retome el trabajo anterior y sea continuado después de un año. Incluso podría llamar al investigador para declarar en un juicio. Con grandes anotaciones se puede tener más éxito.

También pueden existir investigaciones ejecutadas en apoyo a las fuerzas del orden, a un cliente de inteligencia, o a un equipo legal. Este trabajo podría requerir una documentación de un mayor nivel, de tal manera el trabajo pueda ser utilizados en el sistema judicial o para apoyo en actividades de inteligencia.

Fuentes:

https://www.forensicnotes.com/osint-tools/
https://medium.com/@pizzasteve/a-practical-osint-methodology-tools-note…
 

Con una mejor idea de porque un cliente requiere el trabajo sea completado, es posible aún se tengan preguntas las cuales necesitan ser respondidas sobre el procedimiento. ¿Qué tipo de resultado desea el cliente?. Algunos únicamente desean una respuesta simple a su pregunta, y otros pueden requerir detalles adicionales o un reporte completo. Algunas compañías requieren un reporte sea producido para cada investigación OSINT, a menos el cliente firme una exención indicando no necesita uno. Asegurarse de comprender estos requerimientos de reporte antes del contrato.

¿Tiene sel cliente directrices específicas sobre como necesitan ser almacenados los datos recolectados durante la evaluación? ¿Necesitará utilizar encriptación cuando los datos residan en la computadora? ¿Qué desea el cliente sea hecho con las anotaciones, reporte, y evidencia de respaldo después de la evaluación sea completada? ¿Deberían ser desechados? ¿Deberían ser conservados durante cierto tiempo en caso el cliente los necesite?. Es importante formular estas preguntas.

Otro tópico el cual debe abordarse es: ¿Qué nivel de encubrimiento desea el cliente se mantenga durante el trabajo? ¿Se necesita convertirse en un experto en OSINT y no dejar rastro sobre el trabajo de investigación, o se permitirá interactuar con el objetivo?. Es importante hablar con el equipo legal y asegurarse el cliente haga lo mismo antes de interactuar con el objetivo. Mientras se discuten las interacciones, es común amigos y familiares de los objetivos tengan perfiles menos seguros. ¿El cliente permite investigar a las personas cercanas al objetivo? ¿Y contactarlas en redes sociales? Preguntar.

Fuentes:

https://sosintel.co.uk/evaluating-osint-why-it-matters-and-how-to-do-it…
 

Comprendiendo mejor porque las personas utilizan OSINT, se necesita analizar OSINT desde la perspectiva de los clientes. Ellos ven en la televisión y las películas como se logran hazañas increíbles en segundos usando computadoras y simples consultas en internet. Sí, esto algunas veces puede ocurrir en las evaluaciones. Antes de iniciar la investigación se deben comprender las motivaciones de los clientes para realizar una investigación OSINT. Se necesita educar a los clientes sobre aquello lo cual se puede hacer, debido a limitaciones de tiempo, restricciones éticas y legales, ademas de otros factores, como también aquello lo cual no se puede hacer dentro del alcance de la evaluación. Se presentan a continuación algunos de estos aspectos, y como se podría explicar a los clientes.

Usualmente existe una razón por la cual los clientes requieren una investigación OSINT. Durante la reunión previa al contrato, se necesita comprender cuales preguntas desean sean respondidas por el trabajo realizado.

Algunas veces los clientes solicitarán un reconocimiento general realizado en preparación para algún otro evento (como una fusión con otra empresa). En otras instancias los clientes tendrán preguntas específicas. Algunos ejemplos son:

“¿Me está engañando mi pareja?”

“¿Realmente resultó herida la persona en su accidente automovilístico?”

“¿Quién es la niñera potencialmente contratada?”

“¿Quiénes son los amigos de una persona y cuales creencias religiosas y sociopolíticas comparte ese grupo?”

Se necesita indagar cual es el significado para los clientes una evaluación exitosa. Por ejemplo si alguien solicita averiguar si su pareja es infiel, podría considerar un resultado negativo (es decir no se encuentran pruebas de infidelidad), tan válido como uno positivo (es decir sí existen pruebas de infidelidad). Averiguar aquello buscado por el cliente cliente y asegurarse de la investigación aborde estos temas.

OSINT puede utilizarse para bien o para mal. Preguntar al cliente los “porques” de la evaluación. ¿Porqué requiere se realice la investigación? ¿Porqué le preocupa o no la persona buscada?. Esto puede brindar información valiosa para comenzar. Asegurarse de sentirse cómodo con el cliente y comprender aquello lo cual solicita. Sería lamentable encontrar la persona buscada por el cliente e informara de su ubicación, únicamente para descubrir la semana siguiente dicha persona ha sido agredida o algo peor.

Cuando corresponda se recomienda consultar con un abogado antes de iniciar investigaciones menos convencionales. Cumplir con las leyes locales, estatales, y nacionales es fundamental para el profesional y el negocio.

Fuentes:

https://smartintelligence.eu/about-osint-services/how-can-osint-be-usef…
 

El riesgo se refiere al grado de incertidumbre o expectativa de potencial daño el cual un evento adverso puede causar hacia el sistema o sus recursos, bajo condiciones específicas. Alternativamente el riesgo puede también ser:

• La probabilidad de ocurrencia de una amenaza o un evento el cual dañe, cause pérdidas, o tenga otros impactos negativos sobre la organización, ya sea por responsabilidades internas o externas.
• La posibilidad de amenaza actúe sobre una vulnerabilidad interna o externa, y cause daño hacia un recurso.
• El producto en la probabilidad de un evento ocurra, y el impacto el cual este podría tener sobre un activo de tecnología de información.

La relación entre Riesgo, Amenazas, Vulnerabilidades, e Impacto es la siguiente:

RIESGO = Amenazas x Vulnerabilidades x Impacto

El impacto de un evento sobre un activo de información es el producto de la vulnerabilidad en un activo, y el valor del activo para sus partes interesadas. El riesgo TI puede ser expandida a:

RIESGO = Amenaza x Vulnerabilidad x Valor del Activo

De hecho el riesgo es la combinación de los siguientes dos factores:

• La probabilidad de ocurrencia de un evento adverso
• La consecuencia del evento adverso

Nivel de Riesgo

El nivel de riesgo es una evaluación del impacto resultante sobre la red. Existen varios métodos para diferenciar los niveles de riesgo dependiente de su frecuencia y gravedad. Uno de los métodos comunes utilizados para clasificar los riesgos es desarrollar una matriz bidimensional.

Para analizar los riesgos, es necesario determinar la frecuencia o probabilidad en la ocurrencia de un incidente (probabilidad), y sus posibles consecuencias. Esto es referenciado como el nivel de riesgo. El riesgo se puede representar y calcular utilizando la siguiente fórmula:

Nivel de Riesgo = Consecuencia x Probabilidad

Los riesgos son categorizados en diferentes niveles acorde a su impacto estimado sobre el sistema. Principalmente existen cuatro niveles de riesgo, lo cual incluye extremo, alto, medio y bajo. Recordar las medidas de control pueden reducir el nivel de riesgo, pero no siempre lo eliminan completamente eliminan el riesgo.

Matriz de Riesgo

La matriz de riesgo mide la probabilidad de ocurrencia o probabilidad de un riesgo, junto con sus consecuencias o impacto. Es la presentación gráfica de la severidad del riesgo y la extensión para el cual los controles pueden o podrán mitigarlo. La matriz de riesgo es uno de los procesos más simples utilizados para incrementar visibilidad del riesgo; contribuye a la capacidad de toma de decisiones por parte de la gerencia. La matriz de riesgo define varios niveles de riesgo, y los categoriza como el producto de la probabilidad negativa y severidad negativa. Si bien existen muchas matrices de riesgo estándar, cada organización debe crear las propias.

La tabla anterior es la representación gráfica de una matriz de riesgo, la cual se utiliza para visualizar y comparar riesgos. Diferencia los dos niveles de riesgo y es una manera simple de analizarlos.

• Probabilidad: La posibilidad del riesgo ocurra
• Consecuencia: La severidad de un evento de riesgo ocurra

Anotación: Este es un ejemplo de matriz de riesgo. Las organizaciones deben crear sus matrices de riesgo individuales basadas en los requerimientos del negocio.

Fuentes:

https://csrc.nist.gov/glossary/term/cybersecurity_risk
https://www.ibm.com/think/topics/cybersecurity-risk-assessment
 

La defensa en profundidad es una estrategia de seguridad en la cual los profesionales en ciberseguridad utilizan muchas capas de protección a través de un sistema de información. Esta estrategia utiliza el principio militar sobre es más difícil para un enemigo derrotar un sistema de defensa complejo y de múltiples capas comparado con penetrar una sola barrera.

La defensa en profundidad ayuda a prevenir ataques directos contra un sistema de información y sus datos, pues una irrupción en una capa únicamente conduce al ciberatacante hacia la siguiente capa.

Si un hacker gana acceso hacia un sistema, la defensa en profundidad minimiza cualquier impacto adverso y proporciona tiempo a los administradores e ingenieros para implementar medidas correctivas nuevas o actualizadas para prevenir una nueva ocurrencia de la intrusión.

Fuentes:

https://en.wikipedia.org/wiki/Defense_in_depth_(computing)
https://csrc.nist.gov/glossary/term/defense_in_depth