Prévia do material em texto
Desenvolvimento de Software Seguro Marcio Quirino - 1 SUMÁRIO Princípios de Software Seguro .............................................................................................................. 5 Propósito .................................................................................................................................................... 5 Objetivos .................................................................................................................................................... 5 Introdução .................................................................................................................................................. 5 1. Princípios de segurança e o software seguro ......................................................................... 5 Aspectos essenciais entre princípios de segurança e software seguro ..................................................... 5 O essencial da confidencialidade ............................................................................................................... 6 A garantia da integridade ........................................................................................................................... 7 A importância da disponibilidade ................................................................................................................ 8 A importância da autenticação e autorização ............................................................................................. 9 2. Princípios de design seguro de software ................................................................................. 9 Elementos fundamentais do design de um software seguro ...................................................................... 9 Fundamentos do privilégio mínimo de um software seguro ..................................................................... 10 Defesa em profundidade e padrões à prova de falhas ............................................................................. 11 Defesa em profundidade ...................................................................................................................... 11 Os padrões à prova de falhas .............................................................................................................. 11 Separação de funções e Security by Design ............................................................................................ 12 Economia de mecanismo, design aberto e defesa contra erros ............................................................... 12 3. Avaliação da cadeia de suprimentos ..................................................................................... 13 Elementos da cadeia de suprimentos de um software seguro ................................................................. 13 Vulnerabilidades dos componentes de um software ................................................................................ 14 Avaliação e gerenciamento dos riscos ..................................................................................................... 14 Práticas de codificação segura................................................................................................................. 15 Testes de vulnerabilidades do software ................................................................................................... 16 4. Conclusão............................................................................................................................... 17 Considerações finais ................................................................................................................................ 17 Explore + .................................................................................................................................................. 17 Referências .............................................................................................................................................. 17 Questões de Implementação Para Software Seguro .......................................................................... 18 Propósito .................................................................................................................................................. 18 Objetivos .................................................................................................................................................. 18 Introdução ................................................................................................................................................ 18 1. Validação de entrada ............................................................................................................. 18 Verificação e validação......................................................................................................................... 19 Vulnerabilidades na entrada de dados ................................................................................................. 19 Bibliotecas de validação de entrada ......................................................................................................... 20 Exemplos de bibliotecas ....................................................................................................................... 20 Implementação da validação de entrada no servidor ............................................................................... 21 Etapas para validação no lado do servidor........................................................................................... 21 Desenvolvimento de Software Seguro Marcio Quirino - 2 Limpeza de todas as entradas do usuário ................................................................................................ 22 Etapas da tarefa de limpeza de dados ................................................................................................. 22 Teste e revisão do código de validação de entrada ................................................................................. 23 Etapas dos testes e revisão do código de validação de entrada .......................................................... 23 2. Processamento de dados com segurança ............................................................................ 24 Fundamentos do processamento de dados seguros ................................................................................ 24 Práticas para processamento seguro dos dados ................................................................................. 24 Controles de acesso ................................................................................................................................. 25 Criptografia de dados ............................................................................................................................... 26 Algoritmos de criptografia ..................................................................................................................... 26 Protocolos de comunicação seguros ........................................................................................................ 27 Busca por vulnerabilidades e testes ......................................................................................................... 27 3. Chamadas em software seguro ............................................................................................. 28 Fundamentos de Chamadas .................................................................................................................... 28 O uso de funções e medidas preventivas para chamadas seguras ..................................................... 28 Chamadas de APIs do sistema ................................................................................................................ 29 Definição de permissões ..........................................................................................................................de comprimento. ✓ O Django é um framework de código aberto para desenvolvimento web com a linguagem Python, baseado no padrão arquitetural model-template-views. 6. Laravel Validation ✓ Específica para validar entradas em aplicações web PHP. Ela permite validar a entrada em vários formatos, como strings, números e datas e suporta regras de validação personalizadas. Portanto, existem diversas bibliotecas de validação de entrada disponíveis para as mais variadas programações. Aqui, apresentamos apenas algumas. O mais importante é que você utilize uma biblioteca para implementar a validação da entrada para reduzir as vulnerabilidades do software que está desenvolvendo e isso certamente vai demandar mais estudo! Porém, tenha certeza de que está investindo o seu tempo para adquirir um conhecimento muito valorizado pelo mercado e capaz de lhe auxiliar em termos de empregabilidade e destaque profissional. A seguir, vamos falar sobre a implementação da validação de entrada do lado do servidor. O desenvolvimento de um software seguro, realmente, demanda muito estudo, mas estamos aqui para isso, não é mesmo? Então, vamos lá! Implementação da validação de entrada no servidor Quando falamos sobre validação de entrada de dados, quase sempre estamos nos referindo à aplicação do lado do cliente. No entanto, também devemos nos preocupar com a validação de entrada do lado do servidor. Atualmente, é muito comum utilizarmos aplicações que servem apenas para acessar o servidor e visualizar dados. Portanto, é necessário implementar a validação de entrada do lado do servidor, a fim de adicionar mais um elemento na criação de software seguro. Isso nos permite evitar vários tipos de vulnerabilidades, como ataques de injeção e estouros de buffer. Etapas para validação no lado do servidor A seguir, apresentamos algumas das etapas que devemos implementar para realizar a validação de entrada segura do lado do servidor: 1. Identificar as entradas ✓ Desenvolver métodos ou utilizar funções de bibliotecas — o que é a situação ideal - para identificar, explicitamente, quaisquer dados enviados. Esses dados podem vir por meio de formulários, cabeçalhos HTTP, cookies ou qualquer outra forma de entrada. 2. Definir regras de validação ✓ Definir tipos, comprimentos e formatos de dados esperados. 3. Validar entrada ✓ Validar as entradas para o servidor para verificar se estão em conformidade com as regras definidas. Caso não estejam, jamais devemos apresentar uma mensagem de erro do sistema para o usuário, mas sim uma mensagem indicando que o formato é inválido, sem fornecer dicas. 4. Limpar a entrada ✓ Remover qualquer código ou caracteres maliciosos é imprescindível. Em especial, no caso de entradas para consultas ao banco de dados, elas podem conter ataques de injeção de SQL. 5. Realizar verificações de segurança de vulnerabilidades conhecidas ✓ Conhecer as vulnerabilidades é fundamental para que possamos evitá-las. Existem muitos ataques bem documentados, como Cross-Site Scripting (XSS), que permitem a um invasor Desenvolvimento de Software Seguro Marcio Quirino - 22 injetar código malicioso em uma página da web utilizada por outros usuários; e Cross-Site Request Forgery (CSRF), que permite a um invasor executar ações não autorizadas em nome de um usuário legítimo. 6. Manter um log dos erros de validação ✓ Utilizar mecanismos que registrem todas as ações ocorridas no sistema, de modo a investigar, caso seja necessário, os erros de validação que ocorrerem é muito importante para, assim, acionarmos os mecanismos legais para punir os invasores. Apesar de existirem muitas formas de tratar erros de validação de entrada, também há muitos golpes que se renovam. 7. Manter as regras de validação atualizadas ✓ Revisar os processos e garantir que estejam sendo aplicados é igualmente importante. Nesse sentido, o uso dos logs é fundamental para entendermos o que realmente está acontecendo no sistema e, assim, nos guiar sobre quais são as melhores ações a tomar para melhorarmos a validação da entrada do servidor. Todas essas etapas nos ajudam a implementar a validação de entrada do lado do servidor e reduzir as vulnerabilidades de segurança do nosso software. Na sequência, vamos analisar a limpeza dos dados dos usuários, com o objetivo de reduzir vulnerabilidades e aumentar a segurança dos nossos sistemas. Limpeza de todas as entradas do usuário Vamos imaginar a seguinte situação: você desenvolveu um pequeno sistema para a área de contabilidade da empresa. O cliente lhe informou que os dados de entrada sempre seriam numéricos e, portanto, você focou na implementação das regras de negócio e sem a suposição (ingênua) de que os usuários do sistema sempre entrariam com dados numéricos. Infelizmente, uma pessoa entrou com uma cadeia de caracteres – string – e o sistema falhou, apresentando uma mensagem de erro sem nenhum tipo de tratamento. Esta é uma situação muito comum de vulnerabilidade de software. Etapas da tarefa de limpeza de dados Esse cenário ocorre com muita frequência e serve como alerta sobre a importância de realizarmos ações de limpeza dos dados de entradas do usuário, para aumentamos a segurança do nosso servidor de software. No entanto, essa tarefa pode implicar a exclusão de dados do usuário. Por isso, precisamos de um processo bem definido para realizá-la com segurança. A seguir, apresentamos algumas etapas possíveis: 1. Identificar as entradas do usuário ✓ Nesta etapa, precisamos saber onde os dados ficam e como deveriam estar armazenados. Para isso, precisamos mapear as tabelas de banco de dados, os servidores, os arquivos de logs e quaisquer outros meios de armazenamentos de dados. 2. Determinar as políticas de retenção ✓ Aqui, nos referimos a quanto tempo os dados devem ser mantidos, quem deve ter acesso a eles e como devem ser destruídos quando não forem mais necessários. 3. Definir um processo para limpar as entradas do usuário ✓ Esta é uma etapa fundamental, pois precisamos definir um processo que faça verificação da identidade do usuário, validação das permissões do usuário para limpar os dados e um controle para confirmar a intenção do usuário de realmente excluir os dados e, obviamente, registrar essa ação em um arquivo de log. 4. Usar métodos de exclusão segura ✓ Nesta etapa aplicamos métodos que, de fato, apaguem os dados, de modo que não possam ser recuperados por um invasor. Desenvolvimento de Software Seguro Marcio Quirino - 23 5. Registrar o processo de exclusão ✓ Sempre devemos utilizar uma ferramenta ou uma configuração de sistema que permita fazer o registro do processo de exclusão, ou seja, devemos ser capazes de responder quem excluiu os dados, quando foi realizada a exclusão e qual foi o motivo da exclusão. 6. Notificar o usuário ✓ Por fim, o sistema deve avisar explicitamente ao usuário que seus dados foram excluídos com segurança. Essas etapas auxiliam na limpeza dos dados de entradas do usuário com segurança e garantem que estejam protegidos segundo as regras corporativas – no caso, de empresas e demais organizações – ou enquanto assim desejarmos – no caso de uso pessoal. Teste e revisão do código de validação de entrada Por mais eficiente que seja a técnica que apliquemos no nosso sistema, do lado dos invasores vai existir um grande esforço para violar a segurança. Em especial, no caso de dados valiosos, isso se torna ainda mais crítico. Por isso, precisamos realizar treinamentos e estudar esse assunto continuamente. Atenção Uma etapa crítica no desenvolvimento de software seguro é fazer testes e revisões rotineiras do código de validação de entrada. Etapas dos testes e revisão do código de validação de entrada Essa é uma forma preventiva de reduzir vulnerabilidades e, caso seja necessário, realizar melhorias no código ou no próprio processo de validação de entrada. A seguir,estão listadas algumas etapas que podemos realizar para testar e revisar o código de validação de entrada em um software seguro: 1. Verificar a qualidade das regras de validação ✓ É essencial estarmos sempre alinhados com as melhores práticas de segurança. Por isso, precisamos entrar em sites como a OWASP e outros fóruns para acompanhar novas técnicas de validação e discussões sobre o assunto de profissionais que trabalham na área. 2. Testar entradas inválidas ✓ É necessário criar diversos cenários que forcem entradas inválidas no sistema. Essa abordagem é uma forma muito eficiente de simular ataques, identificar possíveis vulnerabilidades e, posteriormente, corrigi-las. 3. Testar entradas válidas ✓ É uma boa forma de simularmos o comportamento dos usuários legítimos que farão uso do sistema. Vamos avaliar se o sistema vai se comportar conforme o planejado para entradas válidas de usuário. 4. Realizar testes de estresse ✓ A ideia é forçar situações extremas, com a finalidade de identificar possíveis vulnerabilidades na validação de entrada. 5. Usar técnicas de fuzzing ✓ É importante para que seja possível automatizar testes que gerem entradas aleatórias ou, ainda, entradas que possam acionar determinados tipos de vulnerabilidades. 6. Revisar o código para vulnerabilidades de segurança ✓ É necessário revisar o código de validação de entrada e, se for o caso, realizar melhorias para nos prevenir de vulnerabilidades, visando reduzir as chances de que os invasores sejam bem sucedidos ao aplicar novas técnicas para atacar o sistema. 7. Usar bibliotecas de validação ✓ É sempre importante utilizar bibliotecas, pacotes e ferramentas que têm como finalidade realizar testes para detectar vulnerabilidades. Desenvolvimento de Software Seguro Marcio Quirino - 24 2. Processamento de dados com segurança Fundamentos do processamento de dados seguros Damos muita importância para os dados, o que está correto, pois eles podem ser muito úteis para agregação de valor. Entretanto, até chegarmos à etapa de melhorar processos ou criar uma compreensão de existirem oportunidades a serem exploradas por meio da análise dos dados, precisamos processá-los. Atenção Além das preocupações com a implementação das regras de negócio e outros algoritmos que deem essas respostas, precisamos garantir que o processamento dos dados não afete a segurança do sistema. A segurança de um sistema também precisa levar em consideração o processamento dos dados de forma segura. Portanto, precisamos implementar processos e controles capazes de prevenir que os dados sejam acessados por pessoas sem o devido acesso. Se a segurança for violada, isso pode levar a roubo, modificação indevida ou divulgação não autorizada. Por isso, precisamos usar recursos lógicos e físicos que limitem o acesso aos dados. Práticas para processamento seguro dos dados Listamos, a seguir, algumas práticas que nos ajudam a processar dados com segurança: 1. Implementar controles de acesso ✓ São mecanismos de controle responsáveis por garantir que apenas pessoas autorizadas tenham acesso aos dados. Exemplos: uso de mecanismos de autenticação que obriguem os usuários a utilizarem senhas fortes, autenticação multifator ou de duas fases, e uso de biometria para acessar o sistema de processamento de dados. 2. Criptografar dados ✓ Caso uma pessoa sem autorização consiga acessar os dados, os mecanismos de criptografia vão protegê-los, pois não farão sentido para o atacante. ✓ Exemplo: os algoritmos simétricos e assimétricos empregados no processo de criptografia, como o AES (Advanced Encryption Standard) e RSA (Rivest-Shamir-Adleman). 3. Implementar práticas de codificação segura ✓ Utilizar mecanismos e estruturas de codificação conhecidos, capazes de garantir que o código seja escrito de maneira segura e, assim, o software poder processar os dados com segurança. Exemplos: validação de todas as entradas do usuário, limpeza dos dados, ou seja, procurar por conteúdo malicioso e removê-lo, e não executar entrada de dados sem passar por métodos que os critiquem. 4. Usar protocolos de comunicação seguros ✓ O exemplo mais clássico de protocolo de comunicação segura é o HTTPS, que protege os dados em trânsito na rede contra interceptação ou modificação, pois garante que os dados sejam criptografados e autenticados durante a transmissão. 5. Fazer buscas por vulnerabilidade e teste de penetração ✓ Quanto mais complexo for um sistema, maiores são as chances de que ele tenha vulnerabilidades. Por isso, é necessário ter uma rotina para tentar detectá-las e corrigi-las. Uma das formas de fazer isso é por meio do teste de penetração que força situações extremas e, assim, ajuda na identificação de possíveis vulnerabilidades. 6. Limitar o tempo de processamento ✓ Precisamos de uma métrica capaz de ajudar a estimar o tempo provável para que o programa processe os dados. Se o tempo consumido for muito diferente da média esperada, então, precisamos investigar o que aconteceu, pois é um sinal de alerta, de algo fora do normal. Desenvolvimento de Software Seguro Marcio Quirino - 25 Controles de acesso Uma das melhores formas para o processamento dos dados com segurança é garantir que apenas usuários legítimos possam acessá-los. Os controles de acesso são o instrumento responsável por garantir que apenas usuários autorizados possam realizar operações no sistema, tais como acessar os dados ou executar determinadas funções. Listamos alguns dos principais aspectos sobre os controles de acesso: 1. Criação de perfis ✓ Os usuários do sistema, por sua vez, serão associados a perfis com papéis de responsabilidade e que terão direitos e deveres. Dessa forma, facilitamos o processo de gerenciamento do controle de acesso. 2. Princípio do privilégio mínimo ✓ Os perfis de usuário devem ter acesso apenas a recursos e funções estritamente essenciais para que possa realizar suas funções. Caso o usuário precise de mais privilégios, então é necessário rever se ele está no perfil correto, ou, ainda, se devemos ampliar os privilégios do perfil em que está. Por meio do controle por perfis e do princípio do privilégio mínimo, podemos gerenciar melhor os comportamentos dos usuários do sistema e detectar anomalias com mais eficiência. 3. Separação de funções ✓ Os poderes que um perfil de usuário pode ter tornam-se menores quanto mais valiosos forem os dados que o sistema manipula. Nesse caso, a melhor solução é separar as operações sensíveis entre diferentes perfis de usuários, para evitar que um atacante – simulando um usuário legítimo – tenha controle total sobre uma função crítica. Obviamente, isso aumenta a quantidade de processos para realizar uma tarefa, por isso só deve ser aplicada se, realmente, for justificável. 4. Controle de acesso baseado em perfil ✓ O monitoramento e aplicação de políticas de controle de acesso baseadas em perfis de usuários do que em indivíduos é muito simples. A consequência direta desse tipo de controle é, no caso de invasão, mensurar os danos que podem ser causados no sistema e, assim, desenvolver contramedidas para prevenir que ocorram, ou, mesmo, para combater invasores. 5. Autenticação de dois fatores ✓ O controle semelhante aos usados para autenticar a entrada de dados no sistema também pode ser aplicado para verificar a identidade dos usuários que desejam ter acesso aos dados ou processá-los. Por exemplo, podemos usar uma estratégia na qual os usuários forneçam algo que eles conheçam, como uma senha, junto com algo que eles tenham, como um token físico ou um código único enviado para seu dispositivo móvel. 6. Monitoramento e auditoria ✓ O processo adotado novamente é semelhante ao que fazemos com o controle seguro de dados: geração de arquivos de logs. Por meio desses arquivos, podemos monitorar e, se for o caso, auditar o uso do sistema para garantirque tudo esteja funcionando conforme o esperado. Se houver alguma tentativa de acesso não autorizado, podemos investigar com mais cuidado e tomar medidas legais. 7. Políticas de senha segura ✓ O acesso por meio de senhas seguras é básico, mas fundamental. Exemplos dessas políticas incluem senhas fortes com combinação de letras minúsculas e maiúsculas e números, comprimento mínimo e máximo, uso de símbolos especiais, período de expiração de senha e impedimento de reutilização de senhas. Todos esses passos são importantes para o controle de acesso, mas dificultam a vida do usuário legítimo. Portanto, é importante que a implementação dessas técnicas e processos seja justificável e realizada com campanhas de conscientização. Desenvolvimento de Software Seguro Marcio Quirino - 26 Criptografia de dados Por mais cuidadosos que possamos ser, sempre existe a chance de um atacante encontrar formas de violar a segurança do sistema e ter acesso não autorizado aos dados. Isso pode ser desastroso, pois os dados podem ser modificados e, quando realizarmos o processamento deles, posteriormente, estaremos diante de resultados que não refletem a realidade e podem nos conduzir a tomadas de decisões erradas. Portanto, precisamos garantir que os dados só tenham valor para os usuários legítimos. Uma das técnicas mais eficientes para fazer isso é a criptografia. A criptografia é uma técnica fundamental para proteger a confidencialidade, integridade e autenticidade dos dados. Ela se baseia em algoritmos de transformação de dados com o uso de chaves. Então, apenas as pessoas com acesso a essas chaves conseguem acesso aos dados originais. No caso de um invasor acessar os dados criptografados ou tentar modificá-los, isso não trará nenhuma vantagem prática para ele. Saiba Mais A criptografia é um recurso que aumenta bastante a segurança dos dados de um sistema. Atualmente, é muito mais simples utilizá-la na prática, pois muitas ferramentas já a oferecem como recurso para garantir que nossos dados estejam protegidos e, assim, seja possível aumentar a resistência a ataques. Algoritmos de criptografia A seguir, apresentamos algumas questões importantes quando utilizar algoritmos de criptografia para aumentar a segurança de um software: 1. Conhecimento sobre os principais algoritmos de criptografia ✓ Devemos buscar o melhor algoritmo de criptografia para nossos dados, pois isso vai protegê- los contra acessos não autorizados. Alguns dos algoritmos de criptografia mais usados atualmente são AES (criptografia simétrica), RSA (criptografia assimétrica) e SHA (função hash). 2. Gerenciamento de chaves ✓ Precisamos de uma política bem definida sobre gerenciamento adequado de chaves que envolve geração, armazenamento e proteção das chaves usadas para criptografar e decriptografar os dados. O algoritmo de criptografia só é seguro se a chave de criptografia for mantida em segurança. 3. Implementação adequada ✓ Precisamos garantir que as chaves sejam geradas de modo aleatório, o processo de criptografia seja executado corretamente e os dados criptografados sejam armazenados em um ambiente seguro, já que, quem vai aplicar a criptografia é um sistema. 4. Integração com outros sistemas ✓ Podemos aumentar a eficácia do processo ao utilizar protocolos de segurança como TLS/SSL (Transport Layer Security — Camada Segura de Transporte/Secure Sockets Layer - Camada de Soquete Seguro), além dos algoritmos de criptografia em si, pois eles garantem que os dados sejam criptografados tanto em trânsito como em repouso. 5. Gerenciamento de certificados ✓ Devemos criar uma política explícita de gerenciamento para os certificados digitais, pois, atualmente, é difícil falar em segurança sem mencioná-los, já que são um recurso lógico usado para autenticar a identidade de usuários, servidores e outros dispositivos em uma rede e, por este motivo, como outros recursos de segurança, eles também precisam de uma política de gerenciamento para garantir que a comunicação seja segura. 6. Atualizações de segurança ✓ Precisamos atualizar os algoritmos de criptografia, da mesma forma que precisamos atualizar outros recursos de segurança. Para isso, devemos visitar regularmente o fornecedor do Desenvolvimento de Software Seguro Marcio Quirino - 27 algoritmo que estamos utilizando no sistema e realizar as atualizações sugeridas pela fonte oficial Protocolos de comunicação seguros Os protocolos de comunicação segura são especialmente fundamentais em ambientes cliente X servidor, tanto em intranets como na internet. Eles oferecem proteção contra as quebras de confidencialidade, integridade e autenticidade dos dados que transmitimos por uma rede. Existem algumas questões que precisamos considerar ao utilizar protocolos de comunicação seguros em um software: 1. Escolha do protocolo ✓ Devemos levar em consideração os requisitos de segurança para o contexto no qual a nossa aplicação vai trabalhar. Os protocolos de comunicação segura mais utilizados são o TLS e o SSL. 2. Configuração de parâmetros ✓ Temos que configurar diversos parâmetros, como o tamanho da chave de criptografia, considerando que esta é uma das etapas mais complexas no uso de protocolos seguros e uma das principais vulnerabilidades exploradas por invasores. 3. Gerenciamento de chaves ✓ Precisamos realizar a geração, armazenamento e proteção adequados das chaves usadas para criptografia e decriptografia. 4. Gerenciamento de certificados digitais ✓ Precisamos de um plano formal para fazer o gerenciamento, monitoramento, atualização e expiração dos certificados digitais para garantir uma comunicação segura, visto que eles são importantes para autenticar a identidade de usuários, servidores e outros dispositivos que estão na rede. 5. Monitoramento ✓ Precisamos monitorar o protocolo de comunicação seguro em qualquer etapa de um software seguro. Por exemplo, precisamos analisar possíveis violações ou vulnerabilidades de segurança. Fazemos isso por meio do monitoramento de tentativas de acesso não autorizado, padrões de tráfego incomuns ou quaisquer outras anomalias. 6. Atualizações ✓ Precisamos manter uma rotina de atualização por meio de consultas às fontes oficiais. Normalmente, os fornecedores disponibilizam patches de segurança - programas para corrigir vulnerabilidades. Desse modo, garantimos que estamos usando a versão mais segura do protocolo. Sem dúvidas, o uso de protocolos de comunicação segura é uma das questões que devemos levar em consideração para realizar o processamento de dados com segurança, pois é uma forma de proteger os dados e, assim, reduzir as chances de que nossa aplicação sofra ataques bem-sucedidos. Busca por vulnerabilidades e testes Para realizar um processamento de dados com segurança, sempre precisamos fazer uma busca por vulnerabilidades e realizar testes de segurança. Uma grande vantagem é que já existem passos bem conhecidos para tratar esse assunto. Listamos os principais: 1. Varredura de vulnerabilidade ✓ Precisamos usar ferramentas automatizadas para varrer o código do sistema e identificar possíveis vulnerabilidades. Como vimos, a OWASP apresenta diversas vulnerabilidades bem comuns, como injeção de SQL, script entre sites (XSS) e estouros de buffer. Desenvolvimento de Software Seguro Marcio Quirino - 28 2. Teste de penetração ✓ Devemos realizar testes manuais para identificar pontos fracos de segurança. Esses testes conseguem detectar vulnerabilidades que dificilmente seriam pegas por ferramentas automatizadas. Fazemos a simulação de ataques para identificar vulnerabilidades e determinar qual o impacto delas para segurança do sistema. 3. Bibliotecas e componentes de fornecedores confiáveis ✓ Temos, atualmente, acesso a diversas bibliotecas e componentes. Ao utilizarmos esses recursos, porém, podemos introduzir vulnerabilidades no nossosistema, pois é inviável fazermos testes neles. A forma de reduzir as chances de criarmos um problema é usar fontes confiáveis. No entanto, isso não garante que não existam vulnerabilidades nesses recursos. 4. Teste de conformidade ✓ Contamos com alguns padrões de testes de conformidade regulatória, como o padrão de segurança de dados do setor de cartões de pagamento (PCI DSS) e a lei de portabilidade e responsabilidade de seguros de saúde (HIPAA). Ambos os padrões são dos Estados Unidos, mas servem como guia para desenvolvermos nossos testes de conformidade de modo semelhante. 5. Teste contínuo ✓ Devemos lembrar que é importante ter uma rotina de implementação de testes automatizados e testes manuais para identificar possíveis vulnerabilidades, pois, assim, teremos a chance de aplicar correções antes que possam ser exploradas por invasores. 6. Avaliação de risco ✓ Devemos mapear todas as etapas do processamento dos dados e realizar avaliações de risco. Desse modo, podemos identificar possíveis riscos de segurança e priorizar vulnerabilidades com base no impacto potencial delas. 7. Documentação ✓ Precisamos ter em mente que, apesar de não ser bem priorizada, essa etapa é fundamental. Sempre que desenvolvermos e realizarmos os testes, devemos documentá-los, assim como seus resultados. Além disso, é essencial mantermos o registro das ações que tomamos para eliminar as vulnerabilidades e corrigir os erros, pois podem ser úteis para outras pessoas envolvidas no projeto. Todo o processo relacionado ao processamento de dados com segurança exige muito esforço da nossa parte. No entanto, como vimos, existem etapas bem definidas que podemos aplicar para reduzir o potencial de danos e detectar e corrigir vulnerabilidades, antes que elas sejam exploradas por invasores. 3. Chamadas em software seguro Fundamentos de Chamadas Nossa motivação para construir um software é que ele atenda a uma demanda, ou seja, realize ações úteis para seus usuários. Podemos ter softwares utilitários, como os aplicativos de banco, e softwares voltados para o entretenimento, como os jogos eletrônicos. Todos esses sistemas têm em comum uma arquitetura lógica que realiza comandos a partir da chamada de funções específicas. O uso de funções e medidas preventivas para chamadas seguras O uso de funções compõe as boas práticas de organizarmos um sistema, pois elas ficam responsáveis por partes específicas do processo lógico. No entanto, realizar essas chamadas de funções ou, ainda, chamar outros programas de dentro do nosso software, pode ser uma vulnerabilidade para a segurança do sistema. Por isso, apesar de essa prática ser muito útil, devemos tomar algumas medidas preventivas para evitar riscos de segurança. Uma forma bastante comum atualmente de trabalharmos com chamadas de funções é fazer via API (sigla para Interface de programação de aplicativos, do inglês Application Programming Interface). Ela Desenvolvimento de Software Seguro Marcio Quirino - 29 permite que possamos fazer a comunicação entre diferentes componentes de software, de modo que possam interagir entre si e, dessa forma, possibilita integrar nossos sistemas e consumir serviços. A seguir, apresentamos algumas medidas preventivas que nos ajudam a fazer chamadas seguras: 1. Validar as entradas do usuário ✓ Devemos ter certeza de que qualquer entrada do usuário passe por um processo de validação antes de ser processada. Uma função deve receber parâmetros, processá-los e retornar um resultado, especialmente se queremos evitar ataques de injeção de código. 2. Usar APIs do sistema ✓ Podemos nos prevenir de inserir vulnerabilidades no nosso sistema ao utilizarmos APIs e bibliotecas do sistema, pois, teoricamente, elas já foram testadas para evitar problemas de segurança. 3. Definir permissões ✓ Devemos definir as permissões necessárias que um programa deve ter para chamar uma determinada função e, assim, acessar os recursos do sistema. Isso é essencial. Para isso, é necessário garantir que a função faça uma leitura das credenciais de quem está fazendo a chamada, aumentando a complexidade de uma simples chamada. 4. Limitar privilégios ✓ Precisamos também limitar os privilégios da função que está sendo chamada, de modo que ela tenha acesso apenas aos recursos necessários para executar a tarefa. 5. Usar funções com as devidas autorizações ✓ Devemos cadastrar as funções em uma lista, logo após definirmos as permissões e limitar os privilégios de acesso aos recursos do sistema, para controlarmos quem pode realizar chamadas e executar comandos. 6. Monitorar as chamadas do sistema ✓ Precisamos sempre ter um recurso no sistema que gere arquivos de logs, para podermos monitorar as chamadas. Esse é o procedimento mais clássico. Por mais eficiente que seja nosso processo de segurança preventiva, às vezes, os invasores encontram alguma vulnerabilidade e passam a explorá-la. 7. Usar canais de comunicação seguros ✓ Precisamos garantir que a comunicação entre as duas máquinas seja criptografada e autenticada. Isso é especialmente importante quando o programa que está sendo chamado estiver sendo executado em uma máquina diferente. Chamadas de APIs do sistema Usamos as APIs para definir um conjunto de regras que servem para realizar a solicitação de dados, fazer o recebimento de dados, executar operações específicas e acessar determinados recursos de um sistema ou serviço de software. As APIs podem ser usadas para acessar dados de diversas fontes, como bancos de dados, serviços da web e outros aplicativos de software. Portanto, ao utilizá-las, devemos seguir algumas práticas recomendadas para garantir que nosso software seja o mais seguro possível. Listamos algumas sugestões de como proceder: 1. Usar chamadas de API bem documentadas e testadas ✓ Sempre devemos ter uma boa documentação da API e alguma garantia de que ela foi submetida a diversos testes, pois vai nos ajudar a garantir que nosso código permaneça estável, quando a utilizarmos. Desenvolvimento de Software Seguro Marcio Quirino - 30 2. Validar a entrada e a saída ✓ Precisamos validar tanto a entrada como a saída das chamadas da API, com os objetivos de evitar receber dados com códigos maliciosos e produzir uma saída maliciosa que comprometa a segurança do sistema. 3. Usar práticas de codificação seguras ✓ Precisamos considerar que são as mesmas práticas que vimos em outras situações, mas, agora, voltadas para o uso de APIs, como validação de entrada, codificação de saída e tratamento de erros para evitar vulnerabilidades como estouros de buffer e ataques de injeção. 4. Usar o princípio do privilégio mínimo ✓ Reduzimos as chances de os invasores obterem acesso a recursos confidenciais quando permitirmos que a API tenha acesso apenas aos recursos de que precisa para executar a tarefa específica. 5. Manter o software atualizado ✓ Devemos sempre utilizar as fontes oficiais para manter as APIs atualizadas, por exemplo, por meio de programas, como patches. 6. Usar ferramentas de segurança ✓ Devemos nos proteger utilizando ferramentas de segurança como softwares antivírus, firewalls e sistemas de detecção de intrusão, o que vai implicar, na prática, a adição de uma camada de segurança. 7. Realizar testes de estresse ✓ Precisamos compreender que este importante procedimento gera diversos cenários de situações que forçam a identificação das possíveis vulnerabilidades de segurança. Definição de permissões Quanto mais módulos um sistema tiver, maior será a complexidade para estabelecer quais permissões devemos conceder aos perfis de usuários. Esse processo, realmente, pode dar muito trabalho. Vamos considerar um módulo CRUD (inserir, visualizar, modificar e excluir dados), conforme vemos na imagem: Exemplo de um módulo de CRUD. De imediato, precisamos decidir se todos os perfis terão os mesmosacessos e permissões para realizar visualizações, cadastros, modificações e exclusões dos dados. Obviamente, essa tarefa vai exigir muito da nossa atenção e tem grandes chances de apresentar vulnerabilidades. Atenção O processo de definir permissões precisa ser realizado antes que o software seja entregue ao cliente, pois o papel do desenvolvedor é apenas de criar um ambiente no qual um responsável vai associar as permissões aos perfis dos usuários. Desenvolvimento de Software Seguro Marcio Quirino - 31 Diretrizes para a definição de permissões Existem algumas diretrizes que devemos seguir para definir permissões. Vamos conhecê-las! 1. Usar o princípio do privilégio mínimo ✓ Cada permissão deve dar acesso a uma ação específica necessária, exclusivamente, para realizar uma tarefa. 2. Restringir as permissões de arquivos e pastas ✓ Apenas perfis de usuários autorizados podem ter acesso aos arquivos e pastas. No caso de sistemas operacionais baseados em Unix, podemos usar o comando chmod para definir permissões em arquivos e diretórios. 3. Usar contas de usuário separadas ✓ Essa parte pode ser incômoda para o usuário, pois a ideia é que ele utilize uma conta separada para usar do servidor da Web e outra conta para acessar o banco de dados. Uma alternativa é usar um processo de autenticação baseado em certificado digital que garanta a autenticidade do usuário. 4. Usar senhas fortes ✓ Essa recomendação é clássica. Por outro lado, precisamos ter cuidado para não dificultar excessivamente a vida do usuário, pois, caso contrário, ele pode criar situações que gerem vulnerabilidades, por exemplo, anotar a senha e colocar sob o teclado. 5. Aplicar criptografia ✓ Para garantir a confidencialidade dos dados, precisamos usar criptografia. Isso vale tanto para os dados armazenados, quanto para os que estão em trânsito pela rede. 6. Verificar as permissões de forma regular ✓ É natural que haja rotatividade dentro de uma empresa. Às vezes, há mudanças de cargos ou profissionais dispensados. Portanto, sempre precisamos manter uma rotina de verificação capaz de nos ajudar a identificar possíveis problemas de segurança. 7. Realizar testes de estresse ✓ Devemos implementar testes automatizados que verifiquem se as definições de permissões estão, realmente, funcionando. O objetivo é criar situações estressantes para o sistema e estudar como ele se comporta, antes de enviá-lo para produção. Tipos de processamento e vulnerabilidades Vimos diversos controles para restringir os privilégios dos perfis dos usuários e de outros aplicativos, visando reduzir a possibilidade de um invasor assumir a identidade de um usuário ou aplicativo legítimo e causar danos durante o processamento de dados. Contudo, há mais algumas questões interessantes e pouco triviais para as quais precisamos ficar atentos e que são um diferencial em termos de conhecimento: os tipos de processamento e suas respectivas vulnerabilidades. A seguir, apresentamos os principais tipos de processamento de dados e analisamos as respectivas vulnerabilidades de cada um deles: 1. Processamento em lote ✓ Envolve o processamento de uma grande quantidade de dados de uma só vez. As vulnerabilidades do processamento em lote incluem a possibilidade de perda ou corrupção de dados durante a transferência, armazenamento ou processamento. Além disso, o processamento em lote pode ser vulnerável a violações de segurança se os dados não forem devidamente criptografados ou protegidos durante o armazenamento ou transmissão. 2. Processamento em tempo real ✓ O processamento de dados é realizado à medida que são gerados. Há diversas situações em que é muito útil, como controle de condições ambientais e monitoramento de segurança, por exemplo. Uma das vulnerabilidades desse tipo de processamento é em relação a problemas Desenvolvimento de Software Seguro Marcio Quirino - 32 de desempenho e perda de dados. Isso é especialmente crítico quando lidamos com aplicações de Big Data. 3. Processamento de fluxo ✓ É semelhante ao processamento em tempo real. A principal diferença é ele ser projetado para trabalhar com fluxos de dados contínuos, como transmissões de imagens e áudio ao vivo e dados de sensores. Assim como ocorre no processamento em tempo real, também é vulnerável a problemas de desempenho e isso, certamente, tem impacto na qualidade do dado processado. 4. Processamento em nuvem ✓ Tecnologia muito utilizada atualmente por diversos motivos, como custos racionais, flexibilidade e segurança. Basicamente, o processamento de dados ocorre na nuvem, utilizando a arquitetura da internet para realizar processamento em equipamentos de empresas especializadas nesse tipo de serviço. Uma das maiores vulnerabilidades ocorre em relação à dificuldade de configuração, pois, se não for feita cuidadosamente, pode ter diversos tipos de vulnerabilidade, como: violações de segurança, caso os dados não sejam criptografados durante o armazenamento ou transmissão; problemas de desempenho, se a infraestrutura de nuvem não for projetada adequadamente; e questões relacionadas à própria confiança no fornecedor do serviço. Mas, na prática, existem fornecedores muito confiáveis e maduros sobre essa tecnologia, como a Amazon, International Business Machines Corporation (IBM) e Microsoft. Mitigação das vulnerabilidades do processamento de dados Existem várias ações que podemos tomar para reduzir as vulnerabilidades associadas aos diferentes tipos de processamento de dados, tais como: • Usar criptografia; • Aplicar protocolos de segurança; • Implementar rotinas de backup de dados; • Desenvolver e implementar uma política de recuperação de desastres. Além disso, no caso de aplicações de Big Data, precisamos usar tecnologias e técnicas que nos permitam lidar com grandes volumes de dados e sejam escaláveis para atender às demandas futuras. Porém, a ação mais importante de todas é investir na capacitação dos colaboradores e conscientização dos usuários. Monitoramento das chamadas Depois de estudarmos os diversos tipos de controles necessários para ter um processamento seguro e como esses processamentos podem ocorrer, precisamos monitorar como as chamadas são feitas. A seguir, apresentamos algumas ações que podem auxiliar na viabilização desse processo: 1. Identificar chamadas de API críticas ✓ Esse papel está mais associado ao responsável pela arquitetura do software, pois ele pode fazer o mapeamento das chamadas de API e estabelecer níveis de criticidade relacionados à segurança. Alguns exemplos de critérios que podemos usar para estabelecer o nível de criticidade da chamada de uma API é se ela trabalha com dados ou recursos confidenciais. 2. Implementar registro de chamadas ✓ Precisamos desenvolver uma forma para registrar informações sobre a chamada que traga informações como a hora da chamada, qual usuário fez a chamada e quais os parâmetros passados para a chamada. 3. Monitorar logs ✓ Sempre devemos ter uma ferramenta que registre as chamadas em arquivos de logs e um processo que nos ajude a procurar por padrões que indiquem atividades maliciosas. São Desenvolvimento de Software Seguro Marcio Quirino - 33 exemplos desse tipo de chamada chamadas repetidas diversas vezes com os mesmos parâmetros em intervalos muito curtos e chamadas fora dos padrões de uso normais. 4. Definir alertas ✓ Precisamos estabelecer alertas que nos notifiquem sempre que houver uma atividade suspeita. Esse é um dos motivos para mantermos arquivos de logs. 5. Revisar os logs regularmente ✓ O ideal seria detectarmos uma situação de tentativa de ataque e, rapidamente, atuar para evitar que ela fosse bem-sucedida. No entanto, há situações mais complexas que só podem ser detectadas depois de muita análise. Por isso, precisamos ter uma política bem definida de revisão dos arquivos de logs na qual existamprocedimentos e responsáveis para realizar esse tipo de tarefa. 6. Usar ferramentas automatizadas ✓ A ideia é acelerar o processo de análise para tentar identificar padrões e detectar atividades suspeitas com mais eficiência do que a análise manual. 7. Realizar testes ✓ Regularmente, precisamos estressar o sistema por meio da simulação de chamadas maliciosas e verificar como ele se comporta. Esse tipo de teste pode nos dar informações úteis para que possamos atuar de forma preventiva. 4. Envio da saída Fundamentos da saída Todas as etapas são importantes para garantir a segurança. Contudo, a saída merece uma atenção especial, pois pode expor dados confidenciais, favorecer potenciais invasores com informações que eles podem usar para explorar vulnerabilidades em seu software e, ainda, é possível gerar uma saída que seja um problema para outros sistemas, ou prejudicar o suporte à tomada de decisão em vez de ajudar. Devemos estar atentos a alguns procedimentos sobre o envio da saída para aumentar as chances de que o software seja seguro, tais como: 1. Usar criptografia ✓ A saída deve ser criptografada. Dessa forma, se um invasor conseguir interceptá-la, não vai conseguir compreendê-la. 2. Validar a entrada ✓ Como um invasor pode tentar injetar um código para ser executado por nosso programa, precisamos fazer a validação de todas as entradas usadas para gerar a saída. 3. Limpar a saída ✓ Precisamos garantir que a saída contenha apenas as informações estritamente essenciais para quem vai consumi-la. Portanto, devemos remover qualquer informação confidencial que não seja, de fato, essencial. 4. Usar protocolos de comunicação seguros ✓ Precisamos trabalhar com protocolos de comunicação seguros, como o HTTPS, para fazer a comunicação dos dados. Nesse caso, o envio à saída do nosso sistema, com o objetivo de evitar que invasores em potencial interceptem os dados em trânsito. 5. Limitar a saída para usuários autorizados ✓ Precisamos usar ferramentas e outros recursos que permitam que apenas usuários com a devida autorização consigam ler os dados. Por exemplo, podemos usar uma ferramenta que exija a autenticidade do usuário para exibir os dados da saída com o processo inverso da criptografia. Desenvolvimento de Software Seguro Marcio Quirino - 34 6. Usar registros ✓ Devemos registrar todas as saídas do sistema e também informações sobre quem as acessou. Obviamente, o interesse é identificar qualquer atividade suspeita. 7. Realizar testes ✓ Devemos sempre realizar testes para qualquer tratamento de dados, inclusive com a saída. Ao simular situações de ataque com ferramentas de teste automatizadas, temos a possibilidade de identificar quaisquer problemas antes que eles entrem em produção. Uso da criptografia O uso de algoritmos de criptografia é essencial para garantimos que os resultados façam sentido apenas para os usuários autorizados. Algumas das ações para enviar dados seguros são: 1. Usar algoritmos de criptografia fortes ✓ Existem vários algoritmos de criptografia bons, como Advanced Encryption Standard (AES) e Triple Data Encryption Standard (Triple DES). 2. Usar o gerenciamento seguro de chaves ✓ A criptografia só tem utilidade prática se conseguirmos fazer um gerenciamento eficiente das chaves usadas para criptografar e decriptografar os dados. Essas chaves só podem ser acessíveis por usuários autorizados e que possam ter suas ações no sistema rastreáveis. 3. Aplicar protocolos de comunicação seguros ✓ Especialmente, no caso em que os dados da saída serão transmitidos via rede, é fundamental usarmos protocolos de comunicação seguros, como SSL/TLS. 4. Autenticar o remetente e o destinatário ✓ Esse mecanismo de autenticação garante que tanto o remetente quanto o destinatário dos dados estejam autorizados a acessar os dados. 5. Verificar os dados de saída ✓ Antes de criptografar os dados, precisamos garantir que os resultados só contenham informações essenciais para quem vai utilizá-las. 6. Testar a criptografia ✓ Nesse caso, precisamos de ferramentas específicas para automatizar esse processo. O objetivo do teste é garantir que o sistema de criptografia da saída esteja funcionando conforme o esperado. Protocolos de comunicação seguros Protocolos de comunicação segura são especialmente essenciais quando fazemos transmissão de dados confidenciais pela internet ou mesmo pela rede interna – raramente sabemos onde está o invasor. A seguir, listamos alguns dos principais protocolos de comunicação segura: 1. Transport Layer Security (TLS)/Secure Sockets Layer (SSL) ✓ São usados com frequência para proteger o tráfego de dados da web junto com o protocolo HTTPS. O objetivo básico é proteger os dados transmitidos pela internet por meio do uso de algoritmos de criptografia para garantir que não sejam interceptados ou sofram algum tipo de adulteração. 2. Secure File Transfer Protocol (SFTP) ✓ É outro protocolo seguro que tem como objetivo proteger dados de arquivos transferidos pela internet. Semelhante aos demais protocolos, ele usa criptografia para proteger os dados em trânsito. Além disso, utiliza recursos como autenticação de chave pública para garantir acesso seguro aos dados. 3. Internet Protocol Security (IPSec) ✓ É um conjunto de protocolos que serve para proteger comunicações de protocolo de internet (IP) por meio da autenticação e criptografia de cada pacote IP. Especialmente depois da Desenvolvimento de Software Seguro Marcio Quirino - 35 pandemia de covid-19, em que o trabalho virtual se tornou mais comum, esse protocolo ganhou grande popularidade por proteger redes privadas virtuais (VPNs). 4. Simple Mail Transfer Protocol Secure (SMTPS) ✓ É uma extensão segura do protocolo Simple Mail Transfer Protocol (SMTP) que é usado para enviar e-mail. Ou seja, usa técnicas de criptografia para proteger o e-mail em trânsito e, claro, proteger os dados contra a interceptação e adulteração. 5. Secure Shell (SSH) ✓ É um protocolo usado para acesso remoto seguro a servidores e outros dispositivos. O SSH faz a autenticação e criptografia seguras para acesso remoto. Portanto, o utilizamos para impedir o acesso não autorizado a dados confidenciais. 6. Virtual Private Network (VPN) ✓ É uma tecnologia usada para criar uma conexão segura e criptografada entre dois dispositivos – computadores ou servidores – pela internet. Junto com IPSec, o utilizamos para proteger os dados transmitidos entre locais remotos e impedir o acesso não autorizado a dados confidenciais. Restrição da saída para usuários autorizados Há muitos dados circulando pela rede que, se caírem nas mãos erradas, podem gerar enormes prejuízos financeiros e de imagem. Portanto, é fundamental utilizarmos mecanismos que restrinjam a saída apenas a usuários autorizados, para proteger dados confidenciais da saída do nosso sistema seguro. Apresentamos, a seguir, algumas sugestões que auxiliam no processo de restringir a saída apenas a usuários autorizados: 1. Implementar controles de acesso ✓ Sempre devemos usar mecanismos de controles de acesso para restringir o acesso a dados confidenciais apenas a usuários autorizados, como o uso de ferramentas que exijam autenticação de usuário e façam o controle de autorização com base no perfil de quem está acessando a saída. 2. Criptografar dados confidenciais ✓ A criptografia garante que os dados só façam sentido para quem tem acesso à chave de criptografia. Isso, obviamente, é feito por meio de ferramentas que precisam de um gerenciamento explícito. Utilizar criptografia é muito seguro. Mesmo que um invasor tenha acesso aos dados e os modifique, o receptor vai saber que os dados estão corrompidos. Além disso, os dados roubados não farão nenhum sentido para o invasor. 3. Use protocolos de comunicação seguros ✓ Existem diversos protocolos de comunicação seguros para transmitirdados pela rede - seja internet ou intranet - e garantir a sua integridade. 4. Limpar saída ✓ As informações geradas por um sistema só devem fazer sentido para usuários com perfis autorizados. Portanto, é nossa obrigação ficar atento ao que pode ser exposto para cada perfil de usuário. Precisamos fazer isso antes de criptografar os dados, pois a construção lógica do que será enviado para saída é de responsabilidade do nosso sistema. 5. Monitorar a saída ✓ Semelhante ao que fizemos nas demais etapas do ciclo de vida dos dados de um software seguro, também precisamos ter uma rotina de monitoramento bem estabelecida que permita analisarmos o uso da saída do sistema e, se for o caso, detectar qualquer atividade suspeita. Esse processo precisa do apoio de ferramentas específicas e de responsáveis para fazer o acompanhamento de quem está acessando os dados de saída. 6. Realizar testes de estresse ✓ O objetivo é encontrar vulnerabilidade nos nossos controles de acesso, além de garantir que todo o controle de segurança esteja funcionando conforme o esperado. Desenvolvimento de Software Seguro Marcio Quirino - 36 Esses controles não têm implementação trivial, mas aumentam nossas chances de construir softwares seguros. É muito mais racional investir em ações preventivas do que atuar em medidas corretivas para tentar reduzir danos causados por um ataque bem-sucedido. Monitoramento da saída e realização de testes Estamos, finalmente, na última etapa para a construção de um software seguro! Nosso foco está no envio seguro da saída. Assim como temos preocupações em receber dados com códigos maliciosos de outros sistemas, também precisamos ter muita atenção para não gerarmos dados que causem danos à segurança. Por isso, a segurança de software deve ser vista como um conjunto de partes que se combinam para reduzir as chances de ataques bem-sucedidos. Uma forma eficiente de complementar as ações para fazer o envio de uma saída segura é por meio do monitoramento dos usuários que estão usando o sistema. Obviamente, esse tipo de ação, junto com outras que já analisamos, precisa ser justificável. Por exemplo, grandes corporações privadas não têm interesse de que outras empresas conheçam suas estratégias de investimento. Da mesma forma, os setores de inteligência dos governos também não querem que seus adversários – e, às vezes, até aliados – conheçam seus planos militares. Portanto, a definição de processos de monitoramento da saída e ações para identificar problemas são etapas críticas para garantir a segurança de sistemas. Essa é uma área muito dinâmica, exigindo que nos atualizemos constantemente, principalmente, por causa do avanço das técnicas de inteligência artificial, que podem ser utilizadas tanto para combater invasões, como para tentar realizá-las. Etapas da monitoração da saída A seguir, listamos algumas etapas que podemos seguir para monitorar a saída e testar problemas de software seguro: 1. Estabelecer planos de testes de segurança ✓ Estabelecer um plano de teste de segurança, descrevendo metas, metodologias, ferramentas, frequência de teste e responsáveis. 2. Identificar possíveis ameaças à segurança ✓ Desenvolver o pensamento de um invasor para podermos criar possíveis cenários de ameaças e identificar vulnerabilidades que nosso sistema pode enfrentar. 3. Desenvolver e executar testes de segurança ✓ Existem muitos testes que podemos aplicar para verificar, se, de fato, o envio da saída é seguro. Por exemplo, podemos usar ferramentas automatizadas para realizar: ✓ Análise estática: faz a análise do código do sistema. ✓ Análise dinâmica: realiza testes com o sistema em funcionamento. ✓ Teste de penetração: estressa o sistema por meio de busca de vulnerabilidades de segurança bem conhecidas. 4. Gerar e monitorar os logs do sistema ✓ Só podemos analisar dados se eles existirem. Portanto, é essencial utilizarmos recursos que permitam gerar arquivos de logs do sistema, ao mesmo tempo que precisamos implementar rotinas para detectar atividades suspeitas, como muitas tentativas de login com falha. 5. Usar técnicas de detecção de anomalias ✓ Atualmente, temos ferramentas que utilizam algoritmos de aprendizado de máquina para detectar padrões incomuns tanto no comportamento do usuário, como nas atividades do sistema. 6. Realizar revisões de código ✓ Sempre é importante fazer revisões do código para tentar identificar e corrigir vulnerabilidades de segurança. Desenvolvimento de Software Seguro Marcio Quirino - 37 7. Manter o software atualizado ✓ Em sistemas complexos, é normal utilizarmos muitos componentes, bibliotecas e outras tecnologias fornecidas por terceiros. Por isso, precisamos mapeá-las e, com regularidade, visitar os sites dos fornecedores oficiais e realizar as atualizações recomendadas. 5. Conclusão Considerações finais Estudamos diversas questões relacionadas à construção de um software seguro. Tratamos sobre itens importantes, que vão desde a validação da entrada de dados, como o processamento, chamada de outros programas, até o envio da saída de forma segura. Apesar de serem etapas diferentes, o tratamento geral que precisamos dar a cada uma delas em muitos momentos se assemelham: controle de acesso, monitoramento e aplicação de algoritmos de criptografia. Na prática, no entanto, cada uma dessas etapas demanda um tratamento especial. Por exemplo, certamente, nossa preocupação da validação de uma entrada é diferente da validação de uma saída, pois, nesse último caso, os dados já passaram por todas as fases anteriores de controle. Portanto, é muito mais difícil detectarmos uma vulnerabilidade na saída do que na entrada de dados. Isso torna o trabalho ainda mais desafiador. Por isso, precisamos estar constantemente nos atualizando e estudando as formas de agregar mais segurança aos nossos softwares! Explore + Para complementar as discussões trazidas neste conteúdo, acesse o site oficial da Microsoft e procure por: Lei de Portabilidade e Responsabilidade do Seguro de Saúde (HIPAA) & Tecnologia de Informações de Saúde para a HiTECH (Economic and Clinical Health Health) Act. Nessa página, você conhecerá melhor esses padrões de segurança e, certamente, vai ampliar a sua visão sobre software seguro. Usar o PyLint para verificar o código do Python. Lá, você aprende sobre a ferramenta PyLint, que é utilizada na prática para fazer análises estáticas de código no Python que, atualmente, é uma das principais linguagens de programação. Referências CHESS, B.; WEST, J. Secure Programming with Static Analysis. Boston: Addison-Wesley, 2007. HOWARD, M.; LEBLANC, D. Writing Secure Code. 2. ed. Microsoft Press, 2002. MCGRAW, G. Software Security: Building Security In. Nova York: Pearson Education Inc., 2006. PRESSMAN, R. S. Engenharia de Software. 6. ed. São Paulo: MacGraw-Hill, 2006. SOMMERVILLE, I. Engenharia de Software. 6. ed. São Paulo: Pearson Addison Wesley, 2005. VIEGA, J.; MCGRAW, G. Building Secure Software: How to Avoid Security Problems the Right Way. Boston: Addison-Wesley, 2002. Desenvolvimento de Software Seguro Marcio Quirino - 38 Modelagem, Implantação e Verificação de Software seguro Introdução A segurança de software é uma área relevante na tecnologia da informação, pois é responsável por dar garantias mínimas de proteção de dados e disponibilidade de sistemas contra ameaças de ataques cibernéticos. A mentalidade de segurança deve permear o ciclo de vida completo de desenvolvimento de software seguro, introduzindo medidas protetivas específicas para cada fase. Boas práticas, padronizadas por processos estruturados, devem ser empregadas para gestão de risco e modelagem de ameaças. Diversas organizações propõem arcabouços estruturados para cobrir essas questões práticas de desenvolvimento de software seguro, sendo excelentes fontes de consulta para todoprofissional envolvido com a área. 1. Verificação de segurança A importância do software seguro Você já viu um exploit em ação? Parece mágica a forma como um pedaço de código é executado rapidamente e toma o acesso de uma máquina que roda um programa complexo, escrito por uma equipe de especialistas e vendido e usado no mundo todo já por alguns anos. O processo pode parecer algum tipo de magia computacional, tendo como ingredientes uma grande confusão de bits e bytes. Mas quando você der uma olhada no que acontece por debaixo dos panos e perceber como, de fato, funciona, certamente, simpatizará com o criador do código, que teve muita persistência para testar ações (algumas delas bem inusitadas) até encontrar um caminho capaz de furar o uso normal do sistema, ultrapassar os mecanismos de controle e tomar conta da máquina. O cenário apresentado aqui é muito factível, por exemplo, em um caso de ataque do tipo buffer overflow, que ocorre quando um programa tenta armazenar mais dados em uma área de armazenamento temporário na memória (buffer) do que ele pode suportar, o que faz com que o excesso de dados “transborde” e seja armazenado em outras áreas da memória. Isso pode permitir que um invasor execute um código malicioso ou manipule o programa de maneiras favoráveis a, potencialmente, tomar o controle total do sistema. Se você conhece um pouco de software, sabe que todos eles possuem bugs. Todo software, em algum momento após seu lançamento, vai apresentar uma falha, mau funcionamento diante do inesperado (uma ação executada pelo usuário nunca imaginada pelos programadores do sistema) ou até mesmo frente ao esperado. As possibilidades de buracos existentes em um sistema complexo são inúmeras! Seja por descuido ou desconhecimento, os programadores constroem sistemas com falhas, isso é um fato. Quanto maior e mais complexo o software, mais provável a existência de falhas que abram brechas a serem exploradas. No contexto da segurança de software, alguns conceitos são de extrema importância, como a terminologia de base para compreensão de aspectos práticos. Vamos a alguns desses conceitos! Vulnerabilidades Em termos simples, são os pontos fracos de um sistema, os quais os invasores podem aproveitar a seu favor. Uma vulnerabilidade é uma falha específica gerada por desconhecimento ou descuido em um software, que possibilita que um invasor faça algo mal-intencionado; exponha ou altere informações Desenvolvimento de Software Seguro Marcio Quirino - 39 confidenciais; interrompa ou destrua o funcionamento do sistema; ou assuma o controle de um sistema ou programa de computador. Sem dúvida, você deve estar familiarizado com bugs de software. São erros, enganos ou descuidos em programas que resultam em comportamento inesperado e tipicamente indesejável. Quase todo usuário de computador, em algum momento, já perdeu um trabalho importante por causa de um bug de software. Nem todo bug cria vulnerabilidades, ou seja, em geral, as vulnerabilidades de software podem ser consideradas um subconjunto do fenômeno maior de bugs de software. Entenda melhor: Relação entre bugs e vulnerabilidades. Vulnerabilidades de segurança são aqueles bugs ou, genericamente, falhas que trazem uma brecha para que um usuário mal-intencionado possa se aproveitar para lançar ataques contra o software e os sistemas de suporte. Todas as vulnerabilidades de segurança advêm de bugs de software, mas apenas alguns bugs de software acabam se configurando em vulnerabilidades de segurança. Uma falha deve proporcionar algum impacto ou liberar propriedades relevantes à segurança para ser realmente considerada um problema. Em outras palavras, a falha deve permitir que os invasores façam algo que, por meio de comportamento comumente esperado no uso do sistema, não seriam capazes de fazer. Façamos um paralelo com dois termos de mais fácil compreensão: • Segurança • Confiabilidade Tudo aquilo que é sabidamente seguro é automaticamente confiável, mas nem tudo que é confiável é necessariamente seguro. Usando isso como uma comparação útil, digamos que um programa confiável é aquele que está relativamente livre de bugs. Isso significa que o software raramente falha nas mãos do usuário, lidando inclusive com as condições excepcionais normalmente. Se o programa foi escrito de forma a ser capaz de lidar com ambientes de execução incertos e entradas malformadas, podemos dizer que ele foi construído de maneira “defensiva”, e este deve ser um objetivo de todo programador. O programa deve ser capaz de se antecipar a algumas das falhas conhecidas e poder repelir um ataque direcionado por intrusos que estejam tentando manipular seu ambiente, introduzindo entradas para aproveitar alguma falhar e alcançar algum fim nefasto. Confiabilidade e segurança de software não são a mesma coisa, mas compartilham objetivos semelhantes, pois ambos exigem estratégias de desenvolvimento que se concentram no extermínio de bugs de software. Veja o que diferencia esses dois tipos de software! Desenvolvimento de Software Seguro Marcio Quirino - 40 A. Software confiável ✓ É aquele com baixa probabilidade de apresentar mau funcionamento ou falhas inesperadas. Isso inclui a garantia de que o software foi desenvolvido de acordo com padrões de qualidade, foi testado e validado de forma adequada, e pode ser confiável em termos de desempenho, disponibilidade e eficácia acerca dos objetivos para os quais foi projetado e construído. B. Software seguro ✓ É aquele que foi projetado e implementado com o objetivo de proteger o sistema de ataques e vulnerabilidades. Isso inclui a aplicação de técnicas de programação seguras, o uso de criptografia para proteger dados sensíveis, a implementação de controles de acesso para limitar o acesso a informações confidenciais, e outras medidas para reduzir os riscos de ataques e comprometimento do sistema. Lembrando do caso do ataque de buffer overflow, o programador com mentalidade defensiva, para evitar esse tipo de ataque, deve usar técnicas de programação seguras, como verificar o tamanho dos dados armazenados em um buffer e garantir que ele esteja adequadamente dimensionado. Explorando vulnerabilidades nos softwares A exploração de uma vulnerabilidade é realizada na prática por meio de um exploit, que é um software no qual o código tem a função de se aproveitar de uma falha existente dentro de um sistema, uma aplicação ou um serviço. Esse software, normalmente caracterizado por um pedaço de código, pode ser escrito em várias linguagens. Vejamos os tipos de linguagens utilizadas: • Python • C • C++ • Assembly O exploit carrega uma parte do código conhecida como payload. Em segurança de software, um payload (carga útil) refere-se a um código malicioso que é inserido em um sistema vulnerável para executar determinada ação. Essa ação pode ser de diversos tipos e depende do objetivo do invasor. Vamos conferir os tipos de ações que podem ser executadas! 1. O roubo de informações. 2. Os danos ao sistema. 3. A instalação de outros softwares maliciosos. 4. O controle remoto do sistema. No contexto do uso de exploits, um payload geralmente é usado em conjunto com uma técnica de injeção de código para permitir que o atacante execute comandos no sistema comprometido. Isso pode ser feito, por exemplo, enviando um arquivo de exploit especialmente criado para o sistema alvo. Quando o exploit é executado com sucesso, o payload é então inserido no sistema e executado para realizar a ação maliciosa desejada. Outro conceito relacionado com a prática da exploração de vulnerabilidades é o Shellcode, um conjunto de instruções e comandos criados para serem executados assim que o código é injetado. Deve ser encarado como um tipo específico de payload que é projetado para executar um shell (interface de linha de comando) no sistema comprometido. É geralmente escritoem linguagem Assembly e executado diretamente na memória do sistema comprometido. Resumindo O objetivo principal do shellcode é permitir que o invasor execute comandos no sistema comprometido, obtendo controle total sobre ele. Desenvolvimento de Software Seguro Marcio Quirino - 41 Relação entre vulnerabilidade, ameaça e risco Em termos teóricos, a avaliação de segurança de software é feita tomando por base uma análise de risco e o custo e retorno de cada uma das estratégias voltadas para lidar com cada risco. Então, precisamos apresentar os conceitos de ameaça e risco, que irão compor a avaliação de segurança. Começando pela ameaça, é a situação que expõe o sistema a um evento ou a uma ação que pode explorar uma vulnerabilidade existente no software. As ameaças podem ser realizadas por pessoas mal- intencionadas, como hackers, ou por eventos não intencionais do próprio usuário comum. As ameaças podem explorar as vulnerabilidades para causar danos ao sistema, roubar dados ou informações, ou realizar outros tipos de ataques advindos de atividades maliciosas, bem como simplesmente expor dados ou travar um sistema, no caso de um evento não associado a más intenções. É importante reconhecer que a ameaça existe no encontro da vulnerabilidade com a exploração, ou seja, só existe realmente a ameaça quando existe uma vulnerabilidade que pode ser explorada. Observe o esquema: Vulnerabilidade x Ameaça. É possível que exista uma vulnerabilidade em um software e que ela não represente uma ameaça real. Isso pode ocorrer por vários motivos, como: ✓ A vulnerabilidade requer acesso a recursos ou privilégios que não estão disponíveis para um invasor em potencial, ao menos pelos métodos mapeados na avaliação de segurança. ✓ A vulnerabilidade é difícil ou impossível de explorar na prática, também na visão dos métodos mapeados, que deve considerar o estado da arte das técnicas de exploração. Um exemplo prático seria uma vulnerabilidade em um software que requer acesso administrativo ao sistema para ser explorada. Nesse caso a ameaça é dependente da existência de ameaça do acesso administrativo. Se o sistema estiver configurado corretamente e o acesso administrativo for restrito a usuários confiáveis, a vulnerabilidade pode não representar uma ameaça real. Resumindo Não há ameaça real se as condições necessárias para sua exploração da vulnerabilidade não são atendidas. Portanto, é importante avaliar não apenas a existência de vulnerabilidades em um sistema, mas também as condições necessárias para sua exploração e o nível de risco associado a elas. Enfim chegamos ao conceito de risco, que é a probabilidade de uma ameaça explorar uma vulnerabilidade para causar danos ao sistema. O risco deve ser calculado como um produto da probabilidade de uma ameaça ocorrer pelo tamanho do impacto que essa ameaça pode causar. Portanto, quanto maior a probabilidade de uma ameaça ocorrer e maior o impacto que essa ameaça pode causar, maior será o risco associado. Isso pode ser visualizado através de uma ferramenta conhecida como matriz de riscos. Confira: Desenvolvimento de Software Seguro Marcio Quirino - 42 Matriz de riscos. Consolidando, vulnerabilidade é uma fraqueza no software, ameaça é a exploração dessa vulnerabilidade por uma ação ou evento e risco é a probabilidade de uma ameaça ocorrer e impactar o sistema. O gerenciamento de risco é importante na segurança de software para garantir a proteção do sistema contra ameaças conhecidas e desconhecidas. Framework de avaliação A verificação de segurança de software envolve executar ações para avaliar e gerir riscos, sempre considerando as possíveis expectativas que os usuários têm, ou seja, respondendo o que seria considerado uma violação de segurança. Nem toda falha causa impactos na segurança, que é frequentemente descrita com base em três componentes, que podem ser descritos da seguinte forma: A. Confidencialidade ✓ É a capacidade de que a informação se mantenha privada apenas a quem detém direito de acessá-la. B. Integridade ✓ É a capacidade de que a informação seja confiável e esteja correta. C. Disponibilidade ✓ É capacidade de que a informação esteja disponível no momento oportuno. Considerando os três pilares que suportam as expectativas relacionadas à segurança de um sistema, podemos definir a avaliação de risco de segurança conforme as ações de: identificar, avaliar e implementar os principais controles de segurança no software, com enfoque também na prevenção de defeitos e vulnerabilidades. Se a verificação de segurança executa tais ações corretivas e preventivas, perpassando todo o ciclo de vida do software, desde o design até o final do suporte, podemos organizar, de forma enxuta, a gestão de riscos em quatro etapas, com respectivas demandas de atividade. Gestão de risco Envolve um processo estruturado para identificar, avaliar e mitigar os riscos em uma organização. Vejamos algumas etapas comuns envolvidas no processo de gestão de riscos! Desenvolvimento de Software Seguro Marcio Quirino - 43 A. Identificação ✓ Etapa em que se deve levantar todos os ativos críticos da infraestrutura de tecnologia e então elencar as informações confidenciais criadas, armazenadas ou transmitidas por esses ativos. Para cada ativo, deve ser criado um perfil de risco. B. Avaliação ✓ Etapa em que se deve abordar os riscos de segurança identificados para cada um dos ativos críticos, avaliando-os. A avaliação deve analisar as relações entre ativos, cruzando ameaças e vulnerabilidades, e estabelecendo controles atenuantes. Após a avaliação, é necessário determinar como alocar tempo e recursos de maneira eficaz e eficiente para tratar os riscos. C. Tratamento ✓ Etapa em que é preciso definir uma abordagem de correção ou mitigação, aplicando efetivamente os controles de segurança para cada risco encontrado nos respectivos ativos. Os riscos que estiverem dentro de níveis aceitáveis podem ser aceitos, o que significa simplesmente deixá-los de lado. Outra abordagem é delegar a responsabilidade de terceiros, por vezes contratando um serviço, ou se preparar para os impactos apenas fazendo um seguro, por exemplo. D. Prevenção ✓ Etapa em que se deve implementar ferramentas e processos para minimizar a ocorrência de vulnerabilidades e a consequente existência de ameaças aos ativos. A gestão de risco permite que uma organização visualize o portfólio de aplicativos de forma holística pelo ponto de vista de um invasor. Métodos de verificação de software Com foco na verificação de segurança, vamos “explodir” a etapa de avaliação da gestão de risco, pois é justamente sobre ela que recai a parte mais “mão na massa”, na qual os bits e bytes são vistos de perto, ou como dizemos no jargão da TI, “escovados”, a partir de alguns métodos. Vamos conferi-los! Auditoria de software É o processo de análise de código (no formato fonte ou binário) para descobrir vulnerabilidades que possam ser exploradas por invasores. Com esse processo de análise sendo feita por time amigo, é possível identificar e fechar brechas de segurança, que, de outra forma, colocariam dados confidenciais e recursos de negócios em risco desnecessário. Time amigo Refere-se a um grupo de profissionais de segurança da informação, especialistas em auditoria de software, que são contratados pela própria empresa ou organização que desenvolveu o software a ser auditado. Esse time é considerado “amigo" porque trabalha em colaboração com a equipe de desenvolvimento do software, com o objetivo comum de identificar e corrigir quaisquer vulnerabilidades ou brechas de segurança presentes no código. Ao contrário de uma auditoria externa, em que um grupo de especialistas externos é contratado para testar a segurança do software, a auditoria realizada pelo time amigo permite maior transparência e cooperação entre equipes de segurançae desenvolvimento, facilitando a correção imediata das vulnerabilidades descobertas. Dessa forma, o time amigo é visto como um aliado no processo de garantir a segurança do software e proteger os dados confidenciais e recursos de negócios da empresa ou organização. Teste de caixa preta É um método de avaliação de um sistema de software manipulando apenas suas interfaces expostas. Normalmente, esse processo envolve a geração de entradas especialmente criadas que provavelmente farão com que o aplicativo execute algum comportamento inesperado, como falha ou exposição de dados confidenciais. Desenvolvimento de Software Seguro Marcio Quirino - 44 Teste da caixa preta. O teste de caixa preta é tão somente injetar dados em uma aplicação e esperar que ocorra um comportamento inesperado. Não é possível saber exatamente o que o software está fazendo com os dados, portanto, podem existir centenas de caminhos de código que não serão explorados porque os dados injetados não acionam esses caminhos. Porém, por mais espantoso que possa parecer, muitas vulnerabilidades são encontradas por hackers testando o que acontece se lançar dados estranhos ao comportamento esperado como entrada. Felizmente, a auditoria de código pode ser combinada com o teste de caixa preta para maximizar a descoberta de vulnerabilidades em um período mínimo. 2. Modelagem de Ameaças Definição dos objetivos Modelar ameaças é uma forma de usar a identificação de vulnerabilidades para priorizar contramedidas. Vejamos uma modelagem de ameaças em cinco etapas: Modelagem de ameaças. Na primeira etapa, definir objetivos, devemos identificar os objetivos de segurança, definindo-os em estrito acordo com os requisitos. É uma etapa crítica no processo de modelagem de ameaças de segurança de software, pois envolve levantar os ativos que precisam de proteção, elencando as possíveis ameaças que podem prejudicá-los, ou seja, qualquer inobservância a algum ativo pode ter efeito dramático para os resultados. A partir desse mapa, muito similar ao perfil de risco da primeira etapa da gestão de riscos e, tomando por base os requisitos de segurança estipulados, definem-se formalmente os objetivos de segurança a serem atingidos. De maneira mais específica, descrevemos os aspectos mais importantes dessa etapa. Vamos conferir! Desenvolvimento de Software Seguro Marcio Quirino - 45 1. Identificar as metas do sistema ✓ Pode incluir a funcionalidade que o sistema deve fornecer, observando o que o sistema faz e para que e quem ele faz. É importante entender a finalidade do sistema e os objetivos de seus usuários a fim de identificar possíveis riscos de segurança. 2. Identificar ativos que precisam de proteção ✓ Podem ser dados, hardware, software ou pessoal. Isso ajuda a entender o que precisa ser protegido de possíveis ameaças. É importante que nenhum ativo relevante fique de fora desse levantamento. 3. Identificar ameaças potenciais que podem prejudicar os ativos ✓ Pode incluir ameaças externas (como hackers, malware e ataques de phishing) e ameaças internas (como erros de funcionários ou pessoas mal-intencionadas). Essa etapa deve considerar uma diversidade de perfis de especialistas em segurança, a fim de varrer a maior gama possível de ameaças conhecidas. 4. Entender a conformidade regulamentar ✓ Pode ser necessário, dependendo do setor e do país onde o sistema será implantado, cumprir regulamentos ou padrões específicos. É importante identificar e entender esses regulamentos e padrões para garantir que o sistema seja projetado e implementado de acordo. No geral, a primeira etapa da modelagem de ameaças é crucial para definir os objetivos de segurança do sistema e entender os riscos potenciais que podem afetar o sistema. Essa etapa ajuda a estabelecer uma base sólida para o restante do processo de modelagem de ameaças. Diagramação dos fluxos de dados A etapa de diagramação de fluxos visa criar um diagrama de fluxo de dados (DFD), ou seja, envolve a representação visual do sistema e de seus componentes, incluindo como os dados fluem entre eles. Vejamos alguns aspectos importantes! 1. Identificar os componentes do sistema (servidores, bancos de dados e interfaces de usuário) ✓ Inclui o propósito de cada componente e como eles trabalham juntos para atingir os objetivos do sistema e construir uma visão clara sobre como o sistema funciona. 2. Definir fluxo de dados entre os componentes ✓ Inclui identificar os diferentes tipos de dados, como entrada do usuário ou informações confidenciais, e como eles são transmitidos entre os componentes. 3. Identificar onde os dados são armazenados e como são protegidos ✓ Inclui armazenamentos de dados internos, como bancos de dados, e externos, como armazenamento em nuvem. 4. Identificar limites de confiança ✓ Inclui limites de confiança, que definem os limites entre diferentes componentes ou sistemas que possuem diferentes níveis de confiança. Por exemplo, um aplicativo da web pode ter um limite de confiança entre o navegador do cliente e o servidor da web. 5. Analisar o fluxo de dados para identificar possíveis falhas de segurança ✓ Inclui a identificação de áreas onde os dados podem ser vulneráveis ao acesso, à modificação ou à exclusão não autorizados. Ao criar um diagrama de fluxo de dados, o modelador de ameaças obtém melhor compreensão da arquitetura do sistema e de como os dados são transmitidos entre seus componentes. Resumindo O entendimento do diagrama de fluxo ajuda a identificar possíveis riscos e vulnerabilidades de segurança que podem ser tratados nas etapas subsequentes do processo de modelagem de ameaças. É desejável que sejam empregadas ferramentas de modelagem com bom resultado gráfico, gerando documentação de qualidade. Desenvolvimento de Software Seguro Marcio Quirino - 46 Identificação das ameaças A etapa de identificação de ameaças envolve o brainstorming de todas as possíveis ameaças ao sistema e seus componentes, incluindo ameaças internas e externas. Os diagramas de fluxos de dados devem ser utilizados como insumos para o brainstorming, pois trazem visibilidade sobre os possíveis pontos de falha observados a partir do acompanhamento do fluxo dos dados pelo sistema. Vejamos alguns aspectos importantes! 1. Identificar agentes (quem ou o que) de ameaça ao sistema ✓ Inclui ameaças externas, como hackers ou malware, bem como ameaças internas, como funcionários com intenções maliciosas. 2. Identificar vetores de ameaças ✓ Inclui a identificação de possíveis pontos de entrada, como conexões de rede, interfaces de usuário ou componentes de terceiros para identificar como um agente de ameaça pode obter acesso ao sistema ou a seus componentes. 3. Identificar ações de ameaças que um agente pode executar depois de obter acesso ao sistema ✓ Inclui ações como roubo de dados confidenciais, modificação de configurações do sistema ou lançamento de ataques de negação de serviço. 4. Categorizar ameaças ✓ Inclui priorizar quais ameaças devem ser abordadas primeiro. Uma vez identificadas todas as possíveis ameaças, elas devem ser categorizadas com base em sua gravidade e probabilidade de ocorrência. 5. Documentar ameaças identificadas junto com seu impacto potencial no sistema ✓ Inclui a documentação usada na próxima etapa do processo de modelagem de ameaças para desenvolver contramedidas para lidar com as ameaças identificadas. Durante os trabalhos de identificação, pode ser interessante utilizar um checklist estruturado de tipos de ameaça, incluindo: • Falsificação • Adulteração • Repúdio • Divulgação de informações confidenciais • Negação de serviço • Escalada de privilégio Ao identificar todas as possíveis ameaças ao sistema, o modelador de ameaças obtém melhor compreensão dos possíveis riscos e vulnerabilidades que precisam ser resolvidos. Esse entendimento ajuda30 Diretrizes para a definição de permissões............................................................................................ 31 Tipos de processamento e vulnerabilidades ............................................................................................ 31 Mitigação das vulnerabilidades do processamento de dados .............................................................. 32 Monitoramento das chamadas ................................................................................................................. 32 4. Envio da saída ........................................................................................................................ 33 Fundamentos da saída ............................................................................................................................. 33 Uso da criptografia ................................................................................................................................... 34 Protocolos de comunicação seguros ........................................................................................................ 34 Restrição da saída para usuários autorizados ......................................................................................... 35 Monitoramento da saída e realização de testes ....................................................................................... 36 Etapas da monitoração da saída .......................................................................................................... 36 5. Conclusão............................................................................................................................... 37 Considerações finais ................................................................................................................................ 37 Explore + .................................................................................................................................................. 37 Referências .............................................................................................................................................. 37 Modelagem, Implantação e Verificação de Software seguro.............................................................. 38 Introdução ................................................................................................................................................ 38 1. Verificação de segurança ...................................................................................................... 38 A importância do software seguro ............................................................................................................ 38 Vulnerabilidades ....................................................................................................................................... 38 Explorando vulnerabilidades nos softwares ............................................................................................. 40 Relação entre vulnerabilidade, ameaça e risco ........................................................................................ 41 Framework de avaliação .......................................................................................................................... 42 Desenvolvimento de Software Seguro Marcio Quirino - 3 Gestão de risco .................................................................................................................................... 42 Métodos de verificação de software ..................................................................................................... 43 Auditoria de software ............................................................................................................................ 43 Teste de caixa preta ............................................................................................................................. 43 2. Modelagem de Ameaças ....................................................................................................... 44 Definição dos objetivos ............................................................................................................................ 44 Diagramação dos fluxos de dados ........................................................................................................... 45 Identificação das ameaças ....................................................................................................................... 46 Mitigação das ameaças ............................................................................................................................ 46 Validação do modelo de ameaças ........................................................................................................... 47 3. Implantação de software seguro ............................................................................................ 48 Definindo os requisitos de segurança ...................................................................................................... 48 Projetando software seguro...................................................................................................................... 49 Desenvolvendo software seguro .............................................................................................................. 50 Testando o software ................................................................................................................................. 50 Implantando e fazendo manutenção do software ..................................................................................... 51 4. Garantias e métodos formais ................................................................................................. 52 OWASP .................................................................................................................................................... 52 SAFECode ............................................................................................................................................... 53 Microsoft SDL ........................................................................................................................................... 54 Fornecer treinamento ........................................................................................................................... 54 Definir requisitos de segurança ............................................................................................................ 55 Definir métricas e relatórios de conformidade ...................................................................................... 55 Executar modelagem de ameaças ....................................................................................................... 55 Estabelecer requisitos de projeto ......................................................................................................... 55 Outras práticas ..................................................................................................................................... 55 NIST ......................................................................................................................................................... 55 NIST CSF (Cybersecurity Framework) ................................................................................................. 56 NIST SP 800-39 ................................................................................................................................... 56 NIST SP 800-160 ................................................................................................................................. 56 Outros exemplos .................................................................................................................................. 56 Normas ISO..............................................................................................................................................a garantir que o sistema seja projetado e implementado com a segurança em mente, reduzindo a probabilidade de ataques bem-sucedidos. Mitigação das ameaças A etapa de mitigação envolve o desenvolvimento de contramedidas para lidar com as ameaças e vulnerabilidades identificadas, de forma a corrigir os problemas de segurança do sistema. Acompanhar a gestão de bug, considerando as ameaças identificadas, ajuda a configurar o fluxo de trabalho dessa etapa. Isso ocorre com ainda mais eficiência se for apoiado no checklist estruturado sugerido na identificação das ameaças, pois cria uma padronização da tarefa, garantindo que nada seja esquecido. Vejamos alguns aspectos importantes dessa etapa! Desenvolvimento de Software Seguro Marcio Quirino - 47 A. Priorizar ameaças identificadas ✓ Inclui o foco primeiro nas ameaças mais críticas que são medidas por meio do seu impacto potencial e probabilidade de ocorrência. É comum a utilização de três variáveis de avaliação como critério de priorização, a saber: impacto, gravidade e risco. B. Avaliar a eficácia de cada contramedida ✓ Inclui testar a contramedida, garantindo que ela aborde a ameaça identificada em um ambiente controlado, além de simular diferentes cenários de ataque. C. Implementar contramedidas ✓ Inclui a avaliação da eficácia de cada uma das contramedidas, para que sejam implementadas no sistema. Isto é: integrar as contramedidas no projeto do sistema e garantir que não interfiram na funcionalidade do sistema, como os controles de segurança, controles de acesso, criptografia ou sistemas de detecção de intrusão. ✓ As contramedidas podem cobrir um ou mais tipos controles de segurança, dentre eles: controles físicos (câmeras de segurança), técnicos (como criptografia) ou administrativos (como políticas). Além disso, podem ter uma ou mais funções, como: preventiva, detectiva, corretiva, recuperativa e impeditiva. D. Documentar contramedidas implementadas ✓ Ao registrar essas contramedidas, garantimos um registro dos controles de segurança implantados no sistema. Dessa forma, podemos manter e atualizar as contramedidas conforme necessário. Ao desenvolver e implementar contramedidas para abordar as ameaças identificadas, o modelador de ameaças reduz a probabilidade de ataques bem-sucedidos e fortalece a segurança geral do sistema. A manutenção contínua e as atualizações das contramedidas garantem que o sistema permaneça seguro diante das ameaças em evolução. A documentação amplia a consciência situacional e pode contribuir também para observação de possíveis lacunas ocasionadas por falta de cobertura das contramedidas. Validação do modelo de ameaças A etapa de validação envolve revisar e testar o modelo de ameaça para garantir que ele reflita com precisão os requisitos de segurança do sistema e seja eficaz na identificação e no tratamento de riscos de segurança. Geralmente acontece antes da implantação do sistema para garantir que os requisitos de segurança sejam cumpridos, as hipóteses sejam validadas e os controles de segurança sejam avaliados. Vejamos algumas ações importantes! 1. Revisar modelo de ameaça e garantir precisão dos requisitos de segurança ✓ Inclui revisar o diagrama de fluxo de dados, as ameaças identificadas e as contramedidas desenvolvidas para lidar com essas ameaças. 2. Testar contramedidas desenvolvidas e garantir a eficácia no tratamento das ameaças ✓ Inclui testar o sistema em um ambiente controlado e simular diferentes cenários de ataque. 3. Resolver problemas identificados durante revisão e teste, atualizando modelo de ameaça e contramedidas ✓ Inclui a adição de novas contramedidas ou o ajuste das existentes para lidar melhor com as ameaças identificadas. 4. Comunicar às partes interessadas resultados da validação do modelo de ameaça ✓ Inclui documentar o modelo de ameaça atualizado e as contramedidas e fornecer treinamento para administradores de sistema e outro pessoal relevante. Ao validar o modelo de ameaça, o modelador de ameaças garante que o sistema seja projetado e implementado com a segurança em mente, reduzindo a probabilidade de ataques bem-sucedidos. A validação e os testes contínuos ajudam a garantir que o sistema permaneça seguro diante das ameaças em evolução. Desenvolvimento de Software Seguro Marcio Quirino - 48 3. Implantação de software seguro Definindo os requisitos de segurança Chegou a hora de implementarmos o software, e é neste momento que entra o ciclo de vida de desenvolvimento seguro, encontrado na literatura pelas siglas SSDLC (secure software development lifecycle) ou SDL (secure development lifecycle). Confira as quatro etapas de teste: Ciclo de vida de desenvolvimento seguro. Na etapa de definição dos requisitos, que envolve capturar o escopo de funcionalidades do produto, são definidos objetivos e metas do projeto de software, traduzidos em requisitos funcionais e não funcionais que o software deve atender. É uma parte crítica do SDL porque define a base para todo o processo de desenvolvimento de software, sendo importante identificar os requisitos de segurança nesse estágio para garantir que a segurança seja integrada ao software desde o início. Isso pode ajudar a evitar que vulnerabilidades de segurança sejam introduzidas posteriormente no processo de desenvolvimento, quando se torna mais difícil e caro para corrigir. Comentário Os requisitos de segurança são geralmente identificados por meio de uma combinação de análise de risco, modelagem de ameaças e padrões e diretrizes de segurança. Os requisitos de segurança devem ser documentados e comunicados claramente a todas as partes interessadas, incluindo desenvolvedores, testadores e gerentes de projeto. Vamos conhecer alguns exemplos de requisitos de segurança que podem ser identificados durante a fase de levantamento de requisitos. Vamos lá! looks_one 1. Requisitos de autenticação e controle de acesso ✓ Especificam como os usuários são autenticados e autorizados a acessar o software e seus recursos. 2. Requisitos de proteção de dados ✓ Especificam como os dados confidenciais serão protegidos, por exemplo, usando criptografia ou outras medidas de segurança. 3. Requisitos de registro e auditoria ✓ Especificam como a atividade do sistema será registrada e auditada para detectar incidentes de segurança e rastrear a atividade do usuário. Desenvolvimento de Software Seguro Marcio Quirino - 49 4. Requisitos de conformidade ✓ Especificam quaisquer requisitos regulamentares ou legais que o software deve atender, como a Lei Geral de Proteção de Dados (LGPD), ou outra norma associada ao negócio no qual o sistema irá operar. O conceito-chave nesse passo é definir os aspectos de segurança do produto de maneira a incutir uma mentalidade de “segurança em primeiro lugar” e promover a conscientização do time de desenvolvedores. Ao identificar e documentar os requisitos de segurança, os desenvolvedores de software podem garantir que a segurança seja uma preocupação desde o princípio e que o software seja projetado e construído para atender aos padrões de segurança exigidos. Isso pode ajudar a reduzir o risco de violações de segurança, proteger dados confidenciais e manter a integridade e a disponibilidade do software. Projetando software seguro A etapa de projeção de software seguro envolve desenhar tecnicamente os requisitos. A arquitetura do software é desenhada e as especificações técnicas são formalmente definidas empregando linguagens voltadas à modelagem. Resumindo O objetivo da fase de projeção de software é garantir que este seja projetado de forma a atender aos requisitos funcionais e não funcionais identificados na fase de definição dos requisitos, ao mesmo tempo em que integra considerações de segurança ao design. As considerações de segurança são integradas à arquitetura geral do software e às especificaçõestécnicas, o que inclui analisar possíveis riscos e vulnerabilidades de segurança identificados e projetar o software de forma a mitigar esses riscos. Vejamos algumas considerações de segurança que podem ser abordadas na fase de design. Confira! 1. Armazenamento e transmissão segura de dados ✓ Projeta o software para armazenar e transmitir dados com segurança, como criptografar dados em trânsito e em repouso. 2. Controle de acesso ✓ Projeta o software para controlar o acesso a recursos ou dados confidenciais, como por meio de controle de acesso baseado em função (role-based access control - RBAC) ou outros mecanismos de autenticação. 3. Validação de entrada ✓ Projeta o software para validar a entrada de usuários e outros sistemas, de modo a evitar a exploração de vulnerabilidades de segurança, como injeção de SQL ou script entre sites (cross-site scripiting - XSS). 4. Protocolo de comunicação seguro ✓ Projeta o software para usar protocolos de comunicação seguros, como hypertext transfer protocol secure (HTTPS), para proteger os dados transmitidos pela Internet. 5. Tratamento de erros ✓ Projeta o software para lidar com erros e exceções de maneira segura, como registrar erros sem revelar informações confidenciais e tentar garantir o retorno ao estado anterior durante a detecção do erro. Essa abordagem é chamada de resiliência em software e visa tornar o sistema mais confiável. Ao integrar considerações de segurança no projeto do software, os desenvolvedores podem criar um software menos vulnerável a ataques. Isso pode ajudar a evitar que vulnerabilidades de segurança sejam introduzidas posteriormente no processo de desenvolvimento e pode reduzir o risco de violações de segurança e perda de dados ou de disponibilidade. A fase de projeto prepara o terreno para a fase de desenvolvimento, na qual o software é realmente construído e codificado de acordo com as especificações técnicas definidas nessa etapa. Desenvolvimento de Software Seguro Marcio Quirino - 50 Desenvolvendo software seguro A etapa de desenvolvimento envolve escrever o código que implementa o desenho técnico e permite que o software seja desenvolvido com base nas especificações técnicas definidas na fase de projeto. O objetivo dessa fase é implementar o software de forma que atenda aos requisitos funcionais e não funcionais, e integre as considerações de segurança identificadas nas fases anteriores. Durante a fase de desenvolvimento, os desenvolvedores escrevem o código, criam a documentação e executam tarefas de garantia de qualidade para assegurar que o software funcione conforme pretendido e atenda aos requisitos especificados. Práticas de segurança e técnicas de codificação seguras são seguidas durante essa fase para garantir que o software seja desenvolvido com a segurança em mente. Alguns exemplos de práticas de codificação segura que podem ser seguidas durante a fase de desenvolvimento incluem todas as considerações abordadas na fase de projeto e a utilização de bibliotecas seguras, em vez de escrever o código do zero. O desenvolvedor pode utilizar bibliotecas seguras já existentes que tenham sido testadas e verificadas para evitar vulnerabilidades de segurança que abram brechas para ataques ao sistema. Vamos relembrar as preocupações levantadas e desenhadas na fase de projeto, uma vez que devem ser levadas em consideração durante o desenvolvimento. Confira! • Validação de entrada, inclusive com crítica não apenas ao formato, mas também levando em consideração a limitação adequada de tamanho, de forma a tentar evitar ataques de buffer overflow. • Armazenamento e transmissão seguros de dados, considerando mecanismos criptográficos para proteção dos dados. • Tratamento de erros e exceções de maneira segura que garantam a não exposição de informações críticas e confidenciais no caso de uma mensagem de erro. • Controle de acesso com mecanismo de autenticação para dados confidenciais e recursos do sistema. • Protocolos de comunicação seguros para proteger os dados transmitidos pela internet. A fase de Desenvolvimento é uma parte crítica do SDL porque é onde o software é realmente construído e codificado. Ao seguir práticas e técnicas de codificação seguras durante esta fase, os desenvolvedores podem ajudar a fazer um software que atenda aos padrões de segurança, reduza o risco de tornando o software mais robusto em sua superfície de ataques, parte exposta a ameaças de hacker. Além de escrever código, os desenvolvedores também criam documentação e realizam tarefas de garantia de qualidade para assegurar que o software seja desenvolvido de acordo com as especificações técnicas e atenda aos requisitos identificados nas fases anteriores. Conscientização e mentalidade de segurança é algo que os desenvolvedores de software seguro devem possuir. Portanto, oferecer treinamento e educação é algo desejável nas empresas de desenvolvimento. A varredura de código por um profissional diferente do que desenvolveu também contribui para a segurança do software. Existem ainda scanners que analisam código e podem detectar problemas durante a codificação. É importante criar um processo operacional repetível. Por exemplo, instruir os desenvolvedores a sempre executarem as ferramentas de varredura de segurança antes de enviar seu código, bem como realizar reciclagens periódicas de treinamento para melhores práticas de segurança. Testando o software A etapa de teste de software envolve verificar se as funcionalidades se desenvolvam como esperado e dentro dos requisitos de segurança. O software é testado para garantir que funcione conforme o planejado, Desenvolvimento de Software Seguro Marcio Quirino - 51 atenda aos requisitos funcionais e não funcionais e integre as considerações de segurança identificadas nas fases anteriores. A fase de teste é essencial porque ajuda a identificar quaisquer problemas ou vulnerabilidades no software antes de sua implantação, realizando um apanhado geral sobre a qualidade de todas as atividades anteriores voltadas à segurança. Testes devem ser realizados durante todo o processo de desenvolvimento, desde testes unitários até testes de integração, finalizando com teste de sistema e teste de aceitação. Confira alguns exemplos de testes que podem ser realizados: A. Teste funcional ✓ Testar o software para garantir que ele execute as funções a que se destina. B. Teste de segurança ✓ Testa o software em busca de vulnerabilidades e pontos fracos de segurança, como testes de penetração ou verificação de vulnerabilidades. C. Teste de desempenho ✓ Testa o software para garantir que ele funcione adequadamente sob cargas esperadas e cenários de uso, assegurando sua disponibilidade mesmo em condições de estresse dentro dos requisitos previstos. D. Teste de usabilidade ✓ Testa o software para garantir que seja fácil de usar e atenda às necessidades do usuário e que um comportamento inesperado do usuário não comprometa a confidencialidade, integridade ou disponibilidade do sistema. E. Teste de compatibilidade ✓ Testa o software para garantir que ele funcione conforme o esperado em diferentes plataformas, navegadores e dispositivos. O teste deve ser um processo contínuo ao longo do ciclo de desenvolvimento, e os desenvolvedores devem usar uma variedade de ferramentas manuais e automatizadas, e técnicas de teste para garantir que o software seja utilizado de forma completa e precisa. Os resultados dos testes devem ser documentados e comunicados claramente a todas as partes interessadas, incluindo desenvolvedores, testadores e gerentes de projeto. Comentário Um SDL verdadeiramente ágil não segue o padrão de testes de um processo linear. Quando estamos falando em produção de software em modelos tradicionais, primeiro é preciso fazer tudo e só depois testar. Esse protocolo não pode ser seguido em um SDL ágil, porque novasversões são lançadas de forma rotineira. A maioria das equipes hoje constrói algum tipo de pipeline com integração contínua e testes de software frequentes. Nesse modelo, há uma série de testes ocorrendo em vários estágios, alguns durante a codificação, alguns após cada envio de código, alguns todas as noites e alguns testando o ambiente de produção ao vivo, por exemplo. Dentro da etapa de requisitos, é importante mapear onde os testes de segurança devem ser executados, mas é possível introduzir testes adicionais antes da implantação, dependendo da estratégia de lançamento do sistema. Implantando e fazendo manutenção do software Na etapa de implantação e manutenção, o software é implantado em ambiente de produção e mantido ao longo do tempo para garantir que continue atendendo aos requisitos funcionais e de segurança. Durante a fase de implantação, o software é liberado para produção, e a infraestrutura necessária é implementada para dar suporte ao software em um ambiente de produção. Isso pode envolver a configuração de servidores, configuração de bancos de dados e implementação de controles de segurança para proteger o software e os dados. Desenvolvimento de Software Seguro Marcio Quirino - 52 Depois que o software é implantado, manutenção e suporte contínuos são necessários para garantir que ele continue atendendo aos requisitos funcionais e de segurança. Isso pode envolver a execução de atualizações e patches regulares para solucionar vulnerabilidades de segurança ou correções de bugs, monitorar o software quanto a problemas de desempenho ou incidentes de segurança e fornecer suporte técnico aos usuários. Confira alguns exemplos de atividades que podem ser realizadas durante a fase de implantação e manutenção. A. Atualizações e patches de segurança ✓ Envolve atualizar regularmente o software para solucionar quaisquer falhas ou pontos fracos que tenham sido descobertos posteriormente. B. Monitoramento e resposta a incidentes ✓ Envolve monitorar o software quanto a incidentes de segurança ou problemas de desempenho, e respondê-los de maneira oportuna e eficaz, inclusive interagindo com agências específicas da área para publicar os fatos ocorridos, ampliando a abrangência de conscientização sobre as falhas para outras organizações que utilizem o mesmo sistema por meio de alertas. C. Suporte ao usuário ✓ Envolve o fornecimento de suporte técnico aos usuários para garantir que eles possam usar o software de maneira eficaz e segura. D. Ajuste de desempenho ✓ Envolve a otimização do desempenho do software para garantir que ele funcione de maneira ideal sob as cargas esperadas e os cenários de uso. E. Backups de dados e recuperação de desastres ✓ Envolve a implementação de backups de dados e medidas de recuperação de desastres para garantir que os dados sejam protegidos e possam ser restaurados em caso de perda ou interrupção de dados. Ao realizar manutenção e suporte contínuos durante a fase de implantação e manutenção, outros aspectos da segurança devem ser abordados, incluindo questões da infraestrutura que irá abrigar o sistema e os acessos a ela. Para os casos cada vez mais comuns de sistemas que rodam na nuvem, existe toda uma disciplina de segurança. Todas as atividades incluídas nessa etapa visam dar garantias mínimas de que o software continue atendendo às necessidades dos usuários. 4. Garantias e métodos formais OWASP The Open Worldwide Application Security Project (OWASP) é uma fundação sem fins lucrativos que, conforme sua missão, trabalha para melhorar a segurança do software. Promove projetos de software de código aberto, desenvolvendo lideranças locais nos diversos capítulos espalhados pelo mundo, e promove conferências educacionais e de treinamento, servindo de boa fonte para desenvolvedores e tecnólogos protegerem a web. A OWASP atua nos mais diversos temas relacionados à segurança das aplicações web. O SDL proposto pela OWASP é uma estrutura para a construção de software seguro que consiste em uma série de etapas a serem seguidas durante o processo de desenvolvimento de software, desde o planejamento até o lançamento. Vamos conferir! A. Definição dos requisitos de segurança ✓ Nesta fase, os requisitos de segurança para o aplicativo são identificados e documentados, o que inclui a identificação de possíveis riscos e ameaças à segurança e a definição de objetivos de segurança que o aplicativo deve atender. Desenvolvimento de Software Seguro Marcio Quirino - 53 B. Criação de um modelo de ameaças ✓ Nesta fase, o objetivo é identificar e documentar possíveis ameaças e vulnerabilidades à segurança. A modelagem de ameaças envolve a identificação de ameaças potenciais, como usuários mal-intencionados, conexões de rede inseguras ou vulnerabilidades no código. C. Design seguro ✓ Nesta fase, o desenho de projeto do aplicativo é revisado e os recursos de segurança são adicionados, o que inclui a implementação de controles de segurança, como controles de acesso, validação de entrada e criptografia. D. Implementação ✓ Nesta fase, o aplicativo é desenvolvido usando práticas de codificação seguras. Isso inclui seguir as diretrizes de codificação segura, que são orientações para que o software esteja apto a passar nos testes de segurança. E. Verificação ✓ Nesta fase, o aplicativo é testado quanto a vulnerabilidades de segurança usando várias técnicas de teste, como teste de penetração e varredura de vulnerabilidade. F. Lançamento do software ✓ Nesta fase, o aplicativo é liberado para produção. Isso inclui garantir que o aplicativo seja seguro e que os controles de segurança estejam em vigor para proteger o aplicativo e seus dados. G. Pós-lançamento ✓ Nesta fase, o aplicativo é monitorado quanto a vulnerabilidades e ameaças de segurança, o que inclui a realização de avaliações de segurança regulares, resposta a incidentes de segurança e atualização do aplicativo com correções (incluindo as correções segurança), conforme necessário. SAFECode Software Assurance Forum for Excellence in Code (SAFECode) é uma organização sem fins lucrativos, com atuação global, dedicada a aumentar a confiança em produtos e serviços de tecnologia da informação e comunicação por meio do avanço de métodos eficazes de garantia de software. A missão da SAFECode é promover as melhores práticas para desenvolver e fornecer software, hardware e serviços mais seguros e confiáveis. A organização publicou um conjunto de diretrizes denominado “Práticas Fundamentais para o Desenvolvimento de Software Seguro”, no qual apresentam elementos essenciais de um programa de ciclo de vida de desenvolvimento seguro. O SDL proposto é composto de oito práticas fundamentais. Algumas serão descritas com mais detalhes, e outras apenas citadas. Vejamos! 1. Definição de controles de segurança da aplicação ✓ O SAFECode usa o termo application security controls (ASC) para se referir aos requisitos de segurança. As entradas para o ASC devem incluir: princípios de design seguro; práticas de codificação seguras; requisitos legais e do setor com os quais o aplicativo precisa estar em conformidade (por exemplo, PCI – no setor de pagamentos, SCADA – na automação industrial ou LGPD – para proteção de dados pessoais); políticas e normas internas; incidentes e outros comentários; ameaças e riscos. 2. Projeto ✓ O software deve incorporar recursos de segurança para cumprir, internamente, as práticas de segurança e, externamente, as leis ou os regulamentos. Além disso, o software deve resistir a ameaças conhecidas com base no ambiente operacional. A modelagem de ameaças, revisões de arquitetura e revisões de design podem ser usadas para identificar e corrigir falhas de projeto antes de partir para implementação do código-fonte. Desenvolvimento de Software Seguro Marcio Quirino - 54 3. Práticas de codificação segura ✓ Asvulnerabilidades não intencionais são introduzidas no código por erros do programador. Esses tipos de erros podem ser evitados e detectados usando padrões de codificação; selecionando das linguagens, estruturas e bibliotecas mais apropriadas, incluindo o uso de seus recursos de segurança associados; usando ferramentas de análise automatizadas; e revisando manualmente o código. 4. Gestão de risco de segurança inerente ao uso de componentes de terceiros ✓ Os projetos de software são construídos usando componentes de código aberto e de proprietários terceiros. Cada um desses componentes pode ter vulnerabilidades já na adoção ou que apareçam depois. Uma organização deve manter um inventário desses componentes, usar ferramentas para verificar vulnerabilidades neles e ter um plano para responder quando novas vulnerabilidades forem descobertas. 5. Teste e validação ✓ A organização deve aplicar testes automatizados estáticos e dinâmicos, além dos famosos testes de penetração realizado pelos hackers éticos. Nesse último, um especialista em exploração de vulnerabilidades é contratado e liberado legalmente para tentar encontrar e explorar vulnerabilidades do sistema, reportando cada uma delas. 6. Gestão de descobertas de falhas de segurança ✓ As cinco primeiras práticas produzem artefatos que ajudam nas descobertas relacionadas à segurança do produto (ou falta dela). As descobertas devem ser rastreadas e ações devem ser tomadas para remediar as vulnerabilidades. Como alternativa, a equipe pode aceitar conscientemente o risco e, nesse caso, o risco deve ser rastreado, com uma classificação de gravidade; um plano de correção; um prazo de nova revisão. 7. Divulgação e resposta de vulnerabilidade ✓ O fato de seguir um SDL formal não faz o produto se tornar perfeitamente seguro devido ao cenário de ameaças que muda constantemente. A organização deve desenvolver uma resposta de vulnerabilidade e processo de divulgação para ajudar a conduzir a resolução de vulnerabilidades descobertas externamente e para manter todas as partes interessadas informadas sobre o progresso. 8. Planejamento da implementação do desenvolvimento seguro ✓ O SDL saudável e maduro deve incluir, além das sete práticas anteriores, uma integração dessas práticas no processo de negócios em toda a organização, incluindo gerenciamento de programas, gerenciamento de partes interessadas, planejamento de implantação, métricas e indicadores e um plano de melhoria contínua. A cultura, a expertise e o nível de habilidade da organização precisam ser considerados ao planejar a implantação de um ciclo de vida de software seguro. Microsoft SDL A Microsoft desenvolveu um SDL próprio, o Microsoft Security Development Lifecycle, para o processo de desenvolvimento de seus produtos e, desde 2006, vem disseminando esse conhecimento. Seu método contém diversas práticas que serão descritas resumidamente as mais importantes, e as outras apenas citaremos, tudo bem? Fornecer treinamento Toda a organização de desenvolvimento deve conhecer a perspectiva, os objetivos e as técnicas do invasor, não apenas as implicações comerciais de não criar produtos seguros, o que chega a ser intuitivo. Em muitos casos, profissionais como desenvolvedores, arquitetos de software, engenheiros de serviço, gerentes de programa, gerentes de produto e gerentes de projeto não tiveram no seu cabedal de educação formal aprendizado sobre segurança cibernética. Desenvolvimento de Software Seguro Marcio Quirino - 55 Ferramentas de segurança, linguagens de programação seguras e vetores de ataque estão em constante evolução, tornando o conhecimento obsoleto com grande velocidade. Portanto, o treinamento contínuo em segurança cibernética é essencial para organizações que desenvolvem software. Definir requisitos de segurança A empresa desenvolveu algumas técnicas para a elaboração sistemática de requisitos de segurança. Por exemplo, a engenharia de requisitos de qualidade de segurança (security quality requirements engineering - SQUARE), que é um processo de nove etapas que ajuda as organizações a criar segurança nos estágios iniciais do ciclo de vida da produção. O framework keep all objectives satisfied (KAOS) para linguagem de especificação de requisitos baseado em objetivos tem como foco o conceito de antimodelos. Um antimodelo é construído abordando obstáculos maliciosos (chamados antiobjetivos) criados por invasores para ameaçar os objetivos de segurança de um sistema. Um obstáculo nega os objetivos existentes do sistema! O secure i* estende a estrutura de modelagem i* com modelagem e análise de compensações de segurança e alinha os requisitos de segurança com outros requisitos. É importante entender que os requisitos de segurança devem ser continuamente atualizados para refletir as mudanças na funcionalidade necessária, nos padrões e no cenário de ameaças. Definir métricas e relatórios de conformidade A equipe de gerenciamento deve entender e ser responsabilizada pelos níveis mínimos aceitáveis de segurança usando métricas de segurança. Um subconjunto dessas métricas pode ser definido como indicadores-chave de desempenho (KPIs) para relatórios gerenciais. Executar modelagem de ameaças A particularidade da Microsoft é empregar o que chamam de spoofing, tampering, repudiation, information disclosure, denial of service, elevation of privilege (STRIDE) como check list estruturado. Estabelecer requisitos de projeto O design de recursos seguros envolve o cumprimento dos princípios de segurança atemporais, ou seja, conceitos praticamente imutáveis: simplicidade; controle de acesso baseado em permissão em vez de exclusão; segurança não baseada na obscuridade; princípio do privilégio mínimo; defesa em profundidade; entre outros princípios que norteiam os requisitos de projeto. Outras práticas As outras práticas que completam a estrutura de SDL da Microsoft são: • Definição de uso de padrões de criptografia. • Gerenciamento de riscos de segurança usando componentes de terceiros. • Emprego apenas de ferramentas homologadas. • Execução de teste estático de código, conhecido como static analysis security testing (SAST). • Execução de teste dinâmico de código, conhecido como dynamic analysis security testing (DAST). • Teste de penetração, o pen test. • Estabelecimento de processo-padrão de resposta a incidentes. NIST O National Institute of Standards and Technology (NIST) oferece uma série de publicações que podem ser usadas como suporte formal aos esforços de desenvolvimento seguro. Vamos citar algumas, mas dentro de um universo gigantesco de informações disponíveis. Desenvolvimento de Software Seguro Marcio Quirino - 56 NIST CSF (Cybersecurity Framework) O arcabouço de segurança cibernética fornece orientação às organizações para entender, gerenciar, reduzir e comunicar melhor os riscos de segurança cibernética. O framework propõe uma classificação de maturidade para as organizações subdividida em níveis. Os níveis CSF funcionam como uma forma de fazer as organizações enxergarem e compreenderem o patamar que sua abordagem de segurança cibernética e processos em vigor para gerenciar esse risco está. Os níveis têm gradação crescente de rigor e sofisticação na descrição geral das práticas de gestão do risco de segurança cibernética. NIST SP 800-39 O objetivo da Publicação Especial 800-39 é gerenciar riscos de segurança da informação nas operações organizacionais, ou seja, missão, funções, imagem e reputação, ativos organizacionais, indivíduos, dentre outros. Fornece uma abordagem estruturada, mas flexível, para gerenciar o risco de segurança da informação, considerando detalhes de avaliação, resposta e monitoramento contínuo do risco. O texto põe foco na gestão de riscos técnicos de sistemas de TI com abordagem prescritiva e sugestiva. Inclui ameaças, vulnerabilidades, probabilidade e impacto, juntocom monitoramento de controle e verificação de conformidade. NIST SP 800-160 A publicação concentra-se na engenharia de resiliência cibernética, uma disciplina relativamente nova de engenharia de sistemas especializada em desenvolver sistemas seguros confiáveis e com capacidade de sobrevivência. Observada do ponto de vista da gestão de risco, a resiliência cibernética tenta reduzir o risco de dependência da empresa dos recursos cibernéticos. A norma NIST SP 800-160 define a engenharia de resiliência cibernética e tem como objetivo construir e manter sistemas confiáveis com a habilidade de prever, resistir, recuperar-se e adaptar-se a situações desfavoráveis, estresses, ataques ou comprometimentos que envolvam ou sejam ativados por recursos cibernéticos. NIST SP 800-53 É uma publicação bastante interessante em termos práticos para mitigação de risco, no âmbito da gestão de riscos e implementação de contramedidas no âmbito da avaliação de software seguro. Fornece um catálogo de controles de segurança e privacidade para sistemas de informação e organizações para proteger operações e ativos organizacionais e indivíduos de um conjunto diversificado de ameaças e riscos, incluindo ataques hostis, erros humanos, desastres naturais, falhas estruturais, entidades de inteligência estrangeiras e riscos de privacidade. Os controles propostos são flexíveis e customizáveis e abordam diversos requisitos derivados de leis, regulamentos, políticas, padrões e diretrizes. O catálogo de controle aborda a segurança e a privacidade pela perspectiva da funcionalidade e de garantia. Abordar funcionalidade e garantia ajuda a garantir que os produtos de tecnologia da informação e os sistemas que dependem desses produtos sejam suficientemente confiáveis. Outros exemplos Vejamos outras publicações e ferramentas relacionadas que merecem ser citadas: 1. NIST SP 800-61 ✓ Guia para tratamento de incidentes de segurança de computadores. 2. NIST SP 800-122 ✓ Guia para proteção de confidencialidade de informações de identificação pessoal. Desenvolvimento de Software Seguro Marcio Quirino - 57 3. NIST SP 800-218 ✓ Mitigando o risco de vulnerabilidades de softwares pela adoção de um Framework de Desenvolvimento de Software Seguro. O NIST também conta com diversas publicações relacionadas à criptografia, como técnicas de cifragem de blocos, algoritmos de função resumo (hash function) e os próprios algoritmos de criptografia em si, tanto de simétricos como assimétricos. O NIST já foi responsável por um concurso mundial para seleção do padrão de criptografia a ser adotado pelos EUA por ocasião da substituição do então algoritmo padrão, o data encryption standard (DES). Existem publicações que versam inclusive sobre criptografia pós- quântica, ou seja, o que acontecerá com a criptografia quando o computador quântico for efetivamente inventado e fabricado em escala. O NIST preocupa-se em estar sempre na fronteira do conhecimento, sendo, portanto, importante fonte de informação de qualidade. Normas ISO International Organization for Standardization (ISO) é uma entidade não governamental que desenvolve e publica padrões internacionais. A atuação do órgão é extremamente abrangente, passando por diversas áreas do conhecimento. Relacionado à gestão da segurança da informação, podemos relacionar toda a família de normas 27000. Com respeito ao sistemas de software, daremos um destaque especial para: ISO 15288, ISSO 16085, ISO 20004 e ISO 23643. Família ISO 27000 É um conjunto de padrões internacionais que fornece diretrizes para sistemas de gerenciamento de segurança da informação (SGSI). Vejamos a família de normas ISO 27000! 1. ISO/IEC 27001 - Tecnologia da Informação – Técnicas de segurança – Sistemas de gestão de segurança da informação - Requisitos ✓ Especifica os requisitos para um SGSI e fornece uma abordagem sistemática para gerenciar informações confidenciais da empresa para garantir sua confidencialidade, integridade e disponibilidade. 2. ISO/IEC 27002 - Tecnologia da Informação – Técnicas de segurança – Código de prática para controles de segurança da informação ✓ Fornece um código de práticas para gerenciamento de segurança da informação e abrange uma ampla gama de controles de segurança, incluindo segurança física, segurança de rede, controles de acesso e gerenciamento de incidentes. 3. ISO/IEC 27003 - Tecnologia da informação — Técnicas de segurança — Sistemas de gestão da segurança da informação — Orientações ✓ Fornece diretrizes para a implementação de um SGSI e inclui informações sobre as fases de planejamento, projeto e implementação. 4. ISO/IEC 27004 - Tecnologia da informação — Técnicas de segurança — Sistemas de gestão da segurança da informação — Monitoramento, medição, análise e avaliação ✓ Fornece orientações sobre a medição e avaliação da eficácia de um SGSI, incluindo o uso de métricas e indicadores de desempenho. 5. ISO/IEC 27005 - Tecnologia da informação — Técnicas de segurança — Gestão de riscos de segurança da informação ✓ Fornece diretrizes para gerenciamento de riscos relacionados à segurança da informação, incluindo avaliação, tratamento e comunicação de riscos. 6. ISO/IEC 27006 - Information technology – Security techniques – Requirements for bodies providing audit and certification of information security management systems ✓ Apresenta diretrizes ao credenciamento de organizações que fornecem serviços de certificação para SGSI, garantindo que os organismos de certificação operem de forma eficaz e imparcial. No entanto, é uma norma ainda não traduzida/adaptada para o português. Desenvolvimento de Software Seguro Marcio Quirino - 58 A família de padrões ISO 27000 é essencial para organizações que lidam com informações confidenciais, incluindo dados financeiros, informações pessoais e propriedade intelectual. Ao implementar um SGSI com base nesses padrões, as organizações podem reduzir o risco de violações de segurança e garantir a confidencialidade, integridade e disponibilidade de suas informações. Existe uma certificação ISO 27001 que é reconhecida globalmente e proporciona às organizações uma vantagem competitiva, aumentando sua credibilidade e reputação. ISO/IEC 15288 É uma norma antiga (2009), mas que ainda não foi substituída e possui tradução/adaptação para o português. Descreve o ciclo de vida de sistemas a partir de processos que apoiam definição, controle e melhoria dos procedimentos associados ao ciclo de vida utilizados em uma organização ou em um projeto. A ISO/IEC 15288 aborda o desenvolvimento de sistemas e configurações de hardware, software, dados, pessoas, processos, procedimentos, instalações, materiais e entidades envolvidas. Aplica-se a organizações que desempenham papéis tanto de comprador como de fornecedor, engloba todo o ciclo de vida de sistemas, incluindo concepção, desenvolvimento, produção, utilização, suporte e desativação de sistemas, e para a aquisição e fornecimento de sistemas, independentemente de ser realizado interna ou externamente à organização. Além disso, fornece um modelo de referência de processo definido por propósito e resultados esperados de processo, que decorrem da execução bem-sucedida das tarefas. ISO/IEC 16085 É uma norma que fornece um padrão para profissionais responsáveis pelo gerenciamento de riscos associados a sistemas e software ao longo de todo seu ciclo de vida. Essa norma foi revisada recentemente para se alinhar com as atualizações de outros padrões relacionados, bem como para incluir novos conteúdos relacionados aos desafios de gerenciamento de riscos inerentes a grandes programas e projetos de engenharia de sistemas complexos. ISO/IEC 20004 É uma norma que toma por base outras duas, realizando um refinamento de atividades definidas na ISO/IEC 18045. Fornece orientações mais específicas sobre a identificação, seleção e avaliação devulnerabilidades para proporcionar uma avaliação (baseada na ISO/IEC 15408) de um sistema-alvo. A norma tomou como base a biblioteca ITIL (Information Technology Infrastructure Library), que é um conjunto de práticas e processos para gerenciamento de serviços de TI, o qual fez relativo sucesso no início dos anos 2000 com sua versão 2. ISO/IEC 23643 É uma norma recente (2020), que especifica os requisitos para os fornecedores de software e fornece diretrizes para usuários e desenvolvedores de software seguro e ferramentas de verificação de segurança. Os usuários de tais ferramentas são desenvolvedores de software que precisam estar cientes das necessidades de segurança de software. É interessante, pois apresenta casos de uso para segurança de software e ferramentas de verificação de segurança. Apresenta também categorias de ferramentas para segurança de software e fornece orientação e requisitos específicos de cada categoria para fornecedores e desenvolvedores de ferramentas. A ISO é uma importante fonte de consulta para profissionais das mais diversas áreas, tendo algumas de suas normas obrigatoriedade de uso em um grande espectro de setores e indústrias. Considerações finais A verificação de software é um processo crucial que tem como objetivo garantir que o software atenda aos requisitos de segurança, confiabilidade, desempenho e qualidade. A respeito especificamente da segurança, a modelagem de ameaças é uma técnica utilizada para identificar e avaliar as possíveis ameaças e vulnerabilidades que podem comprometer o software. Desenvolvimento de Software Seguro Marcio Quirino - 59 O gerenciamento de risco é outra atividade importante no processo de verificação de segurança de software. Engloba a identificação de ativos, avaliação e tratamento dos riscos associados a medidas de prevenção. O SDL é um processo de desenvolvimento de software que incorpora a segurança desde o início do ciclo de vida do desenvolvimento. A segurança incorporada tira proveito de ferramentas estruturadas, por exemplo, a modelagem de ameaças, composta das seguintes etapas: definição de objetivos; diagramação de fluxos de dados; identificação de ameaças; mitigação; e validação. Em conjunto, a modelagem de ameaças, o gerenciamento de risco e o SDL formam uma abordagem abrangente para a verificação de software, ajudando o software a reduzir o número de falhas que se configurem como vulnerabilidades exploradas. Explore + Confira as indicações que separamos especialmente para você! Pesquise: A base de dados de exploits e conheça os exploits já prontos orientados para determinadas plataformas e tipos de ataque, com o respectivo autor do código. Vale conferir! Em seus próprios portais eletrônicos, OWASP, SAFECode e Microsoft SDL. São excelentes caminhos para aprofundar o seu estudo! Referências KHAN, S. A.; KUMAR, R.; KHAN, R. Software security: concepts & practices. Boca Raton, FL: Chapman & Hall/CRC Press, 2023. Desenvolvimento de Software Seguro Marcio Quirino - 60 Emprego DevSecOps no Ciclo de Vida do Software Introdução Com o DevSecOps, você dá um passo importante na jornada de desenvolver aplicativos mais modernos e, acima de tudo, mais seguros. Essa prática de engenharia de software está se tornando cada vez mais popular, especialmente em relação à transformação digital e à segurança da informação. A prática consiste na integração de segurança no ciclo de vida do desenvolvimento de software, desde o início do projeto até a implantação e manutenção do software em produção. Ou seja, DevSecOps garante que a disciplina de segurança seja trabalhada desde a concepção do software a ser desenvolvido, durante sua implementação, até sua manutenção em produção. Diferente do modelo tradicional de desenvolvimento de software, em que a segurança é considerada apenas na fase final de testes, DevSecOps prega pela integração contínua de requisitos de segurança durante o processo de desenvolvimento, com o objetivo de antecipar, minimizar e até mesmo evitar vulnerabilidades e ameaças à segurança do software em desenvolvimento. Enquanto DevOps tem como objetivo principal acelerar o processo de desenvolvimento de software por meio de práticas de engenharia de software, automação de processos de desenvolvimento, automação de builds e integração frequente e contínua de pequenos artefatos de software entre outros conceitos, DevSecOps alinha as práticas de desenvolvimento ágil com a segurança da informação, garantindo que a segurança seja parte integrante do processo de desenvolvimento. 1. Segurança no ciclo de vida do software Segurança: Modelo tradicional x DevOps Ciclo de vida de software Quando falamos de desenvolvimento de software, a primeira coisa que precisamos considerar é seu ciclo de vida, que normalmente é composto por diversas fases que juntas permitem o desenvolvimento de um produto de software. Não existe um padrão único e que contemple todas as fases possíveis para um ciclo de vida efetivo no desenvolvimento de software, mas podemos destacar fases importantes que devem ser contempladas em qualquer ciclo de vida de desenvolvimento de software. Vamos conferi-las! A. Ideação ✓ Fase em que o problema a ser resolvido com um produto de software é explorado e entendido. Nessa fase, os requisitos de negócio que devem ser endereçados pelo produto de software emergem e são adicionados a um backlog de produto. B. Design ✓ Fase em que a solução de software para resolver os problemas e requisitos de negócio identificados na fase de ideação é desenhada. Contempla-se arquitetura, definição de componentes e integração entre diferentes serviços (inclusive de terceiros), bem como outras características que devem ser endereçadas pela solução, ou seja, é a fase em que a solução é definida. C. Implementação ✓ Fase em que a solução definida na fase de design é implementada, ou seja, construída. D. Teste ✓ Fase em que o produto de software desenvolvido é testado quanto a sua aderência de resolução do problema identificado na fase de ideação. E. Implantação ✓ Fase em que o produto de software desenvolvido e testado é posto em produção para seu efetivo uso por parte dos usuários. F. Evolução Desenvolvimento de Software Seguro Marcio Quirino - 61 ✓ Fase em que o produto de software é evoluído, baseado no feedback de seus usuários. A descrição das fases não deixa claro em que momento a disciplina de segurança deve ser contemplada. Na maioria das vezes, a subjetividade levava à negligência dessa disciplina importante por parte das equipes de desenvolvimento de software, que só se preocupavam com segurança quando algum problema era relatado pelos usuários. Com o advento de DevSecOps, a segurança passa a ser uma disciplina pensada e tratada em todas as fases do ciclo de vida de desenvolvimento, desde a ideação até a sua evolução, sendo parte integrante do dia a dia das pessoas envolvidas em seu desenvolvimento. Segurança no modelo tradicional de desenvolvimento de software No modelo de desenvolvimento de software tradicional, a disciplina de segurança é normalmente endereçada como um aspecto isolado do processo de desenvolvimento, sendo muita das vezes uma fase adicional ao ciclo de vida, ou até mesmo uma atividade na fase de testes desses ciclos tradicionais. Isso porque a disciplina de segurança é identificada como um requisito adicional aos requisitos funcionais das soluções de software, permitindo que os times de implementação enxerguem segurança como uma fase posterior ao desenvolvimento das funcionalidades de negócio. Os times focam na implementação de artefatos de software que resolvem os problemas de negócio, e só depois se preocupam em testar esses artefatos quanto aos aspectos de segurança necessários. Muitas vezes os testes de segurança somente são realizados na fase diretamente anterior a sua implantação. Normalmenteos testes são realizados por uma equipe especializada em segurança que utiliza ferramentas de terceiros para realizar diversos tipos de testes, como testes de penetração, com o objetivo de identificar falhas e vulnerabilidades no sistema desenvolvido. O problema é que essa abordagem é insuficiente e ineficiente, pois as vulnerabilidades somente serão descobertas tardiamente no processo de desenvolvimento, gerando um conjunto de bugs críticos de segurança que devem ser endereçados prioritariamente sobre novas funcionalidades, o que pode levar a atrasos no lançamento do software e a possíveis violações de segurança. Além disso, a disciplina de segurança não é considerada uma responsabilidade compartilhada de todos os envolvidos no processo de desenvolvimento, levando a uma falta de conscientização e compreensão sobre a importância da segurança por todos os envolvidos no desenvolvimento do produto de software. Segurança no modelo DevSecOps de desenvolvimento de software No modelo de desenvolvimento DevSecOps existe uma abordagem completamente diferente da disciplina segurança. Com DevSecOps a disciplina segurança é considerada parte integrante do processo de desenvolvimento do software e permeia por todas as fases de seu ciclo de desenvolvimento, desde a ideação até sua operação e evolução. Essa mudança de paradigma coloca a disciplina de segurança como um dos pilares centrais do desenvolvimento do produto de software, fazendo com que os aspectos de segurança sejam considerados em todos os momentos. Uma das principais maneiras pelas quais o DevSecOps aborda a segurança é por meio da utilização de técnicas e ferramentas de automação. Ferramentas de automação são usadas como base para que continuamente possamos avaliar a segurança do código que está sendo desenvolvido. Essas ferramentas também servem para detectar e corrigir vulnerabilidades de segurança à medida que são encontradas. Elas incluem: Desenvolvimento de Software Seguro Marcio Quirino - 62 A. Análise estática de código B. Testes de penetração automatizados C. Monitoramento de vulnerabilidades em tempo real Outra maneira pela qual o DevSecOps endereça a segurança é por meio do envolvimento de equipes de segurança em todo o processo de desenvolvimento. Isso significa que os especialistas em segurança são incorporados às equipes de desenvolvimento e operações desde o início, em vez de serem chamados apenas no final do processo para realizar uma revisão de segurança. Essa abordagem colaborativa ajuda a identificar e resolver problemas de segurança mais cedo no processo de desenvolvimento, reduzindo o tempo e o custo associados à correção de problemas de segurança no final do ciclo de vida do software. Além disso, a abordagem DevSecOps promove a cultura de segurança em toda a organização, permitindo que todos os membros da equipe sejam responsáveis pela segurança do software, não apenas os especialistas em segurança. Isso é alcançado a partir da conscientização e do treinamento de segurança para todos os membros da equipe, bem como por meio da implementação de políticas e práticas de segurança consistentes em toda a organização. Resumindo O DevSecOps aborda a segurança de forma mais integrada e colaborativa do que os modelos tradicionais de desenvolvimento de software. A segurança é incorporada em todas as fases do ciclo de vida do software, é automatizada sempre que possível e é abordada como uma responsabilidade de toda a equipe. Essa abordagem ajuda a garantir que o software desenvolvido seja mais seguro e confiável, reduzindo o risco de violações de segurança e minimizando os custos associados à correção de problemas de segurança no final do processo de desenvolvimento. Propósito e benefícios do DevSecOps Propósito de DevSecOps O propósito é garantir que a disciplina de segurança seja integrada ao longo de todo o ciclo de vida de desenvolvimento do software, desde sua concepção até a sua operação e evolução. Mas não se restringe apenas aos aspectos técnicos utilizados no desenvolvimento dos produtos de software, DevSecOps vai além, criando uma cultura em que a segurança seja integrada em todos os aspectos e atividades das empresas. Assim, não se restringe ao aspecto técnico e se torna uma preocupação de todas as áreas e pessoas dentro das empresas. O DevSecOps também ajuda a promover a cultura de segurança dentro das organizações de desenvolvimento de software, tornando a segurança uma responsabilidade compartilhada por todos os membros da equipe. Isso pode levar a uma maior conscientização e responsabilidade em relação à segurança do software e dos dados do usuário. Benefícios de DevSecOps É notório que quando adotamos um modelo de desenvolvimento de produtos de software baseado em uma cultura e técnicas de DevSecOps vamos colher diversos benefícios. Vamos destacar alguns! 1. Redução de custos: Ao se tentar antecipar e minimizar possíveis vulnerabilidades e ameaças à segurança do software, a prática de DevSecOps tende a reduzir custos com ações corretivas e de reparação de danos, que muitas das vezes podem ser intangíveis. 2. Melhoria da qualidade do software: Pensar e integrar segurança desde o início do processo de desenvolvimento e mantendo durante todo o ciclo de vida de um software, garante a melhor qualidade do software possível, fazendo com que o software atenda aos requisitos de segurança, performance e disponibilidade. 3. Maior eficiência do processo: A automação de testes e a integração contínua permitem uma entrega mais rápida e confiável de novas funcionalidades e correções de segurança. Desenvolvimento de Software Seguro Marcio Quirino - 63 4. Maior transparência: A integração contínua de segurança no processo de desenvolvimento pode aumentar a transparência do projeto, permitindo que os desenvolvedores entendam melhor os riscos de segurança e tomem medidas preventivas. 5. Maior conformidade regulatória: O DevSecOps incorpora a conformidade com padrões e regulamentos de segurança, ajudando as organizações a cumprir os requisitos de conformidade e a evitar penalidades e multas. 6. Melhor resiliência: A adoção de práticas DevSecOps pode melhorar a resiliência do sistema, permitindo que a organização se recupere mais rapidamente de possíveis violações de segurança ou interrupções no sistema. 7. Maior visibilidade e transparência: A integração contínua de segurança no processo de desenvolvimento pode aumentar a transparência do projeto, permitindo que os desenvolvedores entendam melhor os riscos de segurança e tomem medidas preventivas. 8. Aceleração da entrega de software: Ao integrar segurança no processo de desenvolvimento, as equipes podem antecipar e resolver problemas de segurança mais rapidamente, o que pode acelerar a entrega de software. 9. Melhor gerenciamento de riscos: O DevSecOps permite uma abordagem proativa na gestão de riscos de segurança, ajudando as organizações a identificar e gerenciar melhor possíveis ameaças. 10. Maior agilidade: A incorporação de práticas DevSecOps pode melhorar a agilidade das organizações, permitindo que elas respondam rapidamente às mudanças no ambiente de segurança e às demandas do mercado. 11. Melhor reputação e confiança: Uma abordagem proativa em relação à segurança do software pode ajudar a construir uma reputação positiva e a confiança do cliente, aumentando a lealdade e a fidelidade do cliente. Em resumo, DevSecOps é uma prática que visa integrar segurança no ciclo de vida do desenvolvimento de software, com o objetivo de antecipar e minimizar possíveis vulnerabilidades e ameaças à segurança do software. A prática de integrar segurança desde o início do processo de desenvolvimento pode ajudar a reduzir custos, melhorar a qualidade do software, aumentar a transparência e acelerar a entrega do software. 2. Automação e orquestração Processo de automação e orquestraçãoA importância dos conceitos de automação e orquestração Tanto DevOps quanto DevSecOps têm como um de seus pilares a aplicação dos conceitos de automação e orquestração das atividades necessárias no desenvolvimento das soluções de software. O objetivo principal da aplicação desses conceitos é garantir que atividades rotineiras, que muitas das vezes seriam executadas por pessoas, sejam executadas pelos computadores. Exemplo Imagine que, há alguns anos, toda vez que uma nova versão de um software fosse lançada, os profissionais precisassem testar manualmente todas as funcionalidades, tanto as novas quanto as antigas. Isso era necessário para garantir que o novo desenvolvimento não afetasse as funcionalidades existentes. Nesse cenário, as empresas costumavam ter áreas com muitas pessoas responsáveis por realizar esses testes repetitivos. Esse processo era demorado, propenso a erros - afinal, dependia do trabalho humano - e extremamente ineficiente. A indústria de desenvolvimento de produtos de software precisava encontrar alternativas para melhorar esse cenário, tornando-o mais seguro, rápido e eficiente. E a solução para isso foram os conceitos de automação e orquestração. Desenvolvimento de Software Seguro Marcio Quirino - 64 Automação É fundamental para DevSecOps porque permite que tarefas repetitivas sejam efetuadas de maneira automatizada, como: realização de testes funcionais e de segurança, compilação de código, publicação de artefatos em ambientes, verificação de vulnerabilidades, provisionamento de recursos etc. A automação é importante, pois aumenta a eficiência economizando tempo e recursos, além de reduzir erros humanos. Justamente por automatizar tarefas repetitivas e garantir que sejam executadas de maneira muito mais rápida e segura, a automação permite que novas versões de uma solução de software sejam entregues de maneira mais rápida e contínua, o que é essencial para acompanhar as demandas do mercado. Orquestração É o conceito que se refere à capacidade de coordenar diferentes ferramentas e processos de automação para criar uma cadeia de eventos contínua. A orquestração é responsável por executar as tarefas programadas na sequência correta, definir dependências e gerenciar a execução em vários ambientes, garantindo que todo o processo de entrega de artefatos de software esteja integrado e funcionando de maneira contínua e eficiente. DevSecOps tem a orquestração como um de seus principais pilares, pois garante que as etapas necessárias para se garantir os critérios de segurança de um artefato de software serão executadas de maneira adequada e que o processo de análise seguirá um caminho predeterminado de acordo com o resultado das tarefas executadas. Benefícios Como principais benefícios da automação e orquestração, podemos destacar: A. Eficiência ✓ Ao aplicar técnicas e ferramentas de automação e orquestração, diversas tarefas repetitivas podem ser executadas de maneira muito mais rápida e com menor propensão a erros humanos, garantindo maior eficiência no processo de desenvolvimento de produtos de software. Além de permitir que os profissionais se concentrem em outras atividades que permitam a aceleração do desenvolvimento das entregas de funcionalidades e novos recursos. B. Mitigação de erros ✓ Por se tratar de processos automatizados e orquestrados, removendo o fator humano das atividades repetitivas, mitiga-se a possibilidade de erros eventuais causados pela má execução de uma pessoa. C. Visibilidade ✓ A orquestração fornece uma visão geral de todo o processo de desenvolvimento do produto de software, permitindo que as equipes identifiquem rapidamente possíveis problemas e tomem as ações de correção de maneira mais acelerada, garantindo assim o monitoramento de todo o pipeline do ciclo de entrega dos artefatos de software. D. Redução de custos ✓ A automação e a orquestração ajudam a reduzir os custos de desenvolvimento dos produtos de software, permitindo que as equipes realizem tarefas de maneira mais eficiente. E. Confiabilidade ✓ Aumento da confiabilidade do pipeline de entrega, garantindo que todas as etapas estejam completas antes que a próxima seja iniciada. F. Segurança ✓ A automação e a orquestração ajudam a aumentar a segurança do processo de entrega, detectando e corrigindo vulnerabilidades mais rapidamente. Desenvolvimento de Software Seguro Marcio Quirino - 65 CI/CD e DevSecOps Continuous integration (integração contínua) e continuous delivery (entrega contínua) são práticas de engenharia de software oriundas dos conceitos de automação e orquestração, que são pilares fundamentais para as abordagens DevOps e DevSecOps. As práticas e técnicas são tão essenciais que pode-se dizer que sem elas, DevOps e DevSecOps não seriam viáveis, devido aos benefícios que elas proporcionam como suporte para essas abordagens. Continuous integration (CI) É uma prática de engenharia de software que tem como objetivos: 1. Automatizar o processo de compilação, teste e implantação de código-fonte, de maneira mais rápida, eficiente e frequente possível. Essa prática foi popularizada por Martin Fowler e Kent Beck em seu livro Continuous Integration: Improving Software Quality and Reducing Risk. 2. Detectar erros o mais cedo possível no ciclo de vida do desenvolvimento de software, a partir da frequente integração da base de código-fonte pelos desenvolvedores, antes que se tornem problemas maiores e mais difíceis de corrigir. Isso é feito por meio da execução automatizada de diversas fases, desde a análise estática de código e de testes em busca de violações de estilo e outras anomalias. A CI também ajuda a facilitar a colaboração entre os membros da equipe de desenvolvimento, garantindo que o código-fonte seja frequentemente integrado ao repositório principal, permitindo que todos os desenvolvedores trabalhem a partir de uma base atualizada frequentemente. Para implementar a CI, é necessário o uso de ferramentas que permitam a automação do processo de compilação e teste do código-fonte, como: A. Jenkins, GitLab CI/CD B. Azure DevOps entre outras Além disso, é necessário que a equipe de desenvolvimento adote uma cultura de colaboração e comunicação constante para que a prática de integração contínua seja bem-sucedida, preferencialmente alinhada a uma cultura ágil. Continuous delivery (CD) É uma prática de engenharia de software que visa entregar alterações de código de forma frequente, segura e confiável. O objetivo da CD é alcançado por meio da automação do processo de entrega dos artefatos de software, incluindo testes e implantação automatizada. A CD ligeiramente difere da CI, pois se concentra na entrega confiável e automatizada de software em um ambiente de produção. No entanto, a CI é um componente fundamental da CD, já que permite aos desenvolvedores integrar suas alterações de código com frequência e detectar erros mais rapidamente, sendo assim duas práticas complementares. CI/CD e DevSecOps DevSecOps acrescenta uma dimensão de segurança à prática de CI/CD. Enquanto a integração contínua e a entrega contínua se concentram principalmente em automatizar e agilizar o processo de desenvolvimento e entrega de software, DevSecOps enfatiza a importância de incorporar práticas de segurança em todas as etapas do ciclo de vida do desenvolvimento de software. Assim, o DevSecOps adiciona controles de segurança automatizados em todas as etapas dos pipelines de CI/CD. Confira tais práticas de segurança! A. Análise estática de código-fonte B. Verificação de vulnerabilidades C. Análise de configuração de segurança Desenvolvimento de Software Seguro Marcio Quirino - 66 D. Testes de penetração automatizados Essas práticas de segurança ajudam a identificar e corrigir vulnerabilidades em um estágio inicial do desenvolvimento, garantindo que as ameaças sejam mitigadas antes dechegarem à produção. Além disso, o DevSecOps incentiva a colaboração entre equipes de segurança, desenvolvimento e operações, para garantir que os requisitos de segurança sejam considerados desde o início do processo de desenvolvimento de software. A abordagem DevSecOps também promove a implementação de controles de segurança de forma contínua e o monitoramento em tempo real de ameaças e vulnerabilidades, permitindo que as organizações respondam rapidamente a incidentes de segurança e reduzam o risco geral de segurança de seus sistemas de software. Scripts e estruturas de testes Scripts e estruturas de teste são fundamentais para o DevSecOps, pois são as ferramentas usadas na integração e entrega contínua para avaliar os parâmetros de segurança. Eles desempenham um papel crucial na garantia da qualidade e segurança do software em desenvolvimento. Vamos conhecê-las! Scripts São arquivos que contêm uma sequência de comandos e instruções que podem ser interpretados e executados por um programa ou sistema operacional. Esses comandos e instruções são escritos em uma linguagem de script, que é uma linguagem de programação projetada para ser facilmente legível por humanos e executável por computadores. Os scripts são usados para automatizar tarefas e processos repetitivos em sistemas de computador, como instalação de software, configuração do sistema, gerenciamento de arquivos e pastas, entre outros. No contexto de DevSecOps, os scripts são comumente usados para realizar testes de segurança automatizados e para integrar as ferramentas de segurança ao pipeline de entrega contínua. Scripts são importantes no contexto de DevSecOps porque permitem automatizar tarefas repetitivas e complexas, melhorando a eficiência do processo de desenvolvimento e segurança do produto de software. Com o aumento da complexidade dos sistemas de software, há uma crescente necessidade de testes automatizados para garantir que os sistemas estejam em conformidade com os requisitos de segurança. Dentre as funções que os scripts de teste desempenham, podemos enumerar: 1. Permitir que os testes sejam executados de forma repetitiva e consistente, garantindo que as vulnerabilidades de segurança sejam identificadas e corrigidas com mais eficiência. 2. Facilitar a integração contínua e na entrega contínua, permitindo que os testes sejam executados automaticamente sempre que houver uma nova atualização no software. Isso é essencial para garantir que as mudanças feitas no código não introduzam novas vulnerabilidades e que o software continue seguro. 3. Automatizar tarefas de segurança, como a análise estática de código e a verificação de configuração de segurança, garantindo que o software seja desenvolvido de acordo com as práticas recomendadas de segurança. Isso ajuda a reduzir o tempo gasto em tarefas manuais e aumenta a eficiência geral do processo de segurança. Em resumo, os scripts são importantes no contexto de DevSecOps porque permitem a automação de tarefas de segurança e testes, melhorando a eficiência e a eficácia do processo de desenvolvimento e segurança de software. Estrutura de testes São conjuntos de ferramentas, bibliotecas e convenções que fornecem uma estrutura padronizada para criar e executar testes automatizados de software. As estruturas de teste fornecem um ambiente Desenvolvimento de Software Seguro Marcio Quirino - 67 consistente para testes, permitindo que desenvolvedores e testadores criem e executem testes de maneira mais simples e rápida. As estruturas de teste são uma parte fundamental do processo de desenvolvimento de software, especialmente em um ambiente DevSecOps, em que a automação e a orquestração de testes são essenciais para garantir a segurança e qualidade do software. As estruturas de teste podem ser usadas para testar desde pequenos módulos de código até sistemas inteiros, garantindo que o software seja testado em todas as etapas do processo de desenvolvimento. Existem várias estruturas de teste disponíveis para diferentes linguagens de programação e tecnologias. Conheça agora as estruturas de teste mais populares! A. JUnit para Java B. NUnit para .NET C. PyTest para Python D. Jasmine para JavaScript O uso de estruturas de teste ajuda a garantir que o software seja testado de maneira consistente e confiável, o que pode aumentar a eficiência do processo de desenvolvimento e melhorar a qualidade do software final. Existem diversas estruturas de testes que são importantes para a implementação de DevSecOps. Vejamos algumas das mais relevantes! A. Testes de unidade ✓ Verificam se cada componente do software está funcionando corretamente de forma isolada, ou seja, testam unidades individuais de código. B. Testes de integração ✓ Garantem que diferentes módulos ou componentes do software trabalhem juntos corretamente, integrando as diferentes partes do sistema. C. Testes de aceitação ✓ Validam se o software atende aos requisitos do usuário e se funciona conforme o esperado. D. Testes de performance ✓ Medem o desempenho do software em relação a tempos de resposta, uso de recursos, capacidade de carga, entre outros aspectos. E. Testes de segurança ✓ Verificam a existência de vulnerabilidades no software, como falhas de autenticação, injeção de código, cross-site scripting, entre outras. F. Testes de conformidade ✓ Avaliam se o software está em conformidade com leis, normas e regulamentos aplicáveis, como a Lei Geral de Proteção de Dados (LGPD), PCI-DSS, HIPAA, entre outros. É importante destacar que a escolha das estruturas de testes depende das necessidades específicas de cada projeto e das características do software em questão. 3. Modelagem de Ameaças, Controles e Resposta a Incidentes Conceitos de modelagem de ameaças Modelagem de ameaças É uma técnica utilizada em DevSecOps para identificação e avaliação de possíveis ameaças à segurança em um sistema ou aplicação. A técnica busca a criação de um modelo que represente todos os Desenvolvimento de Software Seguro Marcio Quirino - 68 componentes e processos do sistema e permita avaliar as possíveis ameaças que podem surgir em cada etapa. A modelagem de ameaças é essencial no DevSecOps, pois ajuda a identificar antecipadamente possíveis vulnerabilidades e ameaças de segurança. Isso ajuda a reduzir o risco de serem explorados por pessoas mal-intencionadas. Ao aplicar essa técnica, é possível descobrir e compreender melhor os pontos fracos do sistema, permitindo tomar medidas para corrigir ou reduzir essas vulnerabilidades. A modelagem de ameaças pode e deve ser realizada nas diversas etapas do ciclo de vida do desenvolvimento de software, desde a concepção até a entrega em produção da solução. Além disso, essa técnica pode ser integrada com outras práticas de segurança, como testes de penetração e análise de estática de código-fonte, fornecendo assim uma visão ainda mais abrangente das possíveis ameaças à segurança. Existem diversas ameaças que um sistema pode sofrer. Vamos entendê-las! 1. Spoofing ✓ É o tipo de ataque em que uma pessoa ou um sistema assume a identidade de outra pessoa ou organização por meio da falsificação de dados para enganar uma vítima e assim ganhar sua confiança para ter acesso e realizar ações maliciosas. Um exemplo de spoofing é o ataque phishing, em que o atacante envia um e-mail fingindo ser uma empresa ou indivíduo, a fim de obter informações sensíveis de sua vítima. 2. Tampering ✓ É a ameaça com o objetivo de alterar dados, códigos ou configurações de um sistema criando assim uma vulnerabilidade para que o atacante explore e atinja seu objetivo que pode ser o roubo de dados ou até mesmo prejudicar o funcionamento do sistema. 3. Repudiation ✓ É uma ameaça à integridade dos dados dos sistemas. Ocorre normalmente quando um usuário ou sistema nega ter executado uma ação ou transação específica, e o sistemaafetado não possui mecanismos que garantam a rastreabilidade das ações dos usuários para garantir a autenticidade das transações realizadas. 4. Exploitability ✓ É a ameaça em que o atacante explora uma vulnerabilidade do sistema por meio da injeção de códigos que possam comprometer a integridade do sistema, permitindo assim acesso indevido, utilizando técnicas como SQL Injection, Buffer Overflow etc. Para tentar prever, monitorar e impedir que ameaças sejam exploradas existem diversas metodologias e ferramentas disponíveis para a modelagem de ameaças, vejamos! A. Dread ✓ (Damage, reproducibility, exploitability, affected users and discoverability): Tem como objetivo a análise de risco qualitativa para priorizar as ameaças com base em cinco critérios que compõem a sua sigla, sendo muito utilizada para avaliar a gravidade das ameaças. As ameaças são então categorizadas em uma escala entre 5 e 15 e, com base na nota que o item tiver, ele pode ser considerado de alto, médio ou baixo risco. B. Stride ✓ (Spoofing, tampering, repudiation, information disclosure, denial of service e elevation of privilege): Tem como objetivo identificar ameaças em cada um dos seis tipos de ataques que compõem a sua sigla, sendo uma metodologia amplamente utilizada em grandes corporações provedoras de soluções em tecnologia, como a Microsoft. C. Pasta ✓ (Process for attack simulation and threat analysis): Tem como objetivo ter amplitude na análise das ameaças através de um contexto mais amplo que a Dread e a Strike, Desenvolvimento de Software Seguro Marcio Quirino - 69 considerando fatores como os atores das ameaças, ativos, vulnerabilidades e impacto potencial caso uma vulnerabilidade seja explorada. D. Trike ✓ (Threats, risks, identities, knowledge and environment): É um processo de modelagem de ameaças de código aberto e tem como objetivo analisar ameaças baseada no processo de auditoria de segurança cibernética. Cada metodologia tem sua própria abordagem e técnica, mas todas compartilham o objetivo comum de identificar e mitigar ameaças à segurança em sistemas e aplicações. Controles de segurança e resposta a incidentes Controles de seguranças São medidas que devem ser implementadas para mitigar riscos e proteger sistemas contra possíveis ameaças e vulnerabilidades. Os principais controles de segurança conhecidos são regidos por normas internacionais. São elas: 1. ISO/IEC 27001:2013 ✓ Trata do tema de sistema de gestão de segurança da informação. 2. SO/IEC 27002/2022 ✓ Trata do tema segurança da informação, cibersegurança e proteção de privacidade – Controles de segurança da informação. 3. ISO/IEC 27005/2018 ✓ Trata do tema gestão de risco de segurança da informação. 4. ISO/IEC 27017/2015 ✓ Trata do tema código de prática para segurança da informação em nuvem. Outras normas também são amplamente difundidas e implementadas pelas empresas com o objetivo de desenvolver e implementar camadas adicionais de segurança aos sistemas, podendo destacar a norma Nist SP 800-53, que determina uma estrutura de controle de segurança desenvolvida pelo Instituto Nacional de Padrões e Tecnologia (NIST) dos Estados Unidos e a CIS Controls, que á uma lista com 20 controles de segurança desenvolvida pelo Center for Internet Security (CIS). Observe alguns exemplos de controles de segurança! A. Controle de acesso ✓ Todo sistema que gerencia dados sensíveis deve ter mecanismos de autenticação, autorização e criptografia, limitando o acesso ao sistema e seus dados apenas a pessoas autorizadas. Isso é mandatório. B. Monitoramento ✓ Todo sistema deve ter implementado mecanismos de armazenamento de log para seu monitoramento, permitindo assim sua análise e detecção de eventos suspeitos de exploração de possíveis vulnerabilidades. C. Backup e recuperação ✓ Mecanismos de backup e recuperação devem ser implementados para garantir disponibilidade e integridade das informações críticas dos sistemas. D. Controle de segurança de infraestrutura ✓ Todo sistema deve utilizar firewalls e mecanismos de detecção de intrusões de rede, proteção contra malwares e ameaças externas. Planejamento de resposta a incidentes Parte fundamental da gestão de segurança da informação, o planejamento de resposta a incidentes apresenta o plano de ação para tratar incidentes de segurança, caso ocorram. Tem como objetivo minimizar os danos causados pelo incidente, restaurar o pleno funcionamento dos sistemas afetados o mais rápido Desenvolvimento de Software Seguro Marcio Quirino - 70 possível, além de investigar a causa raiz que permitiu que o incidente ocorresse, identificando solução e melhorias nos processos afetados para garantir que o incidente não ocorra novamente no futuro. As principais normas que regem o tema de resposta a incidentes incluem: 1. ISSO/IEC 279035 ✓ Information Technology – Security Techniques – Information Security Incident Management 2. NIST SP 800-61r2 ✓ Computer Security Incident Handling Guide 3. SANS Institute ✓ Incident handling Step-by-Step Guide Todas as normas determinam um conjunto de técnicas e planos para o a gestão efetiva de incidentes para as empresas. Mas todas têm em comum um conjunto de ações que devem ser contempladas em seus planos. Confira! A. Notificação e comunicação ✓ Procedimento para determinar quais pessoas e áreas devem ser notificadas e comunicadas na ocorrência de um incidente, e como essa comunicação deve ser realizada para as partes interessadas (funcionários, clientes, reguladores etc.). B. Identificação e isolamento ✓ Procedimento para que seja realizada a identificação dos sistemas afetados pelo incidente e o pleno isolamento destes para que outros sistemas não sejam afetados, com o objetivo de limitar o impacto do incidente. C. Recuperação de desastres ✓ Procedimento para restaurar as operações normais do negócio alinhado a procedimento coleta, análise e preservação de evidências do incidente para ações de prevenção futura. 4. Conformidade e governança Práticas em segurança da informação Conceitos de conformidade e governança Conheça agora os conceitos fundamentais de segurança da informação! A. Conformidade ✓ Refere-se ao cumprimento das leis, regulamentos e padrões estabelecidos com o objetivo de garantir a segurança dos dados e informações. B. Governança ✓ Trata do conjunto de processos, políticas, normas e diretrizes que devem ser utilizados para gerenciar e controlar a segurança da informação de uma organização. Esses conceitos são complementares, e para sua adequada implementação são necessários: • Estabelecimento de processos claros e bem definidos • Definição de papéis e responsabilidades • Plena comunicação dentro da organização Conformidade e governança possuem normas que indicam quais são os mecanismos e como deve ser feita a implementação nas empresas, tendo como referência a norma ISO/IEC 27001 – Sistema de gestão de segurança da informação e a ISO/IEC 27002 – Segurança da informação, cibersegurança e proteção de privacidade – Controles de segurança da informação, COBIT (Control Objectives for Information and Related Technology), ISO 38500 – Governança de TI e ITIL (Information Technology Infrastructure Library). Adicionalmente temos a Lei Geral de Proteção de Dados brasileira, que deve ser observada e atendida em sua plenitude. Desenvolvimento de Software Seguro Marcio Quirino - 71 A análise e os métodos de conformidade aplicáveis em cada empresa devem levar em consideração o contexto de negócio que ela está inserida. Uma empresa que atua no mercado financeiro terá um conjunto de regulação a ser atendido, diferente de uma empresa que atua na indústria de óleo e gás, que terá outro conjunto de regulação. Algumas regras serão comuns a todos os contextos de negócio e certos mecanismos serão comuns a todos. Observe alguns exemplos de mecanismos de conformidade!57 Família ISO 27000 ............................................................................................................................... 57 ISO/IEC 15288 ..................................................................................................................................... 58 ISO/IEC 16085 ..................................................................................................................................... 58 ISO/IEC 20004 ..................................................................................................................................... 58 ISO/IEC 23643 ..................................................................................................................................... 58 Considerações finais ................................................................................................................................ 58 Explore + .................................................................................................................................................. 59 Referências .............................................................................................................................................. 59 Desenvolvimento de Software Seguro Marcio Quirino - 4 Emprego DevSecOps no Ciclo de Vida do Software .......................................................................... 60 Introdução ................................................................................................................................................ 60 1. Segurança no ciclo de vida do software ................................................................................ 60 Segurança: Modelo tradicional x DevOps ................................................................................................ 60 Ciclo de vida de software ..................................................................................................................... 60 Segurança no modelo tradicional de desenvolvimento de software ..................................................... 61 Propósito e benefícios do DevSecOps ..................................................................................................... 62 Propósito de DevSecOps ..................................................................................................................... 62 Benefícios de DevSecOps.................................................................................................................... 62 2. Automação e orquestração .................................................................................................... 63 Processo de automação e orquestração .................................................................................................. 63 A importância dos conceitos de automação e orquestração ................................................................ 63 Automação............................................................................................................................. 64 Orquestração ......................................................................................................................... 64 Benefícios .............................................................................................................................. 64 CI/CD e DevSecOps ................................................................................................................................ 65 Continuous integration (CI)................................................................................................................... 65 Continuous delivery (CD) ..................................................................................................................... 65 CI/CD e DevSecOps............................................................................................................................. 65 Scripts e estruturas de testes ................................................................................................................... 66 Scripts .................................................................................................................................................. 66 Estrutura de testes ............................................................................................................................... 66 3. Modelagem de Ameaças, Controles e Resposta a Incidentes ............................................. 67 Conceitos de modelagem de ameaças .................................................................................................... 67 Modelagem de ameaças ...................................................................................................................... 67 Controles de segurança e resposta a incidentes...................................................................................... 69 Controles de seguranças...................................................................................................................... 69 Planejamento de resposta a incidentes ................................................................................................ 69 4. Conformidade e governança .................................................................................................. 70 Práticas em segurança da informação ..................................................................................................... 70 Conceitos de conformidade e governança ........................................................................................... 70 Normas e diretrizes para segurança da informação ................................................................................. 71 Regulamentos e padrões de segurança ............................................................................................... 71 Auditoria de segurança: monitorando a proteção dos sistemas ............................................................... 73 Conceitos de auditoria e monitoramento .............................................................................................. 73 Considerações finais ................................................................................................................................ 73 Explore + .................................................................................................................................................. 74 Referências .............................................................................................................................................. 74 Desenvolvimento de Software Seguro Marcio Quirino - 5 Desenvolvimento de Software Seguro Princípios de Software Seguro Propósito Com a popularidade de áreas como a ciência de dados, aprendizado de máquina, Big Data e inteligência de negócios, houve um aumento significativo de garantir a segurança dos dados, afinal de contas, eles são a matéria-prima para essas áreas. Nesse sentido, é importante conhecer os vários aspectos que devem estar presentes em um software seguro, pois é um assunto extremamente atual e muito valorizado no mercado de trabalho. Objetivos 1. Reconhecer a relação entre os princípios de segurança e o software seguro. 2. Identificar os princípios de design seguro de software. 3. Reconhecer os elementos da cadeia de suprimentos. Introdução Cada vez mais, geramos e consumimos dados. O simples ato de fazer uma compra, podendo ser on-line ou em uma loja, já produz uma grande quantidade de dados que podem revelar informações sobre nossas preferências e que podem ser explorados por profissionais de vendas para incentivar o aumento do consumo personalizado. Em outras situações, os dados podem trazer informações importantes sobre a situação de empresas que podem beneficiar algumas pessoas que tenham acesso a eles e prejudicar muitas outras. Então, não há dúvidas de1. PCI DSS ✓ Padrão de segurança de dados do setor de cartões de pagamento. É um padrão que se aplica a empresas que vão ter algum processo de negócio de pagamento por cartões de crédito e/ou débito. Ele define os requisitos de segurança que as empresas devem seguir ao processar, armazenar ou transmitir dados de cartão de pagamento. 2. SOC 2 ✓ Service Organization Control 2 é um padrão de segurança que define as práticas recomendadas de segurança da informação para empresas que proveem serviços de computação em nuvem para outras empresas. A governança apresenta também diversos mecanismos que devem ser considerados para sua implementação com o objetivo de garantir efetividade, eficiência e segurança das operações. Vejamos alguns dos principais mecanismos de governança! 1. Gerenciamento de risco ✓ Identificação, avaliação e tratamento dos riscos que podem afetar a empresa, levando-se em consideração fatores, como: probabilidade, impacto, vulnerabilidade e ameaças. 2. Controles internos ✓ Implementação de controles internos para garantir a integridade das operações, prevenção de fraudes e erros, proteção de ativos e cumprimento de regulamentações. 3. Compliance ✓ Adoção de um programa de compliance que permita a empresa cumprir com as leis, regulamentações e políticas internas. 4. Responsabilidade corporativa ✓ Promoção de uma cultura de responsabilidade corporativa, que envolve o comprometimento com a ética, integridade e transparência nos negócios. Normas e diretrizes para segurança da informação Regulamentos e padrões de segurança Durante todo o desenvolvimento do conteúdo, citamos diversos regulamentos e padrões que ajudam empresas a se prepararem para lidar com riscos e ameaças de segurança. Regulamentos e padrões de segurança são documentos estabelecidos por governos e organizações com o objetivo de definir requisitos e diretrizes de segurança que as empresas devem seguir, fornecendo um conjunto de regras, normas técnicas e práticas recomendadas para garantir que as empresas implementem medidas de segurança adequadas para proteger operações, sistemas e dados. É essencial lembrar que diferentes contextos de negócio em uma empresa estão sujeitos a regulamentos e padrões específicos. Por esse motivo, é crucial ter processos de negócio claramente definidos. A partir dessa definição, é possível construir ações para mitigar riscos de segurança da informação. A vantagem de se aplicar os padrões de segurança é que as empresas podem implementar um conjunto de práticas e técnicas que são amplamente difundidas e reconhecidas pela indústria como eficazes nos temas que abordam. Desenvolvimento de Software Seguro Marcio Quirino - 72 Além disso, implementando metodologias, mecanismos e práticas determinadas nos padrões de segurança garante-se que os processos de negócio e sistemas da empresa estão aderentes à prática de mercado, o que gera maior segurança e confiabilidade das empresas com seus clientes. Confira aqui um breve resumo das principais normas e regulações que são amplamente conhecidas pelo mercado: 1. ISO 27001: ✓ Norma que define os requisitos para estabelecer, implementar, manter e melhorar continuamente um sistema de gestão de segurança da informação (SGSI). 2. NIST SP 800-53: ✓ Norma, publicada pelo National Institute of Standards and Technology (NIST), que fornece um conjunto abrangente de controles de segurança da informação para as organizações dos EUA. 3. GDPR: ✓ Regulamento Geral de Proteção de Dados da União Europeia, o qual define as regras para a proteção de dados pessoais dos cidadãos da UE. 4. LGPD: ✓ Lei Geral de Proteção de Dados, lei brasileira que estabelece as regras para coleta, armazenamento, tratamento e compartilhamento dos dados pessoais de indivíduos. 5. PCI DSS: ✓ Padrão de Segurança de Dados do Setor de Pagamento, que é um conjunto de requisitos de segurança para empresas que processam transações com cartões de crédito. 6. HIPAA: ✓ Lei de Portabilidade e Responsabilidade do Seguro Saúde, que é um conjunto de normas de segurança da informação para a proteção de dados de saúde nos Estados Unidos. 7. SOX: ✓ Lei Sarbanes-Oxley, lei federal dos EUA que estabelece requisitos para a contabilidade e a divulgação de informações financeiras. 8. COBIT: ✓ Controle de Objetivos para Informação e Tecnologia Relacionada, que é um modelo de governança de TI usado para ajudar as empresas a gerenciar e proteger seus recursos de informação. 9. ITIL: ✓ Biblioteca de Infraestrutura de Tecnologia da Informação (ITIL) é um conjunto de práticas recomendadas para a gestão de serviços de TI. 10. ISO 22301: ✓ Norma que define os requisitos para um Sistema de Gestão de Continuidade de Negócios (SGCN) para ajudar as empresas a se prepararem para lidar com interrupções e manter as operações em caso de desastres. 11. ISO 27002: ✓ Estabelece um conjunto de controles de segurança da informação que podem ser implementados por organizações de qualquer porte ou setor. 12. ISO 27017: ✓ Fornece diretrizes específicas para a segurança da informação em nuvem. 13. ISO 27018: ✓ Estabelece um conjunto de diretrizes para proteção de informações pessoais em ambientes de computação em nuvem pública. 14. ISO 27701: ✓ Trata dos requisitos e orientações para um sistema de gestão de privacidade da informação (SGPI). 15. ISO 22301: ✓ Estabelece requisitos para um sistema de gestão de continuidade de negócios (SGCN). Desenvolvimento de Software Seguro Marcio Quirino - 73 16. ISO 20000: ✓ Estabelece requisitos para um sistema de gestão de serviços de TI (SGSTI). 17. ISA/IEC 62443: ✓ Norma que é usada para proteger sistemas de controle industrial contra ameaças cibernéticas. Auditoria de segurança: monitorando a proteção dos sistemas Conceitos de auditoria e monitoramento Acompanhe a definição desses conceitos! A. Auditoria ✓ É um processo de avaliação das atividades e processos de uma organização ou sistema para garantir a conformidade com normas e procedimentos estabelecidos, bem como identificar pontos de melhoria e riscos potenciais. B. Monitoramento ✓ É uma atividade contínua e sistemática que tem como objetivo avaliar o desempenho da empresa em relação a suas metas e objetivos, bem como verificar se políticas, processos e controles estão implementados e operando de maneira adequada. Tanto auditoria quanto o monitoramento podem ser realizados de forma interna ou externa, sendo executadas por profissionais especializados capazes de fazer uma avaliação independente e imparcial da eficácia e eficiência dos controles e procedimentos internos da empresa. Em ambos os casos os resultados são documentos e relatórios que devem apontar os pontos de aderência e os pontos de falha de adoção de normas e procedimentos a serem utilizados para melhorar a conformidade, a governança e a gestão de riscos das empresas. Existem diferentes modelos de auditoria e monitoramento que as empresas podem adotar, como: 1. Auditoria interna: Realizada por uma equipe interna da empresa para avaliar o cumprimento de políticas, normas e procedimentos de segurança. 2. Auditoria externa: Realizada por uma empresa terceirizada ou por um auditor independente para avaliar a eficácia dos controles de segurança da empresa. 3. Monitoramento de eventos de segurança: Consiste na coleta e análise de informações de logs de sistemas, redes e aplicativos para identificar atividades suspeitas e possíveis violações de segurança. 4. Monitoramento de rede: Consiste no monitoramento constante de tráfego de rede para identificar possíveis ameaças à segurança. 5. Testes de penetração: Consiste na simulação de ataques cibernéticos para avaliar a segurança da infraestrutura de TI da empresa. 6. Avaliação de conformidade: Consiste na avaliação regular da conformidade da empresa com padrões e normas de segurança, como PCI-DSS,ISO 27001, entre outros. 7. Auditoria de privacidade: Consiste na avaliação da conformidade da empresa com leis e regulamentos de privacidade, como GDPR e LGPD. Considerações finais Chegando aqui, certamente, você teve uma boa base para determinar o que é DevSecOps e entender o porquê de essa prática de engenharia de software ser tão importante para acelerar a entrega de um software cada vez mais seguro. Além disso, compreendeu que riscos e ameaças não são apenas do ponto de vista técnico, mas também do ponto de vista pessoal. Entendeu que existem diversas normas e padrões a serem adotados para garantir que os riscos de ameaças e vulnerabilidades sejam mitigados, diminuindo assim o dano potencial desses riscos. Desenvolvimento de Software Seguro Marcio Quirino - 74 Neste conteúdo, foi possível conferir a importância de se ter os processos de negócio que sua empresa atua bem mapeados, a fim de determinar de maneira clara quais regulações, normas e padrões devem ser implementados, juntamente com processos e governança claros para garantir que essas normas sejam devidamente atendidas. Lembre-se ainda que auditoria e monitoramento são benéficos ao negócio, pois evidenciam de maneira proativa possíveis pontos de vulnerabilidade e melhoria. Agora, você é mais do que capaz de identificar como o DevSecOps pode potencializar a segurança dos seus produtos de software e entender como ter uma cultura com foco em segurança pode ajudar a alavancar ainda mais o potencial do seu negócio. Esperamos que tenha tido um bom proveito na aplicação desse conhecimento! Explore + Confira as indicações de leitura que separamos especialmente para você! DevSecOps: A Comprehensive Guide, artigo disponível no portal Owasp. Vale conferir! DevSecOps: Shifting Security Left with Automation, artigo disponível no portal Red Hat. Imperdível! Referências ADKINS, H. et al. Building Secure and Reliable Systems: Best Practices for Designing, Implementing, and Maintaining Systems. 1. ed. Sebastopol: O'Reilly Media, 2020. BRASIL. Lei nº 13.709, de 14 de agosto de 2018. Lei Geral de Proteção de Dados Pessoais (LGPD). Brasília, 2018. CRISPIN, L.; GREGORY, J. Agile Testing: A Practical Guide for Testers and Agile Teams. 1. ed. Boston: Addison-Wesley Professional, 2009. HUMBLE, J.; FARLEY, D. Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation. 1. ed. Boston: Addison-Wesley Professional, 2011. ISO. ISO/IEC 27001: Information security management. Consultado na internet em: 25 maio 2023. ISO. ISO/IEC 27002: Information Technology - Security Techniques - Code of Practice for Information Security Controls. Consultado na internet em: 25 maio 2023. KIM, G. et al. The DevOps Handbook: How to Create World-Class Agility, Reliability, and Security in Technology Organizations. 1. ed. Portland: IT Revolution Press, 2016. MICROSOFT. Microsoft Security Development Lifecycle (SDL). Consultado na internet em: 25 maio 2023. NATIONAL INSTITUTE OF STANDARDS AND TECHNOLOGY. NIST. Cybersecurity Framework. Gaithersburg: NIST, 2018. NATIONAL INSTITUTE OF STANDARDS AND TECHNOLOGY. NIST. Special Publication 800-53: Security and Privacy Controls for Information Systems and Organizations. Gaithersburg: NIST, 2020. OPEN WEB APPLICATION SECURITY PROJECT. OWASP. Dread. Consultado na internet em: 25 maio 2023. PAYMENT CARD INDUSTRY DATA SECURITY STANDARD. PCI DSS. PCI Security Standards Council. Consultado na internet em: 25 maio 2023. SHOSTACK, A. Threat Modeling: Designing for Security. 1. ed. Indianapolis: Wiley Publishing, 2014.que os dados são valiosos. E o que fazemos com coisas valiosas? Protegemos para que sejam utilizadas apenas quando for necessário e para alcançarmos objetivos específicos. Nesse sentido, a segurança da informação tem um papel crucial. Mas aí vem outra questão: quem é que, de fato, torna operacional o gerenciamento da segurança dos dados? A resposta é: os diversos aplicativos de softwares. Então, fica bastante claro que precisamos garantir que um software tenha elementos de segurança que possam ser verificados, para que possa ser chamado de seguro. É exatamente esse assunto que vamos abordar neste estudo. Aqui, teremos a oportunidade de conhecer os diversos aspectos que relacionam segurança ao desenvolvimento, operação e monitoramento de software. Sem dúvidas, é uma das áreas mais “quentes” do momento e que exige muito estudo da nossa parte, mas que é muito valorizada no mercado. 1. Princípios de segurança e o software seguro Aspectos essenciais entre princípios de segurança e software seguro Facilmente, reconhecemos a noção de uma situação segura ou não. Por exemplo, você deixaria um objeto pessoal de valor de forma que qualquer um pudesse ter fácil acesso? Obviamente, não. Então, por que você deixaria os dados do sistema que você opera para qualquer um ter acesso? Provavelmente, você tem cuidado com os dados, mas, certamente, deve conhecer muitas pessoas que ainda não têm cuidados básicos. É aqui que entramos com os aspectos essenciais de segurança e como eles se relacionam com um software seguro. Desenvolvimento de Software Seguro Marcio Quirino - 6 Basicamente, os princípios de segurança são aspectos fundamentais bem conhecidos (trataremos um pouco mais adiante) que são usados para projetar e implementar sistemas seguros. Portanto, um software seguro é um elemento lógico – normalmente, chamado de sistema – que foi projetado e desenvolvido para garantir proteção contra ameaças e ataques. Nesse sentido, precisamos entender a relação entre princípios de segurança e software seguro como a relação entre um projeto de arquitetura de um prédio e sua materialização que, no nosso caso, é o desenvolvimento de software seguro. Os princípios de segurança são a base estrutural para identificar possíveis ameaças e vulnerabilidades e projetar recursos para reduzir a exposição aos riscos. De forma resumida, o software seguro deve ser construído sobre os princípios de segurança. Os princípios de segurança fundamentais para o desenvolvimento de software seguro são: A. Confidencialidade ✓ Significa que apenas pessoas autorizadas podem ter acesso aos dados. B. Integridade ✓ Garante que os dados não sejam modificados ou adulterados de maneira não autorizada. C. Disponibilidade ✓ Garante que os sistemas e dados estejam acessíveis a usuários autorizados sempre que precisam utilizá-los. D. Autenticação ✓ Garante a identificação dos usuários de um sistema antes de conceder acesso a dados. E. Autorização ✓ Garante que os usuários tenham as permissões necessárias para acessar dados ou sistemas específicos. Ou seja, a palavra mais repetida nos princípios de segurança foi “garantia”. E a ideia é exatamente esta: oferecer garantias sobre identificação, acesso e manipulação dos dados. Neste tópico, vimos a relação entre os princípios de segurança e um software seguro. Nos próximos, vamos explorar cada um desses elementos com o objetivo de criar softwares mais seguros e, portanto, menos vulneráveis a ataques. O essencial da confidencialidade Se a pessoa não tem autorização para acessar ou manipular um dado ou sistema, então deve existir um recurso que dê essa garantia. O nome desse recurso é confidencialidade. Ela é um dos elementos básicos de um software seguro, pois auxilia na proteção de dados importantes. Muitas vezes, os dados são classificados de duas formas: A. Sensíveis ✓ Podem incluir informações pessoais como nomes, endereços, números de identidade ou CPF, números de cartão de crédito e registros médicos. B. Confidenciais ✓ Referem-se a qualquer dado que deva ter acesso restrito. Normalmente, são associados a segredos comerciais, informações financeiras ou projetos de empresas e governos. No contexto de software seguro, conseguimos garantir a confidencialidade de medidas de segurança, tais como: 1. Criptografia ✓ Utiliza algoritmos específicos para transformar os dados em um formato ilegível que só pode ser decifrado usando uma chave de criptografia. Desenvolvimento de Software Seguro Marcio Quirino - 7 2. Controle de acesso ✓ Faz a limitação do acesso aos dados utilizando o princípio do menor privilégio, ou seja, o comportamento padrão é que os perfis dos usuários tenham acesso mínimo aos dados. 3. Mascaramento de dados ✓ São técnicas que trocam dados importantes por falsos. Se um software não consegue garantir a confidencialidade, ele está colocando todos os dados do sistema em risco. Isso é uma seríssima vulnerabilidade e pode trazer terríveis consequências, como roubo de identidade, violação de dados, perdas financeiras e usar uma identidade legítima para cometer crimes. A garantia da integridade Quando você escuta a palavra íntegro, lembra de quê? Provavelmente, de algo que não foi violado, ou de uma pessoa que não é corrupta. A mesma coisa se aplica para a integridade do software seguro. Ela é traduzida, na prática, como um conjunto de recursos capazes de evitar que os dados sofram alterações ou modificações sem a devida autorização. Em outras palavras, a integridade vai proteger os dados de qualquer modificação indevida. Essas modificações, quando ocorrem, são feitas através de programas mal-intencionados ou de ataques direcionados. Infelizmente, há situações em que o responsável pelo software facilita a vida dos atacantes, pois não utilizam nenhum recurso que limite o acesso aos dados, nem mesmo tem uma política de backup. Mas aí vem a pergunta: como garantir a integridade dos dados? Existem algumas ações que podemos fazer para garantir a integridade do software. Alguns exemplos concretos são: 1. Assinaturas digitais ✓ É uma técnica que valida a autenticidade e a integridade de um documento, mensagem ou software. Uma boa comparação é com uma assinatura manuscrita com reconhecimento em cartório, só que muito mais segura. 2. Assinatura de código ✓ É um método que utiliza uma assinatura digital em um programa, arquivo, atualização de software ou executável com o objetivo de garantir sua autenticidade e integridade durante a instalação e execução. 3. Controle de versão ✓ Fazem o controle das alterações de código do software no local onde eles ficam hospedados. Um exemplo de um repositório muito conhecido com essa finalidade é o GitHub. Esses repositórios possuem recursos para que os desenvolvedores identifiquem quaisquer modificações ou alterações. 4. Práticas de codificação segura ✓ Existem várias questões que devem ser tratadas em um software. Por exemplo: validação de entrada; tratamento de explícito de exceções; verificação de limites de memória para evitar ataques de estouro de buffer; controle contra ataques de injeção de SQL e controles de injeção de código de um modo geral. Tanto as assinaturas digitais como a assinatura de código nos ajudam a garantir que o software seja íntegro. No caso das assinaturas digitais, elas utilizam mecanismos de criptografia para verificar a identidade do desenvolvedor de software. Já a assinatura de código usa os certificados digitais para vincular uma assinatura digital a um código específico. Interessante, não é? Atualmente, está cada vez mais comum utilizarmos esses recursos. Isso nos ajuda a ganhar tempo, economizar recursos financeiros e, principalmente, aumentar a integridade dos dados e do software. No nosso próximo tópico, vamos abordar o aspecto de disponibilidade. Desenvolvimento de Software Seguro Marcio Quirino - 8A importância da disponibilidade Você já ouviu falar na expressão 24 por 7? Ela significa trabalhar 24 horas por dia durante os sete dias da semana. Mas, isso realmente funciona na prática? Bem, todo software precisa ter um plano de manutenção planejada, caso contrário, vai estar exposto a uma manutenção corretiva que é uma situação muito mais complicada. Por isso mesmo, precisamos estabelecer diretrizes que reduzam as chances de que situações desastrosas ocorram, como, por exemplo, as regras para acessar dados. As regras para acessar os dados de um software seguro precisam ser bem estabelecidas. Vamos ver algumas dessas regras. 1. Quais os dados que o software dá acesso. 2. Quais são os perfis que podem acessar os dados. 3. Quais são as ações associadas a cada perfil. 4. Quais são os horários que os dados podem ser acessados. 5. Quais são os horários que os dados podem ser modificados. 6. Qual a política de backup para garantir que – na eventualidade de um desastre – os dados estejam disponíveis novamente. É um fato muito importante ter consciência de que a indisponibilidade de um software pode causar sérios danos financeiros, de reputação, queda de produtividade e, em alguns casos, a exposição do risco da vida das pessoas. Exemplo Imagine os problemas causados quando os sistemas de controle de trânsito falham. Agora – no caso de uma situação mais extrema ainda –, quais são as consequências quando um sistema que leva oxigênio para mineradores de regiões subterrâneas falha? Ou seja, são situações que exigem cuidados extremos. Agora, vamos pensar um pouco sobre as causas que podem levar um sistema à indisponibilidade. Entre elas estão: • Falhas de hardware; • Problemas de conectividade de rede; • Bugs de software; • Ataques de negação de serviço (DoS). Em especial, o ataque DoS é bastante sofisticado e pode ser usado em dois níveis. No primeiro nível, os invasores sobrecarregam o sistema com um excesso de solicitações, tornando-o inacessível para usuários legítimos. Enquanto os técnicos ficam focados tentando corrigir esse problema, os invasores utilizam outros tipos de ataques para roubar ou adulterar dados. Então, nesse momento, já deve estar bem claro para nós a importância de garantir a disponibilidade de um software. Mas, o que podemos fazer para garantir essa disponibilidade? Para garantir a disponibilidade do software, as pessoas e organizações de um modo geral – sejam públicas ou privadas – devem implementar medidas, tais como: 1. Redundância de dados. 2. Versões mínimas de um software para garantir o funcionamento das atividades mais importantes. 3. Planos de recuperação de desastres. 4. Balanceamento de carga para evitar pontos únicos de falha. 5. Realizar testes regulares. 6. Fazer o monitoramento da operação do sistema por meio da análise dos dados de log. 7. Ter um plano de manutenção de sistemas bem definido. Desenvolvimento de Software Seguro Marcio Quirino - 9 8. Realizar manutenções de software com regularidade. Portanto, existem caminhos que podemos tomar para garantir a disponibilidade de um software. A questão é realizarmos um equilíbrio entre benefícios e custos. Se a disponibilidade do software é fundamental, então, devemos investir nos métodos que deem essa garantia. A seguir, vamos estudar mais dois aspectos importantes para ter um software seguro: autenticação e autorização. A importância da autenticação e autorização Os conceitos de autenticação e autorização são diferentes, mas estão fortemente relacionados. A autenticação é usada para determinar a identidade do usuário. Ou seja, ela trata do processo de verificação de um usuário ou sistema que tenta acessar um recurso ou um conjunto de dados. Existem diversas técnicas para isso. Algumas delas são: • Uma combinação de nome de usuário (login) e senha. • Autenticação biométrica que pode usar a digital, por exemplo. • Métodos de autenticação multifator: essas são mais elaboradas. Por exemplo, o usuário entra com login e senha para acessar o e-mail, mas precisa passar por uma etapa de validação de um número de celular pré-cadastrado para verificar se, de fato, a identidade é dele mesmo. Portanto, o objetivo da autenticação é bem simples: garantir que apenas usuários legítimos possam acessar o sistema e seus recursos. No caso da autorização, o objetivo é determinar quais são os recursos ou funções que um usuário legítimo pode acessar dentro de um sistema. Um software seguro utiliza a autorização associada ao perfil do cliente ao invés do indivíduo em si, pois é mais fácil gerenciar direitos e impor limites. Essas duas características – autenticação e autorização – são dois elementos que devem compor um sistema de software seguro, pois restringem o acesso de quem pode utilizar o sistema e trabalhar com os dados, além de restringirem o que o usuário pode realizar dentro do sistema. Dessa forma, vimos que os princípios de segurança são fundamentais para garantir que um software seja seguro. No próximo módulo, nós vamos estudar sobre os princípios de design seguro, ou seja, dos aspectos que devem fazer parte da arquitetura do software. Antes de avançar, faça os exercícios para fixar o conhecimento e, se for necessário, retorne para o texto para entender melhor algum conceito. 2. Princípios de design seguro de software Elementos fundamentais do design de um software seguro Os usuários de aplicativos utilizam programas prontos para atender às suas necessidades. No entanto, para chegar até esses usuários, os programadores precisam garantir que as funcionalidades estejam funcionando corretamente e que o sistema não tenha vulnerabilidades. Essa segunda parte, em especial, é muito mais desafiante do que parece! Uma vulnerabilidade nem sempre se trata de um erro de software. Pode ser, inclusive, que ela nunca se manifeste. No entanto, é um risco enorme deixá-la dentro de um sistema, seja de forma proposital – que é uma situação muito estranha! – ou por falta de planejamento de testes. É aí que entram os elementos fundamentais do design de um software seguro. Desenvolvimento de Software Seguro Marcio Quirino - 10 Quando falamos sobre design de software seguro, nos referimos ao conjunto de diretrizes que os desenvolvedores usam para projetar e desenvolver um sistema para reduzir as vulnerabilidades. Os principais princípios de design de software seguro são: A. Privilégio mínimo ▪ Significa que os usuários ou, ainda, os perfis dos usuários devam ter apenas os privilégios essenciais para realizar suas tarefas. B. Defesa em profundidade ▪ Utiliza várias camadas de segurança para proteger contra diferentes tipos de ataques. Essas camadas incluem gerenciamento de acesso, acesso condicional, autenticação por multifator, gerenciamento dos privilégios pela identidade e proteção de identidade. C. Padrões à prova de falhas ▪ Utiliza configurações padrões seguras que não dependem do usuário. D. Separação de funções ▪ É essencial fazer a segmentação de um sistema em camadas. Sendo que cada camada tem um conjunto de funções. Um dos modelos mais conhecidos de arquitetura de software é o MVC. Mais à frente, vamos abordá-lo com mais profundidade. E. Security by Design ▪ É a aplicação de boas práticas de segurança em todas as fases do ciclo de vida do desenvolvimento de software. F. Economia de mecanismo ▪ Simplificar a configuração da arquitetura do software para reduzir o potencial de erros e vulnerabilidades difíceis de serem detectadas. G. Design aberto ▪ Significa que a arquitetura do sistema possa ser revisada por outras pessoas do projeto. É uma péssima prática deixar a responsabilidade do projeto da arquitetura de um sistema para apenas um indivíduo. H. Tratamento de erros ▪ É responsabilidade dos desenvolvedores criarem mecanismos para detectar exceções e tratá-las explicitamente. Os erros “raízes” – errosda execução do programa – nunca devem ser expostos para o usuário final, pois podem ser usados para explorar vulnerabilidades. Os princípios de design de software seguro são excelentes direcionadores, para que os desenvolvedores possam criar softwares mais confiáveis e menos vulneráveis a ataques. Nos próximos tópicos, vamos explorar com mais detalhes esses princípios. Fundamentos do privilégio mínimo de um software seguro Como podemos desenvolver um software capaz de reduzir os danos que um invasor pode causar ao se passar por um usuário legítimo? Bem, uma das formas de conseguir esse resultado é conceder privilégios mínimos para cada perfil. O princípio do privilégio mínimo nos orienta a fornecer apenas o nível essencial para que o usuário realize o trabalho dele. O objetivo aqui é reduzir o risco de danos que um invasor – ser humano ou sistema – possa causar. Mas há outro benefício também no caso de o sistema ser comprometido: ser capaz de medir os danos. O ideal é sempre agir com proatividade, mas nem sempre isso é possível. Às vezes, só conseguimos atuar de forma reativa, mas, até mesmo para isso, é importante ter um caminho a seguir. Como sabemos de antemão quais são os privilégios de um determinado perfil, podemos criar mecanismos que bloqueiem a execução das atividades. O privilégio mínimo é importante para segmentar as atividades e, assim, impor restrições. Um exemplo disso ocorre com um processo de servidor da web que pode apenas fazer leitura de arquivos, ou Desenvolvimento de Software Seguro Marcio Quirino - 11 seja, não tem acesso de gravação. Na prática, isso minimiza o risco de modificações não autorizadas. Mas, como podemos implementar o privilégio mínimo em um sistema? Para implementarmos o privilégio mínimo em um sistema, precisamos ter um mapa com todas as funções e responsabilidades associadas a cada perfil de usuário. Ou seja, precisamos saber: • Quais são os processos envolvidos? • Quais os recursos e funções utilizados nesses processos? A ideia é atender à necessidade do usuário por meio de um perfil e, a partir disso, traçar os possíveis caminhos que ele pode seguir. Assim, podemos fazer um monitoramento da operação do sistema e observar se há comportamentos inadequados ou privilégios que não condizem com um determinado perfil. Resumindo O princípio do privilégio mínimo é mais um aspecto de design de software seguro, pois nos auxilia a reduzir riscos de danos e, no caso de uma invasão, nos orienta a como agir para interromper o ataque. No próximo tópico, vamos conhecer um pouco mais sobre dois princípios de design de software seguro: defesa em profundidade e padrões à prova de falhas. Defesa em profundidade e padrões à prova de falhas Esses dois princípios de projeto aumentam a segurança de um software. A ideia básica é trabalharmos com camadas semelhantes à criação de trincheiras para dificultar o avanço de um invasor. A seguir, apresentamos os dois princípios com mais detalhes. Defesa em profundidade É uma estratégia de segurança que implementa várias camadas de controles de segurança e também contramedidas para reduzir danos. Essas camadas podem incluir uma visão mais externa do sistema – a infraestrutura de rede – como também o servidor, a aplicação em si e os dados que são acessados pelo sistema. Abaixo, apresentamos uma figura que nos dá uma ideia da defesa em profundidade. Defesa em profundidade. Os padrões à prova de falhas Tratam das diversas formas para prevenir ou, pelo menos, reduzir o impacto de possíveis falhas ou erros. Entre essas técnicas, estão: • Mecanismos para detecção de erros. • Mecanismos para correção de erros. • Sistemas de backup e recuperação de dados. • Redundância de sistemas. • Técnicas de tolerância a falhas. Desenvolvimento de Software Seguro Marcio Quirino - 12 Juntos, os dois princípios dificultam a vida dos possíveis invasores. Por outro lado, precisamos ter cuidado para não inserir vulnerabilidades no sistema, pois, agora, ele está ficando mais complexo. Separação de funções e Security by Design Novamente, voltamos para a segmentação de funções. Agora, no entanto, utilizamos os princípios de separação de funções e segurança por design. Vamos ver cada um deles com mais detalhes. 1. Separação de funções ✓ Trata da divisão das principais tarefas e responsabilidades entre diferentes indivíduos ou equipes para reduzir as chances de que um invasor possa usar a identidade de um usuário legítimo e ter controle ou acesso a informações confidenciais. Portanto, a ideia é diminuir o poder dos perfis do usuário dentro do sistema. 2. Security by Design ✓ Significa aplicar as boas práticas de segurança no sistema ao longo de todo o ciclo de desenvolvimento. É importante notarmos que esses princípios não fazem parte do processo “natural” de desenvolvimento. Os desenvolvedores precisam ser orientados a trabalhar dessa forma desde o começo do projeto e ser conscientizados sobre a importância desses aspectos de segurança. Por isso mesmo, é importante investir tanto na formação técnica como na explicação para os gestores sobre as implicações de negócio associados a um sistema seguro. Economia de mecanismo, design aberto e defesa contra erros Não há dúvidas de que a segurança é um aspecto essencial para um software. O problema disso é que o efeito colateral de implementarmos esses princípios no software é aumentarmos as possibilidades de que existam vulnerabilidades. Parece contraditório, não é mesmo? Mas basta pensarmos que estamos acrescentando elementos que terão de se comunicar por meio de protocolos e que ninguém terá conhecimento total do sistema. Por isso, precisamos fazer um bom planejamento antes de iniciar uma implementação. Agora, vamos analisar três princípios que auxiliam a manter o software mais seguro, ao mesmo tempo que tentam reduzir as vulnerabilidades devido à complexidade: 1. Economia de mecanismo ▪ São práticas de implementação que desencorajam ataques ou acessos não autorizados. Por exemplo, quando fazemos a implementação de controles de acesso, mecanismos de auditoria e monitoramento e criptografia, estamos aumentando as dificuldades de um invasor. 2. O design aberto ▪ O objetivo aqui é oferecer transparência do código-fonte e, claro, da documentação para outros desenvolvedores. Em especial, para os que têm perfil de desenvolvimento de segurança com o objetivo de revisar e identificar possíveis vulnerabilidades no sistema. 3. A defesa contra erros ▪ Trata-se de mapear o funcionamento do sistema e identificar possíveis falhas. Depois disso, precisamos tratar essas exceções explicitamente e jamais exibir uma mensagem de erro do sistema para o usuário final. Também faz parte desse princípio a utilização de sistemas de backup e recuperação, redundância e princípios de projeto tolerantes a falhas. Todos os princípios que vimos auxiliam a desenvolver sistemas mais seguros, pois fazem parte da arquitetura do software, ou seja, estão ligados ao projeto e, por isso mesmo, precisam ser bem documentados e testados, pois serão a base para a implementação de outros programas. No nosso próximo módulo, vamos estudar sobre a cadeia de suprimentos de um software. Ou seja, vamos estudar sobre o impacto dos componentes de terceiros para a implementação de um software seguro. Desenvolvimento de Software Seguro Marcio Quirino - 13 3. Avaliação da cadeia de suprimentos Elementos da cadeia de suprimentos de um software seguro A expressão “cadeia de suprimentos” é bastante utilizada em problemas de logística. Normalmente, ela está associada aos diversos processos que vão desde a extração da matéria-prima até a entrega de um produto para o consumidor final. Mas, o que isso tem a ver com software seguro? Bem, no contexto de software seguro, a ideia é parecida. Precisamos lembrar que um software é composto por bibliotecas e componentes,além de usar ferramentas de desenvolvimento que são fornecidas por terceiros, ou seja, é uma cadeia de suprimentos tecnológica. Cada elemento dessa cadeia pode influenciar em relação a alguma vulnerabilidade de um sistema. É por isso que precisamos ter políticas de segurança que nos auxiliem a fazer avaliação desses itens que, também, incluem componentes de hardware. Existem vários casos conhecidos de componentes com seríssimas vulnerabilidades. Alguns exemplos são: 1. Heartbleed ✓ Trata-se de uma vulnerabilidade na biblioteca de criptografia OpenSSL. Ela facilitava a vida dos invasores de modo que pudessem ter acesso a dados confidenciais da memória de um servidor da web. 2. Spectre e Meltdown ✓ São vulnerabilidades que tiveram grande impacto na maioria dos processadores modernos. Elas, simplesmente, possibilitavam que um invasor acessasse dados confidenciais da memória de um sistema. 3. Violação de dados da Equifax ✓ Essa vulnerabilidade, em 2017, causou um prejuízo de, aproximadamente, um bilhão e meio de dólares para a empresa Equifax. A empresa sofreu uma violação de dados que possibilitou que os invasores fizessem a exposição de informações pessoais de milhões de clientes. E qual foi a causa desse problema? Devido a uma vulnerabilidade na estrutura do aplicativo web Apache Struts. 4. Spyware Pegasus ✓ É um malware desenvolvido pela empresa israelense NSO Group. Ele age de várias formas, mas, essencialmente, o objetivo é explorar vulnerabilidades em vários aplicativos de software para obter acesso ao dispositivo de um alvo e roubar dados confidenciais. Esses são apenas alguns exemplos das muitas vulnerabilidades de softwares, mas, infelizmente, é claro que existem muitos outros componentes e recursos de terceiros que podem tornar um software inseguro. Então, o que devo fazer para proteger um sistema de vulnerabilidades, de um modo geral? Investir em treinamento e estudo direcionado. Um exemplo concreto de treinamento e estudo direcionado é visitar os seguintes portais: A. OWASP Top Ten ✓ Contém as dez principais vulnerabilidades de aplicações web. Além disso, ele apresenta exemplo de como essas vulnerabilidades se manifestam na prática e o que devemos fazer para combatê-las. B. National Vulnerability Database ✓ Apresenta uma base muito extensa de vulnerabilidades de software conhecidas e o como nos proteger em relação a elas. Desenvolvimento de Software Seguro Marcio Quirino - 14 É importante ressaltar que, no mundo corporativo, esse tipo de estudo deve fazer parte de uma política de segurança formal. Nessa política, deve haver a descrição de procedimentos de estudos, monitoramento e testes que nos auxiliem a tratar com quaisquer riscos a que um sistema esteja exposto. Vulnerabilidades dos componentes de um software Podemos encontrar diversos tipos de vulnerabilidades nos componentes de um software. Como muitas dessas vulnerabilidades são bem conhecidas e documentadas, se elas não forem tratadas rapidamente, podem ser exploradas por atacantes para roubar dados e violar a segurança dos sistemas. A seguir, apresentamos algumas das vulnerabilidades mais comuns. A. Componentes desatualizados ✓ É bastante comum que os fabricantes descubram vulnerabilidades nos componentes deles e disponibilizem correções. No entanto, é obrigação do usuário fazer a atualização. Aqui, cabe, ainda, uma ressalva: sempre faça atualizações apenas de fontes oficiais, pois um atacante pode tentar enganar um usuário com uma versão atualizada falsa. B. Configuração inadequada ✓ Sistemas mal configurados ou usados com configuração padrão podem facilitar ataques de modo que um invasor obtenha acesso não autorizado. C. Injeção de código ✓ Trata-se de um ataque no qual o invasor insere um trecho de código malicioso para ser executado por um programa legítimo. A vulnerabilidade mais conhecida desse tipo é a injeção de SQL que pode permitir que um ataque acesse informações ou assuma o controle do sistema. D. Falhas de autenticação ✓ Se a autenticação de um componente aceitar senhas fracas ou criar alternativas de autenticação, novamente essa vulnerabilidade pode ser explorada para permitir que um atacante tenha acesso não autorizado. E. Quebra de autorização ✓ Se o componente de software não validar as permissões de acesso de um usuário, isso pode ser explorado para permitir que um atacante cause danos no sistema ou nos dados. F. Fragilidade de criptografia ✓ Ocorre quando um componente não faz a criptografia dos dados. Nesse caso, se um atacante tiver acesso a eles, poderá manipulá-los com facilidade. G. Não tratar a entrada de dados ✓ Se os componentes não criticarem os dados de entrada, então o sistema estará exposto a diversos tipos de ataques, como a injeção de código SQL e de outros tipos de dados que podem gerar interrupções do funcionamento do sistema. As maneiras que temos para reduzir as ocorrências dessas vulnerabilidades são: • Implementar práticas de segurança durante todo o processo de desenvolvimento do software. • Realizar testes de segurança com regularidade. • Fazer atualizações de fontes seguras. • Realizar configurações seguras. Além disso, manter-se atualizado sobre notícias relacionadas à segurança nos fóruns na internet. Avaliação e gerenciamento dos riscos Como vimos, as vulnerabilidades podem ser a porta de entrada para ataques muito sérios. Por isso mesmo, precisamos ter um bom conhecimento sobre elas para identificá-las e, sempre que possível, eliminá- las. Mas, nem sempre temos a possibilidade de agir da forma ideal. Então, é fundamental que tenhamos um Desenvolvimento de Software Seguro Marcio Quirino - 15 plano que nos permita fazer a avaliação e o gerenciamento de riscos relacionados aos programas que utilizamos. Para conseguirmos uma identificação e redução de riscos efetivos, precisamos estabelecer processos que devem estar devidamente contextualizados. Por exemplo: 1. Software desenvolvido pela própria empresa ▪ Então é necessário aplicar as práticas seguras que envolvem, inclusive, um plano de testes. 2. Software vem de outro fornecedor ▪ Então precisamos conhecer quais são os planos de manutenção, correção e atualização. Nos dois casos, precisamos de um processo formal que envolve treinamento, muito estudo e realização de simulações e testes de estresse. Ou seja, tudo isso tem o objetivo de identificar riscos potenciais, avaliar a probabilidade da ocorrência de um problema e quais são os impactos deles. Em linhas gerais, podemos formalizar uma política de avaliação e gerenciamento de riscos de software por meio das seguintes etapas: 1. Identificação de riscos ✓ Devemos listar explicitamente quais são os riscos potenciais que podem afetar o software. Dependendo do contexto, podemos tratar de riscos associados ao desenvolvimento, implantação e operação de software. 2. Análise de risco ✓ Consiste em medirmos as probabilidades reais de um risco se tornar um problema e quais os impactos que esse problema pode trazer para nós, seja no contexto pessoal ou corporativo. 3. Priorização de riscos ✓ Na sequência, precisamos estabelecer uma prioridade em relação aos riscos, apesar de que o ideal é eliminarmos a ocorrência por meio da aplicação de técnicas seguras, sempre que for possível. 4. Mitigação de riscos ✓ Aqui é que entra a implementação de medidas para reduzir ou eliminar os riscos identificados. Entre as ações que podemos tomar, estão: o A implementação de controles de acesso. o Formalizar contramedidas para evitar que o risco ocorra ou minimizar seu impacto. 5. Monitoramento e revisão de riscos ✓ Agora, precisamos fazer uma análise periódica do sistema em operação, para estudar o comportamento dele e, quando for necessário, atuarmos para combater ataques. Em resumo, é fundamental termos processos formais da avaliação e do gerenciamento de riscosde software. Além disso, é muito importante atribuir níveis de responsabilidades para os indivíduos, pois, assim, não haverá dúvidas sobre quem deve tomar qual ação sempre que houver a necessidade de atuar para garantir a confiabilidade do software. Práticas de codificação segura Estamos preocupados em entender as melhores práticas que devemos implementar ou verificar para garantir que um software seja seguro. Para garantir a segurança, precisamos reduzir a ocorrência de vulnerabilidades e ter planos formais de como agir, caso ocorra algum problema. Aqui, podemos ver algumas das principais práticas de codificação segura: A. Validação de entrada ✓ Como já vimos, os invasores podem tentar explorar as entradas de um sistema. É por isso que precisamos realizar a validação da entrada antes do sistema executar os procedimentos dele. Desenvolvimento de Software Seguro Marcio Quirino - 16 B. Tratamento de erros ✓ Muitas linguagens de programação oferecem recursos explícitos para o tratamento de exceções. O objetivo é garantir que o sistema permaneça seguro e estável, caso ocorra um erro. Além disso, ao tratarmos os erros de forma explícita, evitamos de fornecer informações sobre o software que possam ser usadas para explorar alguma vulnerabilidade. C. Autenticação segura ✓ Trata-se da utilização de técnicas que garantam políticas de senha fortes, autenticação multifator e armazenamento seguro de credenciais de autenticação. D. Controle de acesso ✓ São mecanismos associados a configurações de privilégios relacionados a perfis de usuário. E. Comunicação segura ✓ Aqui, usamos algoritmos de criptografia para garantir a segurança de qualquer comunicação entre o cliente. F. Armazenamento seguro ✓ Aqui, também precisamos criptografar os dados para impedir o acesso não autorizado, no entanto, o contexto é servidor de banco de dados. G. Uso de funções especializadas em codificação segura ✓ Qualquer funcionalidade de um sistema deve ter como base um componente confiável, ou seja, precisamos ter acesso a uma documentação de boa qualidade e ter um local oficial para realizarmos atualizações e informações. H. Atualizações regulares ✓ Como já vimos, essa prática envolve atualizar o software regularmente apenas com fontes oficiais para evitar vulnerabilidades e corrigir erros no sistema. Em resumo, ao seguir essas práticas de codificação segura, estamos reduzindo as probabilidades de exposição ao risco. Testes de vulnerabilidades do software O teste de vulnerabilidade de software é um processo de identificação de pontos fracos ou vulnerabilidades em software que podem ser explorados por invasores. Existem vários tipos de teste de vulnerabilidade que podem ser usados para identificar vulnerabilidades no software. Aqui estão alguns dos principais: A. Teste estático de segurança de software ✓ É um tipo teste que analisa o código-fonte – por isso é estático – para identificar possíveis vulnerabilidades de segurança. Basicamente, ele verifica o código em busca de padrões conhecidos de vulnerabilidades que podem ser explorados por invasores. B. Teste dinâmico de segurança de software ✓ É um tipo de teste que utiliza a execução do software para analisar o comportamento dele e tentar identificar possíveis vulnerabilidades. Aqui, precisamos enviar uma série de requisições ao software e analisar as respostas. Dessa forma, podemos analisar questões como tempo de resposta médio para a execução de uma tarefa. C. Teste interativo de segurança de software ✓ É um tipo de teste que combina os testes estáticos e dinâmicos para tentar identificar possíveis vulnerabilidades. D. Teste de penetração ✓ Nesse tipo de teste, fazemos a simulação de um ataque ao software para identificar possíveis vulnerabilidades. Como já estudamos, existem muitas vulnerabilidades conhecidas e são elas que esse tipo de teste tenta explorar para analisar o quão seguro é o software. E. Teste Fuzzing ✓ Ele gera dados de entrada aleatórios em grandes quantidades e os envia para o software para identificar possíveis vulnerabilidades, tais como estouros de buffer e ataques de injeção. Desenvolvimento de Software Seguro Marcio Quirino - 17 Por meio desses testes, podemos minimizar os riscos de ficarmos expostos a vulnerabilidades. Mas, obviamente, é necessário fazermos atualizações constantes, pois os invasores são criativos para explorar vulnerabilidades. Tão importante quanto todas as práticas, testes e técnicas que estudamos é a conscientização de gestores, usuários e desenvolvedores sobre a importância de desenvolver e usar um software seguro. 4. Conclusão Considerações finais Estudamos sobres os princípios de software seguro. Aprendemos que esses princípios devem estar presentes desde a concepção do projeto do software até o monitoramento da operação dele. Vimos ainda que existem fontes oficiais que disponibilizam conteúdo sobre vulnerabilidades bem conhecidas que nos ajudam a aprofundar o nosso conhecimento técnico para identificá-las e utilizar recursos técnicos que vão do uso de ferramentas específicas à definição de processos para eliminá-las, quando possível, ou, pelo menos, reduzir os danos que elas podem causar. Sabemos bem que a ciência e a tecnologia têm avançado a uma velocidade gigantesca. Hoje, temos acesso a diversas ferramentas e pacotes que podem ser usados para produzir coisas excelentes, como também podem ser utilizados para cometer crimes, pois, afinal de contas, são apenas ferramentas e técnicas. No centro de tudo isso sempre estará o ser humano. Por isso mesmo, é muito importante formar profissionais com forte base de conhecimento, estimular a proatividade e conscientizar sobre aspectos éticos. Dessa forma, além de alcançarmos nossos objetivos profissionais, também contribuímos para o bem-estar da sociedade e reduzimos os danos que podem ser causados por pessoas mal-intencionadas. Explore + Acesse o site oficial da Microsoft e procure por Visão geral do desenvolvimento e das operações de segurança. Lá, você aprenderá como uma das principais empresas de software do planeta trabalha para desenvolver softwares seguros. Acesse o site oficial do OWASP. Essa é uma leitura obrigatória para um profissional que trabalha ou deseja trabalhar com desenvolvimento de software seguro. Procure pelo termo OWASP Top Ten. Acesse o site oficial do Banco de Dados Nacional de Vulnerabilidades do governo dos Estados Unidos – em inglês: National Vulnerability Database. Essa é uma leitura muito útil para um profissional que trabalha ou deseja trabalhar com desenvolvimento de software seguro. Procure pelo termo Vulnerabilities. Referências CHESS, B.; WEST, J. Secure Programming with Static Analysis. Boston: Addison-Wesley, 2007. HOWARD, M.; LEBLANC, D. Writing Secure Code. 2. ed. Microsoft Press, 2002. MCGRAW, G. Software Security: Building Security In. Irving, TX: Pearson Education Inc., 2006. PRESSMAN, R. S. Engenharia de Software. 6. ed. São Paulo: McGraw Hill, 2006. SOMMERVILLE, I. Engenharia de Software. 6. ed. São Paulo: Pearson Addison Wesley, 2005. VIEGA, J.; MCGRAW, G. Building Secure Software: How to Avoid Security Problems the Right Way. Boston: Addison-Wesley, 2002. Desenvolvimento de Software Seguro Marcio Quirino - 18 Questões de Implementação Para Software Seguro Propósito O conhecimento das diversas técnicas, ferramentas, procedimentos e protocolos de implementação para um software seguro é importante para garantir a segurança dos dados, sendo esta uma das áreas com grande demanda no mercado, em especial, de empresas que usam dados estratégicos para realizar a tomada de decisão. Objetivos • Reconhecer a importância da validação de entrada. • Analisar o processamento de dados com segurança. • Identificar o processo de chamada de outros programas. • Analisar o envio da saída. Introdução Se você utilizaum sistema bancário para gerenciar suas finanças, certamente não gostaria que outras pessoas tivessem acesso aos seus dados, pois isso poderia gerar grandes transtornos. Temos diversas outras situações nas quais precisamos de garantias de segurança. As aplicações que oferecem essa característica são chamadas de software seguro. No entanto, não é uma tarefa tão simples construir sistemas seguros. Uma das grandes dificuldades para construir um sistema seguro é ter um conhecimento multidisciplinar. Ou seja, além de dominar uma linguagem de programação em si, é preciso também aplicar algoritmos de criptografia, protocolos de segurança e mecanismos de controle. Temos ainda que acompanhar os avanços na área de segurança e as atualizações feitas pelos fornecedores oficiais, sempre que estes detectam alguma vulnerabilidade nos sistemas ou fazem melhorias, para reduzir os riscos de invasões bem-sucedidas. Um sistema, basicamente, tem quatro fases de tratamento dos dados: entrada, processamento, chamada a outros sistemas e geração da saída. Para cada uma dessas etapas, precisamos aplicar um tipo de tratamento que, novamente, envolve diversas ações. Além de esse assunto ser extremamente interessante, também vem sendo muito requisitado no mercado e gera alta empregabilidade. Em especial, com as novas tecnologias se popularizando e as técnicas de inteligência artificial se tornando mais presente nas nossas vidas, o conhecimento sobre software seguro é um grande diferencial para o profissional da área. 1. Validação de entrada A parte mais básica de qualquer software é o processo de entrada. Nos casos mais simples, precisamos realizar duas ações: 1. Entrar com o login de usuário válido. 2. Digitar a senha. Depois de validar as credenciais do usuário, muitos sistemas fazem testes para verificar se é uma pessoa e não um robô (programa) que está tentando invadir o sistema. Vejamos um exemplo! Desenvolvimento de Software Seguro Marcio Quirino - 19 Protótipo do aspecto geral da etapa de entrada no sistema. Além disso, alguns sistemas exibem diversas imagens para garantir que é um ser humano que está entrando no sistema. E ainda há casos mais elaborados! A validação segura de entrada de software é um aspecto crítico do desenvolvimento de aplicativos de software seguros. Verificação e validação Alguns autores distinguem verificação e validação. Observe! A. Verificação ✓ Processo de avaliação de um software para determinar se ele atende aos requisitos especificados e se foi implementado corretamente. B. Validação ✓ Processo de avaliação de um sistema para garantir que ele atenda às necessidades de seus usuários e às partes envolvidas. Apesar de haver semelhanças entre os conceitos, ambos se diferenciam de uma forma muito simples: Aquele conceito que responde à pergunta “Fizemos o que foi solicitado pelo cliente do sistema?” é o de verificação. Mas, se a pergunta é “Desenvolvemos o software com a aplicação das melhores práticas?”, significa que estamos preocupados com eficácia e eficiência, ou seja, com o processo de validação. Vulnerabilidades na entrada de dados Até agora, falamos apenas da entrada no sistema, ou seja, do processo de autenticação. Depois que entramos, há vários pontos a serem tratados e observados – neste caso, nosso papel é o de desenvolvedor –, de modo a garantir que o usuário utilize o sistema de forma correta. Várias situações comuns podem ser testadas logo na entrada dos dados, como: Os formatos dos dados estão de acordo com o que o sistema está preparado para aceitar? Os intervalos de dados – tamanho da entrada – estão em conformidade com o que foi especificado? Existem muitas outras vulnerabilidades associadas a entrada de dados. A mais conhecida delas é a injeção de código malicioso, destacando-se o caso de injeção de código SQL. Nesse caso, o ataque funciona da seguinte maneira: o invasor entra com comandos na entrada, que traz informações sobre como é feito o processo de autenticação. A partir da leitura de um erro gerado pelo programa, o atacante entra com um comando SQL que dá acesso ao sistema e, a partir disso, consegue se passar por um usuário autêntico e, obviamente, não fará nenhuma ação positiva. A injeção de código SQL é apenas um exemplo entre muitos outros ataques bem documentados, que exploram vulnerabilidades na entrada do sistema. No entanto, existem práticas que podemos implementar para realizar uma validação segura de entrada de software, como: Desenvolvimento de Software Seguro Marcio Quirino - 20 1. Validar todas as entradas do usuário ✓ Devemos realizar essa validação tanto no cliente quanto no servidor para evitar a entrada de conteúdo ou código mal-intencionado. Exemplos concretos incluem validação de formatos de dados e controle de comprimentos de dados. 2. Usar bibliotecas de validação de entrada ✓ Atualmente, temos diversas bibliotecas para as principais linguagens de programação disponíveis que nos ajudam a fazer esse controle de validação de forma eficiente. Um exemplo concreto é o Pylit para a linguagem Python. 3. Implementar validação de entrada do lado do servidor ✓ Existe um tipo de ataque que ocorre no lado do cliente que tem como alvo o servidor. Um dos mais conhecidos é um ataque de script entre sites, normalmente, referenciado, pela sigla XSS (cross site scripting). 4. Criticar todas as entradas do usuário ✓ Antes de entrar no sistema, é necessário termos mecanismos para remover quaisquer caracteres ou conteúdo que possam ser usados para explorar vulnerabilidades de softwares. Um exemplo concreto é a remoção de tags HTML e código JavaScript. 5. Garantir a aplicação de melhores práticas para o código de validação de entrada ✓ Existem excelentes fontes de informação que explicam detalhadamente como muitos ataques funcionam e como combatê-los. Portanto, é responsabilidade do desenvolvedor aplicar essas boas práticas. No caso de corporações, é fundamental investir na capacitação de seus colaboradores. Uma excelente fonte de informação é o site do OWASP, o qual vamos explorar mais adiante. A seguir, vamos estudar as bibliotecas de validação de entrada. Bibliotecas de validação de entrada A validação ajuda a evitar vários tipos de vulnerabilidades de segurança. Porém, fazer esse trabalho sem uso de ferramentas específicas dá bastante trabalho e pode demandar muitos recursos financeiros, profissionais especializados e, ainda assim, gerar outras vulnerabilidades. Atualmente, temos a vantagem de contar com muitas bibliotecas (algumas ferramentas usam a expressão “pacotes”) que fornecem a funcionalidade de validação de entrada. Exemplos de bibliotecas Vejamos alguns exemplos de ferramentas para validação de entrada: 1. OWASP ESAPI ✓ A sigla ESAPI se refere ao termo Enterprise Security API (API de Segurança Corporativa). Basicamente, é um conjunto de bibliotecas que, entre outras funcionalidades, implementa recursos de segurança, como validação de entrada. 2. InputSanitizer ✓ Como o nome sugere, faz a sanitização para validação de entrada. Ela pode ser utilizada em diversas linguagens de programação, sendo mais comum no caso do PHP. 3. Validator.js ✓ Validação de entrada em aplicativos JavaScript. Ela oferece suporte para regras de validação de e-mail, URL e comprimento. 4. Apache Commons Validator ✓ Validação de entrada em aplicativos Java. Entre as funções de validação de entrada que ele fornece estão entradas em vários formatos, como strings, datas e números e suporte a regras de validação personalizadas. Desenvolvimento de Software Seguro Marcio Quirino - 21 5. Django Forms ✓ Validação de entradas em aplicações para os programadores de Python que trabalham com o framework Django. Entre as validações oferecidas, estão: validar a entrada e manipular os dados do formulário, campos obrigatórios, validação de e-mail e validação