Um registo de incidentes na indústria metalomecânica e de manufatura descreve minimamente quatro coisas: o que aconteceu, quais os sistemas afetados, quem interveio e quando a situação voltou ao controlo. Isto parece simples, mas num ambiente de produção existe uma camada adicional: para além da automatização de escritório, existem aqui sistemas operacionais de máquinas, equipamento CNC e linhas de produção que muitas vezes estão nas mesmas redes que a TI de escritório.
Quem se enquadra na obrigação de diligência da NIS2 ou é solicitado por um cliente para demonstrar de forma comprovada como os incidentes são tratados, não pode contentar-se com um ficheiro Excel solto que apenas regista falhas de TI. Uma paragem de produção causada por um servidor encriptado, um armário de comandos que deixa de responder, ou um fornecedor que acede remotamente a uma máquina e inadvertidamente abre acesso: estes são todos eventos que pertencem ao mesmo registo, mesmo que a causa não seja imediatamente clara.
Por que isto é mais do que um ticket no helpdesk
O registo de incidentes é uma das medidas que resultam da obrigação de diligência da Diretiva NIS2, para organizações que são em si mesmas essenciais ou importantes. Para empresas afetadas através de um cliente, é agora também uma questão comum no questionário: como documenta o que aconteceu e pode demonstrá-lo. Uma visão geral de como esta medida se relaciona com as outras obrigações da obrigação de diligência pode ser encontrada na visão geral de todos os tópicos, com uma resposta breve por tema e a localização no texto oficial.
A diferença entre uma empresa que tem isto em ordem e uma que não tem, raramente está na técnica. Reside no hábito de registar algo assim que acontece, em vez de reconstruir retroativamente exatamente o que ocorreu.
Os sistemas de produção requerem uma perspetiva diferente
Um incidente de escritório é relativamente simples: um computador portátil, uma caixa de correio, uma unidade partilhada. Na indústria metalomecânica e de manufatura, os sistemas de produção funcionam muitas vezes durante anos sem que ninguém repare neles, com acesso para o fornecedor da máquina, uma empresa de manutenção ou um prestador de serviços técnico que acompanha remotamente. Isto torna por vezes difícil distinguir entre uma falha e um incidente de segurança no momento em si: uma linha está parada por desgaste, por uma atualização defeituosa, ou porque alguém não autorizado entrou.
É precisamente por isso que é útil ter no registo um campo separado para o tipo de sistema: automatização de escritório, um sistema de produção ligado à rede empresarial, ou um sistema gerido remotamente por um terceiro. Esta classificação ajuda não apenas na análise posterior, mas também em responder à pergunta que um cliente muitas vezes coloca: como é que o seu ambiente de produção está isolado da sua TI de escritório.
O que deve constar minimamente no registo
Um registo útil descreve o momento em que o incidente foi detetado e por quem, uma breve descrição do que foi observado, quais os sistemas ou linhas de produção efetivamente afetados, quais os passos dados para limitar os danos, e o momento em que a situação normal foi restaurada. Isto também inclui uma breve conclusão: foi este um incidente de segurança, uma falha técnica, ou permaneceu incerto qual era a causa. Esta última categoria pode muito bem existir; nem todo o incidente se explica dentro de um dia, e um registo honesto diz-o também assim.
A diferença entre documentar e notificar
Registar é diferente de notificar. As organizações que são essenciais ou importantes sob a Diretiva NIS2 têm uma obrigação de notificação junto à autoridade de supervisão, com prazos estabelecidos na própria lei. Para os prazos precisos e a forma de notificação, referenciamos o texto oficial e a autoridade de supervisão no seu país; intencionalmente, não fazemos uma estimativa aqui. Quem é afetado pela cadeia de fornecimento geralmente não tem uma obrigação legal de notificação, mas frequentemente tem um acordo contratual com o cliente para notificar incidentes dentro de um prazo acordado. Um bom registro é o ponto de partida em ambos os casos: sem documentação, não há nada a que recorrer quando alguém pedir um esclarecimento.
Quem o acompanha na sua empresa
Em muitas empresas de instalação e manufatura, a responsabilidade pelos sistemas de produção recai sobre a liderança de produção, enquanto o responsável de TI se concentra principalmente na automação de escritório. Isso torna importante determinar com antecedência quem é o proprietário do registro de incidentes como um todo, e quem é contactado primeiro em caso de um incidente específico. Um registro mantido em dois sistemas separados, um para TI e outro para produção, causa atraso no momento em que mais importa.
O que a Secria faz e não faz por si
A Secria ajuda a configurar o dossiê no qual este registro tem um lugar permanente, com um estado, um documento de prova e um proprietário por medida, e com textos preparados para quando uma notificação for necessária. O que não fazemos é resolver o próprio incidente: nenhuma resposta a incidentes, nenhum SOC, nenhuma investigação forense. Isso continua sendo trabalho especializado de terceiros, e nós nos preparamos para que, quando chegar a hora, você não comece do zero. Mais sobre como obtemos nossas informações e quais fontes usamos, você lê na página sobre como funciona. O que o dossiê e os modelos custam está na página de preços.
Quer primeiro saber se e como a sua empresa se encaixa exatamente aqui, como entidade essencial ou importante ou como fornecedor afetado pela cadeia? Faça a verificação NIS2 gratuita e veja em poucas perguntas onde você se encontra, ou continue lendo na base de conhecimento para mais contexto sobre este tópico.