Desenvolver a segurança primeiro ou como um passo posterior?

4

A pergunta Você pensa ativamente em segurança ao codificar? pergunta sobre a mentalidade de segurança durante a programação.

Obviamente, um desenvolvedor precisa pensar em segurança durante a codificação - injeção de SQL, segurança por senha, etc.

No entanto, no que diz respeito à segurança real, totalmente formada, especialmente os problemas complicados que podem não ser imediatamente óbvios, eu deveria estar preocupado em abordá-los durante todo o processo de desenvolvimento, ou deveria ser um passo à sua frente mais tarde? desenvolvimento?

Eu estava ouvindo um podcast sobre Segurança agora e eles mencionaram como muitos dos problemas de segurança encontrados no Flash, porque quando o Flash foi desenvolvido, ele não foi criado com a segurança em mente (porque ele não precisava) - portanto, o Flash tem grandes falhas de segurança em seu núcleo.

Eu sei que ninguém gostaria de discordar ativamente de "pensar primeiro na segurança" como uma prática recomendada, mas muitas empresas não seguem as práticas recomendadas. Então, qual é a abordagem correta para equilibrar a necessidade de obter o produto e desenvolvê-lo com segurança?

    
por MattyD 27.06.2011 / 02:08
fonte

4 respostas

12

No trabalho, temos uma lista de coisas simples / padrão que não devemos fazer. Como consultas não parametrizadas e tal. Temos que rever nosso código e devemos pedir a alguém que o revise também para garantir que nenhum dos no-nos seja implementado. Depois de ter passado por isso algumas vezes, você não pode deixar de pensar em segurança enquanto codifica. Na minha opinião, você deve codificar a segurança enquanto codifica a funcionalidade. O tempo todo. Muito poucas exceções.

    
por 27.06.2011 / 02:21
fonte
6
Em primeiro lugar, com qualquer aplicativo que esteja disponível para o público ou seja executado em máquinas voltadas para o público, tento projetar a segurança no início. Quais riscos esse aplicativo potencialmente expõe? Como isso pode ser mitigado? Qual é o pior resultado que poderia surgir de um comprometimento de segurança deste aplicativo e o que pode ser feito para minimizar a dor desse resultado?

Se você pretende ser seguro desde o início, é preciso pensar menos quando está digitando. É claro que existem práticas que você precisa seguir para evitar os ataques mais comuns, mas se o aplicativo estiver estruturado para se comportar de maneira mais segura desde o início, será muito mais fácil manter a segurança do código posteriormente.

    
por 27.06.2011 / 12:17
fonte
3

Segurança é como desempenho.

Você não pode obter uma lata de segurança e espalhá-la pelo software mais tarde.

Quando as pessoas criam produtos e não pensam nas ilidades , você tem problemas.

  • segurança
  • confiabilidade
  • suportabilidade
  • desempenho (escalabilidade)

Agora, quando você acha que a segurança não é um requisito, é preciso perguntar: onde está o software usado. Se a resposta não estiver em um cartucho de ROM em uma máquina sem mídia externa ou conexão de rede, sua análise de requisitos é um pouco insuficiente.

Se um cliente executar seu software, ele espera que seu software não exponha seus outros dados a roubo ou dano. Eles também podem razoavelmente esperar que seu computador e rede não sejam usados por algum botnet hostil como resultado de falhas de segurança em seu produto.

Essa expectativa de segurança provavelmente é apropriada para quase todos os softwares. A linguagem que usei é intencionalmente legalista, já que estamos falando sobre problemas que um cliente pode tentar processar você ou seu empregador.

Se alguém pode pensar em algum software que pode ser inseguro de antemão, você pode comentar?

    
por 28.06.2011 / 02:07
fonte
1

Existem dois tipos de problemas de segurança:

  • Problemas localizados, como estouro de buffer resultante de uma falta de verificação de limites de matriz ou de injeções de SQL resultantes da confusão de consultas com sequências de caracteres. Isso pode ser resolvido usando boas ferramentas de programação (os sistemas de bom tipo irão capturar muitos deles). Quando encontradas, elas podem ser consertadas facilmente; mas quando há um, geralmente há muitos similares.
  • Problemas de design profundo, como não segregar permissões o suficiente ou se comprometer com protocolos com fuga. Acertar isso requer planejamento inteligente. Quando encontrados, eles geralmente são um pesadelo para corrigir, porque você precisa reescrever grandes faixas de código ou introduzir grandes incompatibilidades.

Não projetar para a segurança é como construir uma casa de palha. Funciona até o grande lobo mau aparecer e você perde. Isso não significa que você deva sempre projetar para segurança, nem sempre a proteção contra defeitos é necessária. Mas você não transforma uma casa de palha em uma casa de tijolos, trancando a segurança; é uma casa totalmente diferente. Da mesma forma, se você não projetar para segurança a partir do dia 1, a proteção será mais uma reformulação completa do que uma evolução leve.

    
por 01.07.2011 / 00:55
fonte

Tags