Exportar (0) Imprimir
Expandir Tudo
Expandir Minimizar

10 Dicas para Projetar, Construir e Implantar Aplicações Web Mais Seguras

Publicado em: 8 de setembro de 2005

Por Matt Clapham

Veja outras colunas de Gerenciamento de Segurança (em inglês).

Nesta página

Resumo
Introdução
1. Nunca Confie Diretamente na Entrada do Usuário
2. Serviços não Devem Ter Acesso ao Administrador ou ao Sistema
3. Siga as Melhores Práticas do SQL Server
4. Proteja os Bens
5. Inclua Recursos de Relatórios, Registros e Auditoria
6. Analise o Código Fonte
7. Implemente Componentes Usando Defesa em Profundidade
8. Desligue Mensagens de Erro em Profundidade para Usuários Finais
9. Conheça as 10 Leis de Administração de Segurança
10. Tenha um Plano de Reação para Incidentes na Segurança
Recursos

Resumo

Este documento fornece um conjunto introdutório de orientações para projetar, construir e implantar aplicações e serviços web de maneira mais segura. O público alvo são aqueles começando a trabalhar com aplicações web ou com segurança em TI. Não se trata, de forma alguma, de uma lista completa, mas sim de um ponto de partida para aplicações e serviços web.

Introdução

Este documento oferecer dicas de melhores práticas coletadas de várias fontes. Ele foi criado para ser usado durante a implantação de aplicações web na família de sistemas operacionais Microsoft Windows, mas pode ser usado para outros fins também. Os tópicos foram divididos em 10 orientações (dicas) que foram então subdivididas e detalhadas.

1. Nunca Confie Diretamente na Entrada do Usuário

A verdade é que alguém, em algum lugar, tentará atacar sua aplicação web. Toda a entrada de usuário deve ser cuidadosamente validada. No mínimo, ele precisa ser checado para extensão, formato, tipo e alcance.

Segurança do Design no Produto

Leve a segurança em consideração desde o início do processo de design; não tente acrescentá-la depois. Pense como um invasor e crie um modelo de segurança desde o primeiro rascunho do projeto. A modelagem da ameaça é parte integral do processo de design. A análise das ameaças em potencial antes de escrever o código pode reduzir a necessidade para mitigação posterior e o custo para o conserto. O design cuidadoso pode reduzir também a área de exposição da superfície de ataque para usuários mal-intencionados.

Não Tente Simplesmente Validar a Entrada do Usuário no Cliente

A sua aplicação web faz toda a validação de inputs através de JavaScript do lado cliente? Como a camada da lógica empresarial reagirá quando um invasor usar uma forma direta de submissão, sem as checagens do lado cliente? A entrada do usuário deve ser validado na aplicação web porque qualquer invasor irá provavelmente contornar as checagens do lado cliente assim que tiverem sido descobertos. Uma expressão regular que apenas permite dados bem formados e rejeita qualquer solicitação mal formada é uma maneira prática e ágil para validar a entrada e pode ser prontamente usada com o próximo ponto.

Revalide os Dados em Cada Camada

A re-checagem da validade do tipo e da forma dos dados nas camadas de armazenamento de dados e lógica empresarial causará uma leve redução no desempenho, mas é uma medida excelente de defesa em profundidade. Além disso, ela ajuda a minimizar as falhas de uma camada ou evitar que afete as demais. Se a revalidação prejudicar muito o desempenho, considere a autenticação da fonte de dados para que se possa acompanhá-la de volta para outro componente confiável do sistema como um todo.

Não Presuma que Ataques Internos Não Ocorrerão

Todos os seus funcionários são completamente confiáveis, certo? Não entregue o jogo às pessoas de dentro. Confie, mas verifique. Isto é especialmente importante em grandes organizações ou para aplicações web internas que apresentam informações de identificação pessoal como números de identidade ou cartão de crédito. Mantenha as informações confidenciais na base do need to know.

2. Serviços não Devem Ter Acesso ao Administrador ou ao Sistema

Muitas vezes os desenvolvedores e avaliadores são executados como administradores locais dado seu caminho de resistência mínima. Esta prática é desempenhada para o desenvolvimento da web, onde é permitida a execução de serviços como Sistema Local porque as coisas quebrariam caso contrário. Permitir a execução de serviços com altos privilégios é uma falha fatal porque permite que um pequeno erro numa aplicação web se transforme num sistema totalmente comprometido. Certifique-se de que nenhuma das aplicações web que você criou requer direitos administrativos para os servidores onde são executadas.

Use Contas de Usuários com Privilégios Mínimos

Os pools de serviços e aplicações web devem ser executados como um usuário local, usuário do domínio, ou uma das contas pré-definidas (Serviço da Rede e Serviço Local). O MSDN tem um ótimo artigo explicando a diferença (veja a seção de Recursos deste documento). Isto reduzirá a magnitude do que um serviço comprometido pode causar. A configuração do sistema para que s contas de serviços tenham apenas o acesso mínimo ao domínio exigido minimizará o impacto caso ocorra um comprometimento.

Use uma Conta de Usuário do Domínio para o Acesso Entre-Máquinas (Intermachine)

Crie um usuário no domínio do servidor web e use-o para executar a aplicação web. Configure o pool de aplicações do Internet Information Services (IIS) 6.0 para executar como a conta selecionada e use-o para solicitações de autenticação de servidores web anônimos. A conta de usuário também pode ser usada para controlar facilmente autenticação e autorização entre diferentes servidores que implantam o serviço. Por exemplo, a conta pode ser usada para permitir que servidores web front-end se comuniquem com a camada de lógica empresarial na camada média. Se diversos servidores web front-end se comunicarem com uma camada média comum, considere o uso de uma conta exclusiva para cada servidor ou configure o serviço para ser executado como Serviço de Rede se possível. Entretanto, existem algumas advertências aqui. Se um invasor tiver acesso ao domínio do servidor web e conhecer o nome de usuário(s), uma recusa de ataque ao serviço pode ser cometida ao tentar fazer o logon repetidamente como conta do serviço até que ela seja travada.

Não Permita Fazer o Logon Localmente

Não se deve permitir que contas de serviços façam o logon no console ou através de uma sessão do desktop remoto sob circunstancias normais. Somente deve-se permitir que a conta faça o logon com um serviço.

Mude a Senha Periodicamente

Realmente existem invasores tentando adivinhar senhas. Mude a senha das contas de serviço pelo menos 4 vezes ao ano para reduzir a possibilidade de que um invasor adivinhe a senha atual. É mais difícil acertar um alvo em movimento. Para complicar ainda mais o trabalho dos adivinhos, certifique-se de que a senha seja longa (15 caracteres ou mais) e razoavelmente complexa (com números, símbolos e letras misturados).

3. Siga as Melhores Práticas do SQL Server

Muitas aplicações web complexas usam um banco de dados do SQL Server no back-end. Estas são algumas dicas práticas para fazer com que os recursos de segurança do SQL Server trabalharem para você.

Não Use a conta SA

Não use o administrador do sistema (system administrator - SA) ao conectar uma aplicação web ao seu banco de dados associado. Ao invés disso, configure funções e usuários específicos no banco de dados com apenas os privilégios exigidos. O uso do login do SA é tão ruim quanto executar um serviço como administrador. O SA pode fazer qualquer coisa no SQL Server, incluindo a queda de tabelas e de todos os dados contidos nelas.

Use Funções e Logins para Controlar o Acesso ao SQL Server

Comece de forma restritiva e adicione permissões apenas para os usuários conforme necessário. Os serviços sendo executados como usuários específicos devem ter permissão para certas interações com o banco de dados. Isto pode ser alcançado prontamente através do uso de logins do SQL Server que são concedidos apenas para operação com uma função pré-definida para a aplicação web.

Sem Acesso Direto às Tabelas para os Usuários de Contas de Serviços

Como uma medida de defesa em profundidade, as contas de serviço não devem ser permitidas para acessar diretamente as tabelas de dados. Isto ajuda a minimizar o impacto no caso de comprometimento, porque o invasor terá apenas um subconjunto de coisas que poderão ser feitas com o banco de dados. Se o banco de dados contém dados confidenciais de clientes, considere ampliar esta restrição para todo o staff, com a advertência de que qualquer relatório padrão baseado nos dados terá que ser criado usando procedimentos armazenados.

Use Procedimentos Armazenados com Consultas Parametrizadas

Toda a interação de banco de dados entre a aplicação web e o SQL Server deve ser feita através de consultas parametrizadas que estão contidas nos procedimentos armazenados. Desta forma, todas as interações com as tabelas de bancos de dados são estritamente controladas, e os parâmetros de input são cuidadosamente checados antes do uso. Este método de interação do SQL Server acompanhado da restrição do acesso direto às tabelas torna a injeção de consultas praticamente impossível. Por exemplo:


CREATE proc sp_GetUserEmailAddress
	@UserID uniqueidentifier
as 
begin
	select EmailAddress from Users where uid_UserID=@UserID
GO


Use o Microsoft SQL Server Best Practices Analyzer (Analisador de Melhores Práticas)

Uma maneira prática de checar o uso do Microsoft SQL Server pelas suas aplicações web é obter uma cópia da ferramenta gratuita Best Practices Analyzer. Execute-o no banco de dados de suas aplicações web e considere implementar as sugestões de cada item no relatório.

4. Proteja os Bens

Todas as aplicações web possuem bens que precisam ser protegidos, desde recursos do CPU até largura de banda e dados privados de usuários. Dependendo do valor dos bens, considere tomar todas as medidas possíveis para protegê-los adequadamente. Uma vez que a informação tiver sido roubada, é virtualmente impossível recuperá-la.

Chaves Criptográficas

A sua aplicação web possui algum tipo de operação de criptografia? Como a chave de encriptogração é protegida? Procure considerar se as chaves privadas e/ou simétricas devem ser armazenadas num tipo de módulo de segurança de hardware (hardware security module - HSM) para a prevenção de roubo por invasores ou pessoas de dentro. Um HSM não bloqueará totalmente um determinado invasor, mas o seu certamente acrescentará uma camada extra de defesa. Além disso, a auditoria do uso de chaves pode fornecer uma pista que pode apontar o uso incorreto de alguém com acesso. De forma alternativa, a API de Proteção de Dados (DPAPI) que é parte do Microsoft Windows Server 2003 pode ser potencializada prontamente para a proteção de chaves de materiais menos confidenciais, com menor expectativa de vida. No mínimo, a aplicação ou serviço web deve usar as Windows Crypto APIs. Não tente reinventar os conhecidos algoritmos criptográficos ou criar outros mais interessantes. Isto é muito difícil de ser feito, portanto deixe a criptografia para os profissionais e concentre-se em outras linhas de frente de defesa.

Credenciais de Contas de Serviços

O nome e a senha de usuário para o usuário do domínio de uma aplicação web estão num pedaço de papel grudado no servidor? As credenciais das contas de serviço devem ser do conhecimento de apenas alguns membros selecionados da equipe. E qualquer cópia armazenada ou escrita das ditas credenciais deve ter acesso restrito (por exemplo, num cofre ou arquivo encriptado).

Dados do Usuário

Os dados do usuário estão num servidor que qualquer usuário interno pode acessar? Estes dados contêm PII? Esta informação é financeira ou confidencial, como números de cartão de crédito? Mantenha o acesso aos dados de usuários na base need to know (de conhecimento necessário). Além disso, o gerenciamento de certos tipos de dados é regulado, portanto você deve checar com o seu departamento legal sobre os níveis de proteção adequados exigidos pela lei. Por exemplo, o armazenamento de dados num formato encriptado e o monitoramento cuidadoso de que quem acessa as versões encriptadas deve ser o suficiente para determinado tipo de serviço web.

5. Inclua Recursos de Relatórios, Registros e Auditoria

Os relatórios não são úteis apenas para contadores minuciosos. Relatórios e registros robustos serão úteis não só para quem precisa analisar a métrica das aplicações web, mas também para a equipe de operadores e equipes que reagirão aos incidentes. É uma parte importante de qualquer serviço ou aplicação web.

Protegendo Dados de Registro

Os dados coletados sobre transações e diversos outros detalhes de aplicações web devem ser mantidos em um local seguro e de acesso restrito. Considere também a mudança regular dos dados de registro offline para um local mais seguro (diária ou semanalmente). Pense cuidadosamente a respeito da reutilização de gravações de registros. O seu sistema de registro exclui entradas antigas automaticamente quando fica cheio? Isto deveria ser feito? Uma maneira comum dos invasores apagarem seus rastros é fazer o spam do sistema de registro com entradas de registro legítimas e benignas que forçam a remoção das entradas antigas que mostravam a evidência do uso indevido.

Mantenha um Histórico

Seu advogado poderá recomendar por quanto tempo os dados de registro devem ser mantidos para satisfazer requisitos ou orientações legais. Mas considere manter resumos mensais, trimestrais e anuais dos dados que não precisam mais ser mantidos na íntegra. Desta forma, as tendências dos dados de um intervalo de tempo maior serão mantidas no futuro e possivelmente serão usadas para identificar a data de comprometimento durante um incidente.

Assine os Dados

Considere o uso de uma forma de assinatura digital para manter os dados registrados comprovadamente intocados, o que pode ajudar se forem eventualmente usados como provas num tribunal.

Colete e Centralize

Alguns detalhes talvez só tenham que ser registrados na forma "por servidor", mas a coleta e a centralização de dados no back-end pode oferecer um retrato mais preciso da saúde e segurança do sistema.

Considere o Uso da Biblioteca Microsoft Enterprise

A Microsoft criou um conjunto incrível de coisas relacionadas às aplicações para a reutilização na Biblioteca Corporativa (Enterprise Library). Muitas funções de aplicações comuns na web já foram criadas e estão prontas para serem usadas. Para mais informações, veja a Biblioteca Corporativa de padrões & práticas na seção de recursos deste documento.

6. Analise o Código Fonte

Análises cuidadosas do código da fonte podem revelar potenciais riscos e buracos na segurança. O Writing Secure Code, Second Edition, traz algumas recomendações excelentes sobre quais cuidados tomar.

Faça Análises de Códigos

Agregue indivíduos pertinentes trabalhando em um determinado recurso e faça-os analisar o código da fonte linha por linha. Qualquer problema encontrado deve ser verificado e alterado da maneira discutida. Análises de códigos são inúteis se os problemas identificados não forem solucionados, então planeje não apenas a análise como também a solução para os problemas.

Cuidado com Estouros do Buffer

Estouros do buffer acontecem quando alguma parte do sistema tenta inserir mais dados do que poderia. É como tentar espremer um litro de suco num copo de 250ml. O trasbordamento pode criar uma condição de Denial of Service (DoS) ou mesmo executar algum fragmento qualquer do código. A melhor maneira de se evitar BOs é fazer com que eles não ocorram! Além disso, o Data Execution Protection que é parte do Windows Server 2003 Service Pack 1 e processadores de 64 bits oferecem proteção extra. Códigos nativos são especialmente suscetíveis a condições de estouro do buffer. Analise cuidadosamente todos os códigos de buffer de input e output. O seguinte exemplo (tirado do artigo Defend Your Code with Top Ten Security Tips Every Developer Must Know - Defenda Seus Códigos com 10 Dicas de Segurança que Todo Desenvolvedor Deve Conhecer) mostra uma função clássica que pode levar a um estouro do buffer se os dados da fonte não forem delimitados por tamanho adequadamente:


void DoSomething(char *cBuffSrc, DWORD cbBuffSrc) {
		char cBuffDest[32];
		memcpy(cBuffDest,cBuffSrc,cbBuffSrc);
}


Cuidado com Estouros do Integer

Estouros do Integer são similares aos BOs no sentido que um valor numérico tenta ultrapassar o tamanho permitido. Mesmo códigos gerenciados são suscetíveis a condições de estouros do integer e como os BOs, os resultados podem variar desde DoS até a execução de algum pedaço de código que o invasor deseja. Analise cuidadosamente todo código de buffer de input e output. No exemplo abaixo, se i é igual a -1 então se obtém uma exceção DIVIDE BY 0:


Int16 i = getFromNetwork();
if (i <= MAX) {
      i++;
      Int32 j = 8192 / i;
}


Ainda, quando a variável, req, for além de 32767 no exemplo abaixo ela passa a ser interpretada como um número negativo, e uma matriz limita uma exceção:


Int16 req;
...
while (true) {
  getRequest();
  req++;
  arr[req] = DateTime.Now;
}


Como nos estouros do buffer, a melhor maneira de evitar o estouro do integer é não tê-los no código. Analise cuidadosamente todas as solicitações de memória dinâmica para a possibilidade de estouro do integer e teste-as devidamente.

Cuidado com Scripting entre Sites

É útil que as aplicações web mais complexas façam chamadas em outras aplicações web para certas sub-tarefas, mas a ação traz riscos. Se a URL usada para as chamadas vier de um input de usuário, existe um alto risco que pode ser manipulado e então usado para executar um ataque de um usuário para outro. Analise os códigos que lidam com interação de usuário para reduzir a possibilidade de um ataque de scripting entre sites. Considere o seguinte trecho de script:


<script language=c#>
  Response.Write("Hello, " + Request.QueryString("name"));
</script>


A fonte do nome não confiável pode conter qualquer coisa, incluindo algo como um script de re-direcionamento de website ou uma tentativa de roubar um cookie de um site.

Cuidado com Problemas de Canonicalization

Caminhos de arquivos e URLs podem muitas vezes ser representados de maneiras diferentes. Analise cuidadosamente qualquer função que lide com a procura de suposições sobre formatos que podem levar a resultados inesperados. Por exemplo, uma URL não pode ser representada apenas como um texto ASCII, mas também codificada em UTF-8.

Faça Buscas por Funções de Risco

O livro Writing Secure Code, Second Edition possui um excelente conjunto de apêndices que lista funções padrões que são comumente usadas incorretamente e de tal forma que deixam um buraco em potencial na segurança. Considere substituir todas as referências de funções inseguras pelas alternativas recomendadas.

Use Escaneamento Automatizado

O uso de ferramentas automatizadas de análise de códigos pode acelerar o processo de análise e fornecer feedback constante. O tempo exigido para trabalhar com estas ferramentas no processo de construção regular será retribuído mais tarde. Apesar de algumas ferramentas dar positivos falsos eventualmente, certifique-se de analisar cuidadosamente qualquer alerta. Alem disso, acione os alertas do compilador como erros no ambiente de desenvolvimento. Ele pode fornecer um positivo falso ocasionalmente, mas é um escaneamento de código de primeira linha. Versões futuras do Microsoft Visual Studio incluirão ferramentas como FXCop e PREFast que buscarão problemas comuns e então gerarão relatórios concisos. Depois disso, o resumo pode ser analisado caso a caso para checar a ocorrência do problema e solucionar o código da fonte devidamente.

7. Implemente Componentes Usando Defesa em Profundidade

Só porque existe a possibilidade de buracos na segurança não significa que nada pode ser feito. Defina maneiras de mitigar os riscos diretos e secundários se determinada tecnologia falhar. Assim que os métodos de mitigação forem definidos, projetados e construídos, teste-os. Lembre-se, softwares bem projetados falham para um modo seguro. Na dúvida, negue o acesso. Verifique se o processo de implantação e instalação não configurou nada além dos privilégios mínimos necessários para que a aplicação web opere. Uma ferramenta excelente para ajudá-lo nesta verificação é o VeriTest-Rational Installation Analyzer (veja a lista de recursos neste documento). Use o Installation Analyzer antes e depois da instalação para verificar se ouve mudanças neste meio tempo.

Siga as Melhores Práticas de Implantação para Todas as Dependências

A aplicação web depende do Microsoft Exchange Server? Depende do Microsoft SQL Server 2000? O site da web trabalha com o IIS 5.0? Seja qual for a lista de tecnologias dependentes necessárias, implante-as usando as melhores práticas de segurança para cada uma delas. Alguns links para guias comuns de implantação podem ser encontrados na lista de Recursos deste documento.

Use uma Arquitetura de Duas ou Três Camadas

Os dados armazenados para a aplicação web (geralmente SQL Server) não devem ser acessíveis diretamente da mesma rede pública de onde chega o tráfego do cliente. Mantenha separadas por servidores front-end as redes públicas e privadas para implantação de sua aplicação web. Além disso, considere separar também a lógica empresarial da camada de apresentação (servidor web), porque isto oferece maior flexibilidade e melhor segurança para implantação se necessário.

Use o SSL nos Servidores Web

A sua aplicação web transmite ou recebe dados confidenciais de clientes como personally identifiable information (PII)? Se a resposta é sim, considere a encriptação da sessão do servidor web com o cliente usando a Secure Sockets Layer (SSL) ou o Internet Protocol Security (IPSec). Isto reduzirá consideravelmente a possibilidade de um invasor observar ou alterar os dados em trânsito. Para a facilidade do uso, adquira certificados de uma autoridade de certificação na qual os sistemas de seus clientes confiarão. No entanto, o SSL tem suas limitações. O SSL apenas oferece encriptação da sessão entre end points e apenas garante imprecisamente que as partes presentes são quem realmente dizem que são. No entanto, trata-se de um excelente ponto de partida para qualquer aplicação web.

Firewalls, Segmentos da Rede, e ACLs Por Todo Lado

Use a combinação de firewalls, segmentação e listas de controle de acesso roteadoras (router access control lists - ACLs) para isolar as diversas partes da aplicação web o máximo possível. Tal combinação funcionará como barreiras que reduzem ou bloqueiam a disseminação de um comprometimento, bem como oferecem alertas e avisos que permitirão uma reação adequada ao incidente. Por exemplo, os servidores da camada de lógica empresarial (business logic layer - BLL) devem ser os únicos a se comunicarem com os computadores executando o SQL Server, então se certifique de que os roteadores ACLs reforcem isto. Um firewall de inspeção de pacote de estado como o Microsoft Internet Security e o Acceleration Server 2004 também pode analisar o tráfego para se certificarem de tem o mesmo o formato e tipo de determinada porta de destino. Por exemplo, um firewall de inspeção de pacote de estado pode ajudar a garantir que o tráfego entre uma instância do SQL Server e a camada de lógica empresarial seja parecido com o tráfego bem formado do SQL Server de alguma porta e não de mensagens HTTP ou DNS. Inclua as devidas ACLs de privilégio mínimo em todos os arquivos usados pelo serviço ou aplicação web. Resumindo, se é algo criado para ou usado pela sua aplicação web, deve ter algum tipo de ACL nele.

Considere a Encriptação do Tráfego de Rede Back-End

A sua implantação compartilha um centro de dados com diversos outros sites? Se um destes servidores estiver comprometido e escutando a rede privada, ele veria algum PII? Se a resposta é sim, considere o uso de tráfego de rede encriptado SSL ou IPSec no back-end. Isto ajudará a evitar espionagem e pode também ser usado como uma forma de autenticação de rede entre máquinas.

8. Desligue Mensagens de Erro em Profundidade para Usuários Finais

Uma das maneiras de um invasor estudar seu alvo é procurando por detalhes sutis revelados nas mensagens de erro. Após uma implantação web ter sido implantada na produção, respostas de erro em profundidade e mensagens de depuração para usuários finais devem ser desligadas.

Apenas Erros Locais

Se um problema é encontrado com a aplicação web in loco, envie mensagens de depuração como stack traces para o log de evento de Aplicativo. Desta forma, o problema pode ser diagnosticado mais adiante sem a exposição de muitos detalhes.

Reporte Erros ao Back-End

Reporte detalhes de erros em profundidade como stack trace completo, variáveis, e informações do sistema para a porção de relatórios, registro e auditoria da aplicação web. Tais dados devem ser úteis para a análise de como seria uma invasão, caso ela ocorresse.

Monitore Sinais de Ataque

Um único cliente está encontrando rapidamente e repetidamente variações do mesmo erro? Este não seria um invasor procurando por buracos ao invés de um cliente válido? Se alguns sinais de ataque (por exemplo, falhas repetidas de autenticação) forem encontrados, faça o sistema avisar a equipe de operações para considerar se é necessária uma resposta ao incidente de segurança. Além disso, considere implantar um Sistema de Detecção de intrusão de terceiros para ajudar a monitorar os sinais intrigantes de comprometimento.

9. Conheça as 10 Leis de Administração de Segurança

Todos envolvidos na criação e operação de aplicações web deveriam estar familiarizados com as 10 Leis Imutáveis de Administração da Segurança. Estas são as excelentes orientações:

Proteja Todos os Sistemas

Não adianta muito implantar aplicações web num sistema não protegido! Proteja todos os sistemas com atualizações, software antivírus e firewalls conforme for apropriado. Isto é especialmente importante para as aplicações web que se comunicam através da Internet.

10. Tenha um Plano de Reação para Incidentes na Segurança

Como a equipe responderá se/ quando ocorrer um comprometimento? Se você pensou nesta possibilidade antes, isto fará uma grande diferença no tempo de reação e para que as operações voltem ao normal. O Centro de Coordenação CERT possui um artigo excelente sobre como deve ser um Plano de Reação para Incidentes na Segurança (Security Incident Response Plan - SIRP). Para mais informações, veja Reagindo a Invasões na seção de Recursos deste documento.

Saiba Quem Chamar

Planeje um diagrama de chamadas para alertar a equipe necessária. Devem estar listados nomes da diretoria, desenvolvimento, gerenciamento de programa, avaliação, operações, recursos humanos, e departamento legal. Além destes, a lista deve incluir informações de contado de terceiros que possam ou não estar envolvidos, como a polícia, provedores da Internet, ou instituições bancárias.

Espere pelo Melhor, Prepare-se para o Pior

Idealmente, um SIRP nunca precisará ser usado, mas em todo caso ele deve ser criado. Tente imaginar alguns cenários possíveis. Por exemplo, o que aconteceria se um servidor da web fosse comprometido de alguma forma? Faça um plano de reação para cada cenário e peça comentários. Então documente tudo e guarde os planos num local conhecido apenas pelas pessoas responsáveis em caso de incidentes.

Siga o Plano

Se um incidente de segurança for detectado, siga o plano geral e as orientações específicas para aquele tipo de situação. A pior situação possível é ter pessoas tentando re-criar uma reação sob pressão após um incidente ter sido detectado.

Saiba Quando Não Seguir o Plano

Não existem dois incidentes iguais na segurança. O plano de reação geral o ajudará em todas as situações, mas existem momentos quando uma abordagem ligeiramente diferente é indicada. Não fique muito preso ao processo. Seja flexível o suficiente para reagir da maneira adequada, desde que o resultado almejado seja conquistado.

Complete uma Análise da Autópsia

Assim que um incidente na segurança for solucionado, analise como e porque ele ocorreu. Repita a linha do tempo do incidente, da reação e verifique sua eficácia. Como o processo poderia funcionar mais eficientemente? Como o incidente poderia ter sido prevenido em primeiro lugar? Seja honesto, mas também cuidadoso para não ficar apenas apontando culpados.

Incorpore o Feedback e as Lições Aprendidas

Após a análise da eficiência dos planos de reação, incorpore o feedback. Um bom SIRP é um documento vivo que pode mudar adequadamente com o tempo. Certifique-se de manter um histórico do plano e das mudanças ocorridas.

Recursos

Veja uma lista completa dos recursos para este artigo

Este é um documento preliminar e pode estar sujeito a alterações substanciais antes do lançamento comercial do software aqui descrito.

As informações contidas neste documento representam a visão atual da Microsoft Corporation sobre os assuntos discutidos até a data da publicação. A Microsoft deve reagir às constantes alterações nas condições do mercado, e sendo assim este documento não deve ser interpretado como um compromisso por parte Microsoft, e a Microsoft não pode garantir a precisão de qualquer informação aqui apresentada após a data de publicação.

Este Informe Oficial tem propósito exclusivamente informativo. A MICROSOFT NÃO OFERECE GARANTIAS, EXPRESSAS, IMPLÍCITAS OU REGULAMENTARES ACERCA DAS INFORMAÇÕES CONTIDAS NESTE DOCUMENTO.

É de responsabilidade do usuário o respeito a toda a legislação de copyright aplicável. Sem restringir os direitos autorais da marca, nenhuma parte deste documento poderá ser reproduzida, armazenada, ou introduzida num sistema de buscas, ou transmitida de qualquer forma (eletrônica, mecânica, através de fotocópias, ou outra), ou com qualquer propósito, sem o consentimento expresso e por escrito da Microsoft Corporation.

A Microsoft pode possuir patentes, aplicações de patentes, marcas registradas, copyright ou outros direitos de propriedade intelectual assegurando os assuntos abordados neste documento. Exceto quando expressamente declarado, através de acordo por escrito da Microsoft, a posse deste documento não dá direito ao uso das patentes, marcas registradas, copyright ou outra propriedade intelectual.

Exceto quando especificado, os exemplos de empresas, organizações, produtos, nomes de domínio, endereços de e-mail, logotipos, pessoas, lugares e eventos aqui descritos são fictícios e não têm relação alguma com qualquer empresa, organização, produto, nome de domínio, endereço de e-mail, logotipo, pessoa, lugar ou evento real.

© 2005 Microsoft Corporation. Todos os direitos reservados.

Microsoft, MSDN, Visual Studio, Windows, e Windows Server são marcas ou marcas registradas da of Microsoft Corporation nos Estados Unidos e/ ou outros países.

Todas as outras marcas são propriedade de seus respectivos donos.

Isso foi útil para você?
(1500 caracteres restantes)
Agradecemos os seus comentários
A Microsoft está realizando uma pesquisa online para saber sua opinião sobre o site do MSDN. Se você optar por participar, a pesquisa online lhe será apresentada quando você sair do site do MSDN.

Deseja participar?
Mostrar:
© 2014 Microsoft