Sobre la mejora de la seguridad con Steve Wilson

Steve Wilson es el director de productos de Contrast Security, con más de 25 años de experiencia en el desarrollo y la comercialización de productos en empresas tecnológicas multimillonarias como Citrix, Oracle y Sun Microsystems. En este AMA, Steve nos habla sobre seguridad sin servidor, seguridad de aplicaciones en el ecosistema JAVA, SBOM y mejores prácticas. Este hilo de Slogging de Mónica Freitas, Steve Wilson, Zach Taylor, Victor de Avila, Jack Boreham y Sara Pinto apareció en el canal oficial #amas de slogging y ha sido editado para facilitar la lectura. Hola @channel, únete a mí para dar la bienvenida a nuestro próximo invitado de AMA, Steve Wilson. Steve es actualmente el director de productos de Contrast Security. Hoy su equipo es responsable de Ingeniería, Gestión de Producto y Diseño de Producto para todos los productos. Steve tiene más de 25 años de experiencia en el desarrollo y la comercialización de productos en empresas tecnológicas multimillonarias como Citrix, Oracle y Sun Microsystems. Antes de Contrast, Steve fue vicepresidente de gestión de productos de Citrix Cloud, donde dirigió la transformación de los productos Citrix de locales tradicionales a SaaS.

En Oracle, dirigió la ingeniería central para una línea de productos de software de gestión de sistemas de miles de millones de dólares. Durante su tiempo en Sun Microsystems, Steve fue uno de los primeros miembros del equipo que desarrolló el sistema de programación informática Java, el conjunto de herramientas de desarrollo de software más utilizado en la historia.

No dude en preguntarle a Steve cualquier cosa sobre:

¡Hola Steve Wilson! ¡Es genial tenerte con nosotros! ¿Podría comenzar contándonos un poco sobre su experiencia y cómo llegó a trabajar con Contrast Security?

¡Hola Mónica Freitas! Es genial estar aquí. Me gustaría comenzar agradeciendo primero a HackerNoon por invitarme a unirme a su AMA y espero responder sus preguntas.

Soy el director de productos de Contrast Security, un líder en seguridad de aplicaciones que permite a los desarrolladores proteger mientras codifican. Nuestra plataforma proporciona a los desarrolladores soluciones de seguridad de autoservicio para mejorar la eficiencia a lo largo de todo el ciclo de vida del desarrollo de software, al mismo tiempo que protege las aplicaciones de las vulnerabilidades antes, durante y después de la producción. Aprovecho mis más de 25 años de experiencia en el desarrollo y la comercialización de productos para liderar a mis equipos que son responsables de la ingeniería, la gestión de productos y el diseño de todos los productos de Contrast.

2 datos divertidos sobre mí:
- Soy cinturón negro de segundo grado en Taekwondo.
- Disfruto tocando melodías clásicas de rock en la guitarra.

Siéntete libre de seguirme en Gracias, Mónica Freitas, feliz de contarles cómo llegué a Contrast! Me uní hace unos 18 meses después de trabajar en grandes empresas como Citrix, Oracle y Sun Microsystems. He trabajado en funciones de colaborador individual y gestión tanto en ingeniería como en gestión de productos, desde mis días como uno de los primeros miembros del equipo de Java a finales de los 90. Encantado de responder preguntas sobre las primeras trivias de Java/Sun si la gente está interesada. 🙂 Sin embargo, una historia rápida sobre cómo llegué a Contrast. En mi puesto anterior, me encontré en una situación en la que un equipo de cientos de ingenieros se vio completamente descarrilado por un equipo de seguridad que ejecutaba un producto de "escaneo de código" defectuoso. Nos generó enormes cantidades de deuda técnica (que debíamos abordar), pero casi no generó mejoras en nuestra postura de seguridad. Se deslizó en los horarios y creó una gran frustración. ¡Al unirme a Contrast, me di cuenta de que había una mejor manera de hacerlo! ¡Hola Steve! ¿Puedes explicar qué es serverless? ¡Gracias, Zach Taylor! Serverless es uno de esos términos que significa muchas cosas para muchas personas, así que analicemos. En esencia, es un conjunto de tecnologías que están diseñadas para hacer que la informática del lado del servidor sea más eficiente y sencilla. Un uso del término tiene que ver con la idea de abstraer el concepto de peso pesado de una "Máquina virtual" (al estilo VMware) y en lugar de usar construcciones escalables más livianas como Docker Containers y Kubernetes. Sin embargo, creo que hay un movimiento mucho más interesante dentro de Serverless... La mayor revolución en 20 años para la arquitectura de aplicaciones son las funciones como servicio. El ejemplo más popular de esto es Amazon Web Services (AWS) Lambda, aunque otras nubes como Microsoft y Google han agregado construcciones similares. De la misma manera que los Java Servlets fueron una gran mejora en la arquitectura web en comparación con el "CGI" anterior, las funciones sin servidor pueden ser 100 veces más rápidas y económicas que las arquitecturas tradicionales. Estas funciones no son divertidas todo el tiempo, están más "basadas en eventos" y se ejecutan solo cuando es necesario. Ve que se utilizan en lugares donde la escalabilidad masiva y el bajo costo son críticos. Aplicaciones de Internet de las cosas (IoT) en las que puede enviar datos de miles o millones de dispositivos a un servicio de recopilación de datos. Esto es realmente emocionante.

¡Eso es muy emocionante para los desarrolladores! Y cuando menciona IoT, parece que abre las puertas a muchos casos de uso diferentes.

¿En qué se diferencia la seguridad sin servidor de, por ejemplo, la seguridad de aplicaciones tradicional?

¡Gran pregunta, Zach Taylor! ¡Hay muchas diferencias! En el lado "positivo", pierdes muchas cosas de las que "no" puedes preocuparte. No necesita preocuparse por tener un sistema operativo o incluso un servidor de aplicaciones que necesita parchear. Todo eso "desaparece" debajo de ti. Algunas versiones todavía existen en alguna parte, pero no las ve ni las administra. ¡Esa es una gran ventaja desde una perspectiva de seguridad! Sin embargo, en el lado de la "precaución", su código para su aplicación se verá MUY diferente. De hecho, debe asumir que las herramientas de AppSec de su código (como su "escáner de código") no funcionan en absoluto. Todos los puntos de entrada y salida son diferentes, por lo que su flujo lógico es diferente. Necesita herramientas de AppSec completamente nuevas para asegurarse de poder detectar las vulnerabilidades de tipo OWASP Top 10 (todas las cuales aún existen). De hecho, OWASP tiene una que vale la pena consultar. Por lo tanto, todavía tiene dos cosas importantes de las que preocuparse con las que sus herramientas de AppSec deben ayudar: las vulnerabilidades en el código fuente abierto que trae y las vulnerabilidades en el código personalizado que escribe. Sin embargo, también hay un nuevo elemento del que preocuparse, que son sus permisos de Gestión de acceso e identidad (IAM) en cada función. Es una pieza fundamental para mantener su código seguro cuando se ejecuta en la nube pública, pero es laborioso hacerlo a mano. Mejor asegúrese de tener una herramienta que pueda automatizar eso por usted. ¡Vaya, eso es muy perspicaz! Entonces, a pesar de las compensaciones (pros y contras de ambos), en general, ¿parece que la automatización es un componente clave para llenar los vacíos? Ese OWASP Top 10 parece muy interesante, definitivamente voy a profundizar más en eso, ¡gracias por compartirlo! ¡Hola Steve! Si una organización considera cambiarse a entornos sin servidor/nativos de la nube, ¿cuáles son las amenazas/peligros más inmediatos? ¿Qué deben tener en cuenta los equipos de seguridad para mejorar la protección?

¡Oye, Víctor de Ávila, gran pregunta! Si bien la tecnología sin servidor elimina muchas de las responsabilidades de seguridad de las tecnologías subyacentes, los desarrolladores todavía están comprometidos con la seguridad de las funciones sin servidor. Si el código se escribe de manera insegura, la aplicación aún puede ser vulnerable a los ataques tradicionales a nivel de aplicación, como Cross-Site Scripting (XSS), inyección de comando/SQL, denegación de servicio (DoS), autenticación y autorización rotas, configuraciones incorrectas de seguridad. , y muchos más.

Los equipos de seguridad no solo deben lidiar con las vulnerabilidades y exposiciones comunes (CVE), o los riesgos asociados con las bibliotecas de código abierto, sino que los entornos sin servidor también presentan amenazas impulsadas por el control de acceso roto, particularmente cuando los desarrolladores necesitan agregar permisos para admitir la funcionalidad necesaria. En esta situación, el equipo de seguridad suele indicar al desarrollador que seleccione de una lista de permisos predefinidos que proporciona más acceso privilegiado del necesario. Un buen proceso de automatización podría ser una gran oportunidad para una aplicación con privilegios mínimos, algo que antes era imposible en ese nivel. Sin embargo, automatizar este proceso a escala, de manera precisa y rápida no es fácil.

En un entorno sin servidor, la superficie de ataque también aumenta, ya que los ataques de deserialización son más comunes y la auditoría y el monitoreo son más difíciles que en las aplicaciones tradicionales. Como resultado, las organizaciones deben seguir los principios de privilegios mínimos y garantizar controles de acceso sólidos para reducir la superficie de ataque y garantizar que solo las personas autorizadas puedan tener acceso.

Del mismo modo, los equipos de DevSecOps también deben tener en cuenta la "expansión" dentro de las funciones sin servidor. Las funciones pueden tener múltiples versiones, en diferentes regiones y en múltiples cuentas, lo que dificulta que los equipos de administración y seguridad comprendan el tamaño general del inventario sin servidor a nivel de organización. Para abordar esto, necesitarán fuertes controles de gestión de activos relevantes tanto para la infraestructura en la nube como para la tecnología sin servidor.

Finalmente, los equipos deben considerar los permisos de su biblioteca. Si bien no es diferente de la seguridad de las aplicaciones regulares, las funciones tienden a tener muchas dependencias. Además, en algunos casos, incluso si el código parece limpio, la infraestructura (como IaC) puede introducir más bibliotecas en el momento de la implementación, lo que genera la pérdida de vulnerabilidades de terceros. Los equipos de DevSecOps deben habilitar procesos de seguridad sólidos con un ojo crítico para estas consideraciones específicas sin servidor. ¡Hola, Steve Wilson! Me encantaría saber sobre su tiempo trabajando en Oracle. ¿Qué hiciste allí?

Hola, Jack Boreham, ¡gracias por preguntar! Estuve en Oracle durante aproximadamente 3,5 años, de 2010 a 2013. Durante ese tiempo, fui "vicepresidente de ingeniería central" para el equipo de Enterprise Manager. Este fue el conjunto de herramientas de administración de Oracle para toda su cartera (desde hardware hasta hipervisor, base de datos, middleware y aplicaciones). Es un trabajo en el que aprendí mucho sobre cómo trabajar a escala (mi equipo estaba formado por unas 500 personas repartidas entre Norteamérica, Europa (Francia y la República Checa) e India). Oracle tenía una cultura corporativa extraña, pero una cultura de ingeniería muy disciplinada (tener comencé con Oracle DB). Aprendí mucho sobre pruebas y control de calidad allí.

Pero, solo para dar más detalles, me uní a Oracle cuando adquirieron Sun Microsystems. De hecho, me uní a Sun a mediados de los años 90 como codificador trabajando en el Java Developer Kit, donde pude trabajar con todo tipo de personas inteligentes como James Gosling (y muchos otros que se convirtieron en programadores famosos y crearon cosas increíbles). Empecé a trabajar en el kit de herramientas de GUI de Java y luego me convertí en el primer ingeniero de rendimiento para Java a tiempo completo. De hecho, escribí un al respecto. Proporcionaré un enlace solo por diversión, ¡pero está muy desactualizado y no recomendaría que nadie lo lea ahora! 😉 Pasé a la gerencia y lideré el equipo IDE de NetBeans (mi trabajo favorito, por cierto) y luego los equipos de administración de sistemas y virtualización de Sun. Avíseme si tiene más preguntas sobre cualquier parte de esto. Muchas historias divertidas sobre Sun/Oracle.

¡Steve Wilson, ese es un gran viaje!
¿A qué desafíos te has enfrentado en tu papel en Contrast? ¿Y qué quiere decir con soluciones de seguridad de autoservicio? ¿Tiene un conjunto establecido de soluciones de seguridad y cualquier empresa puede elegir la que mejor se adapte a sus necesidades? ¿Es posible que las empresas pidan a Contrast soluciones a medida?

Mónica Freitas, gracias por preguntar por Contrast! Contrast es una empresa que se especializa en herramientas para ayudar a los desarrolladores a crear aplicaciones seguras. Mucha gente piensa en cosas como herramientas de seguridad de red, identificación o punto final cuando consideran la seguridad (y eso es importante), pero ¿qué estamos tratando de proteger de los piratas informáticos? Realmente se trata de nuestras aplicaciones y los datos que almacenan para nosotros. Es por eso que la seguridad de las aplicaciones es tan importante y esas son las herramientas que construye Contrast. Tenemos lo que se llama una plataforma de código seguro. Incluye muchas tecnologías para ayudar a los desarrolladores y equipos de seguridad. Esto incluye escaneo de código fuente (SAST), instrumentación que puede probar su aplicación desde "adentro hacia afuera" IAST, protección de tiempo de ejecución (RASP) que realmente puede neutralizar a los atacantes que intentan explotar vulnerabilidades de día cero. Ejemplos recientes son cosas como Log4J y Spring4Shell. Y, por último, recientemente presentamos las primeras herramientas de seguridad del mundo para el código Serverless nativo de la nube. Estaremos encantados de hablar con la gente sobre las mejores opciones para crear un programa DevSecOps que les permita mantener su velocidad de desarrollo, pero también garantizar que su código sea seguro. Puede comunicarse para obtener más detalles . Mónica Freitas, sobre el tema de la seguridad de "autoservicio"... Las soluciones de seguridad de autoservicio se refieren a la capacidad de los desarrolladores de aprovechar las herramientas de Contrasts por su cuenta y usarlas como mejor les parezca. Esto significa que los desarrolladores y los equipos de DevOps pueden obtener solo las herramientas que necesitan para hacer el trabajo y pueden encontrar y corregir vulnerabilidades con una capacitación mínima en seguridad (o supervisión constante de un equipo de ingeniería de seguridad dedicado). En cuanto a pedirle a Contrast soluciones a medida, absolutamente. Nuestro equipo puede guiar a los equipos sobre lo que funcionará mejor en función de sus objetivos, así como de las necesidades a corto y largo plazo. Steve Wilson, ¿cuáles son los problemas de seguridad más comunes que ha visto y qué medidas pueden tomar las empresas para resolverlos? Mónica Freitas, gracias por la pregunta sobre los problemas de seguridad más comunes. Voy a evitar cosas como el phishing y las malas contraseñas (ya que eso es un terreno obvio y bien pisado). En su lugar, me centraré en los problemas de creación de aplicaciones seguras. Hay dos cosas principales que debe tener en cuenta: asegurar el código que escribe y asegurar el código que usa que otra persona escribió (generalmente de código abierto). Con el código que escribe, hay una gran cantidad de tipos de vulnerabilidad que se clasifican. Uno de los más comunes (y más serios) se llama ataque de "inyección". Esto significa que una entidad externa (¡un pirata informático!) puede introducir datos en alguna parte de su sistema de una manera que usted no anticipó ni pretendía. Estos pueden ser cosas como un "ataque de inyección de SQL" en el que un pirata informático puede poner una parte del lenguaje de consulta de la base de datos en su base de datos y ejecutarlo de forma remota. Esto es muy común y ha sido un problema importante durante 20 años. Otro que a menudo se pensó que era menos serio es la "Inyección de archivo de registro", donde un pirata informático puede colocar datos contaminados directamente en un archivo de registro de su aplicación. Parece que no es tan malo, pero esto fue el centro del reciente incidente de seguridad de Log4J que afectó a tantas empresas en diciembre/enero. En cuanto al código de fuente abierta, sabemos que la mayoría del código en las aplicaciones comerciales modernas ni siquiera está escrito por los desarrolladores de una empresa. Es de código abierto. Está abierto a todo tipo de ataques y, si bien el código abierto proporciona una base sólida para el código seguro al tener muchos ojos en el código, muchos de esos ojos ahora son piratas informáticos (desde estudiantes hasta piratas informáticos del estado-nación). Algunas de estas bibliotecas (como Struts, Log4J, Spring) son tan populares que están integradas en millones de aplicaciones en todo el mundo. Hace unos años, la agencia de calificación crediticia llamada Equifax estaba usando una versión vulnerable de Struts y perdió los datos financieros personales de cientos de millones de estadounidenses. Como resultado, fueron multados con más de $ 400,000,000 de dólares. Esto es serio. La mejor manera de manejar estos dos problemas es modernizar sus prácticas de desarrollo para incluir herramientas automatizadas que lo ayuden a detectar y solucionar este tipo de problemas. La plataforma de código seguro de Contrast funciona con Java, JavaScript .NET, Go, Ruby, Python, Scala y Kotlin, por lo que si está utilizando alguna de estas tecnologías populares, nos complacerá ayudarlo a modernizar sus herramientas y crear un programa para automatizar todo. de esta. ¡Hola Steve Wilson! Tengo curiosidad, ¿qué son los SBOM? ¿Pueden afectar los sistemas de seguridad? Sara Pinto, gracias por preguntar sobre SBOM. ¡Qué área tan interesante y actual en este momento! Esto es realmente una parte del tema más amplio llamado Seguridad de la cadena de suministro de software. Como se señaló en algunas de las otras preguntas de este hilo, gran parte del código de las aplicaciones modernas no está escrito por los propios desarrolladores de una empresa. Es de un tercero (a menudo de código abierto). Hace un tiempo, un proveedor de software llamado Solar Winds fue pirateado. Eso fue malo para los vientos solares, pero lo que fue peor fue que el código creado por Solar Winds estaba incrustado en entornos de nube y centros de datos de muchas otras empresas e incluso gobiernos. Sabiendo esto, los piratas informáticos que atacaron a SolarWinds no solo robaron a SolarWinds, sino que aprovecharon la oportunidad para colocar puertas traseras en el software de SolarWind que luego sería incorporado por muchas otras compañías. La exploración fue masiva y condujo a la idea de que debe realizar un seguimiento de su propio código, pero también del código que obtiene de otros lugares. Todo el proceso debe ser seguro de principio a fin y eso se llama seguridad de la cadena de suministro de software. SBOM significa la lista de materiales del software. Un SBOM es una lista de todos los componentes de código abierto y de terceros presentes en un código base, además de todas las licencias que rigen esos componentes. Piense en ello como las etiquetas de información nutricional en el lateral de una caja de alimentos. Ayuda al consumidor a saber qué hay en los alimentos para que puedan usarlo y garantizar que los alimentos sean seguros y saludables para ellos. Los SBOM pueden crear más transparencia en el mercado de software y también permitir que los desarrolladores actúen rápidamente si se identifica una vulnerabilidad. La reciente declaró que se deben requerir los SBOM y la NTIA publicó " " para los elementos imprescindibles de SBOM, y muchos de estos puntos solo se enfatizaron aún más en y la adjunta . Además, Gartner predice que para 2025, el 60 % de las organizaciones que crean o adquieren software de infraestructura crítica exigirán y estandarizarán los SBOM en su práctica de ingeniería de software. Si bien estos son excelentes primeros pasos para proteger las aplicaciones modernas, incluidas las aplicaciones sin servidor, los desarrolladores y los equipos de seguridad todavía están obligados a mantener sus aplicaciones seguras, y esa responsabilidad recae en los equipos de DevSecOps. Steve Wilson, a medida que se desarrolla Web3, ¿considera la posibilidad de crear opciones de seguridad para web3? Mónica Freitas, gracias por la pregunta abunda la seguridad Web3. Este es un tema FASCINANTE y bastante amplio. Trataré de agregar mi perspectiva. Primero, tenemos que definir Web3. En la cultura popular, la idea de Web3 está dominada por el intercambio de extrañas piezas de arte digital. Hay discusiones constantes sobre esquemas Ponzi y fraude. Pero creo que los conceptos de Web3 son fascinantes. Cuando lo quitas todo, Web3 es un conjunto audaz de intentos (y estoy seguro de que muchos fallarán) para reconstruir gran parte de Internet desde cero. ¿Por qué necesitamos hacer eso? Bueno, ¡realmente se trata de seguridad y confianza! Internet y la world-wide-web que se encuentra encima fueron construidos por académicos para académicos. Estaban destinados a abrir la información, hacer avanzar la ciencia y la tecnología y promover el intercambio de ideas. En ese sentido, internet/web es el esfuerzo más exitoso en la historia de la humanidad.

Sin embargo, debido a su naturaleza, le falta un concepto clave: ¡confianza! ¿Cómo sé quién eres? ¿Cómo sé lo que tienes? ¿Cómo sé a qué tienes derecho? Nada de eso estaba integrado en Internet al principio. Todo lo que está en capas encima de eso es frágil y está controlado centralmente. ¿Cómo sé lo que tienes? Le pregunto a su banco/compañía de tarjeta de crédito. ¿Cómo sé quién eres? ¡Vaya, ese es un problema casi sin resolver en Internet hasta el día de hoy!

Web3 tiende a comenzar con los conceptos iniciados por Bitcoin/Criptomoneda, con Blockchain en su núcleo. Hace unos cuatro años, descubrí que mi hija adolescente y sus amigos estaban usando servicios de VPN gratuitos para atravesar el firewall de la escuela secundaria y poder ver Netflix en la escuela. En lugar de enojarme, me pareció una excelente manera de iniciar una conversación con ella sobre seguridad y criptografía (¡ALERTA DE PAPÁ NERD!). De alguna manera, terminamos embarcándonos en una aventura fabulosa extrayendo Ethereum y aprendiendo sobre Blockchain. Puedes leer sobre algunas de nuestras aventuras .

Esto me llevó personalmente a sumergirme realmente en cómo funcionaba Blockchain. De alguna manera, es una maravilla de la informática y, de alguna manera, es una pesadilla de ingeniería, pero fue pionera en un nuevo conjunto de conceptos sobre cómo distribuir la confianza sin una autoridad central. ¡Este es el núcleo de web3! ¿Cómo sé quién es usted y qué posee (en un contexto determinado) sin que una institución de terceros en el medio me lo diga? Si está interesado en leer mis pensamientos sobre lo bueno y lo malo de blockchain, puede consultar este . Tiene algunos años, pero los conceptos centrales aquí se están moviendo lo suficientemente lento como para que todo sea en gran medida relevante para la discusión. Entonces, ¡vamos ahora al grano! ¿Qué le diría a alguien que busca sumergirse en la seguridad web3? Primero, hay instancias de alto perfil de fallas de seguridad en cadenas de bloques más pequeñas. La confianza de Blockchain generalmente se basa en la votación por consenso y, si no tiene una masa crítica, alguien puede poseer más del 50% de los votos y está en problemas. Sin embargo, no creo que este sea el tema más importante para los desarrolladores que buscan Web3 hoy. Cuando observo los grandes incidentes de seguridad en torno a Web3/NFT/Crypto en los últimos años, no están relacionados con la cadena de bloques principal. Están alrededor de las partes Web2 del código/infraestructura de una empresa que aún une al mundo. El juego Web3, en el juego a muy largo plazo (piense en términos de décadas), es reemplazar las bases de Internet con cosas que incluyen la confianza como un componente central. Eso puede suceder, y es loable, pero está muy lejos. Hoy en día, tenemos cosas como IPv4/6, SSL, HTML, JavaScript, REST, servidores de aplicaciones, bibliotecas de código abierto y bases de datos SQL que mantienen unido al mundo (con islas de tecnologías blockchain/web3). Si está ejecutando un intercambio NFT (o algo similar), entonces pasaría la mayor parte (o más) de mi tiempo preocupado por la parte Web2 de mi mundo que es el vínculo entre mis clientes/socios y yo. Es susceptible a los mismos conceptos de seguridad de aplicaciones de los que hemos hablado antes aquí. Necesita un GRAN programa y plataforma DevSecOps. Y la mayor parte debería parecerse a un procesador de tarjetas de crédito o un banco importante. El contraste puede ayudar aquí. Si puede endurecer su "pegamento" Web2 al mismo nivel que un banco importante, entonces puede dedicar su tiempo a preocuparse por cómo diferenciarse en el mundo Web3. Son tiempos emocionantes. No puedo esperar a ver cómo se desarrolla esto. Avísame si quieres hablar más sobre este tema. ¡Me encantaría chatear! Steve Wilson, soy nuevo en todos estos estándares de seguridad de software. ¿Podría elaborar sobre ellos? ¿Qué debo saber sobre esto? Sara Pinto, gracias por la pregunta sobre los Estándares de Seguridad del Software. ¡Guau! Acabas de tocar un tema realmente grande e importante. En líneas generales, existen dos tipos de normas: contractuales/comerciales y estatutarias. Los estándares comerciales son cosas que lo ayudarán a hacer negocios. Adherirse a uno de estos estándares podría estar escrito en un contrato. Por ejemplo, su cliente puede exigirle que se adhiera a un estándar llamado SOC2 y que sea auditado regularmente para demostrarlo. Por otro lado, para vender servicios de computación en la nube al gobierno de los EE. UU., debe cumplir con un conjunto de estándares llamado FedRAMP (eso es "por ley", por lo que se considera un requisito legal). Ambos ejemplos son interesantes e importantes si está ejecutando una empresa de software/SaaS. Sin embargo, para los desarrolladores individuales, son realmente abstractos. Por ejemplo, estos estándares incluyen muchos elementos más allá del "software". Un buen ejemplo sería, ¿tiene suficientes verificaciones de antecedentes y capacitación básica en seguridad para todos sus empleados?

Para los desarrolladores de software, existen estándares más detallados que profundizan mucho más en los detalles de los que quizás desee preocuparse. ¡Aquí hay una lista parcial de cosas divertidas para comenzar a explorar en su viaje! Tenga en cuenta que algunos requisitos son técnicos y algunos requisitos son los procesos que utiliza para crear software.

Orden Ejecutiva de Ciberseguridad 14028

PCI SSF (Pa-DSS reemplazado)

OWASP

NIST

CISA

OGP

Privacidad (la seguridad es una condición previa para la privacidad)

Otro

Esto ha sido súper divertido para todos. ¡Gracias por unirte! Estaré viendo este canal por el resto del día, pero si este es el final de este hilo, les dejaré algo lo que he estado trabajando. ¡Espero que lo disfrutes! Gracias por acompañarnos, Steve Wilson, y por tus inteligentes respuestas. ¡Nos encantó tenerte aquí!