Avances en la Infraestructura en Nube

Body

Al igual a la seguridad de red tradicional, es vital tener visibilidad en el tráfico de la red virtual. Similar a los conmutadores físicos están configurados para vigilar el tráfico de red, los conmutadores virtuales se utilizan para vigilar y administrar el tráfico hacia y desde las máquinas virtuales. Al igual a los dispositivos físicos, los conmutadores virtuales también deben configurarse para operar en modo promiscuo con el propósito de vigilar el tráfico de red.

Las APIs son un elemento esencial en la computación en nube. Las APIs en nube permiten plataformas virtuales aprovechen localmente los recursos y la funcionalidad de computo de potentes aplicaciones remotas. Utilizando aplicaciones para el lado del servidor, las APIs pueden acceder hacia librerías y repositorios desde una variedad de lenguajes de programación, incluyendo plataformas móviles. Las APIs sirven como bloques de construcción de muchas aplicaciones de software sofisticadas y complejas.

En una nube privada la organización posee la infraestructura de hardware soportando y hospedando los sistemas en la nube. Muchas entidades gubernamentales y organizaciones comerciales requieren sus datos sean almacenados sobre sistemas los cuales únicamente las soportan como también sus actividades. Las infraestructuras de nube privada cumplen con este requisito.

En un modelo de nube pública, la infraestructura y el hardware soportando la nube son propiedad de una organización separada o un tercero. Con los modelos de nube pública, es muy importante considerar las necesidades de la organización, los requisitos para protección de los datos gestionándose, y cuales componentes son propiedad de un proveedor externo de nube pública. Una nube híbrida combina ambos modelos.

Mientras la infraestructura en la nube se compone de hardware y software requerido para la computación en nube, la infraestructura como servicio (IaaS) es un modelo de nube ofreciendo a las organizaciones la posibilidad de alquilar estos componentes de infraestructura TI (incluyendo computación, almacenamiento, y redes) sobre internet desde un proveedor de nube pública.

Los proveedores de nube suelen fijar precios de IaaS en base al consumo, con tarifas correspondiendo al uso con un nivel de rendimiento determinado. Para servidores virtuales, esto significa diferentes precios para varios tamaños de servidor, típicamente medidos como un incremento del tamaño estándar de un CPU virtual y la memoria correspondiente. Para almacenamiento los precios típicamente se basan en el tipo de servicio de almacenamiento, como objeto o bloque, nivel de desempeño (SSD o HDD), y la disponibilidad (una ubicación de almacenamiento o replicación a través de múltiples regiones geográficas). La capacidad es medida por el uso por unidad de tiempo, típicamente al mes.

Para el caso de Bigdata, como su nombre implica consiste en la acumulación de enormes cantidades de datos. Cuando los datos son recolectados, no únicamente se almacenan. Muchas organizaciones encuentran más fácil contratar a un proveedor de servicios en la nube para almacenar todos los datos recopilados, en lugar de pagar por mantenerlos localmente y deber gestionarlos por si mismos.

Fuentes:

https://www.webasthan.com/cloud-infrastructure-service-great-future/
 

Ataques contra Infraestructura en la Nube (Parte II)

Body

Aunque la denegación de servicio es un más un ataque tradicional, también puede tener un gran impacto sobre la computación en la nube. Mientras los ataques DoS tradicionales derribaban un objetivo particular, los ataques DDoS contra un proveedor de nube podrían tener un efecto dominó el cual desestabilizaría los recursos de múltiples organizaciones. Aunque los ataques contra aplicaciones o servicios específicos pueden ser perjudiciales para una organización, los ataques contra el proveedor de servicios en la nube por si mismo puede ser catastrófico para múltiples organizaciones.

Un vector de ataque frecuentemente pasado por alto es la cadena de suministro. Aunque la cadena de suministro es el inicio de la construcción de una infraestructura, frecuentemente es el último componente considerado para la seguridad. Es mucho más fácil para un atacante comprometer una organización pequeña a intentar una "Misión Imposible" para acceder hacia un entorno seguro. Esto podría incluir la interceptación de hardware y la instalación de componentes maliciosos, o la publicación de API instruyendo a la aplicación realizar llamadas maliciosas.

Una amenaza la cual nunca cesará de existir es la amenaza interna. Mientras muchas organizaciones están familiarizadas con la amenaza interna hacia su propia red interna, las infraestructuras en la nube multiplican esta amenaza. La nube introduce la posibilidad de una amenaza interna, ya sea accidental o intencional, actuando contra la organización específicamente o como consecuencia de un ataque separado o mayor.

El secuestro de cuentas ocurre como su nombre indica: Un atacante gana las credenciales del propietario de una cuenta y literalmente toma el control de la cuenta. Muchas de las explotaciones para secuestro de cuentas son posibles a través de phishing e ingeniería social. Debido a esto es crítico enfatizar la importancia de una buena higiene de seguridad, y de los conceptos fundamentales de seguridad: No hacer clic en enlaces de correos electrónicos, no abrir archivos adjuntos, y confiar pero verificar.

Fuentes:

https://www.sentinelone.com/cybersecurity-101/cloud-security/security-r…
 

Ataques contra Infraestructura en la Nube

Body

Las máquinas virtuales han mejorado el caso de uso para todos, pero también para los atacantes. El sniffing de tráfico de máquinas virtuales ocurre cuando un adversario ha ganado acceso hacia la red de una víctima, como su homónimo tradicional, inicia haciendo sniffing y vigilando el tráfico de la máquina virtual. Esto es especialmente efectivo si el atacante puede acceder hacia el vSwitch.

Muchas infraestructuras virtuales se basan sobre criptografía y encriptación para protección de datos. Un tema común observado en muchas brechas es la criptografía insegura. Esta debilidad existe tanto en entornos físicos cuanto virtuales. La protección apropiada de las llaves criptográficas es un requisito fundamental para la seguridad, especialmente cuando un sistema físico alberga múltiples máquinas virtuales.

Las ventajas de las API en la nube son; ahorran a los ingenieros y desarrolladores muchas horas en tiempo de codificación, permitiéndoles simplemente conectar APIs directamente. Sin embargo esta simplicidad viene con un costo. La mayoría de las API se escriben con autenticación débil debido a la simplicidad deseada.

La virtualización frecuentemente ofrece una arquitectura de una a muchas máquinas físicas y host. Esto significa los datos, los de la competencia y los de otras organizaciones pueden compartir espacio en el mismo sistema físico. Si alguno de ellos sufre una brecha, esto podría provocar una brecha del hipervisor, poniendo en riesgo a todas las demás máquinas virtuales.

Además de las fallas inherentes al sistema operativo virtual, también deben considerarse las fallas físicas. Spectre y Meltdown son dos vulnerabilidades descubiertas. El resultado fue la primera falla de seguridad importante del 2018. La singularidad de Meltdown y Spectre reside en no son fallas de código, sino residen en el procesador de la computadora. La explotación exitosa de Spectre y Meltdown otorgará permisos a nivel de kernel y acceso hacia archivos del nivel raíz.

Fuentes:

https://www.darktrace.com/cyber-ai-glossary/the-most-common-cloud-secur…
https://meltdownattack.com/
 

Respuesta ante Incidentes en la Nube

Body

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-…
 

Las Tres Maneras de DevOps

Body

"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/
 

Breve Historia de DevOps

Body

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…
 

Descripción General de DevOps

Body

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
 

¿Porqué DevSecOps?

Body

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/
 

Importancia de las Anotaciones en OSINT

Body

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…
 

Examinar las Técnicas y Resultados de OSINT

Body

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…