• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Computação Confiável - Lições aprendidas pela Microsoft sobre Desenvolvimento Seguro
 

Computação Confiável - Lições aprendidas pela Microsoft sobre Desenvolvimento Seguro

on

  • 655 views

A segurança não é um campo estático – ela evolui constantemente à medida que os invasores atacam, os defensores defendem e cada lado aprende mais sobre as técnicas do outro. A segurança é ...

A segurança não é um campo estático – ela evolui constantemente à medida que os invasores atacam, os defensores defendem e cada lado aprende mais sobre as técnicas do outro. A segurança é uma corrida de armamento. Para ficar à frente e prever as manobras dos invasores, nós, os defensores, devemos aprender com nossos erros e criar formas melhores de impedir que os usuários sejam comprometidos.

Statistics

Views

Total Views
655
Views on SlideShare
654
Embed Views
1

Actions

Likes
0
Downloads
4
Comments
0

1 Embed 1

http://www.linkedin.com 1

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

CC Attribution-NonCommercial LicenseCC Attribution-NonCommercial License

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Computação Confiável - Lições aprendidas pela Microsoft sobre Desenvolvimento Seguro Computação Confiável - Lições aprendidas pela Microsoft sobre Desenvolvimento Seguro Document Transcript

    • Computação confiável Lições aprendidas em 5 anos de criação de softwares mais seguros Michael Howard - MicrosoftFonte: http://msdn.microsoft.com/pt-br/magazine/cc163310.aspx - Acessado em 08 denovembro de 2012ConteúdoNão se trata apenas do códigoCorrija o código antigo primeiroDescarte! Elimine! Exclua!As ferramentas são fundamentais... a um pontoAutomatize!Você nunca atingirá vulnerabilidades de segurança zeroA segurança é uma batalha sem fimNão há um boletim de segurança mágicoO mantra “muitos olhos” está certo!A atual negação de serviço é a exploração de amanhãConsiderações finaisHá cinco anos, Bill Gates enviou um memorando a todos os funcionários da Microsoftexplicando a importância de criar um software mais seguro. Desde então, muitas pessoas naMicrosoft trabalharam para aprimorar a segurança de seus produtos. Ao fazer isso,aprendemos muito sobre quais os requisitos para a criação de um software mais seguro.A segurança não é um campo estático – ela evolui constantemente à medida que os invasoresatacam, os defensores defendem e cada lado aprende mais sobre as técnicas do outro. Asegurança é uma corrida de armamento. Para ficar à frente e prever as manobras dosinvasores, nós, os defensores, devemos aprender com nossos erros e criar formas melhores deimpedir que os usuários sejam comprometidos.Sendo assim, o que aprendemos nos últimos cinco anos? A maioria dessas lições épraticamente óbvia, mas como muitas coisas aparentes, às vezes ajuda ter alguém indicando ocaminho. Não se trata apenas do códigoA indústria de software, ou mais precisamente a indústria de qualidade de software, estáconcentrada em obter o código correto. Eu realmente não tenho problemas com isso, masmuitas vulnerabilidades de segurança não estão codificando esses problemas. Muitosproblemas têm a ver com o projeto. Se você mantiver o foco somente na detecção deproblemas de segurança no código, você perderá uma classe inteira de vulnerabilidades. Esse éum dos motivos pelos quais a Microsoft atribui a modelagem de ameaças e a análise desuperfície de ataque como parte do Processo SDL (ciclo de vida do desenvolvimento dasegurança). A modelagem de ameaças é uma técnica de análise que ajuda a identificar e
    • reduzir os pontos fracos do projeto em um produto. A análise da superfície de ataque seconcentra em quais partes de um produto de software estão expostas a usuários nãoconfiáveis, sejam locais ou remotos. Um produto com uma ampla superfície de ataque temmais código exposto a usuários não confiáveis do que um produto com uma pequenasuperfície de ataque. (Leia mais emmsdn.microsoft.com/msdnmag/issues/04/11/AttackSurface.)A vulnerabilidade de saturação do buffer RPC DNS documentada no Microsoft Security BulletinMS07-029 (consulte microsoft.com/technet/security/Bulletin/MS07-029.mspx) permite queum invasor tenha total controle de um sistema afetado. Nesse caso, houve certamente umproblema de código. No entanto, o código estava acessível a usuários anônimos e remotosquando deveria estar restrito aos administradores. Dessa forma, o problema foi umacombinação de vulnerabilidade de código e projeto. Analisei essa vulnerabilidade no blog doSDL (consulte blogs.msdn.com/sdl/archive/2007/06/28/lessons-learned-from-ms07-029-the-dns-rpc-interface-buffer-overrun.aspx).Lição aprendida: É fundamental criar modelos de ameaças para detectar pontos fracos empotencial do projeto e determinar a superfície de ataque do software. Você precisa secertificar de que todas as ameaças materiais serão atenuadas e que a superfície de ataque seráa menor possível. Corrija o código antigo primeiroNo que diz respeito à revisão de código, gosto de classificar o código pelo potencial devulnerabilidade. Escrevi um artigo sobre Segurança e a privacidade da IEEE, intitulado "AProcess for Performing Security Code Reviews" (em inglês), que explica as métricas que utilizeipara priorizar a revisão de código (você pode encontrar um link para o artigo no meu blog emblogs.msdn.com/michael_howard/archive/2006/08/01/686029.aspx).A primeira prioridade é o código antigo, pois é muito mais provável que ele tenha maisvulnerabilidades de segurança do que o código mais recente. As ameaças estão em constanteevolução. O código antigo – até mesmo o código criado há alguns anos – foi criado quando asameaças eram diferentes do que são atualmente. Além disso, as técnicas usadas para criar ocódigo antigo não têm as técnicas de defesa e práticas recomendadas mais recentes. Damesma forma, o código herdado foi criado usando bibliotecas mais antigas e menos seguras. E,finalmente, o código anterior foi criado com menos percepção situacional, em um momentoem que os desenvolvedores tinham pouco ou nenhum conhecimento de segurança.Meu conselho é simples: todo o código antigo deve ser revisado manualmente quanto avulnerabilidades de segurança. Na verdade, essa é a finalidade da fase do esforço de segurançado SDL na Microsoft. Embora o objetivo principal do SDL seja reduzir a probabilidade de osdesenvolvedores adicionarem novas vulnerabilidades a um produto, o esforço de segurança édesenvolvido para forçar a equipe de desenvolvimento a verificar se há problemas no códigoantigo.Nenhuma outra métrica que avaliamos foi tão importante ao priorizar a revisão de código –não a complexidade do código, nem a contagem do número de linhas, nem a formação do
    • código. O indicador número um da densidade potencial de vulnerabilidade é simplesmente aidade do código.Lição aprendida: Identifique todos os seus arquivos de código-fonte e classifique-os por idade,em que idade é a data de “nascimento” do código. Execute a análise estática e revisemanualmente o código, começando primeiro com o código mais antigo. Descarte! Elimine! Exclua!Às vezes, um recurso pode não ser seguro o suficiente no atual cenário de ameaças. O recursopode ter sido bom há alguns anos, mas não é seguro atualmente não devido a vulnerabilidadesde código, mas sim às alterações no atual ambiente computacional.Um bom exemplo disso é o serviço Alerter no Windows® que deveria mostrar o status deimpressão e enviar breves mensagens que seriam exibidas como pop-up na tela do outrousuário. Isso se tornou rapidamente um mecanismo de spam. Portanto, tomamos a difícildecisão de desativar o serviço por padrão no Windows XP SP2 e então o removemostotalmente do Windows Vista®.Outro bom exemplo são os protocolos herdados IPX e SPX. (Sim, sei que o IPv4 também éantigo e tem seus próprios problemas.) No Windows Vista, simplesmente removemos osuporte para o Microsoft® Client for NetWare Networks, pois o código era muito antigo e nãoera utilizado pela maioria dos usuários.Com o tempo, você verá que a Microsoft remove cuidadosamente os recursos mais antigos.Como, alguns usuários contam com determinados recursos, é importante equilibrar o riscocom a utilidade.Lição aprendida: Identifique os recursos antigos que podem ser problemas de segurança alongo prazo e elabore um plano para eliminar tais recursos. Talvez a primeira etapa sejacontinuar lançando o curso, mas desativá-lo por padrão. Então, na próxima versão do produto,o recurso pode ser totalmente removido, mas disponibilizado como um download da Webpara aqueles que dependem absolutamente dele. Finalmente, interrompa o suporte para orecurso. Apenas lembre-se de manter os clientes informados. As ferramentas são fundamentais... a um pontoNo passado, eu era extremamente crítico em relação às ferramentas. Na verdade, não daspróprias ferramentas, mas a confiança excessiva de alguns desenvolvedores em relação a essasferramentas. Por ferramentas, quero dizer análise estática de código, análise binária esimilares que possam ajudar a determinar vulnerabilidades de segurança. Em meus velhostempos, eu era de certa forma menos rígido em relação a isso.Se você tem muito código – digamos, um milhão de linhas – torna-se muito mais difícil analisartodo esse código manualmente. As ferramentas são práticas porque analisam rapidamente
    • grandes faixas de código. No entanto, elas não substituem o intelecto humano. Além disso,muitas delas tendem a não detectar vulnerabilidades por estarem preocupadas em manteruma taxa de falso-positivos e falso-negativos o mais baixa possível. E, para ser totalmentehonesto, muitas ferramentas de análise de segurança criam uma quantidade tão ampla deerros e avisos que pode ser muito difícil determinar quais bugs são reais.É claro, se você vir uma grande quantidade de problemas, isso não significa que podesimplesmente ignorar o resultado da ferramenta! Quando realizamos uma análise da causados efeitos de uma vulnerabilidade de segurança, sempre temos que nos perguntar por que oproblema não foi detectado pelas nossas ferramentas. Existem três motivos possíveis: aferramenta não detectou a vulnerabilidade, a ferramenta a detectou mas separouerroneamente o problema como prioridade baixa e a ferramenta de fato detectou o problemae o revisor humano o separou erroneamente. Essa análise nos permite ajustar as nossasferramentas e treinamento ao longo do tempo.As ferramentas de análise também são muito boas para determinar o potencial devulnerabilidades de segurança no código. Digamos que você tenha dois produtos, cada umcom aproximadamente 100.000 linhas de código C++. Você executa suas ferramentas em cadabase de código – para esse exemplo, vamos pressupor que você usa os comutadores decompilador /W4 e /analyze. A primeira base de código produz 121 avisos /W4 e 19 avisos/analyze, enquanto a segunda base de código tem 235 avisos /W4 e 65 avisos /analyze. Qualconjunto de código você acha que precisa de mais revisão?Finalmente, as ferramentas são excelentes quando executadas em código novo ou modificadoantes da verificação, pois podem atuar como protetores do código e detectar determinadasclasses de bug no início do processo.Lição aprendida: As ferramentas de análise podem ajudá-lo a determinar qual o cuidadonecessário ao seu código. Você também pode usar o resultado da análise para determinar orisco geral do código. Use as ferramentas no momento da verificação para detectar os bugsprecocemente. Além disso, execute as ferramentas com freqüência, de forma que possa lidarrapidamente com novos problemas – se executar as ferramentas somente em intervalos demeses poderá acabar tendo que lidar com centenas de avisos de uma só vez. Automatize!No início de um programa de melhoria de segurança, há uma quantidade significativa detrabalho manual – revisão manual de código, revisões manuais de projeto e assim por diante.Para realmente elevar seu trabalho, você precisa automatizar o máximo possível do processo.Em nossa equipe, criamos muitas ferramentas personalizadas e criamos um site interno daWeb para coletar dados de ferramentas, de forma que a equipe de segurança central pudesserevisar o resultado das ferramentas. Quando é proposta uma melhoria do SDL, essa propostadeve incluir uma forma de automatizar a melhoria. Os principais motivadores para aautomação são a escalabilidade e o uso constante. Se você tiver uma quantidade significativa
    • de código, será necessário automatizar. E, se você quiser que partes de um processo sejamrepetidas constantemente, então a automação é obviamente a solução.Lição aprendida: Sempre que possível busque a automação. Crie ou compre ferramentas queverifiquem o código e carreguem os resultados em um local central para análise porespecialistas de segurança. Você nunca atingirá vulnerabilidades de segurança zeroÉ triste, mas é verdade, mas você nunca terá vulnerabilidades de segurança zero. Lembroquando lancei uma das primeiras atualizações de segurança para o Windows Vista. Algunsusuários ficaram surpresos porque pensaram que a Microsoft alegava ter resolvido o problemade segurança com o Windows Vista. Primeiro, eu não conheço alguém que tenha feito essaalegação e, segundo, simplesmente não é possível atingir vulnerabilidades de segurança zero.Embora as vulnerabilidades de segurança zero sejam o ideal, é ilusório achar que é possívelatingir essa condição. O fato é que o cenário da tecnologia está sempre em fluxo, as ameaçassão um alvo em movimento e a pesquisa de segurança está em andamento. Disseanteriormente que a segurança é uma corrida de armamento. Adicionamos defesas aos nossosprodutos e os invasores se adaptam.O seu código pode parecer totalmente isento de vulnerabilidades hoje, mas isso pode mudaramanhã quando um novo tipo de vulnerabilidade for detectado. Por exemplo, em 15 deoutubro de 2003, a Microsoft lançou um boletim de segurança que corrigia umavulnerabilidade de script em diferentes locais no Outlook® Web Access, incluído com oMicrosoft Exchange 5.5. Em 4 de março do ano seguinte, a Sanctum (adquirida pela Watchfiree agora pela IBM) divulgou um artigo que descrevia uma nova vulnerabilidade de script emdiferentes locais denominada divisão de resposta de HTTP. Seis meses depois, a Microsoftdivulgou outra atualização de segurança para o Outlook Web Access no Microsoft Exchange5.5 para corrigir uma vulnerabilidade de divisão de resposta de HTTP. Então, o que aconteceu?Em síntese, no momento em que o primeiro boletim foi lançado, os problemas de divisão deresposta não eram conhecidos, mas o cenário mudou.Lição aprendida: Certifique-se de que as pessoas na organização saibam que a meta é reduziras vulnerabilidades de segurança, mas que você nunca atingirá problemas de segurança zeroenquanto houver invasores buscando novas técnicas e vulnerabilidades. A segurança é uma batalha sem fimNunca haverá um momento que você dirá, “concluímos a parte de segurança; o problemaagora está resolvido”. Essa é uma extensão do ponto anterior, mas com um ângulo levementediferente. É extremamente importante que você mantenha um treinamento contínuo paraseus engenheiros. Caso contrário, as habilidades podem ficar desatualizadas e a urgência sedissipar ao longo do tempo. A segurança é fundamental e proteger os seus sistemas é
    • imprescindível. Como dito no ponto anterior, as novas ameaças e vulnerabilidades estãoconstantemente sendo detectadas. Portanto, você deve tratar sempre a segurança como umatarefa que nunca é concluída.Você também deve se conscientizar de que não há mais algo de especial em relação àsegurança. A segurança é simplesmente parte da conclusão do trabalho.Lição aprendida: Continue fornecendo treinamento contínuo aos seus engenheiros ecertifique-se de que eles sempre estejam cientes da importância de solucionar os problemasde segurança. Não há um boletim de segurança mágicoAs pessoas me perguntam com frequência “qual é o elemento mais importante do SDL?”. Aresposta é: tudo. Se uma parte do SDL comprovar não ser útil, ela será excluída do SDL. Cadaparte do SDL leva a uma redução nas vulnerabilidades de segurança. Portanto, quando escutoalguém dizer que tem uma tarefa única e mágica para solucionar a segurança, como executarferramentas de análise estática ou treinar pessoas, ele não está cobrindo todas as suas basesde segurança. Com certeza, as ferramentas de análise estática têm seu lugar e ensinar osusuários é fundamental, mas não por eles mesmos. A segurança deve ser completa, bem comodeve ser parte do processo.Lição aprendida Certifique-se de que você esteja solucionando a segurança de todos osângulos disponíveis. Caso contrário, você precisará alterar o seu processo! O mantra “muitos olhos” está certo!Renomado defensor de código-fonte, Eric Raymond, disse “tendo olhos suficientes, todos osbugs são superficiais”. Ele está certo. Mas eu considero que essa afirmação simplificada pecaem um ponto principal. Ela deveria continuar assim, “desde que os olhos sejam incentivados einstruídos”.Na Microsoft, podemos exigir que as pessoas adotem melhorias de processo, pois essesrequisitos fazem parte do trabalho. Esse é o incentivo. Oferecemos ensino de várias formas,como treinamentos dinâmicos, laboratórios e treinamento online. Portanto, há bastantematerial para garantir que os engenheiros estejam atualizados com o que está acontecendo nofront de segurança.Lição aprendida: Quanto mais olhos houver no código, melhor, mas isso deve ser feito emuma determinada estrutura. Você deve garantir que os desenvolvedores fornecendo a revisãodo código tenham um incentivo para que se preocupem em se adaptar ao seu atual processo,bem como que estejam treinados em relação às mais recentes ameaças de segurança.
    • A atual negação de serviço é a exploração de amanhãMuitos fornecedores de software, incluindo a Microsoft, aprenderam essa lição arduamente.Os engenheiros podem analisar o problema de código e rapidamente descartá-lo por ser“apenas um DoS”. Lembre-se de que o mundo da pesquisa em segurança está em constanteevolução e as pressuposições sobre determinadas classes de vulnerabilidade podem mudar danoite para o dia.Lição aprendida: Não seja rápido ao descartar um problema de negação de serviço. Compouco trabalho, os usuários maliciosos podem transformar vulnerabilidades de DoS emverdadeiras vulnerabilidades de execução de código. Considerações finaisSe há algo que aprendi nos últimos anos é que, no que diz respeito à segurança, você precisaestar preparado para ter suas ideias e ponto de vista constantemente desafiado, além de estarsempre atualizado sobre os problemas mais recentes. Se você seguir à risca as liçõesapresentadas neste artigo, você se sairá muito bem.Michael Howard é um dos principais gerentes de programas de segurança na Microsoft e seconcentra no aprimoramento e nas melhores práticas do processo seguro. Ele é o co-autor demuitos livros de segurança, incluindo Writing Secure Code for Windows Vista, The SecurityDevelopment Lifecycle, Writing Secure Code e 19 Deadly Sins of Software Security (em inglês).