Artigos

Responsabilidade Compartilhada

Eduardo Vianna de Camargo Neves

Conviso IT Security | Operations Team

BRASILIA | CURITIBA | SÃO PAULO

Escritório Central

Rua Marechal Hermes 678 CJ 32

CEP 80530-230, Curitiba, PR

t (41) 3095.5736

t (41) 3095.3986

www.conviso.com.br

Responsabilidade Compartilhadapor Eduardo Vianna de Camargo Neves

Conviso IT Security | Operations Team

22 de agosto de 2010

IntroduçãoQuando 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á acontecendoComo 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

d o s a p l i c a t i v o s d e i n t e r a t i v i d a d e

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çaUma 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

Conviso IT Security

Artigos | Responsabilidade Compartilhada! 1

segurança dos releases desenvolvidos, como

ainda é comum a ausência de processos que

garantam a capaci taçã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 prob lema é que esta

necessidade não é atendida pelas empresas.

O Ponemon Institute publicou a pesquisa “State

o f We b A p p l i c a t i o n S e c u r i t y ” c i t a d a

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 ent rev is tados não

cons ideram 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 CompartilhadaSeria 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

apl icaçõ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 cr i t ic idade. Apl icações d i retamente

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 responsab i l idades se jam

compartilhadas, é fundamental que o mesmo

ocorra com as atividades relacionadas. A fábrica

de software deverá ter um processo de

Conviso IT Security

Artigos | Responsabilidade Compartilhada! 2

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 fa lhas 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ãoEste 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.

Referências1. Casos de phishing mais que dobraram no

Brasil em um ano: Matéria publicada pelo

Portal Exame.

2. Malware pode ter contaminado 5 milhões de

sites em serviço de hospedagem: Matéria

publicada pelo IDG Now!.

3. Site da Vivo é invadido por hackers: Matéria

publicada no portal Bem Paraná e Invasão

no site da Oi dissemina vírus para cerca de

140 mil usuários: Matéria publicada pelo

IDG Now!.

4. PF pode investigar vazamento de dados de

inscritos no Enem: Matéria publicada pelo

portal Terra.

5. Cobrança indevida de compra não finalizada

pela internet gera indenização e Mercado

Livre e Caixa Econômica devem indenizar

cliente por golpe de estelionatários, notícias

publicadas no web site DNT.

6. TV digital usará certificado digital como

forma de garantir a autoria e a

responsabilidade civil, matéria publicada no

web site DNT.

Conviso IT Security

Artigos | Responsabilidade Compartilhada! 3

7. Empresa será indenizada por falha no

sistema de rastreamento, matéria publicada

no web site DNT.

8. Conforme dados apresentados na pesquisa

State of Web Application Security do

Ponemon Institute e no documento A

CISO’s Guide to Application Security

preparado pelo CIO Custom Solutions

Group para a Fortity.

9. O OWASP Top 10 apresenta a lista com as

dez vulnerabilidades mais críticas em

aplicações web.

10. O OWASP Legal Project é uma iniciativa do

OWASP para estabelecer requerimentos

legais entre as partes envolvidas no

processo de desenvolvimento de software

que aumentem o nível de segurança dos

produtos envolvidos.

Sobre o AutorEduardo 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 Globa l Educat ion

Committee na América Latina e voluntário no

(ISC)2.

Conviso IT Security

Artigos | Responsabilidade Compartilhada! 4