O que é a tão cobrada Transparência?

Princípios básicos da Governança Corporativa

De acordo com o código de melhores práticas de governança do IBGC, a Governança Corporativa possui quatro princípios de sustentação: a Equidade, a Prestação de Contas, a Responsabilidade Corporativa e a tão falada Transparência. Todos estes princípios serão devidamente apresentados neste post...

Equidade - Fairness

É tratar igualmente os diferentes sócios da instituição e, também, todas as partes interessadas.

Assim, a equidade se refere ao tratamento de forma igualitária aos investidores, o board, os funcionários e qualquer outra parte interessada da instituição, isto é, sem haver concessão de privilégios sob qualquer forma!

Prestação de Contas - Accountability

É a prestação de contas de forma responsável, baseado em práticas de auditoria/contábeis objetivando a prevenção de operações ilícitas ou de conflitos de interesses, reforçando o cumprimento das regulamentações.

Este pilar trata dos esclarecimentos das informações, consolidadas e/ou detalhadas, disponibilizadas aos interessados, produzidas de forma imparcial e com qualidade e veracidade, assim, os responsáveis pelas ações devem prestar contas a todos os interessados e assumir as consequências tanto de seus atos quanto de suas omissões.

Responsabilidade Corporativa - Compliance

É a visão de longo prazo, com considerações de ordem social e ambiental.

Os responsáveis pela governança na instituição devem levar em consideração políticas sociais e ambientais em suas operações, visando sua sustentabilidade e longevidade, pois a instituição também possui um papel social na comunidade de atuação.

Transparência - Disclosure

A transparência está muito além da mera obrigação de informar, é a intenção de gerar credibilidade (interna/externa à instituição) através da publicação de informações verdadeiras, incluindo neste rol as informações que possam trazer impacto negativo ao negócio.

Este pilar trata da divulgação (emissão e a revelação responsável) de informações sem favorecimentos ou privilégios a qualquer stakeholder, independente de os investidores serem externos ou internos.

Como podemos ver, não basta apenas a instituição dizer possuir a tão falada Governança Corporativa, deve haver uma administração transparente e legal, deve ser visada a assertividade na prestação de contas e não se pode esquecer que além de acionistas, ainda existem outros interessados tão (ou mais) importantes: o meio social e ambiental e os stakeholders diversos.

Neste mercado nocivo e ganancioso, dentre os muitos exemplos negativos de Governança Corporativa, podemos citar a falta de equidade e transparência do mega empresário, Eike Batista, praticando o insider trading no seu conglomerado X e realizando a venda de suas ações imediatamente antes de sua derrocada. A falta de transparência, de prestação de contas e de responsabilidade corporativa na aquisição da refinaria de Pasadena pela Petrobrás e por aí vai... Resultado disto: falências, instabilidade no mercado financeiro, perda de bens privados, devassa fiscal, enxurrada de processos, desempregos, obras paradas, estagnação do crescimento, ônus ao sistema jurídico, prisões, descrença internacional, mais ônus aos contribuintes, etc.

Assim sendo, segue um resumo dos princípios básicos da governança corporativa:

Atuar de forma lícita, clara, ética e moral, tendo a certeza de suas responsabilidades por atos e omissões, visando, além dos interesses de sua instituição, o de terceiros e da sociedade que a cerca.

REFERÊNCIAS

Código das Melhores Práticas de Governança Corporativa - IBGC

Governança na OGX

Governança na Petrobrás

Abraços!

Gestão da Continuidade de Negócios - 3/3

Hoje será finalizada a sequência sobre GCN. Serão apresentados o Plano de Recuperação de Desastres, o Plano de Continuidade Operacional e a capacitação dos envolvidos. Ao final serão disponibilizados alguns documentos de apoio.

O Plano de Recuperação de Desastres

Este plano objetiva definir os procedimentos de restauração das operações de negócio aos seus níveis originais, no menor intervalo de tempo possível e dentro do tempo máximo de recuperação, nos casos de desastres (incidentes gravíssimos que causam a parada do negócio).

Pode-se optar por algumas estratégias de recuperação que causam impacto em três fatores na instituição: tempo, recursos humanos e recursos financeiros. Vejam algumas estratégias:

• Aceite: quando a análise do risco inferir que não causará impacto ao negócio, ou que a instituição, mesmo ciente dos impactos ao negócio, opta por aceitá-lo.
• Procedimento Administrativo: quando a instituição decide por contingenciar o impacto através de decisões administrativas, como, temporariamente, fazer uso de documentos em papel para posterior digitação.
• Fortificação: é quando a instituição decide por reforçar sua infraestrutura contra incidentes.
• Hot Site: datacenter primário com a infraestrutura duplicada (ou parcialmente) em site secundário. Faltam apenas os dados que poderão ser recuperados através de backups do site primário. Em caso de desastre, o site secundário fica disponível quase que imediatamente. Custo alto e tempo de recuperação baixa.
• Warm Site: é a implementação do Hot Site em baixa escala, pois o site secundário terá infraestrutura limitada e sem atualizações periódicas de software/dados, sendo realizada somente em caso de desastre. Custo menor que a opção anterior, mas tempo de recuperação maior.
• Cold Site: é a implementação de um Warm Site, sob demanda, em local reservado com apenas a infraestrutura básica disponível (energia elétrica, ar condicionado, etc). Custo muito baixo, tempo muito alto de recuperação.
• Mirrored Site: é a implementação do Hot Site, mas com o site secundário funcionando os mesmos serviços do site primário para manter seus dados sincronizados, em paralelo, em outra localidade. Custo altíssimo, mas com tempo de recuperação imediata.
• Consortium Arrangement: esta estratégia, na verdade, é a implementação de uma das quatro estratégias “Xxx Site” anteriores, mas com o custo dividido entre os participantes do consórcio. O custo de sua implementação é menor do que o custo da implementação da estratégia apenas pela instituição, mas a grande desvantagem é a Segurança da Informação, pois toda a infraestrutura é compartilhada com os outros participantes do consórcio.
• Outsourcing: é o uso da infraestrutura de terceiros para se estabelecer um site secundário.
• Vendor Supplied Equipment: nesta estratégia conta-se com os SLA estabelecidos em contratos de manutenção com fornecedores para a reposição de equipamentos. Possui baixo custo de implementação, mas um alto risco de não atendimento dentro do SLA e é difícil cobrir todos os incidentes em contratos de manutenção.

Plano de Continuidade Operacional

Este plano visa definir os procedimentos para contingenciar os ativos que suportam os processos de negócio, objetivando reduzir o tempo de indisponibilidade e os impactos causados por um incidente. Neste plano deverão ser inseridas as ações (mesmo em site de contingência) a serem executadas para que o negócio não sofra impacto ou que o impacto seja reduzido.

No plano deverão, no mínimo, constar:

• O objetivo do plano
• Pessoas chaves (equipe de comando e equipe de execução), com níveis de autoridade e responsabilidades, meios de contato e a cadeia de escalonamento
• A sala de guerra (War Room) local e externa (em caso de incidente grave) para o comando da operação.
• Processos críticos de negócio priorizados, suas condições para ativação (priorizadas, identificadas com seus responsáveis).
• Análise de possíveis dados perdidos e passos para tentativa de recuperação
• Lista de contatos dos clientes para informe do incidente e das ações tomadas para recuperação do negócio.
• Lista de contato com fornecedores para informe de mudança de local de trabalho, por exemplo, caso atuem dentro do site substituir ou para troca temporária de endereço de entrega de equipamentos, peças, insumos ou execução de serviços.
• Manutenção dos processos críticos de negócio

Plano de Capacitação do PCN

De nada adianta termos uma plena gestão sobre a continuidade do negócio, termos todas as ações referentes ao tratamento de incidentes, identificadas, analisadas e detalhadas em documentos, mas ninguém as conhecer ou fazer uso. Tão importante quanto prover o treinamento às pessoas comprometidas com os planos, evidenciando seus papeis e responsabilidades, é envolver a alta direção, diretores, gestores, funcionários e colaboradores diversos nestas capacitações, pois, de algum modo, todos são stakeholders em uma situação de desastre.

Veja abaixo um modelo de capacitação em GCN para apoiar na produção do seu próprio guia de treinamento.

Fluxo da GCN com a ocorrência de um incidente

Estamos em um dia normal de trabalho e acontece um incidente... o que devemos fazer? 

Bem, se tivermos com equipes preparadas, com planos atualizados e disseminados na instituição, basta analisar e executar o PCN.

A GCN e um incidente

• Passo 1: a resposta ao incidente - no intervalo de minutos a horas, deverá ocorrer a localização da Equipe e de visitantes; as fatalidades já deverão estar gerenciadas; os danos causados pelo incidente já deverão ter sido contidos/limitados e avaliados; a execução imediata do PCN é fundamental para o sucesso da continuidade do negócio.
• O objetivo geral desta etapa é garantir a segurança das pessoas e conter os danos.
• Avaliar e executar o PC/PGI até onde for necessário. 
• Avaliar e executar o PAC, até onde for necessário.

• Passo 2: a continuidade do negócio - no intervalo de minutos a dias, deverá ocorrer o contato com clientes, fornecedores e outros stakeholders; a recuperação dos processos críticos ao negócio, com a recuperação de trabalho perdido, quando necessário.
• O objetivo geral desta etapa é dar continuidade ao negócio, independente do impacto causado pelo dano.
• Executar o PCO.

• Passo 3: a recuperação do negócio - no intervalo de semanas a meses, deverá ocorrer o reparo/substituição do dano; o retorno das atividades ao local original de trabalho; a recuperação dos custos de seguros.
• O objetivo geral desta etapa é retornar à normalidade operacional anterior à ocorrência do incidente.
• Executar o PRD.

Abaixo, estão alguns arquivos para serem utilizados como referência na produção dos documentos de Continuidade de Negócio de sua instituição.


ATENÇÃO: a instituição que hoje ignora a ocorrência de um incidente com o pensamento "Qual é a probabilidade disto acontecer?" deve ficar atenta a pontos críticos com relação ao seu negócio:

• atender aos clientes (direitos, satisfação, imagem e reputação)
• atender às regulamentações (deveres, contratos, leis, processos judiciais)
• atender ao board da instituição (perda de ativos, de receitas, de credibilidade e de poder)
• manter-se no mercado (estabilidade e sobrevivência)

E passar a pensar sobre o incidente e seus impactos de outro modo: "E quando isto acontecer?"

REFERÊNCIAS

Gestão da Continuidade de Negócios - 1/3

Gestão da Continuidade de Negócios - 2/3

SEFAZ - PGI 002 - Incêndio

SEFAZ - Capacitação em GCN

SEFAZ - Metodologia de GCN

SEFAZ - Modelos GCN (Questionário BIA, Estratégia de Continuidade, Plano de Testes)

É isso aí! Aumente a resiliência de sua instituição garantindo sua continuidade do negócio... e até a próxima!

Gestão da Continuidade de Negócios - 2/3

Hoje será dado continuidade à sequência de posts sobre a GCN - serão apresentados os Testes do PCN, o Plano de Administração de Crise e o Plano de Contingência.

Os Testes do PCN

Nesta fase são validadas as hipóteses de soluções aos incidentes mapeados e tratados. Os testes podem ocorrer fora do período de trabalho (noturno ou durante o fim de semana) ou, dependendo da necessidade dentro de um horário crítico, mas controlado.

Para se testar um PCN é necessário:

• Realizar o anúncio à instituição (provável parada controlada nas operações)
• Realizar a simulação do incidente, causando/simulando a parada de ativos críticos
• Seguir os planos do PCN para recuperação das operações

Uma vez reativados os ativos críticos, deverá ser realizado um registro de todos os resultados obtidos – impacto na equipe, em recursos humanos, no negócio, em processos, em equipamentos ou softwares e os desvios ocorridos durante sua execução – com os testes para proceder uma evolução dos planos do PCN, quando/se necessário.

O Plano de Administração de Crises

Crise é o momento que ocorre um incidente que comprometa (deteriore/interrompa) a operação normal da instituição. Durante uma crise, o Comitê da GCN deverá analisar o problema/situação e decidir se irá ativar o processo de Contingência, realizando os devidos contatos com as áreas para que iniciem a execução de seus planos.

Este plano apoia a equipe de administração de crises da instituição em caso de incidente que acarrete uma crise, minimizando os riscos e a falta de controle sobre a mesma, neste momento crítico. Esta equipe que atuará sobre a crise (a mesma que definiu as políticas do PCN) deve comandar a execução do PCN e manter a alta direção alinhada com as ações tomadas e seus resultados.

O PAC deve conter, no mínimo, as seguintes informações:

• O objetivo do plano e as possíveis crises a serem tratadas
• Integrantes da equipe de administração de crise.
• As atividades para administração da crise, seus responsáveis e contatos.
• A sala de guerra (War Room) local e externa (em caso de incidente grave) para administração da crise.
• As diretrizes para realização de informes internos e externos

O Plano de Contingência

Contingência é o momento em que ocorre a mobilização de recursos para responder ao incidente e garantir a continuidade dos negócios críticos durante o incidente.

Aqui estarão contidas as ações e respostas viáveis a incidentes previamente identificados, analisados e geradas as possíveis soluções, objetivando estabilizar a operação.

O PC deve conter, no mínimo, as seguintes informações:

• O objetivo do plano e as ameaças que estão sendo tratadas
• Pessoas chaves (equipe de comando e equipe de execução), com níveis de autoridade e responsabilidades, meios de contato e a cadeia de escalonamento
• Processos de respostas emergenciais (checklist), como, evacuação do ambiente, desativação do ambiente, proteção dos dados
• Condições para ativação dos processos e suas respectivas ações (priorizadas, identificadas com seus responsáveis e os prazos de execução).
• A sala de guerra (War Room) local e externa (em caso de incidente grave) para o comando da operação.
• O catálogo de ativos críticos (hardware, software, dados e documentos)
• Processos de restauração de contingência, com o devido controle, comunicação, recuperação e restauração e, se necessitar, incluir a parte administrativa e logística da operação.
• Documentos de apoio, como a localização física dos ativos críticos de TI, a planta baixa do ambiente com suas instalações elétricas e hidráulicas, a localização de extintores (internos e externos), etc.

Para tornar as tomadas de decisões serão mais rápidas e assertivas, o catálogo de ativos deve ser identificado por níveis de importância ao negócio, como o exemplo baixo (criando tantos níveis quanto se acreditar necessário):

• Nível 1: Ativos de alta importância e alto impacto, que prejudicam muito ou interrompem o negócio.
• Nível 2: Ativos de média importância e médio impacto, que prejudicam o negócio.
• Nível 3: Ativos de baixa importância e baixo impacto, que prejudicam pouco ou nada ao negócio.

E, para cada ativo catalogado, faça a correlação com os processos de negócio que ele suporta, assim, com esta referência cruzada, ficará fácil identificar o impacto no negócio quando o ativo precisar ser movido ou tiver sido prejudicado/danificado.

Conforme a criticidade do incidente causador da interrupção das operações, o PCN pode ser executado total ou parcialmente, em acordo com suas definições, visando dar suporte às atividades críticas necessárias. O conteúdo e os planos componentes do PCN devem variar, em profundidade de detalhe, em escala/abrangência, em relação ao ambiente, à cultura organizacional e à complexidade da instituição. E, ainda, de acordo com o tamanho da instituição e/ou complexidade do negócio, o PCN pode necessitar de documentos separados para cada um de seu incidente crítico (PGI - Plano de Gerenciamento de Incidente) ou, simplesmente, ter todos os aspectos consolidados no PC.

O Plano de Gerenciamento de Incidente (PGI), quando elaborado, possuirá instruções detalhadas de ações a serem executadas em caso de ocorrência de determinado incidente - veja um exemplo de PGI no post final da sequência GCN.

O PCN deve ser testado com frequência, ter seus resultados avaliados e, em caso de necessidade, evoluído, mantendo-o, assim, adequado aos seus objetivos primários. Além disto, tanto as pessoas comprometidas com as ações de recuperação (principalmente), quanto as pessoas que estão envolvidas com a instituição, devem conhecer o PCN e serem capazes de executar as ações sob sua responsabilidade (nem que sejam apenas as ações “Manter a calma” e “Evacuar o ambiente”).

É muito importante que todo o planejamento do processo da Gestão da Continuidade de Negócio leve em consideração a Segurança da Informação, pois o ambiente de continuidade do negócio (muito provavelmente) será diferente do ambiente controlado normal de operação, aumentando potencialmente as ameaças e vulnerabilidades do negócio durante este período de transição. 

REFERÊNCIAS

Gestão da Continuidade de Negócios - 1/3

Até o próximo e último post da "trilogia" GCN com a compilação de alguns documentos de apoio para download.

Gestão da Continuidade de Negócios - 1/3

Hoje será iniciada uma série de 3 posts sobre Gestão da Continuidade de Negócio.

Este assunto é extremamente importante para a sobrevivência de sua instituição quando ela sofrer um grave incidente! Não, não é premonição, é um fato: um dia sua instituição vai sofrer um incidente crítico, portanto, faça o planejamento da continuidade do seu negócio com antecipação...

Gestão da Continuidade de Negócios

A Gestão de Continuidade de Negócio (GCN) é o estabelecimento de uma estrutura estratégica e operacional, bem documentada, bem capacitada, para melhorar a resiliência da instituição, recuperar sua operacionalização pós-desastre e gerenciar as devidas interrupções nos negócios junto aos stakeholders.

Organograma & Responsabilidades

• Alta Direção – papel de criar as políticas de GCN (ou de delegar ao Comitê), criar o Comitê de GCN e aprovar os planos de GCN.
• Comitê/Gestão de GCN, composto pela alta direção, diretorias e gerentes sêniores – papel de direcionar as ações de GCN, disseminar o GCN na instituição, manter o PCN alinhado aos negócios, alocar recursos e apoiar a gestão da crise.
• Equipe de Administração de Crise, composto pelo Comitê e pelo representante da área de relações públicas da instituição – papel de condução da comunicação em momento de crise e definição da equipe que irá elaborar a política do PCN.
• Equipes de Gerência do PCN, composto por gerentes, coordenadores, gestores e representantes de áreas de negócio – papel de condução da elaboração do PCN e de comunicação entre os membros participantes e a equipe do Comitê de GCN.
• Equipes técnicas do PCN – papel de elaboração, manutenção, testes e execução do PCN

Abaixo compartilho um mapa de conceitos gerais de GCN bem interessante:

Mapa de Conceitos de Gestão de Continuidade de Negócio - Jorge H C Fernandes, 2011

Plano de Continuidade de Negócios

O Plano de Continuidade de Negócios (PCN) ou Business Continuity Plan (BCP), possui o objetivo de permitir que uma instituição mantenha suas atividades (e recupere-as!) em caso de interrupção das operações de negócios devido a um incidente – o negócio original pode ser dependente de ativos de TI ou até mesmo ser executado por processos manuais.

Para se criar um PCN seguimos algumas normas, definições e, é claro, as boas práticas de mercado. Logo de início, o Comitê de GCN deve definir a Política do PCN em um documento sucinto, abordando itens imprescindíveis à responsabilidade, criação e manutenção do PCN – este documento deve ser formalmente aprovado pela Alta Direção e estar acessível a todas as pessoas que possuem contato com a instituição:

Informações importantes na Política de GCN:

• Identificar a equipe responsável pela criação da política.
• Definir a periodicidade de avaliação, revisão e atualização dos planos do PCN.
• Definir os meios de publicação dos documentos derivados da PCN.
• Definir os participantes da Gerência de PCN, incluindo neste, representantes de áreas de negócio.
• Definir o coordenador do PCN.
• Definir os processos críticos ao negócio e seus responsáveis.
• Definir os grupos responsáveis pela criação, acompanhamento, revisão, avaliação, evolução, frequência e execução de testes e treinamento dos Planos do PCN.
• Definir a frequência da capacitação das pessoas comprometidas com a execução do PCN.
• Deve ser considerada a identificação e concordância de todas as responsabilidades e procedimentos do PCN.

A identificação dos procedimentos necessários para a manutenção e continuidade do negócio é, sem dúvida, uma atividade onerosa, mas imprescindível, e que requer bastante conhecimento dos processos críticos que integram o negócio e, principalmente, conhecimento dos procedimentos que fazem parte destes processos – serão nestes procedimentos que as ações de contingência/manutenção da continuidade de negócio serão executadas para que possam ser recuperados, de acordo com as prioridades do negócio, no menor intervalo de tempo possível. Após esta etapa, a identificação e concordância das responsabilidades por cada um deles será facilitada.

Com a Política aprovada, pontuando as necessidades básicas da instituição com relação à continuidade do negócio, damos início à elaboração do PCN.

Para se construir o PCN (veja alguns documentos de apoio ao final do último post desta "trilogia") atente-se às etapas estabelecidas pelo BSI Group:

Ciclo de vida da GCN, BSI Group

Reconhecer e compreender a estrutura organizacional

Esta etapa objetiva alinhar o PCN com os objetivos, obrigações e responsabilidades da instituição.

O que precisa ser feito:

• Definir o escopo, o cenário atual e seu nível de maturidade.
• Fazer uma Análise de Impacto sobre Negócios (BIA – Business Impact Analysis), para identificar, medir e avaliar os resultados de um incidente objetivando: quantificar os impactos financeiro, operacional e de reputação; processos de negócio críticos e suas prioridades; recursos críticos; dependências (internas e externas); prazo máximo de indisponibilidade do negócio; prazo máximo para recuperação do negócio em caso de incidente desastroso.
• Realizar análise, avaliação e gestão dos riscos com base no escopo, cenários e maturidade.

A BIA é um processo de análise em uma instituição utilizado para identificar seus processos críticos de negócios (e suas inter/dependências) e seus prazos limites de operação, com o objetivo de estimar seu impacto (financeiro, operacional e reputação) devido às paradas causadas por incidentes e criar uma ordem de recuperação dos processos.

A avaliação dos riscos sendo executada após a BIA auxilia a focar os esforços nos processo críticos da instituição, mas leve em consideração que é quase impossível prever todos os riscos operacionais, devido à dificuldade de identificar as possíveis ameaças. Trate tantos riscos quanto forem possíveis (custo X benefício).

Definir as estratégias para a continuidade do negócio

Esta etapa objetiva considerar aspectos de continuidade relativos a pessoas (retenção de conhecimentos do negócio), instalações (redução do impacto pela indisponibilidade das instalações físicas normais de trabalho), serviços de tecnologia (garantia do provisionamento), informação (considerar os diversos meios – físicos e digitais – nos quais a informação é retida – de forma provisória ou definitiva –, a conservação dos níveis de segurança e do nível aceitável de falta de atualização da informação), suprimentos (inventariar e desenvolver estratégia de ressuprimento para a execução das atividades críticas) e relações com stakeholders (considerar fatores de mercado, culturais e condições especiais de atendimento e relacionamento, durante e após o desastre, com os stakeholders).

O que precisa ser feito:

• Definir estratégias para a instituição
• Definir estratégias para os processos de negócio
• Definir estratégias para recuperação de ativos

Desenvolver e implementar respostas

Esta etapa objetiva buscar a implantação das estratégias definidas e a formalização de planos que garantam o gerenciamento de incidentes e a continuidade de suas atividades críticas. Deve ser estruturada uma equipe de gerenciamento de crises ou incidentes que tem como funções avaliar o incidente (natureza e extensão), controlá-lo e se comunicar com as partes internas e externas envolvidas na solução (polícia, bombeiros, imprensa, fornecedores, funcionários, dentre outros).

O que precisa ser feito:

• Plano de Gerenciamento de Incidentes
• Plano de Continuidade de Negócios:
• Plano de Contingência (PC)
• Plano de Administração de Crises (PAC)
• Plano de Recuperação de Desastres (PRD)
• Plano de Continuidade Operacional (PCO)

Aplicar, manter e rever (evoluir)

Esta etapa objetiva garantir a validação das ações descritas nos planos por meio de testes e análises críticas, além de contribuir com sua manutenção, de forma a mantê-las permanentemente atualizadas/coerentes com as necessidades da instituição.

O que precisa ser feito:

• Planejamento e execução dos testes dos planos de PCN
• Avaliar e manter os planos de PCN
• Evoluir, analisando, auditando, identificando e implementando potenciais melhorias no PCN

Todos estes planos devem ser desenvolvidos e implementados para a manutenção e recuperação das operações e para assegurar a disponibilidade da informação no nível requerido e na escala de tempo requerida, após ocorrência de interrupções ou falhas dos processos críticos do negócio.

Abraços e até a segunda parte do tema GCN, quando falaremos sobre o Plano de Administração de Crises e o Plano de Contingência.

Produtos derivados da implantação do SGSI

Neste post, assim como foi feito para a implantação da Governança Corporativa e de TI, foram enumerados alguns produtos (documentos, processos, normas, planos, controles, diretrizes, etc) que normalmente são criados a partir da implantação de um Sistema de Gestão de Segurança da Informação e devem ser mantidos e evoluídos de forma cíclica por seus respectivos processos de gestão.

Produtos derivados da implantação de um SGSI

RELACIONADOS À PSI

• Escopo da PSI
• PSI (Política de Segurança da Informação)
• Política de Conformidade
• Plano de Gestão da PSI
• Gestão de Comunicação da SI
• Plano de Conscientização de SI
• Gestão de Riscos de SI
• Matriz de Papeis e Responsabilidades sobre a SI
• Matriz de Contatos com Autoridades (escalation matrix)
• Normativos de Segurança da Informação
• Política de Continuidade de Negócio
• Termo de Aceitação da PSI
• Acordos de Confidencialidade (NDA)
• Processo Disciplinar Formal

RELACIONADOS AOS ATIVOS

• Gestão de Ativos
• Inventário de Ativos
• Processo de Classificação da Informação
• Política de Uso de Ativos de TI
• Política de Controle de Acessos aos Ativos
• Política de Movimentação de Ativos
• Processo de Gerenciamento de Acessos aos Ativos
• Gestão de Mudança de Ativos Críticos
• Política de Teste de Falhas em Ativos Críticos
• Plano de Continuidade de Negócio
• Plano de Contingência
• Plano de Gerenciamento de Incidentes
• Plano de Administração de Crises
• Plano de Recuperação de Desastres
• Plano de Continuidade Operacional
• Gestão de Capacidade

RELACIONADOS AOS SERVIÇOS

• Política de Gerenciamento de Redes
• Política de Controle de Acessos às Áreas Restritas
• Política de Incidentes de SI
• Política de Manuseio de Mídias
• Política de Monitoramento e Controle de Eventos
• Política de Proteção Contra Códigos Maliciosos e Móveis
• Política de Uso de Criptografia
• Política de Senhas
• Política de Troca de Informações
• Política de Redes (Segregação)
• Gestão de Segurança Física
• Política de Backup/Restauração
• Gestão dos Níveis de Serviço
• Acordos de Nível de Serviço (SLA - Service Level Agreement)
• Acordos de Nível Operacional (OLA - Operational Level Agreement)
• Contratos de Apoio (UC - Underpinning Contract)
• Planos de Melhorias de Serviços
• Gestão de Portfólio de Serviços
• Gestão da Conformidade

RELACIONADOS A SISTEMAS (Desenvolvimento interno ou externo)

• Gestão de Homologação de Software
• Política de Requisitos de SI para Sistemas
• Gestão de Portfólio de Sistemas

RELACIONADOS A TERCEIROS

• PSI para Fornecedores
• Matriz de Contatos com Grupos Especializados em SI
• Gestão de Contratos
• Gestão de Mudança da Contratação

RELACIONADO ÀS PESSOAS

• Processo de Classificação e Organização das Funções
• Política para uso de dispositivo pessoal
• Política de Computação Móvel e Trabalho remoto

É isso aí, pessoal, temos muito trabalho para garantir a Segurança da Informação de nossa instituição...

REFERÊNCIAS

Produtos derivados da Governança

Sistema de Gestão de Segurança da Informação - 1/3

Sistema de Gestão de Segurança da Informação - 2/3

Sistema de Gestão de Segurança da Informação - 3/3

Checklist da Norma ISO 27.001

Abraços!

Checklist da Norma ISO 27.001

Checklist da Norma ISO 27.001

Neste post será apresentado o checklist preparado para os 133 controles da Norma ISO 27.001, ajudando na implantação do SGSI em uma instituição.

O código ISO foi dividido em níveis, para uma melhor indexação dos controles, podendo, assim, uma instituição optar por implementar e evoluir controles que se referenciam ao mesmo assunto. Na coluna Controle foi apresentada a descrição da necessidade para a implementação do respectivo controle:

• Aquisição, desenvolvimento e manutenção de sistemas de informação
• Controles criptográficos
• Gestão de vulnerabilidades técnicas
• Processamento correto de aplicações
• Requisitos de segurança de sistemas de informação
• Segurança dos arquivos do sistema
• Segurança em processos de desenvolvimento e de suporte
• Conformidade
• Conformidade com normas e políticas de Segurança da Informação e conformidade técnica
• Conformidade com requisitos legais
• Considerações quanto à auditoria de sistemas de informação
• Controle de acessos
• Computação móvel e trabalho remoto
• Controle de acesso à aplicação e à informação
• Controle de acesso à rede
• Controle de acesso ao sistema operacional
• Gerenciamento de acesso do usuário
• Requisitos de negócio para controle de acesso
• Responsabilidades dos usuários
• Gerenciamento das operações e comunicações
• Cópias de segurança
• Gerenciamento da segurança em redes
• Gerenciamento de serviços terceirizados
• Manuseio de mídias
• Monitoramento
• Planejamento e aceitação dos sistemas
• Procedimentos e responsabilidades operacionais
• Proteção contra códigos maliciosos e códigos móveis
• Serviços de comércio eletrônico (Sistemas transacionais On-Line)
• Troca de informações
• Gestão da continuidade do negócio
• Aspectos da gestão da continuidade do negócio, relativos à Segurança da Informação
• Gestão de ativos
• Classificação da informação
• Responsabilidade pelos ativos
• Gestão de incidentes de Segurança da Informação
• Gestão de incidentes de Segurança da Informação e melhorias
• Notificação de fragilidades e eventos de Segurança da Informação
• Organizando a Segurança da Informação
• Infraestrutura da Segurança da Informação
• Partes externas
• Política de segurança
• Política de Segurança da Informação
• Segurança em recursos humanos
• Antes da contratação
• Durante a contratação
• Encerramento ou mudança da contratação
• Segurança física e do ambiente
• Áreas seguras
• Segurança de equipamentos

E ainda, para facilitar o agrupamento e implementação de cada controle no SGSI de sua instituição, os controles foram identificados por:

• Sua relevância dentro do conjunto de controles

• Seu custo/dificuldade de implementação

Assim, a implantação do SGSI poderá ser dividida em etapas, como, por exemplo, um lote com os controles mais relevantes e com menos custo/dificuldade de implementação.

Para complementar, disponibilizei uma apresentação muito interessante sobre Boas Práticas em SI... acredite, realmente vale a pena fazer sua leitura para contextualização no assunto!

Os documentos estão disponibilizados no Box... façam bom proveito!

REFERÊNCIAS

Sistema de Gestão de Segurança da Informação - 1/3

Sistema de Gestão de Segurança da Informação - 2/3

Sistema de Gestão de Segurança da Informação - 3/3

Checklist - Controles da ISO 27.001

SEFAZ - Boas Práticas em Segurança da Informação

Abraços!

Sistema de Gestão de Segurança da Informação - 3/3

Com a apresentação desta terceira parte, será finalizada a sequência de post sobre a SGSI... fique firme, restam poucos controles a serem explorados!

Sistema de Gestão de Segurança da Informação

A.12 - Aquisição, desenvolvimento e manutenção de sistemas de informação

A.12.1 - Requisitos de segurança de sistemas de informação

Deve-se especificar, para novos sistemas de informação ou melhorias em sistemas existentes, os requisitos mínimos para os controles de segurança nas especificações de requisitos de negócios.

A.12.2 - Processamento correto de aplicações

Deve-se implementar políticas para que os dados de entrada de aplicações, o processamento interno, as transações, as integridades das mensagens e os dados de saída sejam validados para garantir que estão corretos e apropriados.

A.12.3 - Controles criptográficos

Deve-se implementar uma política para o uso de controles criptográficos para a proteção da informação levando em consideração o processo de gerenciamento de chaves - as tecnologias de criptografia devem ser implantadas em conformidade com uma política de classificação da informação.

A.12.4 - Segurança dos arquivos do sistema

Deve-se implementar politicas e procedimentos formais para controlar a instalação de software (mesmo os freeware) em sistemas operacionais.

Deve-se desenvolver e implementar politicas e procedimentos formais para que se use ferramentas geradoras de dados de testes ou que os dados de teste sejam selecionados com cuidado (subset), protegidos (descaracterizados) e controlados.

Deve-se controlar e restringir o acesso aos códigos-fontes, documentos, procedimentos e modelos de dados.

A.12.5 - Segurança em processos de desenvolvimento e de suporte

Deve-se implementar controles de mudanças utilizando procedimentos formais com a adoção de procedimentos para que as aplicações críticas de negócios sejam analisadas criticamente e testadas quanto à segurança da informação quando sistemas operacionais são mudados, controlar e restringir modificações desnecessárias em pacotes de software, evitando impacto nas operações.

Deve-se implementar políticas de prevenção de vazamento e perdas de dados na plataforma de DLP e adotar soluções de criptografia, apoiadas por uma política de classificação da informação.

Deve-se adotar a função de gestão de desenvolvimento de software terceirizado sob responsabilidade de um colaborador interno, baseando-se em normas formais sobre desenvolvimentos de software e implementando uma política de propriedade intelectual.

A.12.6 - Gestão de vulnerabilidades técnicas

Deve-se implementar processos adequados e periódicos para identificação e monitoração de vulnerabilidades técnicas dos sistemas de informação e posterior tratamento aos riscos identificados.

A.13 - Gestão de incidentes de Segurança da Informação

A.13.1 - Notificação de fragilidades e eventos de Segurança da Informação

Deve-se implantar procedimentos e canais apropriados para que os eventos de SI sejam relatados à direção, o mais rapidamente possível.

Deve-se implementar um canal de denúncias, com a adoção de mecanismo que garanta o anonimato (e isso deve estar explícito), para que os funcionários, fornecedores e terceiros possam ser formalmente instruídos a registrar e notificar qualquer observação ou suspeita de fragilidade em sistemas ou serviços.

A.13.2 - Gestão de incidentes de Segurança da Informação e melhorias

Deve-se implantar normas, políticas e procedimentos que definam a responsabilidade e estabeleçam respostas rápidas, efetivas e ordenadas a incidentes de SI, que devem ser monitorados, mensurados e analisados criticamente e, também, deve considerar processos adequados para coleta e custódia legal de evidências.

A.14 - Gestão da continuidade do negócio

A.14.1 - Aspectos da gestão da continuidade do negócio, relativos à Segurança da Informação

Deve-se implantar normativos e processos formais para garantir a continuidade dos negócios da instituição. Estes processos devem: identificar os serviços críticos ao negócio; ser embasados em avaliações de risco e impacto; possuir plano de recuperação de interrupção/falhas (garantir a disponibilidade dos serviços); possuir níveis de serviços mínimos aceitáveis e ser testado/atualizado periodicamente, garantindo sua eficiência e eficácia.

A.15 - Conformidade

A.15.1 - Conformidade com requisitos legais

Deve-se implementar processo periódico formal para verificação de requisitos estatutários, regulamentares e contratuais relevantes e a definição de enfoque da instituição nestes.

Deve-se implementar políticas sobre direitos de propriedade intelectual e sobre o uso de produtos de software proprietários.

Deve-se implementar política de classificação da informação, com o uso de ferramentas como plataformas de criptografia e prevenção de perda de dados, refletindo os requisitos legais aplicáveis às informações protegidas.

Deve-se implantar processos formais de conscientização de SI para que os usuários evitem usar recursos de processamento da informação indevidamente.

Deve-se implementar uma política para o uso de controles criptográficos para a proteção da informação levando em consideração o processo de gerenciamento de chaves - as tecnologias de criptografia devem ser implantadas em conformidade com uma política de classificação da informação. No Brasil ainda não existe regulamentação ou lei aplicável à normatização de criptografia.

A.15.2 - Conformidade com normas e políticas de Segurança da Informação e conformidade técnica

Deve-se implementar norma que defina os gestores como responsáveis pela execução dos procedimentos de SI de forma correta e adequada, dentro de sua área, com a verificação de conformidade identificada através de processos. Deve-se realizar termos aditivos ao contrato de trabalho que descrever aos gestores a obrigação de conhecer e cumprir a PSI.

Deve-se implementar processo formal periódico para verificação de conformidade dos sistemas de informação às normas e à PSI.

A.15.3 Considerações quanto à auditoria de sistemas de informação

Deve-se implantar um processo formal para verificação de conformidade dos sistemas de informação (aplicativos e SO) às normas e PSI.

Deve-se implantar um processo formal para verificação de conformidade dos ferramentas de auditoria de sistema de informação às normas e à PSI, com o objetivo de proteger o acesso às mesmas e prevenir a possibilidade de uso indevido.

Após esta enxurrada de informação sobre Segurança da Informação, escolha o modelo ideal para sua instituição, planeje muito bem sua PSI e faça a implantação com todo apoio da Alta Administração - todas as pessoas envolvidas com a instituição devem estar comprometidas com a Segurança da Informação.

É isto aí... com este post encerra-se a explanação sobre a importante Norma ISO 27.001.

Em breve será apresentado um checklist com todos os 133 controles da Norma ISO 27.001 para que possa ser utilizado como guia na implantação de um SGSI... aguarde!

Mas, enquanto aguarda, como sabemos que os ativos de uma instituição necessitam estar bem protegidos e já conhecemos um pouco mais sobre Segurança da Informação, agora só depende de dar o primeiro passo para se iniciar a implantação do SGSI... o que você está esperando?

REFERÊNCIAS

ABNT

ISO 27.001

ISO 27.002

Sistema de Gestão de Segurança da Informação - 1/3

Sistema de Gestão de Segurança da Informação - 2/3

Abraços e até a próxima!