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?
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.
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.
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.
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?
Existem dois tipos de problemas de segurança:
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.
Tags security