Diretoria de Segurança Corporativa
Superintendência de Segurança da Informação
Baseline de Segurança da Informação
Avaliação de Fornecedor
Fábrica de Software
Baseline de Análise de Risco em Fornecedores
SUMÁRIO:
1.
SEGURANÇA DA REDE:.......................................................................................................................................... 5
2.
PATCHES DE SEGURANÇA: .................................................................................................................................... 5
3.
HARDENING: ........................................................................................................................................................ 5
4.
SCANNING: ........................................................................................................................................................... 6
5.
PEN TEST: ......................................................................................................................................................... 6
6.
PROCEDIMENTOS PARA TRATAMENTO DE INFORMAÇÃO: ................................................................. 6
7.
REGISTRO DE USUÁRIO: ............................................................................................................................... 7
8.
RETIRADA DE DIREITOS DE ACESSO:........................................................................................................ 7
9.
SEGREGAÇÃO DE FUNÇÕES: ...................................................................................................................... 7
10. GERENCIAMENTO DE SENHA DO USUÁRIO: ............................................................................................ 8
11. PROCEDIMENTOS SEGUROS DE ENTRADA NOS SISTEMAS: ............................................................... 8
12. NAVEGAÇÃO INTERNET: ............................................................................................................................... 9
13. MENSAGENS ELETRÔNICAS: ....................................................................................................................... 9
14. POLÍTICA DE ESTAÇÃO DE TRABALHO:.................................................................................................... 9
15. SENHA DE BIOS / ACESSO VIA USB: .........................................................................................................10
16. FERRAMENTA DE CAPTURA REMOTA: .....................................................................................................10
17. AUTENTICAÇÃO PARA CONEXÃO EXTERNA DO USUÁRIO: ................................................................10
18. REGISTROS E PROTEÇÃO DE TRILHAS DE AUDITORIA: ......................................................................10
19. CRIPTOGRAFIA DE DISCO:...........................................................................................................................11
20. SISTEMA OPERACIONAL ATUALIZADO COM VERSÕES SUPORTADAS PELO FABRICANTE: .....11
21. SINCRONIZAÇÃO DOS RELÓGIOS: ............................................................................................................11
22. CONTROLES CONTRA CÓDIGOS MALICIOSOS: ......................................................................................11
23. GESTÃO DE MUDANÇAS: .............................................................................................................................12
24. SEPARAÇÃO DOS RECURSOS DE DESENVOLVIMENTO, TESTE E DE PRODUÇÃO: ......................12
25. CÓPIAS DE SEGURANÇA DAS INFORMAÇÕES: ......................................................................................12
26. POLÍTICA DE SEGURANÇA DA INFORMAÇÃO: ........................................................................................12
27. POLÍTICA DE MESA LIMPA: ..........................................................................................................................13
28. POLÍTICA DE TELA LIMPA: ...........................................................................................................................13
29. COORDENAÇÃO DA SEGURANÇA DA INFORMAÇÃO:...........................................................................13
30. RESPONSABILIDADES E PROCEDIMENTOS (INCIDENTES DE SEGURANÇA DA INFORMAÇÃO):
13
31. RECOMENDAÇÕES PARA CLASSIFICAÇÃO: ...........................................................................................14
32. ACORDOS DE CONFIDENCIALIDADE: ........................................................................................................14
33. CONSCIENTIZAÇÃO, EDUCAÇÃO E TREINAMENTO EM SEGURANÇA DA INFORMAÇÃO: ............15
34. INVENTÁRIO DOS ATIVOS: ...........................................................................................................................15
35. REMOÇÃO DE PROPRIEDADE: ....................................................................................................................15
36. CONTROLES DE ENTRADA FÍSICA: ............................................................................................................15
09/04/15
Pág: 2
Baseline de Análise de Risco em Fornecedores
37. CONTINUIDADE DE NEGÓCIOS: ..................................................................................................................16
38. INSPEÇÕES PERIÓDICAS DE VERIFICAÇÃO DE COMPLIANCE AOS REQUISITOS DE
SEGURANÇA: ..........................................................................................................................................................16
ANEXO A – SEGURANÇA PARA DESENVOLVIMENTO DE APLICAÇÕES ...................................................17
1.
INTRODUÇÃO ..................................................................................................................................................17
2.
DESENVOLVIMENTO SEGURO - MELHORES PRÁTICAS GERAIS ........................................................17
3.
REVISÃO SEGURA DE CÓDIGO – PRÁTICAS GERAIS ............................................................................19
4.
DESENVOLVIMENTO SEGURO - MELHORES PRÁTICAS ESPECÍFICAS .............................................20
4.1. PROTEÇAO PARA WEBSERVICES ..............................................................................................................20
4.2. PROTEÇÃO PARA APLICATIVOS MÓVEIS ................................................................................................21
4.3. PROTEÇAO PARA BANCO DE DADOS .......................................................................................................23
4.4. GERENCIAMENTO E EXECUÇÃO MALICIOSA DE ARQUIVOS ..............................................................24
4.4.1.
EXEMPLOS: ...............................................................................................................................................24
4.4.2.
REFERENCIAS:.........................................................................................................................................25
4.5. FALHAS DE INJEÇÃO ....................................................................................................................................25
4.5.1.
PROTEÇÃO – SQL INJECTION ..............................................................................................................26
4.5.2.
PROTEÇÃO – OS COMMAND INJECTION ...........................................................................................26
4.5.3.
PROTEÇÃO – PATH TRAVERSAL/DISCLOSURE ...............................................................................26
4.5.4.
EXEMPLOS ................................................................................................................................................27
4.5.5.
REFERÊNCIAS ..........................................................................................................................................27
4.5.6.
REVISÂO DE CÒDIGO .............................................................................................................................27
4.6. FALHA DE AUTENTICAÇÃO E GERENCIAMENTO DE SESSÃO ............................................................27
4.6.1.
PROTEÇÃO - REPLAY DE SESSÃO ......................................................................................................29
4.6.2.
PROTEÇÃO – HIJACKING DE SESSÃO ...............................................................................................29
4.6.3.
EXEMPLOS ................................................................................................................................................29
4.6.4.
REFERÊNCIAS ..........................................................................................................................................29
4.6.5.
REVISÃO DE CÓDIGO .............................................................................................................................30
4.7. PROTEÇÃO CONTRA CROSS-SITE SCRIPTING (XSS) ............................................................................30
4.7.1.
EXEMPLOS ................................................................................................................................................31
4.7.2.
REFERÊNCIAS ..........................................................................................................................................31
4.7.3.
REVISÃO DE CÓDIGO ....................................................................................................................................31
4.8. REFERÊNCIA DIRETA INSEGURA A OBJETOS .......................................................................................31
4.8.1.
EXEMPLOS ................................................................................................................................................32
4.8.2.
REFERÊNCIAS ..........................................................................................................................................32
4.9. INFRAESTRUTURA E AMBIENTE .................................................................................................................32
4.9.1.
LOGS PARA AUDITORIA ........................................................................................................................34
4.10.
ARMAZENAMENTO CRIPTOGRÁFICO INSEGURO ...........................................................................34
4.10.1.
09/04/15
EXEMPLOS ............................................................................................................................................35
Pág: 3
Baseline de Análise de Risco em Fornecedores
4.10.2.
4.11.
REFERÊNCIAS ......................................................................................................................................36
FALHAS AO RESTRINGIR ACESSO A URLS ......................................................................................36
4.11.1.
EXEMPLOS ............................................................................................................................................37
4.11.2.
REFERÊNCIAS ......................................................................................................................................37
4.12.
COMO EVITAR CROSS-SITE REQUEST FORGERY (CSRF) .............................................................37
4.12.1.
EXEMPLOS ............................................................................................................................................38
4.12.2.
REFERÊNCIAS ......................................................................................................................................38
4.12.3.
REVISÃO DE CÓDIGO ................................................................................................................................38
4.13.
REDIRECIONAMENTOS E ENCAMINHAMENTOS INVÁLIDOS.........................................................38
4.13.1.
EXEMPLOS ............................................................................................................................................39
4.13.2.
REFERÊNCIAS ......................................................................................................................................39
4.14.
EVITANDO O BUFFER OVERFLOWS/OVERRUNS .............................................................................39
4.14.1.
REFERENCIA ........................................................................................................................................39
4.14.2.
REVISÃO DE CÓDIGO .........................................................................................................................40
4.15.
TRATAMENTO DE DADOS CONTRA INTEGER AND ARITHMETIC OVERFLOWS .......................40
4.15.1.
EXEMPLOS ............................................................................................................................................40
4.15.2.
REFERÊNCIAS ......................................................................................................................................40
4.16.
FORMAT SPRING NÃO CONTROLADA ................................................................................................41
4.16.1.
EXEMPLOS ............................................................................................................................................41
4.16.2.
REFERÊNCIAS ......................................................................................................................................41
4.17.
CONDIÇÕES DE CONCORRÊNCIA .......................................................................................................41
4.17.1.
REFERÊNCIAS ......................................................................................................................................42
4.17.2.
REVISÃO DE CÓDIGO .........................................................................................................................42
4.18.
COMUNICAÇÕES INSEGURAS ..............................................................................................................42
4.18.1.
EXEMPLOS ............................................................................................................................................43
4.18.2.
REFERÊNCIAS ......................................................................................................................................43
09/04/15
Pág: 4
Baseline de Análise de Risco em Fornecedores
Os controles de segurança a seguir devem ser implantados:
1. Segurança da rede:
Manter atualizado o diagrama da rede, mostrando os componentes de rede que garantam a
proteção das informações do Itaú Unibanco necessários à operacionalização do serviço (incluir
nessa representação roteadores, switches, firewalls dedicados e eventuais topologias de rede
sem fio existentes). Os pré-requisitos mínimos de rede devem estar aplicados, conforme abaixo:
conexão dedicada com o Itaú Unibanco, ficando o modelo triangulado (derivação da rede
para outros sites) como não recomendado;
firewall com controle de sessão, respeitando um tempo de vida de sessão de 1 hora;
controle de acesso aos pontos de rede via 802.1X, para validação de certificados de
máquina e de usuário através de servidor Radius, que tratará as requisições informando
aos switches se devem direcionar o acesso para a rede corporativa (no caso de
certificados validados) ou para a rede de visitantes (no caso de certificados inválidos ou
inexistentes);
sistemas de detecção de invasão e/ou sistemas de prevenção contra invasão para
monitorar/bloquear todo o tráfego malicioso;
formalização, justificativa, aprovação e teste de todas as regras configuradas do firewall,
roteador e switch, não podendo haver regras com origem, destino ou porta “any” (qualquer
protocolo ou endereço IP);
se houver rede WI-FI, deverá ser implementada segurança via WPA2 com autenticação
através do protocolo 802.1X;
não deverá existir “Trust” (confiança entre domínios) entre servidores Windows da
operação Itaú Unibanco com qualquer outro servidor.
2. Patches de Segurança:
Um procedimento de identificação e atualização de Patches de Segurança deve ser posto em
prática para que os patches sejam instalados em até 30 dias da divulgação pelo fabricante e
obedecidos os critérios de homologação.
3. Hardening:
Aplicar procedimento de blindagem dos equipamentos (hardening) para prover proteção a esses
recursos. Vide documentos a seguir, que deverão ser solicitados para a Área de Segurança da
Informação do Itaú, assim que o serviço for contratado:
Itau_Hardening_PTB - Network Devices – Router;
Itau_Hardening_PTB - Network Devices – Switch;
09/04/15
Pág: 5
Baseline de Análise de Risco em Fornecedores
Itau_Hardening_PTB - Windows IIS;
Itau_Hardening_PTB - Windows Servidor;
Itau_Hardening_PTB - Windows Workstation.
Obs.: Estes documentos devem ter acesso restrito às equipes envolvidas
4. Scanning:
Um procedimento de varredura de vulnerabilidades em equipamentos de rede (scanning) deve
ser executado ao menos 01 vez ao mês e/ou após modificações significativas no ambiente.
5. Pen Test:
Realizar PenTest (teste de invasão) no perímetro interno e externo para identificação de
vulnerabilidades pelo menos uma vez ao ano ou após modificações significativas no ambiente.
6. Procedimentos para tratamento de informação:
Em caso de empresa com acesso ao ambiente do Itaú:
Deverá ser feito exclusivamente ao ambiente de desenvolvimento com o VDI.
Em caso de empresa que irá receber Código Fonte:
para a transmissão/recepção das documentações e códigos fonte deve ser utilizada
solução homologada pela área de tecnologia, com garantia de autenticidade,
criptografia e regras de Firewall específicas autorizadas e liberadas através de rede
DMZ;
O processo de inserção do código fonte enviado pela fábrica no ambiente de
desenvolvimento deverá seguir o fluxo atualmente previsto na metodologia de
desenvolvimento de sistemas;
Não encaminhar informações do Itaú Unibanco para empresas terceiras sem a prévia
avaliação e consentimento da área de Segurança da Informação do Itaú. deve existir
um procedimento de gestão de acessos (fluxo com alçadas de aprovação para
cadastro e revogação e revisão de acessos de usuários);
criar mecanismos de trilha de auditoria em todo o ciclo de vida da informação
(recepção, processamento e saídas).
O Datacenter da empresa deverá estar no Brasil, em função da diversidade de legislações em
outros países, dificuldades de investigação e atuação no caso de problema.
A área de Segurança da Informação do Itaú deverá ser informada quando houver a intenção de
terceirização do Datacenter (Colocation e Hosting) para emitir uma avaliação de Risco.
09/04/15
Pág: 6
Baseline de Análise de Risco em Fornecedores
7. Registro de usuário:
Estabelecer procedimentos que orientem a concessão e revogação de contas de acesso,
tornando obrigatório:
identificação de usuário (ID) único, pessoal e exclusivo para assegurar a
responsabilidade de cada usuário por suas ações;
disponibilização de acessos levando em consideração o mínimo privilégio
(necessidade para o negócio ou por razões operacionais);
formalizar os direitos de acesso fornecidos aos usuários;
liberar acesso aos usuários somente após conclusão dos procedimentos de
autorização;
não permitir a utilização de usuário genérico no ambiente de produção;
manter um registro formal de todas as pessoas com direito de acesso concedido;
assegurar a remoção imediata, ou bloqueio dos direitos de acesso, de usuários que
mudaram de cargos, funções ou deixaram a empresa.
8. Retirada de direitos de acesso:
Um fluxo de ‘exclusão/bloqueio’ imediato de acessos físicos e lógicos, de forma que reflita as
ações do RH, deve estar aplicado para:
suspender funcionários em ausência legal (ex. férias, licenças, etc.) por todo o período
que estiverem fora da empresa;
ter procedimento para casos de necessidade de exclusão imediata de acessos físicos
e lógicos;
ter processo de revisão mensal em todas as plataformas de acessos (redes e
sistemas), inclusive de clientes.
9. Segregação de funções:
Um critério de segregação de funções baseado em ‘cargos/funções/atividades/cliente/ operação’,
deve estar estabelecido, de forma que o funcionário tenha somente acesso ao indispensável para
a execução da atividade para a qual foi contratado. Além disso:
09/04/15
estágios críticos de processo, desempenhadas, por exemplo, pelo administrador do
sistema, security officer ou auditor fiquem a cargo de dois ou mais funcionários;
categorias e perfis de usuários aos quais privilégios especiais de acesso precisam ser
concedidos devem estar identificados e registrados (ex: no AD, RACF ou outro sistema
de controle).
Pág: 7
Baseline de Análise de Risco em Fornecedores
10. Gerenciamento de senha do usuário:
Uma política de senhas ‘forte’ deve ser criada de acordo com a tabela a seguir:
Políticas
Parâmetro
Histórico de senhas
Manter as últimas 24 senhas
Duração máxima da senha
30 dias
Duração mínima da senha
1 dia
Tamanho mínimo da senha
mínimo de 8 caracteres para usuários comuns
mínimo de 15 caracteres para usuários
administradores
Duração do bloqueio
Manual – Requer intervenção da área de suporte
Exclusão de conta por inatividade de uso
Remover as contas dos usuários inativos há 60
dias. Exceção: usuário de conta de sistema ou
especiais
Números de tentativas inválidas de logon
3
Complexidade
As senhas devem ser compostas por no mínimo
três das regras abaixo:
Caracteres maiúsculos (A, B, C...).
Caracteres minúsculos (a, b, c...)
Numerais (0, 1, 2, 3, 4, 5, 6, 7, 8, 9)
Caracteres especiais (@ # &)
Adicionalmente, devem ser criados procedimentos para:
verificar a identidade do usuário antes de fornecer uma senha temporária, de
substituição ou nova;
nunca armazenar as senhas nos sistemas de um computador de forma desprotegida;
aplicar a criptografia no mínimo Kerberos para cache de senhas;
orientar usuários a manter a confidencialidade das senhas e evitar manter anotadas
as senhas, a menos que elas possam ser armazenadas de forma segura;
controlar o uso de senhas de usuários com perfil de administração (ex: root, sa,
administrator, etc), que deverão ser digitadas por pelo menos duas pessoas,
envelopadas e mantidas em local com controle de acesso físico.
11. Procedimentos seguros de entrada nos sistemas:
Um aviso geral informando que somente pessoas autorizadas devem obter acesso ao
computador deve ser exibido no início do processo de login.
Mensagens de ajuda durante o procedimento de entrada nos sistemas não devem ser exibidas,
para que não auxiliem um eventual usuário não autorizado na tentativa de acesso.
09/04/15
Pág: 8
Baseline de Análise de Risco em Fornecedores
12. Navegação internet:
Para estações de trabalho dedicadas ao desenvolvimento Itaú, não deverá ser liberado o acesso
a Navegação Internet.
13. Mensagens eletrônicas:
Para estações de trabalho dedicadas ao desenvolvimento Itaú, não deverá ser liberado o acesso
para envio e recebimento de E-mail Externo.
14. Política de Estação de Trabalho:
Deve ser implementado o bloqueio nos itens abaixo:
botão Executar;
botão Configurações;
compartilhamento entre estações de trabalho;
gerenciador de tarefas;
gravação em mídia removível;
browsers para a execução de programas;
acessos administrativos;
alteração de horário;
cache de credenciais;
programas e serviços (ver necessidade da Operação);
execução automática de programa (autorun), que deverá estar desabilitada em todos
os drivers;
instalação de impressora;
gravação de arquivos na estação de trabalho pelos usuários da operação.
Além disso, racks e cadeados devem ser utilizados para evitar acesso físico não autorizado nas
estações, impedindo troca ou furto do disco rígido do equipamento.
A execução de Scripts deve ser desabilitada através de restrições nos arquivos cscript.exe e no
wscript.exe, também se faz necessário desativar o Windows Script Runtime (SCRRUN.DLL). Vl,
verificar também, no caso da utilização do pacote office, politicas de grupo para desativar a
execução de macros (vide: http://technet.microsoft.com/en-us/library/ee857085.aspx ).
Adicionalmente, incluir os demais controles do documento anexo (Itaú_hardening-ptb_windows
Workstation.docx). Caso o sistema operacional das estações seja diferente de Windows,
consultar a área de Segurança da Informação do Itaú para avaliação dos controles necessários.
09/04/15
Pág: 9
Baseline de Análise de Risco em Fornecedores
15. Senha de BIOS / Acesso via USB:
Uma senha de BIOS deve ser definida e utilizada para que não seja possível iniciar o sistema
operacional das estações através de mídia removível. Cuidados especiais devem ser adotados
para que esta senha seja utilizada apenas em caso de manutenções.
A prevenção ao uso de USBs nas estações não deverá ser provida apenas por soluções
baseadas em ‘Filter Drivers’. Assim, desabilitar a USB na BIOS e proteger a mesma com senha,
ou desativar o hardware do USB dentro da estação (nesta última situação, desde que haja
controle robusto que impeça o acesso ao interior do gabinete da máquina).
16. Ferramenta de Captura Remota:
Para estações de trabalho dedicadas ao desenvolvimento Itaú, não deverá ser liberado a
utilização de ferramenta de captura remota.
17. Autenticação para conexão externa do usuário:
Para estações de trabalho dedicadas ao desenvolvimento Itaú, não deverá ser liberado acesso
remoto.
18. Registros e proteção de Trilhas de Auditoria:
Devem ser padronizados os registros de logs de auditoria para as atividades de usuários,
exceções e outros eventos de rede e sistemas, incluindo:
identificação (ID) do usuário;
data e o horário de entrada (logon) e saída (logoff) dos eventos-chave;
tipo do evento;
os arquivos cujo acesso foi obtido, os programas ou utilitários utilizados;
todas as operações privilegiadas (utilização de contas administrativas);
inicialização e finalização do sistema e tentativas de acesso não autorizado (intrusion
detection);
violação da política de acesso e notificações para gateways e firewalls da rede;
alertas dos sistemas proprietários de detecção de intrusão e de falhas do sistema
(alertas ou mensagens do console);
registro das exceções do sistema.
Além disso, os seguintes critérios de proteção e retenção devem ser aplicados:
09/04/15
não permitir que os administradores de sistemas e redes tenham permissão de
exclusão ou desativação dos registros de log de suas próprias atividades, seguindo
as orientações estabelecidas nas regras de segregação de funções;
Pág: 10
Baseline de Análise de Risco em Fornecedores
aplicar medidas de segregação de funções para assegurar que as pessoas
autorizadas que realizam atividades nos servidores de log sejam diferentes daquelas
que realizam a auditoria;
utilizar protocolos seguros (por exemplo: SSL/SSH) para acesso remoto aos
servidores de log;
registrar todas as atividades executadas nos servidores de log;
documentar todos os procedimentos dos servidores de log, tais como: configuração e
instalação, administração e operação, backup e manutenção, acessos a todas as
trilhas de auditoria, inicialização dos registros de auditoria;
manter um histórico do registro de log de auditoria conforme determinações de órgãos
reguladores ou por pelo menos um ano, com um mínimo de três meses,
imediatamente disponível para análise (por exemplo, online, arquivado ou recuperável
a partir do backup).
19. Criptografia de disco:
Criptografia no disco das estações de trabalho deve estar implementada, com algoritmo mínimo
3DES. O sistema operacional dessas estações deve ser Windows 7 ou superior, pois a
ferramenta ‘Bitlocker’ já se encontra nativa nas versões Enterprise ou Ultimate (a manutenção
de versões anteriores no ambiente tecnológico, Windows XP, por exemplo, torna obrigatório o
uso de uma solução de criptografia de disco).
20. Sistema Operacional atualizado com versões suportadas pelo fabricante:
Manter o parte tecnológico atualizado. Ex: Como o WinXP perde o suporte em 04/2014, o
mínimo seria Win7, no caso de plataforma Windows.
21. Sincronização dos relógios:
Implementar mecanismo que permita a sincronização dos relógios de computadores a um padrão
de tempo confiável, por exemplo, o tempo coordenado universal ("Coordinated Universal Time" UTC) ou um padrão de tempo local (Observatório Nacional - ON).
22. Controles contra códigos maliciosos:
Softwares maliciosos, tais como vírus de computador, cavalos de Tróia e "worms" de rede, devem
ser controlados através de:
09/04/15
política formal de uso de software;
homologação pela Área de Tecnologia;
software antivírus atualizado em todas as estações de trabalho e servidores;
varredura de vírus em qualquer arquivo recebido por mídias e redes;
manutenção em estações de trabalho sendo feitas somente por pessoal autorizado.
Pág: 11
Baseline de Análise de Risco em Fornecedores
23. Gestão de mudanças:
Deve haver um processo formalizado para gestão de mudanças com:
fluxo de comunicação com os detalhes das mudanças para todas as pessoas
envolvidas, incluindo o Itaú;
identificação, registro e aprovação formal das mudanças significativas;
planejamento, teste e avaliação de impactos operacionais e de segurança das
mudanças;
procedimentos de recuperação em caso de insucesso ou ocorrência de eventos
inesperados.
24. Separação dos recursos de desenvolvimento, teste e de produção:
Segregação dos ambientes de ‘desenvolvimento/teste’ dos de produção, implementando:
perfis diferentes de acesso de usuários em situação de desenvolvimento, de teste e
de produção;
proteção e controle dos dados de teste (mascaramento), não utilizando os dados de
produção;
controle para impedir que informações do ambiente de produção não sejam
transferidas para outros ambientes.
25. Cópias de segurança das informações:
Prover cópias de segurança das informações pertencentes à operação do Itaú Unibanco,
conforme periodicidade acordada, com no mínimo:
teste mensal das cópias;
identificação das mídias de armazenamento;
As mídias contendo as cópias deverão ser armazenadas em local com segurança compatível a
existente na proteção da sala de servidores, com acesso restrito ao ambiente, monitoração por
câmeras, controle de movimentação dessas mídias e necessidade de autorização (nível
gerencial) na realização dos restores dos dados.
26. Política de segurança da informação:
Um documento que possa nortear a gestão da segurança das informações corporativas deve
existir, com no mínimo:
09/04/15
aprovação pela Alta Administração;
divulgação e disponibilidade para consulta de todos os funcionários e terceiros da
empresa, através da Intranet ou outro meio;
Pág: 12
Baseline de Análise de Risco em Fornecedores
revisão uma vez ao ano, com registro da versão e da data;
definição de papéis e responsabilidades dos custodiantes de informações críticas;
definição de sanções em caso de descumprimento de com qualquer item.
27. Política de mesa limpa:
Deve haver um documento disciplinando cuidados com a política de mesa limpa,
‘definindo/orientando’ (no mínimo):
os autorizados a utilizar impressora e fax no ambiente de atendimento;
a retirada imediata de informações sensíveis e classificadas, quando impressas, das
impressoras e fax;
o local apropriado para armazenar os papéis (relatórios) e mídia eletrônica.
28. Política de tela limpa:
Assim como na política de mesa limpa, um documento deverá existir para orientar sobre a
necessidade de:
desligamento dos computadores pessoais, terminais de computador e impressoras
quando não estiverem sendo utilizados;
bloqueio da estação e da console dos servidores sempre que a pessoa se ausentar.
29. Coordenação da segurança da informação:
Uma estrutura de gerenciamento de segurança da informação deve existir na Organização,
definindo responsáveis:
pelo desenvolvimento e implementação de controles, com independência da Área de
Tecnologia;
por definir e garantir a aderência da empresa às diretrizes de Segurança da
Informação;
por identificar as ameaças significativas e a exposição da informação;
por promover a conscientização de todos os funcionários e terceiros;
monitorar os controles e realizar uma análise crítica dos incidentes.
30. Responsabilidades e Procedimentos (Incidentes de Segurança da Informação):
Quanto aos incidentes de Segurança da Informação, deve have planos de respostas para cada
um dos incidentes, prevendo:
09/04/15
falhas;
Pág: 13
Baseline de Análise de Risco em Fornecedores
códigos maliciosos;
negação de serviço;
erros resultantes de dados incompletos ou inconsistentes;
violações de confidencialidade e integridade e uso impróprio de sistemas de
informação;
definição das responsabilidades no tratamento aos incidentes;
garantia da proteção das trilhas de auditoria e evidências relacionadas ao incidente;
comunicação imediata do incidente de segurança envolvendo o Itaú Unibanco.
31. Recomendações para classificação:
Um procedimento para classificar informações, que defina um conjunto apropriado de níveis de
proteção e determine a necessidade de medidas especiais de tratamento para cada um desses
níveis deverá existir, considerando, no mínimo:
estar baseado nos requisitos contratuais ou de conformidade legal, como o PCI, ISO
27001, SOX etc.;
ter a designação dos responsáveis, custodiantes e usuários das informações;
rótulos e regras para o tratamento seguro das informações durante todo o ciclo de
vida;
critérios de armazenamento, backup, transmissão e descarte seguro para informações
impressas e lógicas;
três níveis de classificação, por exemplo, Públicas, Internas e Confidenciais,
considerando que toda informação encaminhada pelo Itaú Unibanco deve ser
classificada como Confidencial.
32. Acordos de confidencialidade:
Deve existir um documento assinado por todos os funcionários e terceiros para que estejam
cientes das suas responsabilidades de Segurança da Informação, com no mínimo:
09/04/15
aprovação pelo Jurídico da empresa;
consideração sobre riscos, controles de segurança, políticas e procedimentos para os
sistemas de informação, no que diz respeito à questão de sigilo e condições de uso
das informações disponibilizadas em rede de computadores e/ou estações de trabalho
no contrato entre as partes;
assinatura e data;
indicação de que a confidencialidade deve ser mantida mesmo após o desligamento
do funcionário ou terceiro;
Pág: 14
Baseline de Análise de Risco em Fornecedores
definição de sanções em caso de violação.
33. Conscientização, educação e treinamento em segurança da informação:
Um programa para garantir que os colaboradores sejam conscientizados em Segurança da
Informação deverá ser aplicado, desde a contratação e em campanhas periódicas, com no
mínimo:
reconhecimento do conteúdo do treinamento, através de formalização;
atualizações regulares sobre as políticas e procedimentos organizacionais;
meios de divulgação da campanha de forma que todos os funcionários e terceiros
tenham acesso;
campanha no mínimo uma vez ao ano.
34. Inventário dos ativos:
Um inventário dos ativos de TI deve manter o registro de identificação, localização e informação
armazenada. Esse controle deverá conter as seguintes informações mínimas:
ativos físicos: especificação, tipo, número de série, MAC address/hostname de
equipamentos computacionais (estação, notebook, servidor, roteador, firewall e
switch), localização (prédio, andar, operação/setor). Considerar também: mídia
magnética (fita e CD/DVD), equipamentos de comunicação (celulares) e outros
equipamentos técnicos (exemplo: no-break e gerador);
inventário de software: nome, versão de aplicativos, sistemas, ferramentas de
desenvolvimento e utilitários.
35. Remoção de propriedade:
Um fluxo formalizado de retirada e devolução de equipamentos (ex: dispositivos de comunicação
móvel), informações ou software deve estar sendo aplicado, contendo descrição do ativo e motivo
da retirada, autorizada pelo responsável pelo ativo (no mínimo gerente).
36. Controles de entrada física:
Controles de entrada apropriados devem estar implementados para assegurar que somente
pessoas autorizadas tenham acesso físico a empresa e áreas restritas (ex: Datacenter e
Operação), com no mínimo:
09/04/15
segregação das áreas críticas (ex: Datacenter e Operação);
identificação para acesso às áreas autorizadas por biometria, crachá (com foto) ou
senha;
registro de data e hora de entrada e saída, mantendo histórico dos acessos por 90
dias;
Pág: 15
Baseline de Análise de Risco em Fornecedores
monitoração de CFTV, garantindo que todas as entradas, saídas e corredores sejam
monitorados, retendo as imagens por no mínimo 90 dias;
procedimento para que terceiros que realizam serviços de suporte, tenha acesso
restrito às áreas necessárias ao atendimento, sempre monitorado por um funcionário
autorizado;
procedimento para formalização de inclusão, exclusão e revisão dos acessos
concedidos;
equipamentos posicionados de forma que o ângulo de visão seja restrito;
proibição de entrada no ambiente de Operação com pertences que possam ser
utilizados para saída de informação, tais como: papéis, canetas, bolsas, celulares,
máquinas fotográficas, filmadoras etc;
portas e janelas trancadas, quando não utilizadas, e dotadas de proteção externa;
cabeamento da rede dentro de racks trancados com chave quando não estiverem
sofrendo manutenção.
37. Continuidade de Negócios:
A empresa deverá possuir um Plano de Continuidade de Negócios, quando for previsto em
Contrato que a prestação do serviço não pode ser interrompida. Para isso deverá:
ter documento de BCP, alinhado com a necessidade do negócio do Itaú;
realizar testes de disaster recovery.
38. Inspeções periódicas de verificação de compliance aos requisitos de segurança:
A empresa deverá permitir e facilitar a realização de inspeções periódicas, pela área de
Segurança do Itaú, nas instalações que estiverem sendo usadas para atendimento aos serviços
contratados.
09/04/15
Pág: 16
ANEXO A – SEGURANÇA PARA DESENVOLVIMENTO DE APLICAÇÕES
1. INTRODUÇÃO
Esta documentação lista as melhores práticas e recomendações para o desenvolvimento de
software seguro e que podem se relacionar com diversos tipos de aplicações: Mobile, WebApp,
WebService e Desktop. É recomendado aplicar os requisitos descritos em cada uma das
subseções seguintes para mitigar os riscos de segurança no desenvolvimento de aplicações.
As seções seguintes descrevem os métodos de prevenção para tais problemas.
2. ESCOPO
Não faz parte do escopo deste documento:
Descrever práticas que não produzam benefícios diretamente relacionados à segurança das
aplicações ou que visem outros objetivos tais como desempenho, robustez e usabilidade,
entre outros.
Detalhar exaustivamente o uso seguro de recursos, estruturas e comandos das diversas
linguagens de programação utilizadas no Itaú, embora casos especiais, normalmente
justificados por sua ampla utilização ou criticidade, possam ser explorados mais
extensamente.
3. DESENVOLVIMENTO SEGURO - MELHORES PRÁTICAS GERAIS
1.
Criar e manter uma política de privacidade para o produto ou linha de serviço cobrindo
o uso de dados pessoais e disponibilize para o usuário, especialmente quando eles
fazem escolhas de consentimento.
2.
O aplicativo deve gravar os arquivos que cria em um diretório diferente daquele em que
o código executável da aplicação é armazenado.
3.
O aplicativo não deve usar cookies ou qualquer outra tecnologia web que recolha
informações de identificação do usuário, tais como listas extensas dos sites visitados
anteriormente, endereços de e-mail ou outras informações para identificar ou criar perfis
de usuários individuais.
4.
O aplicativo não pode utilizar cookie persistente como mecanismo de coleta de dados
sensíveis e controle de sessão. Esse requisito garante que as informações do usuário
não serão armazenadas de forma irregular e insegura, podendo ser utilizada por
usuários maliciosos ou atacantes, e evitando possíveis problemas com usuários.
5.
A opção autocomplete=off deve estar configurada em todos os formulários que solicitem
informações pessoais.
6.
Os formulários de cadastro ou qualquer outro parâmetro enviado à aplicação devem ser
validados pela aplicação e não por meio de scripts presentes no próprio código html do
site.
7.
Quando enviados segredos para endereços de e-mail, como um mecanismo de reset de
password. Use números randômicos limited time-only para reiniciar o acesso e envie
um e-mail de retorno assim que a senha for re-configurada. Cuidado ao permitir que
Baseline de Análise de Risco em Fornecedores
usuários registrados mudem seus endereços de e-mail – envie uma mensagem para o
e-mail anterior antes de efetuar a mudança.
8.
Certifique-se que o controle de acesso (ou autorização) é realizado em todos os passos
de um fluxo e não apenas no passo inicial de um processo.
9.
Para evitar exploração de Clickjacking, aplicar o cabeçalho “X-Frame-Options:” com
valores DENY ou SAMEORIGIN que irão bloquear respectivamente framing ou framing
de sites de origens diferentes.
10. O mecanismo de gestão de senhas da aplicação deve ser capaz de reconhecer que o
usuário está tentando utilizar uma de suas senhas anteriores e deve impedir o usuário
de escolher tal senha. O administrador deve ter a possibilidade de especificar o número
de senhas expiradas que não devem ser escolhidas pelo usuário.
11. O aplicativo deve garantir a confidencialidade da conta e dos dados do usuário. A
aplicação deve garantir que quando uma tentativa de login for realizada utilizando um
nome de usuário inválido, ela não revelará se o usuário existe ou não.
12. O aplicativo deve garantir proteção contra bloqueio inadvertido de contas. Esse requisito
garante que as contas serão bloqueadas da forma correta, sob as circunstâncias
planejadas, e não em decorrência de um ataque.
13. Deve ser avaliado a possibilidade de execução de teste de turing (CAPTCHA) durante
o cadastro ou outras funcionalidades críticas em áreas não autenticadas da aplicação,
caso seja percebido anomalias no acesso como um número específico de cadastros da
mesma origem. Esse requisito garante que será possível diferenciar usuários e sistemas
automatizados durante a criação de um novo cadastro.
14. O aplicativo deve garantir a validade de um cadastro através da verificação da validade
do e-mail ou celular cadastrado pelo usuário. Esse requisito garante que após o
preenchimento do cadastro, será feita uma validação do endereço de e-mail ou número
de celular que foi cadastrado, que funcionará atrelado a um tempo determinado de
validade, que uma vez atingida, invalidará o cadastro.
15. Toda aplicação deve possuir controles de permissão para restrição de acesso, limitando
os acessos baseando-se na premissa do privilégio mínimo. Restrição dos direitos de
acesso a IDs de usuários privilegiados ao menor número de privilégios necessários para
desempenhar as responsabilidades.
16. O aplicativo deve garantir ID exclusivo para cada indivíduo que possua direito de acesso.
Não é permitido ID compartilhado ou ID genérico. Ao garantir que todos os usuários
sejam individualmente identificados, em vez de usar um ID para vários funcionários, uma
organização consegue manter a responsabilidade individual pelas ações e uma trilha de
auditoria eficaz por funcionário. Isso ajudará a apressar a resolução e a contenção de
problemas quando ocorrer mau uso ou tentativa mal-intencionada.
17. Toda aplicação deve garantir que uma conta com várias tentativas de acessos incorretas
em um pequeno espaço de tempo seja bloqueada por um tempo mínimo ou exigida outra
forma de confirmação de identidade. Se uma conta estiver bloqueada em função de uma
pessoa tentar continuamente adivinhar a senha, os controles para atrasar a reativação
dessas contas bloqueadas evitarão que o indivíduo mal-intencionado continue a tentar
adivinhar a senha.
09/04/15
Pág: 18
Baseline de Análise de Risco em Fornecedores
18. Não permita que o processo de login comece de uma página não criptografada. Sempre
inicie o processo de login de uma segunda página criptografa ou de um novo código de
sessão, para prevenir o roubo de credenciais ou da sessão, phishing e ataques de
fixação de sessão.
19. Considere gerar uma nova sessão após uma autenticação que obteve sucesso ou
mudança do nível de privilégio.
20. Use períodos de expiração de prazo que automaticamente realizam logout em sessões
inativas, bem como o conteúdo das informações que estão sendo protegidas.
21. Não exponha nenhum identificador de sessão ou qualquer parte válida das credenciais
em URLs e logs (não regrave ou armazene informações de senhas de usuários em logs).
22. Além de invalidar os tokens adequadamente (no lado do servidor), durante os principais
eventos do aplicativos, também é fundamental que os próprios tokens sejam gerados
corretamente. Eles devem ser suficientemente longos e complexos, e pseudoaleatórios,
de modo a ser resistente aos ataques de adivinhação\antecipação.
23. Nunca permitir contas padrão, as senhas padrão ou vazio, ou grupo de contas de acesso
ao sistema;
24. Utilizar a autenticação de dois fatores sempre que a informação que está sendo
manipulada é sensível e que o acesso pode ser concedido a partir de várias origens não
confiáveis;
25. Usar algoritmos de hash sobre a senha dos usuários antes de armazena-la.
26. Especifique o cabeçalho X-Content-Type-Options: nosniff para garantir que o
browser não tente detector um um Content-Type diferente o que foi enviado.
4. REVISÃO SEGURA DE CÓDIGO – REQUISITOS GERAIS
1.
Deve ser tomado como base e guia para revisão e certificação de software a
metodologia ASVS (Application Security Verification Standard -2014) considerando o
nível 3 para os requisitos a serem verificados.
2.
O código deve ser revisado com o intuito que sejam removidos componentes, plug-ins
e trechos desnecessários. Esses artefatos podem introduzir vulnerabilidades ao
software.
3.
Aplicações que incluem códigos de terceiros devem incluir as versões mais recentes do
código, com todos os patches de segurança aplicados de acordo com o processo de
implantação aprovado.
4.
O software, código ou componentes deve ser revisado a fim de entregar ao Banco um
produto livre de vulnerabilidades comuns, conforme especificado pelo Common
Vulnerabilities and Exposures (CVE®) - O padrão para nomes de vulnerabilidades de
segurança da informação que podem ser acessados em http://cve.mitre.org/.
5.
O software, código ou componentes deve ser revisado a fim de entregar ao Banco um
produto livre de brechas conhecidas, tal como especificado na Common Weakness
Enumeration (CWE) - Um dicionário dos tipos de vulnerabilidades conhecidas que
podem ser acessadas em http://cwe.mitre.org/.
09/04/15
Pág: 19
Baseline de Análise de Risco em Fornecedores
6.
O software, código ou componentes deve ser revisado a fim de entregar ao Banco um
produto livre de qualquer tipo de agente malicioso, incluindo bombas lógicas,
ransonwares, spywares e trojan.
7.
O software, código ou componentes deve ser revisado a fim de entregar ao Banco um
produto livre de credenciais hardcoded e chaves de criptografia em texto claro nas linhas
do código ou em arquivos de configuração.
8.
O software, código ou componentes deve ser revisado a fim de entregar ao Banco um
produto livre de maintenance hooks (backdoors).
9.
O software, código ou componentes deve ser revisado a fim de entregar ao Banco um
produto livre de códigos de depuração (debugging code) e flags.
10. O software, código ou componentes deve ser revisado a fim de entregar ao Banco um
produto livre de comentários desnecessários ou informação sensível nos comentários
do código.
11. O software, código ou componentes deve ser revisado a fim de entregar ao Banco um
produto livre de contas de testes antes do processo de implantação da aplicação em
produção.
5. DESENVOLVIMENTO SEGURO - MELHORES PRÁTICAS ESPECÍFICAS
5.1.
PROTEÇAO PARA WEBSERVICES
As seguintes práticas não devem ser tomadas como únicos métodos para proteção de aplicações
baseadas em WebServices mas sim como complemento específico para esse tipo de tecnologia,
tome como referencia todas sessões desse documento para construção segura de uma aplicação
baseada em WebServices.
12. Considere usar apenas a chave de sessão de token ou API para manter o estado do
cliente em um cache do lado do servidor. Isto é diretamente equivalente à forma como
web apps normais fazem, e há uma razão para isso é moderadamente seguro.
13. Anti-replay. Atacantes vão copiar e colar uma sessão e tornar-se outra pessoa.
Considere o uso de uma chave de criptografia de tempo limitado, fechado contra a chave
de sessão de token ou API, data, hora e endereço IP de entrada. Em geral, implemente
alguma proteção de armazenamento do cliente local do token de autenticação para
mitigar ataques de repetição.
14. Proteja os métodos HTTP. Uma política ou controle de acesso pra determinando token
de sessão/API com acesso a uma coleção de recursos, usuário ou ação deve ser
definido para cada método HTTP.
15. Whitelist Metodos Permitidos. Da mesma forma que o requisito anterior é importante que
o serviço restrinja os métodos permitidos para determinada entidade, todos os outros
métodos devem retornar o código de resposta adequado (por exemplo, 403 Forbidden).
16. Proteja ações privilegiadas e coleções de recursos sensíveis. O token de sessão ou API
key devem ser enviados juntamente como parâmetro de cookie ou no body para garantir
09/04/15
Pág: 20
Baseline de Análise de Risco em Fornecedores
que recursos privilegiados ou ações sejam devidamente protegidos contra uso não
autorizado.
17. Web services precisam garantir que a saída enviada aos clientes é codificada para ser
consumida como dados e não como scripts. Isto torna-se muito importante quando os
clientes de web services usam a saída para renderizar páginas HTML, direta ou
indiretamente por meio de objetos AJAX.
18. A mesma questão acima é relevante quanto a JSON encoders que devem evitar
execução de código JavaScript no browser ou Node.js no servidor. No caso de XML
encoding deve sempre ser utilizado um XML serializer para garantir que o conteúdo
enviado ao browser é “parseável” e não contém injeção de XML.
19. Proteja ações privilegiadas e coleções de recursos sensíveis. O token de sessão ou API
key devem ser enviados juntamente como parâmetro de cookie ou no body para garantir
que recursos privilegiados ou ações sejam devidamente protegidos contra uso não
autorizado.
20. Log e conte falhas de validação de input, qualquer um pode executar chamadas no Web
Service, então considere implementar rate limiting para falhas na validação de input em
determinado período de tempo. Implemente esse controle parametrizável para
acompanhar a evolução do negócio.
21. É difícil de executar a maioria dos ataques se os valores permitidos apenas são true ou
false, um número, ou ainda um de um pequeno número de valores aceitáveis.
Especifique o tipo de dados de entrada o mais cedo possível.
22. Valide o Contente-Type. O cliente nunca deve assumir o Content-Type (ex.:
application/xml ou appication/json), mas sempre verifique se o cabeçalho Content-Type
e o conteúdo são do mesmo tipo. A falta de cabeçalho Content-Type ou um cabeçalho
Content-Type inesperado, deve resultar no servidor rejeitar o conteúdo com uma
resposta 406 Not Acceptable.
23. O servidor de autorização deve considerar a limitação do número de tokens de acesso
concedidos por usuário. Deve ser incluída uma quantidade entropia adequada nos
"códigos" de autorização. Um invasor pode esgotar o pool de "códigos" de autorização
direcionando repetidamente o navegador do usuário a solicitar autorização de "códigos"
ou tokens de acesso.
24. Log e conte falhas de validação de input, qualquer um pode executar chamadas no Web
Service, então considere implementar rate limiting para falhas na validação de input em
determinado período de tempo. Implemente esse controle parametrizável para
acompanhar a evolução do negócio.
5.2.
PROTEÇÃO PARA APLICATIVOS MÓVEIS
As seguintes práticas não devem ser tomadas como únicos métodos para proteção de aplicações
baseadas em Mobile mas sim como complemento específico para esse tipo de tecnologia, tome
como referencia todas as sessões desse documento para construção segura de uma aplicação
baseada em Mobile.
09/04/15
Pág: 21
Baseline de Análise de Risco em Fornecedores
1.
Não guarde senhas ou segredos no binário do aplicativo. Não use um segredo para
integração com a infraestrutura (como uma senha embutida no código). Binários de
aplicativos móveis podem ser facilmente baixados e sobrepujados por engenharia
reversa.
2.
Não permitir o uso de versões com vulnerabilidades. Forçar atualização do aplicativo
quando funções críticas e bugs de segurança tiverem sido identificados e corrigidos.
3.
Não autorizar código/app a executar como root/privilégios de administrador.
4.
Devido a requisitos de uso off-line, podem ser solicitados a aplicativos móveis
autenticação local ou verificações de autorização no código do aplicativo móvel. Se este
for o caso, os desenvolvedores devem adicionar controles locais de verificação de
integridade dentro do código para detectar qualquer alteração não autorizada.
5.
Autenticação persistente (Remember Me) funcionalidade implementada dentro de
aplicações móveis nunca devem guardar a senha de um usuário no dispositivo.
6.
Sempre que possível, garantir que todas as solicitações de autenticação sejam
executadas no lado do servidor. Após a autenticação bem sucedida, os dados do
aplicativo serão carregado para o dispositivo móvel. Isso irá garantir que os dados do
aplicativo só estarão disponível após a autenticação bem-sucedida.
7.
A aplicação deve forçar o fechamento de uma sessão inativa por determinado período
de tempo. Este período deve ser determinado de acordo com o negócio da aplicação.
8.
O aplicativo mobile deve garantir que tokens de sessão de alta entropia e imprevisíveis
sejam implementados.
9.
Toda aplicação deve garantir controle sobre número máximo de tentativas sem sucesso
de logins em um determinado período de tempo. O mecanismo de Identificação e
Autenticação deve permitir ao administrador a configuração do número máximo de
tentativas de login, configurável por utilizador ou por regra, dentro de um determinado
período de tempo.
10. Aplicações que possuam identificação ou autenticação implementadas com base em ID
de usuário, senha estática e dados pessoais de usuários, deverão garantir
codificação/criptografia em todos os campos sensíveis ou garantir o uso de one-time
cookie criptografado. Os cookies nunca poderão ser persistentes.
11. O aplicativo deve garantir a identificação e autenticação sempre que uma nova sessão
for estabelecida. A aplicação não deve armazenar senhas do usuário em cookies, scripts
client ou server-side, ou qualquer outra forma automatizada de login de usuário para que
o usuário não tenha que digitar sua senha de login, quando iniciar uma nova sessão.
12. Nunca armazene credenciais no sistema de arquivos do telefone. Forçar o usuário a se
autenticar usando um sistema web ou API de login padrão (HTTPS) para a aplicação
em cada abertura e garantir que o tempo limite de sessão está definido para atender os
requisitos mínimos de experiência do usuário.
13. Evite confiar exclusivamente em chaves de criptografia ou descriptografia codificados
ao armazenar os ativos de informações sensíveis.
14. Considere fornecer uma camada adicional de criptografia além de qualquer mecanismos
de encriptação padrão fornecido pelo sistema operacional.
09/04/15
Pág: 22
Baseline de Análise de Risco em Fornecedores
15. Proteja o binário da aplicação. Siga técnicas de codificação segura para os seguintes
componentes de segurança dentro do aplicativo móvel:
Controles de detecção para Jailbreak;
Controles de Checksum;
Controles de Certificados fixados;
Controle de detecção para Debugger;
Para mitigar outros riscos técnicos residuais expostos acima o ideal é que os desenvolvedores ou a
empresa terceira impeça de forma adequada que um usuário mal intencionado possa analisar o
aplicativo usando técnicas estáticas ou dinâmicas de análise e engenharia reversa; e o app deve ser
capaz de detectar durante o runtime que código foi adicionado ou alterado a partir do que ele conhece
sobre a sua própria integridade durante a compilação. Ele deve ser capaz de reagir de forma
adequada durante o runtime a uma violação da integridade do código.
5.3.
PROTEÇAO PARA BANCO DE DADOS
1.
Usar consultas parametrizadas para acesso as informações do banco de dados;
2.
Utilizar validação de entrada e codificação de saída e assegurar a abordagem de meta
caracteres. Se houver falha, o comando não deverá ser executado no banco de dados;
3.
Realizar a codificação (escaping) de meta caracteres em instruções SQL;
4.
A aplicação deve usar o menor nível possível de privilégios ao acessar o banco de
dados;
5.
Usar credenciais seguras para acessar o banco de dados;
6.
Não incluir strings de conexão na aplicação. As strings de conexão devem estar em um
arquivo de configuração separado, armazenado em um sistema confiável e as
informações devem ser criptografadas;
7.
Usar procedimentos armazenados (stored procedures) para abstrair o acesso aos dados
e permitir a remoção de permissões das tabelas no banco de dados;
8.
Encerrar a conexão assim que possível;
9.
Remover ou modificar senhas padrão de contas administrativas. Utilizar senhas
robustas (pouco comuns ou difíceis de deduzir) ou implementar autenticação de
múltiplos fatores. Desativar qualquer funcionalidade desnecessária no banco de dados,
como serviços não utilizados. Instalar o conjunto mínimo de componentes ou de opções
necessárias (redução da superfície de ataque);
10. Eliminar o conteúdo desnecessário incluído por padrão pelo fornecedor como esquemas
e bancos de dados de exemplo;
11. Desativar todas as contas criadas por padrão e que não sejam necessárias para suportar
os requisitos de negócio;
09/04/15
Pág: 23
Baseline de Análise de Risco em Fornecedores
12. A aplicação deve conectar-se ao banco de dados com diferentes credenciais de
segurança para cada tipo de necessidade como, por exemplo, usuário, somente leitura,
convidado ou administrador;
5.4.
GERENCIAMENTO E EXECUÇÃO MALICIOSA DE ARQUIVOS
Em muitas plataformas, frameworks permitem o uso de referências a objetos externos, como
referências a URLs ou a arquivos de sistema. Quando o dado é insuficientemente verificado, isto
pode levar a uma inclusão arbitrária remota que será processada ou invocar um conteúdo hostil
pelo servidor web.
1.
Usar um mapeamento indireto de objetos de referência. Por exemplo, quando um nome
de arquivo parcial é uma vez usado, considere um hash para a referência parcial.
2.
Limitar os tipos de arquivos que podem ser enviados para aceitar somente os
necessários ao propósito do negócio;
3.
Validar se os arquivos enviados são do tipo esperado, através da validação dos
cabeçalhos, pois, realizar a verificação apenas pela extensão não é suficiente;
4.
Não salvar arquivos no mesmo diretório de contexto da aplicação Web. Os arquivos
devem ser armazenados no servidor de conteúdos ou no banco de dados.
Recomendamos a utilização de um Sandbox para essas finalidade;
5.
Prevenir ou restringir o carregamento de qualquer arquivo que possa ser interpretado
ou executado pelo servidor Web;
6.
Desativar privilégios de execução nos diretórios de armazenamento de arquivos;
7.
Implantar o carregamento seguro nos ambientes UNIX por meio da montagem do
diretório de destino como uma unidade lógica, usando o caminho associado ou o
ambiente de “chroot”;
8.
Ao referenciar arquivos, usar uma lista branca (whitelist) de nomes e de tipos de arquivos
permitidos. Realizar a validação do valor do parâmetro passado e caso ele não
corresponda ao que é esperado, rejeitar a entrada ou utilizar um valor padrão;
9.
Não passar caminhos de diretórios ou de arquivos em requisições. Usar algum
mecanismo de mapeamento desses recursos para índices definidos em uma lista prédefinida de caminhos;
10. Nunca enviar o caminho absoluto do arquivo para o lado cliente de uma aplicação;
11. Certificar-se de que os arquivos da aplicação e os recursos estão definidos somente
com o atributo de leitura;
12. Verificar os arquivos que os usuários submeterem através do mecanismo de
carregamento em busca de vírus e malwares;
5.4.1. EXEMPLOS:
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-0360
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-5220
09/04/15
Pág: 24
Baseline de Análise de Risco em Fornecedores
5.5.
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-4722
5.4.2. REFERENCIAS:
CWE: CWE-98 (PHP File Inclusion), CWE-78 (OS Command Injection), CWE-95
(Evalinjection), CWE-434 (Unrestricted file upload)
WASC Threat Classification:
http://www.webappsec.org/projects/threat/classes/os_commanding.shtml
OWASP Guide:
http://www.owasp.org/index.php/File_System#Includes_and_Remote_files
OWASP Testing Guide,
https://www.owasp.org/index.php/Testing_Directory_traversal/file_include_(OTG-AUTHZ001)
FALHAS DE INJEÇÃO
1. Falhas de injeção acontecem quando os dados que o usuário passa de entrada são
enviados como parte de um comando ou consulta. Os atacantes confundem o
interpretador para o mesmo executar comandos manipulados enviando dados
modificados.
2. Evite o uso de interpretadores quando possível. Caso invoque um interpretador, o
método chave para evitar injeções está no uso de APIs seguras, como por exemplo,
queries parametrizadas e bibliotecas de mapeamento objeto relacional (ORM).
3. Se uma API parametrizada não estiver disponível, você deve cuidadosamente filtrar os
caracteres especiais utilizando a sintaxe para esse interpretador;
4. “Lista branca" ou validação de entrada positiva também é recomendada, mas não é uma
defesa completa já que muitas aplicações requerem caracteres especiais em suas
entradas. Se os caracteres especiais são exigidos, somente as abordagens 1. e 2. acima
tornarão a sua utilização segura;
5. Localize erros de canonicalização. As entradas devem ser decodificadas e convertidas
para a representação interna corrente antes de ser validada. Certifique-se que sua
aplicação não decodifica a mesma entrada duas vezes. Tais erros podem ser usados
para ultrapassar esquemas de whitelist pela introdução de entradas perigosas após sua
validação.
6. Quando há falha de validação, a aplicação deve rejeitar os dados fornecidos;
7. Validar dados provenientes de redirecionamentos. Os atacantes podem incluir conteúdo
malicioso diretamente para o alvo do mecanismo de redirecionamento, podendo assim
contornar a lógica da aplicação e qualquer validação executada antes do
redirecionamento;
8. Realizar o tratamento (sanitização), baseado em contexto, de todos os dados
provenientes de fontes não confiáveis usados para construir as consultas SQL;
9. Testar a utilização de funções escape no SGBD e em stored procedures caso não cause
overhead. Testes de desempenho antes da utilização dessas funções são altamente
recomendados.
09/04/15
Pág: 25
Baseline de Análise de Risco em Fornecedores
10. Se a rotina de validação padrão não abordar as seguintes entradas, então elas devem
ser verificadas:
a) Verificar bytes nulos (%00);
b) Verificar se há caracteres de nova linha (%0d, %0a, \r, \n);
5.5.1. PROTEÇÃO – SQL INJECTION
1. Nunca execute queries formadas a partir de entradas ou parâmetros fornecidos pelo
usuário sem a devida verificação.
2. Valide e corrija o conteúdo de toda variável passada para o banco.
3. Verifique se a entrada tem o tipo de dado esperado.
4. Utilize sempre aspas para a entrada de dados passada ao banco.
5. Nunca disponibilizar parâmetros de usuário e senha do banco de dados em interface
com o usuário.
5.5.2. PROTEÇÃO – OS COMMAND INJECTION
1. Verificar toda entrada de dados.
2. Nunca passar entrada de dados não verificada como parâmetro para comandos de
sistema.
3. Nunca passar entrada de dados não verificada como parâmetro para pipes.
4. Verifique se a entrada de dados contém comandos de sistema.
5. Verificar todos os argumentos passados em system calls.
6. Utilizar sempre full pathnames.
7. Sempre configurar o diretório de trabalho corrente.
8. Verificar retorno de funções.
9. Garantir que as bibliotecas utilizadas sejam íntegras e livres de códigos maliciosos.
10. Utilizar sempre que possível; recursos de timeout em leituras e escritas de rede.
11. Verificar as informações retornadas na comunicação entre processos pais e filhos.
12. Utilizar mecanismos de autenticação/verificação na comunicação inter-processos.
13. Aplicações não devem ser executadas com privilégios de administrador. Se necessário,
isolar a porção crítica do código de forma que somente ela seja executada com privilégio
adicional. Se possível, adotar o conceito de Privilege Separation, onde porções de
código que demandam níveis de privilégios diferentes são executadas por processos
diferentes.
5.5.3. PROTEÇÃO – PATH TRAVERSAL/DISCLOSURE
1. Tratar a entrada em busca de meta caracteres que descrevem trilhas, como “.”, “/” e “\”.
09/04/15
Pág: 26
Baseline de Análise de Risco em Fornecedores
2. Procure utilizar trilhas absolutas e extensões hard-coded na aplicação.
5.6.
5.5.4. EXEMPLOS
http://cwe.mitre.org/data/definitions/77.html
http://cwe.mitre.org/data/definitions/78.html
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-5121
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-4953
5.5.5. REFERÊNCIAS
CWE: CWE-89 (SQL Injection), CWE-77 (Command Injection), CWE-90 (LDAP Injection),
CWE-91 (XMLInjection), CWE-93 (CRLF Injection).
WASC Threat Classification:
http://www.webappsec.org/projects/threat/classes/os_commanding.shtml
http://www.webappsec.org/projects/threat/classes/ldap_injection.shtml
http://www.webappsec.org/projects/threat/classes/sql_injection.shtml
OWASP - Command Injection and OS Command Injection
https://www.owasp.org/index.php/OS_Command_Injection
https://www.owasp.org/index.php/Command_Injection
OWASP Code Review Guide:
http://www.owasp.org/index.php/Reviewing_Code_for_SQL_Injection
OWASP – SQL Injection and Query Parameterization:
http://www.owasp.org/index.php/SQL_Injection
https://www.owasp.org/index.php/Query_Parameterization_Cheat_Sheet
OWASP Guide:
http://www.owasp.org/index.php/Guide_to_SQL_Injection
https://www.owasp.org/index.php/Testing_for_SQL_Injection_(OTG-INPVAL-006)
5.5.6. REVISÂO DE CÒDIGO
OWASP - Injection:
https://www.owasp.org/index.php/Reviewing_Code_for_SQL_Injection
https://www.owasp.org/index.php/Reviewing_Code_for_OS_Injection
https://www.owasp.org/index.php/Reviewing_Code_for_Data_Validation
FALHA DE AUTENTICAÇÃO E GERENCIAMENTO DE SESSÃO
Falhas nesta área geralmente envolvem a falha na proteção de credenciais e nos tokens da
sessão durante seu tempo de vida. Estas falhas podem estar ligadas à roubo de contas de
usuários ou administradores, contornando controles de autorização e de responsabilização,
causando violações de privacidade. As principais recomendações são descritas a seguir::
1. Um conjunto único de controles fortes de autenticação e gerenciamento de sessão. Tais
controles devem procurar:
a) Cumprir todos os requisitos de autenticação e gerenciamento de sessão definidos
no Padrão de Verificação de Segurança da Aplicação do OWASP (ASVS), áreas V2
(Autenticação) e V3 (Gerenciamento de Sessão);
09/04/15
Pág: 27
Baseline de Análise de Risco em Fornecedores
b) Ter uma interface simples para os desenvolvedores. Considere o ESAPI
Authenticator e User APIs como bons exemplos para simular, usar ou construir como
base;
2. Grande esforço também deve ser feito para evitar falhas de XSS (Cross Site Scripting)
que podem ser utilizados para roubar os IDs de sessão;
3. Todas as funções administrativas devem ser isoladas do acesso dos usuários comuns
e o gerenciamento de contas devem ser tão seguras quanto o mecanismo de
autenticação principal;
4. A funcionalidade de saída (logout) deve encerrar completamente a sessão ou conexão
associada;
5. A funcionalidade de saída (logout) deve estar disponível em todas as páginas que
requerem autenticação;
6. Gerar um novo identificador de sessão quando houver uma nova autenticação;
7. Não permitir conexões simultâneas com o mesmo identificador de usuário;
8. Gerar um novo identificador de sessão e desativar o antigo periodicamente. Isso pode
mitigar certos cenários de ataques de sequestro de sessão, quando o identificador de
sessão original for comprometido;
9. Considere o uso de uma chave de criptografia de tempo limitado, fechado contra a chave
de sessão de token ou API, data, hora e endereço IP de entrada. Em geral, implemente
alguma proteção de armazenamento do cliente local do token de autenticação para
mitigar ataques de repetição.
10. Não permita que o processo de login comece de uma página não criptografada. Sempre
inicie o processo de login de uma segunda página criptografa ou de um novo código de
sessão, para prevenir o roubo de credenciais ou da sessão, phishing e ataques de
fixação de sessão.
11. Considere gerar uma nova sessão após uma autenticação que obteve sucesso ou
mudança do nível de privilégio.
12. Use períodos de expiração de prazo que automaticamente realizam logout em sessões
inativas, bem como o conteúdo das informações que estão sendo protegidas.
13. Use somente funções de proteção secundárias eficientes, tais como perguntas e
respostas e reset de senha, pois estas credenciais são como senhas, nomes de usuários
e tokens. Aplique one-way hash nas respostas para prevenir ataques nos quais a
informação pode ser descoberta.
14. Configurar o atributo "secure" para cookies que trafegam informações sensíveis
incluindo cookies de sessão que são transmitidos através de uma conexão TLS;
15. Configurar os cookies com o atributo “HttpOnly”;
16. Assegure-se que todas as páginas tenham um link de logout. O logout deve destruir
todas as sessões e cookies de sessão. Considere os fatores humanos: não pergunte
por confirmação, pois usuários acabarão fechando a aba ou janela ao invés de sair com
sucesso.
09/04/15
Pág: 28
Baseline de Análise de Risco em Fornecedores
17. Não exponha nenhum identificador de sessão ou qualquer parte válida das credenciais
em URLs e logs (não regrave ou armazene informações de senhas de usuários em logs).
18. Verifique a senha antiga do usuário quando ele desejar mudar a senha.
19. Não confie em credenciais falsificáveis como forma de autenticação, como endereços
de IP ou máscaras de rede, endereço de DNS ou verificação reversa de DNS,
cabeçalhos da origem ou similares.
5.6.1. PROTEÇÃO - REPLAY DE SESSÃO
1. Gere identificadores de sessão que sejam difíceis de aplicar engenharia reversa,
criptografia forte e Message Digest robusto.
2. Preveja o uso de SSL na aplicação para proteção do cookie em seu trânsito entre o
navegador e o servidor. Garanta que todos os cookies tenham o campo secure
habilitado.
3. Preveja uma função de encerramento de sessão ou logout, que expire todos os cookies
e tokens de autenticação.
5.6.2. PROTEÇÃO – HIJACKING DE SESSÃO
1. Re-autentique usuário antes que ações críticas sejam executadas.
2. Se possível, tente vincular tokens de sessão a cada instância de navegador, por
exemplo, utilizando um hash do endereço MAC do computador cliente e o process id do
navegador.
3. Siga as contra medidas para prevenir ataques de Força Bruta e Replay de Sessão.
5.6.3. EXEMPLOS
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-6145
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-6229
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-6528
5.6.4. REFERÊNCIAS
CWE: CWE-287 (Authentication Issues), CWE-522 (Insufficiently Protected Credentials),
CWE-311 (Reflection attack in an authentication protocol), others.
WASC Threat Classification:
http://www.webappsec.org/projects/threat/classes/insufficient_authentication.shtml
http://www.webappsec.org/projects/threat/classes/credential_session_prediction.shtml
http://www.webappsec.org/projects/threat/classes/session_fixation.shtml
OWASP Guide:
http://www.owasp.org/index.php/Guide_to_Authentication
OWASP Code Review Guide:
http://www.owasp.org/index.php/Reviewing_Code_for_Authentication
http://www.owasp.org/index.php/Testing_for_authentication
09/04/15
Pág: 29
Baseline de Análise de Risco em Fornecedores
5.7.
RSNAKE01:
http://ha.ckers.org/blog/20070122/ip-trust-relationships-xss-and-you
5.6.5. REVISÃO DE CÓDIGO
OWASP – Integridade de Sessão
https://www.owasp.org/index.php/Reviewing_Code_for_Session_Integrity
PROTEÇÃO CONTRA CROSS-SITE SCRIPTING (XSS)
O XSS permite que atacantes executem script no navegador da vítima, podendo sequestrar
sessões de usuários, desfigurar web sites, inserir conteúdo hostil, conduzir ataques de roubo de
informações pessoais - conhecido como phishing e obter o controle do navegador do usuário
usando um script mal intencionado, tal como um malware.
1. A opção apropriada é filtrar adequadamente todos os dados não confiáveis com base
no contexto HTML (corpo, atributo, JavaScript, CSS ou URL) no qual os dados serão
colocados;
2. “Lista branca" ou validação de entrada positiva também é recomendada pois ajuda a
proteger contra XSS, mas não é uma defesa completa, já que muitas aplicações
requerem caracteres especiais em sua entrada. Tal validação deve, tanto quanto
possível, validar o tamanho, caracteres, formato, e as regras de negócio sobre os dados
antes de aceitar a entrada;
3. Não use validação de blacklist para detectar XSS na entrada ou codificação de saída. A
procura ou troca de poucos caracteres ,"<" ">" e outros caracteres similares ou frases
como script, é fraco e tem sido explorado com sucesso. Mesmo uma tag <b> não
verificada é insegura em alguns contextos. O XSS possui um conjunto surpreendente
de variantes que torna simples ultrapassar validações de blacklist.
4. Implementar a Política de Segurança de Conteúdo (CSP): CSP é um mecanismo do
browser que permite criar recursos de whitelists para o lado do cliente utilizado pela
aplicação Web. Por exemplo: JavaScript, CSS, imagens e etc. CSP via cabeçalho HTTP
especial instrui o Browser para executar somente ou “renderizar” recursos desta fonte.
Por exemplo, o cabeçalho CSP abaixo permite conteúdo apenas de um domínio, o seu
domínio próprio e subdomínios: Content-Security-Policy: default-src 'self'
*.mydomain.com
5. Determinar se o sistema suporta conjuntos de caracteres estendidos UTF-8 e, em caso
afirmativo, validar após efetuar a descodificação UTF-8;
6. Validar todos os dados provenientes dos clientes antes do processamento, incluindo
todos os parâmetros, campos de formulários, conteúdos das URLs e cabeçalhos HTTP,
como, por exemplo, os nomes e os valores dos Cookies;
7. Cuidado com os erros de conversão. As entradas devem ser decodificadas e convertidas
para a representação interna corrente antes de ser validada. Certifique-se que sua
aplicação não decodifica a mesma entrada duas vezes. Tais erros podem ser usados
para ultrapassar esquemas de whitelist pela introdução de entradas perigosas após
serem checados.
09/04/15
Pág: 30
Baseline de Análise de Risco em Fornecedores
5.8.
5.7.1. EXEMPLOS
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-4206
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-3966
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-5204
5.7.2. REFERÊNCIAS
CWE: CWE-79, Cross-Site scripting (XSS)
WASC Threat Classification:
http://www.webappsec.org/projects/threat/classes/crosssite_scripting.shtml
OWASP – Cross Site Scripting:
http://www.owasp.org/index.php/Cross_Site_Scripting
OWASP – Testing for XSS,
http://www.owasp.org/index.php/Testing_for_Cross_site_scripting
OWASP Stinger Project (A Java EE validation filter)
http://www.owasp.org/index.php/Category:OWASP_Stinger_Project
OWASP PHP Filter Project:
http://www.owasp.org/index.php/OWASP_PHP_Filters
OWASP Encoding Project:
http://www.owasp.org/index.php/Category:OWASP_Encoding_Project
Klein, A., DOM Based Cross Site Scripting:
http://www.webappsec.org/projects/articles/071105.shtml
Fortify Javascript Hijacking:
http://james.padolsey.com/wp-content/uploads/javascript_hijacking.pdf
OWASP Enterprise Security API:
http://www.owasp.org/index.php/ESAPI
5.7.3. REVISÃO DE CÓDIGO
OWASP XSS
https://www.owasp.org/index.php/Reviewing_Code_for_Cross-Site_Scripting
REFERÊNCIA DIRETA INSEGURA A OBJETOS
Uma referência direta a um objeto acontece quando um desenvolvedor expõe uma referência a
um objeto de implementação interna, como por exemplo, um arquivo, diretório, registro na base
de dados ou chave, uma URL ou um parâmetro de um formulário. Um atacante pode manipular
diretamente referências a objetos para acessar outros objetos sem autorização, a não ser que
exista um mecanismo de controle de acesso.
1. Uso de referência indireta a objetos por usuário ou sessão. Isso impede que o atacante
atinja diretamente os recursos não autorizados. Por exemplo, em vez de utilizar a chave
de banco de dados do recurso, uma lista de seis recursos autorizados para o usuário
atual poderia utilizar os números de 1 a 6 para indicar qual valor o usuário selecionou.
A aplicação tem que mapear as referências indiretas por usuário de volta para a chave
do banco de dados real no servidor;
09/04/15
Pág: 31
Baseline de Análise de Risco em Fornecedores
2. Verificar o acesso. Cada utilização de uma referência direta a objeto de uma origem não
confiável deve incluir uma verificação de controle de acesso para garantir que o usuário
está autorizado para o objeto requisitado;
3. Garantir o controle de autorização em todas as requisições, inclusive em scripts do lado
servidor;
4. Se for permitida a existência de sessões autenticadas por longos períodos de tempo,
fazer a revalidação periódica da autorização do usuário para garantir que os privilégios
não foram modificados e, caso tenham sido, realizar o registro em log do usuário e exigir
nova autenticação;
5. Verificar a integridade de parâmetros para verificar quais parâmetros não foram
mudados. Essa verificação de integridade pode ser adicionada como um parâmetro
adicional utilizando criptografia ou técnicas de hashing;
6. A melhor solução é usar um valor de índice ou um mapa de referência para prevenir
ataques de manipulação de parâmetro.
7. Outra solução é verificar a integridade de parâmetros para verificar quais parâmetros
não foram mudados. Essa verificação de integridade pode ser adicionada como um
parâmetro adicional utilizando criptografia ou técnicas de hashing.
5.9.
5.8.1. EXEMPLOS
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-0329
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-4369
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-0229
5.8.2. REFERÊNCIAS
CWE: CWE-22 (Path Traversal), CWE-472 (Web Parameter Tampering)
WASC Threat Classification:
http://www.webappsec.org/projects/threat/classes/abuse_of_functionality.shtml
http://www.webappsec.org/projects/threat/classes/insufficient_authorization.shtml
OWASP Testing Guide:
https://www.owasp.org/index.php/Testing_for_business_logic
https://www.owasp.org/index.php/Testing_Directory_traversal/file_include_(OTG-AUTHZ001)
GST Assist attack details:
http://www.abc.net.au/7.30/stories/s146760.htm
INFRAESTRUTURA E AMBIENTE
As recomendações primárias são para estabelecer todas as medidas:
1. Um processo de hardening recorrente que torne fácil e rápido de implantar outro
ambiente que está devidamente blindado. Ambientes de desenvolvimento, controle de
qualidade e produção devem ser todos configurados de forma idêntica (com senhas
diferentes usadas em cada ambiente). Este processo deve ser automatizado para
minimizar o esforço necessário para configurar um novo ambiente seguro;
09/04/15
Pág: 32
Baseline de Análise de Risco em Fornecedores
2. Certifique-se de que a plataforma de back-end (servidor) está funcionando com uma
configuração blindada (hardening) com os últimos patches de segurança aplicados no
SO, Web Server e outros componentes de aplicação.
3. Um processo para se manter a par e implantar todas as novas atualizações e correções
de software em tempo hábil e para cada ambiente. Este processo, deve incluir todas as
bibliotecas de código;
4. Uma arquitetura de aplicação forte que forneça a separação segura e eficaz entre os
componentes;
5. Considere executar varreduras e fazer auditorias periodicamente para ajudar a detectar
erros futuros de configuração ou correções ausentes;
6. Verificar o acesso. Cada utilização de uma referência direta a objeto de uma origem não
confiável deve incluir uma verificação de controle de acesso para garantir que o usuário
está autorizado para o objeto requisitado;
7. Criar uma Política de Controle de Acesso para documentar as regras de negócio da
aplicação, tipos de dados e critérios ou processos de autorização para que os acessos
possam ser devidamente concedidos e controlados. Isto inclui identificar requisitos de
acessos, tanto para os dados, como para os recursos do sistema;
8. As contas de serviço ou contas de suporte a conexões provenientes ou destinadas a
serviços externos devem possuir o menor privilégio possível;
9. Usar mecanismos de tratamento de erros que não mostrem informações de depuração
(debug) ou informações da pilha de exceção;
10. Usar mensagens de erro genéricas e páginas de erro personalizadas;
11. O tratamento de erros lógicos associados com os controles de segurança devem, por
padrão, negar o acesso;
12. Todos os controles de log devem ser implementados em um sistema confiável, por
exemplo, centralizar todo o processo no servidor;
13. Não armazenar informações sensíveis nos registros de logs, como detalhes
desnecessários do sistema, identificadores de sessão e senhas;
14. Remover aplicações desnecessárias e documentação do sistema que possam revelar
informações importantes para os atacantes;
15. Desativar a listagem de diretórios;
16. Definir quais métodos HTTP, GET ou POST, a aplicação irá suportar e se serão tratados
de modo diferenciado nas diversas páginas da aplicação;
17. Desativar as extensões HTTP desnecessárias como, por exemplo, o WebDAV. Caso
seja necessário o uso de alguma extensão HTTP com o propósito de suportar a
manipulação de arquivos, utilize um mecanismo de autenticação conhecido,
padronizado e bem testado;
18. Remover informações desnecessárias presentes nos cabeçalhos de resposta HTTP e
que podem estar relacionadas com o sistema operacional, versão do servidor web e
frameworks de aplicação;
09/04/15
Pág: 33
Baseline de Análise de Risco em Fornecedores
19. Servidores que recebem qualquer conexão da Internet, por exemplo http ou https, não
devem possuir aplicações ou acessos liberados para que esses efetuem conexões de
saída à Internet ou qualquer rede pública.
20. Deve ser implementada apenas uma função principal por componente, host virtual ou
host físico. Temos que garantir que servidores desempenharão somente uma função
principal da aplicação garantindo arquitetura “componentizada” e segurança em
camadas.
21. Levar em consideração a construção de um ambiente Sandbox (separado da infra em
produção) para integração de parceiros.
22. A arquitetura deve ser concebida de forma a garantir o deployment dinâmico e sem
interrupção do serviço durante os deliveries (exemplo: stick balance entre front-end e
back-end).
23. Garantir o isolamento de ambientes de desenvolvimento, homologação e produção, bem
como dos serviços corporativos. Isso quer dizer que os dados não podem ser
compartilhados entre as redes e tampouco transferidos.
24. Assegure que as comunicações entre os elementos da infraestrutura, como servidores
de web e sistemas de banco de dados, estão propriamente protegidas pelo uso de
camadas de transporte de segurança ou de criptografia de nível de protocolo para
credenciais e informações de valor intrínseco.
5.9.1. LOGS PARA AUDITORIA
1. As aplicações devem logar todos os eventos de segurança relevantes configurados pelo
administrador, para o seu próprio log seguro de auditoria/eventos ou serviço de logs
centralizado, ou transmitir esses dados de forma segura para uma facilidade de coleta
de auditoria externa;
2. A funcionalidade de auditoria usada pela aplicação deve permitir que o administrador
selecione os eventos que serão logados e a informação que será capturada sobre cada
evento;
3. A facilidade de auditoria utilizada pela aplicação deve anexar a identificação individual
do usuário causador - ou associado com a causa, do evento de auditoria para o registro
de auditoria daquele evento;
4. Os controles de acesso utilizados pela aplicação devem proibir ler, escrever, excluir,
executar, mover ou copiar os dados de auditoria de acesso da aplicação por processos
ou usuários não autorizados;
5. Todos os acessos aos relatórios devem ser registrados em log;
6. Todas as tentativas de login ao banco de dados, que falharem, deverão se logadas;
7. Uma das coisas mais importantes de se implantar é um log de auditoria para controles
de autenticação e autorização. Devemos ser capazes de responder facilmente as
seguintes questões: Quem logou, quando, qual origem, que transações foram
executadas e que dados foram acessados?
5.10.
ARMAZENAMENTO CRIPTOGRÁFICO INSEGURO
09/04/15
Pág: 34
Baseline de Análise de Risco em Fornecedores
Os perigos da criptografia insegura, o uso de TLS/SSL e proteção de dados estão muito além
das informações descritas nesse documento. Dito isto, no mínimo, faça todas as
recomendações:
1. Considerando que você pretende proteger os dados de ameaças (como por exemplo,
ataque interno ou de usuário externo), tenha a certeza de criptografar todos os dados
sensíveis em repouso e em trânsito de uma forma que iniba estas ameaças;
2. Não armazene dados sensíveis desnecessariamente. Descarte-os o mais rápido
possível. Dados que você não tem não podem ser roubados;
3. Certifique-se que o nível utilizado nos algoritmos e chaves são fortes, e que o
gerenciamento de chaves está aplicado adequadamente. Considere utilizar os módulos
criptográficos validados do FIPS-140-2;
4. Desabilite o auto completar em formulários de coleta de dados sensíveis e desabilite o
cache em páginas que contenham dados sensíveis;
5. Se a aplicação gerenciar um repositório de credenciais, esta deverá garantir que as
senhas são armazenadas na base de dados somente sob a forma de resumo/hash da
senha na forma de one-way salted hashes e que a tabela/arquivo que armazena as
senhas e as próprias chaves são manipuladas apenas pela aplicação;
6. Desativar a funcionalidade de auto completar nos formulários que contenham
informações sensíveis, inclusive no formulário de autenticação;
7. Desativar o cache realizado no lado cliente das páginas que contenham informações
sensíveis. O parâmetro Cache-Control: no-store, pode ser usado em conjunto com o
controle definido no cabeçalho HTTP “Pragma: no-cache”, que é menos efetivo, porém
compatível com HTTP/1.0;
8. Toda aplicação que requeira uso de criptografia deve garantir a validação de
certificados, recusando e não utilizando certificados inválidos, auto-assinados ou
revogados. As aplicações que requerem uso de criptografia devem garantir que as
validações e revogações dos certificados sejam sempre realizadas corretamente.
9. Não crie algoritmos de criptografia. Somente use algoritmos aprovados publicamente
como, AES, Criptografia de chaves publicas RSA, SHA-256 ou melhores para hash.
10. Não use algoritmos fracos, como MD5/SHA1. Use mecanismos mais seguros como
SHA-256 ou melhores.
11. Hashing não é criptografia. Se um atacante souber qual algoritmo de hashing está sendo
usado, ele pode fazer um ataque de força bruta para crackear o valor do hash.
12. Crie chaves offline e armazene chaves privadas e simétricas com extremo cuidado.
Nunca transmita chaves privadas ou simétricas em canais inseguros.
13. As chaves de criptografia das informações devem ser de propriedade e administração
do Itaú Unibanco.
5.10.1. EXEMPLOS
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-6145
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-1664
09/04/15
Pág: 35
Baseline de Análise de Risco em Fornecedores
5.11.
5.10.2. REFERÊNCIAS
CWE: CWE-311 (Failure to encrypt data), CWE-326 (Weak Encryption), CWE-321 (Use of
hard-coded Cryptographic key), CWE-325 (Missing Required Cryptographic Step)
OWASP:
https://www.owasp.org/index.php/Guide_to_Cryptography
OWASP Guide:
http://www.owasp.org/index.php/Insecure_Storage
https://www.owasp.org/index.php/How_to_protect_sensitive_data_in_URL%27s
PCI Data Security Standard:
https://www.pcisecuritystandards.org/pdfs/pci_dss_portuguese.pdf
Bruce Schneier:
http://www.schneier.com/
CryptoAPI Next Generation:
http://msdn2.microsoft.com/en-us/library/aa376210.aspx
FALHAS AO RESTRINGIR ACESSO A URLs
Segurança por obscuridade não é suficiente para proteger dados e funções sensíveis em uma
aplicação. Verificações de controles de acesso devem ser executadas antes de permitir uma
solicitação a uma função sensível, na qual garante que somente o usuário autorizado acesse a
respectiva função.
O principal método de ataque para esta vulnerabilidade é chamado de navegação forçada
(Forced browsing), na qual envolve técnicas de adivinhação de links (Guessing) e força bruta
(Brute force), para achar páginas desprotegidas.
É comum que aplicações utilizem códigos de controle de acesso por toda a aplicação, resultando
em um modelo complexo que dificulta a compreensão para desenvolvedores e especialistas em
segurança. Esta complexidade torna provável a ocorrência de erros e algumas páginas não
serão validadas, deixando a aplicação vulnerável.Veja abaixo alguns métodos para proteger a
aplicação:
1. Tendo o tempo para planejar a autorização criando uma matriz para mapear as regras
e as funções da aplicação é o passo primordial para alcançar a proteção contra acessos
não autorizados.
2. Aplicações web devem garantir controle de acesso em todas as URLs e funções de
negócio. Não é suficiente colocar o controle de acesso na camada de apresentação e
deixar a regra de negócio desprotegida. Também não é suficiente verificar uma vez o
usuário autorizado e não verificar novamente nos passos seguintes.
3. Garanta que a matriz do controle de acesso é parte do negócio, da arquitetura e do
design da aplicação
4. Garanta que todas URLs e funções de negócio são protegidas por um mecanismo de
controle de acesso efetivo que verifique as funções e direitos do usuário antes que
qualquer processamento ocorra.
5. Certifique-se que este processo é realizado em todos os passos do fluxo e não apenas
no passo inicial de um processo, pois pode haver vários passos a serem verificados.
09/04/15
Pág: 36
Baseline de Análise de Risco em Fornecedores
6. Preste muita atenção em arquivos de includes/bibliotecas, especialmente se eles
possuem extensões executáveis como php. Sempre que possível, devem ser mantidos
fora da raiz web. Devem ser verificados se não estão sendo acessados diretamente, por
exemplo, verificando por uma constante que pode somente ser criada pelo requisitante
de uma biblioteca.
7. Não suponha que usuários não estarão atentos ao acessar URLs ou APIs escondidas
ou especiais. Sempre se assegure que ações com privilégios altos e administrativos
estarão protegidas.
8. Bloqueie acesso a todos os tipos de arquivos que a sua aplicação não deva executar.
Este filtro deve seguir a abordagem accept known good na qual apenas são permitidos
tipos de arquivos que a aplicação deva executar, como por exemplo .html .pdf, .php. Isto
irá bloquear qualquer tentativa de acesso a arquivos de log, arquivos XML, entre outros,
aos quais se espera nunca serem executados diretamente.
9. Configure uma política de segurança e habilite o Java Security Manager.
10. Mantenha o antivírus e as correções de segurança atualizadas para componentes como
processadores XML, processadores de texto, processadores de imagem, entre outros
que manipulam arquivos fornecidos por usuários.
5.12.
5.11.1. EXEMPLOS
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-0207-0147
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-0131
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-1227
5.11.2. REFERÊNCIAS
CWE: CWE-325 (Direct Request), CWE-288 (Authentication Bypass by Alternate Path),
CWE-285 (Missingor Inconsistent Access Control)
WASC Threat Classification:
http://www.webappsec.org/projects/threat/classes/predictable_resource_location.shtml
OWASP:
http://www.owasp.org/index.php/Forced_browsing
OWASP Guide:
http://www.owasp.org/index.php/Guide_to_Authorization
COMO EVITAR CROSS-SITE REQUEST FORGERY (CSRF)
Um ataque CSRF força o navegador logado da vítima a enviar uma requisição para uma
aplicação web vulnerável, que realiza a ação desejada em nome da vítima.
1. A prevenção de um CSRF geralmente requer a inclusão de um token imprevisível em
cada requisição HTTP. Tais tokens devem, no mínimo, ser únicos por sessão de usuário.
2. A opção preferida consiste em incluir um token único em um campo oculto. Isso faz com
que o valor seja enviado no corpo da requisição HTTP, evitando-se a sua inserção na
URL, que é mais propensa a exposição.
09/04/15
Pág: 37
Baseline de Análise de Risco em Fornecedores
3. O token único pode ser incluído na própria URL, ou em parâmetros da URL. Contudo,
tal posicionamento corre um risco maior já que a URL será exposta ao atacante,
comprometendo assim o token secreto.
4. Exigir que o usuário autentique novamente, ou provar que são realmente um usuário
(por exemplo, através de CAPTCHA) também pode proteger contra CSRF.
5. Não use requisições GET (URLs) para dados sensíveis ou para realizar transações de
valores. Use somente métodos POST quando processar dados sensíveis do usuário.
Entretanto, a URL pode conter token randômico à medida que este cria uma URL única,
que torna o CSRF quase impossível de se realizar.
6. Verifique o Content-Type para proteger chamadas para funções AJAX e web services.
7. Mesmo o cabeçalho HTTP Referer podendo ser spoofado, verificar o Referer é uma boa
prática para detectar tentativas de hacking.
5.13.
5.12.1. EXEMPLOS
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-0192
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-5116
5.12.2. REFERÊNCIAS
CWE: CWE-352 (Cross-Site Request Forgery)
WASC Threat Classification: No direct mapping, but the following is a close match:
http://www.webappsec.org/projects/threat/classes/abuse_of_functionality.shtml
OWASP CSRF:
http://www.owasp.org/index.php/Cross-Site_Request_Forgery
OWASP Testing Guide:
https://www.owasp.org/index.php/Testing_for_CSRF_(OTG-SESS-005)
OWASP CSRF Guard and PHP CSRF Guard:
http://www.owasp.org/index.php/CSRF_Guard
http://www.owasp.org/index.php/PHP_CSRF_Guard
RSnake, "What is CSRF?":
http://ha.ckers.org/blog/20061030/what-is-csrf/
Microsoft, ViewStateUserKey details:
http://msdn2.microsoft.com/enus/library/ms972969.aspx#securitybarriers_topic2
5.12.3. REVISÃO DE CÓDIGO
OWASP – CSRF
https://www.owasp.org/index.php/Reviewing_Code_for_Cross-Site_Request_Forgery
REDIRECIONAMENTOS E ENCAMINHAMENTOS INVÁLIDOS
Evitar tais falhas é extremamente importante já que elas são o alvo favorito de phishers tentando
obter a confiança do usuário.Uso seguro de redirecionamentos e encaminhamentos pode ser feito
de várias formas:
1. Simplesmente evitar usá-los;
09/04/15
Pág: 38
Baseline de Análise de Risco em Fornecedores
2. Se forem usados, não envolva parâmetros de entrada do usuário no cálculo do destino.
Normalmente, isto pode ser feito;
3. Se os parâmetros de destino não podem ser evitados, tenha certeza que o valor
fornecido é válido, e autorizado para o usuário;
4. Recomenda-se que qualquer parâmetro de destino seja um valor mapeado, e não a URL
real ou parte dela, e que o código do lado do servidor traduza este mapeamento para a
URL de destino. Aplicações podem usar ESAPI para substituir o método sendRedirect()
para certificarem-se de que todos os destinos do redirecionamento são seguros.
5.14.
5.13.1. EXEMPLOS
https://cwe.mitre.org/data/definitions/601.html
5.13.2. REFERÊNCIAS
Open Redirect
https://www.owasp.org/index.php/Open_redirect
WASC Threat Classification: URL Redirector Abuse:
http://projects.webappsec.org/w/page/13246981/URL%20Redirector%20Abuse
EVITANDO O BUFFER OVERFLOWS/OVERRUNS
Os itens a seguir devem ser observados quanto ao desenvolvimento de aplicações que irão lidar
com a leitura de dados e transferi-los para buffers de memória:
1. Use tratamento de buffers e funções de string seguras sempre que necessitar transferir
dados aos mesmos;
2. Ative qualquer defesa do sistema operacional para a pilha de execução, como a
prevenção de parâmetros da pilha de execução no Solaris, Data Execution Prevention
(DEP) no Windows e PaX para Linux;
3. Utilizar técnicas de endereço randômico (ASLR) para reduzir a possibilidade de
execução depois de um estouro de buffer;
4. Se C++ estiver sendo utilizado, sempre que possível substituir qualquer função de string
de baixo nível em C, por classes de string atualizadas em C++;
5. Verificar os limites do buffer caso as chamadas à função sejam realizadas em ciclos e
verificar se não há nenhum risco de ocorrer gravação de dados além do espaço
reservado;
6. Liberar a memória alocada de modo apropriado após concluir a sub-rotina
(função/método) e em todos pontos de saída;
7. Verificar o conteúdo, formato e tamanho da entrada de dados.
8. Ao fazer cópias de posições de memória, verificar se o destino é capaz de conter toda a
origem.
5.14.1. REFERENCIA
09/04/15
Pág: 39
Baseline de Análise de Risco em Fornecedores
CWE-122 (Heap-based Buffer Overflow):
https://cwe.mitre.org/data/definitions/122.html
CWE-121 (Stack-based Buffer Overflow):
https://cwe.mitre.org/data/definitions/121.html
WASC - Buffer Overflow :
http://projects.webappsec.org/w/page/13246916/Buffer%20Overflow
OWASP Buffer Overflow:
https://www.owasp.org/index.php/Buffer_Overflow
OWASP - Testing Guide
https://www.owasp.org/index.php/Testing_for_Heap_Overflow
https://www.owasp.org/index.php/Testing_for_Stack_Overflow
5.14.2. REVISÃO DE CÓDIGO
OWASP - Code for Buffer Overruns and Overflows:
https://www.owasp.org/index.php/Reviewing_Code_for_Buffer_Overruns_and_Overflows
5.15.
TRATAMENTO DE DADOS CONTRA INTEGER AND ARITHMETIC OVERFLOWS
Os itens a seguir devem ser observados no desenvolvimento de aplicativos que lidam com as
operações aritméticas e manipulação de números inteiros:
1. Validar os resultados que vão decidir sobre a alocação de memória para garantir que o
resultado está no intervalo, antes de realizar as alterações de memória;
2. Evitar utilizar tipos inteiros para os limites de matriz que definem o tamanho da memória
de dados;
3. Validar todas as operações que resultarão na identificação dos índices a serem
utilizados, para garantir que eles estão dentro da faixa esperada;
5.15.1. EXEMPLOS
http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-2192
http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-2191
http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-2063
5.15.2. REFERÊNCIAS
CWE-190: Integer Overflow or Wraparound
https://cwe.mitre.org/data/definitions/190.html
OWASP - Integer overflow:
https://www.owasp.org/index.php/Integer_overflow
WASC Threat Classification – Integer Overflows:
http://projects.webappsec.org/w/page/13246946/Integer%20Overflows
Standard for Binary Floating-Point Arithmetic:
http://grouper.ieee.org/groups/754/
09/04/15
Pág: 40
Baseline de Análise de Risco em Fornecedores
5.16.
FORMAT SPRING NÃO CONTROLADA
Os itens a seguir devem ser observados no desenvolvimento de aplicações que irão lidar com a
formatação de sequências de entrada do usuário:
1. Definir a formatação de strings estáticas, sempre que possível, não confiando na entrada
do usuário;
2. Se a entrada do usuário é necessária, validar e restringir o tipo de dados inseridos,
considerando todos os caracteres de escape ou quaisquer outros símbolos indesejados
como inválidos;
3. Revisar dados de internacionalização provenientes de arquivos externos ou informações
de log sendo capturadas para entradas inválidas;
5.17.
5.16.1. EXEMPLOS
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-9157
5.16.2. REFERÊNCIAS
CWE-134 - Uncontrolled Format String
https://cwe.mitre.org/data/definitions/134.html
OWASP Testing for Format String:
https://www.owasp.org/index.php/Testing_for_Format_String
OWASP Format string attack:
https://www.owasp.org/index.php/Format_string_attack
CONDIÇÕES DE CONCORRÊNCIA
Os itens a seguir devem ser observados quanto ao desenvolvimento de aplicativos que lidam
com recursos globais ou multithreading (multi-processamento), que podem acabar causando
condições de concorrência. Uma race condition ocorre quando um par de chamadas de rotina
em uma aplicação não executam em modo sequencial, sobrepujando as regras de negócio. É
um evento dentro do software que pode se tornar uma vulnerabilidade de segurança se as
chamadas não são executadas na ordem correta.
1. Evitar o máximo possível usar os recursos globais ou arquivos que também estão em
uso por outros aplicativos que você não tem controle;
2. Sempre bloquear ou impedir que outros acessem o recurso global no momento em que
sua aplicação irá lidar com ela;
3. Evitar criar arquivos temporários em pastas graváveis e impor o uso de nomes aleatórios
para a criação de tais arquivos;
4. Utilizar mecanismos de bloqueio para evitar requisições simultâneas para a aplicação
ou utilizar um mecanismo de sincronização para evitar condições de concorrência;
09/04/15
Pág: 41
Baseline de Análise de Risco em Fornecedores
5. Implementar de alguma forma um mecanismo de bloqueio no código que altera ou lê
dados persistentes.
6. Criar checagens de sanidade no recurso bloqueado. Se não houver mecanismos de
bloqueio, usar flags para impor seu próprio esquema de bloqueio quando os recursos
estão sendo usados por outras threads em execução.
7. Garantir que o bloqueio ocorre antes da execução, ao invés de depois dela.
5.17.1. REFERÊNCIAS
CWE-362- Concurrent Execution using Shared Resource with Improper Synchronization
https://cwe.mitre.org/data/definitions/362.html
CWE-364 – Signal Handler Race Condition
https://cwe.mitre.org/data/definitions/364.html
CWE-368 – Context Switching Race Condition
https://cwe.mitre.org/data/definitions/368.html
CWE-366 – Race Condition within a Thread
https://cwe.mitre.org/data/definitions/366.html
OWASP Testing Guide – Race Condititions:
https://www.owasp.org/index.php/Testing_for_Race_Conditions_%28OWASP-AT-010%29
5.17.2. REVISÃO DE CÓDIGO
OWASP Reviewing Code for Race Conditions:
https://www.owasp.org/index.php/Reviewing_Code_for_Race_Conditions
5.18.
COMUNICAÇÕES INSEGURAS
A criptografia, geralmente TLS/SSL, deve ser usada em todas as conexões autenticadas,
especialmente páginas web com acesso via internet, mas também conexões com o backend. Os
itens a seguir devem ser observados quanto ao desenvolvimento de aplicativos que devem
enviar informações sobre a rede:
1. Evitar o uso de protocolos sem criptografia (SMTP, FTP, POP3, IMAP, SNMP e HTTP)
para enviar dados através da rede;
2. Usar métodos conhecidos de criptografia como SSL e TLS para a transmissão de
informações confidenciais, evitando criar seu próprio código de criptografia;
3. Utilizar um mecanismo de autenticação forte para a identificação de clientes e
servidores, para garantir a identidade de ambas as partes de ambos os lados. Se estiver
usando protocolos conhecidos como SSL ou IPSec, o protocolo em si já fornece os
meios para realizar essa autenticação, utilizar certificados;
4. Filtrar os parâmetros que contenham informações sensíveis, provenientes do “HTTP
referer”, nos links para sites externos;
5. Utilizar um padrão único de implementação TLS configurado de modo apropriado;
09/04/15
Pág: 42
Baseline de Análise de Risco em Fornecedores
6. Quando ocorrer alguma falha nas conexões TLS, o sistema não deve fornecer uma
conexão insegura;
7. Os certificados TLS devem ser válidos, possuírem o nome de domínio correto, não
estarem expirados e serem instalados com certificados intermediários, quando
necessário;
8. Quando utilizar TLS/SSL, o faça para toda a sessão. Proteger somente as credenciais
de logon é insuficiente porque dados e informações da sessão também devem estar
criptografados. Garanta esse controle implementando o HSTS (HTTP Strict Transport
Security).
9. Assegure que as comunicações entre os elementos da infra-estrutura, como servidores
de web e sistemas de banco de dados, estão propriamente protegidas pelo uso de
camadas de transporte de segurança ou de criptografia de nível de protocolo para
credenciais e informações de valor intrínseco.
5.18.1. EXEMPLOS
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-6430
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-4704
http://www.schneier.com/blog/archives/2005/10/scandinavian_at_1.html
5.18.2. REFERÊNCIAS
CWE: CWE-311 (Failure to encrypt data), CWE-326 (Weak Encryption), CWE-321 (Use of
hard-coded cryptographic key), CWE-325 (Missing Required Cryptographic Step)
OWASP Testing Guide, Testing for SSL / TLS,
https://www.owasp.org/index.php/Testing_for_Weak_SSL/TLS_Ciphers,_Insufficient_Transp
ort_Layer_Protection_(OTG-CRYPST-001)
OWASP Guide:
http://www.owasp.org/index.php/Guide_to_Cryptography
Found stone - SSL Digger
http://www.mcafee.com/br/downloads/free-tools/ssldigger.aspx
09/04/15
Pág: 43
Download
