Podemos definir vulnerabilidade como sendo uma fragilidade de um ativo ou grupo de ativos de TI que podem ser explorados por uma ou mais ameaças. Essa definição de vulnerabilidade vem da norma NBR ISO/IEC 27002. Você também teve acesso na nossa disciplina à definição do autor Beal (2005), que traz a vulnerabilidade como sendo uma fragilidade que poderia ser explorada por uma ameaça para concretizar um ataque.
Na disciplina, aprendemos que as vulnerabilidades podem ser classificadas como Natural, Organizacional, Física, Hardware, Software, Meios de Armazenamento, Humana ou de Comunicação.
Se focarmos nas vulnerabilidades de softwares, sendo esse um item extremamente explorado para danificar ou vazar dados, um modo para melhorar a segurança e a qualidade do desenvolvimento e dos produtos entregues é realizar atividades ou boas práticas de segurança através do ciclo de vida do software. O autor McGraw (2006), correlaciona a segurança dentro das fases do ciclo de vida da aplicação em um projeto de software.
Sabendo disso, descreva as atividades e relacione com as ações que tentam eliminar ou minimizar as vulnerabilidades em desenvolvimento de softwares.
Soluções para a tarefa
Resposta:
As atividades ou boas práticas de segurança de software descritas por McGraw usadas para eliminar ou minimizar as vulnerabilidades em desenvolvimento de softwares são:
• Casos de abuso: construir casos de abuso é relevante para realizar uma relação entre os problemas e a análise de risco. É importante observar neste momento se algum padrão de ataque se encaixa no sistema ou nos requisitos do software. Este é um bom momento para modelar cenários de vulnerabilidades que podem ser exploradas nas fases de revisão de código ou teste de penetração.
• Requisitos de segurança: estes precisam cobrir os requisitos funcionais e de segurança, casos de abuso e levantar a maior quantidade possível de dados e padrões de ataque. Nesta fase toda a necessidade de segurança do software precisa ser mapeada para garantir sua correta implementação. Um bom exemplo de requisito de segurança esta relacionado com o uso correto de criptografia para proteger dados críticos.
• Análise de risco arquitetural: complementa a análise de riscos orientada pela ISO 14971 (2007). Esta análise está relacionada com o levantamento dos riscos de segurança que podem estar presentes na arquitetura da aplicação que será construída e é uma pequena parte do processo de gerenciamento de risco que todo fabricante necessita aplicar para garantir aderência à referida norma, de acordo com (IEC 62304, 2006).
• Teste de segurança baseado em riscos: a estratégia de testes da aplicação precisa cobrir pelo menos dois tópicos principais, que são os testes dos requisitos de segurança com técnicas de teste para requisitos funcionais e testes de segurança baseados em riscos, levantados pelos casos de abuso e pela avaliação dos padrões de ataque.
• Revisão de código fonte: após a fase de codificação e antes da fase de testes, a análise de código fonte é uma boa atividade para garantir que os requisitos de segurança foram bem implementados e que as vulnerabilidades listadas na análise de casos de abuso não estão presentes no software. A revisão de código pode ser automática e manual e cada estratégia tem prós e contras. Ferramentas automatizadas não cobrem todos os cenários, por este motivo a análise manual é sempre necessária (LONG et al., 2012).
• Testes de penetração: este é um composto de técnicas e ferramentas utilizadas em conjunto para testar dinamicamente um software ou sistema contra falhas de projeto ou vulnerabilidades. Esta atividade é importante para garantir que a aplicação ou sua infraestrutura não possuam nenhum problema
potencial que possam ser explorados de uma forma particular para alterar o comportamento da aplicação em tempo de execução (MICROSOFT, 2008).
• Operação segura: é importante responsabilizar as atividades do usuário no momento da utilização do sistema de software. Ainda mais importante é manter estes dados de forma correta e protegida, para garantir que o atacante ou atividades de ataque possam ser rastreadas após qualquer tentativa, bem sucedida ou não.
Explicação:
Paginas 141, 142 do livro de SEGURANÇA E
AUDITORIA DE SISTEMAS