Cibersegurança em fintech: como desenvolver com segurança usando código aberto

Por que a cibersegurança é importante para empresas de fintech?

Transações financeiras são alvos naturais para hackers em busca de dinheiro fácil. Por esse motivo, os bancos tradicionais estão sujeitos a regulamentações rigorosas de cibersegurança. Já as empresas de tecnologia financeira (fintechs) não são tão regulamentadas quanto os bancos e, muitas vezes, deixam de seguir etapas importantes do processo de segurança, especialmente quando não há uma exigência clara de proteger totalmente as aplicações.

Mas as fintechs devem considerar a cibersegurança uma prioridade máxima por alguns motivos:

Tipos de dados armazenados

Como as fintechs lidam com os mesmos tipos de dados financeiros que os bancos, elas são alvos atraentes para invasores. Esses dados confidenciais incluem informações de contas, saldos, fluxos de caixa, orçamentos e contatos.

Considerando o valor desses dados, sobretudo para mineração em projetos de IA/ML, as fintechs têm motivos para armazenar o máximo possível de dados específicos e úteis. Mas há uma contrapartida: armazenar grandes volumes de dados torna essas empresas alvos mais valiosos.

Custos das violações

Para os bancos tradicionais, o custo de uma violação inclui tanto os custos diretos quanto os indiretos, como danos à reputação e multas. Uma única violação também pode levar milhares de clientes a abandonar o banco. Como as fintechs lidam com os mesmos tipos de dados que os bancos, uma violação pode ter um impacto negativo semelhante. A perda da confiança dos clientes e os danos à reputação talvez sejam os aspectos mais custosos de uma violação, sobretudo para startups de fintech ou empresas em hiper crescimento. As violações também podem ter consequências legais, como multas e processos judiciais.

Conformidade

As fintechs têm a obrigação de cumprir os requisitos de Know Your Customer (KYC), além das regulamentações locais de cada região onde seus clientes estão. Essas regulamentações incluem:

• Na União Europeia: O Regulamento Geral sobre a Proteção de Dados (GDPR) regulamenta o processamento de dados pessoais de pessoas que residem na UE, mesmo que a organização esteja fora do bloco. O Regulamento eIDAS sobre Identificação Eletrônica e Serviços de Confiança rege as transações digitais transfronteiriças e oferece uma estrutura unificada para fintechs, organizações clientes, autoridades reguladoras e usuários finais. A Diretiva de Serviços de Pagamento (PSD2) estabelece requisitos de segurança para pagamentos eletrônicos. A PSD2 frequentemente se sobrepõe ao GDPR, por isso pode ser necessário consultar especialistas para garantir a conformidade.

• Nos EUA: Padrão de Segurança de Dados do Setor de Cartões de Pagamento (PCI DSS), que regulamenta a coleta, o processamento e o uso de dados dos principais cartões de crédito.

• No estado da Califórnia: A Lei de Privacidade do Consumidor da Califórnia (CCPA) é semelhante ao GDPR, mas apresenta algumas diferenças, como nas definições de termos jurídicos. A agregadora de dados de fintech Yodlee enfrentou uma ação coletiva após supostamente violar a CCPA com suas práticas de coleta e uso de dados.

Quais desafios de cibersegurança as fintechs enfrentam?

A cibersegurança precisa ser uma prioridade máxima para as fintechs, mas há muitos obstáculos para proteger as aplicações de forma adequada. Tradicionalmente, a cibersegurança se concentrava em proteger o produto final com senhas, criptografia, autenticação multifator e lógica segura. A responsabilidade pela segurança ficava nas mãos das equipes de operações de TI e segurança. Em geral, as aplicações só eram testadas depois de lançadas no ambiente de produção, deixando muitas organizações expostas. Quando um bug ou uma vulnerabilidade era descoberto, as equipes de segurança tinham que voltar aos desenvolvedores.

Hoje, a maioria das empresas também inclui testes de segurança antes do lançamento. O problema é que isso pode gerar consequências imprevistas e prolongar o ciclo de lançamento. Como lidar com dezenas ou até centenas de vulnerabilidades que podem ser descobertas? Corrigi-las pode exigir reescritas significativas dos componentes de software subjacentes, que então precisam ser verificados e testados novamente. Além disso, isso cria atritos entre as equipes de segurança e de desenvolvimento. Para levar um produto fintech ao mercado mais rapidamente, os desenvolvedores podem lançar software inseguro, mas corrigir os problemas mais tarde no ciclo de vida de desenvolvimento de software (SDLC) fica muito caro.

Em resumo, essas práticas tradicionais de teste ficaram ultrapassadas. Os tipos de vulnerabilidade evoluíram, e a forma de desenvolver e entregar software mudou. Como o mercado exige entregas rápidas, o desenvolvimento de aplicações convencional adota uma abordagem ágil. Essa abordagem mais moderna de DevOps divide grandes lançamentos monolíticos em sprints mais curtos, permite lançar novos recursos várias vezes ao dia, acelerar as iterações e incluir automação sempre que possível. Organizações que adotam uma abordagem ágil percebem que ferramentas legadas de segurança de aplicações, criadas para a era pré-nuvem, viram um gargalo para implantações rápidas e seguras.

Quais são os riscos do código aberto para as fintechs?

A proliferação de bibliotecas e pacotes de código aberto traz um desafio adicional para a cibersegurança das fintechs. Aplicações em nuvem geralmente integram diversas bibliotecas e serviços de código aberto. Isso permite que os desenvolvedores aproveitem o trabalho já feito por outras pessoas, mas também abre uma brecha para que invasores violem redes.

Essas aplicações de código aberto podem conter vulnerabilidades que chegam à produção. Quando elas são detectadas no fim do processo de compilação ou em produção, acabam causando atrasos nos projetos.

As dependências transitivas (ou dependências de dependências) representam um risco específico, pois criam uma árvore de dependências complexa. Isso facilita que passe despercebido quando sua aplicação chama um pacote com vulnerabilidades. Com o uso crescente de código aberto, as aplicações modernas de fintech têm uma superfície de ataque maior do que apenas o código proprietário que desenvolvem.

Como aplicar uma cultura de DevSecOps em fintechs?

A realidade do desenvolvimento moderno de software exige que a segurança seja um processo, e não uma solução pontual. A segurança deve estar presente em todo o ciclo de desenvolvimento, com ferramentas de teste de segurança, testes de invasão e auditorias.

Essa nova abordagem de segurança, conhecida como DevSecOps, é uma extensão do DevOps que introduz a responsabilidade compartilhada pela segurança entre as equipes de desenvolvimento, segurança e operações. As equipes de segurança e DevOps trabalham juntas desde o início para integrar a segurança ao pipeline de CI/CD. A modelagem de ameaças é feita desde cedo e com frequência. Durante todo o processo, os desenvolvedores usam a análise de composição de software (SCA) para monitorar componentes de código aberto.

Os recursos e as aplicações em produção são resultado de um processo colaborativo. A equipe de segurança não precisa procurar as equipes de desenvolvimento depois, pois elas sabem que a segurança foi integrada ao processo desde o início. Assim, incorporar a segurança aos processos de DevOps dá aos desenvolvedores responsabilidade pela segurança. Como as vulnerabilidades e os bugs são detectados cedo, o DevSecOps resulta em entregas de software mais rápidas e seguras, com custos menores.

A transição de DevOps para DevSecOps não é responsabilidade apenas dos desenvolvedores. As equipes de segurança devem supervisionar o planejamento e se concentrar em aplicar a segurança com o mínimo de interrupção aos fluxos de trabalho existentes.

Adote uma mentalidade de segurança desde a concepção

O DevSecOps busca garantir a segurança do software desde a concepção. Isso começa nas primeiras etapas do desenvolvimento com a segurança de software, uma abordagem proativa que se concentra em prevenir problemas no código, como estouros de buffer e tratamento inadequado de exceções.

É fundamental acertar essas etapas iniciais do desenvolvimento, definindo ferramentas e procedimentos para encontrar e corrigir bugs. As cadeias de dependências de bibliotecas e pacotes de código aberto também são importantes, pois podem se tornar confusas e ocultar vulnerabilidades nas aplicações.

Ciclos rápidos de feedback ajudam a reduzir a ocorrência de bugs, e é importante escolher bibliotecas de código aberto seguindo princípios de segurança desde a concepção.

Implemente os princípios de shift left

Um aspecto essencial da segurança desde a concepção é a segurança shift left, que incorpora medidas de segurança de aplicações desde o início. Antecipar a segurança permite que os desenvolvedores a integrem aos fluxos de trabalho existentes, enquanto as equipes de segurança podem oferecer suporte e supervisão. O processo começa pela definição de políticas de segurança e, em seguida, pela avaliação do processo de criação de software para identificar pequenas mudanças que permitam testar mais cedo. É fundamental automatizar a segurança e dar às equipes visibilidade constante do processo.

Crie um SDLC seguro

Um SDLC seguro complementa uma abordagem de desenvolvimento de software com DevSecOps. O DevSecOps se concentra em criar responsabilidade compartilhada pela segurança das aplicações, enquanto um SDLC seguro se concentra em incorporar a segurança ao processo de design e desenvolvimento.

Proteger o SDLC padrão começa com uma mudança de mentalidade nas equipes de desenvolvimento. O foco não deve estar apenas na funcionalidade, mas também na segurança ao longo de todo o projeto. O objetivo não é eliminar as verificações tradicionais, mas resolver possíveis problemas desde o início, em vez de tentar voltar atrás depois que o software é implantado em produção.

As equipes de desenvolvimento lideram os esforços de segurança: os especialistas no domínio que escrevem o software corrigem os problemas. Pode parecer muito trabalho, mas a maior parte é automatizada em um ambiente de SDLC seguro. O resultado são aplicações mais seguras em produção e a um custo menor.

Como a Snyk apoia a cibersegurança em fintechs

Snyk Open Source é uma ferramenta de SCA que detecta vulnerabilidades em dependências enquanto você programa no IDE ou na CLI. Fácil de usar para desenvolvedores, a ferramenta analisa pull requests antes do merge e pode impedir que vulnerabilidades avancem no processo de compilação. A Snyk permite automatizar testes em todo o pipeline de CI/CD e testa continuamente suas aplicações para identificar a exposição a vulnerabilidades conhecidas ou recém-descobertas. Outros recursos incluem monitoramento contínuo, regras de segurança personalizadas e gerenciamento automatizado da conformidade de licenças.

Como empresa de fintech que lida com informações privadas e confidenciais, a Revolut precisa cumprir normas específicas. A implementação da Snyk permite à empresa proteger sua infraestrutura principal e manter a conformidade com o PCI, entre outros requisitos.

“Passamos o ano todo sendo auditados. Com a Snyk, podemos dizer que protegemos nosso pipeline de código aberto”, disse Evangelos Deirmentzoglou. “Assim, não se trata apenas de melhorar nossa exposição a riscos de segurança, mas também de apoiar nossos esforços de conformidade.”

Saiba mais sobre como a Revolut usou a Snyk para melhorar sua cibersegurança e cumprir as normas regulatórias.

Para saber mais sobre o uso de componentes de código aberto em fintechs, confira nosso webinar sob demanda: Boas práticas e armadilhas no uso de componentes de código aberto em fintechs

Perguntas frequentes sobre cibersegurança em fintechs