Segurança: análise de riscos (ISO/IEC 27002)

A análise de riscos é utilizada para identificar os riscos que a organização possui. Um risco, dano ou perda da informação é determinado pelas ameaças, ou melhor, a chance desta ameaça ocorrer e suas consequências.

Quando a ameaça se materializa, o risco se efetiva.

Vulnerabilidade – fraqueza, associada aos ativos da organização.
Ameaça – uma ocorrência; um fato; explora a vulnerabilidade

PROBABILIDADE é igual a uma CHANCE

Quanto MAIOR a Probabilidade MAIOR o Risco

Risco – é o potencial em que uma dada ameaça irá explorar as vulnerabilidades para causar perda ou dano imediato.

Gerenciamento de Risco – processo que trata as ameaças, riscos e medidas de segurança. É um processo contínuo na qual identifica, examina e reduz a um nível aceitável uma ameaça.

Os objetivos da analise de riscos, são:

  • Identificar ativos e valores;
  • Determinas as vulnerabilidades e ameaças;
  • Determinar os riscos e as ameaças que podem causar danos nos processos operacionais;
  • Determinar o equilíbrio entre custos de um incidente e custo das medidas de segurança.

Análise de Risco Quantitativa

Pretende calcular com base no impacto do risco, a perda financeira e a probabilidade de que uma determinada ameaça torne-se um incidente de segurança.
Os custos das medidas, não devem ser maiores que o valor do objeto a ser protegido do risco.

Análise de Risco Qualitativa

É baseada em cenários e situações. A chance é analisada com base nos sentimentos das pessoas.
Medidas podem ser tomadas para reduzir o risco residual a um nível aceitável.

Medidas para reduzir o risco

As medidas podem ser de redução da chance do evento ocorrer ou da redução de suas consequencias ou a combinação das duas.

Tipos de Medidas de risco

  • Redução: usada para reduzir ameaças;
  • Preventivas: usadas para prevenir incidentes;
  • Detecção: usadas para detectar incidentes;
  • Repressivas: usadas para parar as consequencias de um incidente;
  • Corretivas: usadas para recuperação de danos causados por um incidente.

Gerenciando a Continuidade do Serviços de TI

Plano_continuidadeO Gerenciamento da Continuidade do Serviços de TI (GCSTI) é parte integrante do processo de Gerenciamento da Continuidade do Negócio (GCN). O GCSTI é parte do GCN, pois o GCSTI depende da informação oriunda do GCN.

Se o “negócio”, não gerencia a continuidade de si mesmo, imagina a TI!?

O GCSTI é mais um processo da ITIL e um dos seus objetivos é assegurar a sobrevivência do negócio minimizando o impacto de um desastre ou uma falha.

Algumas empresas insistem em afirmar que possuem um GCSTI. Grande parte não tem o GCN. Faz parte, infelizmente este é o cenário de parte das empresas brasileiras.

Um GCSTI não é contratar dois Data Centers e links redundantes.

Um GCSTI precisa ter:

  • Gestão (administração);
  • Infraestrutura Tecnológica;
  • Procedimentos de Operação;
  • Time técnico qualificado e treinado;
  • Segurança;
  • Contingenciamento de sites;
  • Retorno a operação normal.

É lógico que não basta ter estes itens descritos acima. Algumas atividades são necessárias para que ele funcione corretamente. Uma delas é a realização de Testes de Continuidade.

Possuir sites redundantes nem sempre é financeiramente justificável, desta forma alguns riscos podem ser assumidos.

Não é um processo fácil de ser implementado dentro da empresa. Muitas áreas da empresa precisam estar envolvidas, ou melhor comprometidas. E isso não é fácil.

Se você acha que um GCSTI não é importante, veja este cenário:

Devido à forte chuva da madrugada, um raio atingiu o quadro elétrico afetando a sala dos servidores não disponibilizando os mesmos aos usuários. Vamos ao cálculo de 1 dia de indisponibilidade do serviço.

1000 funcionários x 1 dia (8 horas) x R$ 40,00/hora = R$ 320.000,00/dia

 

 

A Gestão de Mudanças no ambiente tecnológico e de negócio

As mudanças que ocorrem no ambiente tecnológico de sua empresa são gerenciadas?change_ahead

Por definição, mudança é uma determinada ação na qual resultará em um novo status para um ou mais Itens de Configuração (IC’s) no ambiente tecnológico (ambiente tecnológico refere-se à infraestrutura, sistemas e serviços. Resumidamente: Hardware e Software).

Com base na definição acima de mudança, temos algumas questões que podem esclarecer melhor essa definição.

  1. Se “eu” aplicar uma atualização no Sistema Operacional do equipamento X, pois o fabricante descobriu uma falha, estou fazendo uma mudança?
    1. Resposta: SIM.
  2. Por necessidade do negócio, um novo sistema web irá entrar em operação e necessito incluir um novo endereço IP no servidor, para atender este novo sistema. Estou fazendo uma mudança?
    1. Resposta: SIM.
  3. Por motivos operacionais, um usuário que era do departamento de Contas a Pagar foi transferido temporariamente para o departamento da contabilidade. Para que este funcionário tenha acesso ao sistema e arquivos da contabilidade, uma alteração no grupo deste usuário se faz necessário. Ao realizar esse procedimento, estou fazendo uma mudança?
    1. Resposta: NÃO. Neste caso você não está alterando um IC, o que se faz neste exemplo é apenas uma pequena alteração no propriedade de grupo deste usuário.

O efetivo gerenciamento das mudanças se faz presente e necessário em ambientes tecnológicos de todos os tamanhos.

Infelizmente, algumas empresas (geridas por pessoas), a gestão de mudança é muitas vezes encarada como uma “burocratização” no processo do ambiente tecnológico. Mas isso não é verdade!

Tome nota: Burocracia (segundo o dicionário) – 1. Administração da coisa pública por funcionários, sujeitos a hierarquia, rotina e regulamentos inflexíveis. 2. A classe dos burocratas. 3. Morosidade ou complicação no desempenho de serviço administrativo, decorrente do poder abusivo da burocracia.

Veja o simples fluxo abaixo, nele temos um exemplo extremamente simplório de como o fluxo de uma mudança deve ser.

Fluxo de Gerenciamento de Mudanças
Fluxo de Gerenciamento de Mudanças

Basicamente existem dois tipos de mudanças:

  1. Mudança Emergencial – é a mudança que precisa ser realizada o mais rápido possível, de modo a evitar uma paralisação ou perda (financeira, de sistema, etc);
  2. Mudança Comum – é a mudança que precisa ser realizada, para melhorar/atualizar um IC, entretanto a não execução desta mudança não causará impactos imediatos.

Toda mudança precisa ser planejada, antes de ser executada! Não importa se a mudança seja emergencial ou não. O planejamento deve fazer parte da execução da mudança.

Após o planejamento da mudança, um comitê deve aprovar a execução ou não da mudança. Além da aprovação da mudança, o comitê deve apoiar a gestão de mudanças na priorização, seja com uma visão técnica ou com uma visão de negócio. Logo, este comitê deve ser formado por pessoas que entendam as necessidades de negócio e que tenham conhecimento técnico razoável.

Como disse anteriormente, o processo de mudança não é burocrático, pois é através deste processo que alguns ganhos podem ser obtidos, como por exemplo:

  • Melhor alinhamento entre TI e o negócio;
  • Melhor avaliação do custo de cada mudança;
  • Melhor visão, da própria equipe de TI, sobre o processo de mudança
  • Melhor retorno sobre o investimento (ROI)

 

Tecnologia ou Serviço?

Em um estudo publicado pelo Instituto Gartner, mostra que 80% das causas de indisponibilidade são causadas por Pessoas ou Processos (provavelmente pela falta de habilidades ou pela inexistência de processos. Talvez por ambas).

Estes 80%, são divididos em:

  • 20% Software
  • 15% Rede
  • 10% Erro de Hardware
  • 5% Segurança
  • 30% Causas desconhecidas

E os 20% restantes? Os 20% restantes, são erros mais comuns são causados pela Tecnologia.

Conforme já havia escrito no último post (que pode ser lido integralmente aqui), o que as empresas precisam são de Processos e não de ferramentas.

Em um outro estudo realizado, pelas empresas Find SVP, Contingency Planning and Research, Dataquest, Yankee Group, temos alguns dados sobre o custo de uma indisponibilidade não planejada:

  • Operações em Bolsa de Valores: US$ 5.6 – US$ 7.3 milhões
  • Vendas por cartão de crédito US$ 2.2 – US$ 3.1 milhões
  • Área Industrial/Produção US$ 1.6 milhões
  • Vendas por telefone US$ 110,000
  • Reservas de passagens aéreas US$ 90,000
  • Custo Médio por sistema US$ 50,000

Todos os custos são por hora. Sendo que:

  • Número médio de paradas não planejadas no ano: 13
  • Duração média por parada: 4 horas

Quando a TI (Tecnologia da Informação) é orientada a serviço, ela atua como um prestados de serviço, como qualquer outro que a empresa possui. Entretanto, ela possui a facilidade de vivenciar de forma muito clara o dia-a-dia da empresa.

Serviço neste contexto, nada mais é que um grupo de componentes inter-relacionados utilizados no fornecimento de suporte a alguma área de negócio da empresa.
HSPP_Servico

Quando a área de TI passa a se preocupar mais com o serviço prestado e menos qual a tecnologia, ela começa a entender melhor o negócio da empresa a TI tende a ser observada não mais como uma área com muitos custos, mas uma área importante dentro da empresa.

Esta mudança não é fácil, ela é bem complexa de ser realizada e precisa do apoio imediato da alta direção e dos principais diretores.

O que você (departamento/área), da área de tecnologia, fornece para a empresa? Serviço ou Tecnologia?

Projetos: Teorias versus Prática

Há muito tempo que a gestão de projetos deixou de ser algo novo e sem confiança. Hoje em dia, cada vez mais as empresas possuem projetos e consequentemente, precisam que os mesmos sejam geridos.

teoria_praticaAo passar dos anos, muitos estudos foram sendo realizados e algumas metodologias, de como gerir um projeto, foram sendo desenvolvidas. Algumas teorias são mais conservadoras outras nem tanto. Algumas focam no resultado final, deixando de lado alguns fatores “sem controle”.

Mas o foco deste post não é falar das características de cada teoria existente, nem conhecimento e tempo para falar de todas tenho disponível. O que quero relatar, são observações minhas que pude, felizmente, capturar ao longo dos anos atuando como membro de uma equipe de projetos ou até mesmo como gestor de projetos.

Atualmente as duas principais metodologias (frameworks)  que a grande maioria das empresas trabalha são o SCRUM e o guia PMBOK. Existem outras como o Prince2 e uma grande quantidade, quando focamos em desenvolvimento de software.

Ao meu entender são duas excelentes metodologias para a de gestão de projetos.

Com o passar do tempo, uma necessidade que observei e que ao meu entender é deixado de lado por estas metodologias e que é fundamental para que o projeto seja um sucesso é o que eu chamo de “Fator Humano” (relacionamento humano).

Saber controlar os custos/despesas de um projeto é fundamental, até mesmo obrigação do gestor.

Controlar o “escopo” é um assunto para um outro post, mas está diretamente relacionado ao “Fator Humano“.

Em alguns casos, a falta de gestão do “Fator Humano” pode ocasionar a perda de controle do projeto, qualidade inapropriada da entrega, atrasos e tudo isso acarreta perda de tempo. Logo, perde-se dinheiro!

Já tive a infelicidade de presenciar, projetos serem cancelados pela falta de gestão do “Fator Humano”.

O relacionamento humano, a cada dia que passa se torna mais difícil entre empresas e clientes.

No passado, a “palavra” tinha uma importância fundamental. Com o passar dos anos a importância que a “palavra” tinha ficou demasiadamente fraca, sem poder. Foram criados os contratos e por fim, clientes e fornecedores (de produtos os serviços), ficam analisando os contratos para identificar falhas de modo que o produto/serviço não seja entregue ou de forma que o que foi entregue não precise ser pago.

Infelizmente, casos assim ocorrem todos os dias em empresas de pequeno, médio, grande porte, multinacionais e governo.

É uma pena que dificilmente, seja possível adaptar grande parte destas metodologias e utilizá-las realmente na prática.

Como é o gerenciado o Fator Humano em seus projetos?