{"id":512,"date":"2018-01-22T17:44:57","date_gmt":"2018-01-22T20:44:57","guid":{"rendered":"http:\/\/www.batori.com.br\/blog\/?p=512"},"modified":"2018-03-22T08:37:16","modified_gmt":"2018-03-22T11:37:16","slug":"gestao-de-vulnerabilidade-tecnica-software-em-eol-end-of-life","status":"publish","type":"post","link":"http:\/\/www.batori.com.br\/blog\/gestao-de-vulnerabilidade-tecnica-software-em-eol-end-of-life\/","title":{"rendered":"Gest\u00e3o de vulnerabilidade t\u00e9cnica – software em EOL (end of life)"},"content":{"rendered":"

\"Gest\u00e3o<\/a>Muitas empresas e gestores de TI convivem com um dilema dif\u00edcil de resolver: conviver com o risco de manter os softwares antigos sem suporte do fabricante ou atualizar os softwares e correr risco de tem problemas decorrentes da migra\u00e7\u00e3o para a nova vers\u00e3o do software? Na maioria das situa\u00e7\u00f5es, ambas op\u00e7\u00f5es geram riscos de seguran\u00e7a da informa\u00e7\u00e3o que podem afetar o neg\u00f3cio das empresas.<\/p>\n

O objetivo deste artigo \u00e9 ajudar a tomada de decis\u00e3o entre aceitar os riscos de manter um software obsoleto (End of Life<\/em>) ou fazer a atuliza\u00e7\u00e3o necess\u00e1ria.<\/p>\n

Para esta an\u00e1lise consideramos como sendo software, os sistemas operacionais, sistemas de banco de dados, servidores web, servidores de email, bibliotecas usados por outros softwares, aplica\u00e7\u00f5es web de neg\u00f3cios, aplicativos de dispositivos m\u00f3veis, etc.<\/p>\n

O ciclo de vida de um software pode variar de empresa para empresa desenvolvedora. Algumas empresas definem um cronograma do ciclo de vida de um software considerando as etapas: encerramento do desenvolvimento de novas funcionalidades, encerramento de corre\u00e7\u00e3o bugs, encerramento do servi\u00e7o de suporte, encerramento de corre\u00e7\u00e3o vulnerabilidades de seguran\u00e7a, etc.<\/p>\n

Normalmente um software obsoleto possui uma s\u00e9rie de vulnerabilidades conhecidas e divulgadas nas comunidades de seguran\u00e7a da informa\u00e7\u00e3o e incorporadas nos produtos de seguran\u00e7a da informa\u00e7\u00e3o como, por exemplo, scanner<\/em> de vulnerabilidades, IDS\/IPS, SIEM e outras tecnologias de seguran\u00e7a de rede e aplica\u00e7\u00f5es. Para estas vulnerabilidades n\u00e3o \u00e9 muito dif\u00edcil encontrar na internet, exploits<\/em> (scripts<\/em> ou programas para explorar uma vulnerabilidade) prontos para serem usados. Ou seja, \u00e9 fundamental que, caso voc\u00ea tenha em seu ambiente de TI, um software obsoleto, todas as corre\u00e7\u00f5es de seguran\u00e7a disponibilizadas estejam devidamente aplicadas.<\/p>\n

Por\u00e9m, mesmo que voc\u00ea tenha aplicado todas as corre\u00e7\u00f5es de seguran\u00e7a, podem existir vulnerabilidades que foram descobertas depois que a empresa desenvolvedora parou de disponibilizar corre\u00e7\u00f5es de seguran\u00e7a. Neste caso, voc\u00ea s\u00f3 poder\u00e1 eliminar este tipo de vulnerabilidade com remendos desenvolvidos por terceiros ou adotar outro tipo de contramedida. O que nem sempre \u00e9 uma boa solu\u00e7\u00e3o.<\/p>\n

Analisando a melhor forma de eliminar ou mitigar os riscos envolvidos no uso de software obsoleto, a solu\u00e7\u00e3o parece bastante simples: migrar o software para uma vers\u00e3o mais nova. Correto? Correto pode ser, mas nem sempre \u00e9 a op\u00e7\u00e3o mais segura ou mais vi\u00e1vel para executar.<\/p>\n

Por exemplo, vamos considerar uma aplica\u00e7\u00e3o web de neg\u00f3cio que \u00e9 fundamental para uma empresa. Esta aplica\u00e7\u00e3o est\u00e1 em opera\u00e7\u00e3o h\u00e1 mais de 8 anos sem hist\u00f3rico de problema ou incidente de seguran\u00e7a. Est\u00e1 aplica\u00e7\u00e3o web roda num servidor IIS 6.0 e no Windows 2003 Enterprise Edition, ambos sem nenhum suporte ou desenvolvimento de novas corre\u00e7\u00f5es de seguran\u00e7a por parte Microsoft. Para eliminar as vulnerabilidades que estes softwares possuem e que n\u00e3o s\u00e3o poucas, a empresa ter\u00e1 que migrar o servidor web para uma nova vers\u00e3o do Windows e do servi\u00e7o web IIS.<\/p>\n

Existe o risco da aplica\u00e7\u00e3o apresentar incompatibilidade o novo IIS e\/ou com a nova vers\u00e3o do Windows. Para evitar este problemas, a aplica\u00e7\u00e3o deve ser migrada, testada e homologada detalhamente no novo ambiente. Esta migra\u00e7\u00e3o carrega riscos inerentes \u00e0s implanta\u00e7\u00f5es e mudan\u00e7as nos ambiente de TI. A an\u00e1lise destes riscos deve considerar como um eventual incidente nesta aplica\u00e7\u00e3o web ir\u00e1 impactar o neg\u00f3cio da empresa.<\/p>\n

O resultado desta an\u00e1lise pode levar a conclus\u00e3o de que o risco de migrar a aplica\u00e7\u00e3o web \u00e9 maior do que a conviv\u00eancia com software obsoletos. Pode tamb\u00e9m definir a necessidade de controles adicionais como, por exemplo, segra\u00e7\u00e3o da aplica\u00e7\u00e3o web em uma rede isoloada por firewall ou a implanta\u00e7\u00e3o de web application firewall.<\/p>\n

Ou por outro lado, pode-se chegar a conclus\u00e3o que a migra\u00e7\u00e3o dos softwares obsoletos \u00e9 a melhor solu\u00e7\u00e3o para eliminar as vulnerabilidades e diminuir os riscos de seguran\u00e7a da informa\u00e7\u00e3o. N\u00e3o \u00e9 poss\u00edvel fazer uma recomenda\u00e7\u00e3o generalizada sem conhecer o ambiente espec\u00edfico de cada situa\u00e7\u00e3o, o neg\u00f3cio e o perfil de risco da empresa.<\/p>\n

Conformidade e governan\u00e7a<\/strong><\/p>\n

Quando analisamos o uso de software obsoleto ou em EOF sob a \u00f3tima de governan\u00e7a corporativa podemos ser mais objetivos.<\/p>\n

O n\u00edvel de governan\u00e7a depende muito de como os n\u00edves de controle podem ser comprovados pelas partes interessadas extenas ao ambiente da empresa.<\/p>\n

Se voc\u00ea for analisar uma empresa na qual voc\u00ea n\u00e3o conhece a sua estrutura interna, as pessoas ou os processos internos e, se voc\u00ea constatar que esta empresa convive com software obsoletos, voc\u00ea certamente ir\u00e1 considerar esta situa\u00e7\u00e3o como um ponto negativo, mesmo que existam in\u00fameras justificativas para esta situa\u00e7\u00e3o.<\/p>\n

Com exemplo, vamos considerar duas normas de seguran\u00e7a da informa\u00e7\u00e3o conhecidas, a ISO\/IEC 27.001 e o PCI\/DSS.<\/p>\n

De acordo com o requisito 6.2 do PCI\/DSS, os patches de seguran\u00e7a cr\u00edticos devem ser aplicados em at\u00e9 um m\u00eas ap\u00f3s o lan\u00e7amento, o que fica imposs\u00edvel de cumprir este requisito, caso o software esteja em End of Life<\/em>.<\/p>\n\n\n\n
Requisito 6.2 do PCI\/DSS 1: “Certifique-se de que todos os componentes do sistema e softwares estejam protegidos de vulnerabilidades conhecidas instalando os patches de seguran\u00e7a aplic\u00e1veis disponibilizados pelos fornecedores. Instale patches de seguran\u00e7a cr\u00edticos em at\u00e9 um m\u00eas ap\u00f3s o lan\u00e7amento.<\/em>“<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

A norma ISO\/IEC 27001 e ISO\/IEC 2002 \u00e9 mais abrangente e tem um enfoque maior na avalia\u00e7\u00e3o dos riscos associados \u00e0 vulnerabilidade identificada.<\/p>\n\n\n\n
Item d) do controle 12.6.1 “Gest\u00e3o de vulnerabilidades t\u00e9cnicas ” da norma\u00a0da norma ISO\/IEC 27002: “uma vez que uma vulnerabilidade t\u00e9cnica potencial tenha sido identificada, conv\u00e9m que a organiza\u00e7\u00e3o avalie os riscos associados e as a\u00e7\u00f5es a serem tomadas; tais a\u00e7\u00f5es podem requerer o uso de emendas de corre\u00e7\u00f5es (patches) nos sistemas vulner\u00e1veis e\/ou a aplica\u00e7\u00e3o de outros controles.<\/em>“<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

Considera\u00e7\u00f5es finais<\/strong><\/p>\n

Manter softwares obsoletos \u00e9 um risco muito grande devido a exist\u00eancia de vulnerabilidades sem corre\u00e7\u00f5es e a cont\u00ednua possibilidade de novas vulnerabilidade serem descobertas.<\/p>\n

Sob o ponto de vista de governan\u00e7a corporativa, seguir uma pol\u00edtica de n\u00e3o usar software obsoletos (em End of Life<\/em>) ir\u00e1 facilitar a obten\u00e7\u00e3o de conformidade com as boas pr\u00e1ticas de mercado.<\/p>\n","protected":false},"excerpt":{"rendered":"

Muitas empresas e gestores de TI convivem com um dilema dif\u00edcil de resolver: conviver com o risco de manter os softwares antigos sem suporte do fabricante ou atualizar os softwares e correr risco de tem problemas decorrentes da migra\u00e7\u00e3o para … Continue lendo →<\/span><\/a><\/p>\n","protected":false},"author":125,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[5],"tags":[],"_links":{"self":[{"href":"http:\/\/www.batori.com.br\/blog\/wp-json\/wp\/v2\/posts\/512"}],"collection":[{"href":"http:\/\/www.batori.com.br\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"http:\/\/www.batori.com.br\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"http:\/\/www.batori.com.br\/blog\/wp-json\/wp\/v2\/users\/125"}],"replies":[{"embeddable":true,"href":"http:\/\/www.batori.com.br\/blog\/wp-json\/wp\/v2\/comments?post=512"}],"version-history":[{"count":18,"href":"http:\/\/www.batori.com.br\/blog\/wp-json\/wp\/v2\/posts\/512\/revisions"}],"predecessor-version":[{"id":533,"href":"http:\/\/www.batori.com.br\/blog\/wp-json\/wp\/v2\/posts\/512\/revisions\/533"}],"wp:attachment":[{"href":"http:\/\/www.batori.com.br\/blog\/wp-json\/wp\/v2\/media?parent=512"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"http:\/\/www.batori.com.br\/blog\/wp-json\/wp\/v2\/categories?post=512"},{"taxonomy":"post_tag","embeddable":true,"href":"http:\/\/www.batori.com.br\/blog\/wp-json\/wp\/v2\/tags?post=512"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}