InfoSec Council

Planejamento Estratégico da Segurança da Informação

Capítulo 8 - Gerenciamento de Mudanças * 

Neste capítulo, trataremos das questões que envolvem a gestão de mudanças, os desafios relacionados a este processo crítico da tecnologia da informação (TI), como dois dos mais conhecidos modelos de melhores práticas tratam o tema e como é possível avaliar se um processo de gestão de mudanças alinhado ao planejamento estratégico de segurança da informação (PESI) entrega, de fato, valor ao negócio.

1. Mudanças como causas de incidentes

Um percentual significativo dos problemas que ameaçam a disponibilidade, a integridade e a aderência regulatória nos serviços críticos da TI tem sua origem na execução inadequada e pouco planejada de mudanças. Desta forma, ao invés de voltar sua atenção na gestão de incidentes, que trata do problema depois de seu aparecimento, a TI deve olhar, de forma preventiva, para a gestão de mudanças para evitar a ocorrência de incidentes. Na verdade se os processos de gestão de mudanças não são estruturados e constantemente aprimorados (no melhor entendimento do modelo PDCA – Plan, Do, Check and Action, ou planejamento, execução, verificação e ação), provavelmente o departamento de TI entrará em um ciclo vicioso, onde parte dos incidentes de segurança será causada por ações oriundas da própria TI; e mesmo as ações corretivas podem ser a origem de novos incidentes.

Segundo o ITIL® (Information Technology Infrastructure Library), os principais problemas relacionados a

este processo são:

• A falta de informação para análise de riscos – o surgimento de situações não previstas decorre da falta de uma base de configuração atualizada com as informações necessárias para fazer uma adequada análise de impacto;
• A falta de integração entre processos – a utilização de uma ferramenta adequada apóia o controle de mudanças e a sua integração aos demais processos auxilia o planejamento da mudança;
• Priorização de todas as mudanças – as mudanças devem ser planejadas e agendadas no tempo correto e de acordo com as necessidades de negócio. Devem ser tratadas apenas como mudanças urgentes àquelas que implicam na indisponibilidade atual ou imediata de um serviço.

A cultura da empresa influenciará na adesão e implantação deste processo e seus controles. O fator humano é essencial na mudança de paradigma. É importante fazer com que a equipe em TI esteja consciente dos efeitos positivos do processo como um todo. A falta de comprometimento da equipe é um dos pontos críticos em se tratando da gestão de mudanças. Da mesma forma, os usuários e a alta administração precisam estar conscientes de que o planejamento e os controles não são inimigos da flexibilidade, mas contribuem para um ambiente operacional equilibrado, estável e disponível.

Para colocar um pouco mais de ordem neste cenário extremamente desafiador, podemos lançar mão dos modelos de melhores práticas do CobiT® 4.1, mais especificamente no processo AI6 – Gerenciar mudanças.

2. Desafios na gestão de mudança

As exigências pela excelência nos níveis de serviços para alcançar os objetivos do negócio são crescentes. Derivado desta necessidade, é possível perceber a área de TI em constante mudança para atender a demanda da evolução do cenário de negócios, implantando novas soluções, aumentando a capacidade e criando novos controles. Como fazem os tubarões, é preciso estar sempre em movimento, atento e, principalmente, sem se deixar levar pelo pânico. Planejar, ponderar e agir com lucidez são requisitos para que decisões emotivas não nos levem ao fracasso.

A princípio todas as mudanças, previstas ou não, seriam contempladas em um processo de gestão de mudanças. Contudo, na maioria das vezes é impraticável tratar todas as mudanças desta forma. Sinteticamente, podemos dizer que as principais atividades que envolvem a gestão de mudanças são:

• Monitoração e direcionamento do processo de mudança;

• Registro, avaliação e aceite ou rejeição das requisições de mudança (request for change ou, simplesmente, RFCs) recebidas;

• Classificação e priorização das mudanças junto aos comitês de negócio competentes para aprovação das RFCs;
• Coordenação do desenvolvimento e implantação da mudança;
• Avaliação dos resultados da mudança e encerramento do processo de mudança em caso de sucesso.

Todas as mudanças, incluindo aplicação de patches e manutenções emergenciais, sejam relacionadas à infraestrutura ou aplicações em ambiente de produção, devem ser formalmente geridas de maneira controlada. As mudanças (incluindo de procedimentos, processos, sistemas e parâmetros de serviço) são registradas, avaliadas e autorizadas antes de sua implantação e revisadas frente aos benefícios planejados. Estas etapas garantem certo conforto de que impactos negativos não afetem dois dos principais pilares da segurança da informação: a disponibilidade e a integridade do ambiente de produção.

A gestão de mudanças não pode ser uma cruzada individual da TI. O envolvimento e o apoio da área de negócio são vitais para o sucesso desta empreitada. Desde o primeiro momento, comitês de negócio devem ser formados visando não só a participação das principais áreas da empresa, mas a formação de uma cultura de gestão recursos e governança da TI. Outro suporte altamente recomendável é a aplicação de um modelo de maturidade na indicação dos níveis de formalização e automatização das atividades.

3. Gestão de mudanças segundo o CobiT®

Segundo o modelo de boas práticas e controles da ISACA®, os controles sobre o processo da TI de gerir mudanças visam, de forma direta, a geração de soluções que reduzam defeitos e retrabalho, requisitos alinhados as estratégias de negócio de qualquer companhia. Para isso, é preciso focar nos controles relacionados a avaliações de impacto, na autorização e implantação de todas as mudanças à infraestrutura da TI e na implantação de soluções técnicas. Estas ações minimizam erros originados de requisições de mudança incompletas ou podem chegar a suspender uma implantação de mudanças não autorizadas.

Estes objetivos, contudo, são alcançados pela definição e comunicação de procedimentos de mudança, incluindo-se aí as mudanças emergenciais. Soma-se a este procedimento o desenvolvimento e aplicação de método para avaliação, priorização e autorização de mudanças e, por fim, o rastreamento de status e reporte das mudanças.

O processo em si de gestão de mudanças é subdividido em cinco atividades, a saber:

1) Padrões e procedimentos de mudança: estabelecimento de procedimentos formais de mudança para gerir de forma padronizada todas as solicitações (incluindo manutenção e patches) para mudanças em aplicações, procedimentos, processos, sistemas e parâmetros de serviço, em suas respectivas plataformas.

2) Avaliação de impacto, priorização e autorização: avaliação de todas as requisições de mudança (RFCs) de forma estruturada para determinar o impacto nos sistemas em operação e suas funcionalidades. Além disso, garantir que todas as mudanças sejam categorizadas, priorizadas e, principalmente, autorizadas.

3) Mudanças Emergenciais: estabelecimento de um processo para definição, identificação, teste, documentação, avaliação e autorização de mudanças emergenciais que, eventualmente, não seguirão o processo préestabelecido de mudanças.

4) Rastreamento de status das mudanças e reporte: estabelece um sistema, automatizado ou não, para rastreamento e reportado as mudanças rejeitadas, comunicação do status das alterações aprovadas, em avaliação, em andamento e das mudanças finalizadas. Ter segurança de que toda as alterações aprovadas foram implementadas conforme planejado.

5) Encerramento e documentação: independente da mudança implementada, deve-se atualizar os sistemas relacionados, bem como a documentação do usuário e procedimentos.

Espera-se que, fruto da implantação destas atividades, tenha-se os seguintes resultados:

• Uma abordagem padronizada e consensual para avaliação de impactos de forma eficiente e eficaz;

• Expectativas formalmente definidas para impactos de mudanças, emergenciais ou não, baseadas nos riscos do negócio e em medições de desempenho;

• Procedimentos consistentes de mudança, emergenciais ou não;
• Uma abordagem padronizada e consensual para documentação das mudanças;
• Mudanças revisadas e aprovadas de forma consistente e coordenada;
• Procedimentos consistentes para mudanças e documentação.

Como em qualquer processo, é vital que todas as atividades gerem um resultado formal, rastreável e auditável.

4. Mantendo os riscos sob controle

O processo de gestão de mudanças tem impactos em virtualmente todos os recursos da TI, como os humanos, infra-estrutura, informações ou aplicações. Da mesma forma, aspectos de eficiência, eficácia, integridade, disponibilidade e confiabilidade das informações (este último, de forma secundária) podem ser afetados negativamente caso um processo formal e bem controlado não esteja implantado. Algumas das principais ameaças à TI que podem ser controladas são:

• Autorização de acesso especial não-revogado adequadamente;
• Efeitos adversos na capacidade e desempenho da infraestrutura;
• Mudanças não registradas ou rastreadas;
• Documentação de configuração que não reflete as configurações atuais do sistema;
• Falta de aderência às normas e políticas internas;
• Falta de habilidade na resposta as necessidades emergenciais de mudança;
• Alocação incorreta de recursos;
• Dependência crescente em pessoas;

•  
  • Probabilidade crescente de que mudanças não autorizadas são introduzidas nos sistemas-chave da companhia;
    • Alocação insuficiente de recursos;
    • Controle insuficiente sobre as mudanças emergenciais;
    • Falta de documentação dos processos de negócio;
    • Falta de gestão na priorização das mudanças;
    • Perda do rastreamento das mudanças;
    • Disponibilidade de sistema reduzida;
• Mudanças não autorizadas implantadas, resultando em comprometimento da segurança e acesso não autorizado às informações da companhia;

• Mudanças não detectadas e não autorizadas em ambiente de produção.

5. Medindo a eficiência dos controles

A eficiência e a eficácia deste processo podem ser medidas pela implantação de alguns indicadores de desempenho, a saber:

• Número de falhas graves ou erros de dados causados por uma especificação imprecisa ou uma avaliação de impacto incompleta;

• Volume de retrabalho em aplicações ou infraestrutura causado pela especificação inadequada de mudanças;
• Percentual de mudanças que seguem o processo formal de controle de mudanças.

6. Pergunta para pensar

Um processo é fruto de “entradas” e “saídas”. Ao se implantar um processo para gestão de mudanças, quais seriam as principais fontes dentro da TI e do negócio a serem consideradas? Considerando o CobiT como modelo, consulte os processos PO1, PO4, PO6, PO6 ,PO7, PO8, PO9, PO10, DS3, DS5, DS8, DS9 e DS10.

Leitura recomendada:

CobiT® Mapping Documents. Disponível em: http://www.isaca.org/cobitmapping.

* - Este artigo é parte do documento Planejamento Estratégico da Segurança da Informação, publicado pelo Infosec, e sua integra pode ser lida em Publicações.