A segurança é uma decisão de negócio

A quantidade de risco que um negócio pode assumir é determinada pela sua própria cultura, a sua sensibilidade de risco da sua reputação e a sua tolerância à perda.

O propósito de alinhar a segurança das TI com a do negócio vai muito mais longe do que garantir que todos têm a mesma pauta de música e estão afinados. A chave está na existência de uma boa política de aceitação do risco para que os objectivos se alinhem.

Definição de Aceitação do Risco

Quando uma organização toma uma decisão acerca do risco só pode fazer de 3 escolhas:

Aceitar o risco tal como foi avaliado – a organização pretende tolerar o impacto potencial de uma segurança comprometida.

Mitigar o risco – reduzir o nível de risco através de controlados melhorados até atingir um nível aceitável.

Terminar a actividade – isto implica que o risco não pode ser reduzido, até um nível aceitável, com efectividade de custo para a actividade de negócio que está a criar o risco.

A forma como estas decisões são tomadas e por quem são definidas na Política de Segurança de Informação da organização. Decisões de Ao Nível de risco podem ter de ser tomadas pela Comissão Executiva enquanto os riscos de baixo nível podem ser decididos pelo proprietário do negócio.

Em todos os casos, a decisão deve ser baseada numa avaliação formal do risco real. Sem surpresa, este processo é denominado Avaliação de Risco e é o trabalho da Segurança da Informação garantir que o risco é avaliado de forma regular.

A actividade de Avaliação de Risco

Risco = Impacto x Ameaça x Vulnerabilidade. Esta não é uma verdadeira fórmula matemática, mas é uma equação que declara que o risco é a combinação do impacto de uma perda e a capacidade de uma ameaça explorar uma vulnerabilidade.

Uma avaliação de risco abrange todos estes factores para determinar o nível de risco. Os controlos de uma organização são, também, analisados para determinar se estão adaptados à tarefa de gerir as vulnerabilidades. Há métodos quantitativos (ou seja $$) e qualitativos (por exemplo, alto, médio e baixo) para a avaliação do risco; ambos são desenhados para comunicar decisões sobre o risco.

A Ligação ao SLA

Qual é a quantidade suficiente de segurança? O negócio já tomou esta decisão na sua aceitação formal do risco. A um nível prático, O Service Level Agreement (SLA) pode referir-se ou às Política de Aceitação do Risco, ou defini-la com mais detalhe para um serviço particular em questão.

Muitas vezes o SLA documenta a frequência com que a avaliação de risco deve ser realizada e define o proprietário do negócio que está apto para tomar as decisões acerca do risco e até que nível. Pode ainda definir os níveis de risco para os quais as decisões devem ser delegadas para outras pessoas. Um SLA deve produzir investimentos de TI com custos justificáveis e o processo de aceitação de risco produz automaticamente investimentos de custos justificáveis em controlos de segurança.

Conclusão

A segurança da informação assumiu uma muito maior importância para as organizações nestes anos recentes devido à regulação, confiança nos sistemas e às preocupações dos clientes e empregados. Isto deveria reflectir-se em decisões sobre o risco pelos proprietários do negócio que directamente podem experimentar a perda potencial.

Mas, neste pequeno paìs da Europa, parece que nada pode acontecer e, portanto, gastar recursos e tempo na avaliação de risco é uma opção de segunda prioridade.

Quando o projecto corre mal

Estava tudo a correr suavemente e bem quando, de repente, verifica que está atrasado e acima do orçamento e sem fim à vista. Para voltar ao caminho necessita cumprir um processo. Proponho-lhe 8 passos neste processo.

1. Avaliação:

A primeira coisa que tem de fazer é pesquisar até que ponto está fora do caminho. Exactamente, quantos dias está atrasado relativamente ao planeado e o que é isso em % da linha de tempo? Também, quanto está acima do orçamento e o que significa isso em % do orçamento global?

2. Re-planear:

De seguida reveja o seu Plano do Projecto, para verificar se consegue recuperar tempo através de mudanças nas atribuições das actividades. Primeiro, veja se pode realocar pessoas a actividades de forma mais expedita poupando tempo. Em seguida, verifique as dependências das actividades e veja se há uma sequência mais lógica que consiga completar mais cedo os prazos. Assegure-se que identifica o caminho crítico no seu plano para que saiba que actividades devem ser concluídas e quais são secundárias. Assim, atribua os seus melhores recursos às actividades críticas e tente concluí-las mais cedo. Todo o tempo que consiga poupar através do replaneamento vai-lhe ser precioso.

3. Brainstorm:

Reúna-se com a sua equipa e reveja o plano replaneado e verifique se em conjunto conseguem obter novas ideias para realizar o projecto mais cedo ou poupar no orçamento. Pode até ficar surpreendido com os resultados que obtém.

4. Diminuir o âmbito:

A forma mais fácil de voltar a colocar o projecto no caminho certo é diminuir o âmbito. Isto significa realizar menos que o previsto originalmente. Faça uma lista dos resultados do seu projecto, priorize-os em relação com os objectivos do projecto e veja se há alguns resultados que possa, com a autorização do Sponsor do Projecto, remover do âmbito do projecto, para o ajudar a voltar ao caminho. Não significa que estes resultados deixam de ser produzidos, antes que poderão vir a ser feitos como actividades isoladas após a conclusão do projecto.

5. Peça ajuda:

Se o seu Sponsor não pretende alterar o âmbito do projecto, então peça-lhe por uma extensão do prazo ou por mais orçamento para que possa atribuir mais recursos para concluir dentro do prazo. Obtenha o seu apoio informando-os do seu atraso. Seja honesto e frontal. Mostre que está disposto a fazer tudo para estar em condições de cumprir o prazo estabelecido, mas que necessita de apoio para isso. Com este apoio tudo é possível.

6. Controle a mudança:

Agora tem de controlar de forma apertada a mudança para que novas funcionalidades ou resultados não sejam adicionadas sem a sua aprovação. A mudança é comum na maioria dos projectos o que o obriga a controlá-la para garantir a oportunidade de sucesso.

7. Reunião:

Realize uma reunião com a equipa para explicar porque é que o projecto está atrasado e a importância dele. Obtenha o apoio deles para trabalharem com empenho e mais horas de forma a serem capazes de o realizar em tempo. Lembre-se que necessita da compreensão de todos e adesão para poder acabar em tempo e dentro do orçamento.

8. Comunique:

Mantenha todos informados do progresso com regularidade. Desta forma manter-se-ão focados e motivados para alcançar os objectivos estabelecidos.

Compreender o Workflow ITIL

Muitas companhias começam a sua implementação ITIL com a função Service Desk e os processos de Gestão de Incidente e Problema. O seguinte exemplo mostra como estes grupos podem trabalhar em conjunto.

Call Center – o Serviço de Call Center redirecciona as chamadas para o apropriado Service Desk ou membro do Service Desk com base nos atributos da chamada. Por exemplo, um utilizador requer assistência na utilização de uma aplicação. Esta chamada é redireccionada pelo Call Center para o agente apropriado no Service Desk.

Service Desk – O agente do Service Desk toma a propriedade do Incidente. Regista o Incidente em preparação de realizar suporte directo ao utilizador, este membro do Service Desk de forma segura realiza as actividades estabelecidas no processo de Gestão de Incidente.

Gestão de Incidente – O agente, torna-se um operador de Incidente no âmbito do processo de Gestão de Incidentes, recolhe a informação e tenta verificar a triagem com o utilizador. Se o agente for incapaz de assistir o utilizador, pode escalar ou abrir um registo de Problema.

Escalar o Incidente

A Escalação é outro ponto de confusão em muitas organizações que planeiam para ITIL. Quando o primeiro nível de tratamento esgota todas as fontes de informação disponíveis e determina que é provável que não seja capaz de concluir dentro da linha de tempo ou é-lhe impossível assistir o utilizador, então o Incidente deve ser encaminhado para outra pessoa (2º nível) ou aberto um Problema.

Assumindo encaminhamento do Incidente para um 2º nível, o agente continua a desempenhar actividades na base da Gestão de Incidentes. A pessoa do 2º nível de Incidente pode residir fisicamente em qualquer sítio, seja num departamento de TI ou mesmo fora da organização, mas desde que trabalhe sobre o Incidente, estará a trabalhar na dependência e controlo da Gestão de Incidentes.

Não há nenhum requisito de que qualquer nível de suporte para além do agente do Service Desk (p. ex. 2º, 3º, etc.) faça parte de qualquer função ou departamento e qualquer linha de suporte pode realizar investigações talvez até com a utilização de procedimentos de teste, ferramentas de diagnóstico, etc.

Como exemplo, na dependência de um Incidente, o segundo nível poderá ser um técnico no grupo de redes ou um administrador que trabalha no departamento de comunicações. É o trabalho realizado, não a estrutura de reporting organizacional que interessa. Isto exige muitas vezes a existência de Acordos de Nível Operacional (OLA – Operational Level Agreements) entre as TI e vários processos, bem como grupos funcionais.

No nosso exemplo continua a ser a rotina do trabalho do dia-a-dia e considerado, contudo, um Incidente. Se o segundo nível determina que não é provável solucionar ou é incapaz de resolver a questão, pode então ser escalado. O número de níveis de suporte é indefinido, sendo único para cada infra-estrutura da companhia ou organização. Não é incomum existirem dois, três ou quatro níveis de Suporte a Incidentes cada um com crescente foco em conhecimento e experiência.

Gestão de Problemas

Em qualquer momento, se parece que a questão é tão complexa ou que exige o envolvimento de múltiplos departamentos tecnológicos ou silos, o Incidente pode exigir a criação de um registo de Problema. Algumas organizações escolhem levantar um Problema sempre que um Incidente não possa ser encontrado na Base de Conhecimento.

Quando trabalha com um Registo de Problema, a equipa passa a trabalhar sob o controlo do processo de Gestão de Problemas. Este exige a nomeação de um “Gestor de Problemas” ou um “Coordenador de Problemas” para liderar o trabalho e supervisionar as interacções entre departamentos.

È neste ponto que é formada uma “equipa de Problema” de técnicos de vários grupos técnicos. Os técnicos do Service Desk (que realizam o suporte de 1º nível no tratamento de Incidentes) tomam agora a responsabilidade de supervisão e monitorização da resolução do Problema, coordenando com o líder da equipa de problema e mantendo o utilizador ou cliente informado conforme for requerido.

Sumário

Precisamente são estas funções e as suas responsabilidades que criam o processo. Como pudemos ver nestes exemplos, a estruturação para os processos nem sempre exige a reorganização dos departamentos. Mas exige muitas vezes formação e organização de equipas dinâmicas para que saibam como e quando devem actuar (por exemplo, Utilização de Scripts para a Gestão de Incidentes) e podem, ainda exigir Acordos de Nível Organizacionais.