Antes de escolher o tópico do diploma, notei que uma situação é generalizada quando, durante ataques de computador, uma pessoa é considerada apenas de um lado - aquele que está sendo atacado como uma vulnerabilidade.
Durante o ataque, todos estão interessados apenas nas ferramentas e ações dos criminosos, e somente depois que tudo aconteceu - quem estava por trás do ataque e quais objetivos eles queriam alcançar.
Anos se passaram (quase seis anos), mas esse tópico ainda não me deixa em paz.
Ao escrever um diploma, ficou claro que superestimei muito minha força e não consegui criar um projeto dessa escala para uma pessoa em seis meses. Pelo menos eu não consegui.
A falta de experiência em sistemas reais também teve um impacto, e algumas decisões de design foram repensadas ao escrever um diploma, mas cheguei a alguns pontos somente depois de anos.
Este artigo é sobre um rascunho do design e as deficiências e perguntas que surgiram durante o processo de design.
Eu ficaria feliz se alguém estivesse interessado neste lado dos ataques de computador e ele pudesse usar minhas modestas conquistas.
E sim, o "hacker" no título do artigo é usado apenas em um significado estritamente definido - um violador da segurança da informação.
Tema do diploma: projetando um sistema para determinar dinamicamente o alvo potencial de um violador da segurança de redes de computadores.
A ideia geral: quando de alguma forma corrigimos um ataque (por exemplo, usando
SIEM ), com base
nesses dados, assumimos o que o invasor deseja fazer no final.
Quando escrevi o diploma, ficou claro que alguns dos pontos do diploma podem e devem ser aprimorados.
Eu já falei sobre parte do meu diploma, ou melhor, sobre um dos problemas que encontrei no processo de redação
aqui . Meu artigo não é o melhor, mas aprendi algo útil para mim nos comentários, graças a todos os comentadores.
Sobre layouts
A primeira coisa que gostaria de chamar a atenção, em primeiro lugar, dos graduados é o layout.
Tudo e constantemente. Ficará claro onde e o que está errado. E se não estiver claro, aprimore suas habilidades. Infelizmente, eu não sou um programador ou desenvolvedor, e com administração eu realmente não. Eu realmente gosto de inventar algo novo ou procurar gargalos nas idéias. Portanto, a prototipagem e a condução do experimento caíram quase inteiramente no meu supervisor de pós-graduação, pelo qual muito obrigado a ela.
Eu não tinha minha própria infraestrutura.
Você pode se unir a alguém e lascar ferro. Pegue, por exemplo, vários laptops, um roteador e neste sistema em miniatura.
Você também pode comprar nos sites de classificados gratuitos antigos, não muito animados, mas o ferro vivo. Às vezes, eles vendem por "1.000 rublos, mas são recolhidos".
Vá direto ao ponto
Por onde começar a prever?
Para entender o que está acontecendo no presente.
O SIEM OSSIM foi responsável por isso. Ao mesmo tempo, o desenvolvedor afirmou que poderia determinar ataques e criar cadeias de ataque CVE. Por isso, fiquei viciado - não preciso determinar os ataques sozinho e posso me concentrar diretamente na determinação do alvo em potencial. Como o SIEM OSSIM define ataques e atribui o CVE não foi muito interessante para mim, para ser sincero. Não faz muito tempo, tentei descobrir, mas não consegui encontrar os detalhes.
Além disso, o
CAPEC poderia ser usado para
previsão . No entanto, eu estava muito mais interessado em usar o CVE / CVSS e o CAPEC. Não prestei muita atenção.
Mas antes disso, cuidaremos de tudo o que amamos - classificação de violadores.
Classificação dos infratores
Eu já levantei esse tópico, mas vamos analisá-lo novamente, apenas rapidamente.
O SIEM coleta um ataque em uma cadeia CVE. No CVE / CVSS, pegamos o vetor AccessComplexity. A segunda versão do CVSS foi usada, então existem três gradações, e não duas, como é agora.
De alguma forma, não é impressionante, é? Será mais interessante ainda. Além disso, este não foi o caso no último artigo.
Segurança da informação é o processo de garantir a disponibilidade, a integridade e a confidencialidade das informações.
Essa é uma das definições geralmente aceitas.
Mas e se classificarmos os infratores por violação dessas propriedades da informação?
Portanto, a seguinte classificação resultou:
“Escoteiro” - seu principal objetivo é divulgar informações sobre o sistema ou obter informações (dados, arquivos, etc.) dele.
"Destruidor" (Destruidor) - seu principal objetivo é interromper o sistema ou seus componentes, até a falha.
"Invasor" - seu principal objetivo é obter controle sobre o sistema ou seus componentes.
Essa distribuição de "papéis" me pareceu há cinco anos como uma boa idéia. No entanto, muita coisa me pareceu uma boa ideia então.
Para classificar os violadores por essas classes, utilizamos o CVE / CVSS ConfImpact ("Impacto na confidencialidade"), IntegImpact ("Impacto na acessibilidade"), AvailImpact ("Impacto na integridade").
Em um vetor, uma influência pode assumir os seguintes valores: nenhuma influência em um recurso (
N ), influência parcial em um recurso (
P ), controle total sobre um recurso (
C ).
Bem, para concluir, apontamos que as classes têm efeitos diferentes no sistema: menos que tudo, “Scout” e, acima de tudo, “Invasor”.
Assim, tendo obtido uma cadeia de ataques do SIEM, podemos classificar o invasor. E já nisso, podemos tirar algumas conclusões sobre os objetivos do violador.
Passando uma cadeia de ataques, um invasor pode apenas aumentar suas habilidades e classe, mas não reduzi-las. Baixo → Médio → Alto e Batedor → Destruidor → Invasor.
A classificação é usada na previsão indireta da intenção do invasor.
Mas classificando os infratores, pode-se assumir o que eles estão buscando.
Talvez possamos dizer que a classificação é o lugar mais funcional do diploma.
Todas essas nuances que me confundem são geralmente descritas em um artigo anterior.
Arquitetura
Vamos primeiro olhar para a arquitetura da solução.
Os principais componentes do subsistema do sistema para determinar dinamicamente o alvo em potencial de um invasor de segurança são três módulos nomeados após as três bruxas escandinavas míticas e nornas que determinam o destino de uma pessoa - Urd, Verdandi e Skuld.
Falando sobre as "feiticeiras escandinavas" em defesa do diploma, eu tinha certeza de que essa é uma ótima idéia e ajudará de alguma forma a "amenizar a situação". Não. Parece que o efeito é o oposto. Mas eu senti isso depois de tudo expresso. Talvez essa abordagem seja adequada se você é orador em algum lugar nos dias de folga, mas não antes da comissão estadual.
No entanto, dar apenas esses nomes aos subsistemas me ajudou a entender como o sistema deveria funcionar.
O sistema é funcionalmente dividido em três subsistemas principais:
- Base de Conhecimento (Urd - Passado);
- Sistema de Coleta de Informações (Verdandi - Presente);
- Sistema de previsão de metas (Skuld - Future).
O lugar central é dado ao DBMS - um banco de dados do servidor incluído na base de conhecimento.
Supunha-se que haveria um tipo de banco de dados global no qual os usuários registrariam e receberiam gráficos de ataque. Eles devem se parecer com isso.
Então, como armazenar gráficos em um banco de dados e trabalhar com eles como gráficos? É simples - existem
bancos de dados gráficos .
Mas foi nesse momento que percebi que não podia fazer isso sozinho e o diploma havia se mudado especificamente para o conceito, em vez de um sistema realmente desenvolvido e funcional.
Eu precisava encontrar no banco de dados SIEM onde os ataques estão armazenados e, em seguida, escrever um analisador que transferisse essas informações para o banco de dados gráfico.
Como a base é preenchida: o SIEM detecta um ataque, me dá CVE, adiciono um novo vértice à base ou, se já existe, aumenta o número de transições entre os vértices em uma unidade. Se o ataque continuar, adiciono um vértice / transição.
Essa abordagem tem vantagens, como:
- autopreenchimento, isto é, não são necessárias etapas adicionais para criar novos gráficos de ataque, já que os próprios atacantes o fazem;
- baixa redundância, ou seja, apenas os gráficos de ataque que os atacantes realmente usam estão no gráfico.
A principal desvantagem da abordagem é que, se um invasor usa um ataque que não foi usado anteriormente, é impossível prever suas ações.
Esse método pode ser aprimorado adicionando gráficos de ataque modelados de outras maneiras ao banco de dados, configurando as transições para "0".
Além disso, esse método usando um banco de dados de gráficos tem duas dificuldades puramente práticas:
- Escreva no banco de dados.
- Leia a partir do banco de dados.
O problema com a gravação é a detecção de ataques. Em que momento você precisa escrever um ataque na base?
Quando o ataque está completo? O ataque pode ser longo. Em que momento você percebe que está completo? De repente, o invasor não possui as habilidades necessárias e deixa de desenvolver um ataque? E se o ataque for concluído, a infraestrutura para enviar dados sobre o ataque poderá não ser mais.
No processo? Escreva todas as transições no CVE? Bem, não é uma má escolha, mas parece-me que também haverá armadilhas aqui.
O problema com a leitura é o volume estimado de árvores que precisam ser retiradas do servidor. Em termos de recursos e lead time, essa operação parece ser um desastre.
Você pode tentar não fazer uma seleção para cada detecção de transição pelo gráfico de ataque (mais sobre isso posteriormente), mas sincronizar o banco de dados inteiro. Mas não consigo nem imaginar quanto a base ocupará naquele momento em que começa a ser digitada com dados reais.
Além do banco de dados do servidor, usei um local, que coletará estatísticas sobre ataques em um sistema específico.
Você também pode dizer que ataques offline não podem ser adicionados ao banco de dados. O phishing e, de fato, toda a engenharia social, passará por nós. Só poderemos determinar até onde o assassino se moveu ao longo da cadeia de assassinatos quando ele já está tentando nos matar.
Magia
Agora resta seguir para o mais importante e interessante. Para previsão.
Algoritmo de Previsão Histórica
Agora parece-me que o "algoritmo estatístico" seria um nome mais adequado. Mas então considerei que é melhor não usar a palavra "estatística" em um diploma.
O algoritmo que foi inventado é provavelmente o mais valioso do meu diploma (novamente, obrigado por escrever no pseudo-código, graças ao meu supervisor de diploma).
1. Obtenha CVE_ID, HOST_ID de um evento de segurança
2. Dgraph = DirectedGraph (CVE_ID)
se DirectedGraph == 0 retornar
3. Set_Edges: = DirectedGraph.getOutEdges (CVE_ID, HOST_ID, DirectedGraph.getRoot ())
4. Set_Edges: = MAX_EXPLOIT_FREQUENCY (SET_EDGES)
Se (SET_EDGES) == retorno nulo
if (SET_EDGES.SIZE ()> 1)
SET_EDGES: = MIN_ACCESS.COMPLEXITY (SET_EDGES)
if (SET_EDGES.SIZE ()> 1)
SET_EDGES: = MIN_IMPACT_GOAL (SET_EDGES)
para cada EDGES ∈ SET_EDGES
edge.Exploit_Probability == ((edge.AttackFrequency) / (1 + ∑edge.AttackFrequency))
5. Vá para o passo 3.
Ao longo dos anos, não é fácil para mim ler esse algoritmo, então vamos ficar um pouco mais simples.
Obtemos o nome do host, CVE-id, do evento de segurança que o SIEM nos fornece e, no banco de dados, selecionamos a subárvore que começa com a vulnerabilidade cujo CVE-id recebemos.
Entre as vulnerabilidades mais próximas, selecionamos uma com a maior frequência de uso.
Se houver várias vulnerabilidades com a mesma frequência, usaremos a que tem menos complexidade de acesso.
Se houver várias vulnerabilidades com a mesma complexidade de acesso, uma vulnerabilidade será tomada com menos impacto no ImpactGoal (da classificação).
Se, neste caso, houver várias vulnerabilidades, essas vulnerabilidades serão consideradas igualmente prováveis e várias maneiras serão usadas para determinar o alvo em potencial.
Para cada vulnerabilidade, a probabilidade de explorar a vulnerabilidade é calculada: a frequência do uso do caminho para a vulnerabilidade que consideramos provável é dividida pela soma das frequências do uso de todas as faces de saída desse nó.
Após concluir essas etapas, analisamos novamente as vulnerabilidades que nos cercam, ou seja, nós contornamos a árvore até o fim.
Visualização do algoritmo de previsão histórica
Temos uma certa base de ataques já formada.
Recebemos o ataque e o primeiro CVE do SIEM.
Vermelho indica vulnerabilidades obtidas no SIEM. Cinza - vulnerabilidades descartadas durante o algoritmo, já que não há mais um caminho para elas. Preto - vulnerabilidades e frequência de uso de caminhos, que ainda são considerados possíveis na árvore de ataque. Laranja - vulnerabilidades e frequência de uso de caminhos, identificadas pelo algoritmo como as mais prováveis.
Nesse caso, obtemos o seguinte CVE potencial pelo número de transições.
Obtenha o próximo CVE do SIEM.
Não adivinhe. Sim, e no estágio seguinte existem apenas dois caminhos e eles têm o mesmo número de transições. Nós olhamos para a complexidade da operação.
Mais uma vez não adivinhou. As transições são as mesmas novamente. Sim, e a complexidade da operação coincidiu. Nós olhamos para os vetores de influência.
Problemas do algoritmo de previsão histórica
Esta é uma abordagem na testa. Não é muito elegante. Mas sem experiência real investigando ataques de computador, esse é o máximo que eu poderia extrair.
Também deve ser mencionado que, na realidade, apenas a condição do número de transições provavelmente será usada, porque a probabilidade de coincidir o número de transições provavelmente é muito pequena.
E também as dificuldades começam com o fato de que, por exemplo, há um ataque do Destruidor e um ataque do Invasor. Eles se cruzam em um CVE. Se mais frequentemente eles seguirem o caminho do Destruidor, o ataque do Invasor depois de mudar para este CVE não será previsto corretamente.
Há mais uma nuance de que, na descrição do algoritmo, foi dito que a probabilidade para o objetivo final é calculada. Mas a fórmula que propus quebrou tanto em tais cruzamentos. O cálculo da probabilidade permanece, mas ficou mais fácil, mas é improvável que funcione corretamente.
E o mais importante, que ... eu, é claro, não sou especialista na investigação de ataques de computador (como já disse mais de uma vez), mas algo me diz que, na realidade, meu banco de dados se pareceria com isso.
I.e. um pouco de caos. E esta é uma opção ainda mais ou menos boa, como me parece.
Esse banco de dados funcionará mais ou menos bem no mesmo host (e até o CVE no software aplicativo pode não ser calculado corretamente). Mas como prever corretamente o movimento do intruso entre as estações? É necessário filtrar o CVE do banco de dados com base em uma auditoria de segurança.
Algoritmo analítico
O objetivo era criar um banco de dados de ataque do CVE usando o CAPEC / CWE. Somente nas transições não haverá informações.
Obtemos o CVE do SIEM, usamos para classificar o invasor e, em seguida, selecionamos no banco de dados do CVE os que mais correspondem à classe e às habilidades do invasor.
Infelizmente, esta é uma das partes menos desenvolvidas do meu diploma.
Resumo do projeto
É difícil avaliar quais recursos são necessários para manter um banco de dados. Pelo menos é difícil para mim.
Existem certas dificuldades tanto na gravação de novos dados no banco de dados quanto no download de dados dele.
O sistema não foi implementado de forma alguma, exceto no papel, mas o experimento teve que ser feito "manualmente". Nem consigo imaginar quanto tempo levaria para implementar algum tipo de demonstração. Provavelmente, se eu tivesse iniciado a implementação enquanto escrevia um diploma, teria terminado.
A classificação dos infratores serve como uma ferramenta adicional na determinação de objetivos.
O próprio sistema pode atuar como uma fonte de dados para alguns
DSS . Por exemplo, se houve tentativas de ataque do invasor e, em seguida, parou abruptamente, o DSS pode recomendar uma auditoria porque o invasor pode atingir seu objetivo.
Além disso, se você aprender a determinar quem faz o ataque, tente determinar os objetivos de um agressor em particular. Você também pode tentar fazer o oposto - diga quem está conduzindo o ataque.
O sistema precisa ser integrado não apenas ao SIEM, mas também aos sistemas de análise de segurança.
O “algoritmo histórico” é uma ferramenta de trabalho com a qual você pode definir objetivos, mas existem muitas ressalvas. Esta não é a solução mais elegante, mas até agora. Precisamos continuar a pensar, a refinar. Ou recuse e use um algoritmo completamente diferente.
O uso do CAPEC tem suas vantagens e desvantagens, mas requer trabalho adicional.
Provavelmente, a mais ofensiva para esse sistema, do ponto de vista conceitual, pode ser se o invasor ... não tiver nenhum objetivo. Ele ganha acesso ao sistema porque simplesmente poderia fazê-lo. Talvez ele não tenha planejado esse truque. E então ele simplesmente não sabe o que fazer a seguir. Ou começa a se comportar como uma raposa em um galinheiro.
O sistema está muito ligado à capacidade do SIEM de detectar ataques, além de determinar qual ataque CVE está sendo usado. Confrontado com um sistema de 0 dias desaparece nos três métodos de previsão. E você tem que viver com isso, mas nunca esqueça.
O sistema permite que você receba informações adicionais sobre o invasor, uma vez que a maioria dos sistemas fornece apenas informações técnicas sobre o ataque, enquanto informações sobre os motivadores, objetivos e nível de habilidade do invasor também são importantes e é o sistema que eu tento obter.
Obrigado pela atenção.