O ambiente corporativo abriga algumas distorções e mitos a respeito da segurança de aplicações internas e da web, levando a um aumento na incidência de ataques e à redução do número de defesas. Alguns mitos tendem a minimizar os riscos, transmitindo uma falsa sensação de segurança, seja através do uso de uma nova tecnologia “fantástica” ou da falta de visibilidade do problema. Essa ilusão de segurança normalmente leva a empresa a subestimar ameaças bem reais, quando ela não mobiliza os recursos que devia para suas medidas de segurança.
A internet se tornou o principal ponto de convergência dos sistemas corporativos, integrando operações entre parceiros, fornecedores, clientes e terceiros através do mesmo canal eletrônico. De acordo com o grupo Gartner, o número global de dispositivos conectados ultrapassou os 2.4 bilhões em 2014.
Com esta quantidade imensa de usuários consumindo sistemas de informação numa rede pública, a segurança de sistemas diretamente disponibilizados na web ou integrados através dela se tornou um item de altíssima prioridade na agenda dos gerentes de TI. Além disso, o cenário está aumentando em complexidade, com a disseminação da computação distribuída na nuvem, o uso de big data, a interação entre estes serviços distribuídos e a crescente necessidade de se implementar a governança corporativa.
É cada vez mais necessário eliminar os mitos que em nada contribuem para uma proteção de sistemas bem sucedida. Listamos abaixo 5 mitos sobre segurança de aplicações que podem atrapalhar uma percepção adequada de proteção.
5 mitos sobre segurança de aplicações
Segurança não é tão problemática se eu tiver poucos sistemas na web
A segurança de sistemas internos — que não estão expostos à internet — deve ser levada tão a sério quanto segurança de aplicações da web. Imagine uma vulnerabilidade num servidor de aplicações interno (desconectado da web) que processa dados de clientes. Ignorar a segurança deste servidor equivale a confiar cegamente em toda e qualquer informação que ele processa. Infelizmente, na maioria dos casos, não podemos confiar em todos os itens de dados que um servidor processa. Dados maliciosos poderiam passar despercebidos através de uma entidade confiável (como um banco de dados) e alcançar trechos vulneráveis de código de maneiras inesperadas. Com recursos escassos, alguém talvez queira arcar com os riscos quando se tratar de aplicações com pouco impacto em caso de falha ou que recebem dados cuidadosamente auditados e sanitizados. Entretanto, com aplicações críticas para o negócio ou que processam dados sensíveis, o risco pode ser grave demais e as consequências podem ser financeiramente desastrosas.
O firewall de aplicações vai nos proteger de tudo
Quase todas as vulnerabilidades de segurança residem na camada de aplicativo, e milhares de novos ataques surgem diariamente. Para muitas empresas, as aplicações web são o ponto mais fraco, que se for comprometido, pode levar potencialmente a vazamento de dados, invasão da rede, roubo de identidade, danos ao nome da empresa e até perda financeira.
Os Firewalls de Aplicações Web (Web Application Firewalls – WAFs) e outras abordagens reativas não estão conseguindo manter o ritmo, entregando apenas um aumento na latência de rede e uma falsa sensação de segurança. WAFs se baseiam em definições e assinaturas de ataques que já aconteceram, então eles estão sempre um passo atrás e não podem fazer nada contra ataques não divulgados (zero-day exploits). Normalmente é bem dispendioso fazer a sintonia fina de um WAF para reduzir falsos positivos e mantê-lo atualizado.
Firewalls de Aplicação são a última linha de defesa antes da aplicação propriamente dita. Se a aplicação for insegura, o WAF vai contar muito pouco no aumento de segurança.
SSL é o bastante para a segurança da aplicação
O Security Socket Layer (SSL) foi desenvolvido para criptografar e autenticar o tráfego de dados. O que ele faz é criptografar os dados trocados entre cliente e servidor usando um par de chaves (pública e privada) de um Certificado Digital.
Isto é efetivo contra a maioria dos ataques de interceptação de dados (man-in-the-middle) e de adulteração (dados modificados em trânsito), mas sem efeito sobre a lógica da aplicação. Essa abordagem não protege todo o ambiente da aplicação, nem evita o uso malicioso de recursos exploráveis depois de estabelecida a conexão SSL, como por exemplo a injeção de SQL. Nem garante que os dados estejam seguros dentro da própria rede, depois de entregues. Seu uso faz parte das boas práticas de segurança, mas SSL não resolve tudo.
Vulnerabilidades de aplicações são muito parecidas com as de rede e de sistema
Um problema muito comum é a falta de validação dos dados inseridos em uma aplicação via formulário. Por exemplo, um formulário web que solicita um endereço de e-mail deveria aceitar somente caracteres que fazem parte de um endereço válido, rejeitando ativamente todos os outros. Um atacante poderia potencialmente apagar ou modificar seu banco de dados, tranquilamente escondido e a salvo de firewalls, sistemas detectores de intrusão e servidores web, simplesmente explorando a vulnerabilidade à injeção de SQL nesse formulário da aplicação. Mesmo com os ativos de rede fazendo perfeitamente seus respectivos trabalhos, o dano estaria feito.
Ataques contra aplicações da web não visam ativos de rede, visam encontrar e explorar aplicações imperfeitas que usam HTTP(s).
Manter as atualizações em dia e acompanhar os boletins de vulnerabilidade é o bastante
Em empresas com um nível alto de normalização é comum que sejam exigidas revisões anuais de segurança. Infelizmente esta ainda não é uma prática largamente adotada no cenário nacional, especialmente das aplicações web.
Mesmo nos ambientes onde se exige uma revisão anual, manter as atualizações de software em dia e acompanhar as notificações de vulnerabilidade (via Securelist, NVD, Exploit Database, etc) não vai ser o bastante. Dentro do ciclo de vida de uma aplicação, quanto maior for a frequência de novas alterações ou implementações, maior será a necessidade de revisões de segurança mais frequentes. Testes de Penetração (Pentest) e relatórios de segurança estão sempre potencialmente atrasados.
E pensar que o gerenciamento de atualizações e patches vão ajudar a responder rapidamente, no caso de se identificar uma vulnerabilidade, é ilusão.
É vital reexaminar o “senso comum” e a cultura em torno da segurança de software. Ainda estamos a uma imensa distância de conseguir criar softwares impenetráveis, mas já aprendemos muito. Sabemos que as vulnerabilidades são uma ameaça real e urgente aos negócios. E sabemos que não podemos acreditar que nossos métodos atuais de produção de software vão necessariamente incluir segurança no resultado final.
E acima de tudo, sabemos que providenciar e manter a melhoria contínua da segurança no desenvolvimento e uso de nossos sistemas é possível, praticável e essencial. Vamos agir. Caso ainda tenha dúvidas ou precise de ajuda, conte com a Conviso!
Veja também:
