Como convencer meu administrador de que o Java ON A SERVER não é inseguro por si só?

A aplicação

Temos um pequeno aplicativo Java que usa algumas rotas do Camel para coletar arquivos enviados de um servidor da web, processá-los e enviar alguns e-mails com os resultados.

O servidor no qual este aplicativo estava sendo executado foi descomissionado. Por enquanto, temos que executá-lo em hardware com pouca potência, porque não consigo convencer o administrador a instalar um JRE no servidor da web (que na verdade é um servidor multiuso).

O medo

Sou engenheiro de aplicativos Java, escrevo código JEE para viver, lidando com transações B2B no valor de dezenas de milhares de euros por semana. Mas tenho problemas para encontrar fontes confiáveis ​​que refutam o mito de que o java é inseguro em si.

Os dois principais argumentos do administrador contra a instalação de um JRE:

1. Aplicativos Java consomem toda a minha RAM
2. Java está cheio de vulnerabilidades

A verdade?

Quando se trata de aplicativos java que comem ram. Bem ... eu diria que temos que definir valores adequados para Xmx. Feito.

Agora, existem muitas fontes falando sobre as muitas vulnerabilidades do Java. Essas fontes visam principalmente usuários finais executando um determinado sistema operacional de uma empresa em Redmond / EUA. AFAIK, pode ser verdade nas versões sem patch do Java Browser Plugin, que está configurado para executar todos os miniaplicativos automaticamente, que há grandes chances de ser vítima de uma unidade por infecção. Assim como existe o risco de contrair uma DST ao fazer sexo desprotegido com o eveyone no trem enquanto se desloca para o trabalho.

Mas não consegui encontrar ninguém na interwebz mundial que fale sobre aplicativos de servidor ou JREs rodando sem cabeça. Isso é outra coisa.

Ou estou faltando alguma coisa aqui?

[editar 28/08/2014] esclarecimento: Estou preocupado apenas com Java nos servidores. Não me importo com problemas com o Java Plugin e / ou software específico desenvolvido em java.

A superfície de segurança adicional que o java coloca no seu ambiente é complexa e é importante não ignorá-lo ou tentar simplificá-lo.

Em primeiro lugar, há o registro horrível que o JRE possui por ter bugs de segurança. É difícil apontar uma específica, e essa é a parte mais assustadora - os bugs são vulnerabilidades predominantemente não especificadas com vetores não especificados.

Quando eu, como consultor de segurança, leio cláusulas como "permite um atacante remoto" sem qualificação adicional quanto ao seu significado, vejo que isso pode muito bem significar que determinados parâmetros que entram em uma determinada função podem invocar a condição vulnerável, mesmo se você estão executando apenas o código que você escreveu. E, como não são especificados, você não sabe se foi afetado.

Melhor ainda, o JRE canônico publicado pela Oracle possui um ciclo de atualização trimestral declarado para atualizações críticas, incluindo quase todas as atualizações de segurança. Eles criaram patches fora do ciclo um total geral de 11 vezes nos últimos quatro anos. Isso significa que existe a possibilidade de você estar vulnerável a um bug de segurança até três meses depois que ele é relatado antes de ter alguma maneira de corrigi-lo.

Há outros problemas com o java que não abordarei aqui, mas realmente parece que há uma preocupação justificável, especialmente para um servidor multiuso. Se você precisar executar essas coisas, você deve pelo menos criar uma VM de propósito único e isolá-la de outras coisas.

Em particular, se houver um controle remoto no JRE que permita que um invasor obtenha o RCE, outro no PHP que faça o mesmo e outro no Ruby que faça o mesmo novamente, será necessário corrigir os três. Todos os três parecem um pouco prováveis, como essas coisas acontecem, e o invasor escolhe o que for mais conveniente e depois é dono de todo o servidor. É por isso que devemos usar VMs para separar software, especialmente softwares de buggy, como estruturas de linguagem gerenciada, e especialmente aquelas que agrupam patches de segurança apenas quatro vezes por ano e são de propriedade de um fornecedor que afirma diante de todas as evidências de que eles são um exemplo de segurança.

Para atualizar, aqui estão alguns CVEs que selecionei na pesquisa CVE vinculada do ChrisS, a título de demonstração.

• https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-5884
• https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-5910
• https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-5456
• https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-3007
• https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-2454
• https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-2447
• https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-1557

E o meu favorito, desde que eu estava lá:

• https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-1488

A propósito, isso é apenas uma pequena amostra.

Aplicativos Java consomem toda a minha RAM

A alternativa ao uso da RAM é desperdiçar RAM. Você não pode salvá-lo para mais tarde.

Java está cheio de vulnerabilidades

Isso realmente não importa, porque você não vai expor a JVM ao mundo. Presumo que você não executará nenhum programa hostil e, se estiver, o Java é mais seguro do que a maioria das outras linguagens. O que importa é se seus aplicativos têm vulnerabilidades.

Contrate uma empresa para fazer análises estáticas no seu programa. A Veracode, por exemplo, é uma empresa que eu usei no passado para auditar a segurança do código de programas Java, especificamente.

Fature o código de cobrança da sua equipe de administradores, obviamente.

Explique que todas as outras linguagens (ou máquinas virtuais) podem se tornar inseguras pelo código implantado nelas, assim como no Java. Se ele acha que as outras plataformas são inerentemente seguras (ou mais seguras que Java) sem abordar corretamente a segurança, ele é ilusório.

Sua empresa obviamente investiu na contratação de um desenvolvedor Java, por que o administrador de sistemas se recusa a oferecer suporte a uma tecnologia que a empresa decidiu usar?

Eu faria a pergunta e perguntaria a ele quais alternativas ele propõe e como elas são mais seguras do que o Server JRE mais recente disponível, em termos muito específicos. Enquanto isso, trabalhe para mostrar que você entende sua tecnologia, a possível superfície de ataque e que você trabalhou para minimizá-la (por exemplo, estruturas desnecessárias, código de terceiros etc.). Verifique seu código, procure vulnerabilidades publicadas para as estruturas nas quais você confia nos últimos X anos, compare-o com outras linguagens / estruturas (certifique-se de incluir também participação no mercado, estruturas obscuras sem vulnerabilidades publicadas não significam nada).

Não podemos saber como aconteceu toda a conversão entre vocês dois, mas se esses foram os dois argumentos dele, acredito que você esteja lidando com um administrador de sistemas júnior. Ele tem experiência com servidores de aplicativos Java? Talvez ele esteja desconfortável com a tecnologia e com medo de colocar algo em produção sem entendê-la completamente (boa atitude do administrador de sistemas).