![[LIVE] CABC - AVALIAÇÃO INICAL NO POLITRAUMA SEGUNDO O ITLS](https://i.ytimg.com/vi/RKuoUFTQL_Q/hqdefault.jpg)
Contente
- Apenas os fatos
- Sem erros, sem estresse - seu guia passo a passo para criar software que muda vidas sem destruir sua vida
- Contabilizando o impacto?
- Hora de mudar o sistema?
Fonte: BrianAJackson / iStockphoto
Leve embora:
É hora de agitar as coisas com a forma como pensamos em avaliar o risco de componentes de código aberto.
Desenvolver um sistema para avaliar quão seriamente a comunidade de desenvolvimento de software deve levar vulnerabilidades é um desafio, para dizer o mínimo. O código é escrito por seres humanos e sempre terá falhas. A questão, então, se assumirmos que nada será perfeito, é como melhor categorizamos os componentes de acordo com o risco de uma maneira que nos permita continuar trabalhando produtivamente?
Apenas os fatos
Embora existam muitas abordagens diferentes para resolver esse problema, cada uma com sua própria justificativa válida, o método mais comum parece basear-se em um modelo quantitativo.
Por um lado, usar uma abordagem quantitativa para julgar a gravidade de uma vulnerabilidade pode ser útil, pois é mais objetivo e mensurável, com base apenas nos fatores relacionados à própria vulnerabilidade.
Essa metodologia analisa que tipo de dano pode ocorrer se a vulnerabilidade for explorada, considerando a ampla utilização do componente, biblioteca ou projeto em todo o setor de software, bem como fatores como que tipo de acesso ele poderia dar ao invasor. eles devem usá-lo para violar seu alvo. Fatores como fácil exploração potencial podem desempenhar um grande papel aqui ao afetar a pontuação. (Para obter mais informações sobre segurança, consulte Segurança cibernética: como novos avanços trazem novas ameaças - e vice-versa.)
Se queremos olhar em um nível macro, a perspectiva quantitativa analisa como uma vulnerabilidade pode prejudicar o rebanho, concentrando-se menos nos danos que podem cair nas empresas que são realmente atingidas pelo ataque.
O National Vulnerability Database (NVD), talvez o banco de dados de vulnerabilidades mais conhecido, adota essa abordagem para as versões 2 e 3, seu Sistema de Pontuação de Vulnerabilidade Comum (CVSS). Em sua página explicando suas métricas para avaliar vulnerabilidades, eles escrevem sobre seu método que:
Seu modelo quantitativo garante uma medição precisa e repetível, permitindo que os usuários vejam as características subjacentes da vulnerabilidade que foram usadas para gerar as pontuações. Portanto, o CVSS é bem adequado como um sistema de medição padrão para indústrias, organizações e governos que precisam de pontuações de impacto de vulnerabilidade precisas e consistentes.
Com base nos fatores quantitativos em jogo, o NVD pode obter uma pontuação de gravidade, ambos com um número em sua escala - 1 a 10, sendo 10 o mais grave -, além de categorias de BAIXO, MÉDIO e ALTO .
Sem erros, sem estresse - seu guia passo a passo para criar software que muda vidas sem destruir sua vida
Você não pode melhorar suas habilidades de programação quando ninguém se importa com a qualidade do software.
Contabilizando o impacto?
No entanto, o NVD parece estar se esforçando para ficar longe do que podemos chamar de mais uma medida qualitativa de uma vulnerabilidade, com base no impacto que uma certa exploração tem causado em causar danos. Para ser justo, eles incorporam o impacto na medida em que medem o impacto da vulnerabilidade no sistema, observando os fatores de confidencialidade, integridade e disponibilidade. Esses são todos os elementos importantes a serem observados - como o vetor de acesso, a complexidade e a autenticação de acesso mais facilmente mensuráveis -, mas eles não têm a tarefa de relacionar o impacto no mundo real quando uma vulnerabilidade causa perdas reais na organização.
Tomemos, por exemplo, a violação do Equifax que expôs as informações de identificação pessoal de cerca de 145 milhões de pessoas, incluindo detalhes de sua carteira de motorista, números de previdência social e outros bits que poderiam ser usados por caracteres inescrupulosos para realizar operações maciças de fraude.
Foi a vulnerabilidade (CVE-2017-5638) que foi descoberta no projeto Apache Struts 2 que a Equifax usou em seu aplicativo da web que permitiu que os atacantes entrassem pela porta da frente e finalmente conseguissem sair com os braços cheios de informações pessoais suculentas .
Enquanto o NVD corretamente atribuiu uma pontuação de gravidade de 10 e HIGH, sua decisão foi devido à avaliação quantitativa de seu dano potencial e não foi afetada pelo dano extensivo que ocorreu posteriormente quando a violação do Equifax se tornou pública.
Isso não é uma supervisão da NVD, mas parte da política declarada.
O NVD fornece "pontuações básicas" do CVSS, que representam as características inatas de cada vulnerabilidade. Atualmente, não fornecemos "pontuações temporais" (métricas que mudam ao longo do tempo devido a eventos externos à vulnerabilidade) ou "pontuações ambientais" (pontuações personalizadas para refletir o impacto da vulnerabilidade em sua organização).
Para os tomadores de decisão, o sistema de medição quantitativa deve importar menos, pois está analisando as chances de espalhar danos por todo o setor. Se você é o CSO de um banco, deve se preocupar com o impacto qualitativo que uma exploração pode ter se for usada para fugir com os dados de seus clientes ou, pior, com o dinheiro deles. (Aprenda sobre os diferentes tipos de vulnerabilidades em As 5 ameaças mais assustadoras da tecnologia.)
Hora de mudar o sistema?
Portanto, a vulnerabilidade no Apache Strusts 2, usada no caso Equifax, deveria receber uma classificação mais alta, considerando a extensão do dano, ou faria com que a mudança se tornasse subjetiva demais para um sistema como o NVD continuar?
Nós garantimos que apresentar os dados necessários para obter uma "pontuação ambiental" ou "pontuação temporal", conforme descrito pelo NVD, seria extremamente difícil, abrindo os gerentes da equipe CVSS livre a críticas intermináveis e uma tonelada de trabalho para o NVD e outros para atualizar seus bancos de dados à medida que novas informações são divulgadas.
Obviamente, existe a pergunta sobre como essa pontuação seria compilada, já que poucas organizações oferecem os dados necessários sobre o impacto de uma violação, a menos que exigido por uma lei de divulgação. Vimos no caso da Uber que as empresas estão dispostas a pagar rapidamente, na esperança de impedir que as informações em torno de uma violação cheguem à imprensa para que não enfrentem uma reação pública.
Talvez o necessário seja um novo sistema que possa incorporar os bons esforços dos bancos de dados de vulnerabilidade e adicionar sua própria pontuação adicional quando as informações estiverem disponíveis.
Por que instigar essa camada extra de pontuação quando a anterior parece ter feito seu trabalho suficientemente bem todos esses anos?
Francamente, tudo se resume à prestação de contas para que as organizações assumam a responsabilidade por seus aplicativos. Em um mundo ideal, todos verificariam as pontuações dos componentes que eles usam em seus produtos antes de adicioná-los ao seu inventário, receberiam alertas quando novas vulnerabilidades forem descobertas em projetos anteriormente considerados seguros e implementariam os patches necessários por conta própria. .
Talvez se houvesse uma lista que mostrasse o quão devastadoras para algumas organizações poderia ser uma organização, as organizações poderiam sentir mais pressão para não serem pegas com componentes de risco. No mínimo, eles podem tomar medidas para fazer um inventário real de quais bibliotecas de código aberto já possuem.
Após o fiasco do Equifax, mais de um executivo de nível C provavelmente estava se esforçando para garantir que eles não tivessem a versão vulnerável do Struts em seus produtos. É lamentável que um incidente dessa magnitude tenha levado a indústria a levar a sério sua segurança de código aberto.
Esperamos que a lição de que as vulnerabilidades nos componentes de código aberto de seus aplicativos possam ter consequências muito reais, afetando a maneira como os tomadores de decisão priorizam a segurança, escolhendo as ferramentas certas para manter os dados de seus produtos e clientes em segurança.