Como é que um CTO de uma startup SaaS consegue equilibrar a velocidade de desenvolvimento e a segurança?

Aprendizagens de empresas SaaS anteriores

Numa típica empresa SaaS em fase de arranque, a equipa de desenvolvimento está sob forte pressão para apresentar novas funcionalidades. Normalmente, há concorrentes que podem ser mais bem financiados, a equipa de vendas pede uma última funcionalidade para fechar o negócio, a equipa de apoio ao cliente pede uma correção de erros. Pode ser difícil dar prioridade à segurança, a menos que um cliente empresarial de maior dimensão o exija ou que a direção o imponha a partir do topo.

Na maioria das empresas em fase de arranque, é possível que não tenha uma gama completa de perfis técnicos à sua disposição: pode ainda não ter um gestor de produto a tempo inteiro, provavelmente não tem um chefe de segurança a tempo inteiro na sua equipa de desenvolvimento. Uma equipa de desenvolvimento sob pressão para entregar o produto será forçada a cortar muitos cantos, mesmo quando se trata de segurança.

Fui CTO de 3 empresas SaaS em fase inicial. (Teamleader, Officient & Futureproofed) Abaixo, descrevi as minhas aprendizagens com essas experiências anteriores em empresas SaaS.

Evitar reinventar a roda

Um bom exemplo: não crie um sistema de início de sessão com palavras-passe. Sim, pode construí-lo em poucos dias, mas o custo para o manter e adicionar funcionalidades de proteção avançadas no futuro será muito elevado. Considere a possibilidade de utilizar um início de sessão através de um início de sessão único, como o Gmail, ou utilize um serviço como o Auth0.com. Não só terá uma experiência de início de sessão mais suave e com mais funcionalidades, como também não terá de se preocupar com toda uma classe de aspectos de segurança relacionados com o início de sessão (força bruta, fuga de credenciais de utilizador em serviços de terceiros, evitar e detetar ataques de apropriação de conta, validar endereços de correio eletrónico, registo...).

No final, se escolher o fornecedor certo, não está apenas a reduzir a sua superfície de ataque, está também a ganhar tempo que pode ser gasto em funcionalidades mais valiosas.

Outros exemplos excelentes que podem poupar-lhe semanas ou meses são:

• Não guarde cartões de crédito, utilize algo como Stripe ou Mollie ou Chargebee
• Não execute você mesmo software complexo como MySQL, PostgreSQL ou ElasticSearch. Utilize serviços geridos na nuvem, como o RDS.
• Não crie os seus próprios sistemas de registo. Utilize sistemas como o Sentry ou o Papertrail (e não registe aí quaisquer dados sensíveis)
• Não utilize os seus próprios servidores de correio eletrónico (SMTP), utilize um serviço gerido como o Sendgrid ou o Mailgun
• Não construa servidores de websocket, utilize serviços geridos como o Pusher.com
• Não crie o seu próprio sistema de marcação de caraterísticas, utilize um serviço como o Launchdarkly
• Não crie a sua própria integração de calendário, utilize uma ferramenta como o cronofy.com
• Ao criar integrações em geral, verifique se existem APIs unificadas nesse espaço, como o Apideck.

Investir algum tempo num sistema de comunicação de crise

Certifique-se de que tem ferramentas configuradas, como uma aplicação de conversação para falar com os seus clientes, ou melhor, uma página de estado gerida ou uma conta no Twitter onde pode comunicar problemas. No caso de algo de mau acontecer, é uma boa prática permitir que o resto da sua empresa comunique com os seus clientes enquanto se concentra na resolução do problema durante uma crise.

Adicionar barreiras de proteção globais

Provavelmente está a rever os Pull Requests dos seus programadores, ótimo! É uma tarefa e tanto revisá-los quanto à capacidade de manutenção, desempenho e funcionalidade. Tem tempo para os rever também em termos de segurança? De certeza que vai conseguir cobrir alguns riscos, mas é bom poder contornar alguns riscos adicionando alguns guardrails e configuração global.

Por vezes, é possível ter sorte e existem correcções globais para problemas específicos.

• Se você usa nodeJS e não gosta de pensar em poluição de protótipos, você deve congelar o protótipo para desabilitar esta classe de ataques em toda a aplicação. O Aikido pode construir automaticamente um Pull Request que faz isso por si.
• Se utilizar SQL e tiver receio de ataques de injeção de SQL (deveria ter), pode utilizar um WAF (como o AWS WAF) ou RASP (como a segurança de aplicações da Datadog) para proteção de toda a aplicação
• Se estiver a descobrir muitos ataques XSS, é provável que consiga eliminar uma grande parte deles introduzindo uma política CSP muito rigorosa no browser.
• Se estiver a fazer muitos pedidos de saída com base na entrada do cliente, poderá estar vulnerável a ataques SSRF. Embora possa ser difícil bloquear isto completamente, pode atenuar os danos certificando-se de que não pode levar a algo pior (como um ataque IMDSv1 às credenciais IAM no AWS). O Aikido monitoriza isto na sua nuvem AWS por predefinição.
• Ao lidar com o armazenamento de objectos, evitar tipos específicos de funções como Pickle, XML, (un)serialize em Java e PHP,... e em vez disso optar por opções de armazenamento simples como JSON pode evitar muitas explorações típicas relacionadas com a não-serialização insegura. O Aikido monitoriza este tipo de funções na sua base de código por defeito.
• Se utilizar um CDN ou mecanismos de cache, utilize domínios separados para os seus activos estáticos com configurações de CDN separadas para evitar todos os tipos de ataques de envenenamento de cache (o ChatGPT deparou-se com esta armadilha recentemente)

Eduque os seus programadores com este truque simples

Há um truque fácil (trocadilho intencional) que pode implementar nos seus processos. Uma pergunta rápida para fazer à equipa de desenvolvimento durante o planeamento do sprint:

Como é que a funcionalidade que estamos a construir pode ser pirateada (e como podemos evitar que isso aconteça)?

Embora a equipa de desenvolvimento possa não prever todos os cenários de abuso potenciais, esta metodologia é muito simples de escalar. É um pequeno passo extra que incentiva os programadores a verificarem as considerações de segurança antes de efectuarem qualquer trabalho de desenvolvimento.

Atribuir prioridades a diferentes partes da sua base de código

Nem tudo será um alvo tão grande para os hackers. Os principais componentes que eles gostam de atacar são :

• Sistemas de pagamento, carteiras electrónicas, sistemas de crédito
• Funcionalidade que se liga a APIs dispendiosas como SMS, voip (pense em Twilio)
• Redefinição da palavra-passe, sistemas de início de sessão, convites de utilizadores
• Funções de exportação como PDF, Excel,... exportações que podem efetuar operações de risco
• Qualquer coisa relacionada com o carregamento de ficheiros e imagens
• Caraterísticas que fazem pedidos de saída por conceção, tais como webhooks
• Qualquer tipo de funcionalidade que envie correio eletrónico, especialmente com conteúdo personalizado

PS: O Aikido pode ajudá-lo a concentrar-se apenas nos principais repositórios do universo da sua empresa, atribuindo níveis de risco a cada base de código.

Não esquecer o aspeto humano

Como CTO numa pequena empresa em fase de arranque, é normalmente também o responsável pela segurança operacional. Forneça à sua equipa os meios para proteger as suas contas. Certifique-se de que utilizam Yubikeys de hardware ou aplicações de software para a 2FA e, se possível, imponha-a. Ferramentas como o Gmail permitem aplicar esta medida. É uma óptima primeira linha de defesa contra ataques de phishing.

É difícil manter-se atualizado em relação às práticas de segurança

Aprender sobre novos tipos de ataques a software é difícil. Já é suficientemente difícil acompanhar as actualizações das linguagens que utilizamos (Python, Node, Go,...) ou as correcções dos sistemas operativos ou as explorações populares em pacotes de código aberto. Ataques específicos tornam-se mais populares ao longo do tempo, pelo que vale a pena seguir as tendências. Por exemplo, depois de notar um aumento nos ataques de aquisição de subdomínios no ano passado, a Aikido introduziu uma ferramenta de monitorização de aquisição de subdomínios para evitar esse risco e automatizar a prática de monitorização destes registos DNS.

Automatizar

Nas minhas empresas anteriores, tentávamos chegar a um nível superior de segurança pedindo a um responsável pela segurança que criasse um calendário com tarefas de segurança recorrentes. Fazer uma análise de acesso a todas as aplicações todos os trimestres. Fazer um scan de leaked-secrets no código de duas em duas semanas, limpar os CVEs dos pacotes de código aberto todas as sextas-feiras, fazer um scan SAST de vez em quando, verificar os registos DNS para takeovers de subdomínios todos os meses,... O resultado destas tarefas era difícil de triar e tornar acionável para os programadores. Pior ainda, quando essa pessoa deixava a empresa, era difícil para qualquer outra pessoa assumir essas tarefas porque exigiam muitos conhecimentos específicos.

Foi aqui que a ideia do Aikido começou a crescer. Precisávamos de uma solução que automatizasse tudo o que foi dito acima, filtrasse o ruído e colocasse as tarefas à frente dos seus programadores no Slack ou no Jira.

Comece hoje a digitalizar o seu código e a sua nuvem com o Aikido. Registe-se aqui e comece a digitalizar gratuitamente.