Perguntaram-me há algum tempo que tipo de coisas que podem ser consideradas quando se analisa a Internet Banking.
Abaixo está uma lista de coisas que poderiam ser consideradas. Foi apenas um cérebro despejo e, como tal, podem não estar completos.
Não subestime o valor de norma para sua infra-estrutura, configuração site, mecanismo de banco de dados configuração / Arquitetura, encenação ambiente e desenvolvimento / QA ambientes.
Alguns pensamentos:
- Muitos não bloquear contas após X falhou logins, isto é normalmente feito para o bem de atendimento ao cliente, mas deixa o sistema vulnerável.
- E todas as outras coisas que o esperado para um remoto sessão de login (forçado senha mudanças, envelhecimento, etc))
- Ferramentas como Brutus pode ser utilizar a força bruta hack sessões autenticadas.
- Muitos permitem sessão números de sequência para ser incrementada, permitindo que um usuário autenticado para ler outras cliente sessão.
- Estes podem ser lado do servidor, lado cliente, baseado biscoito, etc
- Tire alguém para checar o desenvolvimento de metodologias e do código a ser usado.
- Base de Dados query strings podem ser colocadas em teste entrada campos, permitindo que a tabela lixeiras navegador.
- Confira todas as páginas servidas são seguras e conter a autenticação do usuário bandeiras.
- Customer data may not be segregated, this needs to be checked.
- Os dados dos clientes não devem residir no Web Server.
- Um segmento diferente para o principal sistema bancário.
- Webserver deve ser dual homed ou equivalente (VLAN algumas técnicas são boas)
- Separe privadas e públicas placas de rede, monitorização / backup / administração
- Infra-estrutura "set-up para negar explicitamente entrada / saída portas, monitoramento IP privado & a fugir à rede.
- A todos os dados segregação pontos assegurar regras estão em vigor, que aprecia os tráfego embora esse ponto.
- Todos os dados dos clientes quando possível deve ser obtida a partir de um seguro de dados back-end.
- Essa pode ser uma encenação ambiente. ou seja, sem o principal sistema bancário.
- Isso permite geralmente para transações em tempo real para aparecer para o cliente.
- Muitas operações podem ser agrupadas em realidade. (internos ou externos ao banco)
- Assegurar normas adequadas foram set-up sobre firewalls.
- Deve haver regras de entrada e saída de firewalls e roteadores de filtragem.
- Não permitir que qualquer infra-estrutura no front end para permitir conexões remotas administrativa. (Telnet, etc)
- Use a porta serial para se conectar a um servidor ou back-end do terminal server.
- Assegurar que uma separada desenvolvimento / QA / meio de produção e sistema adequado processo está em vigor.
- Serviços não utilizados pelo sistema são ativos
- Eles devem ser desativados.
- Port scan da infra-estrutura de apoio (roteadores / comutadores) e servidor (es).
- Investigar os motivos de todas as portas abertas.
- Não utilize a principal porta de entrada para parceiros confiáveis acesso (clearing / RAS / etc)
- Fazer tudo isso normal e as verificações do IIS NT verificações (scripts de exemplo, mudança de gestão, remendar metodologias, etc)
- Assegurar a negação de serviço precauções foram tomadas em consideração para todas as infra-estruturas e do servidor de equipamentos.
- Verificar a adequação dos procedimentos utilizados escalada.
- Olhe para o acompanhamento em tempo real e de alerta.
- Olhe para a responsabilidade matriz.
- Olhe para a apropriação das questões.
- Considere a montante (s) transportadora vulnerabilidade (denial of service, spoofing IP, DNS hacking, etc)
- Considere engenharia social do cliente, administração, contabilidade parceiro / sistemas / infra-estrutura.
- Helpdesk procedimentos e políticas e / ou suplentes tecnologias (Caller ID, Gateway IP, etc.)
- Use senhas dinâmicas quando possível (SecureID, TACACS, etc.)
- Use túneis criptografados quando necessário (IPSec, Firewall 1, etc)
- Considere a olhar para outro cliente métodos de autenticação para melhorar os métodos existentes.
- Digital cert, endereço IP bloqueado a conta, etc
- Considerar uso do CVV ou CVN para bancários emitidos cartões.
- Reflectir sobre o modo como as senhas são distribuídas / mudou para os clientes.
- Texto simples e-mail, telefone, etc
- Pode ser mudado senhas on-line?
- É adicionais autenticação usado entre as seções de serviços, uma vez autenticado?
- Considere o que o cliente tem acesso a uma vez autenticado.
- Olhe para SWIFT, LBTR, inter-transferências bancárias, o acesso aos cartões de crédito, etc
- Se um atacante não chegar, o que pode fazer?
- Use as técnicas para garantir páginas, informações cliente em cache não estão em ISP, ou sistema cliente.
- Essas são bandeiras que pode ser definida dentro de páginas.
- Normalmente é o SSL em cache, proxy, mas alguns vendedores foram brincar com as técnicas para o fazer.
- Cache de SSL páginas no sistema cliente pode ser ligado em alguns navegadores.
- Maio bancos utilizar uma aplicação Java (ou similar) para todos os clientes applet interação, restringindo todas as questões caching.
- Assegurar suporte de papel e on-line responsabilidade cláusulas estão disponíveis todos os endereços são efectuadas áreas.
- Assegurar dentro do processo de inscrição cliente bancário passivo é reduzida.
- Tenho visto declarações como "utilizar este sistema por sua conta e risco, a responsabilidade por qualquer responsabilidade ou reclamação será NÃO ... ..."
- Não é muito focada cliente, mas isso é o que seu departamento jurídico da recomendável.
Todas as anteriores podem afetar a segurança e / ou de uma operação on-line banking system.
Outras coisas a considerar:
- Externos ao desenvolvimento e suporte do pedido.
- Propriedade e gestão do hardware e aplicativos
- Publishing pontos de novos conteúdos (interna / privada / confiável rede ou Internet)
- Topologia de front end. Ie Segurança Arquitetura documento deve ser posto em prática e gerido de forma adequada.
- AP testes realizados são limitados quando mudanças são feitas para o meio ambiente? ou seja integrado em Alterar AP processo de gestão.
- Database acesso. Ela é tamponado ou é ao vivo para o núcleo sistemas bancários.
- Que facilidades são prestados? O débito direto + Cartão de Crédito + SWIFT + ... .... Ponderar diferentes cenários para o seu ataque, dependendo da característica.
- Que outros serviços são partilhadas dentro do segmento de rede que o Internet Banking está executando o serviço. Esta pode ser usada para comprometer o Internet Banking site. por exemplo. diferentes suportes / empresa / desenvolvimento organizações com diferentes estratégias de segurança / perfis.
- Pense em todos os serviços de apoio externo dentro de você AP. Olhem interno / externo DNS envenenamento oportunidades, correio, etc Qual IPS's que eles utilizam já o ISP qualquer oportunidade de sistemas de acesso ou o apoio a serviços que possam afectar o Internet Banking.
- Dependendo do tamanho do Banco, muitas organizações não usam o mesmo grupos de apoio e de infra-estrutura do aplicativo. Como resultado conexões externas para a infra-estrutura pode ser previsto um apoio externo para administrar a organização da infra-estrutura.
- Olhe para o negócio ea autenticação do usuário métodos e caminhos (lado cliente certs, ID segura, smart card, etc). Considere duas fator de autenticação e modernos de identificação do utilizador métodos. por exemplo. qual é o seu prato preferido, para além da normal nomes de usuários e senhas. Do sistema de administração do pessoal usar senhas dinâmicas (secureID, etc)?
- Veja se o Internet Banking aplicação envia e-mails para usuários que podem conter informações interessantes.
- Melhor acesso à petição pode ser geralmente adquirida após o acesso ao sistema. ou seja, buscar uma legítima conta no sistema. Eu descobri que algumas amostras / administração telas foram restritas a usuários autenticados apenas.
- Considere a engenharia social Help desk para ter uma conta de redefinição de senha.
