Como um CTO de startup SaaS equilibra velocidade de desenvolvimento e 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 ótimo exemplo: não construa um sistema de login com senhas. Sim, você poderia construí-lo em alguns dias, mas o custo para mantê-lo e adicionar recursos avançados de proteção no futuro será muito alto. Considere usar um login via Single-sign on, como Gmail, ou usar um serviço como Auth0.com. Você não apenas terá uma experiência de login mais fluida e rica em recursos, mas também não terá que se preocupar com toda uma classe de aspectos de segurança relacionados ao login (força bruta, credenciais de usuário vazadas em serviços de terceiros, prevenção e detecção de ataques de tomada de conta, validação de endereços de e-mail, logging...).

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 ótimos exemplos que podem economizar semanas ou meses são:

• Não armazene cartões de crédito, use algo como Stripe, Mollie ou Chargebee.
• Não execute softwares complexos como MySQL, PostgreSQL ou ElasticSearch por conta própria. Utilize serviços gerenciados de Cloud, como o RDS.
• Não crie seus próprios sistemas de log. Utilize sistemas como Sentry ou Papertrail (e não registre nenhum dado sensível neles).
• Não execute seus próprios servidores de e-mail (SMTP), use um serviço gerenciado como Sendgrid ou Mailgun.
• Não crie servidores de websocket, use serviços gerenciados como Pusher.com.
• Não crie seu próprio sistema de feature flagging, use um serviço como Launchdarkly.
• Não crie sua própria integração de calendário, use uma ferramenta como cronofy.com.
• Ao construir integrações em geral, procure por APIs Unificadas nesse espaço, como Apideck.

Invista algum tempo em uma configuração de comunicação de crise.

Certifique-se de ter ferramentas configuradas, como um aplicativo de chat para falar com seus clientes, ou melhor, uma página de status gerenciada ou conta do Twitter onde você possa comunicar problemas. Caso algo ruim aconteça, é uma ótima prática permitir que o restante da sua empresa se comunique com seus clientes enquanto você se concentra em resolver o problema durante uma crise.

Adicione guardrails globais.

Você provavelmente está revisando Pull Requests de seus desenvolvedores, ótimo! É uma tarefa e tanto revisá-los quanto à manutenibilidade, desempenho e funcionalidade. Você tem tempo para revisá-los também quanto à segurança? Com certeza você conseguirá cobrir alguns riscos, mas é bom poder mitigar alguns riscos adicionando guardrails e configurações globais.

Às vezes, você pode ter sorte e encontrar correções globais para problemas específicos.

• Se você usa nodeJS e não gosta de pensar em poluição de protótipo, você deve congelar o protótipo para desabilitar essa classe de ataques em todo o aplicativo. Aikido pode construir automaticamente um Pull Request que faz isso para você.
• Se você usa SQL e tem medo de ataques de injeção SQL (e deveria ter), você pode usar um WAF (como AWS WAF) ou RASP (como a segurança de aplicativos da Datadog) para proteção em todo o aplicativo.
• Se você está descobrindo muitos ataques XSS, provavelmente pode eliminar grande parte deles introduzindo uma política CSP muito rigorosa no navegador.
• Se você está fazendo muitas requisições de saída baseadas em entrada do cliente, pode estar vulnerável a ataques SSRF. Embora possa ser difícil bloquear isso completamente, você pode mitigar danos garantindo que não leve a algo pior (como um ataque IMDSv1 em credenciais IAM na AWS). O Aikido monitora isso na sua Cloud AWS por padrão.
• Ao lidar com armazenamento de objetos, 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 muitos exploits típicos relacionados à desserialização insegura. O Aikido monitora esses tipos de funções na sua base de código por padrão.
• Se você usa um CDN ou mecanismos de cache, utilize domínios separados para seus ativos estáticos com configurações de CDN separadas para evitar todos os tipos de ataques de cache poisoning (o ChatGPT caiu nessa armadilha recentemente).

Eduque seus desenvolvedores com este truque simples.

Há um truque fácil (trocadilho intencional) que você pode implementar em seus processos. Uma pergunta rápida para fazer à equipe de desenvolvimento durante o planejamento do sprint:

Como a funcionalidade que estamos construindo pode ser hackeada? (& como podemos evitar que isso aconteça)

Embora a equipe de desenvolvimento possa não antecipar todos os cenários potenciais de abuso, esta metodologia é extremamente simples de escalar. É um pequeno passo extra que incentiva os desenvolvedores a verificar as considerações de segurança antes de iniciar qualquer trabalho de desenvolvimento.

Atribua prioridades a diferentes partes da sua base de código.

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

• Sistemas de pagamento, carteiras, sistemas de crédito
• Funcionalidades que se conectam a APIs caras como SMS, VoIP (pense em Twilio)
• Redefinição de senha, sistemas de login, convites de usuário
• Recursos de exportação, como PDF, Excel, etc., que podem realizar operações arriscadas
• Qualquer coisa relacionada a upload de arquivos e imagens
• Recursos que realizam requisições outbound por design, como webhooks
• Qualquer tipo de recurso que envia e-mail, especialmente com conteúdo personalizado

PS: O Aikido pode ajudar você a focar apenas nos principais repositórios no universo da sua startup, atribuindo níveis de risco a cada base de código.

Não se esqueça do aspecto humano

Como CTO em uma pequena startup, você geralmente também é o responsável pela segurança operacional. Forneça à sua equipe os meios para proteger suas contas. Certifique-se de que eles usem Yubikeys de hardware ou aplicativos de software para 2FA e, se possível, force o uso. Ferramentas como o Gmail permitem impor isso. É uma ótima primeira linha de defesa contra ataques de phishing.

Manter-se atualizado com as práticas de segurança é difícil

Aprender sobre novos tipos de ataques em software é difícil. Já é difícil acompanhar as atualizações das linguagens que você usa (Python, Node, Go,..) ou a aplicação de patches de SO ou exploits populares em pacotes de código aberto. Ataques específicos se tornam mais populares com o tempo, então vale a pena seguir as tendências. Por exemplo, após notar um aumento nos ataques de sequestro de subdomínio no ano passado, o Aikido introduziu uma ferramenta de monitoramento de sequestro de subdomínio para prevenir esse risco e automatizar a prática de monitorar esses registros DNS.

Automatize

Nas minhas empresas anteriores, tentávamos alcançar um próximo nível de segurança tendo uma pessoa de segurança que criava um calendário com tarefas de segurança recorrentes. Fazer uma revisão de acesso para todos os aplicativos a cada trimestre. Fazer uma varredura de Secrets vazados no código a cada duas semanas, limpar os CVEs de pacotes de código aberto toda sexta-feira, fazer um scan SAST de vez em quando, verificar os registros DNS para sequestros de subdomínio todo mês,... A saída dessas tarefas era difícil de triar e tornar acionável para os desenvolvedores. Pior, quando essa pessoa saía da empresa, era difícil para qualquer outra pessoa assumir essas tarefas porque elas exigiam muito conhecimento específico.

Foi aqui que a ideia do Aikido começou a crescer. Precisávamos de uma solução que automatizasse tudo o que foi mencionado, filtrasse o ruído e apresentasse as tarefas aos seus desenvolvedores no Slack ou Jira.

Comece a escanear seu código e Cloud com Aikido hoje mesmo. Inscreva-se aqui e comece a escanear gratuitamente.