Segurança cibernética: como fechar flancos

Não há dúvidas quanto aos desafios da proteção de sistemas computacionais. Quase que semanalmente temos a divulgação de casos de vazamento de dados e de extorsões (ramsomware) pela mídia. A impressão que temos é que estamos perdendo esta guerra.

Grande parte das brechas que ocorrem são fruto de ataques tradicionais como abuso de privilégios, comprometimento de contas de acesso, patches não aplicados, falta de monitoração entre outros. Os ataques às aplicações WEB têm aumentado consideravelmente nos últimos anos. Primeiro na pandemia e mais recentemente por conta da guerra entre Rússia e Ucrânia. Segundo o CyberThreat Defense Report, publicado em 2022, 44,6% dos entrevistados estimaram que a rede de sua organização havia sido comprometida entre uma e cinco vezes nos últimos 12 meses, enquanto 27.9% estimavam entre 6 e 10 vezes. Estamos falando de mais de 70%!

Este artigo não tem a pretensão de abordar toda e qualquer possibilidade de comprometimento de sistemas, mas sim, chamar a atenção para três temas que têm tirado o sono dos gestores de TI e de segurança por conta do risco inerente de comprometimento e vazamento de informações: a) o crescimento vertiginoso do uso de APIs; b) a necessidade de inclusão da segurança durante o ciclo de desenvolvimento de aplicações; c) o desafio de monitorar os acessos aos bancos de dados, tanto em ambientes on premises quanto na nuvem.

Proteção de APIs

A melhor forma de viabilizar a integração entre sistemas e empresas é através do uso de APIs. Nos últimos anos temos experimentado um aumento exponencial no uso de APIs. Aliado à necessidade crescente do uso desta funcionalidade, há uma certa complexidade devido ao uso de microserviços, containers, ambientes on premises e multi clouds. Muitas empresas sequer possuem um inventário atualizado de suas APIs e isto aumenta consideravelmente o risco de comprometimento do ambiente.

Tradicionalmente, uma das formas de proteção de APIs é através do uso de arquivo OAS (OpenAPI specification). O arquivo OAS, basicamente, possui a descrição de como uma API funciona, quais métodos para acessar os API endpoints, URLs, tipos de campos e obrigatoriedade ou não de uso destes. Uma vez disponibilizado o arquivo, o cliente pode utilizá-lo nas plataformas de CloudWAF (WEB Application firewall em ambiente SaaS) e com isso criar um modelo positivo de segurança, isto é, aquilo que não for o correto será bloqueado.

O problema do uso de um arquivo estático como o OAS é que as APIs são muito dinâmicas, sofrendo modificações ao longo do tempo e levando à necessidade de constantes atualizações na plataforma de WAF (embora isto possa ser automatizado de alguma forma). Além disso, em muitos casos não há um arquivo OAS associado às APIs e a equipe de segurança/TI pode não ter visibilidade de todas as APIs.

Desta forma, soluções que se proponham a proteger as APIs devem ter, no mínimo, as seguintes características/funcionalidades:

• Levantar o inventário das APIs através do uso de aprendizado, que se atualize automaticamente à medida que as APIs mudem;
• Identificação destas APIs não somente no ambiente diretamente exposto à internet, mas também em sistemas internos que se integram com empresas parceiras como broakers, gateways de pagamento, chatbots, etc. E este acesso normalmente não é coberto pelo CloudWAF, por isso precisa também ser contemplado sob risco de perda de visibilidade do processo inteiro.

Não há dúvidas de que o uso crescente de APIs cria uma grande superfície de ataques e isso deve ser endereçado. Temos um exemplo do que pode acontecer devido a uma falha na proteção de APIs: em 2018, a operadora de telefonia móvel T-Mobile notificou os 2,3 milhões de assinantes de sua base que as informações de suas contas pessoais poderiam ter sido expostas. (Veja mais aqui)

Segurança no ciclo de desenvolvimento de aplicações

Tradicionalmente o desenvolvimento de aplicações era feito por uma equipe de desenvolvedores, que depois entregavam o código pronto para ser implementado pelas equipes de TI, e uma vez com os sistemas em produção era feita uma revisão de segurança (normalmente uma análise de vulnerabilidades ou pentest). Não é preciso dizer que isso é bastante ineficiente, especialmente em ambientes de nuvem devido à constante necessidade de agilidade na implementação. Descobrir uma vulnerabilidade depois de implantado um sistema é infinitamente mais custoso do que se isso tivesse sido feito ainda na fase inicial de desenvolvimento.

A implementação de segurança como parte do CI/CD (Continuous Integration/Continuous Delivery) de ambientes DevOps permite uma otimização deste processo, incluindo segurança em todas as etapas do pipeline de DevOps.

Uma das alternativas interessantes de segurança para este tipo de situação é o uso de ferramentas de monitoração/bloqueio de ataques que afetem a integridade destas aplicações. Como a proteção é feita na ponta, existe uma vantagem adicional que é a proteção leste-oeste. Ferramentas tradicionais de segurança como Firewalls, IPS, WAF, etc, são muito eficientes na proteção norte-sul, isto é, ataques originados na Internet, mas possuem maior dificuldade de proteção no sentido leste-oeste, também conhecido como movimentação lateral. Um ataque pode vir de um parceiro de negócios que esteja conectado via VPN e que não passe por estas ferramentas de segurança tradicionais.

Há um controle recomendado pelo NIST 800-53, na seção “System and Information Integrity Family”, Controle SI-7(17) Runtime Application Self-Protection, que é focado neste tipo de proteção. Um trecho interessante da descrição deste controle: “Runtime application self-protection employs runtime instrumentation to detect and block the exploitation of software vulnerabilities by taking advantage of information from the software in execution. Runtime exploit prevention differs from traditional perimeter-based protections such as guards and firewalls which can only detect and block attacks by using network information without contextual awareness.”

Para este tipo de solução é altamente recomendável:

• Integrar a ferramenta de proteção com as novas aplicações (via CI/CD pipeline) e também com aplicações legadas;
• Solução deve permitir a proteção, mesmo sem a necessidade de alterar o código-fonte das aplicações;
• Permitir identificar em qual parte da aplicação um determinado ataque aconteceu. Isso ajuda muito a equipe de desenvolvimento caso haja necessidade de mudar algo no código-fonte para correção da vulnerabilidade.

Monitoração e proteção de bancos de dados

A proteção de bancos de dados já foi algo mais fácil de se realizar! A quantidade de Bases de Dados era menor (Oracle, MS SQL, DB2 e algumas outras) e o conceito de perímetro era muito mais fácil de definir. Hoje temos mais de sessenta tipos diferentes! Além disso, ainda existe o desafio de atender às diversas normativas de mercado. Apenas para citar algumas, podemos lembrar de PCI, LGPD, SOX, HIPAA etc.

A tecnologia utilizada por este tipo de solução sempre envolveu a instalação de agentes que tinham por objetivo monitorar todos os acessos às bases/tabelas. Hoje, com o uso cada vez maior de bases de dados na modalidade PaaS, onde não é possível instalar agentes, torna-se necessário utilizar outras técnicas para sua efetiva monitoração. Isto normalmente é feito através da integração com os sistemas de Logs destas bases como o CloudWatch, o EventHub e Pubsub.

É fundamental que a solução escolhida possa centralizar a monitoração de logs de auditoria, originadas tanto no on premises, quanto na nuvem. Deve permitir também a retenção destas informações por vários anos, normalmente uma necessidade de conformidade.

E para finalizar, este tipo de solução deve permitir a integração com vários tipos de sistemas diferentes, não somente para enriquecimento de dados (exemplo: integração com informações provenientes de um CMDB) mas também com sistemas de tickets (ex: ServiceNow) e de SIEMs (ex: Splunk, QRadar etc).

Não há dúvidas de que a superfície de ataque é muito grande e isso certamente gera dificuldades, mas a proteção de componentes chave da infraestrutura, apoiada por uma boa análise de riscos, permite mitigar boa parte destas questões e proteger o ativo mais importante da empresa: a informação!

Segue uma lista de relatórios altamente recomendáveis que complementam o conteúdo deste artigo:

• CyberEdge 2022 CDR Report
• Gartner® Magic Quadrant™ for WAAP 2021 (Full Report)
• The Forrester Wave™: Bot Management, Q2 2022
• Forrester Insider Threats Drive Data Protection Improvements (Full Report)
• NIST Special Publication 800-53 - Revision 5