No começo desta semana publiquei um artigo no blog da Conviso que reproduzo abaixo, fazendo uma provocação com a responsabilidade compartilhada entre empresas e fábricas de software na segurança das aplicações colocadas no mercado. Como de costume, uma cópia está disponível para leitura on-line ou download pelo Scribd.
Introdução
Quando uma empresa tem uma ou mais vulnerabilidades do seu Ambiente Informatizado exploradas por um atacante, as conseqüências podem ir da exposição negativa da imagem perante a sociedade até prejuízos financeiros decorrentes da parada de um processo, como no caso de um comércio eletrônico.
Mas quando este incidente também afeta os clientes das empresas, o que pode acontecer e como este risco pode ser reduzido a um nível aceitável? Ocorrências desta natureza tem aparecido com freqüência e retirando os casos onde as pessoas são vitimadas por quadrilhas especializadas em phishing [1], cenários agressivos aparecem no Brasil:
- Em agosto de 2010 mais de cinco milhões de web sites hospedados em um provedor estavam sendo utilizados para propagação de malware [2], e no Brasil os web sites das empresas Vivo e Oi [3] sofreram ataques similares.
- Dados pessoais de 12 milhões de pessoas que participaram do Exame Nacional do Ensino Médio (ENEM) vazaram de uma base de dados restrita, expondo-as a serem vítimas de crimes virtuais, como furto de identidade. [4]
O que está acontecendo
Como resultado, algumas pessoas tem utilizado instrumentos presentes no Código Civil e no Código do Consumidor para buscar reparações em diferentes esferas. Em alguns casos, a responsabilidade é compartilhada não só pela empresa que hospedava o componente onde o problema foi gerado, mas ainda outras envolvidas no processo de alguma forma [5]. A elaboração de leis e regulamentações que definam regras para este cenário como forma de garantir a aplicação de critérios legais para os negócios on line, vem sendo conduzida em diversas iniciativas.
Em especial sobre falhas em aplicações podem ser interpretadas no âmbito dos processos contra empresas envolvidas, é interessante destacar duas notícias que mostram o que podemos esperar de um futuro próximo:
- O Comitê Gestor da ICP-Brasil busca a aplicação de certificados digitais nos códigos dos aplicativos de interatividade desenvolvidos por diversas empresas para a TV Digital como forma de garantir a autoria e a responsabilidade civil [6].
- Uma empresas de rastreamento e bloqueio de veículos por satélite foi condenada a restituir um de seus clientes, uma vez que o sistema utilizado para suportar o processo falhou e permitiu o furto de um caminhão. [7]
Uma proposta de mudança
Uma vez que as falhas em aplicações representam hoje entre 75% a 92% dos ataques realizados através da Internet [8], e as empresas buscam posicionar seus recursos cada vez mais através de interfaces web, o que fazer para ter aplicações mais seguras e reduzir o risco de impactos diretos e colaterais da exploração de vulnerabilidades?
Onde as fábricas de software falham
As fábricas de software deveriam implementar controles que garantissem a remoção de vulnerabilidades óbvias de seus produtos, e não é isso que tem acontecido. Desde a sua primeira edição em 2004, o OWASP Top 10 [9] apresenta falhas persistentes em aplicações web e disponibiliza projetos para que estas sejam corrigidas ainda no ciclo de desenvolvimento, mas elas ainda ocorrem freqüentemente.
As causas estão todas na inexistência de um ciclo de desenvolvimento seguro, onde não existem controles que verificam o nível de segurança dos releases desenvolvidos, como ainda é comum a ausência de processos que garantam a capacitação contínua dos desenvolvedores como forma de aumentar gradativamente a qualidade da segurança embutida no produto.
Mas antes de se apontar o dedo para as fábricas de software, existe um ponto que deve ser considerado com o mesmo peso para uma avaliação: o que as empresas que compram software tem feito para mudar este cenário?
Onde as empresas falham
Segurança e performance são competências antagônicas que devem ser equilibradas para garantir o atendimento às necessidades do cliente dentro de um nível de segurança adequado. Para garantir o resultado aceitável desta equação, é necessário investir em um esforço similar ao empregado para outras atividades de suporte ao produto final comuns no desenvolvimento de software, tais como design de interface e conectores com produtos de mercado. O problema é que esta necessidade não é atendida pelas empresas.
O Ponemon Institute publicou a pesquisa “State of Web Application Security” citada anteriormente neste artigo, que foi realizada com 638 empresas de grande porte nos Estados Unidos e mostrou uma realidade que atesta a afirmação anterior:
- Quase 70% dos entrevistados não consideram que o orçamento para segurança das aplicações web é suficiente.
- Das vulnerabilidades consideradas urgentes nas empresas, 34% não são consertadas e 55% dos entrevistados acreditam que os desenvolvedores são ocupados demais com outras atividades para adequar as falhas de segurança.
A Responsabilidade Compartilhada
Seria inocente esperar uma mudança imediata dos dois lados mediante esta situação, uma vez que são necessários recursos extras aos já previstos e o atendimento de um nível de maturidade que só o tempo permite chegar. Porém existe pelo menos uma ação que pode ser tomada para mudar este cenário: assumir a responsabilidade compartilhada.
A primeira ação a ser considerada, é estabelecer contratos que deixem claro quais são os papéis de cada um. O OWASP Legal Project [10] apresenta o “OWASP Secure Software Development Contract Annex” como um modelo para ser utilizado nesta ação.
O objetivo do documento é servir de base para garantir o atendimento de um nível de proteção adequado para o software através da definição de papéis no processo de desenvolvimento, estabelecimento das áreas onde os controles de segurança devem ser considerados e ainda formalizar o uso de testes e recursos técnicos específicos.
Mais do que uma ação isolada e ineficaz para injetar a responsabilidade pela segurança das aplicações para um dos dois lados, é fundamental entender que a mudança será atingida se algumas premissas forem aceitas e consideradas como base para o processo.
Níveis de proteção racionais
O contrato deve prever que o nível de proteção do software irá variar de acordo com o seu nível de criticidade. Aplicações diretamente relacionadas ao negócio da empresa ou que estejam sujeitas a uma regulamentação, potencialmente serão mais críticas que as demais. Aplicar o mesmo nível de proteção em todos os produtos não é uma ação racional e muito provavelmente vai fazer a fábrica de software alocar um esforço que poderia ser evitado, e a empresa irá pagar esta conta.
Com isso, o programa será em pouco tempo criticado com razão, considerado um custo desnecessário e eliminado. É fundamental ter critérios adequados de onde, como e com qual nível de rigor os controles deverão ser aplicados.
Compartilhamento de atividades
Para que as responsabilidades sejam compartilhadas, é fundamental que o mesmo ocorra com as atividades relacionadas. A fábrica de software deverá ter um processo de desenvolvimento seguro como parte do processo, porém a empresa que adquire a aplicação tem como obrigações mínimas garantir que o processo de desenvolvimento seguro não será atropelado por motivos de negócio que não considerem todo o trabalho de planejamento estabelecido. Se for realmente necessário, a área solicitante deve formalmente – ou mesmo legalmente? – assumir a responsabilidade por isso.
Além disso, os componentes de arquitetura utilizados devem passar pelos mesmos critérios de segurança, uma vez que falhas e vulnerabilidades nestes componentes podem comprometer o nível de segurança do software.
Evolução contínua
O processo deve ser pensado como algo que irá aumentar o nível de rigor de forma crescente e contínua. Os termos apresentados no exemplo do documento publicado pelo OWASP devem ser considerados como uma base para ser adaptada pelos advogados de cada empresa, o que irá variar muito não só pelas características organizacionais, mas ainda de acordo com o mercado de atuação e regras setoriais específicas (ex. PCI DSS).
Uma proposta racional é estabelecer métricas de acompanhamento e reuniões de status entre às partes, onde a meta de atingir um nível de excelência no desenvolvimento seguro poderá ser atingida aos poucos. Todas as metodologias de desenvolvimento seguro apresentam propostas para este tipo de controle, é buscar o que for mais adequado para a realidade de cada empresa e adaptar.
Conclusão
Este artigo é uma provocação com uma sugestão e deve ser entendido desta forma. Certamente, a primeira pergunta que surge na leitura é: quem paga esta conta?
A primeira resposta acaba sendo a comum a produtos com melhorias: o cliente final. Porém, vale pensar em todo este processo como um modelo de negócios, algo que irá potencializar os produtos em um mercado onde estabelecer e garantir um nível de segurança adequado é algo desejado por todos os clientes que usam a Internet para suas transações.
No começo da Internet os provedores eram pagos e quem conseguia um preço menor com nível de qualidade similar (ou mesmo inferior …) a seus concorrentes abocanhava boa parte do mercado. Um dia uma grande empresa decidiu prestar o serviço de graça para a sociedade, e o modelo ruiu. Com a evolução dos processos legais e a potencial perda de clientes para concorrentes que apresentam um nível de segurança superior – ainda que esta impressão exista por nunca terem sofrido uma perda – quem ficar para trás vai acabar pagando uma conta bem mais cara.
Sobre o Autor
Eduardo Vianna de Camargo Neves trabalha com Segurança da Informação desde 1997, tendo atuado como auditor, consultor e Security Officer. É sócio-fundador e Gerente de Operações da Conviso IT Security, responsável pela administração e estratégia da empresa. Serve ainda como membro do Capítulo Brasil do OWASP, do OWASP Global Education Committee na América Latina e voluntário no (ISC)2.
