ICS Department

Avaliação de cibersegurança e gestão de vulnerabilidades

em ambientes industriais

Objetivo PÁG. 03

Introdução PÁG. 05

Introdução ao ciclo de vida das vulnerabilidades

Deteção e validaçãoAnálise

Resolução e fecho

Conclusões PÁG. 21

Recursos utilizados PÁG. 23

02www.s21sec.com

Índice |

Processo de gestão de vulnerabilidades PÁG. 07Pág. 08

Pág. 10Pág. 17

Pág. 19

03

Objetivo

Objetivo

04

As implementações habituais de um grande número de sistemas de controlo industrial (ICS) consti-tuem uma janela aberta para a exploração de vulnerabilidades de segurança. Com o cenário de ciber ameaças a evoluir, os sistemas de controlo industrial e a sua arquitetura subjacente devem ser protegidos para resistir adequadamente aos ciberataques aos quais estão expostos. Portanto, é importante definir um método de avaliação e gestão de vulnerabilidades apropriado para sistemas de controlo industrial.

Este documento analisa diferentes metodologias de avaliação de vulnerabilidades de segurança em ICS. Também é proposto um pro-cesso de avaliação e gestão de vulnerabilidades de referência em ICS, construído com base na experiência da equipa de cibersegurança industrial da S21Sec.

05

Introdução

Introdução

06

Os progressos alcançados na última década nas tecnologias de telecomunicações, juntamente com a adição de novas funcionalidades, resultaram na incorporação dos conceitos de IoT e compu-tação em cloud nos ambientes de automação e controlo atuais. Ainda assim, as práticas de imple-mentação dos sistemas ICS / SCADA continuam a abarcar uma ampla variedade de vulnerabilida-des de segurança.

Os ciberataques nos sistemas ICS/SCADA podem ser realizados diretamente da Internet, através de equipamentos ou dispositivos intermediários na rede do cliente que têm acesso físico a um dispositivo de campo (por exemplo, contadores inteligentes), etc.

O impacto desses ciberataques pode causar a interrupção ou dano de operações em infraestrutu-ras críticas ou processos industriais (por exemplo, fabricação em cadeia) e gerar grandes perdas económicas ou mesmo pôr em causa vidas humanas. Por estas razões, os sistemas ICS tornam-se alvos óbvios e prioritários para os atacantes.

Os ciberataques exploram vulnerabilidades de segurança em sistemas SCADA para assumir o con-trolo ou interromper as funções normais do sistema. Nesse sentido, é fundamental identificar e ana-lisar vulnerabilidades e debilidades de segurança nesses sistemas por forma a desenvolver soluções de segurança e mecanismos de proteção.

07

Proteção de gestão de vulnerabilidades

Introdução ao ciclo de vida das vulnerabilidades

08

O surgimento de novas vulnerabilidades é uma constante (e nos últimos anos tem aumentado de forma exponencial), pelo que a sua gestão não deve ser tratada como uma atividade pontual, mas sim contínua ao longo do tempo. Por este motivo, é necessário definir e implementar um processo de gestão de vulnerabilidades que deve cobrir todo o seu ciclo de vida.

Um modelo base de ciclo de vida de vulnerabilidades baseia-se nas seguintes fases:

Deteção e Validação Fase em que as vulnerabilidades presentes nos ativos da organização são identifica-das através de diferentes metodologias de avaliação técnica e da notificação por serviços de terceiros como as próprias notificações de fabricantes ou organizações que relatam avisos de alerta, como o Centro Nacional de Ciber Segurança (CNCS). Nesta fase, é importante não só detetar potenciais vulnerabilidades, mas validar que estas se manifestam nos ativos industriais.

AnáliseFase em que todas as vulnerabilidades identificadas são analisadas para avaliar o risco para a organização. Para isso, será levada em consideração a gravidade da vulnerabilidade e criticidade do ativo afetado. Desta forma, pode estabelecer priori-dades na resolução de vulnerabilidades.

NotificaçãoFase em que as vulnerabilidades são notificadas aos responsáveis pelos ativos.Normalmente, esta fase inclui a sugestão de medidas de mitigação e resolução.

ResoluçãoNesta fase, as vulnerabilidades detetadas são resolvidas. Toma-se como ponto de partida as sugestões de mitigação/resolução feitas no processo de notificação.

Validação e FechoNesta fase, verifica-se se a mitigação/resolução das vulnerabilidades foi realizada de forma correta. Nesse caso, o caso está encerrado.

09

A atribuição de responsabilidades deverá ser realizada indicando as atividades definidas no proces-so de gestão de vulnerabilidades bem como os grupos ou pessoas responsáveis pela sua exe-cução dentro da organização. Seguem-se algumas das responsabilidades mais importantes a serem atribuídas:

Auditor ICS: Responsável por realizar avaliações de segurança nos ativos da organização (dis-positivos, sistemas, aplicações, ...). É necessário que tenha conhecimento e experiência em am-bientes ICS (metodologias, ferramentas, etc.).

Gestor de vulnerabilidades: Responsável por documentar, validar, analisar e avaliar as vulnerabili-dades detetadas e inventariá-las.

Examinador de Vulnerabilidades: Responsável por verificar as resoluções e proceder ao fecho.

Resolutor de vulnerabilidades: Responsável pela gestão interna da resolução de vulnerabili-dades. Deve coordenar as diferentes tarefas necessárias para resolvê-las, considerando a sua classificação, ativos afetados, solução recomendada ou proposta, prioridade, tempo máximo de resolução, ações de mitigação, etc.

As seções seguintes detalham as fases mais críticas do ciclo de vida das vulnerabilidades e os aspetos a considerar no processo de gestão de vulnerabilidades a implementar em cada organização.

Deteção e validação

10

O objetivo de uma avaliação de segurança é detetar ou identificar fraquezas ou quebras de segu-rança que um potencial invasor pode usar para executar ciberataques contra o sistema alvo. É importante não limitar as vulnerabilidades a bugs de software e considerar também configurações fracas, projetos inseguros em aplicações e comunicações, etc. No geral, os resultados da avaliação de segurança fornecem recomendações e diretrizes para melhorias no estado de segurança e me-canismos de proteção para mitigar riscos e evitar possíveis ameaças à segurança.

A avaliação de segurança é um processo fundamental em qualquer programa de segurança da informação. No entanto, avaliar a segurança da infraestrutura crítica ou sistemas de controlo Indus-trial é mais complexo e desafiador do que em sistemas tradicionais de IT. Por exemplo, o uso de enumeração padrão e scanning em sistemas de controlo industrial pode causar falhas com graves consequências no ambiente físico. Portanto, a avaliação da segurança das infraestruturas críticas e sistemas de controlo industrial requer um planeamento e execução cuidadosos.

Talvez o problema mais desafiador na avaliação de segurança em ambientes ICS seja a sua com-plexidade e heterogeneidade. Outro desafio importante está relacionado à vida útil dos aparelhos dos sistemas industriais, já que muitos sistemas herdados coexistem com aparelhos atuais na mesma infraestrutura crítica ou sistema de controlo industrial, e podem estar mais vulneráveis a ciber ataques. Tal acontece porque no momento de sua conceção e implementação, não foi consi-derada nenhuma medida de segurança, entre outras razões, porque os ciber riscos que existem hoje não existiam nesse momento, ou porque estavam fisicamente isolados de outras redes.

O terceiro grande desafio na avaliação de segurança em ambientes ICS é o grande número de vulnerabilidades conhecidas. O enorme volume de vulnerabilidades identificadas e relatadas por fabricantes, instituições de segurança pública e órgãos profissionais nos últimos anos, pode levar a que as organizações se concentrem apenas nas vulnerabilidades mais críticas.

Técnicas e ferramentas de deteção e identificação

Técnicas Passivas Técnicas Ativas Outras fontes de deteção

11

Técnicas e ferramentas de deteção e identificação

As avaliações de segurança em ambientes ICS diferem significativamente das avaliações tradicio-nais em ambientes IT. É imperativo que os membros da equipa que irão realizar a avaliação tenham conhecimento e experiência em ambientes ICS e que estejam cientes das limitações e desafios associados aos testes num ambiente de produção.

Ao detetar/identificar vulnerabilidades em ambientes ICS, deve-se estar muito atento às dimensões de segurança que podem ser impactadas pelos testes de validação. Referimo-nos especificamente à Confidencialidade, Integridade e Disponibilidade, CIA. Para os sistemas de am-biente IT, o objetivo principal é a confidencialidade. No entanto, para ambientes OT os objetivos mais importantes são a disponibilidade e integridade.

As avaliações de segurança podem ser realizadas através de diferentes técnicas sob uma aborda-gem analítica passiva ou ativa.

12

Técnicas passivas

As técnicas passivas apenas observam e recolhem dados e comportamentos, sem comunicação ou interação com os sistemas examinados. Portanto, parecem ser mais adequadas para avaliar a segurança em ambientes ICS reais, uma vez que não são intrusivas.

Uma das técnicas passivas mais utilizadas é a análise do tráfego da rede, que permite identificar ativos, protocolos e fluxos de comunicação, sistema operacional e versões de software das apli-cações, etc. De seguida, apresentamos alguns dos problemas que podem ser identificados na aná-lise do tráfego de rede:

Ativos não inventariados.

comunicações com ativos de redes públicas ou com ativos de redes com as quais não se

deveriam comunicar.

Protocolos de comunicação inseguros

Credenciais de acesso

Informação confidencial ou de processo que não está devidamente protegida.

Infeções de código malicioso

Configurações incorretas.

Vulnerabilidades associadas aos sistemas operativos e

software de aplicações identificados.

Outros problemas que poderão ser identificados a partir da análise do tráfego

de rede.

Ilustração 1

Idealmente, as capturas de tráfego duram várias horas, ou até dias inteiros, e são analisadas através de ferramentas como tcpdump, networkminner, Wirehark, IDS / IPS industrial, etc. Porém, esta opção nem sempre é viável economicamente ou por motivos operacionais, pelo que essas captu-ras devem ser reduzidas a meia hora. Os principais recursos de algumas das ferramentas utilizadas são detalhados de seguida:

Ferramenta de análise de tráfego que permite gerar inventário dos ativos identificados, analisar o tráfego capturado dos decodificadores (já incluídos na própria ferramenta) de diversos protocolos de comuni-cação comum em ambientes de TI e OT, e inspecionar visualmente cada um dos campos individuais que compõem os pacotes. Além disso, permite gerar dados estatísticos do tráfego capturado, como volume de tráfego de entrada e saída por equipamentos e protocolos, fluxos de comunicação entre equipamentos, protocolos usados, etc.

13

Para analisar o tráfego da rede é necessário capturá-lo. Para isso temos diferentes opções:

Aproveitando o facto de que atualmente uma parte muito relevante de muitas infraestrutu-ras industriais adotou redes comutadas baseadas em Ethernet, pode realizar-se um span port (ou port mirror) em cada um dos switches da arquitetura de comunicação que se pre-tende analisar.

Outra alternativa, quando esses switches não têm capacidade de port mirroring ou quando enfrentamos Fieldbus, é o uso de taps de rede, cuja implementação requer interrupção mínima nas comunicações. Existem versões para redes não comutadas, como redes ponto a ponto ou Fieldbus.

Wireshark

Ferramenta para análise forense que permite fazer “sniffing” às redes informáticas e posteriormente apresentar vários tipos de informação como por exemplo: Indicação dos sistemas operativos usados nas má-quinas que estão na rede; Informações sobre as sessões estabelecidas por essas mesmas máquinas; hostnames (nomes das máquinas); portas abertas; Snifing em tempo real; possibilidade de fazer parser a ficheiros .pcapAlém das credenciais, o NetworkMiner permite ainda capturar as frames que são passadas na rede e ainda aceder a algumas infor-NetworkMinner

Ferramenta de análise de tráfego e deteção de anomalias que permite gerar inventário dos ativos identificados, visualizar a comunicação da rede de forma ágil e flexível e estabelecer um perfil de comunicações permitidas e uma inspeção profunda de pacotes de aplicação para protocolos industriais. Além disso, tem recursos para identificar vulne-rabilidades e configurações incorretas de ativos identificados, junta-mente com Indicadores de Compromisso (IoC) comuns de grandes incidentes de cibersegurança industrial.

14

IDS/IPS industriales

Outra das técnicas de análise passiva não intrusiva mais utilizadas consiste na análise das configu-rações dos diferentes ativos que compõem a infraestrutura num formato “white-box” tanto a dispo-sitivos de rede (firewalls, routers, switches), como estações de operação e servidores de supervisão e controlo industriais ou PLCs, RTUs, IEDs, etc. Não é difícil identificar problemas na configuração dos ativos, como sistema operativo, firmware e software de aplicações desatualizado, falta de me-canismos de proteção contra dispositivos removíveis, políticas de passwords fracas, perfis de utili-zadores muito permissivos, falta de registo de eventos de segurança, listas de controlo de acesso relevantes não ajustadas, etc.

Para realizar as revisões de configuração, é necessário extraí-las dos ativos e analisá-las posterior-mente. Caso não possam ser extraídas (por exemplo, sistemas legados, PLCs, RTUs, etc.), será necessário revê-las diretamente no ativo. Em ambos os casos, os dispositivos não são acionados, pois são acessos de leitura. Portanto, a revisão é totalmente passiva e não afeta o seu comporta-mento.

15

Técnicas ativas

As técnicas ativas interagem e comunicam com o sistema analisado para identificar vulnerabilida-des e avaliar o grau de exposição. Portanto, a avaliação de vulnerabilidades ativa deve ser executa-da com precauções extras em sistemas de produção. A abordagem ativa através scans de ativos, por exemplo, pode causar problemas ou exaustão de recursos de rede / CPU, denial of service, reinicializações ou paragens nos sistemas verificados, aumento nos tempos de resposta e outros impactos imprevistos. Portanto, geralmente são realizadas em ambiente de laboratório onde os sistemas ICS são desconectados dos sistemas de produção. Para isso, deve ser feita uma réplica o mais semelhante possível ao sistema de produção a analisar, incluindo os componentes relevantes nas condições reais de operação (ex.simular comunicações com o resto das aplicações e sistemas).

Ambas as fases são realizadas com o apoio de aplicações de software, como port scanning (nmap) e scans de vulnerabilidades (OpenVAS e Nessus), para scanning de endereços IP e deteção de ameaças, juntamente com uma avaliação da sua criticidade e recomendações básicas para a sua resolução.

Posteriormente, serão realizados diferentes penetration tests nos sistemas com base nas vulnerabi-lidades descobertas. Para isso, podem ser usadas diferentes técnicas de exploração de vulnerabili-dades como, por exemplo, ferramentas disponíveis na distribuição Kali Linux (man-in-the-middle, fuzzing de protocolos, engenharia reversa, exploits, etc.).

Por vezes não é possível (ou é muito caro) simular o ambiente produtivo para avaliar. Portanto, pode considerar fazer alguns testes não invasivos diretamente no seu ambiente de produção. Esses testes devem ser mínimos e muito controlados. É um recurso que pode ser utilizado para verificar o uso de senhas padrão, por exemplo, ou para identificar problemas de segregação e segmentação da rede, avaliando as possibilidades de realização de movimentos laterais dentro da rede.

A avaliação de vulnerabilidades através de técnicas ativas consiste basicamente em duas fases:

Descoberta de vulnerabilidades do sistema

Penetration Tests para valiar as vulnerabilidades detetadas e eliminar falsos positivos

16

Outras fontes de deteção

Para complementar as técnicas passivas e ativas mencionadas anteriormente, também é neces-sário identificar os canais oficiais de informação para notificar de forma rápida sobre novos patches, atualizações e ameaças à segu-rança. No gráfico à direita incluem-se alguns de canais.

Além disso, há que ter em conta que os parches e atualizações resolvem vulnerabilidades, mas não todas. Por vezes, a vulnerabili-dade é resolvida através de alte-rações de configuração dos com-ponentes do sistema. Organi-zações como CIS, NIST, SANS facilitam informações e recomen-dações sobre como remediar tais vulnerabilidades (por exemplo, configurações seguras de siste-mas operativos, dispositivos de rede, aplicações, etc.)

Fabricantes de hardware e software (Cisco,

CheckPoint, Fortinet, Palo Alto, Siemens, Schneider,

Honeywell, etc);

https://www.securityfo-cus.com/vulnerabilities

https://www.us-cert.go-v/ics/advisories

https://www.inci-be-cert.es/alerta-tem-

prana/avisos-seguridad

Boletins de notícias de cibersegurança

Twitter

FórunsOutro tipo de canais

Conferências, seminários e eventos de segurança.

Ilustración 2

Análise

17

Para determinar a prioridade de resolução de uma vulnerabilidade, é necessário avaliar o risco que representa para a organização, para isso, deve-se ter em consideração o nível de criticidade dos ativos e a gravidade da vulnerabilidade.

É comum usar matrizes de proba-bilidade e impacto como um método qualitativo para estimar o risco.

Ao avaliar o risco associado às vulnerabilidades que encontra-mos, podemos usar uma matriz semelhante.

Neste sentido, a importância (ou nível de criticidade) do ativo pode ser avaliada com base no impacto que um ciber incidente que afeta a confidencialidade, integridade e / ou disponibilidade do ativo ana-lisado teria na continuidade do negócio; em conjunto com a probabilidade de sofrer o ciber incidente.

Para isso, é prática comum definir níveis de impacto (BIA) para atribuir aos diferentes ativos. (ilus-tração 2)

O risco é normalmente definido como uma função da probabilidade de que um determinado impacto se materialize na organização:

R = P*I

CO

NS

EQU

ÊNC

IAS

PROBABILIDADERaro

Sem Impacto

Leve

Médio

Grave

Gravíssimo

MédiaBaixa Quase certoAlta

Baixo

Baixo

Médio

Médio

Médio

Médio

Médio

Alto Alto Muito alto Muito alto

Muito altoAlto Alto

Alto Alto

Medio

Médio

Médio

Médio

Médio

Médio

Baixo Baixo

Baixo

Ilustração 3. Exemplo de matriz de probabilidade-impacto

Ilustração 4

Médio

Baixo

Muito alto

Crítico

Alto

2

1

4

5

3

18

Por outro lado, a componente de probabilidade de um determinado impacto nas dimensões CIA do ativo pode ser modelada através do conceito de gravidade da vulnerabilidade. A framework Mitre CVE (Common Vulnerabilities and Exposures) permite exatamente isso. A gravidade de cada vulne-rabilidade é pontuada usando o sistema de pontuação CVSS (valor de 1 a 10), que oferece um método padrão e aberto. É composto por três grupos principais de métricas: Base, Temporal e de Ambiente. Cada um desses grupos, por sua vez, é composto de um conjunto de métricas. As métri-cas básicas para o cálculo do referido vetor CVSS são detalhadas de seguida:

Dos dois valores anteriores (criticidade ativa e CVSS), é obtido o valor do risco final das vulnerabilida-des. As duas pontuações são cruzadas numa tabela como a seguinte (ou semelhante):

Este valor de risco final deve marcar a prioridade da resolução das vulnerabilidades identificadas pelo ativo.

Vetor de ataque (AV)

Complexidade do Ataque (AC)

Privilégios necessários (PR)

Interação do utilizador (UI)

Âmbito (S)

Impacto na Integridade (I)

Impacto na Disponibilidade (A)

Impacto na confidencialidade (C)

CVSS v3Criticidade ativo

Baixa 1

2

3

4

5

1

1

2

2

3

1

1

2

3

4

1

2

3

4

5

2

3

4

5

6

Média

Alta

Muito alta

Crítica

3

4

5

6

7

4

5

6

7

8

5

6

7

8

9

6

7

8

9

10

7

8

9

10

10

8

9

10

10

10

1 2 3 4 5 6 7 8 9 10

CVSS v3Criticidade ativo

Baixa 1

2

3

4

5

0

0

1

1

1

0

1

1

2

2

1

1

2

2

3

1

2

2

3

4

Média

Alta

Muito alta

Crítica

1

2

3

4

5

1

2

4

5

6

1

3

4

6

7

2

3

5

6

8

2

4

5

7

9

2

4

6

8

10

1 2 3 4 5 6 7 8 9 10

Figura 5

Figura 6

Resolução e Fecho

19

Dentro do processo de gestão de vulnerabilidades identificadas, devem ser considerados diferentes métodos de resolução a aplicar dependendo da sua classificação e da infraestrutura da organização. Abaixo enumeram-se alguns métodos de resolução a considerar:

Além disso, deve ser associado um tempo máximo de resolução à vulnerabilidade, tendo em con-sideração a sua prioridade.

RESOLUÇÃO DEFINITIVA

Aplicar a resolução proposta pelo fabricante

MITIGAÇÃO

Aplicar uma solução (workaround) que mini-mize a possibilidade de exploração da vulne-rabilidade mediante contramedidas compen-satórias que o impeçam, como por exemplo soluções de segurança (Firewall, IPS/IDS, Virtual Patching, EDR, EPP, etc)

ACEITAÇÃO DO RISCO

Assumir a vulnerabilidade como um risco aceitável devido à sua baixa pontuação ou como um risco inevitável devido a condições externas que impedem a sua resolução (por exemplo, vulnerabilidades cuja resolução requer atualização para uma versão superior do sistema operativo, mas as aplicações ou componentes dos fabricantes não suportam a nova versão).

TRANSFERÊNCIA DE RISCO DA VULNERABILIDADE

Através de cláusulas contratuais que obrigam os fabricantes a assumirem multas por não poderem fornecer mitigação ou resolução de vulnerabilidades. Outra opção é fazer uso do ciber seguro.

É aconselhável atribuir uma data de deteção, atribuição, resolução, etc., aos diferentes estados do ciclo de vida pelos quais uma vulnerabilidade pode passar.

Por último, é importante frisar que antes de solucionar as vulnerabilidades no ambiente operacio-nal, deve ser realizada uma fase de estudo, análise e teste para verificar a viabilidade das possíveis resoluções a aplicar. O teste deve ser feito em ambientes não produtivos, como por exemplo. ex. ambientes de pré-produção, laboratórios, dispositivos isolados, etc. Além disso, os testes devem ser devidamente documentados, bem como o processo reverso a ser realizado caso as resoluções aplicadas causem erros e incidentes colaterais.

20

Segue abaixo uma proposta para am-bientes de automação e controlo, nos quais qualquer intervenção deve ser cuidadosamente planeada (Figu-ra 7).

É uma boa prática atribuir um status que reflita o momento no qual se encontra a vulnerabilidade ao longo de seu ciclo de vida. Abaixo apresentamos uma proposta (Figura 8)

RESOLUÇÃO PRIORIDADETEMPO DE

RESOLUÇÃO

Urgente

Alta

Média

Baixa

Muito baixa

Crítica

Muito alta

Alta

Média

Baixa

2 - 4 meses

4 - 8 meses

8 - 16 meses

16 - 24 meses

> 24 meses

ESTADO DESCRIÇÃO

Detetada

Assignada

Em resolução

Resolvida

Mitigada

Vulnerabilidade detetada, mas ainda não reportada à equipa de resolução.

Vulnerabilidade notificada e assignada à equipa de resolução, mas ainda não começou a sua resolução.

Vulnerabilidade em resolução por parte da equipa responsável.

Vulnerabilidade resolvida com a aplicação da resolução por parte da equipa responsável

Vulnerabilidade resolvida através de um patch virtual, uma medida compensatória

Falso positivo

Aceite

Fechada

Vulnerabilidade descartada quando se comprova que não se aplica ao ativo afetado

Vulnerabilidade não resolvida, assume-se o seu risco

Vulnerabilidade fechada e resolução verificada pelo examinador de vulne-rabilidades

Figura 7

Figura 8

21

Conclusões

Conclusões

22

A crescente interconexão de redes ICS e redes IT, o uso de tecnologias padrão (por exemplo, Ethernet, TCP / IP, sistemas operativos Windows, etc.), expõe os sistemas de automação e con-trolo a uma ampla variedade de vulnerabilidades e ameaças à segurança. Um ataque a um sistema industrial pode ter consequências catastróficas ao nível económico e nos serviços essenciais dos países. Portanto, a análise de segurança e o planeamento de contra-medidas é essencial e obrigatório.

Ao longo do documento, foram expostas as diferentes fases que um processo de gestão de vulne-rabilidades deve incluir. Embora todas as fases sejam importantes, uma vez que deve ser coberto o ciclo de vida completo das vulnerabilidades, foi colocado um foco especial na fase de deteção, nomeadamente nas diferentes técnicas e ferramentas de deteção e identificação utilizadas. Esta é uma das fases em que há maior diferença em relação à área de IT.

A gestão adequada de vulnerabilidades ICS ajuda a identificar e avaliar vulnerabilidades e planear com eficácia a implementação de medidas que permitem proteção contra prováveis cenários de ataque.

Uma gestão de vulnerabilidades em ICS adequada implica uma deteção minimamente intrusiva de vulnerabilidades em operações e processos industriais. Essas tarefas são essenciais para proteger o sistema contra ciber ataques. No entanto, devido à escala e complexidade dos sistemas ICS, bem como às tecnologias de comunicação associadas ao planeamento, execução e revisão de ava-liações de vulnerabilidades físicas e ciber, são mais difíceis de realizar do que em sistemas IT.

23

Recursos utilizados

Recursos utilizados

24

“Guide to Industrial Control Systems (ICS) Security” - NISThttps://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-82r2.pdf

“Technical Guide to Information Security Testing and Assessment“ – NISThttps://csrc.nist.gov/publications/detail/sp/800-115/final

“Implementing a Vulnerability Management Process” - SANS Institutehttps://www.sans.org/reading-room/whitepapers/threats/imple-menting-vulnerability-management-process-34180

“A Practical Methodology for Implementing a Patchmanagement Process” - SANS Institutehttps://www.sans.org/reading-room/whitepapers/bestprac/practi-cal-methodology-implementing-patch-management-process-1206

“ICS Vulnerabilities Thermometer” – CCI (Centro de Ciberseguridad Industrial)https://www.cci-es.org/documents/10694/1105457/CCI+-+ICS+Vul-nerabilities-EN.pdf/60de3914-e07e-4d2a-9d08-f10a203b87b5

“Cyber Resilience Review (CRR) – Vulnerability Management” - US CERThttps://www.us-cert.gov/sites/default/files/c3vp/crr_resour-ces_guides/CRR_Resource_Guide-VM.pdf

“A Review of Security Assessment Methodologies in Industrial Control Systems” – Research Gatehttps://www.researchgate.net/publication/283568912_A_Review_o-f_cyber_security_risk_assessment_methods_for_SCADA_systems

“Cyber Security Assessments of Industrial Control Systems” – CPNIhttps://www.ccn-cert.cni.es/publico/InfraestructurasCriticaspublico/CPNI-Guia-SCI.pdf

“Industrial Control Systems Vulnerabilities Statistics” – Kasperskyhttps://media.kasperskycontenthub.com/wp-content/uploads/si-tes/43/2016/07/07190426/KL_REPORT_ICS_Statistic_vulnerabilities.pdf

“Common Cybersecurity Vulnerabilities in Industrial Control Systems” – Homeland Securityhttps://www.us-cert.gov/sites/default/files/recommended_prac-tices/DHS_Common_Cybersecurity_Vulnerabilities_ICS_2010.pdf

“Dragos 2019 ICS Year in Review: ICS Vulnerabilities” – Dragoshttps://www.dragos.com/resource/dragos-2019-ics-year-in-review-ics-vulnerabilities/

“Controles de seguridad de la información” - ISO/IEC 27002:2013

“Common Vulnerabilities and Exposures (CVE)” – MITREhttps://cve.mitre.org/cve/identifiers/index.html

www.s21sec.com | 902 020 222 | marketing@s21sec.com