A necessidade de garantia de segurança de software

Atualizado: Fev 11




As vulnerabilidades de software podem resultar de falhas na plataforma de infraestrutura de um sistema, incluindo configuração incorreta de serviços, aplicativos ou outros problemas operacionais.


Um dos principais objetivos da garantia de software é reduzir essas vulnerabilidades para obter confiança na segurança do software.


Algumas décadas atrás, computadores e software eram restritos a apenas alguns campos, como pesquisa acadêmica, empresas de desenvolvimento de software, certas indústrias privadas e instituições governamentais. A expansão das necessidades de negócios alimentou a demanda por sistemas de computador e software personalizado, tornando a parte crítica da infraestrutura de uma empresa.


Os serviços automotivo, químico e de manufatura adotaram sistemas de computador por sua capacidade computacional nas fábricas, enquanto bancos e indústrias baseadas em serviços exigiam processamento de informações distribuído. Com o aumento da demanda por funcionalidade do computador, tornou-se necessário um software especializado.


A introdução de redes de computadores e da Internet fez com que essa demanda crescesse, e a tecnologia finalmente chegou a residências individuais. A interconectividade e o grande volume de informações privadas disponíveis nos servidores corporativos e na Internet levantaram preocupações sobre a segurança das informações.


Hoje, todos os sistemas de computador usam segurança de software. No entanto, quase todos os dias ouvimos falar sobre a violação desses sistemas, e a pergunta permanece: quem ou o que é o culpado? É a organização que hospeda o sistema ou a empresa que desenvolveu seu software? Além da ameaça humana interna, como podemos ter certeza de que o software é seguro?


Com tantos fatores influenciando o tempo adequado para liberar aplicativos de software, há pouca dúvida de que o necessário é um ciclo de vida de desenvolvimento de segurança dentro do ciclo de vida de desenvolvimento de software.


Modelagem de ameaças


Modelo de Segurança


Um modelo de segurança é uma especificação formal do sistema de software, suas propriedades de design, suas preocupações com segurança e as seções de código em risco. Um modelo de segurança descreve os aspectos funcionais do software para entender as operações básicas do software em cada fase do ciclo de vida do desenvolvimento.


Ao compreender as operações básicas, as organizações podem eliminar incertezas e inconsistências e garantir a robustez do software. A abstração pode ser usada para testar o desempenho de uma medida de segurança.


Da perspectiva de um desenvolvedor, o modelo de segurança pode:

  • ajudar a determinar as expectativas do comportamento do software

  • encontre erros e vulnerabilidades no design

  • encontre decisões de projeto defeituosas

  • verifique se o código atenderá às especificações

  • resolver conflitos

  • analisar como a segurança afetará os requisitos, especificações e expectativas das partes interessadas

No final de cada fase do ciclo de vida, o modelo de segurança deve ser reavaliado e atualizado à medida que as alterações são feitas.


Princípios de modelagem de ameaças


Idealmente, o software deve ser testado e todos os erros eliminados antes de ser implantado. No entanto, o teste exaustivo do software é impraticável e não é econômico, portanto, testes baseados em risco podem ser empregados.


O teste baseado em risco identifica e prioriza riscos com base nos níveis de ameaça, impacto e custos de mitigação. O teste baseado em risco testa minuciosamente as áreas do software que apresentam maior risco, garantindo assim que as áreas mais ameaçadas do software são as mais seguras. É necessário que os desenvolvedores, testadores e gerentes de projeto identifiquem as partes do software que podem atrair os atacantes, quebre o software para entender exatamente como os componentes separados funcionam, classificar os riscos e desenvolver estratégias para remediar, se o risco persistir. explorado. Como os riscos são priorizados com base na gravidade e na importância, os riscos mais importantes com os maiores impactos podem ser reduzidos ou resolvidos primeiro (Wysopal et al, 2007).


Identificar ativos


Os ativos que seriam afetados pelo software devem ser determinados. Os ativos podem incluir computadores, o próprio software, dados, finanças e até reputação e partes interessadas.


Criar uma visão geral da arquitetura


A arquitetura do aplicativo deve ser documentada, usando elementos simples, como diagramas e tabelas. Subsistemas, limites de confiança e fluxo de dados também podem ser incluídos.


Decompor Aplicação


A arquitetura do aplicativo deve ser decomposta, incluindo o design subjacente da rede e da infraestrutura do host, para criar um perfil de segurança para o aplicativo. O objetivo do perfil de segurança é descobrir vulnerabilidades no design, implementação ou configuração de implantação do aplicativo (Meier et al, 2003).


Identifique ameaças


Mantendo os objetivos de um invasor em mente, e com a visão geral da arquitetura e possíveis vulnerabilidades do aplicativo, as organizações devem identificar ameaças que podem afetar o aplicativo.


Ameaças de documentos


Cada ameaça deve ser documentada usando um modelo de ameaça comum que define um conjunto principal de atributos a serem capturados para cada ameaça.


Classifique ameaças


As ameaças devem ser classificadas de acordo com a prioridade, com a ameaça mais significativa abordada primeiro.


Pense como um atacante


Introdução


O software lançado com muitas vulnerabilidades corre o risco de ser explorado pelos invasores. Ataques em software podem ser considerados um custo direto ou indireto para uma organização. Por exemplo, um custo indireto pode estar instalando e mantendo patches. Portanto, se possíveis vulnerabilidades forem corrigidas no início do processo, será menos dispendioso para a organização no final.


Desenvolvedores e testadores podem descobrir vulnerabilidades importantes no software "pensando como um invasor". Se desenvolvedores e testadores tentarem atacar o software, eles poderão descobrir vulnerabilidades antes de seu lançamento público.


Cenário 1


A Keyphase Software Inc. é uma nova empresa de software baseada em serviços de tamanho médio, com cerca de 2.000 funcionários. Ele mantém informações confidenciais de clientes, clientes e funcionários em seus servidores. Portanto, a estratégia de segurança do Keyphase nada mais é do que um mecanismo de autenticação para esses servidores. A empresa já possui algumas políticas de segurança para impor regras de autorização seletiva.


Desafios de segurança no Keyphase


Etapa 1: configuração de segurança


Embora existam mecanismos de segurança padrão, como autenticação e autorização, eles podem não ser suficientemente robustos para escalar com o crescimento do Keyphase. Para definir a configuração de segurança, o Keyphase precisa abordar um fornecedor.


Isso tornará o Keyphase dependente do fornecedor para quaisquer alterações adicionais em sua configuração de segurança. Além disso, os funcionários da Keyphase podem não ter o conhecimento necessário para lidar com qualquer violação.


Etapa 2: Riscos de segurança


Devido à necessidade de presença global, a expansão do Keyphase ocorre a um ritmo constante. Agora que a Keyphase é amplamente conhecida, outra empresa pode contratar um engenheiro social para realizar a espionagem corporativa. Outra possibilidade é que um hacker tente obter acesso aos servidores da Keyphase.


A Keyphase agora enfrenta uma série de riscos à custa de seu crescimento. A empresa precisa realizar a devida diligência e reavaliar sua postura de segurança ou correr o risco de perder a fé dos clientes.


Etapa 3: diretivas de segurança


O Keyphase define uma política de segurança separada para diferentes equipes e clientes externos, dependendo de sua análise de risco. Quando um funcionário passa da Equipe B para a Equipe A, e se a empresa não revogar suas políticas relacionadas à Equipe B? Derrotaria o objetivo de ter políticas separadas e poderia representar um risco.


As políticas de segurança definidas pelo Keyphase precisam ser continuamente revisadas e estendidas para diferentes usuários, dependendo de seus locais e das informações que estão acessando. Além disso, as políticas precisam ser aplicadas de maneira eficaz.


Cenário 2


A Keyphase Software Inc. está criando um site para uma empresa automotiva que deseja exibir carros. A empresa escolhe o ciclo de vida do protótipo evolutivo para obter feedback antecipado do cliente sobre os protótipos produzidos. O cliente recentemente concordou com o protótipo e a fase de implementação foi iniciada.


No final da implementação, o cliente produz um novo requisito. O cliente deseja permitir que seus clientes configurem os carros que compram online. Enquanto a Keyphase prosseguiu com o projeto, a empresa não prestou muita atenção ao aspecto de segurança.


Segurança como uma reflexão tardia


Nem a Keyphase nem o cliente pensaram que a segurança poderia ser uma parte importante do sistema. Essa realização tardia da inclusão de segurança pode dificultar o projeto, pois pode haver uma reformulação considerável.


Segurança como despesa adicional


A segurança é frequentemente considerada como um atributo de qualidade. Não é que a segurança não seja considerada; é que custa mais tempo e recursos, não é importante para os clientes (eles não estão dispostos a pagar mais por mais segurança) e não gera lucros imediatamente.


Análise de risco inadequada


Muitas empresas não conseguem identificar, classificar e medir corretamente os riscos associados aos seus ativos de software. Isso faz com que requisitos de segurança incorretos sejam injetados no ciclo de vida de um projeto.


Código inseguro


Para acomodar os requisitos do cliente, o Keyphase precisará fazer alterações em seu código. Essa alteração pode tornar o código inseguro. Mesmo que os riscos e requisitos de segurança tenham sido identificados, o código não seguro pode criar um ponto de entrada facilmente acessível para o sistema. Nesse sentido, os estouros de buffer se tornaram uma preocupação para os programadores de segurança.


Sumário


A fase chave deve garantir que as preocupações com segurança sejam tratadas no nível organizacional e de desenvolvimento de software.


Referências


A principal fonte é o curso MS de Gerenciamento e Política de Segurança Cibernética da UMUC - University of Maryland College University


Meier, J.D., Mackman, A., Dunner, M., Vasireddy, S., Escamilla, R. e Murukan, A. (2003, junho). Melhorando a segurança de aplicativos da Web: ameaças e contramedidas. Corporação Microsoft. Recuperado de https://msdn.microsoft.com/en-us/library/ff649874.aspx[JB1]


Wysopal, C., Nelson, L., Zovi, D. D. e Dustin, E. (2007). A arte de testar a segurança de software e o aplicativo da Web da Microsoft. Addison-Wesley.

Materiais feitos para você

Contato

Edifício Icon - Alameda Mamoré, 503 Conj.33

Alphaville - São Paulo

CEP 06454-040

Edifício Bolsa de ImóveisAv. das Nações Unidas, 11.541 - Brooklin, São Paulo - SP, 04578-000

 

 

 

 

Tel: +55 11 3181-8444

contato@baymetrics.com.br