Hardening: o que, como e por que?

Olá pessoal, vocês já ouviram falar de hardening?

Se sua resposta for não, vale uma atenção sobre isso. Se já ouviu falar, mas quer saber mais, está no lugar certo.

Vamos lá, a palavra em inglês “hardening”, na tradução literal já nos dá uma dica: endurecimento. Mas isso é muito amplo, então vamos falar especialmente de tecnologia e isso abrange muito o lado de segurança principalmente. No entanto veremos que o assunto é mais amplo.

Quando falamos de tecnologia, envolvemos ambientes operacionais, como servidores, aplicações, redes, etc. Se pergunte se o seu computador está seguro, por exemplo. Quando você instala um antivirus, você está “hardenizando” seu computador, ou seja, reduzindo a possibilidade de ser infectado por um vírus. Se você é desenvolvedor de software e utiliza uma ferramenta que valida a segurança do seu código, como ferramentas SAST, você está protegendo sua aplicação e mitigando riscos que ela gere para o ambiente onde ela será implantada.

Muito complexo isso tudo? Vamos a um exemplo bem didático. Se você mora em uma casa, em um bairro perigoso e o seu muro é baixo, seu risco é alto. Se você aumenta o muro, deixa bem alto e coloca uma cerca elétrica no alto, você está reduzindo seu risco. Isso é hardening.

Voltemos à tecnologia. Partimos do princípio que estar 100% seguro é bem difícil, então chegar o mais perto desse percentual parece algo bem razoável, concordam? Então vamos a exemplos mais práticos, direcionando para profissionais do setor.

Se você é um analista de infraestrutura ou cloud, manter seu servidores e sistemas operacionais atualizados é uma tarefa trivial, correto? Mas cuidar das portas de rede, certificados de segurança, gestão de acessos, logs e etc, são itens complementares e importantes quando falamos de governança. Se você atua com deploy de aplicações em web servers (IIS, Apache, Nginx e outros), hardenizar estes recursos é também uma necessidade. Se atua com containers, por exemplo, com docker ou podman, é mais uma camada que requer atenção, logicamente envolvendo outros profissionais, como desenvolvedores, analistas responsáveis por DevOps, etc.

Se você é desenvolvedor de software, note que hoje em dia falamos muito de componentes e, principalmente em linguagens como Node, usamos estes componentes de um repositório público, o NPM. Quando instalamos um componente do NPM em nossos projetos, logicamente estamos visando atender um requisito de nossas aplicações, portanto são necessários, a menos que você próprio crie seus componentes. Neste ponto, saber a segurança de um componente que estamos trazendo para nossas aplicações passa a ser um item de atenção, concordam? Afinal, o componente está lá, foi desenvolvido por alguém que você não conhece provavelmente. E se o componente, por má fé ou meramente por acaso, contiver uma brecha de segurança, você trouxe ela para seu sistema quando fez um ‘npm install’ ou um ‘yarn install’ ou qualquer outro. E isso se estende a qualquer linguagem, quando fazemos um “pip install” do python ou “go get” no Golang, etc.

Hoje em dia, estamos muito condicionados a containers, algo que facilita muito nossas entregas de softwares. Como o Docker é um sabor de container bem utilizado, usarei ele no exemplo, mas poderia ser qualquer outro. O Docker conta com seu repositório (o nome adequado é “registry”), onde temos imagens base para construir nossos containers. Isso acontece quando escrevemos um “Dockerfile” e colocamos a referência da imagem que queremos logo no início, usando o comando “FROM”. Quando construímos nossos containers a partir daí, o docker obtém a imagem base no seu registry, o Docker Hub. O Docker Hub por sua vez é público, tem imagens oficiais e não oficiais, igualmente passíveis de vulnerabilidades nas devidas proporções. Vamos lembrar que a imagem de um container contem itens básicos do sistema operacional que propiciam minimamente que uma aplicação implantada dentro dele funcione. Temos então 2 pontos nessa hora: o primeiro é que obtivemos uma imagem externa. O segundo é que estamos colocando dentro dela mais artefatos, bibliotecas, pacotes e etc. Quando terminamos de construir essa imagem, contendo então essas duas partes, temos uma imagem nossa, e é aí que precisamos também do hardening. Buscando por “scan docker images” no Google temos opções, busquem por exemplo por Trellix ou Trivy, são boas opções entre ferramentas pagas e gratuitas. Uma outra ferramenta que possui versão gratuita também, produzida por um grande player do setor, a Tenable, é o produto chamado Nessus, vale muito a pena conhecer.

Quando realizamos um scan de imagens de containers e, não somente neles, podendo ser em um sistema operacional em host também, temos como descobrir entre outras informações os chamados “CVE”s (Common Vulnerabilities and Exposures). Complicou? Vamos lá, os catálogos de CVE são facilmente encontrados na internet, mas basicamente são nomeados pelo ano e código catalogado, que indicam quando a vulnerabilidade foi identificada. Vamos a um exemplo, um CVE recente do Docker é o CVE-2023-24329. Conforme comentado, o primeiro trecho indica o ano, ou seja, é de 2023. A própria Docker alerta sobre ele no link: https://dso.docker.com/cve/CVE-2023-24329 indicando que foi criado há 1 mês atrás, considerando a data de publicação desta matéria. Os catálogos de vulnerabilidades indicam sempre um “CVSS Score” que basicamente indica o quão crítica é aquela vulnerabilidade. Se identificarmos algo igual ou acima à severidade Média (Medium) já é algo importante. No nosso exemplo, o score atual é 7.5, sinalizado portanto como Alto (High). Este nem é o mais alto, ainda temos itens de vulnerabilidade classificados com severidade Crítica (Critical) que são ainda mais importantes quando falamos em um plano de ação: o hardening.

E como atuar nisso?

Fazer um hardening exige algumas habilidades, desde sistema operacional, infra e software de forma geral. Mas buscando um ponto de partida, nos catálogos de CVE, como comentei, em geral há instruções ou indicativas do que deve ser feito. Por exemplo, se pegarmos novamente o nosso exemplo do Docker, no mesmo link que citei acima, o site informa que aquela vulnerabilidade acontece devido a uma biblioteca do python até uma determinada versão, ou seja, se atualizarmos para uma versão superior, mitigamos o risco: hardenizamos a imagem.

Importante salientar, pessoal, que usei aqui várias vezes o “hardening” como um verbo. Esse neologismo não deve ser considerado como palavra portuguesa, apenas apliquei como forma de ilustração do “hardening”.

Se você trabalha ou tem uma empresa que precisa de mais detalhes sobre esse assunto, a Dopster pode ajudar. Fale com a gente.

É isso! Até mais!