Proteger e servir

Vem esta conversa a propósito de estar 3 dias a falar sobre a auditoria das TI e a dificuldade de manter o investimento quando a auditoria é utilizada para garanntir que é suficiente a proteção em posição.

Este lema é certamente bom para as TI, como para outras actividades mais ‘bélicas’. Ouvimos dizer muito este lema, por que parece ser o lema da polícia dos EUA e soa como uma coisa das «berças» que se usa nos filmes.

Quando olhamos para as TI parece-nos que estas só existem para criar novas respostas de TI para satisfazer as necessidades do negócio. De facto, isto não é verdade!

Servir sabemos que é o seu propósito mas também protegem.

O Departamento Financeiro não existe somente para encontrar dinheiro para quaisquer que sejam as necessidades do negócio. O departamento financeiro também existe para se preocupar com a saúde e a segurança da organização. Por vezes o departamento financeiro irá resistir a novas iniciativas simplesmente porque a organização não tem possibilidade para as custear. Esta então faz tudo para que a sua posição seja escalada para o Executivo ou para o Conselho de Administração para este decidir se prossegue ou não contra a opinião do responsável financeiro.

Da mesma forma, o departamento de TI existe para proteger os interesses das TI, dos responsáveis da organização, ao mesmo tempo que servem os seus clientes e os utilizadores. Os dois interesses algumas vezes não se alinham. A fixação corrente no Cliente – o culto do Cliente – pode ser errada e perigosa. O departamento de TI deve proteger os activos de TI da organização. Esta actividade inclui:

· A própria informação, a sua confidencialidade, integridade e disponibilidade;

· O investimento nos sistemas existentes para gerir, suportar e usar a informação;

· A capacidade para implementar sistemas novos e alterados: arquitectura, análise, desenho, desenvolvimento e implementação.

Algumas vezes, não é do melhor interesse da organização abandonar estes investimentos ou aumentar os riscos para a confidencialidade, integridade e disponibilidade da informação, de forma a responder a novas necessidades para novas TI para os clientes ou, por outro lado, por que o departamento financeiro considera que não há dinheiro para os custear.

Em qualquer dos casos, as TI devem resistir (aconselhar em desfavor) à mudança e escalar para o Executivo ou para o Conselho de Administração para este decidir se prossegue ou não.

As TI não podem ser encaradas só como um centro de custo, pelo contrário, se as suas principais actividades têm a ver a defesa da informação avultam sempre as destinadas ao prosseguimento do investimento e em apoio e resposta às necessidades dos seus clientes – o negócio. Sem este esforço de investimento, a resposta do negócio ao ambiente seria inadequada e impediria a obtenção dos resultados positivos que permitem a afirmação e desenvolvimento da organização.

Luis Quintino

Como planear um projecto Prince2

Um guia para gestores de projecto

"Um objectivo sem um plano é só um desejo." - Antoine de Saint-Exupery

O que é isto?

Planear é um processo muito natural. Todos os dias fazemos muitos pequenos planos (por exemplo, o que é que vamos ver na TV esta noite, onde é que vamos no fim-de-semana, onde é que vamos nas férias). O processo é tão natural que o mais provável é que nem sequer pensemos que se trata de planeamento, só mais uma forma da vida diária. O facto é directo, todos planeamos todos os dias e somos (como um todo) muito bons nisso.

 

De que se trata?

Tente sempre planear os projectos como naturalmente os planeia. Utilize o seguinte guia:

Comece por aquilo que pretende alcançar com o projecto (isto é, o seu objectivo) e decomponha-o em coisas que tem de fazer para o alcançar. Por exemplo, se quiser umas ‘boas férias’ no próximo ano (e pretender conseguir uma reserva barata) pode querer começar hoje o seu projecto da «próximas férias». Sabe que para ter umas boas férias tem de fazer uma reserva de férias, reserve também espaço num lar para o gato e assegure-se de que alguém toma conta dele. Numa data acordada terá de pagar a Reserva e fazer a mala e obter transporte para o aeroporto. São seis coisas (a que chamamos ‘produtos’) que temos de fazer para alcançar o nosso objectivo.

Comece pelo fim do projecto e venha de trás para afrente para ter uma ideia dos ‘produtos’ escolhidos, porque os produtos finais temos uma boa ideia do tempo que tem de estar definidos para os obter antes da obtenção do objectivo.

Faça a revisão dos tempos e assegure-se de que tem os ‘produtos’ pela ordem correcta. Muitas vezes é óbvio mas em outros casos não é assim tanto. Reserve algum tempo para garantir que alguma coisa que queremos fazer na próxima semana não esteja dependente de outra coisa que só pode ser iniciada no próximo mês.

A outra coisa que termos só de considerar nesta etapa é por alto quanto é que isto irá custar. Lembre-se que isto, neste momento, é só uma estimativa.

Possui agora um plano de alto nível (todas as coisas que (pensa) necessita fazer; nas datas que (pensa) necessitar delas). Agora decida o que tem de acontecer agora e/ou nas próximas semanas e chame-lhe a ‘primeira etapa’. Se apropriado divida o resto do projecto em etapas e registe-as no seu plano. Agora foque-se na sua primeira etapa e naquilo que tem de fazer. Para cada ‘produto’ na primeira etapa, deve responder a algumas perguntas específicas:

• O que tenho de fazer?
• Qual é o orçamento?
• Quem vai fazer o trabalho? E estará disponível para o fazer? (já falámos com eles e conhecem o projecto).
• Como é que vou saber quando está terminado na forma adequada?

Com a resposta a estas perguntas criamos um pequeno plano para a etapa e para que consigamos obter os ‘produtos’ completos.

A não ser que seja você a fazer o trabalho, não se preocupe com as tarefas passo a passo de como é que o trabalho será feito, antes acorde a sua realização com quem irá ser responsável por cada ‘produto’ e saiba como se irá manter em contacto. Isto é, Como e quando será informado do progresso e como irá ser comunicado se as coisas correrem de forma inadequada.

Finalmente, quando tiver concluído o seu plano, peça a toda a gente para olhar para ele e pense simular o que é que poderá correr mal. Isto pode parecer muito pessimista mas pode poupar tempo e esforço mais tarde. Para tudo aquilo que pode correr mal veja se pode fazer alguma coisa para reduzir as possibilidades de isso acontecer. Pense também o que poderá fazer se de facto correr mal. Mantenha todos estes riscos para o projecto num Registo do Projecto e reveja-os com regularidade.

 

Quem faz o quê?

Como gestor do projecto será o responsável pelos planos do projecto. Isto não significa, no entanto, que os deve escrever isolado, longe disso. Consulte as pessoas o mais possível, tente realizar workshops para incluir os outros no seu plano.

 

Quando é que acontece?

Planear é um esforço contínuo ao longo do projecto. Podem acontecer muitas coisas durante o projecto que o irão forçar a fazer mudanças controladas aos seus planos. Nenhum plano deverá sobreviver na sua forma original desde o início do projecto até ao seu fim.

 

Dicas e armadilhas

Se tem de usar uma ‘ferramenta’ como o MS Project, lembre-se que esta irá tentar e forçar o planeamento ‘não natural’, isto é, adicionar actividades individuais desde o início do projecto até ao fim, assim tente planear primeiro os ‘produtos’ e depois carregar os dados na ‘ferramenta’.

Planeia a próxima etapa antes do fim da etapa corrente. Quando chegar ao fim da etapa, apresente ao sponsor uma visão completa do que foi realizado até à data e o que é que pretende realizar na próxima etapa.

 

Documentos chave

 

O Documento de iniciação do projecto (PID)

O PID é o centro de toda a informação de definição relacionada com o seu projecto. Ou seja, os seus objectivos, o business case, as comunicações, o plano de qualidade, etc.

 

O plano do projecto

O plano do projecto compreende o seu plano de alto nível e o plano da etapa corrente. Pode ter muitas formas e isso exige que você garanta que usa alguma coisa apropriada para o projecto que está a gerir. Note que os planos de projecto são muitas vezes definidos dentro do Documento de iniciação do projecto (PID) em vez de num documento separado.

 

Descrições de produtos

A maneira mais fácil de chegar a acordo nos ‘produtos’ é utilizar descrições dos produtos – podem ser contidos numa folha de papel e deforma sucinta conter toda a informação que o gestor do projecto e a pessoa responsável pelo ‘produto’ necessitam para realizar com sucesso o produto.

 

Work Packages

Um work package destina-se a acordar uma relação de trabalho entre o gestor do projecto e o responsável pelo trabalho para a realização de uma parte ou de um ‘produto’ do projecto.

 

O registo do projecto

Detalha todos os riscos do projecto e toda a outra informação e é muitas vezes o documento mais útil a par com o PID e o plano.

Análise de Risco do Projecto: O que é e porquê fazer?

Os planos de projecto são, evidentemente, acerca do futuro tudo o que trata do future tem certa incerteza associada. Quando se estima a duração da actividade em 5 dias está intrinsecamente assente que isto pode provavelmente não ser assim mesmo. Pode haver uma pequena quantidade de incerteza ou uma grande, mas alguma haverá com certeza.

Como resultado da incerteza acerca das durações das actividades, qualquer estimativa da data de conclusão do projecto é só isso, uma estimativa. Esta será válida tão só as estimativas das durações das actividades se verifiquem como verdadeiras. Como há sempre muitas actividades, é quase certo que muitas delas tomem menos tempo que o estimado enquanto outras levarão mais tempo que o estimado.

Assim, na realidade o fim do projecto é provável que não possa ser projectado de forma tão determinística como o CPM e o PERT, mas esteja, talvez, dentro de um limite de datas que se pode espalhar simetricamente à volta da estimativa. (Na realidade é pior do que isso. O uso de estimativas determinísticas também introduz um preconceito de tal forma que as estimativas tendem sistematicamente para serem optimistas.)

A Análise de Risco do Plano (Schedule Risk Analysis) é uma técnica que reconhece esta incerteza ao substituir a duração determinística para cada actividade pela distribuição representando os limites das durações prováveis. Existem métodos analíticos para processar as distribuições de probabilidade em casos simples, mas as redes de projecto são normalmente muito complicadas para que estes possam ser aplicados.

A solução é utilizar uma simulação Monte Carlo. Isto é como simular um evento da vida real através do lançamento de dados, só que isto é feito num computador. Os computadores podem gerar aquilo que é denominado como números pseudo-random. Não são verdadeiramente ao acaso, porque eles podem ser reproduzidos se alguém conhecer o mecanismo de geração: utilizando estes números pseudo-random, podemos gerar séries de distribuições desejadas e estas são usadas numa simulação Monte Carlo para simularem sistemas físicos sobre um grande número de cenários gerados ao acaso.

A simulação Monte carlo tem aplicações em muitas áreas. No contexto de uma rede de projecto, a simulação Monte Carlo:

Usa uma amostra da distribuição definida pelo utilizador para cada duração da actividade.

Faz uma análise de caminho crítico (CPM) com base nas durações da amostra.

Armazena os resultados desta análise de tempo (geralmente de uma forma sumária como um histograma).

Repete os passo de 1 a 3 várias centenas ou milhares de vezes.

No fim deste processo pode produzir histogramas representado a probabilidade das distribuições de qualquer resultado de interesse, que geralmente incluem datas mais cedo e mais tarde de início e datas de fim, folga livre e total e custo para cada actividade.

Como resultado, a data de fim estimado do projecto e outras milestones importantes são representadas por distribuições de probabilidade em vez de estimativas com um único ponto. Assim em vez de prever que o projecto será completado em determinada data – uma previsão que o mais certo é ser errada – podemos fazer previsões mais realistas tais como «há 90% de hipótese que o projecto termine até 31 de Maio.»

Mas, talvez a razão mais importante para fazer uma análise de risco é o equilíbrio anteriormente mencionado, que significa que uma estimativa de um só ponto da conclusão do projecto realizada através de um determinístico CPM ou PERT não está muitas vezes nem dentro dos limites representados pela distribuição probabilística produzida pela análise de risco. A razão para isto é um fenómeno denominado merge bias.

UM equilíbrio fundido (merge bias) ocorre sempre que dois ou mais caminhos convergem numa rede e a incerteza acerca das suas durações é tal que qualquer dele pode tornar-se crítico. Para ilustrar este equilíbrio fundido, considere uma actividade que só tem dois predecessores que correm em paralelo. Suponha que cada uma possa levar qualquer coisa como de 1 a 6 dias com probabilidade igual. E suponha, ainda, que elas não ocupam fracções de um dia. (Isto pode parecer um pouco artificial e até é. No entanto, isto permite que o ponto a ser feito por analogia com o lançamento de dados e sem nos envolver numa montanha de cálculo.)

A duração esperada para cada actividade individual é, claro, de 3,5 (já que 1+2+3+4+5+6 todos divididos por 6): mas qual é o tempo esperado para ambos para se concluírem? A tabela seguinte mostra todos os 36 resultados possíveis para o par de actividades, que pode ser simulado pelo lançamento de dois dados. (Assim , por exemplo, se a primeira levar 5 dias e a segunda só 3 dias. O tempo tomado por ambas para serem completadas é 5 dias e pode ser visto na tabela.

	1	2	3	4	5	6
1	1	2	3	4	5	6
2	2	2	3	4	5	6
3	3	3	3	4	5	6
4	4	4	4	4	5	6
5	5	5	5	5	5	6
6	6	6	6	6	6	6

Das 36 possibilidades, só uma tem 1 como máximo enquanto 11 têm 6 como máximo. Assim tendo só dois caminhos paralelos podemos ver que o tempo que leva a realizar ambas as actividades é provável que seja maior do que a estimativa determinística de 3,5 dias. Se fizermos as contas vemos que o valor esperado é na realidade quase 4,5 dias. Com 3 actividades paralelas, o valor esperado é quase de 5 dias e com 5 actividades é cerca de 5,4 dias. E com 10 é de 5,8 dias. A convergiram claramente para 6 conforme o nº de caminhos paralelos aumenta).

Outra forma de olhar para isto é declarar a Lei de Murphy de uma forma menos pessimista do que Murphy.

“Se houver muitas coisas que possam correr mal então pelo menos uma irá correr mal.”
Numa rede de projecto com caminhos paralelos, basta um caminho correr mal para atrasar a conclusão do projecto. (correr mal significa tão só durar mais do que o esperado. Isto não implica que foi feito algum erro, mas pode ser só o resultado da inevitável incerteza envolvida na estimativa original). É isto o merge bias.

“Nestes assuntos a única certeza é que nada é certo.”  (Plínio o Velho)

Categorias de Riscos a ter em atenção

Os riscos são inevitáveis nos projectos. Não podemos evitar os riscos e conseguir uma suave execução do projecto. Temos somente de aceitar este facto e afastarmo-nos dos riscos iminentes. Estes eventos de risco estão muito bem escondidos em lugares dos mais improváveis, mas confiamos sempre em que o bom tempo e a bonomia dos nossos concidadãos nos permitam alcançar algum sucesso sem sermos confrontados com um destes eventos prováveis.

Os gestores de projecto pesquisam os riscos em locais conhecidos ou dependem por completo da experiência quando identificam riscos potenciais no seu projecto. O seu registo de riscos vai melhorando conforme eles adquirem experiência. Mas este tipo de educação é muito dispendiosa para o projecto e para o sponsor do projecto. Uma exploração sistemática de riscos em áreas problemáticas conhecidas deve ser uma obrigação em todos os projectos. Esta exploração deve ser sistemática e deve, para facilitar, ser realizada com a utilização de uma lista de verificação. Não se pode deixar um aspecto tão crítico do projecto para a memória do gestor de projecto. Esta lista deve ser um documento vivo e deve ser actualizada sempre que factos novos ou conhecimentos estejam disponíveis durante a execução dos múltiplos projectos.

Em sumário, o gestor de projecto deve ter atenção às seguintes áreas de risco:

• Âmbito
• Plano e Esforço
• Asumpções, Dependências e constrangimentos
• Tecnologia
• Critérios de Aceitação e Qualidade
• Pessoas, experiências e competências
• Regulação e Política

Todas estas áreas correspondem a uma lista de perguntas que os gestores de projecto devem colocar quando, de forma obrigatória e regular, abordarem a revisão de riscos para o projecto.

Quanto tempo para implementar a ISO 27001

Esta é a segunda pergunta mais comum no que respeita à implementação da ISO 27001. A primeira é, evidentemente, «quanto é que vai custar?». Bem, mas a resposta não é muito encorajante – porque a maioria das pessoas acha que se faz num par de meses. Só que isto não é realista – a duração mais aproximada se tudo correr bem é: cerca de 1 ano.

Claro que se pode continuar a produzir 50 documentos com fluxos, regras e normas em alguns dias e reclamar que temos regras em conformidade com a norma ISO 27001, mas isto não é aquilo que importa. O que queremos falar é sobre a implementação que faz sentido, que produz resultados – um menor número de incidentes, crescimento da eficiência, poupança de custos, etc.

Tempo para as fases de PLANEAR e FAZER

O esforço principal da implementação será gasto nas fases de Planear e fazer, ou seja, nas primeiras fases mandatórias nas quais são realizadas a avaliação de risco e análise de impacto no negócio e nas quais todos os controlos (incluindo os planos da continuidade do negócio) são implementados. A duração para estas duas fases depende, em primeiro lugar, da dimensão da organização.

• Organizações mais pequenas (até 50 colaboradores) normalmente implementam o standard em 8 meses.
• Organizações médias (até 500 colaboradores) implementam o standard de 8 a 12 meses.
• Organizações grandes (mais de 500 colaboradores) a implementação leva de 12 a 15 meses.

As companhias que arrastam estes projectos demasiado tempo, não conseguem terminar – em tais organizações nunca há suficiente reconhecimento da importância do standard, e assim os recursos financeiros e humanos dedicados ao projecto nunca são suficientes.

Quando falamos de tempo de implementação é importante referir que o trabalho de implementação da ISO 77001 e da ISO 25999 não termina com as fases Planear e Fazer – estes sistemas de gestão necessitam ser mantidos e melhorados (fases Verificar e Agir), o que significa que o trabalho na segurança da informação e na continuidade de negócio não é uma vez mas sim contínuo. Contudo, o esforço para manter e melhorar o sistema de gestão é bem menor que o necessário nas duas primeiras fases.

As coisas que aceleram a implementação

A duração que referimos acima depende de muitos factores, mas geralmente os seguintes factores irão acelerar a implementação:

Realizar a implementação como um projecto – se souber com exactidão quais são os objectivos, quem é o responsável e por quê, se os recursos estiverem dispo níveis e quais são os resultados, não só irá acelerar o processo, mas também aumentará as usas oportunidades de sucesso.

Se já tiver a ISO 9001 ou outro sistema de gestão – os standards não são diferentes de outros sistemas de gestão, o que permite utilizar alguns dos procedimentos e processo existentes e poupar entre 20 a 30% de tempo.

Se já possuir a funcionar muitos dos procedimentos e políticas de segurança / continuidade de negócio – a oportunidade de que a documentação existente seja aceitável para a ISO 27001/25999 irá reduzir o tempo de implementação; também por que já possui na organização uma compreensão acerca da segurança da informação e continuidade de negócio.

Possuir os modelos de documentação adequados – não quero dizer quaisquer modelos de documentação, mas modelos na própria língua, apropriados para a dimensão da companhia e feitos para o propósito das ISO 27001 e 25999. Os modelos livres da internet obrigam à tradução e adaptação, com frequentes revisões.

Possuir o conhecimento – este pode obter-se através da leitura, formação pessoal, cursos online, ou pela contratação de um consultor; sem o conhecimento o seu projecto irá levar mais tempo, e provavelmente nunca será concluído.

A última mas certamente a primeira – o apoio e compromisso da gestão – se este não for obtido e se não for comprometido efectivamente em recursos e em dinheiro, o projecto irá demorar mais ou será concluído mesmo antes de começar.

Em conclusão – a implementação de standards com o estes toma muito tempo o que força a que se faça com este propósito em mente. Se a implementação for realizada de forma superficial ou sem objectivos claros, não irá somente perder uma quantidade de tempo mas também perder uma oportunidade para ajudar a companhia a melhorar e a crescer.

LQ

O Risco, uma técnica simples

Todos os projectos são diferentes e a melhor forma de identificar os potenciais riscos dentro de projectos complexos é recorrer à experiência de projectos passados dentro da mesma área. Mesmo com indústrias diferentes há muitas áreas de risco potencial que podem ser as mesmas ou similares, existindo obviamente áreas específicas.
A primeira abordagem é obter uma visão global das diferentes áreas do projecto tais como:

• Âmbito
• Equipamento
• Tecnologia
• Pessoas
• Escala de tempo
• Orçamento

Em seguida, escolha cada uma destas secções e decomponha-a com mais detalhe. Pode ser útil uma sessão de brainstorming com um pequeno grupo de membros da equipa em representação de diferentes partes dos departamentos e grupos envolvidos. Não deve ser uma actividade que consuma muito tempo, mas é crítica para a gestão com sucesso do projecto.

Âmbito

A natureza do âmbito é a definição do que é e do que não é incluído nos requisitos que o negócio pretende obter. Assim, as áreas que podem correr mal ou causar problemas serão questões que terão a ver com o que é e não é escrito neste documento ou que não foi suficientemente descrito nos documentos do projecto. Os primeiros riscos identificados podem ser «requisitos de negócio pobremente definidos», «falta de pessoal experimentado» ou «requisitos de negócio que não foram aprovados pelo cliente».

Equipamento

Esta área de foco deve incluir o equipamento requerido para concluir o projecto em vez de qualquer equipamento que seja uma entrega ou um resultado final do projecto. Pode incluir hardware de computadores, equipamento fabril para a realização do produto final ou um conjunto de outras possibilidades dependentes do projecto particular. Ao identificar os riscos nesta secção deveremos considerar riscos como «confiança do equipamento», «facilidade de substituição se avariar», «custos da substituição do equipamento avariado».

Tecnologia

Esta secção cobre todas as áreas que tenham a ver com o uso de computadores excepto o hardware físico e outras áreas de inovação ou de desenvolvimento envolvidas no projecto. Deve ter-se atenção às dependências com pacotes de software (quer internos como externos) e sistemas de gestão de bases de dados, com outros fornecedores de tecnologia a usar no projecto.

Pessoas

Até que ponto são críticas as pessoas existentes para o sucesso do projecto. Eles possuem conhecimentos especializados que podem ser difícil ou muito dispendioso obter em outro lado. Deve enfrentar-se também a possibilidade de haver uma grande mobilidade das pessoas ou, ao contrário, as equipas estão bem motivadas e estabelecidas e irão permanecer durante o decurso do projecto. Se for o caso de ser gestor de um projecto grande e global, pode até ocorrer que não conheças as equipas em localizações diversas e só tenha contacto com gestores de projecto locais. O conhecimento sobre a dinâmica e construção das equipas pode ser muito útil para a avaliação de riscos potenciais.

Escala de Tempo

Os primeiros problemas têm a ver com o detalhe e correcção das estimações efectuadas para todo o projecto e cada actividade individual. Se o projecto for qualquer coisa diferente de tudo o que fez antes, serão as estimativas meras adivinhas? Quando as escalas de tempo foram determinados por um imperativo de negócio por virtude uma data determinada pelo mercado são acrescentados novos factores de risco no agendamento. Todos estes factores afectam o tipo e a probabilidade dos riscos para as escalas de tempo do projecto.

Orçamento

Se o orçamento foi determinado por um imperativo do cliente em vez do custo real pode não oferecer os meios para concluir o projecto. Um orçamento limitado, por outro lado, não é necessariamente uma causa de insucesso para o projecto. Um bom gestor de projecto possuirá as competências requeridas para obter o máximo de um orçamento limitado e minimizar também os riscos dentro de um projecto deste tipo.

Em geral

De facto muitos factores que gestores de projecto menos experientes podem pensar que criam um projecto mais «arriscado» são muitas vezes factores que podem ser facilmente geridos porque ocorrem frequentemente, como ó caso de recursos limitados, escalas de tempo apertados ou orçamento limitado. É mais provável que o risco provenha de factores que ocorrem com menos frequência como tecnologia ainda não totalmente testada ou produtos, e estes podem tirar um projecto do seu curso.
Desta forma, a identificação dos riscos num projecto é crítica para os gerir com sucesso e estas áreas que, em breve, descrevemos são as mais importantes para o gestor do projecto considerar ao identificar os riscos. Para projectos maiores e mais complexos, a gestão de risco será um trabalho a tempo inteiro e exige que o gestor de projecto tenha a formação e as competências para o assumir com efectividade
.

Porque falham os processos numa crise

A tecnologia é um componente crítico de todos os negócios. Durante uma crise, se a organização de TI é incapaz de responder pode por toda a companhia em risco. Entretanto, durante uma crise aquilo que muitas vezes inibe uma organização de TI de responder com efectividade é exactamente a mesma coisa que a deveria salvaguardar – a confiança em processos disciplinados.

O problema fundamental é que a introdução das disciplinas de processo na gestão operacional de TI, na última década, criou uma atmosfera em que a gestão intermédia de TI fica muitas vezes com medo de tomar decisões e falta-lhes competências de criatividade e liderança. Contudo, durante uma crise, o que é mais exigido antes de tudo mais são essas duas competências.

Embora uma organização de TI possa funcionar admiravelmente sob operação normal, muito poucas organizações conseguiram alcançar uma maturidade tal nas suas disciplinas de processo que sejam capazes de responder efectivamente a interrupções massivas de serviço e negócio. Podem ter protocolos em posição para disaster recovery, mas do ponto de vista operacional os seus processos ficam submergidos durante uma crise devido ao enorme volume e velocidade das exigências operacionais que lhes são requeridas. É neste ponto que os processos fracassam e a organização de TI cai num estado de caos não gerido. É também neste ponto que certos membros da equipa de TI se «destacam» e «fazem tudo o necessário» para resolver as coisas – fazendo ressaltar a cultura de cowboy contra a qual as organizações de TI batalharam durante anos.

Para ultrapassar estes desafios, a gestão de TI deve investir no desenvolvimento das competências quer de liderança quer de resolução criativa de problemas a todos os níveis da organização. Estes dois atributos são exigidos não só na gestão sénior mas também a todos os níveis da organização. Durante uma crise, as equipas de TI podem ficar isoladas, sem modelos claros de decisão e dispondo de pouca informação. Elas devem então ser capazes de se auto organizarem, avaliarem a situação, estabelecerem linhas de comunicação e assumirem as funções de liderança de forma dinâmica.

Luís Quintino

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.