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

2.626 visualizações

Publicada em

Publicada em: Negócios
0 comentários
0 gostaram
Estatísticas
Notas
  • Seja o primeiro a comentar

  • Seja a primeira pessoa a gostar disto

Sem downloads
Visualizações
Visualizações totais
2.626
No SlideShare
0
A partir de incorporações
0
Número de incorporações
1
Ações
Compartilhamentos
0
Downloads
61
Comentários
0
Gostaram
0
Incorporações 0
Nenhuma incorporação

Nenhuma nota no slide

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

  1. 1. Fundamentos para uma Política de Segurança da InformaçãoO uso de conceitos básicos de Project Management para criar documentos efetivosEduardo Vianna de Camargo Neveseduardo@camargoneves.comIntroduçãoA primeira Política de Segurança da Informação que escrevi, foi para um banco estatal lá pelosidos de 1998, e confesso que apesar do resultado final ter deixado o cliente satisfeito, odesenvolvimento foi um verdadeiro desastre. A instituição não tinha nenhuma política nem idéiade como fazê-la, e coube a minha equipe partir do zero com base nos resultados de umaanálise de risco prévia para dar conta da tarefa em três meses. O comitê para a elaboração foimontado, e um grupo que começou com três representantes do cliente, terminou com dozepessoas que não conseguiam se entender e tentavam a cada reunião criar documentos quefossem satisfatórios às necessidades deles, e não do banco.Essa experiência e outras que aconteceram nos últimos anos me ajudaram a entender algunsconceitos básicos para o desenvolvimento de uma Política, e nenhum deles está escrito empadrões de segurança ou apresentado em técnicas que podem ser ensinadas em um curso. Elestêm a ver com um elemento que é cada vez mais importante para o profissional de Segurançada Informação entender, estudar e inserir no seu kit de ferramentas de trabalho: usabilidade, ouseja, ter a capacidade de produzir uma ferramenta que atenda às necessidades de umainstituição e ao mesmo tempo seja simples de ser usada pela comunidade a qual é destinada. Areceita para isso é mais simples do que parece, mas tenho a impressão que a maioria dasinstituiçõ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 demodelos disponíveis na Internet e as pessoas que as implementam ainda tem alguma esperançade que vão funcionar. Existem algumas etapas que devem ser seguidas sempre que fornecessário criar uma política de segurança e erros que podem ser evitados. Estruturar odesenvolvimento como um projeto formal no mínimo reduz a probabilidade de ocorrência deboa 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 paraGerenciamento de Projetos; um documento de planejamento de atividades que serve como“contrato” entre as partes envolvidas, e permite o acompanhamento do alcance dos objetivosao longo do tempo, controle de desvios potenciais e manutenção das premissas que foramestabelecidas 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.
  2. 2. Camargo Neves RMSConceituando o ProjetoA primeira fase na criação de uma Política é definir qual é o escopo que será utilizado o queparece óbvio, porém é um conceito que pode ser alterado durante o desenvolvimento dasatividades 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, oque na maioria das vezes não é o mesmo da Instituição como um todo. Além disso, ainda existeo 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 oscomponentes da equipe, tarefas que devem ser definidas, metas a serem atingidas, tempo paracumprimento 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 podemnão terminar como planejado.Falta de Envolvimento dos Clientes InternosQuando não existe o envolvimento dos clientes internos, dois fenômenos ocorrem; as pessoasque irão usar o produto não se sentem satisfeitas com os resultados porque não sabem do quese trata e sentem uma imposição corporativa, e os membros do projeto definem os resultadosconforme o seu próprio julgamento, que dificilmente tem o mesmo ponto de vista de umcliente 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 domaterial, como ainda contribuem identificando possíveis pontos de resistência e ajudando nacriaçã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 CronogramaEstabelecer 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ãodesenvolvidas passa por transformações, que são cada vez mais rápidas e abrangentes. Umarecomendação comum aos projetos de grande porte onde o cronograma não pode serreduzido é dividir as etapas em projetos menores.Aplicando este conceito ao desenvolvimento da Política, é possível definir uma série deatividades que sejam divididas em projetos contínuos, mas onde existam cronogramas,orçamentos, equipes e outros componentes distintos de acordo com cada caso. Umarecomendação é dividir em, ao menos, quatro projetos; a definição do padrão que será utilizadocomo base, o desenvolvimento das políticas, a ampliação das normas estabelecidas para ospadrões, a criação dos guias e finalmente a escrita e implementação dos procedimentos.Fundamentos para uma Política de Segurança da Informação Página 2
  3. 3. Camargo Neves RMSRequerimentos Inadequados ou InexistentesÉ incrível, mas isso acontece com mais frequência do que deveria. Muitos dos problemasrelacionados aos requerimentos voltam ao primeiro item citado, falta de envolvimento daspessoas no projeto, mas um componente ainda mais escondido pode ser citado:desconhecimento em reconhecer a própria ignorância. Apesar de parecer uma afirmaçãopolêmica, ela é uma constatação em cima de um fato comum no mercado de hoje; muitosprofissionais acham que entendem profundamente Segurança da Informação ou ao menosquerem que a comunidade pense assim. Para criar e desenvolver uma iniciativa focada naelaboração de uma Política é necessário que o gerente do projeto entenda de políticas eprocedimentos e busque o apoio de profissionais com especialização em todos os campos queserão abordados; segurança de aplicações, planos de contingência, segurança física e outrasdisciplinas envolvidas.Escopo InadequadoO escopo é uma definição clara de como o projeto irá funcionar e o que ele irá abordar. O quepode 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 oescopo de um projeto durante o seu desenvolvimento, mas isso deve ser adequadamenteregistrado e mensurado – vide próximo item – além de obrigatoriamente ter que estarrelacionado com o escopo original.Um exemplo que já testemunhei, foi um projeto de atualização de uma Política quase tornar-seuma revisão de processos, uma vez que uma das áreas queria “aproveitar” os consultores paraavaliar toda a sua documentação – relacionada ou não à Segurança da Informação – e gerar umplano de ação de melhorias. Neste caso, o que recomendei e foi aceito pelo cliente na época, foicontinuar 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 onosso escopo original.Inexistência de Controle de MudançasComo 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 olevantamento de requerimentos. Mas quando isso ocorrer, a possibilidade de mudança deve serregistrada, o esforço mensurado, o cronograma ajustado e tudo aprovado pelos patrocinadoresantes 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 formasubestimada, onde novos itens são incluídos no escopo e o gerente do projeto acha que otrabalho 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 aatividade e obter a aprovação de quem paga a conta. Ao final, ele talvez não aprove a alteraçãosabendo o quanto isso pode custar.Fundamentos para uma Política de Segurança da Informação Página 3
  4. 4. Camargo Neves RMSA Adoção de um Business CaseUma dificuldade que muitas pessoas que trabalham com Segurança da Informaçãocompartilham, é o problema em escrever um documento que tenha como público umaaudiê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 partedo jargão utilizado. Infelizmente as pessoas que recebem e usam os nossos produtos, assimcomo as que aprovam as verbas para que eles sejam desenvolvidos, estão em outro mundo eusam 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 facilidadesdispostas em um processo de gerenciamento de projeto, ela deve ser tratada como tal, e aprimeira etapa é escrever um documento que deixe muito claro para este outro público o queserá construído com o dinheiro que eles irão aprovar e como os resultados poderão trazerbenefícios que interessam à Organização. Este documento simples e ao mesmo tempocompleto é o Business Case.Posicionado como uma ferramenta para definir os conceitos gerais de um projeto e apresentaras justificativas que mostrem porque a atividade deve ser executada como melhoria para osnegócios de uma Organização, o Business Case pode ser definido como um contrato entre aequipe 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 CaseUm documento voltado para qualquer atividade ligada à Segurança da Informação deve buscarlevar a linguagem deste mercado para o elemento onde as pessoas que irão ler as informaçõese aprovar o projeto costumam viver suas rotinas; normalmente um ambiente de negócios ondeclientes, 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 basicamentetrês pontos nos quais a produção do documento e todo o discurso referente devem serguiados: 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 estimadaFundamentos para uma Política de Segurança da Informação Página 4
  5. 5. 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 elógica. O Business Case adere a isto e permite colocar em pouco mais de dez páginas todas asinformações necessárias para documentar o processo de desenvolvimento de uma Política ejustificar de forma adequada o investimento financeiro e alocação de recursos para suportar asatividades.Aprofundando os Três PontosEm qualquer projeto bem sucedido, a montagem do time que irá desenvolver todas asatividades é 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 daOrganização. A primeira recomendação é colocar na equipe os profissionais das principais áreasque 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 destedocumento, que devem ser aplicados como base para construção do Business Case para oprojeto de Política, e que certamente pode ajudar a elaboração de documentos similares paraqualquer iniciativa relacionada à Segurança da Informação.Fundamentos para uma Política de Segurança da Informação Página 5
  6. 6. Camargo Neves RMSMensagem AdequadaPolíticos profissionais são mestres em adequar a mensagem à audiência desejada. Umaestratégia famosa ocorreu durante a campanha presidencial de 1960 nos EUA, onde JohnKennedy concorreu com Richard Nixon e ganhou. Apesar de todos os demais elementos quecercam uma campanha deste porte, Kennedy foi aos poucos passando a sua mensagem daforma que os eleitores queriam ouvir, culminando no primeiro debate na televisão, onde estaestraté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ãoquis 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 porbaixo do terno. Reza a lenda que vendo a camisa azul de Nixon, os assessores democratasdesligaram o ar-condicionado do estúdio, acrescentando aos problemas de Nixon um suadouroincessante que marcou sua camisa e rosto, e o fez parecer extremamente nervoso para os 80milhões de espectadores.Guardadas as devidas proporções, é exatamente isso que deve ser pensando ao elaborar oBusiness Case; como a mensagem será passada para uma audiência que deverá ver não umdocumento 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 aOrganização trabalhe de forma segura.Para que isso seja possível, palavras como “provável”, “estimado” e outras que remetem a umaprobabilidade que pode nunca se tornar um fato, devem ser evitadas. Use verbos e frases quemostrem certeza no discurso e seja claro, objetivo e pragmático. A tabela apresentada abaixoadaptada de um documento publicado pela TruSecure em 2004, onde acrescentei algunselementos que ajudam a mostrar essas diferenças. Use-a como base para identificar alinguagem 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  Aderência a regulamentações exigidas agregar valor à pelo mercado (ex. SOX). Organização?  Alinhamento com as necessidades dos  Como os acionistas irão clientes (ex. e-commerce). perceber isto?  Satisfação dos acionistas (ex. incremento de segurança das informações financeiras). CFO  Em quanto o custo  A garantia de continuidade de operacional pode ser processos pode gerar redução dos reduzido? custos com seguros e sistemas  Como a produtividade das redundantes. (ex. Business Continuity) áreas pode aumentar?  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)Fundamentos para uma Política de Segurança da Informação Página 6
  7. 7. Camargo Neves RMS Audiência Necessidade Exemplos Diretor de  Como as vendas podem  A integridade de uma base de dados é ser melhoradas? fundamental para garantir o Vendas  Como a satisfação do funcionamento adequado de um CRM. cliente pode ser mantida?  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á  Um sistema de change management atrapalhar a agilidade dos implementado e sendo seguido evita sistemas? 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ólidaNada passa uma fragilidade maior do que quando um executivo de vendas faz umaapresentação sobre as maravilhas do seu produto e usa como exemplo “uma grandeOrganização financeira”, “um player mundial do mercado de bens de consumo”, “100% desegurança”, “produto à prova de falhas” e essas outras falácias e frases de efeito completamentevazias de qualquer solidez ou precisão. Se a proposta for apresentada desta forma para umapessoa 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 aOrganização, agrega valor e faz parte de uma abordagem de senso comum em MelhoresPráticas de Governança Corporativa, algo que todo executivo sabe o que é e busca para suagestão. Para isso, primeiro você tem que acreditar no que escreve, pois o conteúdo será falado epossivelmente terá que ser defendido na frente de muita gente que vai questionar desde apolí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 menosminimizado o impacto, fazer contas para colocar isso em benefícios tangíveis e intangíveis eestar preparado para a argumentação. Neste tópico, voltamos ao item anterior, muito cuidadocom 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”.Fundamentos para uma Política de Segurança da Informação Página 7
  8. 8. Camargo Neves RMSExistem fontes de informação onde os dados podem ser levantados de forma geral, tais como osite CSO On Line, o FIRST, e o genuinamente brasileiro CAIS. Todos podem fornecer estatísticasde 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 multasregulatórias e legais que podem ser pagas em caso de não cumprimento de metas, e contratosonde punição por descumprimento de Service Level Agreements (SLA) esteja exposta, são reaise falam de números que irão efetivamente impactar as pessoas que lerão o documento.Solidificação da Base ExistenteIndependente do mercado onde a Organização atua, existem normas e regulamentos que eladeverá cumprir. Agências como a ANATEL e ANVISA têm web sites excelentes onde fartadocumentação está disponível para deixar claro o que as empresas devem cumprir para atuarde forma adequada junto a sociedade. Uma extensão destas normas pode ser obtida junto atrê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 anecessidade 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íficasdas Leis devem ser cumpridas pela Organização e de que forma. Existem pontos do Código Civilque 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 é umadvogado, 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 Governoem busca do seu quinhão de impostos. Graças à zona que é o sistema tributário brasileiro, osEstados possuem datas diferentes para o reporte de determinadas taxas e multas pesadíssimasem caso de descumprimento. Como esta transmissão de dados é feita por sistemascomputadorizados, esta é a equação que você precisa.Já a Área de Compras, vai depender muito de como ela funciona na Organização. Mas ela, ouqualquer outra que seja responsável pela gestão de contratos com clientes, parceiros efornecedores, poderá informar quais são os acordos comerciais existentes e que tipos deobrigaçõ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 utilizadospara mensurar perdas com impactos decorrentes de vulnerabilidades em Segurança daInformação.Fundamentos para uma Política de Segurança da Informação Página 8
  9. 9. Camargo Neves RMSIniciando o Business CaseCom a modelagem da linguagem adequada, e o levantamento de informações relevantes comnúmeros estabelecidos, o desenvolvimento do Business Case pode prosseguir sem muitasinterrupções. Apesar de muita gente considerar que somente o conteúdo é que vale, o formatodo documento é extremamente importante e deve ser entendido como parte do esforço de secriar um Business Case adequado às suas necessidades. Além de não ser grande o suficientepara assustar o leitor, o documento deve ter uma linguagem clara e apresentar elementos quefacilitem 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 Executivode uma página, onde os principais itens estejam resumidos e apresentados na já faladalinguagem de negócios. Lembre-se que as pessoas que você quer atingir irão pagar uma contaque pode ser alta, e certamente questionarão cada detalhe em busca de uma justificativaplausível para assinar seus nomes na autorização de pagamento e posteriormente nofechamento do projeto.Esta parte deve ser escrita por último, e conter um pequeno histórico da necessidade doprojeto, os objetivos, uma lista de produtos que serão entregues, os nomes das áreas usuáriasdos produtos, as datas de início e término e o quanto tudo irá custar. Se for possível colocargráficos, tabelas e bullet points ao invés de puro texto, melhor, na minha experiência notei queeste público tem uma predileção incrível por informações o mais sumarizadas possíveis.Estrutura MínimaNo desenvolvimento do Business Case, existem elementos que compõe uma estrutura mínimade 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 clientetinha uma necessidade específica que fazia sentido colocar no documento.Note que o Business Case é um instrumento inicial que apresenta a necessidade do projeto eexplica como ele será desenvolvido e que benefícios serão gerados para a empresa. Após a suaaprovação, um segundo documento deverá ser desenvolvido com muito mais detalhes; oProject Initiation Document, deixe o aprofundamento para esta etapa, pois não faz sentidogastar tempo com um documento deste tipo se a proposta inicial não for aprovada.MotivadoresQualquer projeto tem um motivador, o que é óbvio pelo próprio significado da palavra, porémesta obviedade deve ser escrita de forma exata, pois é muito fácil entrar em dúvida quandopalavras sem sentido são utilizadas. Tenho de novo que fazer referência à linguagem quepermeia documentos corporativos, onde maluquices como “sinergia”, “mudança de paradigma”,“musculatura necessária” e outros jargões aparecem com frequência. Opte pela simplicidade eprecisã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 depoisapresentar em bullet points os motivadores do projeto, preferencialmente colocando-os daforma como serão usados para promover melhorias na Organização. Explique quaisnecessidades de negócio serão atendidas pelos produtos gerados, e foque sua descrição naFundamentos para uma Política de Segurança da Informação Página 9
  10. 10. Camargo Neves RMSlinguagem da Organização, sempre. A tabela abaixo mostra alguns exemplos reais que já reviseie alterei, onde os nomes foram trocados e o conteúdo mantido. Objetivo Texto Original Texto Corrigido Atender A Empresa XYZ tem a A Empresa XYZ tem a obrigação de regulamentações necessidade de estar alinhada garantir a integridade de seus dados do Mercado. às necessidades do mercado financeiros como parte do alinhamento à para garantir sua regulamentação SOX, Seção 404. O não competitividade frente à cumprimento desta norma pode impactar concorrência. diretamente à capacidade de negociação de ações na NYSE. Atender as O incremento de controles nas Manter boas práticas de segurança necessidades transações on line é suportadas por uma Política é a primeira dos clientes fundamental para garantir etapa para aumentar o nível de confiança 100% de segurança aos dos clientes no uso de ferramentas para clientes. transações comerciais on-line. Redução de Uma política de segurança irá O estabelecimento de regras claras de custos reduzir o uso inadequado dos segurança possibilita que a Empresa XYZ recursos de TI. 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 ExistentesQualquer apresentação para um grupo de pessoas inteligentes irá resultar em perguntas sobre aabordagem escolhida, onde serão questionadas outras opções. Isso é normal e saudável, masexige que você faça um trabalho prévio de análise e escolha um modelo de trabalho que possaser 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. Existemabordagens comuns em gerenciamento de projetos, e para este caso eu sugiro uma divisão emetapas lógicas, que podem ser apresentadas na justificativa da abordagem como razão para aescolha apresentada. Os pontos abaixo relacionados mostram de uma forma geral porque umaestrutura dividida em fases foi determinada, e quais são as vantagens desta em relação àsdemais.Dimensionamento de EsforçoO esforço necessário para criar uma Política é impossível de ser determinado sem que sejaesclarecida a profundidade que será utilizada (ex. Somente políticas e padrões, ou ir atédocumentar procedimentos operacionais?), e em quanto tempo os documentos estabelecidosno escopo serão desenvolvidos (ex. Como ele será efetivamente aprovado?). Ao estabelecerfases, é possível dimensionar cada etapa e corrigir os desvios com base em medições reais esimples.Fundamentos para uma Política de Segurança da Informação Página 10
  11. 11. Camargo Neves RMSAlteração na Cultura CorporativaUma Política muda muito o dia-a-dia de uma Organização, especialmente quando regras queafetam 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 cadamudança seja avaliada e colocada em prática junto com uma ação de conscientização ecomunicação maciça. Somente um processo colocado em fases permite que este tipo deplanejamento seja feito.Adequação do Processo de ConscientizaçãoTomando como base o motivo anterior, o processo de conscientização varia de acordo com acultura corporativa de cada Organização. Eu considero impossível implementar diversasmudanças na cultura corporativa de uma só vez e esperar que funcione de forma adequada. Asbarreiras surgirão e por melhor que seja a campanha utilizada, a antipatia das pessoas pelainiciativa ficará marcada.Ir aos poucos, mudando de acordo com a capacidade de absorção da comunidade envolvida é amelhor opção, pois não requer grandes investimentos e permite transformar pessoas irritadasem aliados para o processo, pois eles “comprarão” a idéia com mais facilidade se entenderporque isto está sendo feito, sem imposição.Benefícios EsperadosDevem-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 valoresmonetários, e intangíveis, quando os benefícios forem válidos, mas não for possível expressá-losem ganhos financeiros. Como em Segurança da Informação a discussão sobre ROI (Return onInvestment – Retorno Sobre Investimento) é longa e dificilmente as pessoas que concordamcom a sua existência tem algum tipo de afinidade no assunto com as que discordam, creio quevale um pequeno adendo.Benefícios TangíveisExistem 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 quepara processos. No caso de um projeto para a criação de uma Política, métricas diversas podemser obtidas junto à Organização para mensurar o quanto pode ser atingido em benefíciosmensurá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 bemFundamentos para uma Política de Segurança da Informação Página 11
  12. 12. 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 empresavai ganhar com determinado produto ou processo, mas também em quanto ela vai parar deperder em números absolutos ou percentuais, desde que sejam factíveis e capazes de seremprovados.Benefícios IntangíveisNo caso deste tipo de projeto, pode-se novamente buscar a ajuda de algumas áreas dentro daOrganização, como eu citei no artigo anterior desta série. O alinhamento às regulamentaçõespresentes no mercado relacionado é um bom exemplo, e apesar de não ser possível mensurarcom 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 sobreimpacto na imagem, queda de ações e perda de mercado. Alguns exemplos da vida real podemilustrar 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).Fundamentos para uma Política de Segurança da Informação Página 12
  13. 13. Camargo Neves RMSEm 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 degeneralismos e escrever com base em dados que façam sentido para os executivos que irão lero Business Case.RiscosNesta Seção falamos dos riscos para o Projeto, que podem ser divididos em diversas categoriasde acordo com cada Organização. Basicamente existem cinco classificações que podemcompreender as demais e um bom trabalho de análise prévia com especialistas de áreasrelacionadas dentro da Organização pode render uma lista factível e aceitável para os leitoresdo Business Case. A lista abaixo relacionada não é exaustiva, mas pode ser usada comoreferê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).Fundamentos para uma Política de Segurança da Informação Página 13
  14. 14. Camargo Neves RMSO CronogramaEntendendo que o Business Case é um documento direcionado para esclarecer como o Projetoserá desenvolvido e se ele será aprovado ou não, o cronograma deve ser criado dimensionandoo esforço necessário para as atividades e não as datas efetivas. Estas serão discutidas caso odocumento seja aprovado, acordadas e documentadas no Project Initiation Document. A tabelaabaixo apresenta um modelo de apresentação do cronograma nesta fase com os esforçosrequeridos, e algo neste sentido deve ser criado após um entendimento mínimo da culturacorporativa com os representantes da Organização. Semanas Atividade 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 ProjetoInvestimentos RelacionadosOs valores necessários para as atividades do Projeto devem ser apresentados de acordo com asdefinições de cada Organização, cabendo ao Business Case apresentar como estes valores serãodesembolsados. Mais uma vez cabe uma análise prévia junto às áreas da Organização paraidentificar qual investimento será necessário para o projeto e quando a manutenção futurapoderá custar, de acordo com as atividades de revisão e atualização planejadas. Custos comprocessos anuais de revisão dos documentos, auditorias de qualidade, campanhas deconscientização e similares, devem ser apresentados ao menos como estimativa e fazer partedos valores de investimento mostrados.Um cuidado que deve ser tomado nesta Seção, é dividir de forma clara os custos do projeto eos valores futuros, possibilitando que os leitores e aprovadores do Business Case tenham umanoçã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á viacontecer 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 grandesprodutos (ex. Concorde e Airbus A380) e principalmente em obras grandiosas como o Canal doPanamá 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 queFundamentos para uma Política de Segurança da Informação Página 14
  15. 15. Camargo Neves RMSpode desacreditar a competência do Gerente de Projeto, talvez até impossibilitando que umexcelente projeto vá para a frente por falta de confiança dos patrocinadores.ConclusãoO Business Case é só um documento, lembre disso. Muitos profissionais no mercado deSegurança da Informação tem dificuldade ou simplesmente não gostam de escreverdocumentos, 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émevita 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 AutorEduardo V. C. Neves, CISSP, trabalha com Segurança da Informação desde 1998. Iniciou suacarreira 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 deAplicações e hoje se dedica a prestar serviços de consultoria nas práticas de Risk Management eBusiness Continuity. Serve ainda como voluntário no OWASP e (ISC)2 e contribui para iniciativasde evangelização nas práticas de proteção da informação para federações e associações noBrasil. Pode ser contatado pelo e-mail eduardo@camargoneves.com.Fundamentos para uma Política de Segurança da Informação Página 15

×