Construir un programa de seguridad desde cero

Ser contratado como la primera persona de seguridad en una empresa es un tipo específico de caos. No hay cola de tickets, no hay herramientas establecidas, y usualmente no hay una línea presupuestaria esperándote. Lo que sigue es un mapa aproximado de cómo suelen transcurrir esos primeros 90-180 días, y qué realmente mueve la aguja versus qué solo se siente productivo.

Qué "nada" generalmente significa

Cuando la gente dice que una empresa no tiene función de seguridad, raramente significa cero controles. Significa que no hay un propietario dedicado. Ingeniería probablemente ha habilitado algunas políticas básicas de AWS IAM, IT tiene algo de antivirus implementado a través de una herramienta MDM, y alguien en finanzas tiene opiniones sobre SOC 2 porque un cliente lo preguntó. Tu primer trabajo es inventario, no implementación. Antes de escribir una sola política, descubre qué ya está corriendo: cuentas de cloud (y cuántas no recuerda nadie haber creado), herramientas SaaS con acceso de administrador al código fuente, y si existe una única fuente de verdad para la desvinculación de empleados. Un spreadsheet está bien para esto. Una plataforma GRC no es la prioridad aún.

Los primeros 30 días: visibilidad sobre control

Resiste el impulso de escribir una política de uso aceptable en la semana uno. Nadie la leerá y no detendrá los riesgos reales. En su lugar, obtén visibilidad en tres cosas:

• Identidad: extrae una lista completa de usuarios de tu proveedor de identidad (Okta, Google Workspace, Azure AD) y haz referencias cruzadas contra la lista de empleados activos de HR. Encontrarás cuentas fantasma.
• Huella de cloud: ejecuta algo como aws organizations list-accounts si estás en AWS, o revisa el Asset Inventory de GCP, para ver cuántos ambientes existen versus cuántos alguien puede nombrar de memoria.
• Exposición de código y secretos: ejecuta gitleaks detect o trufflehog filesystem . contra tus repositorios principales. Encontrar una clave API codificada en el historial de commits de hace dos años es casi garantizado y es una forma rápida de demostrar valor.

Documenta hallazgos, pero no conviertas esto en un informe de 40 páginas que nadie abre. Un resumen de riesgos de una página con cinco puntos es leído por un CTO. Un PDF largo no.

Elegir tus primeros tres controles

Sin personal y sin presupuesto de herramientas, no puedes hacerlo todo a la vez. El orden de operaciones que tiende a funcionar:

1. MFA en todos lados donde no esté ya, comenzando con el proveedor de identidad, luego GitHub/GitLab, luego consolas de cloud. Esto solo cierra el camino de toma de cuenta más común.
2. Logging centralizado para eventos de cloud y auth. Incluso el nivel gratuito de una herramienta adyacente a SIEM, o simplemente enviar CloudTrail/logs de auditoría de GCP a un bucket con retención, es mejor que no tener nada cuando ocurre un incidente.
3. Un plan de respuesta a incidentes escrito y corto, incluso si son dos páginas: quién recibe la página, quién habla con clientes, quién tiene autoridad para apagar algo. Nadie recuerda construir esto hasta el día en que lo necesita, y para entonces es demasiado tarde.

Observa que ninguno de estos requiere un contrato con un proveedor grande. Requieren decisiones y seguimiento.

Obtener aprobación sin una línea presupuestaria de seguridad

La forma más rápida de perder credibilidad como primer contratado de seguridad es aparecer con una lista de deseos de herramientas antes de mostrar resultados. En su lugar, vincula cada solicitud a algo concreto: "encontramos tres usuarios de IAM con claves de acceso sin rotar desde 2021" funciona mejor que "necesitamos una herramienta CSPM." Enmarca solicitudes en términos que ingeniería y finanzas ya se importan: radio de explosión reducido, auditorías más rápidas, menos páginas a las 2 a.m. Si la empresa está persiguiendo SOC 2 o ISO 27001, ese plazo de cumplimiento es a menudo tu mejor punto de apalancamiento para obtener recursos, incluso si el cumplimiento en sí no es el objetivo.

Errores comunes en el primer año

Comprar una plataforma cara (SIEM, EDR, CSPM) antes de tener el proceso o personal para operarla realmente es el desperdicio más común de presupuesto temprano. Una herramienta de $50k que nadie sintoniza genera ruido, no detección. De manera similar, escribir políticas copiadas de una plantilla sin adaptarlas a cómo la empresa realmente funciona garantiza que sean ignoradas la primera vez que alguien necesita una excepción. E intentar ser propietario de todo solo después de los primeros seis meses es un camino hacia el agotamiento; en el momento en que hay tracción, la siguiente contratación generalmente debería ser alguien que pueda ser propietario de detección y respuesta para que puedas seguir construyendo la estructura del programa.

Seguridad desde cero es principalmente sobre secuenciación: ver qué existe, cerrar las brechas más ruidosas, construir suficiente proceso para que las decisiones no dependan de tu memoria, y expandir desde ahí.

Si este tipo de construcción de programa a nivel básico te interesa, Korra Studio tiene segmentos relacionados en fundamentos de respuesta a incidentes y postura de seguridad de cloud que funcionan bien con este.