O que os programadores das empresas de segurança fazem?

Eu ouvi falar de empresas de segurança que consultam sobre a segurança dos sistemas de um cliente. Todas as pessoas que conheço neste campo são engenheiros de rede, mas sei que os programadores também se envolvem em segurança. O que os programadores de segurança que realizam auditorias / consultoria realmente fazem? Eles literalmente passam pela base de código procurando todas as vulnerabilidades nos sistemas legados das pessoas? Sempre presumi que foi isso que eles fizeram, mas parece que isso seria altamente confiável e não faria muito mais do que fornecer uma falsa sensação de segurança. Nota: Não estou falando de programadores que escrevem algoritmos de criptografia ou algo parecido, apenas aqueles relacionados a auditorias / consultoria de segurança de software.

Francamente, tentamos não analisar sua base de código, tentamos escrever ferramentas para fazer isso por nós.

Primeiro, a teoria. A segurança é um requisito de um sistema de software, assim como outros requisitos (funcionalidade, usabilidade, acessibilidade, desempenho, etc.), deve ser considerado em todas as etapas do fluxo de trabalho de engenharia de software, da coleta de requisitos à implantação e manutenção. De fato, isso é possível, e existem orientações para ajudar as equipes de projeto de software a fazer isso. Embora eu trabalhe principalmente com desenvolvedores do iOS, minha descrição favorita do "ciclo de vida de desenvolvimento seguro" é da Microsoft Press .

Nesse modelo, a segurança do aplicativo começa quando estamos tentando obter requisitos de nossos usuários. Precisamos descobrir suas preocupações de segurança e privacidade, o que não é fácil, porque somos especialistas, não usuários, e onde eles entendem seus requisitos de segurança, eles podem achar difícil expressá-los. Também precisamos descobrir a quais riscos o software será exposto na implantação e qual nível de risco é aceitável.

Projetamos nosso aplicativo atendendo a esses requisitos. Escrevemos o código visando atender a esses requisitos e evitar riscos adicionais associados a erros de segurança no nível do código. Testamos o software para garantir que nosso modelo de segurança seja consistente com o que realmente construímos e, em seguida, implantamos o software de maneira a corresponder às suposições que fizemos sobre o ambiente quando projetamos a coisa. Por fim, fornecemos suporte e manutenção que ajudam o usuário a operar o software de maneira consistente com seus requisitos de segurança e que permite que ele (e nós) reaja a novas mudanças nos riscos apresentados.

Ok, muito por teoria. Na prática , por razões que são explicadas muito bem (embora de forma não técnica) na Geekonomics e principalmente devido à maneira como as empresas de software são motivadas, a maioria das coisas acima não acontece. Em vez disso, entendemos isso. Os desenvolvedores:

• contrate um sujeito ou moça de segurança para estar presente quando estiver fazendo uma licitação para mostrar que eles "obtêm" segurança.
• escreva software.
• contrate um responsável pela segurança ou gal para validar o software antes do lançamento, corrigindo muitos problemas que surgiram na etapa 2.
• corrigir tudo o resto após a implantação.

Então, o que a maioria das pessoas de segurança de aplicativos está realmente fazendo é, como você diz, encontrar bugs. Esta é realmente uma revisão de código glorificada, mas é uma revisão de código altamente focada, realizada por pessoas que são especialistas nos tipos de bugs que esta revisão está procurando, portanto ainda há valor em obter ajuda externa para fazer isso. Essa é uma regra geral de inscrição, é claro: sempre peça a alguém para testar quem não está envolvido em fazer a coisa.

Se aceitarmos o exposto acima como verdadeiro, conclui-se que as pessoas que tomam decisões de compra provavelmente equiparam "cara de segurança capaz" a "encontra muitos bugs". Aqueles que fazem com que os computadores façam o trabalho para eles encontrarão mais erros do que aqueles que não o fazem, portanto, é claro, eles dependem muito das ferramentas de análise estática e terão como objetivo gastar mais tempo estendendo as ferramentas do que codificando para problemas específicos para clientes específicos. Em seguida, concluímos que o pessoal de segurança do aplicativo tem mais chances de escrever ferramentas para ler código do que para ler código.

** Atenção: o que resta é opinião e especulação pessoais **

A realidade está quebrada. Você notará que a teoria da segurança de software era sobre identificar e responder ao risco de depender de um sistema de software, enquanto a prática era sobre encontrar o maior número possível de erros. Claro, isso ainda reduzirá o risco, mas apenas como efeito colateral. O ponto do jogo se tornou menos importante do que "vencer" o jogo, então as regras são alteradas para facilitar a vitória.

O que você, como desenvolvedor de software, pode fazer sobre isso? Jogue o jogo de acordo com suas regras originais. Encontre alguém na sua equipe (de preferência na sua equipe, em vez de um contratado, para que eles sejam motivados a fornecer resultados a longo prazo, em vez de uma vitória rápida) que entenda a importância da segurança e treine com eles. Dê a essa pessoa a responsabilidade de orientar a equipe no fornecimento da segurança ponta a ponta descrita no início da minha resposta.

Além disso, dê a essa pessoa a autoridade para seguir adiante . Se um design não expressa os requisitos de segurança, ele deve ser revisado. Se a implementação não atender aos requisitos de segurança, ela não deverá ser liberada . O seu responsável pela segurança pode fazer a decisão, mas deve poder agir com base nessa decisão. Sei que isso pode parecer o cara da segurança dizendo "segurança OMFG é a coisa mais importante", mas não é isso que eu quero dizer. Se o seu produto também não atender aos requisitos de funcionalidade, usabilidade ou desempenho, você também não deve liberar esse item.

Por que você gostaria de fazer isso? Deveria ser mais barato: todos nós já vimos (e provavelmente cotamos para um representante barato de +10) a tabela Code Complete, onde os defeitos ficam mais caros quanto mais tarde você os corrige, certo? Bem, defeitos de segurança também são defeitos. Nas regras do jogo do mundo real, a maioria delas são problemas nos requisitos que são corrigidos na manutenção. Isso é barato?

Ok, agora o que eu posso fazer como arma de segurança para contratar? Bem, acontece que também posso me recusar a jogar pelas regras alteradas. Posso dizer aos desenvolvedores que tudo se resume a reduzir riscos, que isso pode ser feito em todas as etapas e, então, posso ajudá-los a fazer isso.

Desde 15 anos executando programas de garantia de segurança contra aplicativos, ambientes, sistemas etc. pequenos e extremamente grandes, eu diria que há um pouco de tudo. Nas minhas equipes, sempre tive alguns que são codificadores hardcore.

No nível detalhado, parte disso se resume a uma revisão muito aprofundada do código - como exemplo, atualmente estou trabalhando em uma base de código de vários milhões de linhas, usando ferramentas para restringir os possíveis problemas e, em seguida, analisando cada um deles. categorizar.

(É certo que eu entrego aos desenvolvedores para remediar ou explicar por que o problema não representa um risco)

Mas esse é um compromisso específico para o qual o perfil de risco faz sentido para realizar esse tipo de trabalho intensivo em recursos.

Muito mais padrão e muito mais econômico está tentando entender o perfil de risco da organização e se concentrar nos riscos de cima para baixo, por exemplo:

• Apetite ao risco - impacto nos negócios, modelagem de ameaças
• Governança - conformidade regulatória, relatórios etc.
• Políticas - definições para garantir que a estrutura de governança seja eficaz
• Processos - técnicos e humanos
• Padrões - definições para cada controle de segurança
• Implementação - o Como Fazer

O lado da programação realmente só aparece nos dois últimos, com revisão de código e teste de penetração personalizado. Para algumas organizações, é de pouca importância; por exemplo, se você possui controles de segurança em camadas que já foram revisados ​​por pares extensivamente (vários tipos de criptografia, por exemplo), então enquanto você pode verificar sua implementação, geralmente não vai verificar novamente código como já foi feito antes.

Eu nunca encontrei nenhum que vá muito além de discutir a arquitetura / práticas recomendadas de maneira vaga durante o design e / ou a execução de conjuntos de testes de ataque / fritzing / exceção em projetos concluídos.

Em quase todos os casos, posso até dizer quais ferramentas eles usam pelos vetores de ataque que tentam e a maneira pela qual o ataque é realizado depois que uma das auditorias passa em um sistema existente.

Eu imagino que existem alguns que realmente levam tempo para examinar o código e fazer alguns testes de revisão / caixa branca, mas ainda não os encontrei na vida real.