Desenvolvimento Confiável. Mais do que Seguro!

Foto: Edison Fontes, Polônia, Varsóvia

Edison Fontes, CISM, CISA, CRISC, Ms. 2022

Desenvolvimento Confiável é um conjunto obrigatório de controles técnicos e de gestão que buscam garantir que o desenvolvimento de aplicações ofereça um produto confiável para o negócio e para todos os ambientes utilizados, com controles de segurança de informação, cibernética e de privacidade. Isto é, possibilite que a organização se concentre em melhor utilizar a aplicação para seus objetivos corporativos.

Produto Confiável significa um produto, solução ou serviço, que possui controles de segurança da informação, segurança cibernética e proteção à privacidade, com o propósito de garantir o uso correto da informação e impedir impactos negativos (financeiros, legais, operacionais ou de reputação) para a organização.

No texto abaixo, o termo “deve”, significa controle obrigatório.

Os desenvolvedores devem implementar nos seus códigos de aplicação, os seguintes controles, independente se o ambiente está na organização ou em um serviço em nuvem, mas não se limitando a:

 

Testes

• Deve ser elaborado um plano de teste com todas as situações possíveis que podem causar erros ou explorar fragilidades no código da aplicação.
• O Plano de Teste deve ser seguido e a aplicação deve responder adequadamente. A execução do Plano de Teste deve gerar evidências que devem ser guardadas durante pelo menos um ano, respeitando exigências legais ou contratuais.
• Sendo possível, é aconselhável a realização de teste de performance sob alta utilização do aplicativo.
• Somente após o atendimento de 100% do Plano de Teste a aplicação pode ser liberada para utilização.

 

Gestão de Mudanças

Para a passagem para o ambiente de produção é necessário a existência do Processo de Gestão de Mudanças, com representantes de todas as áreas envolvidas no funcionamento da nova versão da aplicação.

 

Autorização, identificação e autenticação

• A aplicação somente deve ser ativada para os usuários autorizados, identificados e autenticados.
• Caso este controle de autorização, identificação e autenticação não seja responsabilidade da aplicação, o mesmo deve fazer parte do Plano de Teste.
• Considerar sempre a possibilidade de uso de dupla autenticação ou outro mecanismo com melhor segurança.

 

Uso da informação – Registro de atividade

• Todo tratamento realizado pela aplicação em alguma informação, deve ser registrado e armazenado por um tempo mínimo de um ano, respeitando exigências legais ou contratuais.
• Uma sugestão de registro de log, mas não se limitando, quando dos seguintes eventos:

– Todos os eventos de autenticação (sucesso, falha, solicitação de alteração de senha etc.);
– Transações relacionadas a movimentações financeiras;
– Tentativas de acesso que foram bloqueadas pela aplicação; e
– Dados maliciosos que foram enviados para a aplicação.

 

Documentação

• Deve existir uma documentação da aplicação e seu contexto dentro do sistema, possibilitando que outro profissional com o mesmo perfil técnico de quem criou a aplicação, possa realizar manutenção em condições adequadas.

 

Validação da essência da informação (Semântica e Sanitização)

• As informações recebidas pela aplicação devem ser validadas rigorosamente em relação à sua essência e sua forma de construção. Campos numéricos, alfanuméricos, que aceitam ou não caracteres especiais. Campos ocultos ou desabilitados nunca devem ser preenchidos.
• Campos devem ser analisados se não possuem mascarados possíveis códigos maliciosos executáveis. Limpar, sanitizar se for o caso. E gerar alertas.

 

Mecanismos de Tratamento de Erros e Alertas de Segurança

• Deve existir uma Gestão para Tratamento de Erros e Alertas de Segurança, normalmente utilizando ferramentas para que estas situações sejam conhecidas e se tenha a possibilidade de tomar decisões sobre as mesmas.

 

Proteção de Dados Pessoais desde o Desenvolvimento

• A Lei Geral de Proteção de Dados Pessoais, trouxe uma responsabilidade para o desenvolvedor: desde o início da concepção do aplicativo, a proteção de dados pessoais deve ser considerada. (LGPD, Art. 46. § 2º ).
• Devem ser avaliados se os controles (regras) da LGPD afetam a aplicação ou serão tratadas por outras aplicações.

 

Revisão de Código

• Considerando a criticidade da aplicação desenvolvida deve ser avaliada a necessidade do Controle de Revisão de Código por outro profissional ou profissionais diferentes dos desenvolvedores que escreveram a aplicação.
• A metodologia de desenvolvimento deve considerar a classificação de criticidade e de sensibilidade de código para definir a exigência do Controle Revisão de Código.

 

Ambiente de Desenvolvimento

• Os desenvolvedores devem ter acesso exclusivamente às bibliotecas de código-fonte do software que sejam necessárias para sua atividade.
• Os desenvolvedores não devem ter acesso ao ambiente de produção de maneira semelhante ao ambiente de desenvolvimento.

 

Versionamento

• Deve existir uma Gestão de Versão de Códigos estruturada e que garanta a integridade do aplicativo.
• Qualquer alteração realizada no código fonte deve alterar a versão relacionada ao mesmo.

 

Padrão Mínimo de Controles Técnicos

• Deve ser adotado um Padrão de Verificação de Segurança de aplicações. Recomendamos o Padrão OWASP.
• Toda aplicação deve cumprir os Requerimentos de Padrão de Verificação de Segurança de Aplicações OWASP Nível 1.
• Deve existir um normativo interno da organização classificando os tipos de aplicações que devem ser submetidas a Padrão OWASP Nível 2 ou Nível 3.

 

Classificação da Informação

• A aplicação deve possibilitar no seu tratamento de informação o uso de Classificação em relação ao Sigilo, Criticidade, Dado Pessoal, Transparência ou outra segmentação utilizada pela organização.

 

Acompanhamento após implantação

• Cada aplicação deve ser acompanhada após a sua implementação no ambiente de produção, por pelo menos três meses e ser avaliada se ocorrem problemas motivados pelo código fonte desenvolvido.

• Problemas em ambiente de produção devem ser analisados e verificados se a causa raiz foi uma realização de teste incompleta ou não correta.

 

Atualização da Infraestrutura de Desenvolvimento

• Havendo atualização do ambiente lógico de infraestrutura de desenvolvimento de aplicações, principalmente motivado por fragilidades que podem comprometer a segurança da aplicação, a mesma deve ser novamente gerada a partir do código fonte, utilizando esta infraestrutura mais confiável.

 

Gestão Executiva

• Deve ser emitido mensalmente um Relatório Gerencial possibilitando que o Corpo Diretivo da organização tenha uma visão da Maturidade de Conformidade com os Controles de Desenvolvimento Confiável

 

Conclusão

Um grande percentual dos problemas de erros e de vulnerabilidades que possibilitam a atuação de criminosos, tem como causa raiz a não aderência aos Controles de Desenvolvimento Confiável.

A aplicação dos Controles de Desenvolvimento Confiável exige recursos de tempo, financeiro e inteligência. Mas com certeza serão mais baratos do que o cancelamento, funcionamento inadequado ou ação criminosa.

Seguir Controles de Desenvolvimento Confiável deve ser uma diretriz da Segurança da Informação, porém uma obrigação da Gestão de Desenvolvimento em Tecnologia da Informação.

Grande abraço.

Edison Fontes, CISM, CISA, CRISC, Ms.

CyberSecurity Evangelist – NTT DATA Europe & LATAM

[email protected]