Red Team vs Blue Team? O que isso quer dizer na segurança da informação?

team_blue_vs_team_red_logo

No mundo da segurança cibernética, estar um passo a frente dos possíveis atacantes à nossa infraestrutura pode ser o que definirá as nossas chances de sucesso na reação quando um ataque surgir, e para tanto muitas empresas utilizam táticas de simulação para a realização de testes quanto a capacidade de resposta a incidentes de segurança.

Um exemplo desse tipo de procedimento envolve utilizar grupos de profissionais de TI, divididos em times, e que objetivam atacar ou defender a infraestrutura das empresas envolvidas para tentar evidenciar pontos fracos e fortes de suas soluções de proteção de dados.

Nesse tipo de verificação, a equipe responsável pelo ataque deve valer-se de sua expertise para tentar atingir um objetivo definido pela alta direção, realizando sofisticados testes de penetração e buscando pontos de falha nos processos, pessoas e tecnologias que compõem as defesas atualmente em uso na empresa para o cumprimento da missão. Essa equipe é apelidada de Red Team.

Neste cenário, o Red Team agiria como uma ameaça externa, que buscaria localizar quaisquer vulnerabilidades possíveis de serem exploradas, objetivando, por exemplo, extrair dados da localidade predeterminada pela alta direção. Idealmente este time deve ser composto por profissionais que não tenham contribuído, ou contribuam, para a estratégia de defesa atualmente aplicada na empresa, pois isto poderia gerar um conflito de interesses a partir da atitude de não querer buscar realmente, ou mesmo expor, as fraquezas disponíveis na infraestrutura da corporação, e que não foram cobertas pelas defesas que ajudaram a implantar.

O foco em realmente “quebrar” a segurança implantada deve dirigir a vontade do Red Team na busca por brechas de segurança, o que pode envolver as mais diversas táticas, desde a utilização de ataques spear phishing até mesmo a simples pendrives infectados e deixados nos arredores da empresa.

Em contrapartida, a equipe responsável por defender essa infraestrutura, apelidada de Blue Team, deve buscar identificar através de logs, monitoramento de ativos, tráfego de dados, comportamento anômalo, entre outros recursos, os possíveis vetores de acesso que o time ofensivo utilizará para tentar obter êxito na invasão, buscando frustrar os planos de de acesso e extração de dados. Esse time é geralmente formado pela equipe de resposta e tratamento de incidentes apoiada pelo centro de operações de segurança.

O desenvolvimento deste tipo de atividade permite a realização de testes controlados de invasão, bem como da efetividade dos procedimentos utilizados, e do treinamento das equipes para a proteção do ambiente corporativo, pois através dos relatórios de ação e reação, de cada uma das equipes, é possível identificar pontos fortes e fracos na estratégia de defesa, permitindo a antecipação do que poderia vir a ser uma exploração real de vulnerabilidades na infraestrutura, além dos ajustes necessários para uma proteção mais eficiente.

É recomendável, sempre que possível, a realização periódica destes tipos de testes, bem como a revisão dos procedimentos previstos para os casos de incidentes de segurança, a atualização de conhecimento das equipes sobre os diversos tipos de ataques, além  do constante treinamento e aperfeiçoamento de técnicas e ferramentas disponíveis, buscando sempre a elevação dos níveis de segurança no ambiente corporativo.

Anúncios

Dirty Cow na Slackware Linux?

dirty_cow

Essa era uma dúvida que também me deixava com aquela coceirinha no cérebro, afinal a vulnerabilidade Dirty Cow é um dos assuntos mais comentados no campo da segurança em sistemas GNU/Linux, já que várias versões do kernel Linux se mostraram afetadas, porém alguns distribuidores começaram a disponibilizar pacotes com atualizações para a correção de suas respectivas distribuições, podendo ser citadas aqui a Red Hat, CentOS, Ubuntu, Debian, entre outras, por exemplo.

A busca sobre as versões afetadas ainda retornam informações confusas, mas como pode ser visto no site do CERT, a vulnerabilidade aparentemente afeta a grande maioria das versões do kernel Linux posteriores à versão 2.6.22, mas já corrigida nas versões 4.8.3, 4.7.9 e 4.4.26.

A mesma página que nos trás essas informações, oferece uma lista de distribuições onde consta, ao lado de cada uma, os seus respectivos status com relação à vulnerabilidade. Até o momento em que escrevo esse artigo, a Slackware Linux aparece na lista com status de “desconhecido” para a presença da vulnerabilidade.

Acessando a página oficial da Slackware, vemos que até o momento não há alertas de segurança para a vulnerabilidade, e a mais recente atualização nesse sentido foi em primeiro de outubro, relativa ao Mozilla Thunderbird.

Sabemos que o kernel Linux mais recente, disponibilizado até o momento na distribuição, é a versão de número 4.4.23, liberada também no dia primeiro de outubro, inclusive na árvore current, e que não consta entre as versões imunes, mas que devido a não existir confirmação de ser afetada nos perguntamos, o que fazer? Bem, temos algumas opções:

  • Aguardar o comunicado oficial dos mantenedores da distro, para então saber se há necessidade ou não de atualização, mas correndo o risco de ter a segurança de nossos sistemas comprometidos;
  • Baixar e aplicar o patch de atualização, alterando a versão atual para a qual é sabido não ser vulnerável, que é a 4.4.26;
  • Ou aproveitar a deixa e atualizar o kernel para a versão estável mais recente, que é a 4.8.4, e que também atende à nossa necessidade.

Já que de qualquer forma seria necessário reiniciar o equipamento, para que o kernel da versão corrigida passasse a ser utilizado no lugar do anterior, escolhi a última das três opções, atualizando para a versão estável mais recente no momento.

Compilando e instalando um novo kernel

O procedimento não é muito complicado, mas pode deixar o sistema inoperante caso seja conduzido de forma errada, portanto, caso queira realizá-lo, pode seguir os passos que realizei, porém por sua conta e risco.

De qualquer maneira, o recomendado é manter os backups sempre atualizados com os dados que deseja reter, facilitando a recuperação em caso de necessidade. Vai continuar? Então siga em frente!

Primeiramente verifique a versão do seu sistema:

# uname -a

Ou apenas:

# uname -m

Veja se aparecerá a informação de que é um kernel x86_64, para o caso de ser 64 bits, ou mesmo i686 ou x86 para versões de 32 bits.

Baixe o kernel Linux estável mais recente a partir do site The Linux Kernel Archives:

# wget https://cdn.kernel.org/pub/linux/kernel/v4.x/linux-4.8.4.tar.xz

Mova o arquivo para a pasta do sistema onde fica o código fonte do kernel:

# mv linux-4.8.4.tar.xz /usr/src/

Vá para a pasta onde o mesmo foi movido e o descompacte:

# cd /usr/src/

# xz -d linux-4.8.4.tar.xz

# tar -xvf linux-4.8.4.tar

Remova o link simbólico existente:

# rm linux

Crie um link simbólico para o diretório com o novo código fonte do kernel:

# ln -s linux-4.8.4 linux

Acesse o diretório onde o conteúdo do arquivo foi descompactado:

# cd linux

A partir dele, temos algumas opções de configuração do novo kernel mas, primeiramente, só para o caso de não ser a primeira vez que um kernel é compilado em seu sistema, o ideal é “limpar” os arquivos anteriores, porém preservando a configuração, utilizando o comando a seguir:

# make clean

Agora, para evitar muita demora e maiores erros na hora de configurar o novo kernel, utilize a opção de comando de configuração que aproveita a configuração anterior e apenas questiona sobre as novas funcionalidades:

# make oldconfig

Com esse comando todas as configurações anteriormente selecionadas pelo time de desenvolvedores é preservada, e as perguntas sobre as novas funcionalidades também tem as respostas padrão previamente selecionadas. Caso não queira realizar modificações, basta manter a tecla enter pressionada e todas as opções padrão serão escolhidas durante a apresentação das perguntas.

No meu caso, a versão instalada é de 32 bits, portanto a primeira pergunta foi se eu desejava compilar um kernel de 64 bits, opção que deixei desmarcada. Outra pergunta era referente à compressão a ser usada, à qual escolhi a opção bzimage. Para o restante mantive as respostas padrão para as perguntas. Tão logo elas terminem, o arquivo com a configuração do novo kernel estará pronto.

Agora compile o kernel:

# make bzImage

Tenha atenção para a letra I maiúscula. Ela deve ser digitada desta forma mesmo.

Caso seu sistema possua mais de um processador, é possível acelerar esse processo dividindo a carga da compilação entre eles, por exemplo, para um sistema com 6 processadores você poderá usar o comando acima com a opção -j <nº de processadores>, o que conforme o exemplo sugerido seria:

# make -j6 bzImage

Tão logo o processo de compilação seja concluído, você pode compilar os módulos:

# make modules

Esse processo é bem mais rápido, e tão logo seja concluído você já poderá instalá-los:

# make modules_install

Agora é preciso mover a imagem do kernel compilado para a pasta à qual se destina, em /boot. Geralmente esta imagem tem o nome de vmlinuz, portanto ao mover a nova imagem, renomei-a de forma diferente, assim como fiz no exemplo abaixo. Isso facilitará sua vida nos passos seguintes:

# mv arch/x86/boot/bzImage /boot/vmlinuz-4.8.4-x86

Módulos instalados, e imagem no lugar, agora deve alterar o bootloader para que receba o novo kernel como opção de carregamento. É aqui que entra a facilidade citada anteriormente, pois caso simplesmente substituíssimos a imagem anterior pela nova, e algo desse errado, teríamos mais trabalho para restabelecer o sistema, ao passo de que agora só precisamos escolher o kernel que queremos carregar.

Para editar o lilo, acesse seu arquivo de configuração em /etc, como no exemplo abaixo:

# vi /etc/lilo.conf

Altere o conteúdo do arquivo, adaptando-o para a partição correspondente em seu sistema. As últimas linhas do arquivo anteriormente eram assim:

# Linux bootable partition config begins
image = /boot/vmlinuz
  root = /dev/sda2
  label = Linux
  read-only
# Linux bootable partition config ends

Agora ficaram assim:

# Linux bootable partition config begins
image = /boot/vmlinuz-4.8.4-x86
   root = /dev/sda2
   label = Slackware_4.8.4
   read-only

image = /boot/vmlinuz
  root = /dev/sda2
  label = Linux
  read-only
# Linux bootable partition config ends

Isso insere a opção de carregamento do novo kernel. Salve o arquivo e saia. Agora execute a gravação da nova configuração na MBR:

# lilo

Feito isso, basta reiniciar o sistema e escolher a opção no menu de inicialização que corresponde ao nome que definiu para o carregamento do novo kernel, verificando se o mesmo será carregado normalmente.

Caso o procedimento não funcione, ainda poderá carregar o sistema através da opção existente anteriormente e tentar realizar o procedimento novamente para ver onde pode ter ocorrido algo errado.

Se tudo correer bem ao final do carregamento do sistema, você pode confirmar a versão em uso através do terminal novamente com o comando uname, verá algo parecido com o exemplo a seguir:

# uname -r

4.8.4

Também é recomendável adicionar os pacotes referentes ao kernel à blacklist, evitando que o mesmo seja sobrescrito quando utilizar o slackpkg para realizar alterações no sistema:

# vi /etc/slackpkg/blacklist

kernel-generic
kernel-generic-smp
kernel-huge
kernel-huge-smp
kernel-modules
kernel-modules-smp

Salve o arquivo e saia. Replique o procedimento em todos os seus sistemas, e aplique as atualizações disponíveis para aqueles que não sejam Slackware Linux.

Como tudo funcionou por aqui, agora já sabe porque a dúvida não me perturba mais e, caso tenha realizado os procedimentos acima com sucesso, também pode voltar à tranquilidade pois a vulnerabilidade não afeta mais o seu ambiente.

Quando se sentir mais a vontade para explorar as opções disponíveis para a configuração do kernel, você poderá realizar o processo novamente, mas agora verificando as especificações do seu equipamento e desmarcando as opções que não se encaixam, como por exemplo drivers de rede que não sejam os que dispõe, sistemas de arquivos com os quais não lida, entre outros, deixando assim o núcleo do sistema mais enxuto e rápido.

Se a cada procedimento tomar o cuidado de adicionar a nova imagem com um nome diferente no diretório /boot, além de mais uma seção ao lilo, poderá sempre carregar o kernel anterior em caso de remover alguma funcionalidade essencial do sistema e, caso tudo dê certo, remover a entrada para o kernel anterior, bem como a sua imagem do diretório de inicialização.

Espero ter ajudado e até a próxima!

Cansados do assunto segurança da informação?

cansado

Olá pessoal! Hoje venho falar sobre os resultados de uma pesquisa realizada em conjunto a profissionais do National Institute of Standards and Technology (NIST), e divulgada pela IEEE Computer Society, na qual foi apontada que o excesso de notícias e alertas sobre segurança da informação tem levado os usuários a uma “fadiga de segurança”, o que por sua vez tem feito os usuários tomarem decisões ruins relacionadas ao tema.

Embora o relatório tenha sido divulgado apenas no dia 04 deste mês, a pesquisa foi conduzida entre os meses de janeiro e março de 2011, entrevistando diversos participantes, incluindo homens e mulheres de algumas partes dos Estados Unidos, onde foram incentivados a falar sobre como se sentiam em relação ao tema segurança da informação.

Estes foram questionados a respeito de atividades realizadas online, percepção de segurança da informação, além do conhecimento e uso de ícones de segurança, ferramentas e terminologias associadas ao tema. A partir disso, técnicas de dados qualitativos foram utilizadas para codificar e analizar os resultados em busca de sintomas, fatores contribuintes, e efeitos relacionados a fadiga de segurança da informação.

Mesmo que a fadiga não tenha sido envolvida diretamente nos protocolos da pesquisa, mais da metade dos entrevistados apresentaram sintomas referentes a ela em suas respostas, onde expressaram resignação, perda de controle, fatalismo, minimização de riscos, e até mesmo indicaram evitar tomar decisões relativas ao tema segurança.

Algumas das respostas oferecidas pelos entrevistados podem ser vistas em um vídeo, onde uma das Cientistas da Computação que realizaram a pesquisa, e que trabalha atualmente para o NIST, Mary Frances Theofanos, explica o que é a fadiga de segurança da informação. Veja algumas das afirmações feitas por participantes:

“Segurança parece ser algo meio incômodo, é só mais uma coisa que devemos ter e nos manter atualizados”.

“Acho que estou meio insensível a ela… as pessoas se cansam de ser bombardeadas com ‘cuidado com isso’,’cuidado com aquilo’ “.

É quase compreensível que tenham esse tipo de reação, levados é claro pelo número cada vez mais frequente de notícias envolvendo quebras de segurança, tanto no setor privado quanto governamental, porém é possível minimizar esse tipo de sentimento se seguirmos alguns conselhos oferecidos pela própria pesquisadora.

Limitar o número de decisões do usuário quando estas forem relacionadas a segurança da informação. Quanto maior a quantidade de decisões que se deve tomar durante um dia, mais difíceis elas se tornam. A partir do suporte oferecido, podemos indicar quais seriam as melhores soluções a serem empregadas em determinada situação, para resolver uma determinada dificuldade relacionada ao tema, minimizando assim a necessidade de preocupação por parte dos usuários na busca pela resolução da mesma.

Desenvolvedores de sistemas participam dessa ação ao criarem códigos seguros a despeito da experiência do usuário. A segurança dos sistemas não pode ser minimizada para melhorar o seu contato com os usuários. Estes sistemas devem ser idealizados para limitar os riscos de exploração, aleḿ de reforçar os princípios de uma autenticação forte e segura.

Tornar simples para o usuário tomar a decisão certa relativa ao assunto segurança. Não devemos simplesmente impor ao usuário, através de nossas políticas de segurança, que este tenha uma senha com determinada quantidade de caracteres, seguindo uma determinada combinação, e que esta seja trocada a cada período determinado, sem oferecer-lhes formas seguras de criar e armazenar estas senhas, como um chaveiro digital por exemplo.

O usuário deve ser guiado a construir uma proteção efetiva de seus dados a partir do entendimento de como essa proteção é construída, em torno de sí mesmo primeiramente, até o contato que estes tem com os sistemas corporativos a seu dispôr. Não se pode negligenciar a forma de como este usuário enxerga o valor de seus dados, e não lhes oferecer indicações sobre como podem se proteger fora do ambiente corporativo.

Tentar proteger estes sistemas, utilizando as mais diversas ferramentas e orçamentos disponíveis, sem que o usuário seja instruído sobre como lidar com a segurança de seus dados pessoais, ou de seu equipamento doméstico ou móvel, de uma forma que seja compreensível por ele, será sempre uma luta difícil de ser vencida.

A participação de todos os envolvidos nos processos, é essencial para a minimização dos riscos na segurança da informação, por isso a alta direção deve se preocupar com a educação dos usuários sobre o tema, mas fazendo isso a partir do ponto de vista deles, oferecendo caminhos que possam ser trilhados para a obtenção de segurança, removendo a tensão existente, e melhorando a proteção de todos.