Deperimetrização e Externalização, será?

Após a leitura do excelente post do Fernando Cima sobre Deperimetrização e Externalização eu fiquei pensando em alguns pontos sobre o tema. Apesar de, a idéia ser cada vez mais factível eu ainda acho que devemos pensar em alguns pontos que serão fundamentais para esse conceito/técnica ser adotado amplamente. Afinal esse conceito já está sendo comentado há um bom tempo.

Além das vantagens citadas pelo Cima, ainda podemos citar uma que sem dúvida é fundamental para quem paga a conta, que é a possibilidade de transformar o que era Capex (capital expenditure, despesas com ativos fixos) em (Opex operational expenditure, despesas operacionais).

Agora na minha opinião o que realmente vai fazer a diferença é sua real eficácia como controle de segurança. Afinal, a externalização vai trazer outros "problemas". O custo para manter isso pode ser tão caro quanto, além de um problema que conhecemos bem e que Bruce Schneier fez uma excelente analogia:

"Considere dois problemas de segurança diferentes. No primeiro deles, você guarda seus pertences num cofre no seu porão. As ameaças são os ladrões, claro. Mas o cofre é seu e a casa é sua, provavelmente. Você controla o acesso ao cofre e provavelmente tem um sistema de alarme.

O segundo problema é parecido, mas você guarda os seus pertences no cofre de outra pessoa. Pior ainda, no cofre de quem você não confia. Ele não sabe a senha, mas controla quem acessa o cofre. Ele pode tentar quebrá-la no seu tempo livre. Ele também pode transportar o cofre para onde ele quiser. Ele pode usar qualquer ferramenta que precisar.

No primeiro exemplo, o cofre precisa ser protegido, mas ainda é somente parte da segurança da casa. No segundo caso, o cofre é o único dispositivo que você tem.

Este segundo problema de segurança parece ser teórico, mas ele acontece com frequência na nossa sociedade da informação: dados controlados por uma pessoa, são armazenados em dispositivos controlados por outra pessoa."

Fonte em Português: Crypto-Gram.BR

Portanto, se os custos podem ser os mesmo, existirá outros problemas, o que realmente pode ser o fiel da balança é sua eficácia como controle de segurança.

O que vocês acham?

Business Impact Analysis

Em um post anterior eu havia comentado que falaria um pouco sobre BIA (Business Impact Analysis), nesse post eu vou comentar sobre um equivoco comum cometido por consultorias/profissionais e que infelizmente o mercado aceitou como verdade absoluta.

O que para muitos parece uma dúvida do tipo: quem veio primeiro, o ovo ou a galinha, para quem pesquisou documentos como o The BCI Guide e 10 Práticas Profissionais do DRII, saberia que é um erro grosseiro de conceito.

Ops...Estou falando dos problemas e ainda não disse que erro grosseiro é esse. O erro é realizar uma BIA antes do Risk Assessment (Análise de Riscos) ou como em vários casos eu já vi, realizar uma BIA sem Risk Assessment.

Faça uma reflexão, como é possível analisar os impactos nos negócios de uma organização sem conhecer os riscos que ela está sujeita? Impressionante é ver que o mercado aceitou esse erro e hoje acredita que o primeiro passo de um processo de continuidade de negócios é realizar uma BIA.

Como consultorias renomadíssimas podem cometer um erro tão grosseiro? Simples, a BIA é quase sempre vendida para alavancar o desenvolvimento de um plano de continuidade. De posse das informações sobre impactos financeiros é possível decidir se vale a pena investir ou não em um plano de continuidade e soluções de contingência para evitar eventuais perdas.




Algo lá no fundinho do meu coração me diz que ela serve como FUD (Fear, uncertainty, and doubt). Alguém chega com uma ferramenta de última geração, insere uns dados que vieram sei lá de onde e sai com um maravilhoso gráfico. Ah! Eles chamam isso de probabilidade subjetiva, eu chamo isso de outro nome científico: "inter femores" (Nas Coxas).


O correto é realizar uma análise de risco que irá identificar os riscos que sua organização está sujeita e com base nessas informações realizar uma análise de impacto nos negócios. Portanto, é impossível realizar uma análise de impactos nos negócios sem conhecer os riscos na organização. E sim, a análise de risco é realizada antes da análise de impactos nos negócios.

Sempre que eu participei de projetos que não foram realizadas análise de riscos eu não fiquei contente com os resultados. Não, eu não sou uma das consultorias que vende BIA como motivador de projeto, apenas acreditei em projetos anteriores realizados pela organização.

Se lhe surgir a oportunidade de realizar uma BIA, exija uma análise de riscos ou conheça seus riscos.

Novo blog - http://wagnerelias.com

Esse post é para avisar que o meu blog foi migrado para o endereço http://wagnerelias.com.

Os assinantes de feed rss agora tem duas feeds

• Feed com os Posts
• Feed com os comentários do blog

Por favor, se esse blog lhe é útil, atualize os endereços das feeds.

Crisis Management

Essa semana eu acabei presenciando e participando de algumas discussões que foram ocasionadas por interpretações diferentes de alguns termos que lidamos diariamente na gestão de segurança da informação.

Termos como eficiência, eficácia, contingência, disponibilidade, evento, incidente, crise, gestão e gerenciamento estão na língua de qualquer gestor. Será que todos possuem o mesmo conceito sobre esses termos? Já percebi que não, as vezes estamos falando de A e fulano está pensando em B.

Pensando nisso eu resolvi escrever sobre algo que, na maioria das vezes é esquecido na concepção e implementação de um processo de continuidade de negócios. Estou falando de uma matriz de níveis de crise, simplesmente o recurso que irá servir como indicador para a tomada de decisão para o acionamento ou não de um processo de gerenciamento de crise.

Primeiro gostaria de dar algumas definições dos termos que costumam gerar confusão quando estamos discutindo gestão de tecnologia, segurança e governança de tecnologia:

Eficiência: fazer algo com eficiência significa fazer as coisas do jeito certo, na primeira tentativa. Expressa o grau de aproveitamento dos recursos utilizados ao se produzir um produto ou realizar um serviço;

Eficácia: fazer uma coisa com eficácia, significa fazer o que deve ser feito, fazendo a coisa certa. Expressa o grau com que são atingidas as expectativas de alguém (um cliente de uma empresa, por exemplo);

Contingência: controles como, site alternativo que garantam a disponibilidade do serviço em situação adversa;

Disponibilidade: controles como, load balance, cluster e RAID, que garantem a disponibilidade mínima do serviço caso parte do serviço seja afetada;

Evento: ocorrência futura que pode ocasionar um incidente;

Incidente: um evento que não é comum na operação da organização e que, pode parar serviços, recursos, que suportam as operações da organização;

Crise: um evento crítico que pode ocasionar a parada do negócio, riscos a pessoas, perda de infra-estura essencial para operação da organização e consequentemente abalar drasticamente a imagem, reputação da organização causando prejuízos irreparáveis;

Gestão: planejar, organizar, liderar e controlar as pessoas que constituem uma organização e as tarefas e atividades por estes realizadas;

Gerenciamento: controlar atividades especificas como, serviços de TI;

A Matriz de Níveis de Crise consiste em uma tabela com níveis que possibilitam avaliar um evento e acionar ou não o procedimento de gerenciamento de crises, tornando muito mais eficaz o processo de gestão de crises. A Matriz deverá ser criada com as características e riscos da organização.

Exemplo de matriz de níveis de crise:


Após a definição clara dos eventos que possam impactar o negócio, é preciso treinar e disponibilizar a matriz para acesso dos envolvidos na gestão de incidentes. Os envolvidos na gestão de incidente irão usar a matriz para avaliar se é necessário acionar procedimentos de gerenciamento de crise ou tratar o evento como parte da operação normal da gestão de incidente.

Você pode classificar a matriz de níveis de crise em cores: azul, amarelo, laranja e vermelho. Ou seja, nome, modelo não importa, crie sua matriz conforme as características de sua organização e deixe ela o mais viável possível para servir como fator de decisão para acionamento dos planos, procedimentos que sua organização possui para gerenciar as adversidades.

Use os comentários para discutir critérios adequados para uma matriz de níveis de crise.

Security Cartoon

Para os fãs de tiras cômicas como as de Dilbert, agora pode acompanhar as tirar do SecurityCartoon.

As Tiras são relacionadas a segurança.

Security Cartoon

Para os fãs de tiras cômicas como as de Dilbert, agora pode acompanhar as tirar do SecurityCartoon.

As Tiras são relacionadas a segurança.

Web Server Hardening

Acaba de sair um Draft do 800-44 do NIST. O 800-44 é um guideline para segurança em servidores web publicados na internet.

O documento fala de uma série de características de hardening, arquitetura que um servidor web publicado deve possuir para aumentar a segurança. O documento trata desde a instalação até a gestão de servidores web publicado. Gostei bastante da parte que trata dos logs, o documento inclusive fala de SEIM (Security Event Information Management) para gestão automatizada de logs e do capítulo que trata das informações que serão publicadas, na minha opinião um problema sério.

Alguns checklists que estão presentes no documento:

• Checklist for Planing and Managing Web Servers;
• Checklist for Securing the Web Server Operating System;
• Checklist for Securing the Web Server;
• Checklist for Securing Web Content;
• Checklist for Using Authentication and Encryption Technologies for Web Servers;
• Checklist for Implementing a Secure Network Infrastructure;
• Checklist for Administering the Web Server.
  

Leitura essencial para qualquer administrador de rede ou envolvido com projetos web.

Guidelines on Securing Public Web Servers (Draft)

EndPoint Security

Hoje eu li uma notícia no Slashdot e fiquei impressionado com as características de uma solução de EndPoint Security. Confesso que me pareceu uma faca ginsu, muitas funcionalidades para uma solução barata e prática. Será uma panacéia?

Uma solução composta por nada menos que 13 controles de segurança, inclusive um controle batizado de L8, isso mesmo, Layer 8. Olha que esse layer 8 não é nenhum usuário inexperiente, e sim, um recurso que promete detectar detectar código malicioso baseado em comportamento.

Vamos a lista de recursos:

• Anti Virus
• Anti Spam
• Anti Phishing
• Anti Spyware
• Intrusion Detection (IDS)
• Intrusion Prevention (IPS)
• Firewall (Stateful Inspection)
• VPN
• Web Filtering
• Parental Content Control
• Adaptive Security Policy™
• Multi-Layer Security Agent™
• Layer-8 Security Engine ™
  

Segundo esse paper: Yoggie Pico Personal Datasheet a solução de filtro de conteúdo é da SurfControl; Anti Vírus e Anti Spyware da Kaspersky; e o resto linux-like.

EndPoint Security

Hoje eu li uma notícia no Slashdot e fiquei impressionado com as características de uma solução de EndPoint Security. Confesso que me pareceu uma faca ginsu, muitas funcionalidades para uma solução barata e prática. Será uma panacéia?

Uma solução composta por nada menos que 13 controles de segurança, inclusive um controle batizado de L8, isso mesmo, Layer 8. Olha que esse layer 8 não é nenhum usuário inexperiente, e sim, um recurso que promete detectar detectar código malicioso baseado em comportamento.

Vamos a lista de recursos:

• Anti Virus
• Anti Spam
• Anti Phishing
• Anti Spyware
• Intrusion Detection (IDS)
• Intrusion Prevention (IPS)
• Firewall (Stateful Inspection)
• VPN
• Web Filtering
• Parental Content Control
• Adaptive Security Policy™
• Multi-Layer Security Agent™
• Layer-8 Security Engine ™
  

Segundo esse paper: Yoggie Pico Personal Datasheet a solução de filtro de conteúdo é da SurfControl; Anti Vírus e Anti Spyware da Kaspersky; e o resto linux-like.

Security Research

Você quer dar os primeiros passos como security research? O site Security-Freak.net dá uma forcinha!

Você pode assistir uma série de vídeos educacionais sobre os seguintes temas:

• Basic Socket Programming;
• Packet Sniffing Using Raw Sockets
• Packet Injection Using Raw Sockets;
• Architecture of a Proactive Security Tool;
• Encryption Basics Using RC4.

Videos: Security-Freak.net

Security Research

Você quer dar os primeiros passos como security research? O site Security-Freak.net dá uma forcinha!

Você pode assistir uma série de vídeos educacionais sobre os seguintes temas:

• Basic Socket Programming;
• Packet Sniffing Using Raw Sockets
• Packet Injection Using Raw Sockets;
• Architecture of a Proactive Security Tool;
• Encryption Basics Using RC4.

Videos: Security-Freak.net

CERT Resiliency Engineering Framework

CERT Resiliency Engineering Framework é um projeto novo do CERT. Desenvolvido em conjunto com instituições financeiras renomadas e especialistas em continuidade de negócios como: DRII, DRJ, SunGard e IBM, tem um objetivo bastante ambicioso: desenvolver ferramentas, técnicas e metodologias para garantir a resiliência das organizações unindo segurança e continuidade de negócios.

Bom, o que seria Resiliência?

"A resiliência é um termo oriundo da física. Trata-se da capacidade dos materiais de resistirem aos choques. Esse termo passou por um deslizamento em direção às ciências humanas e hoje representa a capacidade de um ser humano de sobreviver a um trauma, a resistência do individuo face às adversidades, não somente guiada por uma resistência física, mas pela visão positiva de reconstruir sua vida, a despeito de um entorno negativo, do estresse, das contrições sociais, que influenciam negativamente para seu retorno à vida. Assim, um dos fatores de resiliência é a capacidade do individuo de garantir sua integridade, mesmo nos momentos mais críticos."

Fonte: Professora Sandra Maia Farias Vasconcelos, Dr.

Resumindo, tornar uma organização resiliente é desenvolver estratégias, controles que garantam a sobrevivência em situações adversas. Ah! Então é o mesmo propósito de um Plano de Continuidade de negócios? Isso. Muito bem "friper"!

Deixando a brincadeira de lado, lendo os materiais disponíveis no site do projeto é possível chegar a uma conclusão: o material vai ser excelente e a abordagem excepcional. Só espero não ser tão complicado quanto a OCTAVE (Operationally Critical Threat, Asset, and Vulnerability Evaluation) também do CERT.

O framework irá ser organizado em quatro áreas:

Enterprise Management
Engineering
Operations Management
Process Management

Irá possuir 24 processos mais monitoramento, com o objetivo de garantir a resiliência de pessoas, informações, tecnologia e facilities (Infra-Estrura básica) no contexto de serviços e objetivos da organização.

Cada área possui um conjunto de processos. Divididos da seguinte forma:

Enterprise Management Process

RSKM - Risk Management
EF - Enterprise Focus
COMP - Compliance Management
FRM - Financial Resource Management
HRM - Human Resource Management

Operations Management Process

SAM - Supplier Agreement Management
SRM - Supplier Relationship Management
AMC - Access Management and Control
IMC - Incident Management and Control
VM - Vulnerability Management
EC - Environmental Control
KIM - Knowledge and Information Management
SOM - Security Operations Management
ITOPS - IT Operations Management

Engineering Process

RD - Requirements Definition
RM - Requirements Management
AM - Asset Management
COOP - Continuity of Operations Planning
REST - Restoration of Operations Planning
CSI - Control Selection and Implementation
RAD - Resilient Architecture Development

Process Management Processes
OT - Organizational Training
OPF - Organizational Process Focus
OPD - Organizational Process Definition
MA - Measurement and Analysis
MON - Monitoring

Como podemos ver o framework irá tratar dos mais diversos assuntos relacionados a gestão de ativos, segurança e continuidade.

Assim como o CobiT ele não reinventa nada, ele se utiliza de estudos e boas práticas já amadurecidas e disseminadas para atender os assuntos relacionadas a garantia da resiliência das organizações.

O framework também irá utilizar o conceito de níveis de maturidade por processo e será divulgado ainda esse ano.

Proxypot

Depois do Honeypot, sistemas na sua maioria em perl que simulavam serviços como Telnet, SMTP entre outros, surgiram os honeypots voltados para identificar ataques voltados a aplicações web.

Após algum tempo pesquisadores do WASC (Web Application Security Consortium) concluiram que o esforços para desenvolver honeypots "atrativos" consomem muito tempo e esforço. A solução proposta é o Proxypot.

Proxypot é um sensor que irá analisar tráfego em Open Proxys, isso mesmo, a idéia é que contribuintes ao redor do mundo disponibilize proxy aberto para que pessoas mal intencionadas o utilizem e um sensor desenvolvido pelo o WASC vai analisar o tráfego e identificar tendências e ataques conhecidos, armazenando os logs em um local centralizado para pesquisas.

A idéia me parece interessante, mas, vou esperar um tempo para ter uma visão melhor da solução.

Quem quer disponibilizar um Proxypot o projeto disponibiliza imagens prontas para VMWARE, basta enviar um e-mail e solicitar.

O primeiro relatório está disponível no site do projeto The WASC Distributed Open Proxy Honeypot

CERT Resiliency Engineering Framework

CERT Resiliency Engineering Framework é um projeto novo do CERT. Desenvolvido em conjunto com instituições financeiras renomadas e especialistas em continuidade de negócios como: DRII, DRJ, SunGard e IBM, tem um objetivo bastante ambicioso: desenvolver ferramentas, técnicas e metodologias para garantir a resiliência das organizações unindo segurança e continuidade de negócios.

Bom, o que seria Resiliência?

"A resiliência é um termo oriundo da física. Trata-se da capacidade dos materiais de resistirem aos choques. Esse termo passou por um deslizamento em direção às ciências humanas e hoje representa a capacidade de um ser humano de sobreviver a um trauma, a resistência do individuo face às adversidades, não somente guiada por uma resistência física, mas pela visão positiva de reconstruir sua vida, a despeito de um entorno negativo, do estresse, das contrições sociais, que influenciam negativamente para seu retorno à vida. Assim, um dos fatores de resiliência é a capacidade do individuo de garantir sua integridade, mesmo nos momentos mais críticos."

Fonte: Professora Sandra Maia Farias Vasconcelos, Dr.

Resumindo, tornar uma organização resiliente é desenvolver estratégias, controles que garantam a sobrevivência em situações adversas. Ah! Então é o mesmo propósito de um Plano de Continuidade de negócios? Isso. Muito bem "friper"!

Deixando a brincadeira de lado, lendo os materiais disponíveis no site do projeto é possível chegar a uma conclusão: o material vai ser excelente e a abordagem excepcional. Só espero não ser tão complicado quanto a OCTAVE (Operationally Critical Threat, Asset, and Vulnerability Evaluation) também do CERT.

O framework irá ser organizado em quatro áreas:

Enterprise Management
Engineering
Operations Management
Process Management

Irá possuir 24 processos mais monitoramento, com o objetivo de garantir a resiliência de pessoas, informações, tecnologia e facilities (Infra-Estrura básica) no contexto de serviços e objetivos da organização.

Cada área possui um conjunto de processos. Divididos da seguinte forma:

Enterprise Management Process

RSKM - Risk Management
EF - Enterprise Focus
COMP - Compliance Management
FRM - Financial Resource Management
HRM - Human Resource Management

Operations Management Process

SAM - Supplier Agreement Management
SRM - Supplier Relationship Management
AMC - Access Management and Control
IMC - Incident Management and Control
VM - Vulnerability Management
EC - Environmental Control
KIM - Knowledge and Information Management
SOM - Security Operations Management
ITOPS - IT Operations Management

Engineering Process

RD - Requirements Definition
RM - Requirements Management
AM - Asset Management
COOP - Continuity of Operations Planning
REST - Restoration of Operations Planning
CSI - Control Selection and Implementation
RAD - Resilient Architecture Development

Process Management Processes
OT - Organizational Training
OPF - Organizational Process Focus
OPD - Organizational Process Definition
MA - Measurement and Analysis
MON - Monitoring

Como podemos ver o framework irá tratar dos mais diversos assuntos relacionados a gestão de ativos, segurança e continuidade.

Assim como o CobiT ele não reinventa nada, ele se utiliza de estudos e boas práticas já amadurecidas e disseminadas para atender os assuntos relacionadas a garantia da resiliência das organizações.

O framework também irá utilizar o conceito de níveis de maturidade por processo e será divulgado ainda esse ano.

Proxypot

Depois do Honeypot, sistemas na sua maioria em perl que simulavam serviços como Telnet, SMTP entre outros, surgiram os honeypots voltados para identificar ataques voltados a aplicações web.

Após algum tempo pesquisadores do WASC (Web Application Security Consortium) concluiram que o esforços para desenvolver honeypots "atrativos" consomem muito tempo e esforço. A solução proposta é o Proxypot.

Proxypot é um sensor que irá analisar tráfego em Open Proxys, isso mesmo, a idéia é que contribuintes ao redor do mundo disponibilize proxy aberto para que pessoas mal intencionadas o utilizem e um sensor desenvolvido pelo o WASC vai analisar o tráfego e identificar tendências e ataques conhecidos, armazenando os logs em um local centralizado para pesquisas.

A idéia me parece interessante, mas, vou esperar um tempo para ter uma visão melhor da solução.

Quem quer disponibilizar um Proxypot o projeto disponibiliza imagens prontas para VMWARE, basta enviar um e-mail e solicitar.

O primeiro relatório está disponível no site do projeto The WASC Distributed Open Proxy Honeypot

VOIP Security Tools

Foi divulgado pela VOIPSA (VOIP Security Aliance) uma lista de ferramentas para análise e teste de segurança em dispositivos VOIP.

A lista está classificada da seguinte forma:

• VoIP Sniffing Tools
• VoIP Scanning and Enumeration Tools
• VoIP Packet Creation and Flooding Tools
• VoIP Fuzzing Tools
• VoIP Signaling Manipulation Tools
• VoIP Media Manipulation Tools
• Miscellaneous Tools
  

Ainda está disponível uma lista com tutoriais e apresentações.

Voip Security Tools

VOIP Security Tools

Foi divulgado pela VOIPSA (VOIP Security Aliance) uma lista de ferramentas para análise e teste de segurança em dispositivos VOIP.

A lista está classificada da seguinte forma:

* VoIP Sniffing Tools
* VoIP Scanning and Enumeration Tools
* VoIP Packet Creation and Flooding Tools
* VoIP Fuzzing Tools
* VoIP Signaling Manipulation Tools
* VoIP Media Manipulation Tools
* Miscellaneous Tools

Ainda está disponível uma lista com tutoriais e apresentações.

Voip Security Tools

XML Firewall

Muito tem se falado sobre XML Firewall devido a abundância de aplicações na web utilizando webservice/xml, um trabalho publicado por Don Patterson no SANS Institute dá uma visão da solução : XML Firewall Architecture and Best Practices for Configuration and Auditing.

Para os desenvolvedores web eu recomendo fortemente os excelentes artigos, Charset e Encoding e XHTML Media Types escrito por Henrique C. Pereira do Revolução Etc e Entendendo um pouco mais sobre o protocolo HTTP escrito por Nando Vieira do Simples Idéias.

XML Firewall

Muito tem se falado sobre XML Firewall devido a abundância de aplicações na web utilizando webservice/xml, um trabalho publicado por Don Patterson no SANS Institute dá uma visão da solução : XML Firewall Architecture and Best Practices for Configuration and Auditing.



Para os desenvolvedores web eu recomendo fortemente os excelentes artigos, Charset e Encoding e XHTML Media Types escrito por Henrique C. Pereira do Revolução Etc e Entendendo um pouco mais sobre o protocolo HTTP escrito por Nando Vieira do Simples Idéias.

BCI x DRII

Calma, não é nenhuma comparação ou defesa de um time ou outro, sim, as vezes parece que os profissionais tem um time de futebol e não uma base de informações e estudos para desenvolver um plano de continuidade de negócios.

Estou afirmando isso pois, ultimamente tenho visto atitudes no mínimo questionáveis de players de mercado. Ontem levantavam a bandeira do DRII (Disaster Recovery Institute International) e por motivos puramente comerciais começam a levantar a bandeira do BCI (Business Continuity Institute).

Ok, escolhas são escolhas! E quando não se aplica escolhas?

O DRII e BCI são as duas principais escolas sobre continuidade de negócios e ambas tem a mesma filosofia e práticas, com um único objetivo que é garantir a continuidade. Continuidade no sentido amplo da palavra, pois, a ciência se aplica a tudo não apenas a negócios.

Nunca vamos saber se as atitudes são devido a incapacidade intelectual ou falta de ética, mas, cabe a profissionais neutros e que atuam deixar claro questões como essa: BCI é continuidade e DRI é Recuperação de Desastres!

Eu começo com uma simples pergunta: você conhece as dez práticas profissionais do DRI e o The BCI Guide?

Se o profissional que faz tal afirmação estudasse um pouco mais essas duas fontes ele iria encontrar essas informações:

Professional Practices - DRII

1 - Project Initiation and Management
2 - Risk Evaluation and Control
3 - Business Impact Analysis
4 - Developing Business Continuity Strategies
5 - Emergency Response and Operations
6 - Developing and Implementing Business Continuity Plans
7 - Awareness Programs and Training
8 - Maintaining and Exercising the Business Continuity Plans
9 - Crisis Communications
10 - Coordination with External Agencies

Qualquer profissional que tenha um pouco de boa vontade identificaria as práticas número 3 - Business Impact Analysis; Developing and Implemententing Business Continuity Plans; e Maintaining and Exercising the Business Continuity Plans. Essas três práticas só por seu enunciado já desmistificam tal afirmação feita por profissionais que desconhecem os institutos e a ciência continuidade de negócios.

Se não bastasse uma simples análise superficial ainda podemos identificar também nos enunciados do guide do BCI a sinergia entre os institutos.

Good Practices Guideline 2007 - BCI

1 - BCM Policy and Programme Management
2 - Understanding the organisation
3 - Determining BC Strategies
4 - Developing and Implementing a BCM Response
5 - Exercising, Maintenance and Review

O capítulo um do guide tem o mesmo propósito da primeira prática do DRI, que é basicamente definir um escopo para o desenvolvimento do plano e estabelecer um comitê de continuidade de negócios, além dos cuidados para implementação de um processo em uma organização.

O capítulo dois do guide tem o mesmo propósito das práticas 2 - Risk Evaluation and Control e 3 - Business Impact Analysis (aqui também temos sérios problemas de conceito, mas, isso fica para um outro post) do DRI, que é avaliar os riscos e identificar os principais processos de negócios que servirão como principal análise para a seleção de estratégia.

O Capítulo três do guide tem o mesmo propósito da prática 4 - Developing Business Continuity Strategies do DRI, que define que deve-se identificar e implementar soluções para atender os principais processos em situações adversas.

O Capítulo quatro do guide tem o mesmo propósito da prática 6 - Developing and Implementing Business Continuity Plans do DRI, que tem como objetivo implementar a cultura, processo de continuidade de negócios na organização.

O Capítulo cinco do guide tem o mesmo propósito da prática 8 - Maintaining and Exercising the Business Continuity Plans do DRI que tem como objetivo testar e exercitar o processo de continuidade e atualizar o plano mediante a novas demandas do negócio.

Bom, acho que consegui deixar as coisas mais claras por aqui. Sugiro que todos os interessados estudem as 10 práticas profissionais do DRI e o The BCI Guide para ter mais informações e não cometer gafes como essas.