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)