Building

Security In
Maturity
Model

BSIMM-V

Outubro 2013
Release 5.1.2

Autores
BSIMM4 e BSIMM-V: Gary McGraw, Ph.D., Sammy Migues, & Jacob West
BSIMM1 at 3: Gary McGraw, Ph.D., Brian Chess, Ph.D., & Sammy Migues

Agradecimentos
Agradecemos aos sessenta e sete executivos de classe mundial que lideram as iniciativas de segurana de
software que estudamos ao redor do mundo para criar o BSIMM-V. Elesincluem: Adobe (Brad Arkin),
Aetna (Jim Routh), Bank of America (Jim Apple), Box, Capital One (Keith Gordon), Comerica Bank
(George Smirnoff), EMC (Eric Baize), Epsilon (Chris Ray), F-Secure (Antti Vh-Sipil), Fannie Mae
(Stan Wisseman), Fidelity (David Smith), Goldman Sachs (Phil Venables), HSBC (Malcolm Kelly and
Simon Hales), Intel, Intuit, JPMorgan Chase & Co. (Jeff Cohen), Lender Processing Services Inc., Marks
and Spencer (Noel Dunne), Mashery (Chris Lippi), McAfee (James Ransome), McKesson (Mike Wilson),
Microsoft (Steve Lipner), NetSuite (Brian Chess), Neustar (Jonathan Coombes), Nokia (JanneUusilehto),
Nokia Siemens Networks (Konstantin Shemyak), PayPal (Erick Lee), Pearson Learning Technologies
(Aaron Weaver), QUALCOMM (Alex Gantman), Rackspace (Jim Freeman), Salesforce (Robert Fly),
Sallie Mae (Jerry Archer), SAP (Gerhard Oswald), Sony Mobile (Per-OlofPersson), Standard Life (Alan
Stevens), SWIFT (Peter De Gersem and Alain Desausoi), Symantec (Gary Phillips), Telecom Italia (Marco
Bavazzano),Thomson Reuters (Timothy Mathias), TomTom (XanderHeemskerk), Vanguard (Samuel M.
DAmore,Jr.), Visa (Gary Warzala), VMware (Iain Mulholland), Wells Fargo (Steve Adegbite) e Zynga. Para
aqueles que no foram nominalmente relacionados, vocs sabem quem vocs so e ns no poderamos ter
feito este trabalho sem vocs.
Agradecemos Gabriele Giuseppini, David Harper, John Holland, Paco Hope, Matias Madou, e Florence Mottay
que ajudaram na coleta de dados na Europa. Agradecemos Andres Cools, Partha Dutta, Nabil Hannan, Jason
Hills, Girish Janardhanudu, Troy Jones, Drew Kilbourne, Todd Lukens, Brian Mizelle, Kabir Mulchandani,
Jason Rouse, Joel Scambray, Jay Schulman, Carl Schwarcz, Rajiv Sinha, Mike Ware, Caroline Wong, and Dave
Wong que ajudaram na coleta de dados nos EUA. Agradecemos a Matteo Meucci (Minded Security); Markus
Schumacher (Virtual Forge); Susana Romaniz, sua equipe (UTN-FRSF) e Ivan Arce (Fundacin Sadosky); e
Diogo Rispoli e Carolina Girardi Alves; para as tradues em Italiano, Alemo, Espanhol e Portugus do Brasil ,
respectivamente. Agrademos a Betsy Nichols (PlexLogic) pela anlise estatstica complexa no BSIMM2.
Agradecemos ao Pravir Chandra que construiu um esboo do modelo de maturidade sob contrato com a Fortify
e assim provocou este projeto. Agradecemos a John Steven por construir o primeiro framework sobresegurana
de software descrito no captulo 10 -Segurana deSoftware. Agradecemos a John Steven, Roger Thornton, Mike
Ware, Jim DelGrosso eRobert Hines por nos ajudar a forjar o SSF (sigla em ingls) descrito aqui.
Os dados para o Building Security In Maturity Model foram coletados pela Cigital e HP Fortify. As tradues
para o modelo BSIMM foram realizadas por VirtualForge (Alemo), Minded Security (Italiano), e UTN-FRSF e
Fundacin Sadosky (Espanhol).

Licena do BSIMM-V
Este trabalho licenciado de acordo com Creative Commons Attribution-Share Alike 3.0 License. Para acessar uma
cpia desta licena, visite http://creativecommons.org/licenses/by-sa/3.0/ ou envie uma carta para Creative Commons,
171 Second Street, Suite 300, San Francisco, California, 94105, USA.

ii

Resumo Executivo
O Building Security In Maturity Model (BSIMM) o resultado do estudo de vrios anos
sobre iniciativas de segurana de software do mundo real. Ns apresentamos o modelo que
foi construindo diretamente de dados observados em sessenta e sete inciativas de segurana de
software de diversas empresas, entre elas: Adobe, Aetna, Bankof America, Box, Capital One,
Comerica Bank, EMC, Epsilon, F-Secure, Fannie Mae, Fidelity,Goldman Sachs, HSBC, Intel,
Intuit, JPMorgan Chase & Co., Lender Processing ServicesInc., Marks and Spencer, Mashery,
McAfee, McKesson, Microsoft, NetSuite, Neustar, Nokia,Nokia Siemens Networks, PayPal,
Pearson Learning Technologies, QUALCOMM, Rackspace,Salesforce, Sallie Mae, SAP, Sony
Mobile, Standard Life, SWIFT, Symantec, Telecom Italia,Thomson Reuters, TomTom, Vanguard,
Visa, VMware, Wells Fargo, e Zynga.
O BSIMM um instrumento de medida para a segurana de software. O melhor modo de utilizar
o BSIMM comparar e contrastar a sua prpria iniciativa com os dados sobre o que outras
organizaes esto fazendo contidos no modelo. Voc pode ento identificar metas e objetivos por
conta prpria e observar o BSIMM para determinar qual atividade adicional faz sentido para voc.
Os dados do BSIMM mostram o quanto iniciativas altamente maduras so bem equilibradas
implementando uma srie de atividades em todas as doze prticas descritas pelo modelo. O
modelo tambm descreve como iniciativas maduras de segurana de software se desenvolvem,
mudam e se aprimoram ao longo do tempo.

2013

iii

iv
BSIMM-V

Sumrio
Introduo..................................................................................................................6
BSIMM-V...........................................................................................................7

Pblico Alvo........................................................................................................7
Mtodo................................................................................................................7
Participantes.........................................................................................................8
Objetivos.............................................................................................................9
Terminologia........................................................................................................9
Papis.........................................................................................................................10

Liderana Executiva............................................................................................10

O Grupo de Segurana de Software (SSG)..........................................................10

Todos os Outros..................................................................................................11

Identificando um Satlite....................................................................................12
Colocando o BSIMM-V em Uso................................................................................12

Resultados do BSIMM-V....................................................................................12

Novas Atividades para Observao no BSIMM6.................................................15

Avaliando a Sua Empresa com o BSIMM-V........................................................15

Estudando Grupos de Empresas no BSIMM-V...................................................17
BSIMM como um Estudo Longitudinal.....................................................................20

BSIMM ao Longo do Tempo..............................................................................21
A Comunidade BSIMM.............................................................................................22
O Framework de Segurana de Software.....................................................................23
BSIMM-V.................................................................................................................25

GOVERNANA: Estratgia e Mtricas (SM).....................................................26

GOVERNANA: Conformidade e Poltica (CP)...............................................28

GOVERNANA: Treinamento (T)....................................................................30

INTELIGNCIA: Modelos de Ataque (AM)......................................................32

INTELIGNCIA: Funcionalidades e Projeto de Segurana (SFD) 34

INTELIGNCIA: Padres e Requisitos (SR)......................................................36

SSDL TOUCHPOINTS: Anlise Arquitetural (AA)...........................................38

SSDL TOUCHPOINTS: Reviso de Cdigo (CR)............................................40

SSDL TOUCHPOINTS: Testes de Segurana (ST)............................................42

IMPLANTAO: Testes de Penetrao (PT).....................................................44

IMPLANTAO: Ambiente de Software (SE)...................................................46
IMPLANTAO: Gesto de Configurao e Gesto de Vulnerabilidade (CMVM)....47

O Esqueleto do BSIMM............................................................................................49
Classificando as Atividades do BSIMM-V..................................................................61

Atividades Principais do BSIMM........................................................................61

Atividades Observadas nas Sessenta e Sete Empresas............................................61
Apndice: Ajustando o BSIMM4 para o BSIMM-V...................................................63

2013

Ns comeamos com uma breve descrio da funo e importncia de uma iniciativa de segurana de software. Ento
ns explicamos o nosso modelo e o mtodo que utilizamos para quantificar a situao de uma iniciativa. Desde que
o estudo do BSIMM comeou em 2008, ns estudamos 72 iniciativas, que incluram 166 medies distintas porque
algumas empresas usam o BSIMM para avaliar cada uma das suas unidades de negcios e algumas empresas foram
avaliadas mais de uma vez. Para garantir a relevncia continua de cada dado que reportamos, exclumos medidas com
mais de 48 meses do BSIMM-V. O conjunto de dados atual compreende 161 medies distintas coletadas de 67
empresas. Agradecemos por repetir as medies. Ns no reportamos apenas as prticas atuais, mas tambm a maneira
como algumas iniciativas evoluram ao longo dos anos. Dedicamos a parte final do documento para uma explanao
detalhada das 112 atividades que agora compreendem o nosso modelo e um resumo dos dados brutos que coletamos.
Decidimos revisar a descrio de cada atividade do BSIMM-V e tambm adicionamos uma nova atividade ao modelo.
Nosso trabalho com o modelo BSIMM mostra que mensurar a iniciativa de segurana de software de uma empresa
tanto possvel quanto extremamente til. As avaliaes do BSIMM podem ser utilizadas para planejar, estruturar
e executar a evoluo de uma iniciativa de segurana de software. Ao longo do tempo, as empresas participantes do
projeto BSIMM mostram melhorias quantificveis na sua iniciativa de segurana de software.

Introduo

segurana de software comeou a florescer como uma disciplina separada da segurana computacional e de
redes no final dos anos noventa. Pesquisadores comearam a colocar maior nfase no estudo dos meios que
um programador poderia contribuir ou involuntariamente prejudicar a segurana de um sistema computacional.
Quais tipos de bugs ou falhas podem levar a problemas de segurana? Como podemos identificar problemas
sistematicamente?
Na metade da dcada seguinte, havia um consenso emergente que a criao de software seguro demandaria mais do
que somente pessoas inteligentes trabalhando. Obter a segurana correta significa estar envolvido com o processo de
desenvolvimento de software.
A partir da, os profissionais vieram a descobrir que o processo sozinho tambm insuficiente. Segurana de software
engloba aspectos do negcio, sociais e organizacionais. Usamos o termo Iniciativa de Segurana de Software para nos
referirmos a todas as atividades empreendidas com o propositivo de construir software seguro.

BSIMM-V

Building Security In Maturity Model (BSIMM, pronuncia-se bee simm) um estudo sobre iniciativas de
segurana de software existentes. A partir da quantificao das prticas de diferentes organizaes, ns podemos
descrever a base comum dividida por todas, bem como as variaes que fazem cada uma nica. Nosso objetivo
ajudar a larga comunidade de segurana de softwarea planejar, executar e mensurar suas iniciativas prprias. O BSIMM
no um guia de como fazer, muito menos uma prescrio uniforme para todos. Alternativamente, o BSIMM o
reflexo do estado da arte da segurana de software.

BSIMM-V
O propsito do BSIMM quantificar as atividades realizadas por iniciativas reais de segurana de software. Como essas
iniciativas fazem uso de diferentes metodologias e terminologias, o BSIMM requer um framework que nos permita
descrever todas as iniciativas de uma maneira uniforme. Nosso Framework de Segurana de Software (sigla em ingls SSF)
e as descries das atividades proveem um vocabulrio comum para explorar os elementos marcantes de uma iniciativa
de segurana de software, assim permitindo-nos comparar iniciativas que utilizam termos diferentes, operam em escalas
diferentes, existem em setores de mercado diferentes ou criam diferentes tipos de produtos.
Classificamos o nosso trabalho como um modelo de maturidade porque aperfeioar a segurana de software
quase sempre significa modificar a forma como uma organizao trabalha algo que no acontece da noite para o
dia. Entendemos que nem todas as organizaes precisam alcanar as mesmas metas, mas acreditamos que todas as
organizaes podem se beneficiar por utilizarem o mesmo padro de medio.
BSIMM-V a quinta e maior verso do modelo BSIMM. Ela inclui descries de atividades atualizadas, uma nova
atividade e dados de 67 empresas e um estudo longitudinal.

Pblico Alvo
O BSIMM pode ser utilizado por qualquer pessoa responsvel por criar e executar iniciativas de segurana de software.
Ns observamos que iniciativas de segurana de software de sucesso so tipicamente executadas por um executivo snior
que se reporta aos nveis mais altos de uma organizao. Estes executivos lideram um grupo interno que podemos chamar
de Grupo de Segurana de Software (sigla em ingls SSG), encarregado de executar diretamente ou facilitar as atividades
descridas no BSIMM. O BSIMM foi escrito com o SSG e a liderana do SSG em mente.
Esperamos dos leitores a familiaridade com a literatura sobre segurana de software. Voc pode se tornar familiar com
vrios conceitos a partir da leitura sobre Segurana de Software e Ciclo de Desenvolvimento de Software Seguro. O
BSIMM no tenta explicar o bsico sobre segurana de software, descrever sua histria ou prover referncias a sua
literatura sempre em expanso. Proceder com o BSIMM sem se tornar familiar com a literatura de segurana de software
improvvel.

Mtodo
Construmos a primeira verso do BSIMM no outono de 2008, da seguinte forma:

Confiamos em nosso prprio conhecimento de prticas de segurana de software para criar o

framework de segurana de software (apresentamos o framework na pgina 19);

Conduzimos uma srie de nove entrevistas, em pessoa, com executivos encarregados de

iniciativas de segurana de software. A partir dessas entrevistas, identificamos uma srie
de atividades em comum, que organizamos de acordo com o Framework de Segurana de
Software;

Ento ns criamos scorecards para cada uma das nove inciativas que mostraram quais atividades
as iniciativas realizavam. Como forma de validar o nosso trabalho, ns solicitamos para que
cada participante revisasse o framework, as prticas e o scorecards que criamos para a suas
iniciativas.

Neste ponto do projeto, ns havamos usado a mesma tcnica de entrevista para conduzir avaliaes para as 63
empresas adicionais (num total de 72 empresas). (Em nove casos, nos computamos a pontuao de uma grande
empresa pontuando um determinado nmerode divises principais e ento combinando estas pontuaes em uma

2013

pontuao para a empresa.) Iniciando com o BSIMM-V, introduzimos um requisito de frescor dos dados para
excluir avaliaes com mais de 48 meses. Este requisito causou a remoo de cinco empresas do BSIMM-V (Aon,
The Depository Trust & Clearing Corporation (DTCC), Google, Scripps Networks e uma participante annima),
resultando em um conjunto de dados com 161 avaliaes distintas coletadas de 67 empresas. Como o conjunto
de dados envelhece, pretendemos diminuir a janela de frescor para 36 meses para um alinhamento melhor com os
ciclos de negcio.
Ns usamos as pontuaes resultantes para refinar o conjunto de atividades e o seu posicionamento dentro do
framework. Tambm conduzimos um segundo conjunto completo de entrevistas com vinte e um dos participantes
com o objetivo de estudar como as suas iniciativas se modificaram ao longo do tempo. Quatro participantes se
comprometeram com trs medies distintas.
Ns mantivemos os scorecards individuais das empresas em segredo, mas ns publicamos dados agregados
descrevendo o nmero de vezes que ns observamos cada atividade (ver pgina 60). Tambm publicamos
observaes sobre os subconjuntos (como os setores da indstria) quando o tamanho da amostra para o
subconjunto fosse grande o suficiente para garantir o anonimato dos participantes.

Nossa abordagem apenas os fatos no novidade na cincia ou engenharia, mas no domnio da segurana de
software ela nunca foi aplicada em grande escala. Trabalhos anteriores somente descreveram a experincia de uma
nica organizao ou ofereceram um guia normativo baseado na combinao de experincia pessoal e opinio.

Participantes
As 67 organizaes participantes so provenientes de doze verticais (com alguma sobreposio): servios financeiros
(26), fornecedores independentes de software (25), nuvem (16), empresas de tecnologia (14), telecomunicaes (5),
varejo (4), segurana (4), sade (3), meios de comunicao (3), seguradoras (2), energia (1) e provedores de servios
de internet (1). As empresas entre as 67 que gentilmente concordaram em ser identificadas incluem: Adobe, Aetna,
Bank of America, Box, Capital One, Comerica Bank, EMC, Epsilon, F-Secure, Fannie Mae, Fidelity, Goldman Sachs,
HSBC, Intel, Intuit, JPMorgan Chase & Co., Lender Processing Services Inc., Marks and Spencer, Mashery, McAfee,
McKesson, Microsoft, NetSuite, Neustar, Nokia, Nokia Siemens Networks, PayPal, Pearson Learning Technologies,
QUALCOMM, Rackspace, Salesforce, Sallie Mae, SAP, Sony Mobile, Standard Life, SWIFT, Symantec, Telecom
Italia, Thomson Reuters, TomTom, Vanguard, Visa, VMware, Wells Fargo e Zynga
Na mdia, os 67 participantes praticaram segurana de software por 4,25 anos no tempo da avaliao (com algumas
iniciativas novas fazendo a sua primeira avaliao e a iniciativa mais velha completando dezoito anos de idade em
outubro de 2013). Todas as 67 empresas concordaram que o sucesso dos seus programas depende da existncia de
um grupo dedicado a segurana de software o SSG (sigla em ingls). O tamanho mdio do SSG de 14,78 pessoas
(menor 1, maior 100, mediana 7) com outros satlites (desenvolvedores, arquitetos e pessoas na organizao
diretamente engajadas na promoo da segurana de software) na faixa de 29,6 pessoas (menor 0, maior 400, mediana
4). O nmero mdio de desenvolvedores entre os nossos alvos foi de 4.190 pessoas (menor 11, maior 30.000,
mediana 1.600) levando a um percentual mdio do SSG para o desenvolvimento de 1,4%.
Tudo isso dito, o BSIMM descreve o trabalho de 975 membros de SSG trabalhando com satlites da ordem de 1.953
pessoas para dar segurana ao software desenvolvido por 272.358 desenvolvedores.

BSIMM-V

Como um modelo descritivo, a meta do BSIMM somente observar e reportar. Gostaramos de dizer que
perambulamos na selva para observar o que pudssemos e descobrimos que macacos comem bananas em X das
Y florestas que visitamos. Perceba que o BSIMM no relata voc s poder comer bananas amarelas, no corra
enquanto come uma banana, no furtars bananas dos seus vizinhos ou qualquer outro julgamento de valor.
Observaes simples simplesmente relatadas.

Objetivos
Criamos o BSIMM a fim de aprender como as iniciativas de segurana de software funcionam e prover recursos para
pessoas procurando como criar ou melhorar a sua prpria iniciativa de segurana de software.
Em geral, qualquer iniciativa de segurana de software ser criada com alguma meta de alto nvel em mente. O
BSIMM apropriada se as suas metas de negcio para segurana de software incluem:

Decises de gesto dos riscos;

A clareza sobre o que a coisa certa a fazer para todos os envolvidos na segurana de software;
Reduo de custos atravs de padres e processos repetveis;
Melhoria da qualidade do cdigo.

Por objetos claramente observados e pelo mapeamento de prticas com mtricas sob medida para a sua prpria
iniciativa, voc pode utilizar o BSIMM como uma ferramenta de avaliao para guiar a sua prpria iniciativa de
segurana de software.
Inserir segurana de software em uma organizao demanda planejamento cuidadoso e sempre envolve uma ampla
mudana organizacional. Utilizando o BSIMM como um guia para a sua prpria iniciativa de segurana de software,
voc pode aproveitar os muitos anos de experincia captados pelo modelo. Voc deve adaptar as atividades que o
BSIMM descreve para a sua organizao (considerando cuidadosamente os objetivos que documentamos). Note que
nenhuma organizao cumpre todas as atividades descritas no BSIMM.

Terminologia
Nomenclatura sempre um problema na segurana computacional e a segurana de software no uma exceo.
Existe uma quantidade de termos que usamos no BSIMM que possuem um significado particular para ns. Aqui
esto alguns dos termos mais importantes que usamos ao longo do documento:
Atividade Aes empreendidas ou facilitadas pelo SSG como parte de uma prtica. As atividades so divididas
em trs nveis de maturidade no BSIMM. Cada atividade est diretamente associada a um objetivo.
Domnio Um dos quatro grupos mais importantes do Framework de Segurana de Software. Os domnios so:
governana, inteligncia, SSDL touchpoints e implantao. Veja na seo SSF, a seguir.
Prtica Uma das doze categorias de atividades do BSIMM. Cada domnio no SSF possui trs prticas. As
atividades em cada prtica so divididas em trs nveis de acordo com a maturidade. Veja na seo SSF a seguir.
Satlite Grupo de desenvolvedores, arquitetos, gestores e testadores de software interessados e comprometidos,
com afinidade natural para a segurana de software, que so coordenados e estimulados pela iniciativa de
segurana de software.
Ciclo de Vida de Desenvolvimento de Software Seguro (sigla em ingls SSDL) Qualquer SDLC com melhores
prticas relacionadas segurana de software.
Security Development Lifecycle (SDL) Termo usado pela Microsoft para descrever seu SSDL.
Framework de Segurana de Software (SSF) Doze prticas divididas em quatro domnios. Veja na seo SSF.
Grupo de Segurana de Software (sigla em ingls SSG) O grupo interno encarregado pela conduo e
facilitao da iniciativa de segurana de software. Temos observado que este o primeiro passo para uma
iniciativa de segurana de software.
Iniciativa de Segurana de Software Programa coordenado para inserir, medir, gerenciar e evoluir atividades
de segurana de software. Tambm conhecido como Programa Corporativo de Segurana de Software (veja
captulo 10 Segurana de Software).

2013

Papis

eterminar quem encarregado das atividades descritas no BSIMM uma parte importante para fazer uma
iniciativa de segurana de software funcionar.

Liderana Executiva

Os executivos responsveis pelas iniciativas de segurana de software estudadas possuem uma grande variedade de
qualificaes, incluindo: Diretor de Segurana de TI e Gesto de Riscos, Diretor de Controle de Aplicaes, VP (Vice
Presidente) de Produtos e Operaes, Gerente de Segurana de Produto, Gerente Snior de Segurana de Produto, SVP
(Vice Presidente Snior) de Gesto Global de Riscos, Diretor Geral de Mercados de Segurana da Informao, SVP de
Segurana da Informao e CISO (Diretor de Segurana da Informao). Tambm observamos uma ampla disperso da
posio do SSG nas empresas que estudamos. Em particular, 19 existem no departamento do CIO (Diretor Executivo
de Informao), 15 existem no departamento do CTO (Diretor de Tecnologia), 14 se reportam ao COO (Diretor de
Operaes), 4 existem tanto no Departamento Jurdico quanto no Escritrio de Conformidade e Gesto de Riscos,
3 SSGs se reportam aos CSOs (Diretores de Segurana) e um reporta diretamente ao fundador ou CEO (Diretor
Executivo). Algumas das companhias estudadas no especificam em qual lugar seu SSG est posicionado na organizao.

O Grupo de Segurana de Software (SSG)

O segundo papel mais importante numa iniciativa de segurana de software aps o executivo snior o Grupo de
Segurana de Software. Cada um dos 67 programas que descrevemos no BSIMM tem um SSG. Executar com sucesso as
atividades do BSIMM improvvel (e no foi observada em campo at o momento), ento crie um SSG antes de comear
a trabalhar na adoo das atividades do BSSIM. Os melhores membros do SSG so pessoas da segurana de software, mas
estes profissionais so quase sempre impossveis de se encontrar. Se voc precisar de profissionais de segurana de software
do zero, comece com desenvolvedores e ensine-os sobre segurana. No tente iniciar com pessoas da segurana de redes e
ensin-los sobre software, compiladores, SDLCs, rastreamento de bugs e todo o resto do universo de software. Nenhuma
quantidade de conhecimento em segurana tradicional pode superar a inexperincia com software.
SSGs vem em diversos tipos e tamanhos. Todos os bons SSGs aparentam incluir pessoal com experincia de codificao
profunda e pessoal com pendor para arquitetura. Como voc ver abaixo, segurana de software no pode ser sobre
somente encontrar bugs especficos como OWASP Top Ten. Reviso de cdigo uma boa prtica muito importante e
para reviso cdigo voc precisa entender de cdigo (sem mencionar as enormes pilhas de bugs de segurana). Porm, os
melhores revisores de cdigo s vezes so pssimos arquitetos de software e pedi-los para realizar uma Anlise de Risco
Arquitetural vai resultar apenas em olhares vazios. Certifique-se de abranger capacidades de arquitetura no seu SSG assim
como voc faz com cdigo. Finalmente, o SSG geralmente solicitado a orientar, treinar e trabalhar diretamente com
centenas de desenvolvedores. Habilidades de comunicao, ensino, e bom senso de consultoria so obrigatrios para pelo
menos uma parte do pessoal do SSG. Para mais a respeito deste problema, veja nosso artigo informativo: Voc Realmente
Precisa de um SSG<http://bit.ly/7dqCn8>.

BSIMM-V

Uma necessidade primria identificar e delegar um executivo snior para gerenciar as operaes, captar recursos e
oferecer cobertura politica para uma iniciativa de segurana de software. Abordagens polticas para a segurana de
software, provocadas e conduzidas unicamente por desenvolvedores e seus lideres diretos tem um histrico pobre no
mundo real. Da mesma forma, inciativas encabeadas por recursos de um grupo de segurana de rede j existente
geralmente tem srios problemas quando chega a hora de fazer interface com os grupos do desenvolvimento. Ao
identificar um executivo snior e coloc-lo responsvel pela segurana de software, voc enderea dois dos 101 problemas
bsicos da gesto responsabilizao e delegao. Voc tambm cria um lugar na organizao onde a segurana de
software pode tomar assento e comear a prosperar.

Embora nenhuma das 67 empresas que examinamos tenha exatamente a mesma estrutura para o SSG (sugerindo
que no existe uma maneira nica para estruturar um SSG), ns observamos algumas similaridades que valem a
pena mencionar. No mais alto nvel da organizao, os SSGs vm em trs estilos principais: aqueles organizados
com as funes tcnicas do SDLC, aqueles organizao por funes operacionais e aqueles organizados de acordo
com as unidades de negcios. Alguns SSGs so altamente distribudos atravs da empresa e outros so altamente
centralizados e politicamente orientados. Se ns olharmos atravs de todos os SSGs em nosso estudo, existem alguns
subgrupos que so frequentemente observados: pessoas dedicadas para polticas, estratgicas e mtricas; grupos
internos de servio que (muitas vezes separadamente) cobrem ferramentas, testes de penetrao e desenvolvimento
de middleware e orientao; grupos de resposta a incidentes; grupos responsveis por desenvolver e entregar
treinamentos; grupos de marketing e comunicao externos; e grupos de controle de fornecedores.
Nas estatsticas abordadas acima, notamos que taxa mdia do SSG para o desenvolvimento de 1.4% atravs
do grupo inteiro das 67 organizaes que estudamos. Isso significa que existe um membro do SSG para cada 71
desenvolvedores quando calculamos a taxa mdia para cada participante. O maior SSG era 27,27% e o menor era
0,03%. Para relembr-los em termos particulares de elementos do corpo funcional, entre as 67 empresas o tamanho
mdio do SSG era de 14,7 pessoas (menor 1, maior 100, mediana 7).

Todos os Outros
Os participantes da pesquisa engajaram todos os envolvidos com o ciclo de desenvolvimento de software como um
meio de enderear o software seguro.

Construtores incluindo desenvolvedores, arquitetos e seus gerentes devem praticar engenharia de

segurana, garantindo que os sistemas construdos sejam defensveis e no cheio de furos. O SSG interagir
diretamente com os construtores a medida que encaminhem as atividades do BSIMM. Em geral, medida
que a organizao amadurece, o SSG tenta capacitar os construtores para que eles possam realizar a maioria
das atividades do BSIMM por conta prpria com o SSG ajudando em casos especiais e fazendo uma
superviso. Para muitas atividades nesta verso do BSIMM, no apontamos explicitamente quem se deve
responsabilizar por uma atividade (desenvolvedores, testadores, SSG, entre outros). Porm, em alguns
casos, ns tentamos esclarecer as responsabilidades nas metas associadas aos nveis de atividades dentro
das prticas. Proponha uma abordagem mais alinhada com sua organizao, considerando a sua carga de
trabalho e seu ciclo de vida.
Testadores, responsveis pelo teste e verificao devem se esmerar para focar em problemas de segurana.
Algumas das atividades na prtica de teste podem ser encaminhadas diretamente pelo controle de qualidade.
Profissionais de Operao devem continuar a projetar redes seguras, defend-las e mant-las em operao.
A segurana de software no acaba quando o software lanado.
Administradores devem entender a natureza distribuda dos sistemas modernos e comear a praticar o
princpio do menor privilgio, especialmente em relao a aplicaes hospedadas por eles ou na nuvem.
Executivos e gestores, incluindo responsveis pela rea de negcio e gerentes de produtos devem entender
como o investimento antecipado em projeto e anlise com enfoque em segurana afeta o grau de confiana
dos usurios em seus produtos. Os requisitos de negcio devem contemplar explicitamente necessidades de
segurana. Qualquer negcio hoje em dia depende de software. A segurana de software uma necessidade
de negcio.
Fornecedores, incluindo aqueles que fornecem software de prateleira (sigla em ingls COTS), software
customizado e software como servio (sigla em ingls SaaS) esto altamente sujeitos aos acordos de nveis de
servio (sigla em ingls SLAs) e revises (tal como o vBSIMM) que ajudam a garantir que os produtos so
resultados de um SDLC seguro.

Os participantes sentem que as pessoas que precisam ser alistadas para o progresso de curto prazo em segurana de
software so os construtores. Somente deixando no passado o padro-problema da viso de segurana da operao que
comearemos a fazer sistemas de software que ficaro de p sob ataque.

2013

Identificando um Satlite
Adicionalmente ao SSG, muitos programas de segurana de software tm identificado indivduos (frequentemente
desenvolvedores, testadores e arquitetos) que compartilham o mesmo interesse em segurana de software, mas no
fazem parte diretamente da equipe do SSG. Chamamos este grupo de satlite.
Em alguns casos, o satlite amplamente distribudo, com um ou dois membros de cada grupo de produto. Em outros,
o satlite mais focado, se encontrando e se encontram regularmente com outros para comparar registros, aprender
novas tecnologias e expandir o entendimento de segurana de software na organizao. A identificao e promoo de
satlites importante para o sucesso de vrias iniciativas em segurana de software (mas no todas). Algumas atividades
BSIMM focam explicitamente nos satlites.
Em particular, todas as dez empresas com a pontuao mais altas do BSIMM possuem satlites (100%), com um
tamanho mdio de 148 pessoas. Fora dos dez primeiros, 29 das 57 remanescentes tem um satlite (51%). Nas dez
empresas com a pontuao mais baixa no BSIMM, somente duas possuem satlites (20%), com um tamanho mdio
menor do que meia pessoa. Isso sugere que medida que uma iniciativa de segurana de software amadurece, suas
atividades esto distribudas e institucionalizadas na sua estrutura organizacional. Entre a nossa populao de 67
empresas, as iniciativas tendem a evoluir de centralizadas e especializadas no comeo para descentralizadas e distribudas
(com um SSG no centro orquestrando os acontecimentos).

BSIMM descreve 112 atividades que qualquer organizao pode colocar em prtica. As atividades so descritas
em termos do SSF, que identifica doze prticas agrupadas em quatro domnios. Cada atividade est associada a
um objetivo.

Resultados do BSIMM-V
Os dados do BSIMM rendem resultados analticos bem interessantes. Aqui temos dois grficos em teia mostrando
o nvel mdio de maturidade em cada uma das doze prticas sobre alguns nmeros das organizaes. O primeiro
grfico mostra dados de todas as 67 empresas do BSIMM-V. O segundo grfico mostra dados das dez primeiras
empresas (conforme determinado pelo escore bruto calculado somando-se as atividades).
Os grficos em teia so criados observando o nvel mais elevado de atividade em prtica de uma determinada
empresa (nvel mais alto) e em seguida, a mdia da pontuao de um grupo de empresas, resultando em doze
nmeros (um para cada prtica). O grfico possui doze raios correspondendo s doze prticas. Note que todos estes
grficos, o nvel 3 (borda externa) considerado mais maduro que o nvel zero (ponto interno). Outras anlises mais
sofisticadas so possveis, claro, e ns continuamos a experimentar com ponderaes por nvel, normalizao pelo
nmero de atividades entre outros mtodos.

BSIMM-V

Colocando o BSIMM-V em Uso

Ao calcular um escore bruto para cada empresa no estudo, tambm pudemos dar uma olhada na maturidade relativa e prazo
mdio de uma empresa com relao a outras. At o momento, a faixa de valores observados de [13, 93].
O grfico abaixo mostra a distribuio dos escores entre a populao das 67 empresas participantes. Para fazer este grfico,
dividimos a pontuao em cinco barras iguais. Como voc pode ver, os resultados representam uma curva em sino ligeiramente
inclinada.

2013

Estamos satisfeitos que o estudo do BSIMM continua a crescer (o conjunto dos dados cresceu pouco mais 75% desde a publicao do BSIMM4 e dezoito vezes maior do que foi na publicao original). Note que assim que ultrapassamos a amostra de
trinta empresas, comeamos a aplicar analise estatstica produzindo resultados estatisticamente significativos.

BSIMM-V

O Scorecard do BSIMM-V abaixo mostra o nmero de vezes que cada uma das 112 atividades foi observada nos dados do
BSIMM-V. Uma verso expandida desta tabela pode ser encontrada na pgina 60.

Novas Atividades para Observao no BSIMM6

Pela segunda vez no projeto BSIMM, ns observamos uma atividade que ainda no havia sido capturada pelo modelo.
Por isso, ns adicionamos uma nova atividade para o modelo avanar. As observaes relacionadas com esta atividade
sero primeiramente apresentadas nos dados lanados com o BSIMM6, mas descrevemos a atividades nesta verso.
As duas novas atividades descritas primeiramente no BSIMM4 esto sendo ativamente mapeadas durante as avaliaes.
Porm, existe algum atraso nos dados para essas atividades devido nova avaliao. Ns no daremos crditos
retroativos para novas atividades em avaliaes passadas. (Isto se d pelo fato de, por exemplo, [CR3.4 Deteco
automatizada de cdigo malicioso] reportada como uma atividade do BSIMM-V, apesar de sabermos que um grande
nmero de empresas participantes empreendem esta atividade.
Nosso critrio para adicionar uma atividade ao BSIMM apresentado a seguir. Se ns observamos uma atividade
candidata que ainda no est no modelo, ns determinamos baseados em dados capturados anteriormente e em
questionamentos na lista de discusso do BSIMM quantas empresas provavelmente executam esta atividade. Se a
resposta mltiplas empresas, ns observamos de perto a atividade proposta e vislumbramos como ela se encaixa no
modelo existente. Se a resposta somente uma empresa, a atividade candidata tabelada como muito especializada.
Alm disso, se a atividade candidata coberta por atividades existentes ou simplesmente refina ou bifurca uma
atividade existente, ela descartada.
Usando o critrio acima, a atividade adicionada ao modelo BSIMM-V : [CMVM3.4 Opere um programa de
recompensas para bugs]. Ns inclumos uma descrio completa da nova atividade na descrio detalhada do
BSIMM-V e no esqueleto do BSIMM abaixo.

Avaliando a Sua Empresa com o BSIMM-V

O uso mais importante do BSIMM como um padro de medio para determinar onde a sua abordagem est
posicionada em relao a outras empresas. Observe quais atividades voc realmente j possui, use a cobertura de
atividade para determinar os seus nveis e construa um scorecard. No nosso trabalho usando o BSIMM para avaliar
nveis, nos encontramos que o grfico em teia produzindo a abordagem do nvel mais alto (baseado em trs nveis por
atividade) suficiente para um sentimento grosseiro para maturidade, especialmente quando trabalhando com dados
geogrficos ou de um setor em particular.
Uma comparao significante traar o seu nvel mais alto de maturidade contra as mdias que publicamos para
observar como a sua iniciativa se organiza. Abaixo, ns plotamos os dados de uma empresa (falsa) contra o grfico Terra
do BSIMM.

2013

10

BSIMM-V

Uma comparao direta entre todas as 112 atividades talvez o uso mais bvio do BSIMM. Isto pode ser realizado
pela construo de um scorecard usando os dados impressos na pgina 60.
O scorecard que voc v aqui retrata uma empresa (falsa) que executa trinta e sete atividades do BSIMM (1s nas
colunas EMPRESA), incluindo oito atividades que so mais comuns em suas respectivas prticas (caixas roxas). Por
outro lado, a empresa no executa as atividades mais comuns observadas nas outras quatro prticas (caixas vermelhas)
e deve gastar algum tempo para determinar se estas so necessrias ou teis para a sua iniciativa global de segurana de
software. A coluna Empresas do BSIMM-V mostra o nmero de observaes (atualmente de 67) para cada atividade,
permitindo a empresa entender a popularidade em geral de uma atividade entre as 67 participantes do BSIMM.

11

Desde que voc tenha determinado com as suas atividades esto, voc pode criar um plano para melhorar as prticas
com outras atividades sugeridas com o BSIMM. Provendo dados atuais de avaliaes de campo, o BSIMM torna
possvel construir um plano de longo prazo para uma iniciativa de segurana de software e mapear o progresso com
relao ao plano. Para registrar, no existe razo para adotar as atividades na integra em todos os nveis para cada
prtica. Adote as atividades que fizerem sentido para sua organizao e ignore aquelas que no fazem sentido.
O melhor modo de utilizar o BSIMM no planejamento identificar metas e objetos por sua conta e depois
olhar o BSIMM para determinar quais atividades fazem sentido. Escolher entre prticas no recomendado.
Particularmente, no acreditamos que uma iniciativa de sucesso ser capaz de preterir todas as atividades para cada
uma das doze prticas. Colocando de outra forma, os dados mostram que iniciativas altamente maduras esto
redondas e executam atividades em todas as doze prticas. Em todo caso, navegando entre os objetivos e observando
qual tem apelo na sua cultura um modo mais limpo de prosseguir. No momento em que voc sabe quais so os
seus objetivos, voc pode determinar quais atividades adotar. Por favor, perceba que na nossa viso colocar algumas
atividades do Nvel 1 em cada prtica no lugar do que acelerar para o Nvel 3 em apenas uma prtica enquanto
ignora as outras. Esta viso esclarecida pelos dados que ns coletamos.
A discriminao das atividades em nveis para cada prtica destina-se apenas como um guia. Os nveis provem
uma progresso natural atravs das atividades associadas com cada prtica. Porm, no necessrio executar todas
as atividades em um nvel determinado antes de mover para atividades no nvel mais alto na mesma prtica. Isto
dito, os nveis que identificamos jogaro gua no escrutnio estatstico. Atividades Nvel 1 (fceis e simples) so
comumente observadas, Nvel 2 (mais difceis e requerem mais coordenao) um pouco menos e Nvel 3 (topo de
linha, em ingls rocket science) so muito raramente observadas.
Identificando objetivos e atividades para cada prtica que podem funcionar para voc e garantindo o balano
apropriado com respeito aos domnios, voc pode criar um plano estratgico para a sua iniciativa em segurana de
software seguir em frente. Note que a maioria das iniciativas de segurana de software um esforo de muitos anos
com oramento real, mandato e propriedade por trs delas. Embora todas as atividades paream diferentes e so
personalizadas para caber em uma organizao em particular, como descrevemos, todas as iniciativas compartilham
atividades em comum.

Estudando Grupos de Empresas no BSIMM-V

Os grficos em teia que introduzimos acima so tambm teis para comparao grupos de empresas de um setor da
indstria em particular ou de localizaes geogrficas. O grfico abaixo mostra dados do setor de servios financeiros
(26 empresas) e fornecedores independentes de software (25 empresas). Na mdia, empresas de servios financeiros
(sigla em ingls FI) tm maior maturidade quando comparadas com fornecedores independentes de software (sigla em
ingls ISV) em sete das doze prticas. Pela mesma avaliao, fornecedores independentes de software (sigla em ingls
ISV) tem maior maturidade quando comparados com empresas de servios financeiros em cinco das doze prticas.
Embora exista uma abundncia de sobreposio aqui, maiores diferenas podem ser explicadas com referncia
mudana para computao nas nuvens entre as ISVs (veja CMVM e SE) enquanto FIs tendem a enfatizar padres e
prticas de conformidade (veja SR e CP). Um olhar detalhado nas 112 atividades revela mais diferenas interessantes.

2013

12

BSIMM-V

Na tabela abaixo, voc pode ver os Scorecards do BSIMM para os dois maiores setores comparados lado a lado. Na
coluna Atividade, ns destacamos em amarelo as atividades mais comuns em cada prtica como observadas em todo
conjunto de dados do BSIMM (67 empresas). A coluna Delta mostra o valor absoluto da diferena entre FIs e ISVs
para cada atividade. Deltas largos so de interesse particular e esto destacados em azul escuro quando mais ISVs so
observadas realizando a atividade e em vermelho quando mais FIs so observadas realizando a atividade.

H uma grande quantidade de sobreposies nas observaes mais comuns, com a maioria dos deltas equivalentes
a seis ou menos. Na prtica de Poltica e Conformidade, no entanto, existem quatro atividades que so observadas
significantemente mais frequentes nas FIs do que nas ISVs. Elas so [CP 1.1 Unifique as presses regulatrias], [CP
1.3 Crie uma poltica] e [CP 2.2 Exija autorizao formal de segurana para os riscos de conformidade]. O fato de
que FIs colocam mais nfase na conformidade e poltica que ISVs no nenhuma surpresa, pois FIs so reguladas. O
mesmo acontece para a classificao dos dados (ISVs fazem objetos para armazenas dados e FIs armazenam muitos
dados), que explica o tamanho do delta em (AM1.2 Crie um programa de classificao e inventrio de dados].
Por outro lado, ISVs tendem a confiar mais em persuaso do que em imposio quando se trata de influenciar as
equipes de desenvolvimento como refletido por [SM 1.2 Crie o papel de evangelistas e faa propaganda interna] e
tambm aproveitam tecnologia fortemente como visto em [CR 1.5 Torne reviso de cdigo obrigatria para todos os
projetos].
Quando comeamos a trabalhar no BSIMM, espervamos que os dados nos levassem a uma narrativa explicando o
comportamento em setores particulares ou geogrficos. No tivemos sorte. Por exemplo, embora exista uma pequena
diferena visvel entre a empresa mdia de servios financeiros e o fornecedor independente de software mdio
quando se trata de segurana de software, as similaridades entre os participantes altamente maduros em cada setor
pesam mais do que suas diferenas em ordem de magnitude.

13

O mesmo tipo de coisa pode ser dito sobre as empresas Europeias + Reino Unido (dezessete) e as empresas
Estadunidenses (cinquenta). As diferenas entre os conjuntos mostram que as iniciativas Europeias + Reino Unido
esto atrs das iniciativas Estadunidenses entre doze e dezoito meses, como refletido no grfico de teia abaixo e
correspondem ao desenvolvimento do mercado de segurana de software nestas regies. Para um tratamento em
profundidade do mercado Europeu, seja BSIMM Europa: Medindo as iniciativas de segurana de software ao redor
do globo <http://bit.ly/TTBfX>.

2013

14

BSIMM como um Estudo Longitudinal

BSIMM-V

inte e uma das 67 empresas foram avaliadas duas vezes usando o sistema de avaliao do
BSIMM. Na mdia, o tempo entre as duas avaliaes foi de 24 meses. Ainda que as atividades
individuais entre as doze prticas vm e vo, como visto no Scorecard Longitudinal abaixo, em
geral a reavaliao ao longo do tempo mostra uma tendncia clara de crescimento na maturidade
na populao de vinte e uma empresas reavaliadas at agora. A pontuao bruta subiu em dezessete
das vinte e uma empresas na mdia de 14 (um aumento mdio de 16%). Iniciativas de segurana de
software amadurecem ao longo do tempo.

15

Aqui esto dois modos de pensar sobre a mudana representada pelo scorecard longitudinal. Ns vemos as maiores
chances em [T1.7 Realize treinamentos individualizados sob demanda], com 10 observaes novas; [SM2.1 Publique
internamente dados sobre segurana de software] e [SR1.3 Traduza restries de conformidade para requisitos], com
nove observaes novas; e [SM2.5 Identifique mtricas e use-as para direcionar os oramentos], [CP2.4 Formalize
todos os contratos de fornecedores com SLAs de segurana de software] e [CR1.1 Crie uma lista de bugs top N
(preferencialmente com dados reais)] com 8 novas observaes. Existem cinco atividades adicionais recentemente
observadas em sete empresas reavaliadas.
Menos obvio a partir do scorecard a rotatividade entre as atividades. Por exemplo, embora o nmero de empresas
manteve-se constante para [CMVM2.2 Desenvolva uma operao de inventrio de aplicaes], cinco empresas
tem observaes novas desta atividade, enquanto a atividade deixou de ser observada em outras cinco empresas.
Similarmente, nos tivemos novas observaes em cinco empresas para [T3.5 Estabelea um horrio de trabalho para o
SSG] e [SR 2.3 Crie padres especficos por setores de tecnologia], embora as atividades no fossem mais observadas
em quatro empresas. Adicionalmente, ns tivemos observaes novas em quatro empresas para [SFD 3.2 Exija o uso
de funcionalidades e frameworks de segurana aprovados] ao passo que a atividade no foi mais observada em cinco
empresas.
Utilizando o diagrama em teia, ns podemos plotar o nvel mais alto para a primeira avaliao das vinte e uma
empresas contra a segunda avaliao.

BSIMM ao Longo do Tempo

Esta quinta a maior verso do projeto BSIMM.O estudo original incluiu nove empresas e nove avaliaes distintas.
BSIMM2 incluiu 30 empresas e 42 avaliaes distintas (algumas empresas incluiriam subsidirias muito grandes
que foram avaliadas independentemente). BSIMM3 incluiu 42 empresas, onze delas foram reavaliadas, para um
conjunto total de 81 avaliaes distintas. BSIMM4 incluiu 51 empresas, treze delas foram reavaliadas (com uma
empresa avaliada pela terceira vez), consolidando um conjunto total de 95 avaliaes distintas. BSIMM-V inclui 67
empresas, 21 das quais foram reavaliadas (com 4 empresas avaliadas pela terceira vez), gerando um conjunto total de
161 avaliaes distintas. A partir do BSIMM-V, 5 empresas (representando 5 avaliaes distintas) foram descartadas
porque suas avaliaes eram de mais de 48 meses.

2013

16

A Comunidade BSIMM

s 67 empresas participantes do Projeto BSIMM compem a Comunidade BSIMM. Um grupo de discusso

privado e moderado com mais de 200 membros permite aos lideres dos SSGs participantes do BSIMM
discutam solues com outros que enfrentam as mesmas dificuldades, discutam estratgias com algum que j
endereou uma questo, procurem mentores entre aqueles que esto mais adiante no plano de carreira e unem-se
para resolver problemas complexos.
A Comunidade do BSIMM tambm hospeda uma conferncia anual privada onde at trs representantes de cada
empresa se renem em um frum extraoficial para discutir iniciativas de segurana de software. No outono de 2012,
28 das 51 empresas participaram da Terceira Conferncia Anual da Comunidade BSIMM em Galloway, Nova Jersey.
Na primavera de 2013, 10 de 15 empresas com presena na Unio Europeia participaram da Segurana Conferncia
Anual da Comunidade Europeia do BSIMM em Londres, Inglaterra.

BSIMM-V

O website do BSIMM < http://bsimm.com> inclui a seo da Comunidade BSIMM credenciada onde informaes
sobre as conferncias, grupos de trabalho e listas de discusso sobre estudos iniciados so postados.

17

2013

18

O Framework de Segurana de Software

tabela abaixo mostra o SSF. Existem doze prticas organizadas em quatro domnios. Os domnios so:

O Framework de Segurana de Software (SSF)

19

Governana

Inteligncia

SSDL Touchpoints

Implantao

Estratgia e Mtricas

Modelos de Ataque

Anlise Arquitetural

Testes de Penetrao

Conformidade e Poltica

Recursos e Projeto de
Segurana

Reviso de Cdigo

Ambiente de Software

Treinamento

Padres e Requisitos

Testes de Segurana

Gesto de Configurao e
Gesto de Vulnerabilidade

BSIMM-V

1. Governana: Prticas que ajudam a organizar, gerenciar e avaliar a iniciativa em segurana de software. O
desenvolvimento da equipe uma prtica central de governana.
2. Inteligncia: Prticas que resultam numa coleo de conhecimento corporativo usado para realizar as
atividades de segurana de software pela organizao. As colees incluem tanto um guia de segurana
proativa quanto a modelagem organizacional de ameaas.
3. SSDL Touchpoints: Prticas associadas anlise e garantia no desenvolvimento de artefatos particulares de
software e processos. Todas as metodologias de segurana de software incluem estas prticas.
4. Implantao: Prticas que interagem com as reas de segurana de rede tradicional e manuteno de
software. A (gesto de) configurao de software, a manuteno e outras questes de ambiente possuem
impacto direto na segurana de software.

Existem trs prticas em cada domnio. Para ilustrar o que cada prtica considera, inclumos uma explicao para
cada uma delas. Observe que o BSIMM descreve os objetivos e atividades em cada prtica.
No domnio da governana, a prtica estratgia e mtricas engloba planejamento, atribuio de papis e
responsabilidades, identificao de objetivos de segurana, definio de oramento e identificao de medidas e
barreiras. A prtica conformidade e poltica foca na identificao de controles para procedimentos de conformidade
como PCI e HIPAA, desenvolvimento de controles contratuais como Acordos de Nvel de Servio para ajudar
a controlar risco de software COTS, estabelecendo poltica organizacional de segurana de software e auditando
o cumprimento da poltica. O treinamento sempre exerceu um papel crtico em segurana de software, pois os
desenvolvedores e arquitetos quase sempre iniciam com conhecimento muito pequeno em segurana.
O domnio inteligncia serve para criar recursos para toda a organizao. Tais recursos so divididos em trs
prticas. Os modelos de ataque capturam a informao para pensar como um atacante: modelagem de ameaas,
desenvolvimento e refinamento de casos de abuso, classificao de dados e padres de ataque especficos por
tecnologia. A prtica funcionalidades e projeto de segurana tm a responsabilidade de criar padres de segurana
teis para os principais controles de segurana (atendendo aos padres definidos na prxima prtica), construindo
frameworks middleware de controle e criando e publicando outras orientaes proativas de segurana. A prtica
padres e requisitos envolve o levantamento explcito de requisitos de segurana pela organizao, determinando
quais COTS recomendar, construindo padres para os principais controles de segurana (como autenticao,
validao de entrada, entre outros), criando padres de segurana para as tecnologias em uso e criando um comit
de reviso de padres.
O domnio SSDL Touchpoints provavelmente o mais familiar dentre os quatro. Este domnio inclui as melhores
prticas essenciais de segurana de software que esto integradas ao SDLC. As duas mais importantes prticas de
segurana de software so anlise arquitetural e reviso de cdigo. A anlise arquitetural engloba a amarrao da
arquitetura do software em diagramas concisos, empregando listas de riscos e ameaas, adotando um processo para
reviso (como o STRIDE ou Anlise de Risco Arquitetural) e construindo um plano de avaliao e remediao
para a organizao. A prtica de reviso de cdigo inclui ferramentas de reviso de cdigo, desenvolvimento de regras
personalizadas, perfis personalizados para o uso da ferramenta por diferentes papis (por exemplo, desenvolvedores
versus auditores), anlise manual e rastreamento/avaliao dos resultados. A prtica testes de segurana se preocupa
com testes pr-lanamento, incluindo a integrao da segurana nos padro de processos da garantia de qualidade.
A prtica inclui o uso de ferramentas de segurana caixa preta (incluindo o teste fuzz) como um smoke test na QA,
testescaixa branca orientado por riscos, aplicao de modelo de ataque e anlise da cobertura de cdigo. Os testes
de segurana focam em vulnerabilidades durante a construo.
Alternativamente, no domnio implantao, a prtica testes de penetrao envolve mais padres de teste de fora
para dentro realizados por especialistas em segurana. Os testes de penetrao focam em vulnerabilidades na
configurao final e prov informao direta para a gesto de defeitos e mitigao. A prtica ambiente de software
se preocupa com atualizaes de Sistema Operacional e plataforma, firewalls de aplicao web, documentao
de instalao e configurao, monitoramento da aplicao, gesto de mudana e, por fim, assinatura de cdigo.
Finalmente, a prtica gesto de configurao e gesto de vulnerabilidade se preocupa com a atualizao e correo de
aplicaes, controle de verso, rastreamento e remediao de defeitos e tratamento de incidentes.

2013

20

BSIMM-V

presentamos o modelo de maturidade como uma srie de atividades associadas a cada uma das doze prticas. Nossa
abordagem se baseia na identificao de metas para cada nvel de uma prtica, que pode ser detalhadamente divididas em objetivos para a prtica/nvel e esto desta forma associadas s atividades. Caso necessite ajuda no entendimento
sobre como as atividades bsicas esto organizadas, observe o esqueleto do BSIMM.
A caracterizao e venda das metas de negcio da iniciativa faz parte para tornar a iniciativa de segurana de software
um sucesso. A partir de uma perspectiva top-down, a abordagem baseada em metas inclui a identificao de metas
no mbito da iniciativa e de domnio, bem como as metas e objetivos para as prticas, nveis e atividades.
Sob o risco de parecermos repetitivos, as metas de alto nvel realadas para o BSIMM so:

Decises de gesto dos riscos informados;

A clareza sobre o que a coisa certa a fazer para todos os envolvidos na segurana de software;
Reduo de custos atravs de padres e processos repetveis;
Melhoria da qualidade do cdigo.

Domnio

Metas de Negcio

Governana

Transparncia, Responsabilizao, Pesos e Contrapesos

Inteligncia

Auditabilidade, Diligncia, Padronizao

SSDL Touchpoints

Controle da Qualidade

Implantao

Controle da Qualidade, Gesto de Mudanas

No SSF, existem trs prticas em cada domnio. Assim como os domnios, cada prtica possui uma meta de alto nvel.
Pelo entendimento destas metas, voc pode ter uma viso geral porque a adoo de alguns aspectos de todas as prticas
faz sentido. Neste nvel voc pode comear a pensar sobre quais metas so mais importantes para sua organizao e sua
cultura. Aqui esto as metas associadas a cada prtica do BSIMM:

Domnio

Prtica

Metas de Negcio

Governana

Estratgia e Mtricas

Transparncia das expectativas, Responsabilidade pelos resultados

Conformidade e Poltica

Orientaes normativas para todos os stakeholders, Responsabilizao

Treinamento

Fora de trabalho bem informada, Correo de erros

Modelos de Ataque

Conhecimento personalizado

Inteligncia

Recursos e Projeto de Segurana Padres reutilizveis, Orientaes normativas para todos os stakeholders

SSDL Touchpoints

Implantao

21

Padres e Requisitos

Orientaes normativas para todos os stakeholders

Anlise de Arquitetura

Controle da qualidade

Reviso de Cdigo

Controle da qualidade

Testes de Segurana

Controle da qualidade

Testes de Penetrao

Controle da qualidade

Ambiente de Software

Gesto de mudanas

Gesto de Configurao e
Gesto de Vulnerabilidade

Gesto de mudanas

BSIMM-V

Cada um dos quatro domnios no SSF possui suas prprias metas. Entendendo tais metas, pode-se facilmente
observar porque adotar alguns aspectos de todos os quatro domnios faz sentido. Certamente, ignorar um domnio
por completo seria insensato. Aqui esto as metas associadas a cada domnio no BSIMM:

2013

22

GOVERNANA: Estratgia e Mtricas (SM)

Os objetivos gerais para a prtica Estratgia e Mtricas so transparncia das expectativas e responsabilizao pelos
resultados. A gerncia executiva deve esclarecer as expectativas organizacionais para o SSDL de forma que todos
compreendam a importncia da iniciativa. Adicionalmente, a gerncia executiva deve estabelecer objetivos especficos
para todos os stakeholders do SSDL e garantir que os indivduos so responsabilizados por alcanar tais objetivos.

[SM1.1]

[SM1.2]

[SM1.3]

[SM1.4]

[SM1.6]

23

SM Nvel 1: Alcanar um entendimento comum de direo e de estratgia. Os gerentes devem garantir que todos
os envolvidos na criao, implantao, operao e manuteno de software compreendam os objetivos formalizados
de segurana de software da organizao. Os lderes devem tambm assegurar que a organizao como um todo
compreenda a estratgia para atingir esses objetivos. Uma compreenso estratgica comum essencial para a execuo
eficaz e eficiente do programa.
Publique o processo (papis, reponsabilidades, plano), o evolua quando necessrio. O processo que enderea
a segurana de software divulgado a todos participantes, de forma que todos conheam o plano. Metas, papis,
reponsabilidades e atividades so explicitamente definidas. Muitas organizaes partem de uma metodologia
como o OWASP CLASP, Microsoft SDL ou Cigital Touchpoints e ento a adapta segundo suas necessidades.
Um processo SSDL evolui medida que a organizao amadurece e o panorama da segurana se altera.
Crie o papel de evangelistas e faa propaganda interna. A fim de desenvolver apoio para segurana de software
por toda organizao, o SSG assume um papel evangelizador. Tal funo de marketing interno ajuda a manter a
organizao ciente da magnitude do problema da segurana de software e os elementos de sua soluo. O SSG
pode realizar palestras internas, estender convites para palestrantes externos, desenvolver artigos para consumo
interno ou criar uma coleo de artigos, livros e outros recursos em um website interno e promover o seu uso.
Conversas ad hoc entre o SSG e executivos ou um SSG onde todo mundo um evangelistano alcanam
os resultados desejados. Um exemplo cannico do que um evangelizador o papel do Michael Howard na
Microsoft.
Eduque os executivos. Os executivos aprendem sobre as consequncias da segurana de software inadequada
e o impacto negativo para o negcio que pode ter uma segurana pobre. Eles aprendem tambm acerca do
trabalho realizado por outras organizaes para obter segurana de software. Pelo entendimento tanto do
problema quanto da soluo, os executivos passam a apoiar a iniciativa em segurana de software como uma
necessidade da gesto de risco. Na forma mais perigosa, pode-se mostrar o lado negativo por ao de hackers
ou incidentes de exposio pblica de dados. Preferencialmente, o SSG pode demonstrar o cenrio mais
negativo em ambiente controlado com a permisso de todos os envolvidos (mostrando realmente exploraes
funcionando e o seu impacto no negcio). Em alguns casos, a apresentao para a alta administrao pode
ajudar a angariar recursos para uma iniciativa de segurana de software contnua. Trazer um guru externo
sempre til quando se pretende reforar a ateno dos executivos.
Identifique pontos de barreiras, rena os artefatos necessrios. O processo de segurana de software envolver
barreiras para liberao em um ou mais pontos no SDLC, ou do mais provvel, dos SLDCs. Os primeiros dois
passos para estabelecer as barreiras para liberao so: 1) identificar a localizao das barreiras que so compatveis
com o processo de desenvolvimento existente e 2) comear a reunio das entradas necessrias para tomar a deciso
de ir ou no ir. Importante neste estgio que as barreiras no sejam impostas. Por exemplo, o SSG pode coletar
os resultados dos testes de segurana para cada projeto antes do lanamento, mas no fazem um julgamento
rpido do que constitui quantidade de teste suficiente ou resultados aceitveis para os testes. A ideia de identificar
inicialmente as barreiras e s exigi-las depois extremamente til na movimentao do desenvolvimento em
direo a segurana de software sem maiores dores. Socializar as barreiras e somente habilit-las quando os projetos
j souberem como proceder. Esta abordagem gradual serve para motivar um bom comportamento sem requer-lo.
Exija a autorizao da segurana: A organizao tem um processo amplo de iniciativa para aceitao de riscos de
segurana e documentar responsabilizao. O aceitante do risco assina sobre o estado de todo o software antes de seu
lanamento. Por exemplo, a poltica de aceitao pode requerer que o chefe da unidade de negcio aceite vulnerabilidades
crticas que no foram mitigadas ou os passos do SSDL que foram pulados. Aceitao informal dos riscos somente no
conta como uma aceitao de segurana, como o ato de aceitar o risco mais eficaz quando formalizado (exemplo, com
uma assinatura formal, submisso de formulrios, ou similares) e armazenado para referncia futura.

BSIMM-V

um

dois

SM Nvel 2: Alinhe comportamento e estratgia e verifique a aderncia. Os gestores devem identificar explicitamente
os indivduos responsveis pela gesto de risco de segurana de software. Estes indivduos so, por consequncia,
responsveis pelo desempenho das atividades do SSDL. Os gestores do SSDL devem garantir a rpida identificao e
modificao de qualquer comportamento no SSDL que resulte em um risco inaceitvel. Para reduzir o risco inaceitvel,
os gestores devem identificar e encorajar o crescimento de satlite de segurana de software (Veja na seo Papis acima).
Publique dados sobre segurana de software internamente. O SSG publica internamente dados sobre o estado
de seguranado software dentro da organizao. A informao pode vir como um dashboard com mtricas para
executivos e gestores do desenvolvimento de software. Algumas vezes a publicao no dividida com todos na
empresas, mas somente com os executivos relevantes. Publicar informao para os executivos que fazem algo
sobre isso e promovem mudanas o suficiente. Em outros casos, gesto aberta e a publicao dos dados para
todos os stakeholders ajudam a todos conhecerem o que est acontecendo, com a filosofia de que a luz o melhor
antissptico. Se a cultura da organizao promove a concorrncia interna entre os grupos, esta informao adiciona
uma dimenso de segurana para o jogo.

[SM2.1]

Imponha barreiras com avaliao e rastreie as excees. Barreiras agora so obrigatrias: para avanar uma
barreira, um projeto deve satisfazer uma medida estabelecida ou obter uma dispensa. Mesmo as equipes de projetos
teimosas devem agora atuar em conjunto. O SSG monitora as excees. Uma barreira pode exigir que um projeto
se submeta a reviso de cdigo (e corrigir quaisquer questes crticas) antes do seu lanamento. Em alguns casos, as
barreiras so diretamente associadas com controles requeridos por regulao, acordos comerciais e outras obrigaes
comerciais e excees so mapeadas como requisitos regulatrios ou regulamentares. Em outros casos, as barreiras
avaliam o rendimento de indicadores chave de performance que so utilizadas para governar os processos.

[SM2.2]

Crie ou aumente os satlites. O satlite comea como um conjunto de pessoas pela organizao que demonstram
um nvel de interesse ou habilidade em segurana acima da mdia. Identificar este grupo um passo para a criao
de uma rede social que acelera a adoo de segurana no desenvolvimento de software. Uma maneira de comear
monitorar as pessoas que se destacam nos treinamentos. (veja[T2.7 Identifique satlites nos treinamentos].) Outra
forma procurar por voluntrios. Numa abordagem top-down, a adeso inicial dos satlites designada para
garantir a cobertura completa de todos os grupos de desenvolvimento/produto. A continuidade da adeso precisa
ser baseada na performance atual. Satlite forte um bom sinal de uma iniciativa madura de software seguro.

[SM2.3]

Identifique mtricas e use-as para orientar os oramentos. O SSG e sua gesto escolhem mtricas que definem e
avaliam o progresso da iniciativa de segurana de software. Estas mtricas vo orientar o oramento da iniciativa e
a alocao de recursos, ento estatsticas de contagem simples no so suficientes. Mtricas tambm permitem ao
SSG explicar suas metas e seu progresso em termos quantitativos. Uma mtrica pode ser a densidade dos defeitos
de segurana. A reduo da densidade de defeitos de segurana pode ser usada para mostrar um custo decrescente
de remediao ao longo do tempo. A chave aqui amarrar resultados tcnicos com objetivos de negcio de um
modo claro e bvio para justificar o financiamento. Uma vez que o conceito de segurana j tnue para o pessoal
de negcio, torn-lo explicitamente amarrado pode ser muito til.

[SM2.5]

SM Nvel 3: Pratique gesto de portflio baseada em risco. Os responsveis pelas aplicaes e o SSG devem informar
aos gestores sobre o risco associado a cada aplicao no portflio. O SSG deve anunciar as suas atividades externamente
para criar apoio para a sua abordagem e habilitar a segurana no ecossistema.

trs
[SM3.1]

[SM3.2]

2013

Use rastreamento interno de aplicaes com viso do portflio. O SSG usa mapeamento centralizado de
aplicaes para traar o progresso de cada ao relacionada a software sob sua alada. A aplicao registra as
atividades de segurana agendadas, em andamento e concludas. Ele incorpora os resultados de atividades como
anlise arquitetural, reviso de cdigo e testes de segurana. O SSG usa o mapeamento de aplicaes para gerar
relatrios de portflio para muitas das mtricas usadas. Um inventrio combinado e uma postura de viso de riscos
so fundamentais. Em muitos casos, estes dados so publicados pelo menos entre os executivos. Dependendo da
cultura, estes podem causar efeitos interessantes na competio interna. Assim que uma iniciativa amadurece e as
atividades se tornam mais distribudas, o SSG usa o sistema de relatrios centralizados para manter o rastreamento
de todas as partes mveis.
Execute um programa de marketing externo. O SSG promove a iniciativa de segurana de software fora da
empresa para construir apoio externo. A segurana de software cresce alm do exerccio de reduo de riscos e se
torna uma vantagem competitiva ou um diferencial de mercado. O SSG pode escrever artigos ou livros. Ele pode
ter um blog pblico. Membros podem dar palestras em conferncias ou feiras. Em alguns casos, uma metodologia
SSDL completa pode ser publicada e promovida externamente. Dividir detalhes externamente e convidar crticos
pode trazer novas perspectivas para a empresa.

24

GOVERNANA: Conformidade e Poltica (CP)

Os objetivos gerais da prtica Conformidade e Poltica so a orientao normativa para todos os stakeholders e
auditabilidade da atividades do SSDL. A orientao normativa aprovada pela gesto deve estar disponvel para
todas as partes interessadas do SSDL, incluindo fornecedores, para uso no atendimento de objetivos de segurana e
conformidade. Todas as atividades do SSDL devem produzir artefatos suficientes para permitir a auditoria quanto
aderncia s orientaes normativas.
CP Nvel 1: Documente e unifique os direcionadores de conformidade estatutria, regulatria e contratual. O SSG
deve trabalhar com grupos apropriados para captar os requisitos de conformidade de forma unificada numa orientao
normativa e tornar tal conhecimento disponvel aos stakeholders no SSDL.

[CP1.1]

Unifique as presses regulatrias. Se o negcio est sujeito a guias de regulao ou conformidade como FFIEC,
GLBA, OCC, PCI DSS, SOX, HIPAA ou outros, o SSG atua como um ponto focal para a compreenso das
restries que tais guias impem ao software. Em alguns casos, o SSG cria uma abordagem unificada, que remove
a redundncia da sobreposio de requisitos de conformidade. Uma abordagem formal ir mapear sees aplicveis
dos regulamentos para controlar as explicaes de como a organizao ir cumpri-los. Como uma alternativa,
processos de negcio existentes guiados por riscos legais ou de outras naturezas e por grupos de conformidade
externos, o SSG pode tambm atuar como ponto focal. A meta dessa atividade criar um conjunto de orientaes
de segurana de software e assim o trabalho de conformidade completado o mais eficientemente possvel
(principalmente pela remoo dos pontos duplicados). Algumas empresas seguem para guiar a orientao se
tornando diretamente envolvidas nos grupos de padronizao a fim de influenciar o ambiente regulatrio.

[CP1.2]

Identifique as obrigaes PII. A maneira como o software manipula informaes de identificao pessoal (sigla
em ingls PII) pode ser expressamente regulada, mas mesmo que no seja a privacidade muito relevante. O
SSG tem um papel importante na identificao de obrigaes PII decorrentes da regulao e da expectativa
dos clientes. Essas informaes so insumo para promover as melhores prticas de privacidade. Por exemplo, se
a organizao processar transaes com cartes de crdito, o SSG identificar as restries impostas pelo PCI
DSS no manuseio dos dados dos titulares dos cartes. Note que a terceirizao para ambientes de hospedagem
(exemplo, na nuvem) no relaxa a maioria das obrigaes PII. Note tambm, empresas que criam produtos de
software que processem PII (mas no necessariamente manejem dados PII diretamente) devem prover controle
de privacidade e orientao para seus clientes.

[CP1.3]

Crie uma poltica. O SSG orienta o resto da organizao, criando ou contribuindo para a poltica de segurana
de software que satisfaa os requisitos de regulao e requisitos de segurana voltados para o cliente. A poltica
prov uma abordagem unificada para a satisfao da lista (potencialmente longas) da regulao de segurana
no nvel de governana. Como resultado, as equipes de projeto se desobrigam a aprender os detalhes de
toda regulao aplicvel. Da mesma forma, as equipes de projeto no precisam reaprender os requisitos de
segurana do cliente por si s. Os documentos de poltica do SSG so, por vezes, centrados em torno de temas
de conformidade principais, como o respeito manipulao de PII ou o uso de criptografia. Em alguns casos,
documentos da poltica relacionados esto diretamente ao SSDL e seu uso na empresa. Padres de arquitetura
e guias de codificao no so exemplos da poltica de segurana de software. Por outro lado, a poltica que
determina e demanda o uso de guias de codificao e padres de arquitetura para certas categorias contam. A
poltica diz o que permitido e negado ao nvel da iniciativa.

dois

[CP2.1]

25

CP Nvel 2: Alinhe as prticas internas regulao de conformidade e poltica, apoiada pelos executivos. Os
executivos devem promover publicamente o SSG e a iniciativa de segurana de software, inclusive a necessidade de
conformidade. Os gestores de riscos devem assumir explicitamente a responsabilidade pelo risco do software. O SSG
e os responsveis pelas aplicaes devem garantir que os SLAs das entregas dos fornecedores de software contemplam
propriedades de segurana.
Identifique o inventrio dos dados PII. A organizao identifica os tipos de PII armazenados pelos seus sistemas
e os seus repositrios de dados. O inventrio PII pode ser abordado de duas maneiras: atravs de cada aplicao
individualmente pela observao do uso de PII ou atravs de tipo particulares de PII e as aplicaes que os tocam.
Quando combinados com as obrigaes PII da organizao, este inventrio orienta o planejamento de privacidade.
Por exemplo, o SSG passa a ter condies de criar uma lista de bancos de dados que, se violado, exigem notificao
ao cliente.

BSIMM-V

um

Exija a autorizao da segurana para os riscos de conformidade. A organizao possui um processo formal
de aceitao do risco de conformidade e processo de responsabilizao endereando todos os projetos de
desenvolvimento de software. O aceitante do risco concorda com o estado do software antes do seu lanamento.
Por exemplo, a poltica de autorizao pode exigir que o chefe da unidade de negcio autorize as vulnerabilidades
crticas no mitigadas ou passos omitidos do SSDL relativos conformidade. A autorizao precisa ser explcita e
armazenada para futura referncia e as excees precisam ser mapeadas.

[CP2.2]

Implemente e monitore os controles de conformidade. A organizao pode demonstrar conformidade com a

regulao aplicvel, pois suas prticas esto alinhadas com as declaraes de controle desenvolvidas pela SSG. (Veja
[CP1.1] Unifique as presses regulatrias].) O SSG rastreia os controles, orienta reas problemticas e se certifica
que os auditores e reguladores estejam convencidos. Se SDLC da organizao previsvel e confivel, o SSG pode
ser capaz de sentar-se e manter-se pontuando. Caso o SDLC da organizao seja irregular ou pouco confivel, o
SSG pode ser forado a assumir um papel mais ativo como rbitro. Uma empresa fazendo isso apropriadamente
pode explicitamente amarrar satisfatoriamente as suas preocupaes de conformidade com o SSDL.

[CP2.3]

Formalize todos os contratos de fornecedores com SLAs de segurana de software. Os contratos de

fornecedores incluem um acordo de nvel de servio (SLA) garantindo que o fornecedor no comprometer
a histria de conformidade da organizao e a iniciativa de segurana de software. Cada contrato novo ou
renovado contm um conjunto provises exigindo a entrega de um produto ou servio compatvel com a poltica
de segurana da organizao. (Veja[SR2.5 Crie um SLA padronizado].) Em alguns casos, preocupaes com
licenciamento de cdigo aberto iniciam o processo de controle de fornecedores. Isto pode abrir a porta para futura
linguagem de segurana de software no SLA

[CP2.4]

Promova conscientizao dos executivos sobre as obrigaes de conformidade e privacidade. O SSG obtm
patrocnio executivo quanto a atividades de conformidade e privacidade. Os executivos recebem explicaes em
linguagem clara sobre as obrigaes de conformidade e privacidade da organizao e as potenciais consequncias
em caso de falha em satisfaz-las. Para algumas organizaes, explicar o custo direto e os efeitos colaterais da
exposio de dados pode ser uma forma efetiva de abordar o assunto. Para outras organizaes, ter um especialista
externo orienta o trabalho da alta gesto porque alguns executivos valorizam perspectivas externas em detrimento
das perspectivas internas. Um sinal claro de conscincia executiva apropriada a alocao adequada de recursos
para fazer o trabalho.

[CP2.5]

trs

CP Nvel 3: Dados de ameaas, ataques, defeitos e questes operacionais direcionam a evoluo da polticas e a
demanda aos fornecedores. Os executivos devem garantir que a poltica de segurana de software periodicamente
atualizada, baseada em dados reais e que demonstre a continuidade da conformidade na organizao. O SSG, os
responsveis pelas aplicaes e a rea jurdica devem garantir que os fornecedores entreguem software em conformidade
com poltica organizacional relevante.
Crie um atrativo regulatrio. O SSG possui a informao que as entidades reguladoras desejam. A combinao
de poltica, controles e artefatos colhidos ao longo do SSDL d ao SSG a habilidade de demonstrar a histria
de conformidade da organizao sem combater um incndio para cada auditoria. Em alguns casos, reguladores,
auditores e os gerentes seniores ficam satisfeitos com o mesmo tipo de relatrios, que podem ser gerados
diretamente a partir de vrias ferramentas.

[CP3.1]

Imponha a poltica a fornecedores. Os fornecedores so obrigados a aderir s mesmas polticas usadas

internamente. Os fornecedores devem apresentar evidncias que suas prticas de segurana passam por inspeo.
Evidncias incluem resultados de reviso de cdigo ou resultados de testes de penetrao. Fornecedores podem
tambm atestar o de fato que eles esto atestando certos processos do SSDL. Em alguns casos, a pontuao do
BSIMM ou do vBSIMM so utilizadas para ajudar a garantir que os fornecedores esto em conformidade com as
polticas da empresa.

[CP3.2]

[CP3.3]

2013

Conduza o feedback de dados do SSDL de volta poltica. A informao do SSDL rotineiramente retornada
ao processo de criao da poltica. As polticas devem ser melhoradas para encontrar defeitos o quanto antes
ou prevenir sua ocorrncia. Os pontos cegos so eliminados baseados nas tendncias, nas falhas do SSDL. Por
exemplo, anlise arquitetural inadequada, vulnerabilidades recorrentes, barreiras de segurana ignoradas ou a
escolha da empresa errada para executar um teste de penetrao podem expor as fraquezas da poltica. As polticas
se tornam mais prticas e mais fceis de serem executadas com o passar do tempo. (Veja [SM1.1 Publique processo
(papis, responsabilidades, plano), evolua quando necessrio].)Em ltima anlise, as polticas se alinham com os
dados do SSDL, aumentam e melhoram a eficcia de uma empresa.

26

GOVERNANA: Treinamento (T)

Os objetivos gerais para a prtica Treinamento so a criao de uma fora de trabalho bem informada e a correo de
erros no processo. A fora de trabalho deve possuir conhecimento baseado em papis que incluem especificamente
as habilidades exigidas para realizar de forma adequada as atividades SSDL. O treinamento deve incluir informaes
especficas relacionadas s causas raiz dos erros descobertos nas atividades do processo e suas sadas.

[T1.1]

[T1.5]

[T1.6]

[T1.7]

dois

[T2.5]

27

T Nvel 1: Disponibilize os treinamentos personalizados, por papel, sob demanda.O SSG precisa construir interesse
em segurana de software pela organizao e prover material de treinamento especfico por papel, incluindo treinamento
assistido por computador que incorpore lies dos eventos internos atuais.
Fornea treinamento de conscientizao. O SSG fornece treinamento de conscientizao de forma a promover
uma cultura de segurana de software pela organizao. O treinamento pode ser entregue pelos membros do SSG,
por uma empresa externa, pelo treinamento interno da organizao ou por treinamento assistido por computador.
O contedo do curso no necessariamente adaptado a um pblico alvo. Por exemplo, todos os programadores,
engenheiros de garantia de qualidade e gerentes de projeto podem participar do mesmo curso Introduo a
Segurana de Software. Esta atividade em comum pode ser melhorada com uma abordagem customizada para um
curso introdutrio que enderece a cultura da empresa explicitamente. Cursos genricos introdutrios cobrindo o
bsico da segurana de TI e conceitos de alto nvel em segurana de software no geram resultados satisfatrios. Da
mesma forma, prover treinamento de conscientizao somente para desenvolvedores e no para os outros papis
tambm insuficiente.
Distribua um currculo avanado especifico por papis (ferramentas, listas de tecnologias, mostra de bugs).
Treinamento em segurana de software segue atravs da conscientizao e habilita os alunos a incorporar prticas
de segurana no seu trabalho. O treinamento personalizado para os papis dos alunos; Os alunos recebem
informao das ferramentas, listas de tecnologias e tipos de bug que so mais relevantes para eles. Uma organizao
pode oferecer quatro linhas para engenheiros: uma para arquitetos, uma para desenvolvedores Java, uma para
desenvolvedores .NET e uma quarta para testadores. Treinamentos especficos por ferramentas so tambm
observados comumente em um currculo. No esquea que este treinamento ser til para muitos diferentes papis
na organizao, incluindo QA, gesto de produtos, executivos, entre outros.
Crie e use material especfico para a histria da companhia. A fim de provocar mudanas fortes e duradouras
no comportamento, o treinamento deve incluir material especfico para a histria da companhia. Quando os
participantes podem se ver no problema, eles esto mais propensos a entender como material relevante para o seu
trabalho e saber quando e como aplicar o que aprenderam. Um modo de fazer isto usar ataques dignos de ateno
companhia como exemplos no currculo de treinamento. Desconfie de treinamentos que cobrem plataformas no
utilizadas pelos desenvolvedores (desenvolvedores Windows no se preocupam com problemas antigos do Unix)
ou exemplos de problemas que so relevantes para linguagens que no so mais de uso comum (desenvolvedores
Java no precisam entender de buffer overflows em C). Estrias da histria da companhia podem ajudar a conduzir
treinamentos na direo correta somente se as estrias se mantiverem relevantes.
Distribua treinamento individual sob demanda. A organizao reduz a carga nos alunos e reduz os custos de
realizar treinamentos oferecendo-os treinamentos para os indivduos. Treinamento assistido por computador
(CBT) a opo obvia e pode ser mantido atualizado por um modelo de subscrio.
T Nvel 2: Crie o satlite de segurana de software. O SSG deve crescer e fortificar os satlites atravs de atividades
sociais, incluindo treinamento e eventos relacionados. O SSG e os gestores devem garantir que novas contrataes sejam
expostas cultura corporativa de segurana durante as atividades de ambientao.
Fortalea os satlites atravs de treinamentos e eventos. O SSG fortalece sua rede social pela manuteno de
eventos especiais para satlites. Os satlites aprendem sobre tpicos avanados ou assistem palestrantes convidados.
Oferecer pizza e cerveja no atrapalha. Encontros permanentes por teleconferncia no endeream esta atividade,
que tanto sobre construir camaradagem quanto sobre dividir conhecimento ou eficincia organizacional. No
existe substituto para encontros cara a cara, mesmo que eles aconteam apenas um ou duas vezes ao ano.

BSIMM-V

um

Traga pessoal de segurana a bordo. O processo para trazer novos contratados para a engenharia da
organizao requer um mdulo para segurana de software. O processo genrico de novas contrataes cobre
pensamentos como pegar uma boa senha e ter certeza que o pessoal no arraste voc para a construo, mas
isto reforada para cobrir temas como codificao segura, o SSDL, e recursos internos de segurana. O
objetivo garantir que os novos contratados reforcem a cultura de segurana. A rotatividade em organizaes de
engenharia geralmente alta. Ainda que um mdulo genrico seja til a bordo, ele no tem espao em um curso
de segurana de software introdutrio mais completo e oportuno.

[T2.6]

Identifique satlites atravs do treinamento. Os satlites comeam como uma coleo de pessoas disseminadas
atravs da organizao que mostram um nvel acima de mdia de interesse ou habilidades de segurana. A
identificao deste grupo um passo para criao de uma rede social que acelera a adoo de segurana no
desenvolvimento de software. Uma forma de comear mapeando as pessoas que se destacaram durante o curso.
(Veja [SM2.3 Crie ou aumente os satlites].) Em geral, um exrcito de voluntrios pode ser mais fcil de liderar
do que um que foi escolhido.

[T2.7]

trs

T Nvel 3: Promova o reconhecimento para habilidades e um plano de carreira.Tambm construa a moral. Os

gestores e o SSG deve garantir que todos os membros da equipe sejam reconhecidos pelo avano no currculo de
treinamento. Os gestores, responsveis por aplicaes e o SSG devem fornecer treinamento aos fornecedores e
pessoal terceirizado como um mtodo de difundir a cultura de segurana. Os gestores e o SSG devem continuar a
reforar o impulso do satlite pelo marketing externo da cultura de segurana. O SSG precisa estar disponvel, pelo
menos periodicamente, para aqueles procurando orientao em segurana de software. Gestores precisam garantir
que todos os membros da equipe recebem estes treinamentos pelo menos anualmente.
Recompense o avano na grade curricular (certificao e RH). O conhecimento em si j uma recompensa,
mas o progresso no currculo de segurana traz outros benefcios tambm. Os desenvolvedores e os testadores
vem uma vantagem profissional em aprender sobre segurana. O sistema de recompensas pode ser formal
e levar a alguma certificao ou marca oficial no sistema de RH ou pode ser menos formal, a partir do uso
de incentivos como cartas de elogio escritas aos satlites perto da reviso anual. Envolver o departamento de
treinamento da corporao e/ou o RH pode fazer o impacto da segurana na progresso de carreira mais bvio,
mas o SSG precisa continuar a monitorar o conhecimento de segurana na empresa e no abandonar o controle
completo ou a superviso.

[T3.1]

Fornea treinamento para fornecedores e profissionais terceirizados. A organizao oferece treinamento em

segurana para fornecedores e terceirizados. O esforo de ajudar fornecedores a encaminhar a segurana da
maneira correta menor do que a correo do estrago. No melhor caso, todos recebem os mesmos treinamentos.
Treinar individualmente os terceirizados muito mais natural do que treinar empresas de terceirizao inteiras e
um jeito mais razovel de comear. Claramente importante treinar todas as pessoas que trabalham com o seu
software sem se preocupar com o seu tipo de contratao.

[T3.2]

Hospede eventos externos de segurana. A organizao propaga sua cultura de segurana como um diferencial
a partir da hospedagem de eventos externos de segurana. O BlueHat da Microsoft um exemplo de evento,
assim como a Conferncia de Segurana da Intel. Os empregados se beneficiam do acesso a perspectivas
externas. A organizao como um todo se beneficia pela propaganda em segurana. (Veja. [SM3.2 Execute um
programa de marketing externo].)

[T3.3]

Exija reciclagem anual. Todos os envolvidos na construo de software so obrigados a participar de um

curso anual de reciclagem em segurana de software. A reciclagem mantm a equipe atualizada sobre segurana
e garante que a organizao no perde seu foco pela rotatividade. O SSG deve usar metade de um dia para
fornecer uma atualizao sobre o panorama da segurana e explicar as mudanas nos padres e polticas. A
reciclagem pode ser desenrolada como parte de um dia de segurana da empresa ou em consonncia com a
conferncia interna de segurana.

[T3.4]

Estabelea um horrio de trabalho para o SSG. O SSG oferece ajuda para qualquer recm-chegado durante
um perodo de laboratrio anunciado ou por um horrio de expediente regular. Agindo como um recurso
informal para pessoas que precisam resolver problemas de segurana, o SSG alavancar momentos de
aprendizagem e enfatizar a recompensa acima da punio.

[T3.5]

2013

28

INTELIGNCIA: Modelos de Ataque (AM)

O objetivo geral da prtica Modelos de Ataque a criao de conhecimento adaptado aos ataques relevantes para a
organizao. O conhecimento adaptado deve orientar decises tanto sobre cdigo, como controles.
AM Nvel 1: Crie uma base de conhecimento sobre ataques e dados de ativos. O SSG deve identificar os potenciais
atacantes e documentar tanto os ataques que causam uma grande preocupao da organizao e qualquer ataque
importante que j tenha ocorrido. O SSG precisa comunicar informaes sobre atacantes a todas as partes interessadas. O
negcio deve criar um esquema de classificao de dados que o SSG use para inventariar e priorizar aplicaes.

[AM1.1]

Elabore e mantenha uma lista de ataques top N. O SSG ajuda a organizao a entender o bsico sobre os ataques
pela manuteno da lista com os ataques mais importantes e usando esta lista para direcionar as mudanas. Esta lista
combina entrada de mltiplas origens: ataques observados, fruns de hackers, tendncias da indstria, entre outros.
Esta lista no precisa ser atualizada com grande frequncia e os ataques podem ser classificados de forma grosseira. Por
exemplo, o SSG pode realizar reflexes duas vezes por ano para criar uma lista de ataques que a organizao pode estar
preparada para atuar imediatamente, em breve e algum dia. Em alguns casos, informaes do modelo de ataque
so usadas em uma abordagem baseada em listas para anlise arquitetural, ajudando a centrar-se na anlise como no
caso do STRIDE.

[AM1.2]

Crie um esquema de classificao e inventrio de dados. A organizao concorda sobre um esquema de classificao
de dados e usa o esquema para inventariar seu software de acordo com os tipos de dados que o software manipula.
Isto permite que as aplicaes sejam priorizadas pela sua classificao de dados. Muitos esquemas de classificao
so possveis - uma abordagem focar em PII. Dependendo do esquema e do software envolvido, pode ser mais
fcil classificar primeiramente repositrios de dados, ento derivar classificaes para aplicaes de acordo com os
repositrios usados. Outras abordagens para o problema so possveis. Por exemplo, os dados podem ser classificados
de acordo com a proteo da propriedade intelectual, impacto da revelao, exposio ao ataque, relevncia para o
SOX ou barreiras geogrficas.

[AM1.3]

Identifique potenciais atacantes. O SSG identifica atacantes potenciais para compreender suas motivaes e
capacidades. O resultado deste exerccio pode ser um conjunto de perfis de atacantes, incluindo um esboo para
categorias mais abrangentes de atacantes e descries mais detalhadas para indivduos relevantes. Em alguns, um
fornecedor terceiro pode ser contratado para prover esta informao. Informao especfica e contextual do atacante
quase sempre mais til do que informaes genrica copiada da lista de outrem.

[AM1.4]

Colecione e publique histrias de ataques. Para maximizar o benefcio de lies que quase nunca vem de graa,
o SSG coleciona e publica histrias sobre ataques contra a organizao. Ao longo do tempo, esta coleo ajuda a
organizao a compreender a histria. Ambos os ataques bem e mal sucedidos podem ser relevantes. Discutindo
informaes histricas sobre ataques de software tem o efeito de trazer a segurana de software para a realidade da
empresa. Isto particularmente til em treinamentos a fim de combater uma abordagem genrica altamente focada
em lista top tem ou ataques a plataformas ultrapassados e irrelevantes. Escondendo informaes sobre ataques das
pessoas que constroem novos sistemas no traz nenhum benefcio positivo a partir de uma casualidade negativa.

[AM1.5]

[AM1.6]

29

Rena inteligncia sobre ataques. O SSG fica a frente da curva aprendendo novos tipos de ataques e
vulnerabilidades. Essa informao vem da participao em conferencias e workshops, monitoramento de fruns de
ataque e pela leitura de publicaes relevantes, listas de discusses e blogs. Faa Sun Tzu orgulhoso pelo conhecimento
do seu inimigo; Comprometa-se com pesquisadores de segurana que so suscetveis a causar-lhe problemas. Em
vrios casos, a assinatura de servios comerciais prov um modo razovel de adquirir inteligncia bsica sobre ataques.
Independente da sua origem, informaes sobre ataques precisam estar tangvel e usual aos desenvolvedores e
testadores de software.
Crie um frum interno para discutir ataques. A organizao tem um frum interno onde o SSG, os satlites e
outros discutem ataques. O frum serve para comunicar a perspectiva do atacante. O SSG pode manter uma lista
de discusso interna onde os assinantes dividem informaes mais recentes de incidentes publicamente conhecidos.
Disseco de ataques e exploraes que so relevantes para uma empresa pode ser particularmente til, especialmente
se elas estimulam a discusso de mitigaes no desenvolvimento. A simples republicao de itens de listas de discusso
pblicas no alcana os mesmos benefcios de uma discusso ativa. Vigilncia significa nunca ficar to confortvel.
(Veja [SR1.2 Crie um portal de segurana].)

BSIMM-V

um

dois

AM Nvel 2: Fornea divulgao sobre atacantes e ataques relevantes. O SSG deve reunir a inteligncia sobre ataques e
expandir o conhecimento sobre o ataque de modo a incluir tanto padres de ataque de alto nvel e casos de abuso de baixo
nvel. Os padres de ataque devem incluir informao especfica da tecnologia relevante para a organizao.
Construa padres de ataque e casos de abuso amarrados aos potenciais atacantes. O SSG se prepara para os
testes de segurana e para anlise arquitetural pela construo de padres de ataque e casos de abuso amarrados aos
potnciais atacantes. Esses recursos no precisam ser criados do zero para cada aplicao a fim de que seja til, pelo
contrrio, devem existir conjuntos padro para aplicaes com perfis similares. O SSG atualizar essa base a partir das
histrias dos ataques. Por exemplo, um ataque contra gestes ruins de permisses pode levar a um padro de ataque
sobre permisses que impulsiona novos tipos de testes. Se uma empresa mapeia fraudes e custos monetrios para
ataques em particular, essa informao pode ser usada para guiar o processo de construir padres de ataque e casos de
abuso.

[AM2.1]

Crie padres de ataque especficos por tecnologia. O SSG cria padres de ataque especficos baseados em tecnologia
para conquistar conhecimento sobre ataques que tem como alvo tecnologias em particular. Por exemplo, caso o
software web de uma organizao se baseie em recursos de ltima gerao de navegador, o SSG pode catalogar
as brechas dos navegadores mais populares e como elas podem ser exploradas. Padres de ataque diretamente
relacionados com a fronteira de segurana (atualmente segurana para dispositivos mveis e segurana na nuvem)
podem ser teis. A simples republicao de guias genricos (exemplo, Garanta que os dados em trnsito esto
protegidos) e a adio para aplicaes mveis no final no constituem padres de ataque especficos por tecnologia.

[AM2.2]

trs

AM Nvel 3: Pesquise e mitigue novos padres de ataque. O SSG deve conduzir pesquisa sobre ataque ao software
corporativo para obter vantagem sobre a atividade do atacante. O SSG deve fornecer conhecimento e automao
para auditores e testadores como forma de garantir que suas atividades reflitam os ataques perpetrados ao software da
organizao bem como potenciais ataques.

[AM3.1]

Mantenha um time de pesquisa que desenvolve novos mtodos de ataque. O SSG possui uma equipe cientfica
que identifica e torna inerte novos mtodos de ataque antes que eles existam. Isto no se trata de uma equipe de
teste de penetrao buscando novas instncias de tipos conhecidos de fraquezas trata-se de um grupo de pesquisa
na busca por novos tipos de ataques ou novas formas de explorar vulnerabilidades. A equipe cientfica pode incluir
pesquisadores de segurana bem conhecidos que publicam os seus achados em conferncias como a DefCon.

[AM3.2]

Crie e use automao para fazer o que os atacantes faro. O SSG mune testadores e auditores com automao
que reproduz a ao dos atacantes. Por exemplo, um novo mtodo de ataque identificado pela equipe cientfica pode
requerer uma nova ferramenta. O SSG cria a nova ferramenta e a distribui aos testadores. A ideia aqui empurrar
capacidades de ataques alm do que as ferramentas e ofertas tpicas comerciais englobam e ento empacotar estas
informaes para outros utilizarem. Adaptao de ferramentas para as tecnologias particulares de empresa e os
potenciais atacantes uma ideia realmente boa.

2013

30

INTELIGNCIA: Funcionalidades e Projeto de Segurana (SFD)

O objetivo geral da prtica Funcionalidades e Projeto de Segurana a criao de conhecimento adaptado sobre
funcionalidades, frameworks e padres de segurana. Esse conhecimento personalizado deve direcionar as decises de
arquitetura e componentes.

[SFD1.1]

[SFD1.2]

dois
[SFD2.1]

[SFD2.2]

trs

[SFD3.1]

31

SFD Nvel 1: Publique os elementos e arquitetura de segurana. O SSG deve fornecer aos arquitetos e
desenvolvedores orientao sobre funcionalidades de segurana e participar diretamente com os grupos de arquitetura.
Construa e publique funcionalidades de segurana. Alguns problemas devem ser resolvidos somente uma vez. Ao
invs de cada equipe de projeto implementar suas funcionalidades de segurana (autenticao, gesto de papis,
gesto de chaves, auditoria/log, criptografia, protocolos), o SSG fornece orientao proativa a partir da construo
e publicao de mecanismos de segurana para o uso de outros grupos. As equipes de projeto se beneficiam, uma
vez que as implementaes vm pr-aprovadas pelo SSG e o SSG se beneficia por no ter que repetidamente se
envolver em erros que recaem sobre as funcionalidades de segurana. O SSG pode identificar uma implementao
que ele goste e promov-la como uma soluo aceitvel.
Envolva o SSG com a arquitetura. A segurana uma parte frequente da discusso da arquitetura de software
da organizao. O grupo de arquitetura se responsabiliza pela segurana na mesma proporo do desempenho,
disponibilidade e escalabilidade. Uma forma de impedir que a segurana seja desconsiderada da discusso ter um
membro do SSG participando regularmente de reunies de arquitetura. Em outros casos, a arquitetura corporativa
pode ajudar o SSG a criar projetos seguros que se integrem apropriadamente com os padres de projeto
corporativos.
SFD Nvel 2: Construa e identifique solues de segurana. O SSG deve fornecer frameworks seguros desde a
concepo, deve estar disponvel e ser capaz de resolver problemas de projeto para terceiros.
Construa frameworks middleware e bibliotecas seguras desde a concepo. O SSG exerce um papel pr-ativo
no projeto de software fornecendo ou apontando frameworks middleware e bibliotecas seguros desde a concepo.
Adicionalmente ao ensinar por exemplos, tais middleware auxiliam a anlise arquitetural e reviso de cdigo, pois
suas estruturas facilitam a eliminao de erros. Por exemplo, O SSG pode modificar um framework web popular,
como o Spring, para facilitar o cumprimento dos requisitos de validao de entradas. Eventualmente o SSG
pode confeccionar regras de reviso de cdigo especficas para os componentes que ela oferece. (Veja [CR3.1 Use
ferramentas automatizadas com regras adaptadas].) Quando se adota um framework middleware (ou qualquer
outro software largamente utilizado), a habilitao cuidadosa pela segurana antes da publicao importante.
Encorajar a adoo e uso de middleware inseguro no ajuda a situao da segurana de software. Arquiteturas
genricas de cdigo aberto, incluindo OWASP ESAPI, no devem ser consideradas seguras de fbrica.
Crie capacidade no SSG para resolver problemas de projeto complexos. Quando o SSG se envolve
precocemente no processo de um novo produto, ele contribui para uma nova arquitetura e resolve problemas
complexos de projetos. O impacto negativo de segurana que impe outras restries (tempo de colocao no
mercado, preo, entre outros.) minimizado. Caso um arquiteto do SSG seja envolvido no projeto de um novo
protocolo, ele pode analisar a implicaes de segurana de protocolos j existentes e identificar elementos que
possam ser duplicados ou evitados. Projetar segurana no incio mais eficiente do que analisar um projeto de
segurana existente e ento refator-lo quando falhas so descobertas. Alguns problemas de projeto exigiro
expertise especfica de fora do SSG.
SFD Nvel 3: Reuse ativamente os funcionalidades de segurana aprovadas e frameworks seguros desde a
concepo. O SSG deve prover padres de projeto mais maduros retirados de software existentes e da lista de
tecnologias. Os gestores devem garantir que exista um consenso formal na organizao sobre as opes de projeto
seguro. Os gestores devem adicionalmente exigir que as funcionalidades de segurana e os frameworks j definidos
sejam utilizados sempre que possvel.
Estabelea um grupo de reviso ou comit central para aprovar e manter padres de projeto seguros. Um
grupo de reviso ou comit central formaliza o processo por busca de consenso sobre as necessidades de projeto e
os compromissos de segurana. Diferentemente do comit de arquitetura, este grupo especificamente focado em
oferecer orientaes de segurana. O grupo pode tambm periodicamente realizar reviso dos padres de projeto
j publicados (especialmente sobre criptografia), garantindo que as decises de projeto no se tornem velhas ou
desatualizadas.

BSIMM-V

one

[SFD3.2]

[SFD3.3]

2013

Exija o uso de funcionalidades e frameworks de segurana aprovados. Implementadores devem escolher dentre
as listas de funcionalidades e frameworks de segurana aprovadas. So dois os benefcios: os desenvolvedores no
gastam tempo reinventando recursos j disponveis e as equipes de segurana no precisam se preocupar com
defeitos velhos encontrados em projetos novos. Em particular, quanto mais projetos utilizarem componentes j
experimentados, mais a anlise arquitetural e a reviso de cdigo ficam facilitadas. (Veja [AA1.1 Realize reviso
de funcionalidades de segurana].). O reuso a maior vantagem de uma arquitetura de software consistente.
Encontre e publique padres de projetos maduros da organizao. O SSG promove padres de reuso
centralizados pela busca e publicao de padres de projeto maduros a partir e atravs da organizao. Uma
seo no website do SSG pode promover elementos positivos identificados durante a anlise arquitetural, desta
forma boas ideias so disseminadas. Este processo precisa ser formalizado. Uma divulgao ad hoc, acidental no
suficiente. Em alguns casos, uma equipe central de arquitetura ou tecnologia facilita e melhora essa atividade.

32

INTELIGNCIA: Padres e Requisitos (SR)

O objetivo geral da prtica Padres e Requisitos criar uma orientao normativa para todos os stakeholders.
Os gestores e o SSG devem documentar as escolhas de segurana de software e divulgar esse contedo a todos os
envolvidos no SSDL, incluindo as partes externas.

[SR1.1]

SR Nvel 1: Fornea padres e requisitos de segurana acessveis. O SSG deve fornecer conhecimento
fundamental, incluindo pelo menos: padres de segurana, padres de cdigo seguro e requisitos de conformidade.
Os gestores devem garantir que a informao de segurana de software se mantm atualizada e disponvel a todos.
Crie padres de segurana. A segurana de software exige muito mais que funcionalidades de segurana,
mas estas tambm fazem parte do trabalho. O SSG contempla as necessidades de segurana da organizao a
partir da criao de padres que explicam a forma aceitvel de aderir poltica e executar operaes focadas
em segurana. Um padro pode descrever como realizar autenticao usando J2EE ou como determinar
a autenticidade de uma atualizao de software. (Veja [SFD1.1 Construa e publique funcionalidades
de segurana] para os casos nos quais o SSG fornece uma referncia para implementao de padres de
segurana.) Padres podem ser implantados de vrias formas. Em alguns casos, padres e orientaes podem ser
automatizados em ambientes de desenvolvimento (exemplo, trabalhando dentro de uma IDE). Em outros casos,
as orientaes podem ser explicitamente ligadas a exemplos de cdigo para faz-las mais praticveis e relevantes.

[SR1.2]

Crie um portal de segurana. A organizao possui um local central de referncia para informao sobre
segurana de software. Tipicamente ele se caracteriza como um website interno mantido pelo SSG. Uma wiki
interativa melhor do que um portal esttico com documentos de orientao que raramente mudam. As
organizaes podem melhorar estes materiais com listas de discusses e encontros cara a cara.

[SR1.3]

Traduza restries de conformidade para requisitos. As restries de conformidade so traduzidas em

requisitos de software para projetos individuais. Isso uma mo na roda para a estratgia da organizao - pela
representao explcita das restries de conformidade nos requisitos, demonstrando que a conformidade se
torna um risco gerencivel. Por exemplo, caso a organizao rotineiramente construa software para processar
transaes de carto de crdito, conformidade ao PCI DSS pode assumir um papel no SSDL durante a
fase de requisitos. Em outros casos, padres de tecnologia construdos para razes de interoperacionalidade
internacional podem incluir orientaes de segurana. Representar estes padres como requisitos ajuda na
rastreabilidade e visibilidade em caso de auditoria.

[SR1.4]

Use padres de cdigo seguro. Os padres de cdigo seguro ajudam os desenvolvedores a evitarem os bugs
mais bvios e fornecem regras fundamentais para a reviso de cdigo. Os padres de cdigo seguro devem ser
necessariamente especficos por linguagem de programao e podem enderear o uso de frameworks populares
ou bibliotecas. Caso a organizao j possua padres de cdigo para outros propsitos, os padres de cdigo
seguro podem increment-los. Um conjunto claro de padres de codificao segura uma boa forma de orientar
a reviso de cdigo manual e automatizada, bem como reforar os treinamentos de segurana com exemplos
relevantes.

dois

[SR2.2]

33

SR Nvel 2: Comunique padres formalmente aprovados internamente e para os fornecedores. Os gerentes

devem garantir que um processo formal seja usado para criar padres especficos por tecnologia. Os gestores, o
SSG e os responsveis pelos produtos devem garantir que os SLAs sejam reforados por linguagem contratual e
aprovados pela rea jurdica. O SSG deve garantir que todo software de cdigo aberto seja identificado no cdigo da
organizao.
Crie um grupo de reviso de padres. A organizao cria um grupo de reviso de padres para formalizar o
processo utilizado para desenvolver os padres e garantir que os stakeholders tenham a chance de melhor-los.
O grupo pode operar pelo apontamento do campeo para qualquer padro proposto. O nus est no campeo
demonstrar que o padro atende suas metas e conseguir aprovao e patrocnio do grupo. A arquitetura
corporativa ou grupos de risco corporativos algumas vezes tem a responsabilidade de criar e gerenciar o grupo de
reviso de padres.

BSIMM-V

um

[SR2.3]

Crie padres especficos por setores de tecnologia. A organizao padroniza por setores de tecnologias
especficas. Para o SSG isto significa uma sobrecarga reduzida, pois o grupo no precisa explorar novos riscos
da tecnologia para cada novo projeto. Idealmente, a organizao criar uma base de configurao de segurana
para cada setor, reduzindo o trabalho necessrio para usar a tecnologia com segurana. Um setor de tecnologia
inclui sistema operacional, um banco de dados, um servidor de aplicao e um ambiente de execuo para
uma linguagem gerida. A fronteira de segurana um bom lugar para encontrar trao. Atualmente, setores de
tecnologia mvel e plataformas assim como tecnologia baseada na nuvem so duas reas onde ateno especifica
compensa.

[SR2.4]

Identifique cdigo aberto. O primeiro passo no gerenciamento do risco introduzido por cdigo aberto
identificar os componentes de cdigo aberto em uso. No incomum descobrir verses ultrapassadas de
componentes com vulnerabilidades conhecidas ou mltiplas verses de um mesmo componente. Ferramentas
automatizadas para encontrar cdigo aberto uma forma de abordar esta atividade. Um processo que depende
apenas de desenvolvedores solicitando permisso no gera resultados satisfatrios. No prximo nvel de
maturidade, esta atividade apoiada por uma poltica que regula o uso de cdigo aberto.

[SR2.5]

Crie um SLA padronizado. O SSG trabalha com a rea jurdica para criar um modelo de SLA para uso em
contratos com fornecedores e prestadores de servio. O departamento jurdico entende que a padronizao
ajuda a prevenir problemas de privacidade e conformidade. Sob o acordo, os fornecedores e prestadores de
servio devem atender aos padres de segurana de software da empresa. (Veja [CP2.4 Formalize todos os
contratos de fornecedores com SLAs de segurana de software].) Uma linguagem padronizada pode necessitar
de solues de controle de segurana de software para fornecedores como avaliaes vBSIMM ou pontuaes
BSIMM.

trs

SR Nvel 3: Exija decises de gesto de risco para uso de cdigo aberto. Os gestores e o SSG devem mostrar
que qualquer cdigo fonte usado na organizao est sujeito ao mesmo processo de gesto de risco que os cdigos
criados internamente e garantir que todos os padres aplicveis so comunicados para fornecedores terceiros.

[SR3.1]

Controle o risco de cdigo aberto. A organizao controla toda a sua exposio a vulnerabilidades advindas
pelo uso de componentes de cdigo aberto. O uso de cdigo aberto pode ser restrito a projetos pr-definidos.
Ele pode tambm ser restrito a verses de cdigo aberto que passaram por um processo de avaliao de
segurana do SSG, tenham vulnerabilidades inaceitveis remediadas e fiquem disponveis somente a partir de
repositrios internos. Um repositrio interno de cdigo aberto aprovado pode ser usado. O jurdico geralmente
desenvolve controle adicional para o cdigo aberto devido ao problema viral de licenciamento associado
com cdigo GPL. Fazer o jurdico entender o risco de segurana pode auxiliar a levar a organizao a praticar
higienizao aceitvel no cdigo aberto.

[SR3.2]

Comunique padres aos fornecedores. O SSG trabalha com os fornecedores para educ-los e promover os
padres de segurana da organizao. Uma relao saudvel com o fornecedor no pode ser garantida apenas
com a linguagem contratual. O SSG compromete-se com o fornecedor, discute as suas prticas de segurana
e explica em termos concretos (no lugar do juridiqus) o que a organizao espera do fornecedor. A qualquer
tempo que um fornecedor adota os padres de segurana da organizao uma grande vitria. Quando o SSDL
da empresa disponibilizado publicamente, a comunicao em relao s expectativas de segurana de software
se torna mais fcil. Outrossim, dividir prticas internas e avaliaes (incluindo a avaliao do BSIMM) pode
tornar as expectativas muito claras.

2013

34

SSDL Touchpoints: Anlise Arquitetural (AA)

O objetivo geral da prtica Anlise de Arquitetura o controle de qualidade. Aqueles que realizam anlise de arquitetura
devem garantir a deteco e a correo de falhas de segurana. Os arquitetos de software devem garantir aderncia aos
padres e o reuso de funcionalidades de segurana aprovadas.
AA Nvel 1: Realize reviso AA baseada em risco, conduzida pelo SSG. A organizao deve fornecer uma
classificao leve de risco de software. O SSG deve liderar os esforos da anlise de arquitetura, particularmente para as
aplicaes de alto risco, como uma forma de construir capacidade interna e demonstrar valor no nvel de projeto.

[AA1.1]

Realize reviso de funcionalidades de segurana. Para iniciar com a anlise de arquitetura, concentre o processo
nas funcionalidades de segurana. Os revisores que conhecem segurana devem primeiramente identificar os
mecanismos de segurana na aplicao (autenticao, controle de acesso, uso de criptografia, entre outros),
para ento estudar o projeto em busca de problemas que possam causar falhas nestas funcionalidades ou se
comprovarem insuficientes. Por exemplo, um sistema que estava sujeito a ataques de elevao de privilgio
por causa de um controle de acesso frgil ou um sistema que armazenava hashes de senhas sem salt devem ser
identificados neste tipo de reviso. Nos nveis mais elevados de maturidade esta atividade sobreposta por uma
abordagem de anlise arquitetural que extrapola as funcionalidades de segurana. Em alguns casos, o uso de
componentes seguros desde a concepo pode simplificar este processo.

[AA1.2]

Realize reviso de projeto para aplicaes de alto risco. A organizao aprende sobre os benefcios de anlise
arquitetural pela observao de resultados reais para as poucas aplicaes de alto risco e de destaque. Os revisores
precisam ter experincia em executar anlises arquiteturais e na dissecao da arquitetura considerada. Caso o
SSG no esteja preparado para realizar anlise aprofundada de arquitetura, ele lana mo de consultores para este
trabalho. Paradigmas de revises ad hoc que dependem fortemente de expertise podem ser usados aqui, porm ao
longo do tempo elas no escalam.

[AA1.3]

[AA1.4]

dois

[AA2.1]

35

Estabelea um esforo de reviso coordenado pelo SSG. O SSG assume um papel de liderana na anlise
arquitetural de modo a construir a habilidade da organizao em revelar furos. A dissecao da arquitetura um
pouco de arte que exige que o SSG demonstre proficincia, antes de pass-la para os arquitetos e proficincia
requer prtica. O SSG no obter sucesso por si s - ser necessria a participao de arquitetos ou programadores
para compreender o projeto. Com a clareza do projeto nas mos, o SSG pode realizar a anlise com a mnima
interao com o time do projeto. Em nveis elevados de maturidade, a responsabilidade por liderar os esforos de
reviso se move para os arquitetos. Abordagens para a reviso de cdigo (e a modelagem de ameaas) evoluem ao
longo do tempo. No espere estabelecer um processo e utiliz-lo para sempre.
Use um questionrio de risco para categorizar as aplicaes. Para facilitar a anlise arquitetural e outros
processos, o SSG usa um questionrio de risco para coletar informao bsica sobre cada aplicao, de modo que
se possa determinar uma classificao de risco e um modelo de priorizao. As questes podem incluir, Em quais
linguagens de programao a aplicao foi escrita?,Quem usa a aplicao?, e A aplicao manipula PII? Um
membro qualificado da equipe da aplicao responde o questionrio. O questionrio curto o suficiente para
ser concludo em algumas horas. O SSG pode usar as respostas para classificar a aplicao em risco alto, mdio e
baixo. Como um questionrio de risco pode ser facilmente manipulado importante que seja realizado em algum
momento uma verificao da validade e acurcia. Um excesso de confiana no auto relato ou automatizao pode
tornar essa atividade impotente.
AA Nvel 2: Difunda o uso do processo AA documentado. O SSG facilita o uso de anlise arquitetural pela
organizao se colocando disponvel como recurso ou mentor. O SSG deve definir o processo de anlise de arquitetura
baseado em uma linguagem comum descritiva da arquitetura e em padro de modelos de ataque.
Defina e use um processo AA. O SSG define e documenta um processo para realizar anlise de arquitetura e o
aplica na reviso que conduz. O processo inclui uma abordagem padro para reflexo sobre ataques e propriedades
de segurana. O processo definido com o rigor suficiente para que as pessoas fora do SSG possam ser orientadas
e consigam execut-las. Deve-se prestar uma ateno particular na documentao da arquitetura sob reviso e
sobre qualquer falha de segurana descoberta. Conhecimento emprico no conta como um processo definido.

BSIMM-V

um

O STRIDE da Microsoft ou o ARA da Cigital so exemplos de tais processos. Observe que at mesmo essas
duas tecnologias para anlise arquitetural evoluram muito ao longo do tempo. Certifique-se de acessar fontes
atualizadas de informao para anlise arquitetural porque muitas documentaes antigas esto ultrapassadas e no
se aplicam mais.
Padronize a descrio de arquitetura (incluindo fluxo de dados). A organizao usa formatos acordados para
descrever a arquitetura, incluindo formas de representar o fluxo de dados. Este formato, juntamente com o
processo de anlise arquitetural, torna a anlise palatvel para as pessoas que no so peritas em segurana. Uma
descrio padro pode ser melhorada para prover uma viso explcita dos ativos de informao que exigem
proteo. cones padronizados que so consistentemente utilizados como diagramas UML, templates do Visio e
desenhos no quadro branco so especialmente teis.

[AA2.2]

Torne o SSG disponvel como um recurso ou mentor de AA. De modo a capacitar a anlise de arquitetura fora
do SSG, este se divulga como uma fonte ou suporte para equipes que precisam de ajuda na conduo de suas
prprias anlises e pr-ativamente procura projetos para se envolver. O SSG responder s questes de anlise de
arquitetura durante o horrio de expediente e em alguns casos pode atribuir algum para acompanhar o arquiteto
ao longo da anlise. No caso de aplicaes ou produtos de alto risco, o SSG assume um papel mais ativo na
orientao.

[AA2.3]

trs

AA Nvel 3: Forme capacidade de reviso e remediao dentro do grupo de arquitetos. Os arquitetos de software
devem liderar os esforos de anlise pela organizao e devem usar os resultados para atualizar e criar padres seguros de
arquitetura.
Tenha arquitetos de software liderando esforos de reviso de projetos. Os arquitetos de software da organizao
lideram, na maioria das vezes, o processo de anlise de arquitetura. O SSG pode continuar a contribuir segundo
sua capacidade de orientao ou em circunstncias especiais. Esta atividade requer um processo de anlise
arquitetural bem entendido e bem documentado. Mesmo neste caso, a consistncia muito difcil de ser alcanada,
porque dissecar arquiteturas requer muita experincia.

[AA3.1]

Canalize os resultados de anlise para os padres de arquitetura. As falhas identificadas durante a anlise
arquitetural alimentam o comit de projeto de segurana para que erros similares possam ser prevenidos no
futuro a partir de padres de projeto melhorados. (Veja[SFD3.1 Estabelea um grupo de reviso ou comit
central para aprovar e manter padres de projeto seguros].) Padres de projeto seguros podem interagir de formas
surpreendentes na quebra da segurana. O processo de anlise arquitetural precisa ser aplicado mesmo quando
padres de projeto corrigidos esto em utilizao padro.

[AA3.2]

2013

36

SSDL Touchpoints: Reviso de Cdigo (CR)

O objetivo geral da prtica Reviso de Cdigo o controle de qualidade. Aqueles que realizam reviso de cdigo devem
garantir a deteco e correo de bugs de segurana. O SSG deve impor aderncia aos padres e o reuso de mecanismos
de segurana aprovados.

[CR1.1]

[CR1.2]

[CR1.4]

[CR1.5]

[CR1.6]

37

CR Nvel 1: Utilize reviso de cdigo manual ou automatizada com relatrios centralizados. O SSG deve se colocar
a disposio para aumentar a conscientizao e a demandas de reviso de cdigo. O SSG deve realizar reviso de
cdigo para aplicaes de alto risco sempre que puder se envolver no processo e deve usar o conhecimento obtido para
informar a organizao dos tipos de bugs descobertos. A gesto precisa fazer a reviso de cdigo obrigatria para todos
os projetos de software. O SSG precisa aplicar o uso de ferramentas centralizadas de relatrio para reter o conhecimento
de bugs recorrentes e transformar esta informao em estratgia e treinamentos.
Crie uma lista de bugs top N (preferencialmente com dados reais). O SSG mantm uma lista com os tipos de
bugs mais importantes que necessitam ser eliminados do cdigo da organizao. A lista ajuda a focar a ateno
da organizao nos bugs mais importantes. Uma lista genrica pode ser obtida de fontes pblicas, mas uma lista
mais valiosa se ela especfica da organizao e construda a partir de dados coletados na reviso de cdigo, testes e
incidentes reais. O SSG pode periodicamente atualizar a lista e publicar um relatrio dos mais procurados. (Para
conhecer outra maneira de usar a lista, veja [T1.6 Crie e use material especfico para a histria da companhia].)
Algumas empresas usam mltiplas ferramentas e uma base de cdigo real para criar listas top N, no se restringindo
a uma ferramenta ou servio em particular. Uma armadilha em potencial com uma lista dos top N o problema
de procurar uma agulha no palheiro. Por exemplo, a lista OWASP top ten raramente reflete as prioridades de bug
de uma organizao. Simplesmente classificando os dados de bug do dia por quantidade de ocorrncias no produz
uma lista top N satisfatria, uma vez que esses dados no mudam to frequentemente.
Tenha o SSG realizando revises ad hoc. O SSG realiza uma reviso de cdigo ad hoc para aplicaes de alto
risco numa abordagem oportunista. Por exemplo, o SSG pode dar seguimento reviso de projeto para aplicaes
de alto risco com uma reviso de cdigo. Substitua a abordagem ad hoc por uma abordagem sistemtica em nveis
de maturidade mais elevados. A reviso do SSG pode envolver o uso de ferramentas especficas e servios ou pode
ser manual.
Use ferramentas automatizadas juntamente com reviso manual. Incorpore anlise esttica no processo de
reviso de cdigo, de modo a tornar a reviso de cdigo mais eficiente e mais consistente. A automao no
substitui o julgamento humano, mas traz mais clareza ao processo de reviso e expertise de segurana para os
revisores que no so peritos em segurana. A empresa pode utilizar um fornecedor externo de servio como parte
de um processo formal de reviso de cdigo para segurana de software. Este servio precisa ser explicitamente
conectado com o SSDL aplicado durante o desenvolvimento de software e no somente marque a caixinha de
segurana no caminho para a implantao.
Torne a reviso de cdigo obrigatria para todos os projetos. A reviso de cdigo obrigatria para liberao de
todos os projetos debaixo da competncia do SSG. A falta da reviso de cdigo ou resultados inaceitveis ir parar
o trem da verso. Embora todos os projetos precisem submeter-se a reviso de cdigo, o processo de reviso pode
ser diferente para os vrios tipos de projeto. A reviso para projetos de baixo risco podem se apoiar pesadamente
em automao e a reviso para projetos de alto risco podem ter tempo ilimitado na mo dos revisores. Na maioria
dos casos, a barreira da reviso de cdigo com um padro mnimo aceitvel fora os projetos reprovados a serem
corrigidos e reavaliados antes do lanamento.
Utilize relatrios centralizados para fechar o lao do conhecimento e orientar e treinamento. Os bugs
encontrados durante a reviso de cdigo so mapeados em um repositrio central. Este repositrio torna possvel
fazer relatrios concisos e relatrios de tendncia. O SSG pode usar estes relatrios para demonstrar progresso e
direcionar o currculo de treinamento. (Veja [SM2.5 Identifique mtricas e use-as para direcionar os oramentos].)
Informao sobre reviso de cdigo ser incorporada ao dashboard de nvel executivo (CSO) que inclui informaes
de outras partes da segurana da organizao. Igualmente, a informao da reviso de cdigo pode alimentar
um sistema de mapeamento de projetos de desenvolvimento que acumula diversas informaes de segurana
de software (por exemplo, testes de penetrao, testes de segurana, testes caixa preta, testes caixa branca, entre
outros). No se esquea que bugs individualmente se tornam excelentes exemplos para o treinamento.

BSIMM-V

um

dois

CR Nvel 2: Imponha padres a partir do processo de reviso de cdigo. O SSG deve orientar o comportamento do
desenvolvedor pela imposio de padres de cdigo com ferramentas automatizadas e orientao sobre ferramentas. O
SSG deve combinar tcnicas de avaliao automatizada com regras personalizadas para encontrar problemas eficientemente.
Imponha padres de cdigo. Uma violao no padro de cdigo da organizao suficiente para rejeitar uma
parte do cdigo. A reviso de cdigo objetiva - ela no entra no mrito de quando um cdigo ruim explorvel.
A parte de imposio do padro pode ser to simples quanto uma lista de funes banidas. Em alguns casos, padres de cdigo so publicados para os desenvolvedores como orientaes especficas para o tipo de tecnologia (por
exemplo, orientaes para C++ ou Spring) e ento imp-las durante o processo de reviso de cdigo ou diretamente na IDE. Note que as orientaes podem ser positivas (faa isso desta forma) ou negativas (no use esta API).

[CR2.2]

Atribua mentores de ferramentas. Os mentores esto disponveis para mostrar aos desenvolvedores como tirar
o mximo das ferramentas de reviso de cdigo. Caso o SSG seja mais habilidoso com as ferramentas, pode-se
usar o horrio de expediente para ajudar aos desenvolvedores a estabelecerem a configurao certa ou inici-los na
interpretao os resultados. Alternativamente, algum do SSG pode trabalhar com a equipe de desenvolvimento ao
longo da primeira reviso realizada por eles. O uso centralizado de ferramentas pode ser distribudo para o grupo
de desenvolvimento ao longo do tempo pela utilizao de mentores de ferramentas.

[CR2.5]

Use ferramentas automatizadas com regras adaptadas. Adapte a anlise esttica para melhorar a eficincia e
reduzir falsos positivos. Use regras adaptadas para encontrar erros especficos para os padres de cdigo ou do
middleware adaptado da organizao. Desabilite verificaes irrelevantes. O mesmo grupo que fornece a orientao
de ferramenta, provavelmente, encaminhar a customizao. Regras personalizadas podem ser explicitamente
amarradas para o uso apropriado em cada tipo de tecnologia em um senso positivo e evitar erros comumente
encontrados na base de cdigo da empresa em um senso negativo.

[CR2.6]

trs

CR Nvel 3: Construa uma fbrica de reviso de cdigo fonte com regras personalizadas. O SSG deve construir a
capacidade de encontrar e erradicar bugs especficos de toda base de cdigo.

[CR3.2]

Construa uma fbrica. Combine resultados de avaliao de modo que mltiplas fontes de anlises alimentem um
nico relatrio e processo de remediao. O SSG pode escrever scripts para invocar automaticamente mltiplas
tcnicas de deteco e combinar os resultados em um formato que possa abastecer uma nica reviso e soluo de
relatrio. Os engenheiros de anlise podem combinar anlise esttica e dinmica. A parte complicada desta atividade normalizar a informao de vulnerabilidade advinda de fontes distintas e que utilizam terminologia conflitante. Em alguns casos, uma abordagem do tipo CWE pode ajudar com a nomenclatura. Combinar mltiplas fontes
ajuda a conduzir melhor deciso de mitigao dos riscos informados

[CR3.3]

Construa capacidade para erradicar bugs especficos de toda a base de cdigo. Quando um novo tipo de bug
encontrado, o SSG pode escrever regras para encontr-lo e ento utilizar estas regras para identificar todas as ocorrncias na base de cdigo. Com isto possvel erradicar completamente um tipo de bug sem esperar cada projeto
alcanar a parte de reviso de cdigo em seu ciclo de vida. A empresa que tem somente um punhado de aplicaes
ter mais facilidade com esta atividade que uma empresa com um grande nmero de aplicaes grandes.
Automatize a deteco de cdigo malicioso. A reviso de cdigo automatizada utilizada para identificar cdigos
perigosos escritos por desenvolvedores maliciosos da instituio ou por terceirizados. Exemplos de cdigos maliciosos que podem ser atingidos so: backdoors, bombas lgicas, bombas relgio, canais de comunicaes ilegais,
lgicas de programao ofuscada e injeo dinmica de cdigo. Embora a automao padro possa identificar
algumas construes maliciosas, regras personalizadas para ferramentas de anlise esttica, utilizadas para identificar
padres de cdigo aceitveis e inaceitveis na base de cdigo da organizao, se tornaro rapidamente necessrias.

[CR3.4]

2013

38

SSDL Touchpoints: Testes de Segurana (ST)

O objetivo geral da prtica Testes de Segurana o controle de qualidade realizado durante o ciclo de
desenvolvimento. Aqueles que realizam o teste de segurana devem garantir a deteco e correo de bugs de
segurana. O SSG deve impor aderncia aos padres e o reuso de funcionalidades aprovadas de segurana.

[ST1.1]

[ST1.3]

dois

[ST2.1]

[ST2.4]

trs

[ST3.1]

[ST3.2]

39

ST Nvel 1: Incremente a QA alm da perspectiva funcional. O QA deve evoluir para que acrescente testes de
borda e condies de fronteira em suas sutes de teste. As sutes de teste devem incluir testes de segurana funcional.
Garanta que o QA suporte teste de fronteira e de condio de valor limite. O time de QA extrapola o teste
funcional para realizar testes antagonistas. Eles verificam casos simples de borda e condies de limite de fronteira. No necessria habilidade de atacante. Quando a QA entende o valor de avanar alm de testes funcionais
padro utilizando entradas aceitveis, eles passam lentamente a pensar como o cara mal. Uma discusso de
testes de valores limite leva naturalmente a noo do atacante sondando as bordas propositalmente. O que
acontece quando voc entra uma senha errada diversas vezes?
Oriente os testes com requisitos e funcionalidades de segurana. Os testadores miram mecanismos de
segurana declarativa derivados dos requisitos e funcionalidades de segurana. Por exemplo, um testador pode
tentar acessar funcionalidades administrativas como um usurio sem privilgio ou verificar que uma conta de
usurio bloqueada aps certo nmero de tentativas de autenticao invlidas. Para a maior parte, as funcionalidades de segurana podem ser testadas de modo similar a outras funcionalidades de software. Mecanismos de
segurana baseados em requisitos como desbloqueio de contas, limitao de transaes, permisses, entre outros
so testados. Obviamente segurana de software no software de segurana, mas comear com essas funcionalidades fcil.
ST Nvel 2: Integre a perspectiva do atacante aos planos de teste. O QA deve integrar ferramentas de testes de
segurana caixa preta ao processo. O QA deve construir sutes de testes para recursos de segurana funcional. O SSG
deve dividir o seu conhecimento de segurana e os resultados de testes com o QA.
Integre ferramentas de caixa preta de segurana no processo do QA. A organizao usa uma ou mais ferramentas de teste caixa preta de segurana como parte do processo de garantia da qualidade. As ferramentas so
valorosas, pois elas encapsulam a perspectiva do atacante, mesmo que de forma genrica. Ferramentas como a
IBM Security AppScan ou HP WebInspect so relevantes para aplicaes web, e frameworks fuzzing como o
Codenomicon so aplicveis para a maioria dos protocolos de rede. Em algumas situaes, outro grupo pode
colaborar com o SSG para aplicar as ferramentas. Por exemplo, um time de teste pode rodar a ferramenta, mas
leva os resultados para o SSG ajudar na interpretao. Independentemente de quem executa a ferramenta caixa
preta, os testes precisam ser propriamente integrados no ciclo do QA dentro do SSDL.
Compartilhe os resultados de segurana com o QA. O SSG rotineiramente divide os resultados das revises de
segurana com o departamento de QA. Ao longo do tempo, os engenheiros de QA aprendem a mentalidade de
segurana. Utilizando os resultados de segurana para informar e evoluir os padres de testes particulares pode
ser um mecanismo poderoso para um melhor teste de segurana. Esta atividade beneficia o QA com foco em
engenharia que altamente tcnico.
ST Nvel 3: Entregue teste de segurana baseado em riscos. O QA deve incluir teste de segurana nas sutes de
regresso automatizadas. O SSG deve garantir que o teste de segurana e a sua profundidade sejam guiados pelo
conhecimento sobre a base de cdigo e seus riscos associados, bem como testes antagonistas que simulam a perspectiva do atacante.
Inclua testes de segurana na automao de QA. Os testes de segurana ocorrem paralelamente aos funcionais
como parte de testes de regresso automatizados. O mesmo framework de automao hospeda ambos. O teste
de segurana parte da rotina. Os testes de segurana podem ser conduzidos a partir de casos de abuso identificados anteriormente no ciclo de vida ou por testes derivados de ajustes criativos nos testes funcionais.
Realize testes fuzz personalizados para as APIs das aplicaes. Engenheiros de automao de testes personalizaram o framework fuzzing para as APIs da organizao. Eles podem comear do nada ou utilizar um
conjunto de ferramentas fuzzing existentes, mas a personalizao vai alm de criar descries personalizadas de
protocolos ou templates de formato de arquivos. Os frameworks fuzzing possuem um entendimento integrado

BSIMM-V

um

das interfaces das aplicaes que ele chama. Testar protees desenvolvidas explicitamente para aplicaes em
particular podem ser bons lugares para integrar o teste fuzz.
Oriente os testes pelos resultados de anlise de risco. Os testadores se valem dos resultados de anlise de
arquitetura para direcionar seu trabalho. Por exemplo, caso a anlise de arquitetura conclua a segurana do
sistema depende da transao ser atmica e no ser interrompida ao longo de sua execuo, ento subverter
transaes se tornar o alvo principal dos testes antagnicos. Testes antagnicos como este podem ser desenvolvidos de acordo com perfil de risco falhas de alto risco vm primeiramente.

[ST3.3]

Alavanque anlise de cobertura. Os testadores avaliam a cobertura de cdigo de seus testes de segurana para
identificar o cdigo que esteja sendo exercitado. A cobertura de cdigo leva ao aumento da profundidade dos
testes de segurana. Ferramentas padro de testes caixa preta alcanam cobertura excepcionalmente baixa,
deixando a maior parte do software sob teste inexplorado. No deixe isso acontecer com os seus testes. Utilizar
avaliaes padronizadas para cobertura como cobertura de funes, cobertura de linha ou cobertura de mltiplas condies uma boa.

[ST3.4]

Comece a construir e aplicar testes antagnicos de segurana (casos de abuso). Os testes comeam a
incorporar casos de testes baseados em casos de abuso fornecidos pelo SSG. Os testadores se movem alm de
verificar funcionalidades e tomam a perspectiva do atacante. Por exemplo, os testadores podem sistematicamente tentar replicar incidentes da histria da organizao. Casos de abuso e m utilizao baseados na perspectiva
do atacante pode tambm ser derivados da poltica de segurana, inteligncia de ataque e diretrizes. Isto uma
virada no jogo, de testar funcionalidades para tentativas de quebrar o software sob teste.

[ST3.5]

2013

40

IMPLANTAO: Testes de Penetrao (PT)

O objetivo geral da prtica Testes de Penetrao o controle de qualidade do software que passou pelo
desenvolvimento. Aqueles que realizam os testes de penetrao devem garantir a deteco e correo de defeitos de
segurana. O SSG deve impor aderncia aos padres e o reuso de funcionalidades de segurana aprovadas.

[PT1.1]

[PT1.2]

[PT1.3]

dois

[PT2.2]

[PT2.3]

trs

41

PT Nvel1: Corrija os achados do teste de penetrao. Os gestores e o SSG deve iniciar o processo de testes de
penetrao, com recursos internos ou externos. Os gestores e o SSG devem garantir que as deficincias descobertas
sejam endereadas e que todos estejam cientes do progresso.
Use testadores externos para encontrar problemas. Muitas organizaes no se preocupam em enderear a
segurana de software at que exista uma evidncia inquestionvel de que no esto magicamente imunes ao
problema. Caso a segurana no tenha sido prioridade, testadores externos (de penetrao) demonstram que o
cdigo da organizao precisa de ajuda. Testadores externos podem ser trazidos para quebrar uma aplicao de
destaque com o objetivo de marcar este ponto. Ao longo do tempo, o foco dos testadores se move de eu disse
que o suas aplicaes estavam quebradas para smoke tests e verificao de integridade antes do lanamento.
Avaliadores externos trazem uma nova viso para o problema.
Fornea resultados para gesto e mitigao de defeitos do sistema. Os resultados do teste de penetrao
so encaminhados aos desenvolvedores atravs de canais estabelecidos de gesto ou mitigao de defeitos e os
desenvolvedores respondem via processo de gesto de defeitos e liberao. O exerccio demonstra a habilidade da
organizao em melhorar seu estado de segurana. Muitas empresas esto comeando a enfatizar a importncia
crtica de no s identificar, mas, o mais importante, corrigir os problemas de segurana. Um modo de garantir
a ateno adicionar uma flag de segurana no sistema de rastreamento de bugs e gesto de defeitos. Envolver
os DevOps e as estruturas das equipes integradas no elimina a necessidade de um sistema formalizado de gesto
de defeitos.
Utilize ferramentas de teste de penetrao internamente. A organizao cria capacidade interna de teste
de penetrao que faz uso de ferramentas. Esta capacidade pode ser parte do SSG e parte de uma equipe
especializada e treinada que fica em outra posio na organizao. As ferramentas aumentam a eficincia e
a reprodutibilidade do processo de testes. As ferramentas podem incluir produtos de prateleira, ferramentas
padro de testes de penetrao de rede que conhecem a camada de aplicao e scripts escritos mo.
PT Nvel 2: Agende testes de penetrao regulares com os testadores internos. O SSG deve criar a capacidade
interna de teste de penetrao que seja periodicamente aplicado a todas as aplicaes. O SSG deve compartilhar seu
conhecimento de segurana e resultados de testes com todos os testadores de penetrao.
Fornea toda informao disponvel aos testadores. Testadores de penetrao, sejam eles internos ou
externos, utilizam toda a informao sobre seus alvos. Os testadores de penetrao podem realizar uma
anlise aprofundada e encontrar problemas mais interessantes quando eles possuem acesso ao cdigo fonte,
especificaes, resultados de anlise de arquitetura e resultados de reviso de cdigo. D aos testadores tudo
que voc criou atravs do SSDL. Se o seu testador de penetrao no pedir a voc o cdigo, voc precisa de um
testador novo.
Agende testes de penetrao para cobertura da aplicao. Teste periodicamente todas as aplicaes ao alcance
do SSG de acordo com uma agenda estabelecida (que pode estar associada a um calendrio ou ao ciclo de
liberao). Os testes servem como uma verificao de integridade e ajudam a garantir que o software de ontem
no vulnervel aos ataques de hoje. As aplicaes crticas devem passar por teste de penetrao pelo menos
uma vez por ano. Um aspecto importante de testes peridicos ter certeza que os problemas identificados nos
testes de penetrao esto atualmente corrigidos e que eles no retornem para a construo.
PT Nvel 3: Realize testes profundos de penetrao. Gestores devem garantir que o conhecimento em teste
de penetrao da organizao acompanhe os avanos dos atacantes. O SSG deve se aproveitar do conhecimento
organizacional para personalizar ferramentas de teste de penetrao.

BSIMM-V

um

Use testadores externos para realizar testes profundos. A organizao usa testadores de penetrao externos
para realizar anlises profundas em projetos crticos e para oxigenar pensamento dentro do SSG. Tais testadores
so peritos e especialistas. Eles mantm a organizao com a perspectiva mais atual do atacante e eles possuem
experincia para subverter o tipo de software testado. Testadores habilidosos sempre subvertero o sistema.
A questo se eles demonstram as novas formas de pensamento sobre ataques que podem ser teis quando
projetando, implementando e fazendo o hardening dos novos sistemas. A criao de novos tipos de ataques a
partir da inteligncia em ameaas e casos de abuso previne abordagens baseadas em checklists que s olham para
tipos conhecidos de problemas.

[PT3.1]

Faa com que o SSG personalize as ferramentas e scripts para testes de penetrao.O SSG cria ferramentas
de teste de penetrao ou adapta ferramentas pblicas disponveis para que possam atacar de forma mais
eficiente e abrangente os sistemas da organizao. As ferramentas melhoram a eficincia do processo de teste de
penetrao sem sacrificar a profundidade dos problemas que o SSG pode identificar. Ferramentas que podem ser
personalizadas so sempre preferveis a ferramentas genricas.

[PT3.2]

2013

42

IMPLANTAO: Ambiente de Software (SE)

O objetivo geral da prtica Ambiente de Software a gesto da mudana. Aqueles responsveis pelo ambiente
de software devem garantir sua habilidade para fazer mudanas autorizadas e detectar mudanas e atividades no
autorizadas. Os gestores devem impor conformidade poltica corporativa.

[SE1.1]

[SE1.2]

dois

[SE2.2]

[SE2.4]

trs

[SE3.2]

[SE3.3]

43

SE Nvel 1: Garanta que o ambiente da aplicao suporta segurana de software. A operao garante que os controles
de segurana exigidos para os hosts e a rede funcionem e monitorem proativamente o software, incluindo suas entradas.
Use monitoramento de entradas da aplicao. A organizao monitora as entradas que o software processa para
identificar ataques. Para cdigo web, um firewall de aplicao web (WAF) pode realizar esse trabalho. O SSG pode
ser responsvel em cuidar e alimentar o sistema. Responder aos ataques no parte dessa atividade. WAFs frgeis
que escrevem arquivos de log podem ser teis se algum revisa estes logs periodicamente. Por outro lado, um WAF
sem monitoramento no faz barulho quando a aplicao cai na floresta.
Garanta que o bsico de segurana de host e de rede esteja no lugar. A organizao prov uma fundao slida
para o software, garantindo que a base de segurana de host e de rede esteja em operao. Comumente equipes de
segurana da operao so responsveis por funes como atualizao de sistemas operacionais e manuteno de
firewall. Fazer a segurana de software antes da segurana de redes como colocar suas calas antes de colocar suas
roupas ntimas.
SE Nvel 2: Utilize guias de instalao publicados e cdigo assinado. O SSG deve garantir que o processo de
desenvolvimento de software proteja a integridade do cdigo. O SSG precisa garantir que guias de instalao e
manuteno so criados para os grupos de operadores utilizarem.
Publique guias de instalao. O SSDL requer a criao de uma guia de instalao para ajudar os operadores
a instalar e configurar o software de forma segura. Caso sejam necessrios passos especiais para garantir que
a implantao seja segura, os passos so traados no guia de instalao. O guia deve incluir discusses sobre
componentes COTS. Em alguns casos, as guias de instalao so distribudas para os consumidores que
compraram o software. Envolver DevOps e as estruturas das equipes integradas no elimina a necessidade de guias
escritos. Claramente, segurana por padro sempre o melhor caminho a seguir.
Utilize cdigo assinado. A organizao usa assinatura de cdigo para a publicao de software alm de suas
fronteiras de confiana. O cdigo assinado particularmente til para proteger a integridade do software que sai
do controle da organizao, como aplicaes empacotadas ou clientes pesados. O fato de que algumas plataformas
mveis requeiram que o cdigo da aplicao seja assinado no indica o uso institucional de cdigo assinado.
SE Nvel 3: Proteja o cdigo no lado do cliente e monitore ativamente o comportamento do software. O SSG deve
garantir que o cdigo que sai da organizao est protegido. O grupo de operaes precisa monitorar o comportamento
do software.
Use proteo de cdigo. Para proteger a propriedade intelectual e tornar a explorao do desenvolvimento mais
difcil, a organizao impe barreiras engenharia reversa. Tcnicas de ofuscao podem ser aplicadas como parte
do processo de construo e liberao do produto. O emprego de controles especficos por plataforma como
Preveno da Execuo de Dados (DEP), Manipulao Segura e Estruturada de Erros (SafeSEH) e Randomizao
de Layout do Espao de Endereo (ASLR) pode tornar o desenvolvimento de exploraes mais difcil.
Utilize o monitoramento do comportamento e diagnstico das aplicaes.A organizao monitora o
comportamento do software de produo procurando por mau comportamento e sinais de ataque. Esta atividade
vai alm do monitoramento de host e rede para problemas que so especficos do software, como indcios de
fraude. Deteco de intruso e sistemas de deteco de anomalias para o nvel de aplicao devem focar na
interao da aplicao com o sistema operao (atravs das chamadas de sistemas) ou com os tipos de dados que as
aplicaes consomem, originam e manipulam.

BSIMM-V

um

(blank page)

2013

44

IMPLANTAO: Gesto de Configurao e Gesto de Vulnerabilidade (CMVM)

O objetivo geral da prtica Gesto de Configurao e Gesto de Vulnerabilidade gerir mudana. O SSG e os responsveis
pelas aplicaes devem garantir sua habilidade em rastrear mudanas autorizadas a aplicaes e detectar mudanas e
atividades no autorizadas. Os responsveis pelas aplicaes devem garantir conformidade poltica corporativa.

[CMVM1.1]

[CMVM1.2]

two
[CMVM2.1]

[CMVM2.2]

[CMVM2.3]

three
[CMVM3.1]

[CMVM3.2]

45

CMVM Nvel 1: Utilize dados da operao para orientar o comportamento do desenvolvedor. O SSG deve apoiar a
resposta a incidentes. O SSG deve utilizar dados da operao para sugerir mudanas no SSDL e no comportamento do
desenvolvedor.
Crie ou interaja com a resposta a incidentes. O SSG est preparado para responder a um incidente. O grupo cria
sua prpria capacidade de resposta a incidentes ou interage com o time de resposta j existente na organizao. Uma
reunio regular entre o SSG e o time de resposta a incidentes pode manter a informao fluindo em ambas as direes.
Em diversos casos, iniciativas de segurana de software evoluram de times de resposta a incidentes que comearam a
perceber que as vulnerabilidades de software eram a maldio da sua existncia.
Identifique os defeitos de software encontrados na operao e realimente o desenvolvimento com eles. Os
defeitos identificados na operao so retornados ao desenvolvimento e utilizados para mudar o comportamento do
desenvolvedor. O contedo dos logs de produo podem ser reveladores (ou podem revelar necessidade de melhoria
do logging). Em alguns casos, prover um modo de introduzir os dados de triagem dos incidentes no sistema de
rastreamento de bugs existente (muitas vezes utilizando a flag especial de segurana) parece funcionar. A ideia fechar
o lao da informao e ter certeza que os problemas de segurana so corrigidos. No melhor dos casos, processos no
SSDL podem ser melhorados baseados nos dados operacionais.
CMVM Nvel 2: Certifique-se que a resposta de emergncia est disponvel durante ataques a aplicaes. Os gestores
e o SSG devem apoiar resposta de emergncia a ataques na aplicao em uso. Os gestores e o SSG mantm um inventrio
do cdigo. O SSG usa os dados da operao para detectar a evoluo do SSDL e do comportamento do desenvolvedor.
Estabelea uma resposta de emergncia base de cdigo. A organizao pode realizar mudanas simples no cdigo
quando uma aplicao estiver sob ataque. Um time de resposta rpida trabalha em conjunto com os responsveis
pela aplicao e com o SSG para estudar o cdigo e o ataque, encontrar uma soluo e encaminhar uma correo
para produo. Muitas vezes, o time de resposta a incidentes de emergncia o time de desenvolvimento em pessoas.
Apagar incndios no conta; um processo bem definido necessrio.
Acompanhe o processo de correo das falhas encontradas na operao do software. Defeitos encontrados durante
a operao so encaminhados aos desenvolvedores, inseridos em um sistema de gesto de defeitos, e rastreados ao
longo do processo de correo. Esta capacidade pode vir na forma de uma ponte de mo dupla entre quem encontra
e quem corrige os bugs. Certifique-se de que o lao fechado por completo. Marcar a flag de segurana no sistema de
rastreamento de bugs pode ajudar a facilitar o acompanhamento.
Desenvolva inventrio de aplicaes em operao. A organizao possui um mapa de todo o seu software
implantado. Caso uma parte do cdigo necessite de alterao, a operao pode identificar seguramente o impacto das
mudanas que precisam ser aplicadas. Algumas vezes, componentes comuns que so compartilhados entre mltiplos
projetos so bem conhecidos, de modo que quando um erro ocorre uma aplicao, outras aplicaes que dividem o
mesmo componente podem ser corrigidas tambm.
CMVM Nvel 3: Crie um lao apertado entre a operao e o desenvolvimento. O SSG deve garantir que o SSDL tanto
enderece as deficincias encontradas no cdigo, quanto promova melhorias que eliminem as causas raz associadas.
Corrija todas as ocorrncias de bugs de software em operao. A organizao corrige todas as instncias dos bugs de
software encontradas durante a operao e no somente um pequeno nmero de instncias disparadas nos relatrios
de bug. Isto exige habilidade para reexaminar toda a base de cdigo quando novos tipos de bugs so revelados.
(Veja[CR3.3 Construa capacidade para erradicar bugs especficos de toda a base de cdigo.]) Um modo de abordar
isto criar um conjunto de regras que generalize um bug implantado em algo que pode ser examinado por reviso de
cdigo automatizado.
Melhore o SSDL para prevenir bugs de software encontrados na operao. Experincia da operao leva a
mudanas no SSDL. O SSDL fortalecido para prevenir bugs encontrados durante a operao. Para tornar tal
processo sistemtico, a resposta post mortem do incidente pode incluir um passoretorno ao SSDL. Isso funciona
melhor quando uma anlise de causa raiz aponta onde em um SLDC o erro foi introduzido ou escorregou por
descuido. Uma abordagem ad hoc no suficiente.

BSIMM-V

one

[CMVM3.3]

[CMVM3.4]

2013

Simule uma crise de software. O SSG simula crises de segurana de software de alto impacto para garantir que as
capacidades de resposta a incidentes minimizem os estragos. Simulaes podem testar a habilidade de identificar e
mitigar ameaas especficas ou, em outros casos, pode comear com a premissa que um sistema ou servio crtico j est
comprometido e avaliar a habilidade da organizao de responder. Quando o modelo de simulao ataca com sucesso,
uma questo importante a considerar o perodo de tempo necessrio para colocar tudo no lugar. Independentemente,
as simulaes devem focar em falhas de segurana de software relevantes e no em desastres naturais ou outros tipos de
exerccio. Se o data center est ardendo em fogo, o SSG no estar entre os primeiros socorristas.
Opere um programa de recompensas para bugs.A organizao solicita relatrios de vulnerabilidades para
pesquisadores externos e paga-lhes uma recompensa para cada vulnerabilidade verificada e aceita. Os pagamentos
tipicamente seguem uma tabela progressiva ligada a mltiplos fatores como tipos de vulnerabilidade (exemplo: execuo
remota de cdigo vale U$ 10.000,00 versus CSRF vale $750), explorao (exploraes demonstrveis comandam
pagamentos muito altos), ou servios e verses de software (largamente implantados ou servios crticos garantem
pagamentos altos). Atividades ad hoc ou de curta durao, como torneio capture-the-flag, no contam. [Esta uma nova
atividade que ser relatada no BSIMM6.]

46

O Esqueleto do BSIMM

esqueleto do BSIMM prov uma forma de visualizar o modelo de maturidade num piscar de olhos e til
durante a avaliao de um programa em segurana de software. O esqueleto inclui uma pgina por prtica,
organizado em trs nveis. Cada atividade associada com um objetivo. Uma descrio mais detalhada das atividades,
exemplos e definies dos termos podem ser encontradas no documento principal.

GOVERNANA: ESTRATGIA E MTRICAS

Planejamento, atribuio de papis e responsabilidades, identificao das metas de segurana de software,
oramentos, identificar mtricas e barreiras.
Objetivo

[SM1.2]
[SM1.3]
[SM1.4]
[SM1.6]
[SM2.1]
[SM2.2]
[SM2.3]
[SM2.5]
[SM3.1]
[SM3.2]

47

torne o plano explcito publique o processo (papis, reponsabilidades, plano), o evolua

quando necessrio.

Nvel
1

construa suporte pela organizao crie o papel de evangelistas e faa propaganda interna
garanta o patrocnio executivo eduque os executivos.
estabelea as barreiras do SSDL (mas no imponha) identifique pontos de barreiras, rena os artefatos necessrios.
torne claro quem est assumindo o risco exija a autorizao da segurana
estimule a transparncia (ou competio) publique dados sobre segurana de software internamente

mude o comportamento imponha barreiras com avaliao e rastreie as excees

crie uma ampla base de suporte crie ou aumente os satlites
defina o sucesso identifique mtricas e use-as para orientar os oramentos
saiba onde esto todas as aplicaes do seu inventrio use rastreamento interno de aplicaes com viso do portflio
crie suporte externo execute um programa de marketing externo

BSIMM-V

[SM1.1]

Atividade

GOVERNANA: CONFORMIDADE E POLTICA

Identifique controles para conformidade, desenvolva controles contratuais (COTS SLA),
estabelea poltica organizacional, audite com base na poltica.
Objetivo
[CP1.1]
[CP1.2]
[CP1.3]

atenda as necessidades regulatrias ou as crie uma poltica

demandas do cliente com uma abordagem unificada
promova a privacidade identifique o inventrio dos dados PII

garanta a responsabilizao para os riscos de software exija a autorizao da segurana para os riscos de conformidade
alinhe as prticas com a conformidade implemente e monitore os controles de conformidade
garanta que os fornecedores no fujam da formalize todos os contratos de fornecedores com SLAs de
conformidade segurana de software

[CP2.4]

ganhe patrocnio executivo promova conscientizao dos executivos sobre as obrigaes de

conformidade e privacidade

[CP2.5]

demonstre a histria da conformidade crie um atrativo regulatrio

gerencie fornecedores terceiros imponha a poltica a fornecedores

[CP3.1]
[CP3.2]
[CP3.3]

Nvel

promova a privacidade identifique as obrigaes PII

[CP2.1]
[CP2.2]
[CP2.3]

Atividade

entenda os condutores de conformidade (FFIEC, unifique as presses regulatrias

GLBA, OCC, PCI, SOX, HIPAA)

mantenha a politica alinhada com a realidade conduza o feedback de dados do SSDL de volta poltica

mantenha a politica alinhada com a realidade conduza o feedback de dados do SSDL de volta poltica
(t: estratgia/mtricas)

2013

48

GOVERNANA: TREINAMENTO
Objetivo

Atividade

promova a cultura da segurana pela organizao fornea treinamento de conscientizao

[T1.1]

Nvel
1

construa capacidades que ultrapassam a sensibilizao distribua um currculo avanado especifico por papis (ferramentas, listas de tecnologias, mostra de bugs)

[T1.5]

se veja no problema crie e use material especfico para a histria da companhia

[T1.6]

reduza o impacto sobre os alvos dos treinamentos e distribua treinamento individual sob demanda
construa equipe de entrega

[T1.7]

eduque/fortalea a rede social fortalea os satlites atravs de treinamentos e eventos

[T2.5]

garanta que as novas contrataes aumentem a traga pessoal de segurana a bordo

cultura

[T2.6]

alinhe a cultura de segurana com o plano de carreira recompense o avano na grade curricular (certificao e RH)
espalhe a cultura de segurana pelos prestadores fornea treinamento para fornecedores e profissionais terceirizados
venda a cultura de segurana como um diferencial hospede eventos externos de segurana
mantenha os colaboradores atualizados e enderece a exija reciclagem anual
rotatividade

[T3.4]

atue como recurso informal para alavancar momentos estabelea um horrio de trabalho para o SSG
de ensino

[T3.5]

49

BSIMM-V

crie rede social amarrada ao desenvolvimento identifique satlites atravs do treinamento

[T2.7]
[T3.1]
[T3.2]
[T3.3]

INTELIGNCIA: MODELOS DE ATAQUE

Modelagem de ameaas, casos de abuso, classificao dos dados, padres de ataque especficos por tecnologia.
Objetivo

Atividade

[AM1.1]

entenda o bsico sobre os ataques elabore e mantenha uma lista de ataques top N

[AM1.2]

priorize as aplicaes pelos dados crie um esquema de classificao e inventrio de dados

consumidos/manipulados

[AM1.3]
[AM1.4]

entenda a histria da organizao colecione e publique histrias de ataques

Nvel
1

entenda o quem dos atacantes identifique potenciais atacantes

esteja atualizado no ambiente de rena inteligncia sobre ataques
ataques/vulnerabilidades

[AM1.5]

comunique a perspectiva do atacante crie um frum interno para discutir ataques (T: padres/requisitos)

[AM1.6]

fornea recursos para os testes de segurana e AA construa padres de ataque e casos de abuso amarrados aos
potenciais atacantes

[AM2.1]

entenda ataques direcionados a tecnologias crie padres de ataque especficos por tecnologia

[AM2.2]
[AM3.1]

esteja frente da curva do ataque mantenha um time de pesquisa que desenvolve novos mtodos de
ataque

[AM3.2]

municie os testadores e auditores crie e use automao para fazer o que os atacantes faro

2013

50

INTELIGNCIA: FUNCIONALIDADES E PROJETO DE SEGURANA

Padres de segurana para os principais controles de segurana, frameworks middleware
para controles, orientao proativa de segurana.
Objetivo

[SFD1.2]

crie orientao proativa de segurana construa e publique funcionalidades de segurana

sobre as funcionalidades de segurana

crie projetos proativos de segurana construa frameworks middleware e bibliotecas seguras desde a concepo
baseado nos tipos de tecnologia (T: reviso de cdigo)

[SFD2.2]

enderece a necessidade por novas crie capacidade no SSG para resolver problemas de projeto complexos
arquiteturas

[SFD3.1]

formalize o consenso nos projetos estabelea um grupo de reviso ou comit central para aprovar e manter
padres de projeto seguros

[SFD3.2]

promova a eficincia dos projetos exija o uso de funcionalidades e frameworks de segurana aprovados (T:AA)

51

injete pensamento de segurana no envolva o SSG com a arquitetura

grupo de arquitetura

[SFD2.1]

[SFD3.3]

Nvel

pratique o reuso encontre e publique padres de projetos maduros da organizao

BSIMM-V

[SFD1.1]

Atividade

INTELIGNCIA: PADRES E REQUISITOS

Explicite os requisitos de segurana, recomendaes COTS, padres para os principais controles
de segurana, padres para as tecnologias em uso, padres para o grupo de reviso.
Objetivo

atenda a demanda por funcionalidade de segurana crie padres de segurana (T: funcionalidades/
projetos de segurana)

[SR1.1]

Nvel
1

garanta que todos sabem onde conseguir o mais recente e melhor crie um portal de segurana

[SR1.2]
[SR1.3]
[SR1.4]
[SR2.2]
[SR2.3]
[SR2.4]

estratgia de conformidade traduza restries de conformidade para requisitos

diga s pessoas o que procurar na reviso de cdigo use padres de cdigo seguro
formalize padres de processos crie um grupo de reviso de padres

reduza a carga de trabalho do SSG crie padres especficos por setores de tecnologia
gerencie o risco do cdigo aberto identifique cdigo aberto
obtenha patrocnio do departamento jurdico e padronize a crie um SLA padronizado (T: conformidade e poltica)
abordagem

[SR2.5]
[SR3.1]
[SR3.2]

Atividade

gerencie o risco do cdigo aberto controle o risco de cdigo aberto

eduque os fornecedores terceiros comunique padres aos fornecedores

2013

52

SSDL TOUCHPOINTS: ANLISE ARQUITETURAL

Captura de diagramas de arquitetura de software, aplicao de listas de riscos e ameaas, adoo
de um processo para reviso, construo de um plano de avaliao e remediao.
Objetivo

[AA1.3]
[AA1.4]
[AA2.1]

demonstre o valor da AA com dados reais Realize reviso de projeto para aplicaes de alto risco

tenha uma abordagem leve para classificao e priorizao use um questionrio de risco para categorizar as
dos riscos aplicaes
objetos modelo defina e use um processo AA
estimule uma linguagem comum para descrio da padronize a descrio de arquitetura (incluindo fluxo
arquitetura de dados)

[AA2.3]

construa capacidade por toda a organizao torne o SSG disponvel como um recurso ou mentor
de AA

[AA3.2]

53

construa capacidade interna em arquitetura de segurana estabelea um esforo de reviso coordenado pelo
SSG

[AA2.2]

[AA3.1]

Nvel

construa capacidades por toda a organizao tenha arquitetos de software liderando esforos de
reviso de projetos
construa arquitetura de segurana proativa canalize os resultados de anlise para os padres de
arquitetura (T: funcionalidades/projetos de segurana)

BSIMM-V

[AA1.1]
[AA1.2]

Atividade
inicie a AA Realize reviso de funcionalidades de segurana

SSDL TOUCHPOINTS: REVISO DE CDIGO

Utilizao de ferramentas de reviso de cdigo, desenvolvimento de regras personalizadas, perfis de utilizao
de ferramentas por diferentes papis, anlise manual, classificao/avaliao dos resultados.
Objetivo
[CR1.1]
[CR1.2]

Atividade
saiba quais os bugs importam para voc crie uma lista de bugstop N (preferencialmente com dados reais)
(T: treinamento)

Nvel
1

revise oportunisticamente aplicaes de alto risco tenha o SSG realizando revises ad hoc

[CR1.4]

conduza eficincia/consistncia com automao use ferramentas automatizadas juntamente com reviso manual

[CR1.5]

encontre bugs mais cedo torne a reviso de cdigo obrigatria para todos os projetos (T:
estratgia/mtricas)
saiba quais os bugs importam utilize relatrios centralizados para fechar o lao do conheci(para os treinamentos) mento e orientar e treinamento

[CR1.6]
[CR2.2]
[CR2.5]
[CR2.6]
[CR3.2]

conduza o comportamento objetivamente imponha padres de cdigo

faa uso mais eficiente das ferramentas atribua mentores de ferramentas

conduza eficincia/reduza falsos positivos use ferramentas automatizadas com regras adaptadas
combine tcnicas de avaliao construa uma fbrica

lide com novas classes de bugs em uma em construa capacidade para erradicar bugs especficos de toda a
uma base de cdigo j verificada base de cdigo

[CR3.3]
[CR3.4]

enderece ameaas internas do desenvolvimento automatize a deteco de cdigo malicioso

2013

54

SSDL TOUCHPOINTS: TESTES DE SEGURANA

Uso de ferramentas de segurana caixa preta no QA, testes caixa branca orientados a risco, aplicao
de um modelo de ataque, anlise de cobertura de cdigo.
Objetivo

[ST1.3]
[ST2.1]
[ST2.4]
[ST3.1]

comece testes de segurana no familiar territrio oriente os testes com requisitos e funcionalidades de
funcional segurana
use a perspectiva do atacante funcional. integre ferramentas de caixa preta de segurana no processo 2
do QA
facilite a mentalidade de segurana compartilhe os resultados de segurana com o QA
inclua testes de segurana na regresso inclua testes de segurana na automao de QA

ensine ferramentas sobre o seu cdigo realize testes fuzz personalizados para as APIs das aplicaes

[ST3.2]
[ST3.3]
[ST3.4]

explore diretamente os apontamentos de riscos oriente os testes pelos resultados de anlise de risco

[ST3.5]

mova alm do teste funcional para a perspectiva do comece a construir e aplicar testes antagnicos de seguatacante rana (casos de abuso)

55

Nvel
1

oriente testes profundos alavanque anlise de cobertura

BSIMM-V

[ST1.1]

Atividade

execute testes antagnicos alm dos funcionais garanta que o QA suporta teste de fronteira e de condio
de valor limite

IMPLANTAO: TESTES DE PENETRAO

Vulnerabilidades na configurao final, alimente a gesto de risco e a mitigao.
Objetivo

Atividade

demonstre o que cdigo da sua organizao use testadores externos para encontrar problemas
precisa de ajuda tambm

[PT1.1]

Nvel
1

corrija o que voc encontrar para demonstrar fornea resultados para gesto e mitigao de defeitos do
progresso real sistema (T: gesto de configurao/vulnerabilidade)

[PT1.2]

crie capacidade interna utilize ferramentas de teste de penetrao internamente

[PT1.3]

promova anlise profunda fornea toda informao disponvel aos testadores

(T:AA & reviso de cdigo)

[PT2.2]

verifique a integridade constantemente. agende testes de penetrao para cobertura da aplicao

[PT2.3]

mantenha-se no topo da perspectiva do atacante use testadores externos para realizar testes profundos

[PT3.1]

automatize por eficincia sem perder faa com que o SSG personalize as ferramentas e scripts
a profundidade para testes de penetrao

[PT3.2]

2013

56

IMPLANTAO: AMBIENTE DE SOFTWARE

Correes de SO e plataforma, firewalls de aplicao web, documentao da instalao e configurao,
monitorao da aplicao, gesto de mudanas, cdigo assinado.
Objetivo

[SE1.2]

observe o software use monitoramento de entradas da aplicao

oriente as necessidades das aplicaes na operao publique guias de instalao

[SE2.4]

proteja aplicativos (ou parte deles) que so utilize cdigo assinado

publicados atravs das fronteiras de confiana

[SE3.2]

proteja o IP e torne difcil o desenvolvimento de use proteo de cdigo

exploraes

57

fornea fundao slida de host/rede para o software garanta que o bsico de segurana de host e de rede
esteja no lugar

[SE2.2]

[SE3.3]

Nvel

observe o software utilize o monitoramento do comportamento e

diagnostico das aplicaes

BSIMM-V

[SE1.1]

Atividade

IMPLANTAO: GESTO DE CONFIGURAO E

GESTO DE VULNERABILIDADE
Correo e atualizao de aplicaes, controle de verso, remediao e rastreamento de defeitos,
tratamento de incidentes.
Objetivo

Atividade

saiba o que fazer quando algo ruim acontecer crie ou interaja com a resposta a incidentes

[CMVM1.1]

Nvel
1

use dados da operao para mudar o comporta- identifique os defeitos de software encontrados na operao e
mento do desenvolvimento realimente o desenvolvimento com eles

[CMVM1.2]

seja capaz de corrigir aplicaes quando estabelea uma resposta de emergncia base de cdigo
elas esto sob ataque direto

[CMVM2.1]
[CMVM2.2]

use dados da operao para mudar o acompanhe o processo de correo das falhas encontradas na
comportamento do desenvolvimento operao do software

[CMVM2.3]

saiba onde o cdigo est desenvolva inventrio de aplicaes em operao

[CMVM3.1]

aprenda pela experincia operacional corrija todas as ocorrncias de bugs de software em operao
(T: reviso de cdigo)

[CMVM3.2]

use dados da operao para mudar o melhore o SSDL para prevenir bugs de software encontrados
comportamento do desenvolvimento na operao

garanta que os processos esto no lugar para simule uma crise de software
minimizar o impacto dos incidentes de software

[CMVM3.3]

contrate pesquisadores externos em descoberta de opere um programa de recompensas para bugs

vulnerabilidades

[CMVM3.4]

2013

58

Classificando as Atividades do BSIMM-V

scolher quais atividades do BSIMM adotar e em qual ordem pode ser um desafio. Ns sugerimos a criao de
uma estratgia e um plano de segurana de software, focando nas metas e objetivos em primeiro lugar e deixe as
atividades se selecionarem por conta prpria. Criando um cronograma para a implementao sempre muito til.
Obviamente, aprender pela experincia tambm uma boa estratgia. Para isso, esta seo dedicada descrio de
um conjunto de atividades principais que ns observamos em pelo menos quarenta e trs das sessenta e sete organizaes que estudamas e ento fornecemos uma tabela com todas as 112 atividades com um resumo dos resultados
que pode ser visto com o peso bruto.

Atividades Principais do BSIMM

Nas 112 atividades observadas no BSIMM-V existem doze atividades onde pelo menos quarenta e trs das sessenta e
sete empresas que estudamos executam (64%), uma identificada em cada prtica. Embora no possamos diretamente
concluir que estas dozes atividades so necessrias para todas as iniciativas de segurana de software, ns podemos
dizer com confiana que estas atividades so comumente encontradas nos programas mais bem sucedidos. Isto sugere
que se voc est trabalhando em uma iniciativa por conta prpria, devem considerar estas doze atividades com um
cuidado especial (para no mencionar as outras 100).

Objetivo
[CP1.2]
[T1.1]
[AM1.2]
[SFD1.1]
[SR1.1]
[AA1.1]

estabelea as barreiras do SSDL (mas no imponha) identifique pontos de barreiras, rena os artefatos necessrios.
promova a privacidade identifique as obrigaes PII
promova a cultura da segurana pela organizao fornea treinamento de conscientizao
priorize as aplicaes pelos dados consumidos/manipulados crie um esquema de classificao e inventrio de dados
crie orientao proativa de segurana sobre construa e publique funcionalidades de segurana
as funcionalidades de segurana
atenda a demanda por funcionalidade de segurana crie padres de segurana
inicie a AA realize reviso de funcionalidades de segurana

[CR1.4]

conduza eficincia/consistncia com automao use ferramentas automatizadas juntamente com reviso
manual

[ST1.3]

comece testes de segurana no familiar territrio oriente os testes com requisitos e funcionalidades de segufuncional rana

[PT1.1]
[SE1.2]
[CMVM1.2]

demonstre o que cdigo da sua organizao use testadores externos para encontrar problemas
precisa de ajuda tambm
fornea fundao slida de host/rede para o software garanta que o bsico de segurana de host e de rede esteja no
lugar
use dados da operao para mudar o identifique os defeitos de software encontrados na operao e
comportamento do desenvolvimento realimente o desenvolvimento com eles

Atividades Observadas nas Sessenta e Sete Empresas

O quadro presente na prxima pgina monta quantas das sessenta e sete empresas que estudamos adotaram vrias
atividades. As doze atividades principais esto realadas em amarelo. Embora voc possa usar este quadro como um peso
bruto das atividades pela prevalncia, a melhor abordagem do plano para a iniciativa de segurana de software pelas
metas e objetivos.

59

BSIMM-V

[SM1.4]

Doze Atividades Principais que Todos Executam

Atividade

Governana
Inteligncia
SSDL Touchpoints
Implantao
Atividade Observado Atividade Observado Atividade Observado Atividade Observado
[SM1.1]

44

[AM1.1]

21

[AA1.1]

56

[PT1.1]

62

[SM1.2]

34

[AM1.2]

43

[AA1.2]

35

[PT1.2]

51

[SM1.3]

34

[AM1.3]

30

[AA1.3]

24

[PT1.3]

43

[SM1.4]

57

[AM1.4]

12

[AA1.4]

42

[PT2.2]

24

[SM1.6]

36

[AM1.5]

42

[AA2.1]

10

[PT2.3]

27

[SM2.1]

26

[AM1.6]

16

[AA2.2]

[PT3.1]

13

[SM2.2]

31

[AM2.1]

[AA2.3]

20

[PT3.2]

[SM2.3]

27

[AM2.2]

11

[AA3.1]

11

[SM2.5]

20

[AM3.1]

[AA3.2]

[SM3.1]

16

[AM3.2]

[SM3.2]

[CP1.1]

43

[SFD1.1]

54

[CR1.1]

24

[SE1.1]

34

[CP1.2]

52

[SFD1.2]

53

[CR1.2]

34

[SE1.2]

61

[CP1.3]

45

[SFD2.1]

26

[CR1.4]

50

[SE2.2]

31

[CP2.1]

24

[SFD2.2]

29

[CR1.5]

23

[SE2.4]

25

[CP2.2]

28

[SFD2.3]

[CR1.6]

25

[SE3.2]

10

[CP2.3]

29

[SFD3.1]

13

[CR2.2]

10

[SE3.3]

[CP2.4]

25

[SFD3.2]

[CR2.5]

15

[CP2.5]

35

[CR3.1]

18

[CP3.1]

14

[CR3.2]

[CP3.2]

11

[CR3.3]

[CP3.3]

[CR3.4]

[ T1.1]

50

48

[ST1.1]

51

[CMVM1.1]

59
59

[SR1.1]

[ T1.5]

29

[SR1.2]

43

[ST1.3]

55

[CMVM1.2]

[ T1.6]

23

[SR1.3]

45

[ST2.1]

27

[CMVM2.1]

50

[ T1.7]

33

[SR1.4]

27

[ST2.3]

13

[CMVM2.2]

44

[ T2.5]

[SR2.1]

23

[ST2.4]

11

[CMVM2.3]

30

[ T2.6]

13

[SR2.2]

19

[ST3.1]

[CMVM3.1]

[ T2.7]

[SR2.3]

19

[ST3.2]

[CMVM3.2]

[ T3.1]

[SR2.4]

22

[ST3.3]

[CMVM3.3]

[ T3.2]

[SR2.5]

[ST3.4]

[ T3.3]

[SR3.1]

12

[ T3.4]

[ T3.5]

2013

60

Apndice: Ajustando o BSIMM4 para o BSIMM-V

ela razo do BSIMM ser um modelo guiado por dados, ns escolhemos fazer ajustes no modelo baseados nos
dados observados entre o BSIMM4 para o BSIMM-V.

A fim de preservar a compatibilidade com os anteriores, todas as mudanas foram feitas adicionado um rtulo novo
para o modelo, mesmo quando uma atividade foi somente movida entre os nveis.
Ns fizemos todas as mudanas considerando-se os valores extremos tanto do modelo, quanto dos nveis que
atribumos para as vrias atividades nas doze prticas. Ns utilizamos os resultados da anlise de desvio padro
intra-nveis para determinar quais as atividades de valor extremo mover entre os nveis. Para fazer isto, ns focamos
nas mudanas que minimizam o desvio padro em um nmero mdio de atividades observadas para cada nvel.
Nossa regra, difcil e rpida, foi para garantir que o nmero mdio de atividades observadas por nvel seguisse uma
progresso lgica de comum para rara (como traado na nossa discusso dos nveis).
Aqui esto s quatro mudanas que fizemos de acordo com este paradigma:
[SFD2.3]

se tornou [SFD3.3] , [SFD2.3] foi removido (promoo de nvel)
[SR2.1]

se tornou [SR3.2] , [SR2.1] foi removido (promoo de nvel)
[ST2.3]

se tornou [ST3.5] , [ST2.3] foi removido (promoo de nvel)
[CR3.1]

se tornou [CR2.6] , [CR3.1] foi removido (promoo de nvel)

Ns cuidadosamente consideramos, mas no ajustamos,

as seguintes atividades:
O scorecard do BSIMM-V resultante pode ser visto na pgina 60.

61

[CP 2.5]

[ T3.3]

[ T3.4]

[AM1.4]

BSIMM-V

1.
2.
3.
4.

2013

62