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.

Lições aprendidas, são realmente aprendidas pelas equipes?

Um item importante que existe em toda a empresa, mas é muito notório em projetos chama-se: “Lições Aprendidas”. Como o próprio nome diz, devemos aprender algo sobre algum item/entregável/status/comunicação/etapa do projeto que ocorreu durante alguma fase do projeto.

É através das Lições Aprendidas que podemos tornar recorrentes os resultados desejados; e impedir a recorrência dos resultados indesejados

Durante os últimos anos, pude participar de vários projetos, alguns com o escopo pequeno ou simples, outros complexos. Alguns com equipes formada por recursos juniores outros com equipes formadas por profissionais seniores e com grande experiência em sua área de conhecimento.

Em alguns projetos é obrigatório a entrega formal de um documento contendo todas as lições aprendidas pela equipe do projeto aos patrocinadores do mesmo.

Lessons Learned (original: http://www.thefreedomchase.com/wp-content/uploads/2014/04/Entrepreneurial-Lessons.jpg)Em todos os projetos, ocorreram situações onde uma resposta precisava ser aplicada, porém não tínhamos nos preparados para tal situação. Uma ação teve que ser tomada/executada e com isso um resultado foi obtido. Mas, se ocorrem situações em que não houve um planejamento prévio, significa que o planejamento falhou? Pode ser que sim, pode ser que não. Depende do caso…

Bom, mas o que devemos aprender com esta etapa do projeto que não deveria ser esquecida ou ignorada?

Entendo que podemos aprender a evitar que determinadas circunstâncias se repitam, isso vale para a mesma empresa ou não e/ou para projetos semelhantes. Não devemos ter como lições aprendidas a resposta para uma situação. Devemos usá-la como um conhecimento prévio, de modo que determinadas circunstâncias não ocorram novamente.

Escrever, relatar e documentar é algo que muitas empresas não identificam valor, pois a própria empresa não tem a cultura de documentar e ler. Logo, pra que escrever?! Entretanto, existem clientes que precisam saber o que o prestador do serviço aprendeu durante a execução do projeto.

Mas o que devemos levar em conta quando vamos listar/estudar as lições aprendidas?

Vejamos alguns exemplos:

  • O que aprendemos sobre o projeto em geral?
  • O que aprendemos sobre gerenciamento de projetos?
  • O que aprendemos sobre comunicação?
  • O que aprendemos sobre o orçamento?
  • O que aprendemos sobre como trabalhar com os patrocinadores?
  • O que aprendemos sobre como trabalhar com os clientes?
  • O que aprendemos sobre as atividades que ocorreram de forma como foram planejada?
  • O que aprendemos sobre as situações que não ocorreram de forma satisfatória?
  • O que aprendemos que devemos mudar?

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)