31 de dezembro de 2007

Recovery Point Objective

RPO (Recovery Point Objective) é a métrica utilizada para identificar a disponibilização de dados que atendam os RTOs definidos para cada processo de negócio.

Não entendeu nada? Fique tranquilo, é o que eu mais vejo por aí!

Em poucas palavras o RTO é quanto o processo suporta de perda de dados. Não confunda isto com o último backup realizado, equívoco bastante comum entre os profissionais de contingência, infra-estrutura.

O último backup realizado pode servir como métrica para desenvolver uma estratégia para garantir a continuidade de processos de negócios, mas o RTO consiste em um objetivo, como o acrônimo RPO (Recovery Point Objective) deixa claro.

Vamos tentar clarear as coisas. Aconteceu um incidente, preciso restabelecer um processo dentro do objetivo de recuperação que eu identifiquei (RTO). Para restabelecer este processo eu preciso de dados, ai entra o RPO. Se eu preciso de dados de 2 horas (meu RPO) antes do incidente e meu último backup é de 24 horas atrás, tenho um problema sério.

Recovery Point Objective

Para atender o meu RPO de duas horas preciso alterar a minha estratégia de backup ou fazer uma reengenharia no processo.

Porque reengenharia no processo?

Porque não é sempre que o meu problema é apenas com dados digitalizados. Se o problema é backup, eu posso mudar minha solução de backup, alterar a estratégia. Agora se o processo depende de informações "não digitais"? Ai só uma reengenharia no processo pode resolver ou minimizar os impactos.

28 de dezembro de 2007

links for 2007-12-28

19 de dezembro de 2007

Recovery Time Objective

O termo RTO (Recovery Time Objective) é conhecido pela maioria dos profissionais que atuam direta ou indiretamente com Continuidade de Negócios.O RTO consiste no tempo em que determinado processo tem para que, uma solução de recuperação e/ou contingência seja executada/ativada antes que o processo venha causar impacto a organização.

Se já sabemos o que é o RTO, não existe dificuldade em identificar junto aos responsáveis pelo processo, qual o RTO de cada processo. Errado, boa parte dos RTOs identificados em trabalhos de Continuidade de Negócios não condizem com a realidade e acabam direcionando as organizações a tomar decisões precipitadas.

A primeira coisa que devemos nos ater é, o RTO é apenas o tempo que o processo tem disponível para ser suportado por uma solução alternativa que o mantenha a níveis satisfatórios sem causar impactos a organização. Neste tempo teremos apenas uma solução de contorno (Workaround), o que difere do tempo total que um processo pode ficar indisponível. O tempo total que um processo pode ficar indisponível é definido segundo a BS 25999-1 como MTPD (Maximum Tolerable Period of Disruption).

Então podemos identificar pelo diagrama abaixo que, eu preciso subtrair do tempo total que o processo pode ficar indisponível o RTO mais o tempo para reestabelecer a normalidade.
MTPD

Se não bastasse o equívoco cometido quanto aos tempos de RTO/MTPD, muitos generalizam o tempo assumindo que o MTPD é o RTO, ainda temos um problema mais sério. A maioria dos RTOs mapeados em projetos é muito mais baixo do que deveria. Na prática são raras as exceções onde um processo tem RTO menor que 1, 2 hora. O que quero dizer com isto? A maioria dos profissionais valorizam muito os RTOs sem medir ou conhecer as consequências. Um processo que pode ter até 24 horas de RTO é mapeado com um 1 hora como se não houvesse problema nisto.

O grande problema quando mapeamos RTOs relativamente baixos é a solução de estratégia. Sabemos que os RTOs e critícidades dos processos da organização são mapeados na BIA (Business Impact Analysis), fase esta que antecede e serve como tomada de decisão para a próxima fase, seleção de estratégia.

Na fase de Seleção de Estratégia vamos planejar e identificar soluções para atender os tempos mapeados como objetivo (RTO) na BIA. O que acontece quando os RTOs são muito baixo? As soluções para atender estes tempos serão soluções de alta disponibilidade e consequentemente terão um custo muito mais alto que qualquer plano de resposta. Ao contrário do que muita gente pensa, Se sabemos que são raras as exceções de RTO entre 1 e 2 horas, consequentemente são raras as exceções onde você necessita de Alta Disponibilidade para atender as necessidades da organização.

Resumindo, Planos para Continuidade do Negócio estão longe de ser soluções de contingência e a maioria das organizações estão gastando mais do que deviam com soluções de Alta Disponibilidade e Contingência.

No próximo post vou falar sobre o RPO (Recovery Point Objective).

17 de dezembro de 2007

15 de dezembro de 2007

links for 2007-12-15

USB Insecurity

Um assunto comum entre profissionais de segurança recentemente é a disponibilização ou não, de acesso a porta USB de computadores corporativos. Com acesso USB pode se conectar desde de dispositivos de mass storage (pendrive), até periféricos como impressoras.

O problema é que através deste recurso pode-se roubar informações, conectar dispositivos que possam comprometer a segurança do computador, até dar boot em sistemas operacionais.

Esta breve introdução é apenas para dizer que, se já era necessário atenção quando o acesso a porta era físico, imagine se o recurso for acessado via rede?

É exatamente o que o projeto USB/IP Project se propõe a implementar.

USB/IP Project

13 de dezembro de 2007

links for 2007-12-13

Como funciona a cabeça de um hacker

Eu sou leitor assíduo de um site chamado HowStuffWorks, não preciso nem traduzir o título do site. Eles acabam de escrever um artigo bem interessante (apesar de ser escrito para leigos) sobre a cultura, hacker.

O artigo chamado "Como funciona a cabeça de um hacker" está estruturado em 8 tópicos:

1 - Introdução
2 - Tipos de hackers e suas características
3 - O que motiva o hacker
4 - Como atacam os hackers
5 - A ciência do hacking
6 - Hackers que fizeram história
7 - O glossário do hacker
8 - Mais informações

O artigo começa esclarecendo como surgiu a cultura e qual a origem do termo hacker e passa por termos conhecidos como:
Leet ("lito" como diria meu amigo Wendel): A própria palavra leet admite muitas variações, como l33t ou 1337. O uso do leet reflete uma subcultura relacionada ao mundo dos jogos de computador e internet, sendo muito usada para confundir os iniciantes e para firmar-se como parte de um grupo.

White Hats (hackers éticos): Seguem a mesma linha de pensamento original do hacking. Gostam apenas de saber e conhecer mais das coisas, principalmente as fechadas ao público. Para essas pessoas, aprender é a diversão mais importante do mundo. Elas gastam boa parte de seu tempo estudando o funcionamento do que as cerca, como telefonia, internet e protocolos de rede e programação de computadores.

No mundo da segurança de sofware, os hackers éticos são os responsáveis por “informar” as grandes empresas de vulnerabilidades existentes em seus produtos. Fora do mundo da segurança, essas pessoas são responsáveis por desenvolver software livre, como o sistema operacional GNU/Linux.

O hacker ético defende o conhecimento em prol de todos, portanto não o utiliza para prejudicar outras pessoas ou companhias, a menos que considere que uma empresa faz mau uso do poder. A quebra da segurança do iPhone, que bloqueia o seu funcionamento com outras operadoras de telefonia, foi um notável ato de um White Hat.

Black Hats (hackers mal-intencionados): Assim como os White Hats, os Black Hats também são movidos pela curiosidade. O que os distingue é o que cada um faz com a informação e o conhecimento.

O Black Hat vê poder na informação e no que ele sabe fazer. São aqueles hackers que descobrem uma vulnerabilidade em um produto comercial ou livre e não contam para ninguém até que eles próprios criem meios de obter dados sigilosos de outras pessoas e empresas explorando a vulnerabilidade recém-descoberta.

Essa espécie de hacker é responsável por gerar a terceira espécie, os script kiddies. Eles surgem quando cai na rede uma ferramenta ou técnica de invasão criado por um grupo de Black Hats.

Por ser escrito de forma simples e para leigos, esclarece vários pontos comumente confundidos por quem não é da área. Vale destacar as referências, que vão de Barata Elétrica (Conteúdo não "hard", mas quem não leu?), um mirror do site Unsekurity e os tradicionais phrack, securityfocus e packetstorm.

11 de dezembro de 2007

links for 2007-12-11

Business Continuity and Incident Response

A coisa está ficando ótima para quem trabalha com Continuidade de Negócios. Calma, não estou falando que estamos ganhando rios de dinheiro ou que o mercado está bombando. Eu me refiro a quantidade de padrões que estão surgindo para embasar argumentos que muitas vezes ecoavam nos corredores sombrios das organizações e nada era feito.

O mercado está cheio de curioso, charlatão, marqueteiro, que diz conhecer Continuidade de Negócios, todos eles usam a famosa bomba de fumaça: Plano de Continuidade orientado a ISO 27001 e agora o mais novo hype, BS 25999.

Os mais informados sabem que nenhuma das duas lhe ajudará ou dará o caminho das pedras para desenvolver um processo de Continuidade de Negócios. A ISO 27001 apenas diz que você deve ter um plano, a BS 25999 é um sistema de gestão dos controles relacionados ao processo de Continuidade de Negócios.

Um profissional que conheça além de meia dúzia de Buzzword relacionados ao tema, agora tem dois padrões bem interessantes.

Série 28000 - Security management systems for the supply chain

Este padrão vem colaborar com os conceitos básicos de Continuidade de Negócios e segurança. Continuidade de Negócios deve gerenciar riscos com uma visão holística e segurança é transitiva. Do que adianta eu ter inúmeras soluções de alta-disponibilidade e contingência, se meu negócio pode parar se um fornecedor chave por algum motivo deixar de me fornecer?

ISO/PAS 22399 - Guideline for incident preparedness and operational continuity

Este padrão foi recebido com imensa alegria por mim. Sempre que eu tentei dizer que todo o processo de Continuidade de Negócios são controles de resposta a incidentes, achavam que eu era louco, que estava inventando moda.

Agora quem está dizendo é a ISO e não eu. Agora vou dar uma de louco novamente!

Todo profissional de segurança adora falar coisas como estas:


  • Não existe segurança 100%

  • Segurança é equilibrio



Se sabemos que, em algum momento um incidente vai acontecer, deve existir um equilibrio entre controles e procedimentos de resposta. Por que pouco se investe em Resposta?

5 de dezembro de 2007

links for 2007-12-05

Flash Insecurity

Eu nunca gostei de flash em sites web, ainda mais agora que existe inúmeras opções para fazer RIA (Interface Rica) de forma muito mais limpa.

Depois destas apresentações então, estou fora!

1 - Finding Vulnerabilities in Flash Applications

2 - Testing Flash Applications

SCADA Security

Já não é novidade que eu me interesso por segurança em aplicações SCADA. Sempre que encontro uma notícia eu dou pesquisada para ver se encontro mais informações. O próximo passo é brincar com um simulador, afinal ainda não tive a oportunidade de mexer em um ambiente deste.

Se os riscos já são bem divulgados nos EUA a tendência é aumentar os riscos e a exposição. Encontrei alguns projetos relacionados a SCADA bem interessante.

1 - Um cliente web para SCADA;

2 - Um Scada Open Source;

3 - Uma HoneyNet SCADA;

4 - Link Encryption para SCADA.

O SCADA trabalha usando usando o protocolo DNP3. Protocolo que pode trabalhar via TCP/IP.

Business Continuity And Solutions

Quando aqui no Brasil vamos ter soluções que são muito mais que recursos de HA (Alta Disponibilidade)?

O Estado do Texas nos EUA está implantando um sistema muito interessante baseado em RFID. Evacuação de ambientes é uma coisa bem crítica em determinadas situações, o sistema vai rastrear todos os envolvidos e monitorar uma evacuação.