16 de março de 2007

SECMASTER

O SECMASTER é a principal premiação do segmento de Gerenciamento de Risco e Segurança da Informação, e é uma iniciativa conjunta do Capítulo Brasileiro do ISSA e da Via Forum

O SecMaster é uma iniciativa significativa de desenvolvimento do setor, e tem como objetivo reconhecer os profissionais de gerenciamento de risco e segurança da informação que mais contribuiram no ano de 2006 para que o segmento crescesse, fosse reconhecido, fosse debatido, fosse melhorado, fosse divulgado, fosse capacitado, fosse desenvolvido e aumentasse a conscientização da sua importância.

Este ano teremos premiação para as seguintes categorias:

  1. Melhor Profissional do Ano
  2. Melhor Contribuição para o Setor Privado
  3. Melhor Contribuição para o Setor Público
  4. Melhor Contribuição para o Desenvolvimento de Mercado
  5. Melhor Trabalho Acadêmico
  6. Melhor Contribuição Editorial e Jornalística

Teremos também um prêmio especial de Honra ao Mérito.

Participe! Divulgue! Indique! Candidate-se!

Sua participação é importante para fazermos deste prêmio o encontro nacional do segmento e premiarmos aqueles que realmente fizeram diferença.

Dúvidas sobre conteúdo, estou a disposição representanto o Capítulo Brasileiro da ISSA como diretor de educação e conteúdo.

SECMASTER

O SECMASTER é a principal premiação do segmento de Gerenciamento de Risco e Segurança da Informação, e é uma iniciativa conjunta do Capítulo Brasileiro do ISSA e da Via Forum



O SecMaster é uma iniciativa significativa de desenvolvimento do setor, e tem como objetivo reconhecer os profissionais de gerenciamento de risco e segurança da informação que mais contribuiram no ano de 2006 para que o segmento crescesse, fosse reconhecido, fosse debatido, fosse melhorado, fosse divulgado, fosse capacitado, fosse desenvolvido e aumentasse a conscientização da sua importância.


Este ano teremos premiação para as seguintes categorias:




  1. Melhor Profissional do Ano

  2. Melhor Contribuição para o Setor Privado

  3. Melhor Contribuição para o Setor Público

  4. Melhor Contribuição para o Desenvolvimento de Mercado

  5. Melhor Trabalho Acadêmico

  6. Melhor Contribuição Editorial e Jornalística


Teremos também um prêmio especial de Honra ao Mérito.

Participe! Divulgue! Indique! Candidate-se!


Sua participação é importante para fazermos deste prêmio o encontro nacional do segmento e premiarmos aqueles que realmente fizeram diferença.
Dúvidas sobre conteúdo, estou a disposição representanto o Capítulo Brasileiro da ISSA como diretor de educação e conteúdo.



9 de março de 2007

SWOT and Risk Analysis

Como profissional de segurança eu me considero um gestor de riscos, assim como qualquer profissional de segurança envolvido em qualquer fase da análise dos riscos e implementação de controles para mitigação.

Eu vejo empresas, profissionais e estudantes sempre a busca de uma fórmula perfeita para análise de riscos, isso se deve há um mito que foi criado sobre tal tema. Sim, na minha humilde opinião um mito, pois, o que realmente importa é identificar os riscos e trabalhar para que as ameaças não se concretizem.

Ferramentas com formulas mirabolantes e guardadas a sete chaves e métodos que são tão complicados quanto cálculo 1 e 2 para estudantes de engenharia, só colaboram para aumentar esse mito.

Lembro que há algum tempo atrás um amigo me informou que estava aprendendo na pós-graduação, SWOT para realisar análise de riscos. Naquela época eu achei que SWOT não era uma ferramenta adequada, pois, existiam inumeros métodos mais eficiêntes, como, Mosler, Fault Tree Analysis, Monte Carlo, OCTAVE e uma série de modelos complicados. Hoje eu acredito que é bem interessante a análise de SWOT na gestão de riscos.



Como a visão de SWOT poderia ser usada para análise de riscos?

Para responder isso vou falar um pouco de SWOT. Segundo a wikipedia a análise de SWOT não tem registros precisos de sua origem, a quem diga que Sun Tzu já utilizava esse conceito.

"Concentre-se nos pontos fortes, reconheça as fraquezas, agarre as oportunidades e proteja-se contra as ameaças ” (SUN TZU, 500 a.C.)

A análise busca identificar seus pontos fortes (Strengths), suas fraquesas (Weaknesses), oportunidades (Opportunities) e ameaças (Threats), que pode ser interpretada da seguinte forma:

Internamente
  • Como explorar nossos pontos fortes?
  • Como diminuir nossas fraquezas?
Externamente
  • Como explorar nossas oportunidades?
  • Como diminuir as ameaças?
Não é exatamente isso que a segurança da informação busca? Para que utilizar ferramentas complexas e manuais estilo NSA?

Eu não estou querendo pregar que as metodologias citadas são ruins, elas podem ser úteis quando já existe uma cultura, um entendimento claro de conceitos como:
  • Apetite por risco;
  • Mitigação;
  • Redução;
  • Tranferência;
  • e aceitaição.
Em situações onde já existe maturidade, os modelos citados podem ajudar a mensurar e apurar as variáveis que compoem a análise de riscos. De preferência que esses modelos mais precisos sejam implementados utilizando uma ferramenta. Afinal, nosso desafio é evitar que as ameaças se concretizem e não tornar-se um perito em cálculos complexos!

SWOT and Risk Analysis

Como profissional de segurança eu me considero um gestor de riscos, assim como qualquer profissional de segurança envolvido em qualquer fase da análise dos riscos e implementação de controles para mitigação.

Eu vejo empresas, profissionais e estudantes sempre a busca de uma fórmula perfeita para análise de riscos, isso se deve há um mito que foi criado sobre tal tema. Sim, na minha humilde opinião um mito, pois, o que realmente importa é identificar os riscos e trabalhar para que as ameaças não se concretizem.

Ferramentas com formulas mirabolantes e guardadas a sete chaves e métodos que são tão complicados quanto cálculo 1 e 2 para estudantes de engenharia, só colaboram para aumentar esse mito.

Lembro que há algum tempo atrás um amigo me informou que estava aprendendo na pós-graduação, SWOT para realisar análise de riscos. Naquela época eu achei que SWOT não era uma ferramenta adequada, pois, existiam inumeros métodos mais eficiêntes, como, Mosler, Fault Tree Analysis, Monte Carlo, OCTAVE e uma série de modelos complicados. Hoje eu acredito que é bem interessante a análise de SWOT na gestão de riscos.



Como a visão de SWOT poderia ser usada para análise de riscos?

Para responder isso vou falar um pouco de SWOT. Segundo a wikipedia a análise de SWOT não tem registros precisos de sua origem, a quem diga que Sun Tzu já utilizava esse conceito.

"Concentre-se nos pontos fortes, reconheça as fraquezas, agarre as oportunidades e proteja-se contra as ameaças ” (SUN TZU, 500 a.C.)

A análise busca identificar seus pontos fortes (Strengths), suas fraquesas (Weaknesses), oportunidades (Opportunities) e ameaças (Threats), que pode ser interpretada da seguinte forma:

Internamente

  • Como explorar nossos pontos fortes?



  • Como diminuir nossas fraquezas?


Externamente

  • Como explorar nossas oportunidades?



  • Como diminuir as ameaças?


Não é exatamente isso que a segurança da informação busca? Para que utilizar ferramentas complexas e manuais estilo NSA?

Eu não estou querendo pregar que as metodologias citadas são ruins, elas podem ser úteis quando já existe uma cultura, um entendimento claro de conceitos como:

  • Apetite por risco;



  • Mitigação;



  • Redução;



  • Tranferência;



  • e aceitaição.


Em situações onde já existe maturidade, os modelos citados podem ajudar a mensurar e apurar as variáveis que compoem a análise de riscos. De preferência que esses modelos mais precisos sejam implementados utilizando uma ferramenta. Afinal, nosso desafio é evitar que as ameaças se concretizem e não tornar-se um perito em cálculos complexos!

OWASP Top10 2007 RC

Estive analisando o Release Candidate do Top 10 2007 do OWASP (Open Web Application Security Project) e pude perceber que o projeto está sempre pesquisando e atendendo as tendências no desenvolvimento seguro de aplicações web.

A1 – Cross Site Scripting (XSS)

XSS flaws occur whenever an application takes user supplied data and sends it to a web browser without first validating or encoding that content. XSS allows attackers to execute script in the victim’s browser which can hijack user sessions, deface web sites, etc.

A2 – Injection Flaws

Injection flaws, particularly SQL injection, are common in web applications. Injection occurs when user-supplied data is sent to an interpreter as part of a command or query. The attacker’s hostile data tricks the interpreter into executing unintended commands or changing data.

A3 – Insecure Remote File Include

Code vulnerable to remote file inclusion allows attackers to include hostile code and data, resulting in devastating attacks, such as total server compromise.

A4 – Insecure Direct Object Reference

A direct object reference occurs when a developer exposes a reference to an internal implementation object, such as a file, directory, database record, or key, as a URL or form parameter. Attackers can manipulate those references to access other objects without authorization.

A5 – Cross Site Request Forgery (CSRF)

A CSRF attack forces a logged-on victim’s browser to send a pre-authenticated request to a vulnerable web application, which then forces the victim’s browser to perform a hostile action to the benefit of the attacker.

A6 – Information Leakage and Improper Error Handling

Applications can unintentionally leak information about their configuration, internal workings, or violate privacy through a variety of application problems. Attackers use this weakness to violate privacy, or conduct further attacks.

A7 – Broken Authentication and Session Management

Account credentials and session tokens are often not properly protected. Attackers compromise passwords, keys, or authentication tokens to assume other users dentities.

A8 – Insecure Cryptographic Storage

Web applications rarely use cryptographic functions properly to protect data and credentials. Attackers use weakly protected data to conduct identity theft and other crimes, such as credit card fraud.

A9 – Insecure Communications

Applications frequently fail to encrypt network traffic when it is necessary to protect sensitive communications.

A10 – Failure to Restrict URL Access

Frequently, the only protection for sensitive areas of an application is links or URLs are not presented to unauthorized users. Attackers can use this weakness to access and perform unauthorized operations.

A principal novidade é a inclusão do Cross Site Request Forgery uma variação do Cross Site Scripting que está entre as principais ameaças da Web 2.0.

Atendendo a demanda dos profissionais que desenvolvem em php que, segundo o NIST é a linguagem com mais aplicações web vulneráveis, o OWASP hoje possui não só o Stinger, um sanitizador, filter de inputs para aplicações desenvolvida em java, mas, um projeto semelhante para PHP.
Top 10 2007 RC
OWASP

8 de março de 2007

OWASP Top10 2007 RC

Estive analisando o Release Candidate do Top 10 2007 do OWASP (Open Web Application Security Project) e pude perceber que o projeto está sempre pesquisando e atendendo as tendências no desenvolvimento seguro de aplicações web.

A1 – Cross Site Scripting (XSS)

XSS flaws occur whenever an application takes user supplied data and sends it to a web browser without first validating or encoding that content. XSS allows attackers to execute script in the victim’s browser which can hijack user sessions, deface web sites, etc.

A2 – Injection Flaws

Injection flaws, particularly SQL injection, are common in web applications. Injection occurs when user-supplied data is sent to an interpreter as part of a command or query. The attacker’s hostile data tricks the interpreter into executing unintended commands or changing data.

A3 – Insecure Remote File Include

Code vulnerable to remote file inclusion allows attackers to include hostile code and data, resulting in devastating attacks, such as total server compromise.

A4 – Insecure Direct Object Reference

A direct object reference occurs when a developer exposes a reference to an internal implementation object, such as a file, directory, database record, or key, as a URL or form parameter. Attackers can manipulate those references to access other objects without authorization.

A5 – Cross Site Request Forgery (CSRF)

A CSRF attack forces a logged-on victim’s browser to send a pre-authenticated request to a vulnerable web application, which then forces the victim’s browser to perform a hostile action to the benefit of the attacker.

A6 – Information Leakage and Improper Error Handling

Applications can unintentionally leak information about their configuration, internal workings, or violate privacy through a variety of application problems. Attackers use this weakness to violate privacy, or conduct further attacks.

A7 – Broken Authentication and Session Management

Account credentials and session tokens are often not properly protected. Attackers compromise passwords, keys, or authentication tokens to assume other users dentities.

A8 – Insecure Cryptographic Storage

Web applications rarely use cryptographic functions properly to protect data and credentials. Attackers use weakly protected data to conduct identity theft and other crimes, such as credit card fraud.

A9 – Insecure Communications

Applications frequently fail to encrypt network traffic when it is necessary to protect sensitive communications.

A10 – Failure to Restrict URL Access

Frequently, the only protection for sensitive areas of an application is links or URLs are not presented to unauthorized users. Attackers can use this weakness to access and perform unauthorized operations.

A principal novidade é a inclusão do Cross Site Request Forgery uma variação do Cross Site Scripting que está entre as principais ameaças da Web 2.0.

Atendendo a demanda dos profissionais que desenvolvem em php que, segundo o NIST é a linguagem com mais aplicações web vulneráveis, o OWASP hoje possui não só o Stinger, um sanitizador, filter de inputs para aplicações desenvolvida em java, mas, um projeto semelhante para PHP.
Top 10 2007 RC
OWASP

6 de março de 2007

PCI Compliance Demystified

O PCI Compliance Demystified é um excelente blog sobre segurança em meios de pagamentos eletrônicos. Ele foca em questões relacionadas ao padrão PCI (Payment Card Industry) e os meios de pagamento eletrônico.

Um exemplo é um vídeo que mostra como é simples (com ferramentas adequadas) clonar um cartão de crédito.

PCI Compliance Demystified

O PCI Compliance Demystified é um excelente blog sobre segurança em meios de pagamentos eletrônicos. Ele foca em questões relacionadas ao padrão PCI (Payment Card Industry) e os meios de pagamento eletrônico.

Um exemplo é um vídeo que mostra como é simples (com ferramentas adequadas) clonar um cartão de crédito.





1 de março de 2007

Metasploit and OSSTMM video

Estão disponíveis no site do FOSDEM - Free and Open Source Software Development dois vídeos fantásticos.

Simplesmente duas apresentações sobre duas ferramentas essenciais em pentest, metasploit e a metodologia OSSTM (Open Source Security Testing Methodology Manual). E não é uma simples apresentação, são duas apresentações de duas horas tendo como apresentador os pais das crianças H. D. Moore e Pete Herzog respectivamente. Imperdível!
Metasploit
OSSTMM
FOSDEM

Metasploit and OSSTMM video

Estão disponíveis no site do FOSDEM - Free and Open Source Software Development dois vídeos fantásticos.

Simplesmente duas apresentações sobre duas ferramentas essenciais em pentest, metasploit e a metodologia OSSTM (Open Source Security Testing Methodology Manual). E não é uma simples apresentação, são duas apresentações de duas horas tendo como apresentador os pais das crianças H. D. Moore e Pete Herzog respectivamente. Imperdível!
Metasploit
OSSTMM
FOSDEM

28 de fevereiro de 2007

[blog] Dica de conteúdo

Hoje eu recebi um e-mail do meu amigo Cristiano Lincoln informando a URL do seu blog Life Without Knowledge Death in Disguise. Não deixe de acompanhar mais um blog com conteúdo de qualidade.

[blog] Dica de conteúdo

Hoje eu recebi um e-mail do meu amigo Cristiano Lincoln informando a URL do seu blog Life Without Knowledge Death in Disguise. Não deixe de acompanhar mais um blog com conteúdo de qualidade.

25 de fevereiro de 2007

Infectando Linux com vírus para Windows

O blog Doses Diárias publicou um post sobre a possibilidade de infectar ambientes Linux com vírus originalmente desenvolvidos para ambiente windows.

Para que isso seja possível é necessário estar trabalhando com o Wine, pacote que traduz requisições de funções (windows API) do windows para ambiente Linux. Isso possibilita rodar aplicações originalmente desenvolvidas para ambiente Windows em Linux.

Segundo as experiências a grande maioria dos vírus infectou parcialmente o ambiente Linux, mas, somado a um problema muito comum, o excesso de privilégios, a infecção pode ser generalizada.

Alguns posts saíram em defesa do ambiente Linux, considerando que excessos de privilégios não são práticas recomendadas. Bom, que não é recomendada todos nós sabemos, agora quantas pessoas tomam esses cuidados? E com pacotes para Linux cada vez mais NNF (Next, Next e Finish) a tendência é aumentar muito as configurações equivocadas.

Outros informam que um único vírus “rodou” no teste do newsforge e que vírus utilizam APIs não documentadas e funcionalidades bizarras do windows. Os testes realizados no newsforge foram realizados em 2005, os meios de infecção e códigos maliciosos mudaram um pouco não?

Algumas coisas eu ainda preciso avaliar melhor para fazer qualquer comentário. Qualquer aplicação rodando no Wine e com acesso a Web pode ser um vetor de ataque? Soluções de virtualização também estão expostas a problemas semelhantes?

Post no Doses Diárias
Post no NewsForge
Site do Wine
Wine por Wikipedia
Windows API por Wikipedia

Infectando Linux com vírus para Windows

O blog Doses Diárias publicou um post sobre a possibilidade de infectar ambientes Linux com vírus originalmente desenvolvidos para ambiente windows.

Para que isso seja possível é necessário estar trabalhando com o Wine, pacote que traduz requisições de funções (windows API) do windows para ambiente Linux. Isso possibilita rodar aplicações originalmente desenvolvidas para ambiente Windows em Linux.


Segundo as experiências a grande maioria dos vírus infectou parcialmente o ambiente Linux, mas, somado a um problema muito comum, o excesso de privilégios, a infecção pode ser generalizada.Alguns posts saíram em defesa do ambiente Linux, considerando que excessos de privilégios não são práticas recomendadas. Bom, que não é recomendada todos nós sabemos, agora quantas pessoas tomam esses cuidados? E com pacotes para Linux cada vez mais NNF (Next, Next e Finish) a tendência é aumentar muito as configurações equivocadas.Outros informam que um único vírus “rodou” no teste do newsforge e que vírus utilizam APIs não documentadas e funcionalidades bizarras do windows. Os testes realizados no newsforge foram realizados em 2005, os meios de infecção e códigos maliciosos mudaram um pouco não? Algumas coisas eu ainda preciso avaliar melhor para fazer qualquer comentário. Qualquer aplicação rodando no Wine e com acesso a Web pode ser um vetor de ataque? Soluções de virtualização também estão expostas a problemas semelhantes?
Post no Doses Diárias
Post no NewsForge
Site do Wine
Wine por Wikipedia
Windows API por Wikipedia

15 de fevereiro de 2007

BCP FAQ

Por que um FAQ sobre BCP em um blog? Porque durante o longo período que venho estudando, executando projetos e aprendendo com grandes profissionais que tive a oportunidade de trabalhar, sempre ouvi muita bobagem e todo tipo de informação que não colabora em nada com a cultura de continuidade de negócios.

Venho colecionando essas “perolas” há um bom tempo, agora decidi escrever um FAQ para facilitar um pouco a vida de quem ainda não teve a oportunidade de se envolver e estudar a fundo a disciplina de BCP.

1 – Não temos a cultura de BCP porque o índice de desastres naturais em nosso país é muito pequeno?

Muitos países possuem um índice de desastres naturais maiores que o nosso, mas, pode acreditar a nossa falta de cultura em BCP é baixa por falta de estudo e desenvolvimento, pois, se não possuímos desastres naturais, temos uma série de eventos que poderiam ser atendidos por um BCP. Afinal, Deus nasceu em Belém, mas, não é brasileiro!

2 – Ontem faltou energia durante 15 minutos e muitas áreas ficaram sem trabalhar e nosso site institucional ficou indisponível! Por que não acionamos o plano?

Aqui podemos ter duas situações, você possui processos críticos que em 15 minutos causaram impactos altíssimos ao seu negócio e o seu site é fundamental para o seu negócio, ai realmente se não ativaram foi por incompetência. Agora se você não possui processos com RTO menores ou iguais há quinze minutos e o seu site não é crítico, o plano não deveria ser acionado. Mas, eu gastei uma bala com o desenvolvimento do plano e ele não é capaz de suprir minhas necessidades a qualquer momento? Um plano é desenvolvido para atuar em situações abruptas onde a indisponibilidade de processos críticos podem causar sérios problemas à empresa. Incidentes comuns devem ser tratados pela operação normal da empresa. Aqui pode ser interessante implementar os processos de gestão de incidentes, gestão de problemas e a função de service desk para atuar integrado com o plano, se extrapolar a ação deles o plano pode ser acionado.

3 – Quem acionará o botão vermelho?

Calma, você desenvolveu um plano de continuidade de negócios, você ainda não tem um telefone vermelho sobre sua mesa e nem é a pessoa mais importante do mundo. Ninguém deve ser responsável sozinho por ativar um plano, o que irá determinar o acionamento do plano é uma matriz de níveis de crises clara que orienta a ativação do plano. Com base na matriz uma equipe previamente definida, comumente chamada de Crises Management Team, é responsável por avaliar os fatos e ativar o plano. Claro, o nome da equipe é o que menos importa, importante é que a decisão seja tomada por pessoas com visão ampla do negócio e de comum acordo com os controladores do negócio.

4 – Por que você não trás um “book” com um plano de continuidade para eu ver?

Você anda com o seu processo de contas a pagar debaixo dos braços? Apesar de existir documentos como resumptiom plan, onde etapas, atividades de recuperação de desastres são documentadas, o plano de continuidade adequado é o que é elaborado e implementado como um processo de negócios e sofre constante atualização e controle, possibilitando o amadurecimento e adequação do processo a necessidade do negócio.

5 – Gastamos uma bala com consultoria durante um ano e você não quer fazer um teste funcional do meu plano?

Um teste funcional só deve ser realizado após um amadurecimento do processo, somente se testes inferiores já foram executados, identificação de eventuais desvios e correções já foram feitas nos procedimentos de recuperação. Antes de um teste funcional você deve realizar testes como walkthrough, tableTop e testes parciais de cada procedimento, ação.

6 – A maioria dos meus processos não depende de tecnologia, como você vai fazer um BCP?

BCP é Business Continuity Plan ou Technology Continuity Plan? O plano deve atuar em situações que ofereçam risco ao negócio ou pessoas, sendo ele tecnológico ou não. Ah! Para os processos de negócio que não dependem de recursos de tecnologia você pode utilizar procedimentos de continuidade operacional.

7 – DRP é maior que um BCP?

Não. Disaster Recovery Plan é apenas uma pequena parte de um processo completo de continuidade de negócios.

8 – Por que você quer fazer primeiro a análise de riscos, o ideal não é primeiro fazer a BIA?

O ideal é realizar uma análise de riscos identificando todos os issues e com base nessas informações realizar uma análise de impactos no negócio. Em algumas situações realizamos a BIA para identificar os processos críticos e viabilizar a elaboração de um plano de continuidade de negócios.

9 – Por que você passa um ano fazendo todo tipo de entrevista e estudo para desenvolver um site alternativo? Não é muito mais fácil replicar os servidores principais?

Replicar ativos é contingência e não continuidade de negócios. É necessário avaliar o negócio a relação entre os processos, ativos que suportam os processos, riscos associados a esses ativos e caso seja necessário investir em redundância ou outras soluções para recuperação em um tempo inferior ao RTO do processo.

10 – O que tem haver SMS com o plano?

As áreas de SMS (Segurança, Saúde e Meio Ambiente) estão completamente ligadas a continuidade de negócios, essas áreas geralmente possuem procedimentos e recursos que devem ser levados em consideração e utilizados na gestão de crises.

11 – Você não tem uma ferramenta, como vai desenvolver o plano?

Bom, essa não é das piores, pior é ouvir que é necessário uma ferramenta para elaborar uma política de segurança. Uma ferramenta não impede em nada a implementação de um plano de continuidade de negócios. Ferramenta pode lhe auxiliar na gestão do plano, em cálculos de análise de riscos. Mas, que fique claro que não é mandatório.

12Qual é a melhor metodologia DRII, BCI?

Essa costumo ser curto e grosso. Nenhuma das duas são metodologia e sim áreas de conhecimento, como as de gerenciamento de projetos desenvolvidas pelo PMI.

Por enquanto é só, mas, tenho certeza que esse FAQ pode crescer muito.

BCP FAQ

Por que um FAQ sobre BCP em um blog? Porque durante o longo período que venho estudando, executando projetos e aprendendo com grandes profissionais que tive a oportunidade de trabalhar, sempre ouvi muita bobagem e todo tipo de informação que não colabora em nada com a cultura de continuidade de negócios.


Venho colecionando essas “perolas” há um bom tempo, agora decidi escrever um FAQ para facilitar um pouco a vida de quem ainda não teve a oportunidade de se envolver e estudar a fundo a disciplina de BCP.


1 – Não temos a cultura de BCP porque o índice de desastres naturais em nosso país é muito pequeno?


Muitos países possuem um índice de desastres naturais maiores que o nosso, mas pode acreditar a nossa falta de cultura em BCP é baixa por falta de estudo e desenvolvimento, pois, se não possuímos desastres naturais, temos uma série de eventos que poderiam ser atendidos por um BCP. Afinal, Deus nasceu em Belém, mas, não é brasileiro!



2 – Ontem faltou energia durante 15 minutos e muitas áreas ficaram sem trabalhar e nosso site institucional ficou indisponível! Por que não acionamos o plano?


Aqui podemos ter duas situações, você possui processos críticos que em 15 minutos causaram impactos altíssimos ao seu negócio e o seu site é fundamental para o seu negócio, ai realmente se não ativaram foi por incompetência. Agora se você não possui processos com RTO menores ou iguais há quinze minutos e o seu site não é crítico, o plano não deveria ser acionado. Mas, eu gastei uma bala com o desenvolvimento do plano e ele não é capaz de suprir minhas necessidades a qualquer momento? Um plano é desenvolvido para atuar em situações abruptas onde a indisponibilidade de processos críticos podem causar sérios problemas à empresa. Incidentes comuns devem ser tratados pela operação normal da empresa. Aqui pode ser interessante implementar os processos de gestão de incidentes, gestão de problemas e a função de service desk para atuar integrado com o plano, se extrapolar a ação deles o plano pode ser acionado.



3 – Quem acionará o botão vermelho?


Calma, você desenvolveu um plano de continuidade de negócios, você ainda não tem um telefone vermelho sobre sua mesa e nem é a pessoa mais importante do mundo. Ninguém deve ser responsável sozinho por ativar um plano, o que irá determinar o acionamento do plano é uma matriz de níveis de crises clara que orienta a ativação do plano. Com base na matriz uma equipe previamente definida, comumente chamada de Crises Management Team, é responsável por avaliar os fatos e ativar o plano. Claro, o nome da equipe é o que menos importa, importante é que a decisão seja tomada por pessoas com visão ampla do negócio e de comum acordo com os controladores do negócio.



4 – Por que você não trás um “book” com um plano de continuidade para eu ver?


Você anda com o seu processo de contas a pagar debaixo dos braços? Apesar de existir documentos como resumptiom plan, onde etapas, atividades de recuperação de desastres são documentadas, o plano de continuidade adequado é o que é elaborado e implementado como um processo de negócios e sofre constante atualização e controle, possibilitando o amadurecimento e adequação do processo a necessidade do negócio.



5 – Gastamos uma bala com consultoria durante um ano e você não quer fazer um teste funcional do meu plano?


Um teste funcional só deve ser realizado após um amadurecimento do processo, somente se testes inferiores já foram executados, identificação de eventuais desvios e correções já foram feitas nos procedimentos de recuperação. Antes de um teste funcional você deve realizar testes como walkthrough, tableTop e testes parciais de cada procedimento, ação.



6 – A maioria dos meus processos não depende de tecnologia, como você vai fazer um BCP?


BCP é Business Continuity Plan ou Technology Continuity Plan? O plano deve atuar em situações que ofereçam risco ao negócio ou pessoas, sendo ele tecnológico ou não. Ah! Para os processos de negócio que não dependem de recursos de tecnologia você pode utilizar procedimentos de continuidade operacional.



7 – DRP é maior que um BCP?


Não. Disaster Recovery Plan é apenas uma pequena parte de um processo completo de continuidade de negócios.



8 – Por que você quer fazer primeiro a análise de riscos, o ideal não é primeiro fazer a BIA?


O ideal é realizar uma análise de riscos identificando todos os issues e com base nessas informações realizar uma análise de impactos no negócio. Em algumas situações realizamos a BIA para identificar os processos críticos e viabilizar a elaboração de um plano de continuidade de negócios.



9 – Por que você passa um ano fazendo todo tipo de entrevista e estudo para desenvolver um site alternativo? Não é muito mais fácil replicar os servidores principais?


Replicar ativos é contingência e não continuidade de negócios. É necessário avaliar o negócio a relação entre os processos, ativos que suportam os processos, riscos associados a esses ativos e caso seja necessário investir em redundância ou outras soluções para recuperação em um tempo inferior ao RTO do processo.



10 – O que tem a ver SMS com o plano?


As áreas de SMS (Segurança, Saúde e Meio Ambiente) estão completamente ligadas a continuidade de negócios, essas áreas geralmente possuem procedimentos e recursos que devem ser levados em consideração e utilizados na gestão de crises.



11 – Você não tem uma ferramenta, como vai desenvolver o plano?


Bom, essa não é das piores, pior é ouvir que é necessário uma ferramenta para elaborar uma política de segurança. Uma ferramenta não impede em nada a implementação de um plano de continuidade de negócios. Ferramenta pode lhe auxiliar na gestão do plano, em cálculos de análise de riscos. Mas, que fique claro que não é mandatório.




12Qual é a melhor metodologia DRII, BCI?

Essa costumo ser curto e grosso. Nenhuma das duas são metodologia e sim áreas de conhecimento, como as de gerenciamento de projetos desenvolvidas pelo PMI.

Por enquanto é só, mas, tenho certeza que esse FAQ pode crescer muito.

13 de fevereiro de 2007

Hacking HD DVD and Blu-Ray

Segundo o hacker os padrões foram quebrados apenas monitorando a memória, não foi preciso mais nada.

Será que deixaram a "Processing Key" no lugar errado?

Hackers discover HD DVD and Blu-ray
"processing key" -- all HD titles now exposed

Hacking HD DVD and Blu-Ray

Segundo o hacker os padrões foram quebrados apenas monitorando a memória, não foi preciso mais nada.

Será que deixaram a "Processing Key" no lugar errado?
Hackers discover HD DVD and Blu-ray
"processing key" -- all HD titles now exposed

12 de fevereiro de 2007

BCP and Supply Chain

Recentemente o amigo Augusto Paes de Barros comentou um post meu e orientou aos profissionais sobre a necessidade de abrir os olhos sobre os planos de continuidade de negócios dos datacenters. Queria ter escrito sobre isso antes, mas, só agora isso foi possível. A preocupação do Augusto é adequada e muito trabalhada em outros países como os Estados Unidos, que é o estudo do Supply Chain ou cadeia de valores.

Eu sou fã do Cobit, mesmo acompanhando os absurdos cometidos por gestores despreparados e que se deixam levar pelo buzzword do mercado. E um dos controles que eu acho bastante pertinente e adequado para BCM (Business Continuity Management) é o DS2 – Gerenciar Serviços de Terceiros.

O que diz o DS2 do Cobit 4.0?

DS2.1 Identificação de Todos os Relacionamentos com Fornecedores

  • Identificar todos os fornecedores de serviços e categorizá-los de acordo com o tipo de fornecedor, significância e criticidade;
  • Manter documentação formal dos relacionamentos técnicos e organizacional cobrindo os papéis e responsabilidades, objetivos, entregáveis esperados e credenciais dos representantes destes fornecedores.

DS2.2 Gestão de Relacionamento do Fornecedor

  • Formalizar o processo de gestão de fornecedores para cada fornecedor;
  • Um responsável deverá mediar as questões entre o cliente interno e o fornecedor e garantir a qualidade deste relacionamento baseado na confiança e transparência (isto é, por meio de SLA).

DS2.3 Gestão de Risco do Fornecedor

  • Identificar e mitigar os riscos relacionados à capacidade dos fornecedores continuarem a efetivamente entregar o serviço de forma segura e eficiente;
  • Garantir que os contratos cumpram padrões universais de negócio em acordo com requerimentos legais e regulatórios;
  • Gestão de risco devem considerar acordos de confidencialidade ou NDAs (non-disclosure agreements), contratos de consignação, viabilidade continuada do fornecedor;
  • Cumprimento com requerimentos de segurança, fornecedores alternativos, penalidades e recompensas, etc...

DS2.4 Monitoramento do Desempenho do Fornecedor

  • Estabelecer um processo para monitorar a entrega do serviço para garantir que o fornecedor está atingindo os requerimentos do negócio e está continuamente aderente ao acordo contratual e acordo de nível de serviço e que o desempenho está competitivo com os fornecedores alternativos e condições de marcado.

Esses objetivos de controle tratam perfeitamente a necessidade de mapear e acompanhar os riscos da cadeia de valor que é parte do seu negócio.

BCP and Supply Chain

Recentemente o amigo Augusto Paes de Barros comentou um post meu e orientou aos profissionais sobre a necessidade de abrir os olhos sobre os planos de continuidade de negócios dos datacenters. Queria ter escrito sobre isso antes, mas, só agora isso foi possível. A preocupação do Augusto é adequada e muito trabalhada em outros países como os Estados Unidos, que é o estudo do Supply Chain ou cadeia de valores.


Eu sou fã do Cobit, mesmo acompanhando os absurdos cometidos por gestores despreparados e que se deixam levar pelo buzzword do mercado. E um dos controles que eu acho bastante pertinente e adequado para BCM (Business Continuity Management) é o DS2 – Gerenciar Serviços de Terceiros.


O que diz o DS2 do Cobit 4.0?


DS2.1 Identificação de Todos os Relacionamentos com Fornecedores




  • Identificar todos os fornecedores de serviços e categorizá-los de acordo com o tipo de fornecedor, significância e criticidade;



  • Manter documentação formal dos relacionamentos técnicos e organizacional cobrindo os papéis e responsabilidades, objetivos, entregáveis esperados e credenciais dos representantes destes fornecedores.



DS2.2 Gestão de Relacionamento do Fornecedor




  • Formalizar o processo de gestão de fornecedores para cada fornecedor;



  • Um responsável deverá mediar as questões entre o cliente interno e o fornecedor e garantir a qualidade deste relacionamento baseado na confiança e transparência (isto é, por meio de SLA).


DS2.3 Gestão de Risco do Fornecedor




  • Identificar e mitigar os riscos relacionados � capacidade dos fornecedores continuarem a efetivamente entregar o serviço de forma segura e eficiente;



  • Garantir que os contratos cumpram padrões universais de negócio em acordo com requerimentos legais e regulatórios;



  • Gestão de risco devem considerar acordos de confidencialidade ou NDAs (non-disclosure agreements), contratos de consignação, viabilidade continuada do fornecedor;



  • Cumprimento com requerimentos de segurança, fornecedores alternativos, penalidades e recompensas, etc...


DS2.4 Monitoramento do Desempenho do Fornecedor




  • Estabelecer um processo para monitorar a entrega do serviço para garantir que o fornecedor está atingindo os requerimentos do negócio e está continuamente aderente ao acordo contratual e acordo de nível de serviço e que o desempenho está competitivo com os fornecedores alternativos e condições de marcado.




Esses objetivos de controle tratam perfeitamente a necessidade de mapear e acompanhar os riscos da cadeia de valor que é parte do seu negócio.