Para construir um sistema seguro, você deve começar a pensar em segurança desde o início.

Restrições legais e de conformidade

Primeiro, certifique-se de que todos na equipe entendem as necessidades e limitações legais e de conformidade para o sistema.

Os regulamentos vão conduzir muitos dos controles de segurança em seu sistema, incluindo a autenticação, o controle de acesso, a confidencialidade e a integridade (e criptografia) dos dados e auditoria, bem como a disponibilidade e a confiabilidade do sistema.

As equipes de Agile não devem depender somente de seu Product Owner para compreender e comunicar esses requisitos. As restrições de conformidade podem impor restrições importantes de design que, por sua vez, podem não ser claras sob uma perspectiva de negócios, bem como requisitos de garantia que ditam como você precisa construir e testar, entregar o sistema, e que provam que você precisa mostrar que fez um trabalho responsável.

É importante que, como desenvolvedor, você tente entender o que tudo isso significa para você o quanto antes. Para te ajudar a começar, a Microsoft tem um guia útil e simples (Regulatory Compliance Demystified: An Introduction to Compliance for Developers) que explica as regulamentações de negócios comuns, incluindo SOX, HIPAA e PCI-DSS, e o que significam para os desenvolvedores.

Rastreamento de dados confidenciais

A preocupação fundamental na maioria dos marcos regulatórios é o controle e a proteção de dados.

Certifique-se de que todos entendam o que são os dados pessoais/confidenciais/sensíveis e, portanto, que precisam ser protegidos. Identifique e acompanhe esses dados em todo o sistema. Quem é o dono dos dados? O que é a cadeia de custódia? De onde é que os dados estão vindo? A fonte pode ser confiável? Para onde é que os dados vão? Você pode confiar no destino para proteger os dados? Onde os dados são armazenados ou exibidos? Eles precisam ser armazenados ou exibidos? Quem está autorizado a criá-los, vê-los, alterá-los, e essas ações precisam ser monitoradas e revistas?

As respostas para essas perguntas conduzirão os requisitos para validação e integridade de dados, controle de acesso, criptografia e controles de auditoria e registro no sistema.

Controles de segurança de aplicativos

Pense nos controles de segurança de aplicativos funcionais básicos: autenticação, controle de acesso, auditoria – tudo o que nós já abordamos anteriormente nesta série de artigos. Onde é que esses controles devem ser adicionados? Quais histórias de segurança precisam ser escritas? Como é que esses controles são testados?

Abuso de lógica de negócios pode ser explorado

A segurança também deve ser considerada na lógica de negócios, especialmente os fluxos de trabalho de aplicativos multipassos que lidam com dinheiro ou outros objetos de valor, ou os que lidam com informações particulares ou confidenciais, ou funções de comando e controle. Características como carrinhos de compras online, transações online de contas bancárias, de recuperação de senha do usuário, lances em leilões online, ou funções de negociação e administração de root online são todas potenciais alvos para ataques.

As histórias de usuários ou os casos de uso para esses recursos devem incluir exceções e cenários de falha (o que vai acontecer se um passo ou uma verificação falhar ou der o tempo limite, ou se o usuário tentar cancelar ou repetir ou ignorar uma etapa?). E as exigências derivadas de “casos de abuso” ou “casos de uso indevido“. Os casos de abuso exploram como a aplicação verifica e como os controles poderiam ser subvertidos por invasores ou como as funções poderiam ser testadas em busca de erros de lógica de negócios comuns, incluindo o tempo de verificação/tempo de uso e outras condições de execução e problemas de tempo, a entropia insuficiente em chaves ou endereços, o vazamento de informações, a falta de prevenção de força bruta, o não cumprimento do sequenciamento de fluxo de trabalho e das aprovações, os erros básicos na validação de dados de entrada e erro de manipulação/exceção e verificação de limites.

Isso não é uma defesa contra as forças malignas do Black Hat, mas entender essas coisas de forma errada pode ser extremamente prejudicial. Dê uma lida no trabalho clássico do Jeremiah Grossman “Seven Business Logic Flaws that put your Website at Risk” para ver alguns exemplos interessantes de como os caras maus podem explorar e, frequentemente, planejar erros banais nas lógicas dos aplicativos.

Separe um tempo para dar uma olhada nos casos de abuso importantes quando estiver escrevendo histórias ou exigências funcionais, certifique-se de rever esse código com cuidado e incluir testes manuais extras (principalmente testes exploratórios), bem como testes de invasão dessas características para capturar problemas sérios da lógica do negócio.

Estamos nos aproximando da linha de chegada. O artigo final desta série está chegando!

***

Artigo traduzido pela Redação iMasters com autorização do autor. Publicado originalmente em http://swreflections.blogspot.com.br/2014/07/10-things-you-can-do-as-developer-to_7.html