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.

1. 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, vulnerabilidades.

2. 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 bem-
sucedidos, 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

3. 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

4. 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