Modelagem de um incidente

2.2

Modelagem de um incidente

Kumamoto & Henley (1996) alertam que, à primeira vista, as falhas de equipamentos são as causas dominantes dos incidentes – como o de Chernobyl, Challenger ou Three Mile Island. No entanto, uma análise mais cuidadosa poderá revelar que outros fatores contribuíram (ou até determinaram) para sua ocorrência, tais como: erro na operação, no projeto ou na manufatura; problemas de comunicação; falta de clareza na definição de responsabilidades; entre outros.

De fato, a visão de que todo incidente tem um culpado ainda é bastante comum. Esta visão possivelmente tem sua origem no sistema legal, no qual o acusador procura punir o suposto culpado (PARADIES; UNGER, 2000). Hammer & Price (2001), por exemplo, acreditam que a primeira regra escrita para penalidades de um incidente seja o código de Hamurábi, aproxima- damente 1750 a.C.: “Se um construtor fizer uma casa para um homem e não contruí-la com firmeza e a casa colapsar e causar a morte de seu proprietário, o construtor deve ser levado a morte.” (HAMMER; PRICE, 2001, p. 15, tradução nossa).

Atualmente, na maioria dos países, as penalidades são menos severas e não seguem mais a “lei de talião”. Ademais, quando se trata de uma organização, a adoção desta visão possivel- mente irá resultar na punição de alguém que estava trabalhando diretamente no local ou mesmo de um colaborador com falta de sorte – sem se preocupar com fatores organizacionais ou pela interação entre as pessoas, por exemplo. Esta abordagem, a qual procura explicar um incidente por uma única causa, é chamada, no âmbito da segurança no trabalho, de teoria monocausal (CARPES JÚNIOR, 2004). Em contrapartida, as teorias que consideram mais de uma causa são denominadas multicausais.

Observe-se que a base de dados MARS (Major Accident Reporting System database), em maio de 1998, indicou que 64% dos incidentes de grande proporção - ocorridos na União Euro- peia - aconteceram por falha humana, sendo 53% por disfunção organizacional e 11% por erro do operador (LÉGER et al., 2006). Reason (1997) destaca, ainda, que os erros dos operadores

podem ter como causa raiz um problema organizacional, por exemplo, no caso de ele não ter sido adequadamente capacitado.

De acordo com Lima (1985), as teorias multicausais – a exemplo das teorias de Heinrich (1959) e da Tríade Ecológica (LEAVELL; CLARK, 1976) – se consolidaram na década de 60, quando as monocausais se mostraram custosas e insuficientes para explicar a ocorrência de acidentes de trabalho, de forma que se pudessem identificar ações para evitar ou reduzir a chance de aquele incidente ocorrer novamente – ou mitigar suas consequências.

2.2 Modelagem de um incidente 39

várias causas, diretas ou indiretas, formando uma cadeia de eventos que resultam no incidente. Essas causas foram sistematizadas em fatores relativos ao homem, ao ambiente e à máquina (ou ao sistema técnico, em uma visão mais abrangente) – além da interação entre estes fatores, conforme ilustrado na Figura 2.3.

Homem

Ambiente Sistema_técnico

Figura 2.3: Relação entre os envolvidos no sistema da teoria multicausal da ocorrência de in- cidentes

Fonte: Adaptado de Alonço (2004)

É interessante observar que os sistemas técnicos também consideram softwares, além de componentes físicos. Assim, a segurança nesses sistemas está intimamente ligada ao estudo de falhas de software, de componentes físicos, do homem e das perturbações do ambiente.

Existe uma série de outros modelos que procuram representar a ocorrência de um incidente. Leveson (1995) os classifica em 4 tipos: (1) modelos básicos de energia, que considera o inci- dente como resultado de uma liberação de energia indesejada ou fora de controle; (2) modelos de evento único ou dominó, a exemplo do modelo proposto por Heinrich, em 1931, que con- sidera o incidente causado por questões relativas ao ambiente social ou à descendência, que levam a uma falha humana, que é a razão aproximada de uma condição ou ato inseguro, que resulta em um acidente que leva a lesões; (3) modelos de cadeias de eventos, que consideram o incidente resultado de uma série de eventos, normalmente encadeados cronologicamente, a exemplo dos propostos por Mosleh et al. (2004); (4) modelos baseados na teoria dos sistemas, que considera um incidente resultado da interação entre homem, ambiente e sistema técnico que viole as restrições do sistema, a exemplo dos propostos por Leveson et al. (2003).

O modelo proposto por Leveson et al. (2003), denominado STAMP (Systems-Theoretic Accidents Model and Processes), foi apresentado no simpósio internacional do Massachusetts Institute of Technology (MIT / USA), em maio de 2002. Ele se fundamenta na teoria dos sistemas – dos anos 30 e 40 –, que foi uma resposta às limitações das técnicas de análise clássica que não atendiam à crescente complexidade dos sistemas que estavam sendo construídos.

2.2 Modelagem de um incidente 40

inicializador (causa raiz) –, mas por inadequados controles ou restrições relativas à segurança impostas no projeto, no desenvolvimento e no uso do sistema, que não estavam aptos a controlar os distúrbios existentes (LEVESON et al., 2003).

Desta forma, incidentes são vistos pela teoria dos sistemas como resultado de processos defeituosos envolvendo interação entre os componentes dos sistemas, incluindo: pessoas, estru- tura organizacional e social, atividades de engenharia e componentes físicos.

Neste trabalho, será adotado o modelo proposto por Mosleh et al. (2004) – apresentado na Figura 2.4 –, no qual o incidente é resultado de uma condição perigosa aliada a um evento deflagrador, atravessando as barreiras.

+ Consequências Condição per igosa Barreiras Evento gatilho PERIGO Alguns “furos” por falhas ativas

Outros “furos” por condições latentes

Profundidade da defesa Causa ou condição Barreiras Barreiras Incidente Incidente

Figura 2.4: Desencadeamento de um incidente e sua trajetória através de barreiras Fonte: Adaptado de Mosleh et al. (2004) e Reason (1997)

A fim de diminuir a probabilidade de ocorrência do incidente ou, ainda, mitigar suas con- sequências, implementam-se barreiras ao longo da corrente causal. Estas podem ser barreiras físicas, procedimentos, manuais, educação, capacitação, motivação ou qualquer medida que vise atuar na corrente causal evitando o incidente ou minimizando suas consequências.

Um procedimento de manutenção pode atuar para que um sistema não se degrade, tornando- se uma condição perigosa. Uma parede-corta-fogo, por sua vez, visa não permitir que o incêndio se propague, o que minimiza as consequências desse incidente.

2.2 Modelagem de um incidente 41

quer por uma condição latente – podem permitir que o incidente ocorra.

A fim de reduzir o risco de ocorrer o incidente ou mitigar suas consequências, pode-se adotar mais de uma barreira, o que é denominado “defesa em profundidade”.

Outro ponto a se destacar é o tipo de consequência que o incidente provoca. Neste sentido, o Quadro 2.4 apresenta uma proposta de classificação do incidente, ilustrada na Figura 2.5, que é uma adaptação da classificação de falhas apresentada por Smith (2001a).

Quadro 2.4: Classificação de um incidente

Um incidente pode ser classificado como A, B, C, D/A, D/B ou D/C, isto é: A – incidente com comprometimento à segurança;

B – incidente com comprometimento à continuidade;

C – incidente com comprometimento à situação econômica e financeira; D/A – incidente desconhecido com comprometimento à segurança;

D/B – incidente desconhecido com comprometimento à continuidade;

D/C – incidente desconhecido com comprometimento à situação econômica e financeira.

Observe-se que as classificações (A), (B) e (C) não são excludentes. Um incidente pode ter comprometimento à segurança, à continuidade e à situação econômica e financeira da organi- zação. Os incidentes classificados somente como (C) devem ser gerenciados pelos processos cotidianos da organização, enquanto os (A) e (B) devem ser tratados e, quando aceitos, geren- ciados de acordo com os respectivos planos de gerenciamento de incidente.

Quanto aos incidentes desconhecidos (D), e portanto involuntariamente retidos, podem ser gerenciados de acordo com o plano de gerenciamento de crises, conforme proposto em BCI (2005). É importante destacar que uma apólice de seguro pode abranger também os riscos retidos. Assim, deve-se levar em consideração, no gerenciamento de risco, a contratação de seguro.

Note-se que esta classificação não contempla os incidentes com comprometimento à ima- gem da empresa, pois ela pode estar associada a qualquer uma destas classificações, além de depender também de outros fatores, como, por exemplo, a forma que se gerencia o incidente. Para o BCI (2005), um incidente bem gerenciado pode até trazer uma melhora na reputação da organização e da equipe de gestores.

Observe-se que esta taxonomia, apresentada na Figura 2.5, está em consonância com a proposta pela NASA, que apresenta 5 tipos de riscos e suas respectivas consequências (STAMA- TELATOS, 2000):

2.2 Modelagem de um incidente 42

1. relativo à segurança (humana) – consequência: morte, doença, mutilação, etc.; 2. relativo ao meio ambiente – consequência: contaminação, perda de uso, etc.; 3. relativo à programação – consequência: prejuízo à missão, programação, etc.; 4. relativo ao custo – consequência: perdas financeiras;

5. outros ou combinação dos tipos anteriores.

O perfil do incidente é conhecido da organização? Incidente desconhecido. O incidente pode

gerar dano ao homem ou ao meio ambiente? (D) Consequências relativas à segurança. O incidente pode gerar interrupção de processos críticos? Consequências relativas à continuidade. Consequências econômico- financeiras. (A) (B) (C) Sim Não Sim Não Associa (D) às saídas (A), (B) e (C). Sim Não

Figura 2.5: Classificação de incidentes em uma unidade organizacional Fonte: adaptado de Smith (2001a)

É interessante, ainda, distinguir o conceito de segurança relativa a danos (expressa em inglês pelo termo safety) do conceito de segurança relativa a patrimônio e privacidade (expressa em inglês pelo termo security). Leveson (1995) destaca que o último foca principalmente em ações maliciosas – tais como: invasões, vírus de computador, etc. – e enfatiza que os dois conceitos se misturam quando o resultado destas ações maliciosas são considerados danos. No entanto, normalmente eles são tratados separadamente. A norma ISO/IEC Guide 51 “Safety aspects – Guidelines for their inclusion in standards”, por exemplo, trata segurança relativa a dano, enquanto a série ISO/IEC 27000 “Information technology – Security techniques” se atém à