A tragédia da segurança morre no crisol do DevOps

A segurança não é mais o que era. Ou talvez sempre tenha sido assim e apenas pareça diferente devido à lenta degradação do meu idealismo juvenil.

A segurança é bifurcada. Por um caminho, esforçamo-nos para manter as nossas organizações seguras. Para deter agentes maliciosos, proteger dados e ativos e defender os utilizadores de ameaças e até dos seus próprios erros. Pelo outro caminho está a conformidade. Garantir que a organização cumpre normas regulamentares, contratuais e outras. Em ambos os caminhos gerimos riscos: os riscos de violações e de indisponibilidade, ou os riscos de coimas regulamentares.

A tragédia da segurança é um reflexo da tragédia dos comuns. Da Wikipédia:

A maior parte da conformidade em segurança foi concebida para reduzir o risco de segurança. Pelo menos no papel. Mas, ao longo do tempo, temos visto norma após norma, regulamento após regulamento, dissociar o risco da conformidade. A própria natureza das normas de conformidade impede as organizações de adaptarem as medidas de segurança aos riscos organizacionais. Não afirmo que isto seja sempre verdade, mas é verdade em larga medida, sobretudo à medida que se avança para organizações maiores. Não há qualquer evidência de que exigir a redefinição de palavras-passe a cada 90 dias a utilizadores com MFA ou outras restrições condicionais hoje de uso corrente melhore a segurança. A pessoa que inventou os requisitos de complexidade das palavras-passe arrepende-se literalmente disso e afirma que não funcionam. Não existe evidência nem base científica sólida para exigir a encriptação não predefinida de todos os volumes de armazenamento num fornecedor de nuvem.

A segurança é um recurso partilhado e finito. Temos apenas um determinado montante de dinheiro, um determinado número de profissionais de segurança e uma determinada quantidade de tempo que o pessoal não dedicado à segurança pode dedicar à segurança em detrimento dos seus outros objetivos. Quanto mais puxamos para a conformidade, menos deste conjunto sobra para a segurança. Quanto menos a conformidade estiver alinhada com a segurança, menos esforços reduzem os riscos de segurança.

Esta é a tragédia da segurança. Dissociámos o risco da conformidade, tornando a falta de conformidade o próprio risco. Quanto mais os riscos reais estiverem dissociados da conformidade, mais rígido é o regime de conformidade, menos recursos de segurança estão disponíveis para a defesa e menor é o apoio das outras equipas aos esforços de segurança.

Um excelente exemplo surgiu numa conversa com Chris Farris. Parafraseando,

Os programadores preocupam-se, sim, com a segurança. É a conformidade que os irrita. Ajude-os a proteger a sua aplicação e eles apoiarão o esforço. Diga-lhes para assumirem uma indisponibilidade de 4 horas num fim de semana para reconstruir a base de dados com encriptação porque um burocrata da conformidade o exige e estará apenas a irritá-los.

Não estou a dizer que toda a conformidade se resume a regras estúpidas, mas algumas regras de conformidade são estúpidas, e a aplicação incorreta de boas regras, dissociadas dos riscos, é mesmo estúpida.

O DevOps torna-se o crisol do futuro da segurança porque, no mundo da nuvem e do DevOps, as equipas de aplicações individuais passam a ser responsáveis por toda a pilha, incluindo grande parte da segurança. Novos servidores, redes e firewalls estão à distância de um simples git commit e de algumas chamadas de API. Isto também coloca um maior encargo sobre essas equipas na gestão da sua própria segurança e conformidade. Continuamos a ter segurança centralizada e recursos de segurança partilhados, mas, quando se trata da linha da frente, dependemos muito mais das equipas de DevOps. Não podemos criar uma grande DMZ para a nuvem. As fronteiras entre redes internas e externas já não podem ser categorizadas em zonas padronizadas. Muitas aplicações construídas sobre serviços nativos da nuvem já nem sequer têm uma rede e dependem de regras de IAM e de políticas de recursos escritas em JSON, aplicadas pelas equipas de aplicações através de infraestrutura como código.

Assim, boa parte dos meus projetos recentes de conformidade focados em nuvem e DevOps consiste mais em fazer primeiro boa segurança e depois descobrir como redigir um relatório que pareça cumprir a letra da conformidade, ainda que não cumpra, mesmo quando é mais seguro.

Há duas soluções possíveis.

A primeira é rever as normas de segurança para melhor se adequarem à nuvem e ao DevOps e reduzir o número de regras estúpidas ou inaplicáveis. Parte deste trabalho está a acontecer, mas cheguei à conclusão de que isto exige uma mudança geracional pela qual não temos tempo para esperar. Não desistamos, mas não temos de esperar.

A outra é utilizar a automação para retirar às pessoas o máximo possível do encargo de segurança e conformidade, mantendo-lhes a liberdade e o controlo para construir depressa. Não estou a sugerir que o conjunto global de segurança diminua, mas que utilizemos a automação e outras tecnologias para reduzir a necessidade individual de gastar ciclos nas coisas menos valiosas.

Trata-se do tempo e do foco de recursos limitados. E, na verdade, o que é mais valioso… um bom teste de intrusão ou uma auditoria de conformidade? Agora veja quanto gasta em testes de intrusão e quanto paga por uma auditoria.