fundamentos para desenvolver uma política de segurança da informação

Fundamentos para uma Política de Segurança da Informação

O uso de conceitos básicos de Project Management para criar documentos efetivos

Eduardo Vianna de Camargo Neves

[email protected]

Introdução

A primeira Política de Segurança da Informação que escrevi, foi para um banco estatal lá pelos

idos de 1998, e confesso que apesar do resultado final ter deixado o cliente satisfeito, o

desenvolvimento foi um verdadeiro desastre. A instituição não tinha nenhuma política nem idéia

de como fazê-la, e coube a minha equipe partir do zero com base nos resultados de uma

análise de risco prévia para dar conta da tarefa em três meses. O comitê para a elaboração foi

montado, e um grupo que começou com três representantes do cliente, terminou com doze

pessoas que não conseguiam se entender e tentavam a cada reunião criar documentos que

fossem satisfatórios às necessidades deles, e não do banco.

Essa experiência e outras que aconteceram nos últimos anos me ajudaram a entender alguns

conceitos básicos para o desenvolvimento de uma Política, e nenhum deles está escrito em

padrões de segurança ou apresentado em técnicas que podem ser ensinadas em um curso. Eles

têm a ver com um elemento que é cada vez mais importante para o profissional de Segurança

da Informação entender, estudar e inserir no seu kit de ferramentas de trabalho: usabilidade, ou

seja, ter a capacidade de produzir uma ferramenta que atenda às necessidades de uma

instituição e ao mesmo tempo seja simples de ser usada pela comunidade a qual é destinada. A

receita para isso é mais simples do que parece, mas tenho a impressão que a maioria das

instituições não consegue segui-la.

É muito comum você ver políticas que são pura cópia de padrões ou uma tradução literal de

modelos disponíveis na Internet e as pessoas que as implementam ainda tem alguma esperança

de que vão funcionar. Existem algumas etapas que devem ser seguidas sempre que for

necessário criar uma política de segurança e erros que podem ser evitados. Estruturar o

desenvolvimento como um projeto formal no mínimo reduz a probabilidade de ocorrência de

boa parte dos problemas citados, e tem sido uma opção de sucesso que tenho seguido há

alguns anos.

Este artigo aborda o uso de um instrumento comum a maioria das metodologias para

Gerenciamento de Projetos; um documento de planejamento de atividades que serve como

“contrato” entre as partes envolvidas, e permite o acompanhamento do alcance dos objetivos

ao longo do tempo, controle de desvios potenciais e manutenção das premissas que foram

estabelecidas no começo da iniciativa. Definido pela metodologia PRINCE2 como Business Case,

esta ferramenta tem como objetivo apresentar, pelo menos:

As razões pelas quais o projeto deve ser desenvolvido;

Uma análise que justifique as diferentes estratégias que podem ser utilizadas para atingir os

resultados esperados pela Instituição e uma justificativa que suporte a opção escolhida;

Uma lista dos benefícios tangíveis e intangíveis;

Uma análise de custos, benefícios e resultados planejados, e

O quanto tudo isso vai custar.

Camargo Neves RMS

Fundamentos para uma Política de Segurança da Informação Página 2

Conceituando o Projeto

A primeira fase na criação de uma Política é definir qual é o escopo que será utilizado o que

parece óbvio, porém é um conceito que pode ser alterado durante o desenvolvimento das

atividades e comprometer o resultado final. Quando os documentos começarem a ser criados,

possivelmente algumas áreas irão tentar nortear o conteúdo de acordo com seus interesses, o

que na maioria das vezes não é o mesmo da Instituição como um todo. Além disso, ainda existe

o risco de aprofundar em excesso o conteúdo, deixando a simplicidade e eficácia de lado.

Para evitar que isso ocorra e o desenvolvimento da Política seja feito dentro do esperado, é

fundamental iniciar o tratamento do processo como um projeto, estimando quais serão os

componentes da equipe, tarefas que devem ser definidas, metas a serem atingidas, tempo para

cumprimento do cronograma e qual esforço será necessário alocar aos componentes.

Entendendo como um projeto, é necessário observar algumas razões pelas quais eles podem

não terminar como planejado.

Falta de Envolvimento dos Clientes Internos

Quando não existe o envolvimento dos clientes internos, dois fenômenos ocorrem; as pessoas

que irão usar o produto não se sentem satisfeitas com os resultados porque não sabem do que

se trata e sentem uma imposição corporativa, e os membros do projeto definem os resultados

conforme o seu próprio julgamento, que dificilmente tem o mesmo ponto de vista de um

cliente interno que usa o produto como parte de sua rotina.

O envolvimento de um ou mais representantes das áreas que serão afetadas pela Política é

crucial para o sucesso da empreitada. Eles podem não só opinar sobre o conteúdo e redação do

material, como ainda contribuem identificando possíveis pontos de resistência e ajudando na

criação de ferramentas de convencimento (ex. treinamentos e conscientização). O único cuidado

é deixar clara a função representante, que contribui dentro de uma série de definições já

estabelecidas, não podendo mudar o objetivo do projeto.

Subestimar o Cronograma

Estabelecer um cronograma muito longo para um projeto é mais uma receita para o desastre.

As pessoas mudam, as prioridades se movem e todo o ambiente onde as tarefas são

desenvolvidas passa por transformações, que são cada vez mais rápidas e abrangentes. Uma

recomendação comum aos projetos de grande porte onde o cronograma não pode ser

reduzido é dividir as etapas em projetos menores.

Aplicando este conceito ao desenvolvimento da Política, é possível definir uma série de

atividades que sejam divididas em projetos contínuos, mas onde existam cronogramas,

orçamentos, equipes e outros componentes distintos de acordo com cada caso. Uma

recomendação é dividir em, ao menos, quatro projetos; a definição do padrão que será utilizado

como base, o desenvolvimento das políticas, a ampliação das normas estabelecidas para os

padrões, a criação dos guias e finalmente a escrita e implementação dos procedimentos.

Camargo Neves RMS


Requerimentos Inadequados ou Inexistentes

É incrível, mas isso acontece com mais frequência do que deveria. Muitos dos problemas

relacionados aos requerimentos voltam ao primeiro item citado, falta de envolvimento das

pessoas no projeto, mas um componente ainda mais escondido pode ser citado:

desconhecimento em reconhecer a própria ignorância. Apesar de parecer uma afirmação

polêmica, ela é uma constatação em cima de um fato comum no mercado de hoje; muitos

profissionais acham que entendem profundamente Segurança da Informação ou ao menos

querem que a comunidade pense assim. Para criar e desenvolver uma iniciativa focada na

elaboração de uma Política é necessário que o gerente do projeto entenda de políticas e

procedimentos e busque o apoio de profissionais com especialização em todos os campos que

serão abordados; segurança de aplicações, planos de contingência, segurança física e outras

disciplinas envolvidas.

Escopo Inadequado

O escopo é uma definição clara de como o projeto irá funcionar e o que ele irá abordar. O que

pode ser um problema neste caso é a mudança constante de escopo sem critério, o famoso “já

que estamos fazendo isto, vamos aproveitar e …”. Não existe nada de errado em mudar o

escopo de um projeto durante o seu desenvolvimento, mas isso deve ser adequadamente

registrado e mensurado – vide próximo item – além de obrigatoriamente ter que estar

relacionado com o escopo original.

Um exemplo que já testemunhei, foi um projeto de atualização de uma Política quase tornar-se

uma revisão de processos, uma vez que uma das áreas queria “aproveitar” os consultores para

avaliar toda a sua documentação – relacionada ou não à Segurança da Informação – e gerar um

plano de ação de melhorias. Neste caso, o que recomendei e foi aceito pelo cliente na época, foi

continuar o projeto como acordado e incluir uma análise geral da documentação desta área,

gerando um plano de ação bem menos detalhado, mas que foi o suficiente para não alterar o

nosso escopo original.

Inexistência de Controle de Mudanças

Como foi citado no item anterior, não existe nada de errado em alterar o escopo de um projeto,

inclusive o desenvolvimento de uma Política. É bem comum que durante as primeiras análises,

apareçam itens existentes ou necessidades que não haviam sido identificados durante o

levantamento de requerimentos. Mas quando isso ocorrer, a possibilidade de mudança deve ser

registrada, o esforço mensurado, o cronograma ajustado e tudo aprovado pelos patrocinadores

antes de efetivamente serem feitas as alterações.

Uma ocorrência que já vi em mais de um lugar, é a requisição de mudanças de forma

subestimada, onde novos itens são incluídos no escopo e o gerente do projeto acha que o

trabalho adicional decorrente não é extenso o suficiente para requisitar uma mudança formal.

Ledo engano, nenhuma inclusão de escopo pode ser estimada de forma irresponsável, é

fundamental avaliar o esforço da equipe e dos clientes, redimensionar o projeto, registrar a

atividade e obter a aprovação de quem paga a conta. Ao final, ele talvez não aprove a alteração

sabendo o quanto isso pode custar.

Camargo Neves RMS


A Adoção de um Business Case

Uma dificuldade que muitas pessoas que trabalham com Segurança da Informação

compartilham, é o problema em escrever um documento que tenha como público uma

audiência diferente dos profissionais da área, para os quais palavras como criptografia,

acrônimos como DDoS e expressões como snake oil são naturalmente entendidas como parte

do jargão utilizado. Infelizmente as pessoas que recebem e usam os nossos produtos, assim

como as que aprovam as verbas para que eles sejam desenvolvidos, estão em outro mundo e

usam com bastante facilidade outros termos como rentabilidade, CAPEX e capital social.

Para que a elaboração de uma Política de Segurança seja desenvolvida com as facilidades

dispostas em um processo de gerenciamento de projeto, ela deve ser tratada como tal, e a

primeira etapa é escrever um documento que deixe muito claro para este outro público o que

será construído com o dinheiro que eles irão aprovar e como os resultados poderão trazer

benefícios que interessam à Organização. Este documento simples e ao mesmo tempo

completo é o Business Case.

Posicionado como uma ferramenta para definir os conceitos gerais de um projeto e apresentar

as justificativas que mostrem porque a atividade deve ser executada como melhoria para os

negócios de uma Organização, o Business Case pode ser definido como um contrato entre a

equipe do projeto, os patrocinadores e os usuários finais que serve ainda para:

Apresentar aos patrocinadores informações com o detalhamento suficiente para que eles

analisem a proposta e decidam se o projeto pode ser executado.

Ser utilizado como ponto de referência para acompanhamento das atividades planejadas

para o projeto e, ao ser atualizado de acordo com o Gerenciamento de Mudanças, servir de

histórico para que seja possível ter uma visão geral do projeto.

Preparando o Business Case

Um documento voltado para qualquer atividade ligada à Segurança da Informação deve buscar

levar a linguagem deste mercado para o elemento onde as pessoas que irão ler as informações

e aprovar o projeto costumam viver suas rotinas; normalmente um ambiente de negócios onde

clientes, produtos e rentabilidade são palavras mais comuns de serem entendidas com precisão.

Se existe a necessidade de buscar investimentos para custear um projeto, existem basicamente

três pontos nos quais a produção do documento e todo o discurso referente devem ser

guiados:

Mensagem Adequada: A forma como as palavras são escritas, a linguagem narrativa

utilizada e o formato do documento devem ser pensados de acordo com o público que

deverá ser atingido. É uma obviedade que foge na maioria dos documentos que já li nesta e

em outras áreas, pense em como você se sente ao conversar com um médico que detalha

os conceitos de apoptose para explicar queda de cabelo, você se sente confortável?

Argumentação Sólida: De nada adianta usar o discurso FUD ou exemplos exagerados (ex.

World Trade Center) para justificar o investimento. Existem formas simples de identificar

necessidades com base na realidade de cada Organização, e um cálculo de perda estimada

Camargo Neves RMS


de vendas pela parada de um sistema é muito mais eficaz do que uma suposição que um

ciclone pode um dia destruir um depósito de produtos.

Solidificar uma Base Existente: Atualmente clientes, mercados e governos ajudam a

“empurrar” a necessidade da Segurança da Informação, graças a pagamentos pela Internet,

negócios em ambientes B2B e regulamentações como a SOX e mesmo itens da CVM no

Brasil. Estes pontos podem ser usados como base para justificar o investimento, basta ficar

na realidade e buscar um paralelo que faça sentido ao leitor.

Após observar estes pontos, existe a necessidade de criar o documento de forma estruturada e

lógica. O Business Case adere a isto e permite colocar em pouco mais de dez páginas todas as

informações necessárias para documentar o processo de desenvolvimento de uma Política e

justificar de forma adequada o investimento financeiro e alocação de recursos para suportar as

atividades.

Aprofundando os Três Pontos

Em qualquer projeto bem sucedido, a montagem do time que irá desenvolver todas as

atividades é uma etapa essencial, especialmente quando o escopo é uma Política, algo que será

escrito para influenciar diretamente o trabalho de pessoas de praticamente todas as áreas da

Organização. A primeira recomendação é colocar na equipe os profissionais das principais áreas

que serão envolvidas, em especial:

Assuntos Corporativos/Regulatórios: Conhecem o relacionamento da Organização com o

Governo e a Sociedade, e podem ter um papel fundamental na construção de documentos

que estejam de acordo com as necessidades de atendimento de regulamentações e

interesses dos acionistas ou controladores

Controles Internos/Auditoria: Como tem no foco de suas atividades encontrar falhas nos

processos e verificar se os controles estabelecidos estão sendo cumpridos pelas áreas, é

bem comum que as pessoas deste grupo tenham um amplo conhecimento da Organização,

de como ela funciona e tenham uma função de suportar o entendimento geral de como

mantêm seus relacionamentos e dependências.

Legal: Fundamental para esclarecer posicionamentos de cunho legal (ex. pode-se fazer

background screening dos funcionários?) e adequar os textos das políticas, de forma a

reduzir a probabilidade de interpretação inadequada do conteúdo ou questionamento da

legitimidade das normas estabelecidas.

Operações e Vendas: Se nenhum membro das áreas anteriores puder participar, ao menos

um ou dois representantes das áreas de produção e relacionamento com os clientes têm

que ser nomeados. São estas pessoas que estão em contato com a maior parte dos

funcionários e pessoas de esferas externas (clientes, fornecedores, concorrentes, etc.) e

podem dizer se as regras de uma política serão facilmente seguidas ou não.

Com o time estabelecido, passamos ao entendimento dos pontos citados na introdução deste

documento, que devem ser aplicados como base para construção do Business Case para o

projeto de Política, e que certamente pode ajudar a elaboração de documentos similares para

qualquer iniciativa relacionada à Segurança da Informação.

Camargo Neves RMS


Mensagem Adequada

Políticos profissionais são mestres em adequar a mensagem à audiência desejada. Uma

estratégia famosa ocorreu durante a campanha presidencial de 1960 nos EUA, onde John

Kennedy concorreu com Richard Nixon e ganhou. Apesar de todos os demais elementos que

cercam uma campanha deste porte, Kennedy foi aos poucos passando a sua mensagem da

forma que os eleitores queriam ouvir, culminando no primeiro debate na televisão, onde esta

estratégia foi usada de forma genial.

Nixon tinha recém saído de uma temporada no hospital, estava com a aparência cansada e não

quis ser maquiado para as câmeras. Kennedy, ao contrário, estava em plena forma, bronzeado,

maquiado e adequadamente vestido para aparecer nesta mídia, com uma camisa branca por

baixo do terno. Reza a lenda que vendo a camisa azul de Nixon, os assessores democratas

desligaram o ar-condicionado do estúdio, acrescentando aos problemas de Nixon um suadouro

incessante que marcou sua camisa e rosto, e o fez parecer extremamente nervoso para os 80

milhões de espectadores.

Guardadas as devidas proporções, é exatamente isso que deve ser pensando ao elaborar o

Business Case; como a mensagem será passada para uma audiência que deverá ver não um

documento de regras e procedimentos que irão emperrar o negócio (se você trabalha na área,

já deve ter ouvido isso), mas sim uma ferramenta que irá agregar valor e permitir que a

Organização trabalhe de forma segura.

Para que isso seja possível, palavras como “provável”, “estimado” e outras que remetem a uma

probabilidade que pode nunca se tornar um fato, devem ser evitadas. Use verbos e frases que

mostrem certeza no discurso e seja claro, objetivo e pragmático. A tabela apresentada abaixo

adaptada de um documento publicado pela TruSecure em 2004, onde acrescentei alguns

elementos que ajudam a mostrar essas diferenças. Use-a como base para identificar a

linguagem necessária ao seu Business Case, e se não for suficiente, peça para pessoas de outras

áreas lerem o documento, criticarem o que não entenderam e proporem mudanças.

Audiência Necessidade Exemplos

CEO Como este projeto pode

agregar valor à

Organização?

Como os acionistas irão

perceber isto?

Aderência a regulamentações exigidas

pelo mercado (ex. SOX).

Alinhamento com as necessidades dos

clientes (ex. e-commerce).

Satisfação dos acionistas (ex.

incremento de segurança das

informações financeiras).

CFO Em quanto o custo

operacional pode ser

reduzido?

Como a produtividade das

áreas pode aumentar?

A garantia de continuidade de

processos pode gerar redução dos

custos com seguros e sistemas

redundantes. (ex. Business Continuity)

Um ambiente documentado aumenta

o índice de qualidade (ex. Six Sigma) e

mantêm a inteligência competitiva

dentro da Organização (ex. Knowledge

Management)

Camargo Neves RMS


Audiência Necessidade Exemplos

Diretor de

Vendas

Como as vendas podem

ser melhoradas?

Como a satisfação do

cliente pode ser mantida?

A integridade de uma base de dados é

fundamental para garantir o

funcionamento adequado de um CRM.

A disponibilidade de um sistema de

atendimento é fundamental para

reduzir os custos de chamadas em call

centers e garantir o pronto

atendimento ao cliente.

CIO Como a segurança não irá

atrapalhar a agilidade dos

sistemas?

Um sistema de change management

implementado e sendo seguido evita

retrabalho das equipes de

desenvolvimento e garante que os

produtos serão entregues dentro das

especificações definidas pelos clientes,

mesmo que não sejam as ideais.

Argumentação Sólida

Nada passa uma fragilidade maior do que quando um executivo de vendas faz uma

apresentação sobre as maravilhas do seu produto e usa como exemplo “uma grande

Organização financeira”, “um player mundial do mercado de bens de consumo”, “100% de

segurança”, “produto à prova de falhas” e essas outras falácias e frases de efeito completamente

vazias de qualquer solidez ou precisão. Se a proposta for apresentada desta forma para uma

pessoa que tem que tomar decisões, certamente ela não levará a sério de forma alguma.

A argumentação no documento deve ser sólida, mostrando que a Política é necessária para a

Organização, agrega valor e faz parte de uma abordagem de senso comum em Melhores

Práticas de Governança Corporativa, algo que todo executivo sabe o que é e busca para sua

gestão. Para isso, primeiro você tem que acreditar no que escreve, pois o conteúdo será falado e

possivelmente terá que ser defendido na frente de muita gente que vai questionar desde a

política de senhas, até a estratégia de continuidade de negócios.

Para acreditar no que escreve, você deve estudar problemas ocorridos em um passado recente,

analisar como a Política poderia ter evitado a ocorrência dos mesmos, ou pelo menos

minimizado o impacto, fazer contas para colocar isso em benefícios tangíveis e intangíveis e

estar preparado para a argumentação. Neste tópico, voltamos ao item anterior, muito cuidado

com a linguagem que será utilizada.

Ao buscar o exemplo de um relatório de Risk Assessment, certamente uma falha no código

de uma aplicação web para transações financeiras que permita um ataque de DDoS é algo

grave, mas que perde completamente o sentido para um executivo se você informar que

esta vulnerabilidade existe e “pode resultar na indisponibilidade do servidor”.

A mesma mensagem pode ser passada informando que a “configuração inadequada da

aplicação” poderá resultar na “indisponibilidade da aplicação, gerando perda diária de

receita entre US$ 1,000 e US$ 12,000 de acordo com o período de ocorrência estimado pelo

Departamento de Contas a Receber”.

Camargo Neves RMS


Existem fontes de informação onde os dados podem ser levantados de forma geral, tais como o

site CSO On Line, o FIRST, e o genuinamente brasileiro CAIS. Todos podem fornecer estatísticas

de ataques, custos médios por setor, probabilidade de ocorrência e diversas outras métricas

úteis, mas nada será tão eficaz quanto dados originados na própria Organização.

Relatórios de auditoria com valores expressos monetariamente, informações sobre multas

regulatórias e legais que podem ser pagas em caso de não cumprimento de metas, e contratos

onde punição por descumprimento de Service Level Agreements (SLA) esteja exposta, são reais

e falam de números que irão efetivamente impactar as pessoas que lerão o documento.

Solidificação da Base Existente

Independente do mercado onde a Organização atua, existem normas e regulamentos que ela

deverá cumprir. Agências como a ANATEL e ANVISA têm web sites excelentes onde farta

documentação está disponível para deixar claro o que as empresas devem cumprir para atuar

de forma adequada junto a sociedade. Uma extensão destas normas pode ser obtida junto a

três áreas que existem na maioria dos lugares; o Departamento Legal, o Departamento Fiscal e a

Área de Compras. Todos podem ser aliados na elaboração do Business Case, fortalecendo a

necessidade da Política para solidificar o cumprimento de normas já existentes.

O Departamento Legal é a escolha mais óbvia, pois ele pode informar quais partes específicas

das Leis devem ser cumpridas pela Organização e de que forma. Existem pontos do Código Civil

que podem ser interpretados como a necessidade de um Plano de Continuidade de Negócios,

como o Artigo 186 que trata de danos a terceiros, mas quem pode falar com propriedade é um

advogado, fale com ele.

O Departamento Fiscal pode também ser um grande aliado em diversos tipos de Instituições,

principalmente aquelas de grande porte onde existe uma fiscalização permanente do Governo

em busca do seu quinhão de impostos. Graças à zona que é o sistema tributário brasileiro, os

Estados possuem datas diferentes para o reporte de determinadas taxas e multas pesadíssimas

em caso de descumprimento. Como esta transmissão de dados é feita por sistemas

computadorizados, esta é a equação que você precisa.

Já a Área de Compras, vai depender muito de como ela funciona na Organização. Mas ela, ou

qualquer outra que seja responsável pela gestão de contratos com clientes, parceiros e

fornecedores, poderá informar quais são os acordos comerciais existentes e que tipos de

obrigações as partes devem cumprir. Itens como manutenção de níveis mínimos de SLA,

qualidade na entrega de serviços ou produtos e níveis máximos de quebra podem ser utilizados

para mensurar perdas com impactos decorrentes de vulnerabilidades em Segurança da

Informação.

Camargo Neves RMS


Iniciando o Business Case

Com a modelagem da linguagem adequada, e o levantamento de informações relevantes com

números estabelecidos, o desenvolvimento do Business Case pode prosseguir sem muitas

interrupções. Apesar de muita gente considerar que somente o conteúdo é que vale, o formato

do documento é extremamente importante e deve ser entendido como parte do esforço de se

criar um Business Case adequado às suas necessidades. Além de não ser grande o suficiente

para assustar o leitor, o documento deve ter uma linguagem clara e apresentar elementos que

facilitem o entendimento e desperte o interesse em uma primeira olhada.

Uma boa forma de conseguir este resultado é iniciar o Business Case com um Sumário Executivo

de uma página, onde os principais itens estejam resumidos e apresentados na já falada

linguagem de negócios. Lembre-se que as pessoas que você quer atingir irão pagar uma conta

que pode ser alta, e certamente questionarão cada detalhe em busca de uma justificativa

plausível para assinar seus nomes na autorização de pagamento e posteriormente no

fechamento do projeto.

Esta parte deve ser escrita por último, e conter um pequeno histórico da necessidade do

projeto, os objetivos, uma lista de produtos que serão entregues, os nomes das áreas usuárias

dos produtos, as datas de início e término e o quanto tudo irá custar. Se for possível colocar

gráficos, tabelas e bullet points ao invés de puro texto, melhor, na minha experiência notei que

este público tem uma predileção incrível por informações o mais sumarizadas possíveis.

Estrutura Mínima

No desenvolvimento do Business Case, existem elementos que compõe uma estrutura mínima

de informações, que pode ser enriquecida com outras seções se for realmente necessário.

Somente como caso ilustrativo, eu nunca passei muito deste conteúdo, exceto quando o cliente

tinha uma necessidade específica que fazia sentido colocar no documento.

Note que o Business Case é um instrumento inicial que apresenta a necessidade do projeto e

explica como ele será desenvolvido e que benefícios serão gerados para a empresa. Após a sua

aprovação, um segundo documento deverá ser desenvolvido com muito mais detalhes; o

Project Initiation Document, deixe o aprofundamento para esta etapa, pois não faz sentido

gastar tempo com um documento deste tipo se a proposta inicial não for aprovada.

Motivadores

Qualquer projeto tem um motivador, o que é óbvio pelo próprio significado da palavra, porém

esta obviedade deve ser escrita de forma exata, pois é muito fácil entrar em dúvida quando

palavras sem sentido são utilizadas. Tenho de novo que fazer referência à linguagem que

permeia documentos corporativos, onde maluquices como “sinergia”, “mudança de paradigma”,

“musculatura necessária” e outros jargões aparecem com frequência. Opte pela simplicidade e

precisão, e use os elementos que você identificou previamente para montar esta seção.

Uma boa forma de apresentar este texto é fazer um ou dois parágrafos introdutórios e depois

apresentar em bullet points os motivadores do projeto, preferencialmente colocando-os da

forma como serão usados para promover melhorias na Organização. Explique quais

necessidades de negócio serão atendidas pelos produtos gerados, e foque sua descrição na

Camargo Neves RMS


linguagem da Organização, sempre. A tabela abaixo mostra alguns exemplos reais que já revisei

e alterei, onde os nomes foram trocados e o conteúdo mantido.

Objetivo Texto Original Texto Corrigido

Atender

regulamentações

do Mercado.

A Empresa XYZ tem a

necessidade de estar alinhada

às necessidades do mercado

para garantir sua

competitividade frente à

concorrência.

A Empresa XYZ tem a obrigação de

garantir a integridade de seus dados

financeiros como parte do alinhamento à

regulamentação SOX, Seção 404. O não

cumprimento desta norma pode impactar

diretamente à capacidade de negociação

de ações na NYSE.

Atender as

necessidades

dos clientes

O incremento de controles nas

transações on line é

fundamental para garantir

100% de segurança aos

clientes.

Manter boas práticas de segurança

suportadas por uma Política é a primeira

etapa para aumentar o nível de confiança

dos clientes no uso de ferramentas para

transações comerciais on-line.

Redução de

custos

Uma política de segurança irá

reduzir o uso inadequado dos

recursos de TI.

O estabelecimento de regras claras de

segurança possibilita que a Empresa XYZ

estabeleça níveis de controle mínimos, e

dimensione as ações administrativas

necessárias para o uso inadequado de

recursos de TI.

Abordagens Existentes

Qualquer apresentação para um grupo de pessoas inteligentes irá resultar em perguntas sobre a

abordagem escolhida, onde serão questionadas outras opções. Isso é normal e saudável, mas

exige que você faça um trabalho prévio de análise e escolha um modelo de trabalho que possa

ser justificado em termos de custo, cronograma, envolvimento das áreas e resultados esperados.

Este é um bom momento para se perguntar sobre como propor a criação da Política. Existem

abordagens comuns em gerenciamento de projetos, e para este caso eu sugiro uma divisão em

etapas lógicas, que podem ser apresentadas na justificativa da abordagem como razão para a

escolha apresentada. Os pontos abaixo relacionados mostram de uma forma geral porque uma

estrutura dividida em fases foi determinada, e quais são as vantagens desta em relação às

demais.

Dimensionamento de Esforço

O esforço necessário para criar uma Política é impossível de ser determinado sem que seja

esclarecida a profundidade que será utilizada (ex. Somente políticas e padrões, ou ir até

documentar procedimentos operacionais?), e em quanto tempo os documentos estabelecidos

no escopo serão desenvolvidos (ex. Como ele será efetivamente aprovado?). Ao estabelecer

fases, é possível dimensionar cada etapa e corrigir os desvios com base em medições reais e

simples.

Camargo Neves RMS


Alteração na Cultura Corporativa

Uma Política muda muito o dia-a-dia de uma Organização, especialmente quando regras que

afetam diretamente as atividades de todo um grupo de pessoas são implementadas (ex.

composição de senhas). Para que isso seja feito de forma eficiente, é fundamental que cada

mudança seja avaliada e colocada em prática junto com uma ação de conscientização e

comunicação maciça. Somente um processo colocado em fases permite que este tipo de

planejamento seja feito.

Adequação do Processo de Conscientização

Tomando como base o motivo anterior, o processo de conscientização varia de acordo com a

cultura corporativa de cada Organização. Eu considero impossível implementar diversas

mudanças na cultura corporativa de uma só vez e esperar que funcione de forma adequada. As

barreiras surgirão e por melhor que seja a campanha utilizada, a antipatia das pessoas pela

iniciativa ficará marcada.

Ir aos poucos, mudando de acordo com a capacidade de absorção da comunidade envolvida é a

melhor opção, pois não requer grandes investimentos e permite transformar pessoas irritadas

em aliados para o processo, pois eles “comprarão” a idéia com mais facilidade se entender

porque isto está sendo feito, sem imposição.

Benefícios Esperados

Devem-se descrever de forma clara quais benefícios serão obtidos com este projeto, dividindo-

os em tangíveis, quando existe uma forma de medir benefícios mensuráveis em valores

monetários, e intangíveis, quando os benefícios forem válidos, mas não for possível expressá-los

em ganhos financeiros. Como em Segurança da Informação a discussão sobre ROI (Return on

Investment – Retorno Sobre Investimento) é longa e dificilmente as pessoas que concordam

com a sua existência tem algum tipo de afinidade no assunto com as que discordam, creio que

vale um pequeno adendo.

Benefícios Tangíveis

Existem diversas formas de analisar benefícios tangíveis em qualquer projeto relacionado à

Segurança da Informação, e eu acho que o ROI não é a melhor delas, pois é questionável,

muitas vezes baseado em premissas e suposições e talvez sirva bem mais para produtos do que

para processos. No caso de um projeto para a criação de uma Política, métricas diversas podem

ser obtidas junto à Organização para mensurar o quanto pode ser atingido em benefícios

mensuráveis:

Racionalização de Processos: Ao estabelecer um padrão, as atividades diferentes que são

desenvolvidas para este mesmo fim tendem a desaparecer e serem consolidadas em uma

única abordagem. O custo de homem-hora que será economizado pode ser calculado e

aplicado a vários pontos na estrutura organizacional que será afetada pela Política.

Custo de Retrabalho: Quando não existe uma padronização, o erro tende a aparecer com

mais frequência e os custos relacionados com a análise da causa e trabalho de correção vem

na mesma onda. Práticas como Change Management e Business Continuity são bem

Camargo Neves RMS


aplicáveis para dimensionar o quanto a Organização irá deixar de perder com estes custos

quando a processos estruturados são estabelecidos.

Perdas com Falhas na Segurança: Este ponto é um pouco mais delicado, mas se bem

trabalhado junto às áreas responsáveis por respostas a incidentes, pode mensurar o quanto

a Organização já perdeu com contaminações de vírus, destruição indevida de arquivos.

Pense no seguinte, um benefício mensurável não precisa ser quantificado em quanto a empresa

vai ganhar com determinado produto ou processo, mas também em quanto ela vai parar de

perder em números absolutos ou percentuais, desde que sejam factíveis e capazes de serem

provados.

Benefícios Intangíveis

No caso deste tipo de projeto, pode-se novamente buscar a ajuda de algumas áreas dentro da

Organização, como eu citei no artigo anterior desta série. O alinhamento às regulamentações

presentes no mercado relacionado é um bom exemplo, e apesar de não ser possível mensurar

com precisão mínima o valor de multas aplicadas – pois as mesmas dependem de julgamentos,

processos administrativos e outros itens que orbitam a Organização – é possível falar sobre

impacto na imagem, queda de ações e perda de mercado. Alguns exemplos da vida real podem

ilustrar este ponto com mais facilidade:

Imagem Empresarial: A falta de um plano de resposta a emergência adequado está

tornando o acidente da TAM ocorrido em julho no Aeroporto de Congonhas mais um

exemplo de como não se trata uma crise. Independente do que a empresa tenha feito pelos

familiares, a imprensa ficou às escuras por muito tempo e noticiou que nenhuma

informação era passada, e foi isso que o público sentiu e o que mais uma vez arranhou a

imagem da empresa. Faltou um elemento essencial ao Business Continuity, o Plano de

Comunicação.

Perda de Mercado: Os exemplos mais recentes e populares estão disponíveis a um clique

no Google. Empresas gigantescas como a Enron, AOL, Tyco International e mais

recentemente a Parmalat, caíram em desgraça pública e tiveram suas ações derrubadas – ou

mesmo quebraram – após protagonizarem diversos escândalos corporativos baseados em

uma contabilidade irreal que poderia ter sido evitada com um sistema de Governança

adequado, que sempre é suportado por uma Política.

Multas: A Resolução 3380 do Conselho Monetário Nacional exige que as instituições

financeiras em operação no País apresentem, até dezembro de 2007, seus planos de gestão

de riscos. Se a Resolução for lida criteriosamente, podemos assumir que não se fala só de

Business Continuity (Art. 2º Para os efeitos desta resolução, define-se como risco

operacional a possibilidade de ocorrência de perdas resultantes de falha, deficiência ou

inadequação de processos internos, pessoas e sistemas, ou de eventos externos.) mas de

controles presentes em uma Política mesmo (O § 2º cita nominalmente fraudes internas e

externas, aqueles que acarretem a interrupção das atividades da instituição, falhas em

sistemas de tecnologia da informação e falhas na execução, cumprimento de prazos e

gerenciamento das atividades na instituição).

Camargo Neves RMS


Em resumo, o benefício intangível é o quanto a Organização pode ganhar em termos não-

monetários ou de forma monetária, mas não mensurável. Procure mais uma vez fugir de

generalismos e escrever com base em dados que façam sentido para os executivos que irão ler

o Business Case.

Riscos

Nesta Seção falamos dos riscos para o Projeto, que podem ser divididos em diversas categorias

de acordo com cada Organização. Basicamente existem cinco classificações que podem

compreender as demais e um bom trabalho de análise prévia com especialistas de áreas

relacionadas dentro da Organização pode render uma lista factível e aceitável para os leitores

do Business Case. A lista abaixo relacionada não é exaustiva, mas pode ser usada como

referência e está suportada por alguns exemplos que já vivi.

Custos: Qualquer projeto deve ter um orçamento próprio que é controlado pelo Gerente do

Projeto, mas como este valor não é “entregue” e sim custeado, pode ocorrer um

redirecionamento de recursos ao longo do tempo em que o projeto é conduzido,

resultando no aumento de tempo para entrega dos produtos ou mesmo cancelamento da

iniciativa.

Cronograma: A definição inicial, discussão, ajuste e aceite de um cronograma é lugar

comum em qualquer projeto, mas como no desenvolvimento de uma Política isso envolve

outros membros da Organização que não a equipe fixa do projeto, o não cumprimento das

atividades planejadas ou o estouro dos prazos pelos componentes eventuais (ex. um

representante da Área Legal) podem ocorrer com maior frequência.

Técnicos: Riscos técnicos são simples de mensurar em um projeto que envolva produtos e

tecnologias, mas para uma Política eu não acho que este item possa ser plenamente

aplicado. Não existe muita coisa a se falar, mas recursos técnicos mínimos (ex. um servidor

de arquivos para os documentos) devem ser garantidos para que o desenvolvimento das

atividades corra sem impactos relevantes.

Operacionais: Apesar de similar ao risco apresentado ao cronograma, difere-se pela causa

dos problemas. Enquanto o primeiro está baseado no não-cumprimento de prazos, este se

relaciona a falhas na operação das atividades que impactem os resultados. Um exemplo

comum é quando as pessoas indicadas para determinadas atividades não entendem o que

está sendo requisitado, não falam e entregam o produto errado. É uma responsabilidade do

Gerente do Projeto trabalhar de forma constante para deixar as mensagens claras e garantir

que todos estão indo na mesma linha de entendimento em busca do objetivo final.

Organizacionais: É um risco incomum, mas que ocorre quando se menos espera. Mudanças

na estrutura da Organização durante o desenvolvimento das atividades, ou troca de

membros da equipe podem afetar o Projeto em termos de cronograma, e qualidade dos

produtos finais caso as pessoas em questão sejam cruciais para contribuir com

entendimento específico sobre determinado item (ex. Área Fiscal).

Camargo Neves RMS


O Cronograma

Entendendo que o Business Case é um documento direcionado para esclarecer como o Projeto

será desenvolvido e se ele será aprovado ou não, o cronograma deve ser criado dimensionando

o esforço necessário para as atividades e não as datas efetivas. Estas serão discutidas caso o

documento seja aprovado, acordadas e documentadas no Project Initiation Document. A tabela

abaixo apresenta um modelo de apresentação do cronograma nesta fase com os esforços

requeridos, e algo neste sentido deve ser criado após um entendimento mínimo da cultura

corporativa com os representantes da Organização.

Atividade Semanas

1 2 3 4 5 6 7 8

1. Reunião de entendimento do projeto

2. Treinamento básico em Conceitos de Políticas de Segurança

3. Elaboração de Políticas Gerais

4. Elaboração de Políticas Específicas

5. Elaboração dos Padrões de Segurança

6. Desenvolvimento dos processos de implementação

7. Implementação Piloto (Área A)

8. Avaliação preliminar de resultados

9. Implementação da Política de Segurança

10. Reunião de Conclusão e fechamento do Projeto

Investimentos Relacionados

Os valores necessários para as atividades do Projeto devem ser apresentados de acordo com as

definições de cada Organização, cabendo ao Business Case apresentar como estes valores serão

desembolsados. Mais uma vez cabe uma análise prévia junto às áreas da Organização para

identificar qual investimento será necessário para o projeto e quando a manutenção futura

poderá custar, de acordo com as atividades de revisão e atualização planejadas. Custos com

processos anuais de revisão dos documentos, auditorias de qualidade, campanhas de

conscientização e similares, devem ser apresentados ao menos como estimativa e fazer parte

dos valores de investimento mostrados.

Um cuidado que deve ser tomado nesta Seção, é dividir de forma clara os custos do projeto e

os valores futuros, possibilitando que os leitores e aprovadores do Business Case tenham uma

noção exata de quanto terão que desembolsar para o projeto e para a manutenção da Política,

não deixando a iniciativa ser algo temporal que “morre” por falta de revisões, algo que já vi

acontecer em muitas empresas de pequeno, médio e grande porte.

Outro item que vale ficar atento e nunca subestimar os custos visando a aprovação do projeto.

Exemplos públicos do chamado cost overrun aparecem no desenvolvimento de grandes

produtos (ex. Concorde e Airbus A380) e principalmente em obras grandiosas como o Canal do

Panamá e mais recentemente a preparação para os Jogos Pan Americanos no Rio de Janeiro.

Não se engane, isso acontece com frequência em pequenas iniciativas, não caia neste erro que

Camargo Neves RMS


pode desacreditar a competência do Gerente de Projeto, talvez até impossibilitando que um

excelente projeto vá para a frente por falta de confiança dos patrocinadores.

Conclusão

O Business Case é só um documento, lembre disso. Muitos profissionais no mercado de

Segurança da Informação tem dificuldade ou simplesmente não gostam de escrever

documentos, preferindo concentrar seus esforços em atividades de campo ou na área técnica.

Se ajuda, este documento pode não só permitir que um projeto vá para a frente, mas também

evita que ele fuja do escopo planejado e se transforme em um monstro que você mesmo terá

que vencer sem ganhar mais nada por isso além de cabelos brancos.

Sobre o Autor

Eduardo V. C. Neves, CISSP, trabalha com Segurança da Informação desde 1998. Iniciou sua

carreira profissional em uma das principais empresas de consultoria do mercado brasileiro,

posteriormente trabalhando como executivo de uma empresa Fortune 100 por quase 10 anos.

Em 2008 fundou uma das primeiras empresas nacionais especializada em Segurança de

Aplicações e hoje se dedica a prestar serviços de consultoria nas práticas de Risk Management e

Business Continuity. Serve ainda como voluntário no OWASP e (ISC)2 e contribui para iniciativas

de evangelização nas práticas de proteção da informação para federações e associações no

Brasil. Pode ser contatado pelo e-mail [email protected].

mailto:[email protected]