¿Cómo equilibra un CTO de una startup SaaS la velocidad de desarrollo y la seguridad?

Aprendizajes de empresas SaaS anteriores

En una startup SaaS típica, el equipo de desarrollo se encuentra bajo una fuerte presión para entregar nuevas funcionalidades. Normalmente tienes competidores que podrían estar mejor financiados, el equipo de ventas pidiendo una última funcionalidad para cerrar el trato, el equipo de soporte al cliente pidiendo una corrección de errores. Puede ser difícil priorizar la seguridad a menos que un cliente empresarial más grande lo exija o tu junta directiva lo imponga desde arriba.

En la mayoría de las startups, es posible que no dispongas de una gama completa de perfiles tecnológicos: quizás aún no tengas un product manager a tiempo completo, probablemente no cuentes con un responsable de seguridad a tiempo completo en tu equipo de desarrollo. Un equipo de desarrollo bajo presión para entregar se verá obligado a tomar atajos, incluso en lo que respecta a la seguridad.

He sido CTO de 3 startups SaaS en fase inicial. (Teamleader, Officient y Futureproofed) A continuación, he resumido mis aprendizajes de esas experiencias en empresas SaaS.

Evita reinventar la rueda

Un gran ejemplo: no construyas un sistema de inicio de sesión con contraseñas. Sí, podrías construirlo en unos pocos días, pero el coste de mantenerlo y añadir características de protección avanzadas en el futuro será muy alto. Considera usar un inicio de sesión a través de Single-sign on como Gmail o usar un servicio como Auth0.com.  No solo tendrás una experiencia de inicio de sesión más fluida y con más funciones, sino que tampoco tendrás que preocuparte por toda una clase de aspectos de seguridad relacionados con el inicio de sesión (ataques de fuerza bruta, credenciales de usuario filtradas en servicios de terceros, evitar y detectar ataques de toma de control de cuentas, validar direcciones de correo electrónico, registro...).

Al final, si eliges al proveedor adecuado, no solo reduces tu superficie de ataque, sino que también ganas tiempo que puedes dedicar a funcionalidades más valiosas.

Otros excelentes ejemplos que podrían ahorrarle semanas o meses son:

• No almacenes tarjetas de crédito; utiliza plataformas como Stripe, Mollie o Chargebee.
• No ejecutes software complejo como MySQL, PostgreSQL o ElasticSearch por tu cuenta. Utiliza servicios gestionados en la nube como RDS.
• No construyas tus propios sistemas de registro. Utiliza sistemas como Sentry o Papertrail (y no registres ningún dato sensible allí)
• No gestiones tus propios servidores de correo electrónico (SMTP); utiliza un servicio gestionado como Sendgrid o Mailgun.
• No construyas servidores de websocket, utiliza servicios gestionados como Pusher.com
• No construyas tu propio sistema de feature flagging, utiliza un servicio como Launchdarkly
• No construyas tu propia integración de calendario, utiliza una herramienta como cronofy.com
• Al construir integraciones en general, busque APIs Unificadas en ese ámbito, como Apideck.

Invierta tiempo en la configuración de una comunicación de crisis

Asegúrate de tener herramientas configuradas, como una aplicación de chat para hablar con tus clientes, o mejor aún, una página de estado gestionada o una cuenta de Twitter donde puedas comunicar los problemas. En caso de que ocurra algo grave, es una excelente práctica permitir que el resto de tu empresa se comunique con tus clientes mientras tú te concentras en solucionar el problema durante una crisis.

Añadir salvaguardas globales

Probablemente esté revisando los Pull Requests de sus desarrolladores, ¡genial! Es una tarea considerable revisarlos en cuanto a mantenibilidad, rendimiento y funcionalidad. ¿Tiene tiempo para revisarlos también en cuanto a seguridad? Seguro que podrá cubrir algunos riesgos, pero es útil poder mitigar otros añadiendo algunas barreras de seguridad y configuración global.

A veces, puedes tener suerte y existen soluciones globales para problemas específicos.

• Si utiliza nodeJS y no le gusta preocuparse por la 'prototype pollution', debería congelar el prototipo para deshabilitar esta clase de ataques en toda la aplicación. Aikido puede generar automáticamente una Pull Request que haga esto por usted.
• Si usas SQL y temes los ataques de inyección SQL (deberías), puedes usar un WAF (como AWS WAF) o RASP (como la seguridad de aplicaciones de Datadog) para una protección a nivel de aplicación.
• Si está descubriendo muchos ataques XSS, es probable que pueda eliminar una gran parte de ellos introduciendo una política CSP muy estricta en el navegador.
• Si está realizando muchas solicitudes salientes basadas en la entrada del cliente, podría ser vulnerable a ataques SSRF. Aunque podría ser difícil bloquear esto por completo, podría mitigar los daños asegurándose de que no pueda llevar a algo peor (como un ataque IMDSv1 a las credenciales IAM en AWS). Aikido monitoriza esto en su nube de AWS por defecto.
• Al trabajar con almacenamiento de objetos, evitar tipos específicos de funciones como Pickle, XML, (des)serialización en Java y PHP, y optar en su lugar por opciones de almacenamiento simples como JSON, puede evitar muchos exploits típicos relacionados con la deserialización insegura. Aikido monitoriza este tipo de funciones en su base de código por defecto.
• Si utiliza una CDN o mecanismos de caché, use dominios separados para sus activos estáticos con configuraciones de CDN separadas para evitar todo tipo de ataques de envenenamiento de caché (ChatGPT cayó en esta trampa recientemente).

Educa a tus desarrolladores con este sencillo truco

Hay un truco fácil (con juego de palabras) que puedes implementar en tus procesos. Una pregunta rápida para hacer al equipo de desarrollo durante la planificación del sprint:

¿Cómo puede ser hackeada la funcionalidad que estamos construyendo? (& cómo podemos evitar que eso ocurra)

Aunque el equipo de desarrollo puede no anticipar todos los posibles escenarios de abuso, esta metodología es extremadamente sencilla de escalar. Es un pequeño paso adicional que anima a los desarrolladores a revisar las consideraciones de seguridad antes de emprender cualquier trabajo de desarrollo.

Asignar prioridades a diferentes partes de tu base de código

No todo será un objetivo tan grande para los hackers. Los componentes clave que les encanta atacar son:

• Sistemas de pago, monederos, sistemas de crédito
• Funcionalidad que se conecta a APIs costosas como SMS, VoIP (por ejemplo, Twilio)
• Restablecimiento de contraseña, sistemas de inicio de sesión, invitaciones de usuario
• Funciones de exportación como PDF, Excel... que podrían realizar operaciones arriesgadas.
• Cualquier cosa relacionada con la subida de archivos, imágenes
• Funcionalidades que realizan solicitudes salientes por diseño, como los webhooks
• Cualquier tipo de funcionalidad que envíe correos electrónicos, especialmente con contenido personalizado

PD: Aikido puede ayudarle a centrarse solo en los repositorios principales del universo de su startup asignando niveles de riesgo a cada base de código.

No olvides el aspecto humano

Como CTO en una pequeña startup, normalmente también es el responsable de la seguridad operativa. Proporcione a su equipo los medios para proteger sus cuentas. Asegúrese de que utilicen Yubikeys de hardware o aplicaciones de software para la 2FA y, si es posible, impóngalo. Herramientas como Gmail permiten aplicar esto. Es una excelente primera línea de defensa contra los ataques de phishing.

Mantenerse al día con las prácticas de seguridad es difícil

Aprender sobre nuevos tipos de ataques al software es difícil. Ya es bastante difícil mantenerse al día con las actualizaciones de los lenguajes que utiliza (Python, Node, Go,..) o el parcheo del sistema operativo o los exploits populares en paquetes de código abierto. Los ataques específicos se vuelven más populares con el tiempo, por lo que vale la pena seguir las tendencias. Por ejemplo, tras observar un aumento en los ataques de apropiación de subdominios el año pasado, Aikido introdujo una herramienta de monitorización de apropiación de subdominios para prevenir ese riesgo y automatizar la práctica de monitorizar estos registros DNS.

Automatizar para eliminar tareas

En mis empresas anteriores, intentábamos alcanzar un siguiente nivel de seguridad haciendo que una persona de seguridad creara un calendario con tareas de seguridad recurrentes. Realizar una revisión de acceso para todas las aplicaciones cada trimestre. Realizar un escaneo de secretos filtrados en el código cada dos semanas, limpiar los CVEs de paquetes de código abierto cada viernes, realizar un escaneo SAST de vez en cuando, verificar los registros DNS para tomas de control de subdominios cada mes,... El resultado de estas tareas era difícil de clasificar y de hacer accionable para los desarrolladores. Peor aún, cuando esta persona dejó la empresa, fue difícil para cualquier otra persona retomar estas tareas porque requerían mucho conocimiento específico.

Aquí es donde la idea de Aikido empezó a crecer. Necesitábamos una solución que automatizara todo lo anterior, filtrara el ruido y presentara las tareas a tus desarrolladores en Slack o Jira.

Empiece a escanear su código y la nube con Aikido hoy mismo. Regístrese aquí y empiece a escanear gratis.