1. Identificar todas as aplicações do seu stack
Uma das grandes coisas que um sandbox pode fazer é fornecer uma análise em todo o stack de aplicativos de uma empresa, que oferece a capacidade de monitorar e detectar os tipos de ameaças exploráveis e tipos de vetor nesse stack. No entanto, a sandbox não pode encontrar todos os exploits possíveis, se ela não tiver uma visão completa de todas as versões de todas as aplicações que constam no stack, disse Arrington.
"Você precisa saber a freqüência de surgimento das aplicações em sua rede. Se eu tiver várias imagens, terminais ou usuários, eu gostaria de ter certeza de que o stack coincide com o usuário em geral na minha comunidade", disse Arrington. Por exemplo, uma empresa pode ter sete aplicações que são comumente usadas pela maioria dos usuários, mas pode haver várias versões de cada aplicativo em uso a qualquer momento, dependendo de atualização e correção dos ciclos. Certas ameaças procuram centrar combinações de versões específicas de aplicações, a fim de obter entrada numa rede ou acesso aos dados.
"Eu posso ter várias imagens, em sistemas XP e Windows 7. Eu estou apoiando essas aplicações com diferentes sistemas operacionais, e esse procedimento pode ser feito com até duas versões anteriores. Digamos que eu tenha o Adobe Reader e Adobe Reader 10.x 11 em uso. A partir daí, eu preciso saber qual desses são vulneráveis nesse stack de aplicativos, se eles estão sendo usados como um vetor para ter acesso a uma outra aplicação, a fim de expor a vulnerabilidade no nível de funcionamento do sistema operacional", disse Arrington.
2. Reproduzir o ambiente do mundo real
Embora o teste virtual torne-se mais útil se os usuários estiverem usando sistemas virtuais e os testes de aplicações a partir de um sandbox virtual apresentem riscos adicionais, os usuários podem não estar usando aplicativos em um ambiente virtual. Isso porque certos tipos de malware podem facilmente identificar um ambiente virtual e responder adequadamente a isso, disse Arrington. "A menos que seus usuários estejam trabalhando em um ambiente virtual no dia-a-dia, o teste virtual não vai funcionar tão bem. Há uma série de laboratórios de malware que submetem amostras a um ambiente virtual, em que 100 por cento dos seus sistemas são físicos. A mensagem não é capaz de replicar o alvo completamente ou o mais próximo possível da realidade."
Expandindo o ponto acima, os usuários devem evitar o uso de aparelhos para simular a atividade de rede. "É como se fosse uma caixa de produção ou de um laboratório de teste. Na sandbox, podem ser colocados os componentes de rede física em torno da arquitetura de rede e usar INetSim, um simulador de rede para configurar hosts DNS específicos, e talvez até um encaminhamento de IP", disse Arrington.
O sandbox físico também pode identificar atribuições de rede ou anomalias, que não seriam capazes de ser identificadas usando um appliance em um ambiente de laboratório malware, acrescentou.
3. Isolando sua rede
Quando uma organização se conecta a vários fornecedores e dispositivos que reúne firewalls corporativos diferentes, é muito mais difícil de controlar o que entra ou sai. Você não pode querer o seu laboratório de malware conectado a outra rede, você pode não querer compartilhar vulnerabilidades ou indicadores de compromisso com outra organização.
A equipe de segurança cibernética deve ter a capacidade de fechar, literalmente, fora da arquitetura da sandbox para o mundo e coletar apenas os dados que significam algo para a organização. "Você não quer que os seus dados sejam empurrados para tecnologia de nuvem de outro fornecedor e muito menos realizar compartilhamento de informações específicas e atributos organizacionais, através de uma comunidade desconhecida sobre a qual você não tem nenhum controle, disse Arrington.
Quando os dados são enviados para a nuvem, não há garantias de que você tenha acesso aos dados ou que você esteja ciente de que se os dados estavam sendo comprometidos, ajuda Arrington. "Essa é uma das causas sobre o por que você não está identificando o problema e por que você não está fazendo uma verdadeira avaliação do que acontece, realmente, nesses computadores. Você não tem uma plataforma para replicar essa pilha de aplicativos para alavancar os ativos de software que estão sendo testados. "Os sistemas virtuais são apenas isso. Eles são representações virtuais de endpoints físicos, que não estão coletando indicadores específicos de compromisso com base no que está sendo mostrado. Se você tiver endpoints físicos, você precisa coletar dados físicos. Você não está repetindo o ataque inicial através de um verdadeiro alvo em um ambiente virtual" .
4. Eliminar falsos positivos
Os analistas de respostas a incidentes podem obter relatórios que têm uma camada de execução limitada, e ainda assim, ter um monte de falsos positivos. Eles possuem amostras que podem ser detonadas e morrer muito rapidamente, porque o meio ambiente não está sob a condição de direito para que o malware possa ser executado. Enviando uma amostra de sandbox para um appliance ou algo com capacidade limitada, você não será capaz de ver o comportamento da rede. A equipe de resposta a incidentes vai precisar de provas para uma tentativa de intrusão ou arquivos ignorados fisicamente.
Além disso, se há um mecanismo de correlação a partir do qual você está alimentando dados para análise de sua arquitetura, elementos-chave não são introduzidos, acrescentou Arrington.
5. Utilizar um ambiente sandbox múltiplo
Se você é uma empresa encarregada de gerenciar sites remotos com múltiplos pontos de entrada, uma sandbox não vai lhe proporcionar uma verdadeira correlação entre os que uma empresa precisa nesse contexto, Arrington disse. Um ambiente multi- sandbox também permite contrastar comportamento. Por exemplo, uma sandbox pode ser usada para whitelists da mesma forma que poderá ser usada para trabalhos em um laboratório de software malicioso.
Saiba Mais:
[1] Net Security http://www.net-security.org/secworld.php?id=15491