Image for post
Image for post
Autor: Alberto Domínguez Serra| Security Architect

Esse software que você nunca desenvolveu…

O gerenciamento de software nas operações do dia a dia nas organizações é uma questão complexa. Se pensarmos sobre a típica infraestrutura tecnológica que suporta as operações nas organizações, vemos que é um elemento muito diversificado, com muitos componentes diferentes, de diferentes fontes. Neste artigo, vamos explorar o que podemos encontrar quando o software não é desenvolvido pela organização em primeira mão. Se nos concentrarmos na origem do gerenciamento de software, podemos definir três tipos principais: software desenvolvido pela organização, seja utilizando os seus próprios recursos, seja por meios de terceirização, software adquirido comercialmente e desenvolvido por terceiros, e software desenvolvido por comunidades de software de código aberto.

É importante perceber que, em geral, os componentes de software já desenvolvidos são usados para criar outros elementos. Isso significa que cada software ou programa já vem com um conjunto de dependências (componentes) que podem pertencer originalmente a um dos outros tipos mencionados anteriormente. Isto é, a maioria dos artefatos são mistos e têm componentes internos de diferentes origens. Além disso, também pode haver diferentes versões do mesmo software, com diferentes características: funcionalidades, configuração e, em termos de segurança, vulne A execução de medidas adequadas para proteger e manter o software, neste cenário, pode se tornar uma tarefa titánica, se não houver uma abordagem eficiente. Um dos processos que ajuda a manter o controle sobre a tecnologia da infraestrutura de uma organização, é o processo de Configuration Management, que ajuda a inventariar os diferentes programas, aplicativos e softwares de acordo com suas versões e arquivos de configuração correspondentes.

No entanto, o problema se origina nas dependências citadas anteriormente, que vêm de fontes externas para a organização. Se forem detectadas vulnerabilidades em qualquer um desses componentes, isso poderá comprometer todo o artefato. A segurança precisa de que a ordem e o controle sejam bemsucedidos, logo, esse processo de controle deve gerenciar também essas dependências (internas e externas) da mesma forma que aqueles componentes finais já incluídos. Essa é a teoria, mas na prática as coisas são bem diferentes.

Nem tudo que reluz é ouro

O ataque à EQUIFAX, que afetou 143 milhões pessoas, e levou seu CEO a renunciar, foi causada por uma falha em um componente base de um dos seus aplicativos. De acordo com o último relatório da Black Duck, 97% dos aplicativos contêm software de código aberto de terceiros, dos quais 67% também têm vulnerabilidades conhecidas. O uso de componentes de terceiros, especialmente os gratuitos FOSS (Free and Open Source Software), trazem muitos benefícios para as organizações: acelera o tempo de desenvolvimento e fornece suporte de componentes já testados e maduros, o que, por sua vez, reduz os custos de desenvolvimento, etc.

No entanto, essas práticas também exigem que as organizações garantam um acompanhamento completo desses componentes e suas atualizações correspondentes.

Quando os componentes são adquiridos comercialmente, os fornecedores de software geralmente informam aos clientes sobre correções ou atualizações recém lançadas, mas as comunidades de software de código aberto geralmente não sabem quem está usando seus produtos e só podem usar seus canais de comunicação (sites, redes sociais, RSS etc.) para relatar problemas. Assim, cabe à organização ter tudo sob controle e monitorar adequadamente os componentes que formam os diferentes aplicativos FOSS, e isso também é recomendado para componentes de terceiros. Este acompanhamento pode ser realizado por meio de canais online de provedores e comunidades, ou através de repositórios de vulnerabilidades e CERTs (Computer Emergency Response Team).

Riscos

A falta de controle sobre componentes de software em uma organização pode resultar em dois tipos principais de riscos. Em primeiro lugar, alguns componentes podem representar um alto risco para a organização (dependendo das vulnerabilidades). Em segundo lugar, pode resultar na falta de controle sobre a infraestrutura, pois não há como saber qual software está sendo executado e onde. Isso seria crítico se estivéssemos perdendo o conhecimento sobre nossa organização no caso de um ataque. A combinação de ambos os riscos seria fatal, pois isso permitiria que atacantes em potencial acessassem e assumissem o controle da infraestrutura tecnológica.

Em geral, os aplicativos que são expostos online exigem mais supervisão pelas organizações, pois podem se tornar um ponto de acesso direto. Componentes vulneráveis que interagem com o exterior geralmente são detectados durante as auditorias periódicas. No entanto, aqueles usados internamente pelos aplicativos, podem passar despercebidos até que alguma modificação os torne um alvo de ataque viável. Além dos aplicativos, não devemos esquecer outros elementos incluídos na infraestrutura tecnológica, como sistemas operacionais, servidores web, servidores de aplicativos, servidores de banco de dados e qualquer outro tipo de sistema e middleware. Este software é geralmente o principal suporte para as arquiteturas internas da infraestrutura, que por sua vez suporta todos os outros aplicativos, e é essencial para suportar as operações globais da organização.

A maioria desses componentes vem de terceiros em vez de serem desenvolvidos pela organização em primeira mão, e muitos deles são FOSS. Esses elementos devem ser incluídos no processo de Configuration Management da organização, assim como os aplicativos e seus componentes, pois, em termos de vulnerabilidades, todos eles apresentam os mesmos problemas. Assim, deve haver um acompanhamento adequado de vulnerabilidades relatadas e correções publicadas pelas comunidades ou provedores de software correspondentes. Em geral, recomenda-se padronizar e normalizar as diferentes versões implementadas de cada software, para facilitar o gerenciamento da segurança com mais eficiência, em vez de precisar monitorar cada versão do software.

Quanto mais simples a infraestrutura, mais fácil será proteger. Se o objetivo é melhorar a segurança desse tipo de software, as ações de proteção podem ajudar a mitigar possíveis vulnerabilidades.

Para aqueles que não estão familiarizados com o conceito, consiste em um conjunto de práticas e configurações a serem aplicadas ao software para melhorar a segurança. Na maioria das vezes, essas ações buscam eliminar funcionalidades ou serviços desnecessários, modificar configurações por defeito e excluir a documentação de ajuda e os exemplos disponíveis. Há ainda outro tipo de software que deve ser incluído nesses processos de controle, pois pode conter vulnerabilidades e comprometer a infraestrutura. Este software é necessário para manter a conexão e o funcionamento das máquinas, uma vez que é executado em equipamentos de rede, controlando os blades em centros de processamento de dados (CPD) e até mesmo os firewalls.

Normalmente, este software consiste em firmware proprietários dos fornecedores dos equipamentos correspondentes. Este software tem que ser inventariado e controlado como em casos anteriores, especialmente aqueles que mantêm a infraestrutura em funcionamento e conectada. As atualizações do fabricante e as vulnerabilidades mais recentes relatadas devem ser monitoradas também.

Conclusão

Conforme as informações dadas acima, vemos que é essencial ter um controle adequado dos softwares implementados em todos os níveis, e das dependências, como parte das operações diárias das organizações, que estão cada vez mais, contando com o software de terceiros.

Além disso, as auditorias de código de segurança podem ajudar a detectar possíveis falhas nas dependências do nosso software que poderiam passar despercebidas em outros tipos de auditorias. Esses testes são particularmente eficientes quando se trata de encontrar componentes vulneráveis em nossos aplicativos, pois nos permitem verificar a versão que está sendo usada atualmente e até realizar análises internas nos casos de FOSS. Os resultados da auditoria de códigos permitem melhorar o controle sobre a infraestrutura tecnológica, pois podem ser usados para atualizar o inventário de dependências aprovadas para uso e execução na produção. A realização de revisões periódicas por meio de testes de segurança, juntamente com o controle de todos os software em nossa infraestrutura, ajudariam a manter um nível significativo de estabilidade em termos de segurança. Isto faria com que as organizações amadurecessem o suficiente para controlar o risco, e evitar surpresas como a do Equifax, o software que nunca desenvolveram. Alberto Dominguez Serra Security Architect

Written by

Exponential intelligence for exponential companies

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store