Introdução
Ao fazer uma escolha em favor de se conectar ao SOC, a empresa geralmente considera o provedor como uma “rede de segurança” para lidar com incidentes e ameaças complexas, que seriam potencialmente difíceis de lidar por conta própria. Ao mesmo tempo, muitas vezes acontece que, já em fase de teste piloto de um serviço, surgem gargalos ou falhas críticas na estratégia existente para garantir a estabilidade das informações dos ativos digitais. Por isso, o SOC é uma “jornada” colaborativa onde a empresa e o prestador de serviço caminham lado a lado, complementando-se e ajudando-se em toda a distância.
Figura: 1. Fraquezas comuns da empresa
Temos muitos anos de experiência na garantia da segurança da informação: tanto nossa como de nossos clientes. E queremos compartilhar com nossos leitores. Como parte deste artigo, apresentarei vários casos que foram evitados com sucesso por nosso SOC comercial. Muitas coisas úteis podem ser aprendidas com eles.
Caso 1. "Proxy-regular"
O atendente registrou um ataque de rede do endereço 10.XX250 no host 10.XX70 (YYru)
. Descobriu- se que o software Kerio WinRoute Firewall foi instalado no host 10.XX250. Segundo o responsável pela operação, este software era utilizado exclusivamente como firewall. A varredura do host nos mostrou o seguinte:
A interface da web Kerio está confortavelmente localizada na porta 443:
Fig. 2. Kerio olhando direto para a alma
No entanto, a porta aberta 3128, na qual o proxy http estava sendo executado, não despertou menos interesse. Continuando a verificação, constatou-se que utilizando o proxy 10.XX250: 3128, era possível acessar a Internet sem a necessidade de inserir credenciais. O acesso à Internet foi realizado com IP externo 89.XX18. A varredura do endereço IP externo mostrou disponibilidade:
3128 / tcp - Porta do servidor proxy Kerio WinRoute Firewall.
Para este serviço acabou por ser parcialmente possível utilizar o método Connect:
Resultado: através de um proxy na porta 3128 / tcp, é possível o acesso da Internet à rede interna da empresa.
31415 / TCP - operação do serviço de software
mrelayd github.com/thinkberg/jta/blob/master/tools/mrelayd.c
Mrelayd funciona de forma semelhante ao telnet-proxy. Para especificar o endereço de conexão, é utilizado o método "relay", que é indicado como uma linha como: "relay targethost targetport".
Por exemplo:
Para fazer o proxy de uma conexão ssh neste caso, você pode usar a opção ProxyCommand (openssh) ou as opções de conexão no Putty.
Resumindo: é possível acessar a rede interna, inclusive por meio de protocolos de controle.
Este exemplo ilustra, apesar de sua aparente simplicidade, a importância da configuração correta do servidor proxy em uma empresa. Na verdade, caso contrário, o impacto informativo sobre os ativos digitais internos é possível mesmo na ausência de serviços vulneráveis no perímetro da rede e excluindo variações em ataques com autenticação de força bruta de protocolos de controle remoto.
Caso 2. Um roteador que poderia (na verdade não)
Durante o projeto piloto, a atenção dos especialistas do centro de monitoramento operacional foi atraída pela interface web dos equipamentos de rede acessíveis pela Internet. A senha padrão não funcionou, mas na esperança de uma sorte terrível, foi feita uma tentativa de forçar bruta uma senha de 6 caracteres para a conta do administrador.
Figura: 3. Parece facilmente acessível (usando contas padrão) A
tentativa foi bem-sucedida, permitindo pesquisas adicionais. Na lista de interfaces, entre outras coisas, notou-se um "paciente" do tipo "cliente PPTP", e nas suas configurações foram especificadas cuidadosamente as credenciais para se conectar a um host da rede interna da empresa.
Uma conexão bem-sucedida foi feita com as credenciais encontradas e o endereço IP externo do dispositivo foi determinado
Uma varredura de IP externa mostrou a presença de portas associadas à mineração de criptomoedas (o que é um sinal de um possível comprometimento do sistema). Além disso, o serviço na porta 5000 / tcp atraiu interesse. O malfadado 5000 / tcp hospeda um serviço vulnerável que permite o lançamento de scripts arbitrários.
Exemplo de operação:
Fig. 4. Ping para serviços internos lançados através da interface da Web
. Fig. 5. Saída do arquivo / etc / shadow
Parece que isso é mais do que suficiente, mas como parte de uma verificação posterior, descobriu-se que o serviço de monitoramento em execução Cacti em 79 / tcp usava a senha de acesso padrão.
Figura: 6. Dispositivos sendo monitorados
O fato de acessar o Cacti também nos permitiu obter informações sobre a coleta de logs e a comunidade SNMP:
Este exemplo mais uma vez levanta a questão do já enfadonho problema de usar credenciais para acessar sistemas que não cumprem a política de senhas adotada pelo companhia.
Caso 3. Pentest vs SOC
Cada vez com mais frequência, é uma boa forma para as empresas no âmbito dos testes SOC MTC combinarem um projeto de serviço piloto com uma auditoria regular de sistemas de informação no formato Pentest.
O SOC moderno tem a capacidade de detectar, de acordo com o SLA, os fatos do comprometimento inicial do sistema e outras tentativas de um "invasor" em potencial para se firmar no sistema, aumentar os privilégios e desenvolver um ataque contra hosts já dentro da rede corporativa. Para o efeito, as políticas de auditoria dos sistemas Windows / Unix do cliente e outros sistemas de segurança da informação disponíveis são configuradas em conformidade. Os eventos de segurança coletados são processados com base nas regras de correlação desenvolvidas, o que permite ao analista do SOC detectar e responder com eficácia a possíveis incidentes.
Figura: 7. Para um pentester comum, a primeira rodada de "contra-ação" com o SOC termina muito rapidamente,
depois disso, por meio de concessões, fechando os olhos para a atividade do empreiteiro, os clientes sugerem que os especialistas pentest contratados continuem seu trabalho. Isso reforça mais uma vez a eficácia do SOC - calculamos imediatamente as atividades dos pentesters contratados pela empresa para verificar a segurança da infraestrutura. A questão da eficácia e viabilidade de usar SOC desaparece imediatamente.
Segue abaixo um breve estudo de caso com uma das empresas:
Como você pode ver, todas as ações do "atacante", inclusive o momento de sua conexão inicial à rede, foram identificadas e apresentadas à empresa.
Um comprometimento de conta, o endereço IP de um invasor potencial e o fato de que um pentester instalou serviços maliciosos nos hosts do cliente foram identificados. No caso de um incidente real, todas as informações coletadas seriam mais do que suficientes para responder de forma adequada e proteger os ativos digitais da empresa.
E como conclusão
Gostaria de observar que a descrição de casos reais de SOC, como nada mais, deve permitir que as empresas entendam a importância e a conveniência de usar tal serviço.
A criação competente de coleta de eventos de segurança, sua análise, redação de regras de correlação adequadas para a empresa, enriquecimento de eventos de segurança da informação por meio de plataformas de inteligência cibernética projetadas sobre incidentes reais - permitem entender e avaliar a eficiência futura de conexão com o provedor SOC.
É necessário entender seriamente que certas ferramentas de segurança da informação fornecem proteção contra ameaças privadas, porém, não dão uma imagem completa do que está acontecendo “na fronteira”. O SOC, que reúne pessoas qualificadas, tecnologias inovadoras e processos estruturados, oferece proteção abrangente da organização contra ameaças cibernéticas em tempo real.
Por exemplo, como parte do MTS SOC, concordamos com os clientes sobre a lista final de sistemas de origem conectados e regras de correlação. Junto com a empresa protegida, nos conectamos por meio de um túnel de acesso organizado e fornecido pelo cliente aos sistemas de origem, configuramos uma conexão segura entre eles, o servidor de coleta de registros da empresa e o sistema SOC para transferir registros de sistemas de origem, transferir registros para o servidor de coleta de logs da empresa e deste para o sistema SOC em tempo real.
Figura: 8. Esquema de conexão do cliente ao provedor SOC
A equipe SOC, em conjunto com os funcionários da empresa, adapta as regras de detecção de incidentes de segurança da informação, criação de perfil de rede e atividade do host para minimizar falsos positivos. Recursos adicionais podem ser o controle de vulnerabilidades de perímetro externo e investigação de incidentes de segurança da informação.
Com base nos resultados da investigação dos incidentes, é elaborado um relatório do trabalho realizado. A equipe SOC, além de analisar o incidente e estabelecer o sistema de origem e as causas, forma um conjunto de recomendações técnicas para prevenir ou reduzir a probabilidade de incidentes semelhantes no futuro.
Autores do artigo:
Especialista sênior do MTS SOC Dmitry Berkovets e chefe de produtos de segurança da informação do provedor #CloudMTS Alexander Karpuzikov.
Vagas
Se você quiser se juntar à equipe #CloudMTS, temos novas vagas:
Engenheiro de rede
UI / UX Designer
Golang desenvolvedor
DevOps engenheiro