Gestão de riscos em TI

Origem: Wikipédia, a enciclopédia livre.
Saltar para a navegação Saltar para a pesquisa

A Gestão de riscos em TI (em inglês, IT Risk Management) diz respeito ao conjunto de métodos/processos adotados para alcançar um equilíbrio entre os riscos e custos de operações. Os processos e rotinas organizacionais estão se tornando cada vez mais dependentes dos recursos e ferramentas tecnológicas, e juntamente com essas novas tecnologias são introduzidos os riscos que elas podem acarretar à organização. De acordo com Ashwin Pal, diretor de cibersegurança na Unisys, a segurança e o gerenciamento de riscos em Ti devem fazer parte do próprio "tecido" de qualquer organização, independentemente do seu tamanho[1].

Uma gestão de riscos bem efetivada possibilita tomadas de decisões mais assertivas, as quais trazem resultados financeiros melhores e uma melhoria no relacionamento com o cliente.[2]. As atividades operacionais da empresam também são beneficiadas, pois ficam menos sujeitas a interrupções e paradas devido a ataques ou erros no sistema.[3]

A melhor forma de se calcular um risco atualmente é baseada no TIK Framework, sendo obtido através da fórmula:

Risco = ((Vulnerabilidade * Ameaça) / Contramedida) * Valor do ativo em risco[1]

Em outras palavras, um risco(no geral) é calculado levando-se em consideração a vulnerabilidade da empresa, a ameaça que o risco proporciona à organização, a eficiência da contramedida usada para anular esse risco e o valor que está jogo por causa desse risco.

Os riscos em TI[editar | editar código-fonte]

Os riscos em TI são considerados riscos de negócios, relacionados ao uso, operação e influência da tecnologia da informação dentro de uma empresa. Por se tratar de um risco, por definição, sua ocorrência e magnitude é incerta, o que acarreta em desafios para a organização, a qual deve prever e mensurar os possíveis riscos visando assim mitigar o seu impacto. O framework proposto pela ISACA (Information Systems Audit and Control Association), em complemento ao CobiT, define 3 categorias para os riscos relacionados a TI, sendo eles:[4]

  • Risco de uso de benefícios ou valores de TI: São os riscos relacionados a perda de oportunidades do uso da TI como uma forma de melhoria na eficiência dos processos empresariais, ou até mesmo sob a forma da criação de novas iniciativas de negócios.
  • Risco de entrega de programas e/ou projetos: Diz respeito a qualidade, relevância e performance do projeto ou programa desenvolvido.
  • Riscos operacionais e de entrega do serviço: Está associado a todos os aspectos da performance dos serviços e sistemas de TI, envolvendo problemas como a interrupção dos sistemas, problemas de segurança e outras complicações. Pode acarretar na redução ou até mesmo na perda de valores para a empresa.

Dimensões dos riscos em gerenciamento de projetos em TI[editar | editar código-fonte]

O nível de risco em projetos de TI varia de acordo com seu tamanho, complexidade e escopo, entre outros fatores técnicos e organizacionais. De toda forma, esse nível está atrelado à três dimensões do projeto envolvido[5]:

  • Tamanho do projeto: os riscos são diretamente proporcionais ao tamanho do projeto, e crescem junto com o orçamento, tamanho da equipe, tempo de implementação e áreas organizacionais afetadas.
  • Estrutura do projeto: os processos são mais claros, diretos e bem definidos em projetos bem estruturados. Nestes projetos os riscos são menores devido à maior clareza das ações e expectativas geradas pelo projeto por parte dos usuários, o que facilita o comprometimento dos envolvidos e troca de informações.
  • Experiência com tecnologia: os riscos no projeto são inversamente proporcionais ao nível de experiência da equipe envolvida. Aspectos dos projetos de TI como familiaridades com novos equipamentos, programas, sistemas, aplicações, bancos de dados, etc., A quantidade de problemas de implantação de determinada fase de um projeto tende a crescer a medida que sua equipe se envolve com tecnologia (ainda que parcialmente) desconhecida é utilizada e se necessita de tempo para compreensão de seu funcionamento e formação de habilidades específicas.

Metodologias de gerenciamento de risco em TI[editar | editar código-fonte]

Não existem métodos específicos para o gerenciamento de riscos, porém há processos comuns que devem ser seguidos para um gerenciamento eficiente. A NIST 800-30[6] e a ISO 27005:2018[7] descrevem uma série de processo comuns a toda metodologia de gerenciamento de risco, mas que não precisam ser seguidos necessariamente na ordem proposta, porém devem ser aplicados de alguma forma. Alguns dos processos comuns a ambos consistem em:

Estabelecimento do contexto do gerenciamento de riscos[editar | editar código-fonte]

Esse é o primeiro componente do gerenciamento de riscos, aborda a forma como a empresa irá tomar suas decisões baseadas nos riscos. O objetivo desse processo é montar uma estratégia de gerenciamento de risco e definir os critérios que serão adotados pela organização para a avaliação, resposta e monitoramento dos riscos assim como o nível de tolerância dos riscos.

É a base para todos os outros processos no gerenciamento de risco, sendo assim, um estabelecimento de contexto (ou escopo) mal feito pode acarretar na ineficiência da metodologia tomada para o gerenciamento de riscos.

Esta etapa inclui a aquisição de informações para geração de um plano de gerenciamento de riscos, a determinação de critérios de avaliação de riscos assim como de seus impactos, da aceitação de riscos, escopo e limites das atividades e tarefas do projeto e designação de funções e organização interna para gerenciamento e segurança da informação.

Aceitação de riscos[editar | editar código-fonte]

Segundo a Agência Europeia para a Segurança das Redes e da Informação (ENISA), a aceitação de riscos residuais resulta do tratamento de riscos pelos tomadores de decisão nos níveis executivos das organizações[8]. Ao serem aceitos, os riscos são considerados assumidos pela organização, tendo uma relação inversamente proporcional a gestão destes riscos (maiores riscos assumidos equivalem a menores esforços na gestão de riscos). A aceitação de riscos é um processo opcional e pode fazer parte das etapas de tratamento ou comunicação de riscos, porém, ao dedicar uma etapa da avaliação de riscos à aceitação, os gestores de risco trazem aos tomadores de decisão a atenção necessária à um problema ou questão que necessita de cautela diferenciada.

Escopo[editar | editar código-fonte]

Os riscos conexos ao escopo se relacionam com os seguintes aspectos[9]:

  • Objetivos Metas
  • Fases e subfases
  • Tarefas
  • Recursos
  • Orçamento 
  • Prazos

Os riscos inerentes ao escopo incluem, não se limitando a, a responsabilidade e função dos indivíduos no projeto, mudanças nas definições do resultado final, problemas na compreensão das mudanças de escopo por parte da equipe, mudanças das necessidades do projeto, análises das necessidades do projeto insatisfatórias, má observância as prioridades, prazos e orçamento.

As ferramentas e técnicas usadas para identificação de riscos no escopo incluem:

Análise de riscos[editar | editar código-fonte]

A análise de riscos visa identificar os riscos e ameaças e quais seus alcances no projeto, utilizando de métodos qualitativos e quantitativos[10]. O resultado dessa análise auxilia a decisão de quais métodos de controle serão utilizados na nos processos de mitigação. O processo de análise depende de diversas variáveis, as quais dependendo do tamanho e abrangência da organização ou serviço, fica impossível de ser analisado somente por uma pessoa. Na atualidade, com o desenvolvimento da tecnologia, grande parte do processo de análise é automatizado[11], ficando a cargo do sistema analisar os fatores e entregar ao usuário o resultado para que ele possa tomar as devidas decisões. Um dos principais fatores que possibilitam que esse processo se torne cada vez mais automatizado é o desenvolvimento de algoritmos complexos e o crescente uso da inteligência artificial no cenário corporativo.

Estes e outros processos de gerenciamento de risco em T.I tem ganhado destaque, isso porque os processos e rotinas organizacionais estão cada vez mais dependentes de recursos e ferramentas tecnológicas,para que se execute com êxito é necessário o conhecimento dos métodos de gerenciamento do projeto. Sendo assim temos o método tradicional: Abordagem do Livro de Conhecimento em Gerenciamento de Projetos (PMBOK), Abordagem do Projeto em Ambiente Controlado (PRINCE2) e o Abordagem do livro para gerenciamento de projetos e programas para empresas inovação (P2M). método ágil: SCRUM, Gerenciamento ágil de projetos(APM) e o Método de Desenvolvimento de Sistemas Dinâmicos(DSDM)[12].

A avaliação de riscos à segurança da informação abrange três aspectos formais: a identificação, a análise e a estimativa de riscos. A identificação de riscos procura definir possíveis causas de prejuízo, as quais são relacionadas à recursos da empresa, ameaças, controles existentes, vulnerabilidades e suas consequências. A análise de riscos visa estimar de forma qualitativa ou quantitativa os riscos organizacionais relacionados à segurança da informação e envolvem a avaliação das consequências pelo valor dos ativos atingidos, a probabilidade de um incidente através da avaliação de vulnerabilidades e determinação do nível de risco relacionando a probabilidade de um evento e suas consequências. Por último, a estimativa de riscos compara o nível de riscos projetados com os critérios de aceitação de riscos, e auxilia na determinação de prioridades na tomada de decisão da mitigação destes riscos.

Identificação de ameaças[editar | editar código-fonte]

A identificação de ameaças está relacionada a quais ativos dos sistemas de informação uma organização considera críticos. Assim que estes ativos estejam definidos, é possível determinar a quais ameaças ou vulnerabilidades eles estão relacionados. As ameaças aos sistemas de informação e dados podem ser de naturezas diversas[13], ocasionadas por questões ambientais, físicas, de infra-estrutura e suporte ou técnicas.

Ameaças ambientais:

  • Condições climáticas;
  • Alagamentos;
  • Tsunamis;
  • Incêndios;
  • Tempestades e raios;
  • Poeira;
  • Fumaça;
  • Contato com água por meio de vazamentos em encanamentos, telhados, condensação ou ativação de sprinklers;
  • Vibração;
  • Interferências eletromagnéticas.

Ameaças Físicas:

  • Acesso não autorizado;
  • Roubo;
  • Vandalismo;
  • Sabotagem;
  • Terrorismo;
  • Guerra;
  • Transporte inadequado;
  • Ação externa danosa como exposição à chuva ou aparelhos de raios-X;
  • Colisões;
  • Quedas.

Ameaças de Infra-estrutura ou de suporte:

  • Quedas de fornecimento de energia;
  • Falha no controle de temperatura;
  • Falha no controle de umidade;
  • Manutenção inadequada;
  • Falta de pessoal;
  • Falhas no controle de descarte de material.

Ameaças de ordem técnica:

  • Procedimentos inadequados;
  • Operações inadequadas;
  • Configurações de hardware ou software diferentes das recomendadas;
  • Modificações de hardware ou software sem autorização;
  • Cópia de software, dados ou outras informações;
  • Quantidade de acessos superior ao previsto;
  • Classificação de segurança de equipamentos equivocada;
  • Falhas de hardware, software, mídia ou serviços de comunicação;
  • Reutilização de de objetos (como pen-drives ou discos com informações);
  • Modificação acidental de dados (edição, remoção ou inclusão);

O uso por agentes externos ou internos de softwares maliciosos caracteriza um forma especial de ameaça de ordem técnica, com finalidade criminosa[14], que incluem utilização de malwares, vírus, worms, keyloggers, spywares, cavalos de troia, botwares ou denial-of-service, ou ainda taques fraudulentos de spam, scam e phishing.

Identificação de vulnerabilidades[editar | editar código-fonte]

Nos sistemas de informações, vulnerabilidades são falhas nos procedimentos de segurança, de projeto, de implementação ou de controles internos que resultam (de forma acidental ou deliberada) numa brecha de segurança ou violação das políticas de segurança[15][16].

De forma geral, vulnerabilidades não estão unicamente ligadas a fatores tecnológicos, uma vez que podem estar atreladas ao comportamento usuário, fatores sociais diversos ou políticas de autorização ou autenticação para controles de acesso.

As equipes de segurança dos sistemas de informação são responsáveis por identificar vulnerabilidades por meio de fontes de divulgação de vulnerabilidades, testes de vulnerabilidade ou realização de checklists de segurança.

Informações sobre vulnerabilidades podem ser coletadas em diversas fontes, incluindo testes de vulnerabilidades realizados pela organização, relatórios de falhas, anomalias e testes de segurança realizados por empresas especializadas, divulgação por parte dos desenvolvedores de software (incluindo atualizações, hot fixes, patches, service packs, etc.,) e publicações da indústria de TI especializadas em vulnerabilidades.

Testes contra falhas e vulnerabilidades devem fazer parte de uma rotina de verificação de segurança, visto que novas ameaças podem surgir com atualizações de hardware, software ou por descobertas e publicações de novas falhas. Tais testes incluem testes de penetração, avaliação de segurança e uso de ferramentas automatizadas de busca de vulnerabilidades.

Os checklists de segurança resultam do processo de comparação dos controles de segurança (existentes ou planejados para uso futuro) com os requisitos de segurança estipulados pela equipe de TI, contendo os padrões básicos de segurança para avaliação de possíveis vulnerabilidades.

Probabilidade de ocorrência

Relação Probabilidade (Likelihood) x Impacto (Impact).

Será necessário determinar como provável que a ameaça ocorra, com responsabilidade da equipe de gerenciamento de risco.[17]

  • Alta probabilidade - Muito provável que a ameaça ocorra dentro de no próximo ano;
  • Probabilidade média - Possível que a ameaça possa ocorrer durante no próximo ano;
  • Baixa probabilidade - Altamente improvável que a ameaça ocorra durante o próximo ano determinar o impacto da ameaça;

Como consequência custos a longo prazo de qualquer controle é o requisito para manter sua eficácia. Portanto, é necessário fatorar esse custo para o requisito de benefício de qualquer controle. incluindo gastos iniciais com hardware e Programas;Redução na eficácia operacional políticas e procedimentos adicionais para apoiar os novos controles;contratar pessoal adicional ou, no mínimo, treinamento pessoal existente nos novos controles;pessoal de apoio à educação para manter a eficácia do controle.

Nível de impacto

O processo de nível de risco exigirá o uso de uma definição de impacto que permitirá à equipe estabelecer um nível de risco.[17]

  • Impacto - A medida da magnitude da perda ou dano ao valor de um ativo;
  • Alto impacto - Desligamento da unidade de negócios crítica que leva a uma perda significativa de negócios, imagem corporativa ou lucro;
  • Impacto médio - Interrupção abrupta do processo ou sistema crítico;
  • que resulta em um prejuízo financeiro limitado para uma única unidade de negócios;
  • Baixo impacto - Interrupção sem perda financeira;

Monitoramento e revisão de riscos

E necessário entender a importância de incorporar uma cultura de risco dentro da empresa para que se assegure que os objetivos da prática, o contexto interno e externo. o gerenciamento de riscos precisam estar atualizados e precisos e o monitoramento e revisão devem ser uma parte planejada do processo de gerenciamento de riscos e ser feita uma verificação regular. os critérios de avaliação de risco usados também precisam ser revisados para garantir que eles permaneçam relevantes.[18]

Referências

  1. a b Ashwin Pal, "IT Risk Management and Security – Its Business Value and Application", em: CSO. https://www.cso.com.au/article/612808/hitchhiker-guide-it-security-governance-risk-management/
  2. Pedro C. T. Gomes, "GESTÃO DE RISCO EM TI: ENTENDA SUA IMPORTÂNCIA", em: OP Services. https://www.opservices.com.br/gestao-de-risco-em-ti/
  3. TELIUM, "O que é a gestão de riscos em TI?", em: https://telium.com.br/blog/o-que-e-a-gestao-de-riscos-em-ti/
  4. ISACA, "The Risk IT Framework", em: ISACA.ORG. https://www.isaca.org/COBIT/Documents/Risk-IT-Framework_fmk_Eng_0610.pdf
  5. Laudon, Kenneth C., 1944-. Management information systems : managing the digital firm 15th ed., global ed ed. Harlow, England: [s.n.] ISBN 129221175X. OCLC 987341936 
  6. Initiative, Joint Task Force Transformation (17 de setembro de 2012). «Guide for Conducting Risk Assessments» (em inglês) 
  7. «ISO/IEC 27005:2018». International Organization for Standardization. 15 de julho de 2019. Consultado em 12 de julho de 2019 
  8. «Risk Acceptance». www.enisa.europa.eu (em inglês). Consultado em 13 de julho de 2019 
  9. «How to define the scope of a project». CIO. Consultado em 12 de julho de 2019 
  10. Aguinald A. Fernandes, Vladimir F. de Abreu, capítulo: "Modelo de Governança de TI", em: "Implementando a Governança de TI(Editora BRASPORT - 2014)"
  11. Moreira, Esdras, "6 passos no processo de gerenciamento de riscos", em: https://transformacaodigital.com/6-passos-no-processo-de-gerenciamento-de-riscos/"
  12. MELCHER, CHRISTIANE. «PROPOSTA METODOLÓGICA PARA AVALIAÇÕES OTIMIZADAS DE USABILIDADE EM WEBSITES DESENVOLVIDOS COM MÉTODO ÁGIL: UM ESTUDO DE CASO» 
  13. Employment, Small Business and Training (22 de junho de 2012). «What is an information technology risk?». www.business.qld.gov.au (em inglês). Consultado em 13 de julho de 2019 
  14. Hutchings, Alice (3 de novembro de 2017). «Computer security threats faced by small businesses in Australia». Australian Institute of Criminology (em inglês). Consultado em 13 de julho de 2019 
  15. Initiative, Joint Task Force Transformation (17 de setembro de 2012). «Guide for Conducting Risk Assessments» (em inglês) 
  16. Security, Chad Perrin in IT; July 7, in Security on; 2009; Pst, 7:19 Am. «News, Tips, and Advice for Technology Professionals». TechRepublic (em inglês). Consultado em 13 de julho de 2019 
  17. a b Peltier, Thomas R. (2005). Information security risk analysis. [S.l.]: Auerbach Publications. ISBN 0849333466. OCLC 57168595 
  18. «Risk Management Framework - Monitor & Review». survey.charteredaccountantsanz.com. Consultado em 12 de julho de 2019