Segurança aplicada no desenvolvimento de software

Prévia do material em texto

Indaial – 2021
Segurança aplicado 
no deSenvolvimento de 
Software
Prof. Nader Ghoddosi
1a Edição
Copyright © UNIASSELVI 2020
Elaboração:
Prof. Nader Ghoddosi
Revisão, Diagramação e Produção:
Centro Universitário Leonardo da Vinci – UNIASSELVI
Ficha catalográfica elaborada na fonte pela Biblioteca Dante Alighieri 
UNIASSELVI – Indaial.
Impresso por:
G427s
 Ghoddosi, Nader
 Segurança aplicada no desenvolvimento de software. / Nader 
Ghoddosi. – Indaial: UNIASSELVI, 2021.
 220 p.; il.
 ISBN 978-65-5663-419-7
 ISBN Digital 978-65-5663-420-3
 1. Segurança da informação. - Brasil. II. Centro Universitário 
Leonardo da Vinci.
 
CDD 004
apreSentação
Caro acadêmico! Estamos iniciando o estudo da disciplina Segurança 
Aplicada no Desenvolvimento do Software. Este livro é um dos instrumentos 
que contribuirá para a sua aprendizagem. A abordagem do livro é sobre a 
importância da segurança ao longo do desenvolvimento do software. Para 
isso, serão apresentados os principais conceitos de segurança da informação 
que interferem diretamente sobre o processo de desenvolvimento. 
 
Durante o desenvolvimento de um software, os desenvolvedores 
buscam garantir a entrega de um produto minimizando as falhas e 
vulnerabilidades, porém, durante o desenvolvimento, não são raros os casos 
que os profissionais ignoram as boas práticas de segurança. Desse modo, 
é essencial que certas rotinas sejam tomadas ao longo de processo, ainda 
que os modelos tradicionais de criação de softwares não sejam focados 
no desenvolvimento do software seguro. Para isso, este livro abordará 
essa importância da segurança como uma vantagem competitiva para as 
organizações. 
Na Unidade 1, nós abordaremos os principais conceitos de segurança 
no desenvolvimento do software e as normas de segurança mais usuais que 
auxiliam o processo de desenvolvimento seguro. 
Na Unidade 2 serão elencados os principais passos para o 
desenvolvimento seguro considerando as aplicações WEB. Além disso, você 
estudará como fazer uma análise de vulnerabilidade e garantir a segurança 
dos arquivos do sistema. 
Na Unidade 3, nós abordaremos questões vinculadas à auditoria do 
desenvolvimento de sistemas, bem como a avaliação do software. Para isso, 
você irá compreender a relação entre o treinamento da equipe e a garantia da 
segurança no processo de desenvolvimento seguro. 
Aproveitamos a oportunidade para destacar a importância de 
desenvolver as autoatividades, lembrando que essas atividades não são 
opcionais. Elas objetivam a fixação dos conceitos apresentados. Em caso 
de dúvida, durante a realização das atividades, sugerimos que você entre 
em contato com seu tutor externo ou com a tutoria da UNIASSELVI, não 
prosseguindo as atividades sem ter sanado todas as dúvidas que irão 
surgindo. 
Bons estudos!
Nader Ghoddosi
Você já me conhece das outras disciplinas? Não? É calouro? Enfim, tanto para 
você que está chegando agora à UNIASSELVI quanto para você que já é veterano, há novi-
dades em nosso material.
Na Educação a Distância, o livro impresso, entregue a todos os acadêmicos desde 2005, é 
o material base da disciplina. A partir de 2017, nossos livros estão de visual novo, com um 
formato mais prático, que cabe na bolsa e facilita a leitura. 
O conteúdo continua na íntegra, mas a estrutura interna foi aperfeiçoada com nova diagra-
mação no texto, aproveitando ao máximo o espaço da página, o que também contribui 
para diminuir a extração de árvores para produção de folhas de papel, por exemplo.
Assim, a UNIASSELVI, preocupando-se com o impacto de nossas ações sobre o ambiente, 
apresenta também este livro no formato digital. Assim, você, acadêmico, tem a possibilida-
de de estudá-lo com versatilidade nas telas do celular, tablet ou computador. 
 
Eu mesmo, UNI, ganhei um novo layout, você me verá frequentemente e surgirei para 
apresentar dicas de vídeos e outras fontes de conhecimento que complementam o assun-
to em questão. 
Todos esses ajustes foram pensados a partir de relatos que recebemos nas pesquisas 
institucionais sobre os materiais impressos, para que você, nossa maior prioridade, possa 
continuar seus estudos com um material de qualidade.
Aproveito o momento para convidá-lo para um bate-papo sobre o Exame Nacional de 
Desempenho de Estudantes – ENADE. 
 
Bons estudos!
NOTA
Olá, acadêmico! Iniciamos agora mais uma disciplina e com ela 
um novo conhecimento. 
Com o objetivo de enriquecer seu conhecimento, construímos, além do livro 
que está em suas mãos, uma rica trilha de aprendizagem, por meio dela você 
terá contato com o vídeo da disciplina, o objeto de aprendizagem, materiais complemen-
tares, entre outros, todos pensados e construídos na intenção de auxiliar seu crescimento.
Acesse o QR Code, que levará ao AVA, e veja as novidades que preparamos para seu estudo.
Conte conosco, estaremos juntos nesta caminhada!
LEMBRETE
Sumário
UNIDADE 1 — DESENVOLVIMENTO DE SOFTWARE SEGURO ............................................ 1
TÓPICO 1 — DESENVOLVIMENTO DE SOFTWARE .................................................................. 3
1 INTRODUÇÃO .................................................................................................................................... 3
2 SOFTWARE ........................................................................................................................................... 4
3 MODELOS DE PROCESSO DE SOFTWARE ............................................................................... 5
4 PROCESSO DE DESENVOLVIMENTO DE SOFTWARE .......................................................... 6
5 CICLO DE VIDA DE DESENVOLVIMENTO DE SOFTWARE SEGURO .............................. 9
6 ANÁLISE ESTÁTICA DE CÓDIGO ............................................................................................. 13
7 O PROBLEMA DA SEGURANÇA NO SOFTWARE .................................................................. 14
8 BENEFÍCIOS DO DESENVOLVIMENTO SEGURO ................................................................ 15
RESUMO DO TÓPICO 1..................................................................................................................... 19
AUTOATIVIDADE .............................................................................................................................. 21
TÓPICO 2 — SEGURANÇA DE DADOS ....................................................................................... 23
1 INTRODUÇÃO .................................................................................................................................. 23
2 CONCEITOS DA SEGURANÇA DA INFORMAÇÃO ............................................................. 23
3 PRINCÍPIOS DO SOFTWARE SEGURO ..................................................................................... 27
4 SETE PONTOS DE SEGURANÇA DO SOFTWARE SEGURO ............................................... 28
5 REQUISITOS DE SEGURANÇA DE SOFTWARE .................................................................... 29
6 FERRAMENTAS E TÉCNICAS DE AVALIAÇÃO DOS RISCOS ........................................... 30
6.1 CATEGORIZAÇÃO DE RISCOS ................................................................................................ 31
6.2 GERENCIAMENTO DE RISCOS EM PROJETOS ................................................................... 32
6.3 MATRIZ DE RISCO ...................................................................................................................... 34
7 PADRÕES DE SEGURANÇA.......................................................................................................... 36
RESUMO DO TÓPICO 2..................................................................................................................... 40
AUTOATIVIDADE .............................................................................................................................. 42
TÓPICO 3 — NORMASE MODELOS DE SEGURANÇA .......................................................... 45
1 INTRODUÇÃO ................................................................................................................................. 45
2 MODELO SSE-CMM ....................................................................................................................... 45
3 NORMA ISO/IEC 17799 E ISO/IEC 27001 .................................................................................... 47
3.1 ISO/IEC 27001:2018 ....................................................................................................................... 47
4 ISO/IEC 15408 .................................................................................................................................... 52
LEITURA COMPLEMENTAR ............................................................................................................ 54
RESUMO DO TÓPICO 3..................................................................................................................... 60
AUTOATIVIDADE .............................................................................................................................. 62
REFERÊNCIAS ...................................................................................................................................... 64
UNIDADE 2 — SEGURANÇA NO DESENVOLVIMENTO DE APLICAÇÕES WEB ................ 67
TÓPICO 1 — PRIMEIROS PASSOS PARA O DESENVOLVIMENTO
 SEGURO DE APLICAÇÕES WEB ........................................................................... 69
1 INTRODUÇÃO ................................................................................................................................. 69
2 FALHAS DURANTE O DESENVOLVIMENTO DO PROJETO ............................................. 70
3 TAXONOMIA DE ATAQUES WEB .............................................................................................. 75
4 TESTES DE SEGURANÇA NAS APLICAÇÕES ESSENCIAIS .............................................. 79
5 CUIDADOS A SEREM TOMADOS NA IMPLANTAÇÃO ..................................................... 82
6 MANUTENÇÃO DO PROJETO .................................................................................................... 87
6.1 DOCUMENTAÇÃO .................................................................................................................... 89
6.2 ARTEFATOS ................................................................................................................................. 91
RESUMO DO TÓPICO 1..................................................................................................................... 94
AUTOATIVIDADE .............................................................................................................................. 96
TÓPICO 2 — ANÁLISE DE VULNERABILIDADE ....................................................................... 99
1 INTRODUÇÃO .................................................................................................................................. 99
2 A SEGURANÇA DE APLICAÇÕES NA GESTÃO DA
 SEGURANÇA DA INFORMAÇÃO ............................................................................................... 99
3 REPOSITÓRIOS E PADRÕES ..................................................................................................... 104
4 CLASSIFICAÇÃO DAS TÉCNICAS DE VARREDURAS DE VULNERABILIDADE ..... 107
5 PROCESSO DE ANÁLISE DE VULNERABILIDADE ............................................................ 109
6 PROCEDIMENTOS PARA A GESTÃO DE VULNERABILIDADE...................................... 112
7 TESTE DE PENETRAÇÃO ............................................................................................................ 113
RESUMO DO TÓPICO 2................................................................................................................... 118
AUTOATIVIDADE ............................................................................................................................ 120
TÓPICO 3 — SEGURANÇA DOS ARQUIVOS DO SISTEMA ................................................ 123
1 INTRODUÇÃO ................................................................................................................................ 123
2 CONTROLE DE ACESSO AO CÓDIGO-FONTE DO PROGRAMA ................................... 123
2.1 CODIFICAÇÃO SEGURA ......................................................................................................... 125
2.2 CODIFICAÇÃO SEGURA NO CERT ...................................................................................... 128
2.3 CODIFICAÇÃO SEGURA NO PROJETO ABERTO DE SEGURANÇA EM APLICAÇÕES 
WEB (OWASP) ............................................................................................................................. 128
2.4 CODIFICAÇÃO SEGURA NA MICROSOFT ......................................................................... 130
2.5 PRINCÍPIOS DA ARQUITETURA SEGURA ........................................................................ 131
LEITURA COMPLEMENTAR .......................................................................................................... 133
RESUMO DO TÓPICO 3................................................................................................................... 141
AUTOATIVIDADE ............................................................................................................................ 143
REFERÊNCIAS .................................................................................................................................... 145
UNIDADE 3 — SEGURANÇA E AUDITORIA NO DESENVOLVIMENTO
 DO SOFTWARE ..................................................................................................... 152
TÓPICO 1 — AUDITORIA DO DESENVOLVIMENTO DE SISTEMAS .............................. 154
1 INTRODUÇÃO ................................................................................................................................ 154
2 CONCEITOS DE SISTEMAS ........................................................................................................ 154
3 CONCEITOS DE AUDITORIA DE SISTEMAS ....................................................................... 157
4 ABORDAGEM DE AUDITORIA DE SISTEMAS ................................................................... 160
4.1 ABORDAGEM AO REDOR DO COMPUTADOR ................................................................. 163
4.2 ABORDAGEM ATRAVÉS DO COMPUTADOR .................................................................... 164
4.3 ABORDAGEM COM O COMPUTADOR ............................................................................... 164
5 ATIVIDADES DO MÉTODO DE AUDITORIA PARA DESENVOLVIMENTO DE 
SOFTWARE ......................................................................................................................................... 165
RESUMO DO TÓPICO 1................................................................................................................... 170
AUTOATIVIDADE ............................................................................................................................ 172
TÓPICO 2 — AVALIAÇÃO DO SOFTWARE DE AUDITORIA DE SISTEMAS .................. 176
1 INTRODUÇÃO ................................................................................................................................ 176
2 METODOLOGIAS DE SELEÇÃO .............................................................................................. 176
2.1 COBIT .......................................................................................................................................... 177
2.2 CMMI ............................................................................................................................................ 181
2.3 MELHORIA DO PROCESSO DOSOFTWARE BRASILEIRO (MPS.BR) .......................... 184
2.4 ISO/IEC 12207 .............................................................................................................................. 187
3 ASPECTOS FUNCIONAIS ............................................................................................................ 188
4 ASPECTOS DA GESTÃO .............................................................................................................. 189
5 ASPECTOS RELACIONADOS À TECNOLOGIA ................................................................... 190
RESUMO DO TÓPICO 2................................................................................................................... 193
AUTOATIVIDADE ............................................................................................................................ 195
TÓPICO 3 — TREINAMENTO DE SEGURANÇA ..................................................................... 198
1 INTRODUÇÃO ................................................................................................................................ 198
2 IMPACTOS ...................................................................................................................................... 198
3 ORGANIZAÇÃO DO TRABALHO DE AUDITORIA ............................................................ 203
3.1 PLANEJAMENTO ...................................................................................................................... 204
3.2 ESCOLHA DA EQUIPE ............................................................................................................. 204
3.3 PROGRAMAÇÃO DA EQUIPE ............................................................................................... 205
3.3.1 Papéis e responsabilidades ............................................................................................... 207
3.4 EXECUÇÃO DE TRABALHOS E SUPERVISÃO ................................................................... 207
3.5 REVISÃO DOS PAPÉIS DE TRABALHOS ............................................................................. 208
3.6 ATUALIZAÇÃO DO CONHECIMENTO PERMANENTE ................................................. 208
3.7 AVALIAÇÃO DA EQUIPE ........................................................................................................ 209
3.8 DOCUMENTAÇÃO DOS PAPÉIS DE TRABALHO ............................................................. 209
4 CONTROLES ORGANIZACIONAIS E OPERACIONAIS..................................................... 209
5 O PAPEL DO USUÁRIO ............................................................................................................... 210
LEITURA COMPLEMENTAR .......................................................................................................... 212
RESUMO DO TÓPICO 3................................................................................................................... 215
AUTOATIVIDADE ............................................................................................................................ 217
REFERÊNCIAS .................................................................................................................................... 219
1
UNIDADE 1 — 
DESENVOLVIMENTO DE SOFTWARE 
SEGURO
OBJETIVOS DE APRENDIZAGEM
PLANO DE ESTUDOS
 A partir do estudo desta unidade, você deverá ser capaz de:
• conhecer o ciclo de desenvolvimento do software seguro; 
• compreender os principais conceitos de segurança dos softwares; 
• conhecer as principais normas de segurança; 
• reconhecer as categorias de risco no desenvolvimento do software;
• relacionar segurança com processo de desenvolvimento do software.
 Esta unidade está dividida em três tópicos. No decorrer da unidade, 
você encontrará autoatividades com o objetivo de reforçar o conteúdo 
apresentado.
TÓPICO 1 – DESENVOLVIMENTO DE SOFTWARE
TÓPICO 2 – SEGURANÇA DE DADOS
TÓPICO 3 – NORMAS E MODELOS DE SEGURANÇA
Preparado para ampliar seus conhecimentos? Respire e vamos 
em frente! Procure um ambiente que facilite a concentração, assim absorverá 
melhor as informações.
CHAMADA
2
3
TÓPICO 1 — UNIDADE 1
DESENVOLVIMENTO DE SOFTWARE
1 INTRODUÇÃO
O processo de desenvolvimento de software é algo complexo e, para 
isso, é preciso um conjunto de atividades organizadas e sequências estruturadas 
em passos definidos (SÊMOLA, 2003; ALVES, 2006; FONTES, 2006; 2011). Esse 
conjunto de atividades é definido como um processo de desenvolvimento de 
software, que recebe ajuda da engenharia de software (ALVES, 2006; FONTES, 
2011). 
Uma das etapas que causa grande preocupação nesse processo é a falta 
de segurança nos projetos de desenvolvimento, o que gera vulnerabilidades 
(FERREIRA, 2003; SÊMOLA, 2003; ALVES, 2006). Em função disso, as 
organizações estão em uma busca contínua para adotar medidas mais eficazes 
de proteção alinhadas às metodologias de segurança (FONTES, 2006; WAGNER, 
2011; FERNANDES, 2013; GALITEZI, 2011). 
Essas metodologias são necessárias, já que Kolbe Junior (2020) relata que, 
em 2019, ocorreram 85 bilhões de tentativas de ataques cibernéticos, sendo que, no 
Brasil, ocorreram mais de 24 bilhões de tentativas de ataques. Isso denota a grande 
importância de as empresas adotarem protocolos de segurança para mitigar as 
suas vulnerabilidades durante o processo de desenvolvimento de software. No 
período de Corona Vírus (Covid-19), aumentaram, de modo significativo, os 
ataques de hackers contra empresas, já que as ferramentas que adotam o acesso 
remoto aumentaram 333% no Brasil (KOLBE, 2020). O número de brasileiros 
prejudicados por crimes virtuais é maior do que a média mundial, assim, isso 
coloca o Brasil entre os mais prejudicados por esse tipo de crime (WALTRICK, 
2016).
Em casos recentes, como da maior fabricante de produtos militares do 
mundo, a Lockheed Martin, teve sua rede invadida por hackers que tinham, como alvo, os 
trabalhadores remotos (WALTRICK, 2016).
NOTA
https://www.cliccamaqua.com.br/noticias/2/policia.html
UNIDADE 1 — DESENVOLVIMENTO DE SOFTWARE SEGURO
4
FIGURA 1 – PREJUÍZO FINANCEIRO CAUSADO PELOS CRIMES VIRTUAIS
FONTE: <http://bit.ly/2WrncLp>. Acesso em: 15 maio 2020.
Desse modo, podemos observar que existe a necessidade de produtos de 
software que, além suportarem os negócios, apresentem melhorias de segurança 
contínua. Neste tópico, entenderemos o processo de desenvolvimento e as suas 
características para permitir a segurança do software. 
2 SOFTWARE
Para iniciar este subtópico, vamos definir o que é software? Conforme 
Pressman e Maxim (2016), o software de computador é um produto que os 
desenvolvedores constroem e o mantêm ao longo do tempo. Sommerville (2011) 
coloca que software não é somente o programa, mas toda a documentação 
associada, além dos dados necessários para executar os programas de modo 
adequado. 
Entretanto, um grande ponto a ser considerado na segurança do 
desenvolvimento de software e que está relacionado com a sua definição é o fato 
de que um determinado software pode ser composto por algumas dezenas de 
linhas de código desenvolvidas por um programador ou pode ser constituído 
TÓPICO 1 — DESENVOLVIMENTO DE SOFTWARE
5
por milhões de linhas de código, dados de configuração, documentação etc. 
(FONTES, 2006; 2011). Portanto, para que o software tenha qualidade e segurança, 
é essencial seja desenvolvido por meio de um processo adequado.
3 MODELOS DE PROCESSO DE SOFTWARE 
O processo de software desenvolvido em uma organização é, geralmente, 
formulado através de padrões previamente descritos, sendo que estes definem 
um conjunto de ações e atividades, necessárias ao desenvolvimento do software 
(FONTES, 2006; SOMMERVILLE, 2011; PRESSMAN; MAXIM, 2016). Portanto, 
um modelo de processo de software pode ser compreendido como um roteiro 
a ser seguido para desenvolver um software de alta qualidade em um tempo 
determinado (PRESSMAN; MAXIM, 2016). Esse modelode processo pode 
ser considerado uma representação abstrata de um processo de software 
(SOMMERVILLE, 2011). Existem inúmeros modelos de processo de software que 
você pode revisar no Livro Didático de Engenharia de Software. 
Os modelos prescritivos prescrevem um conjunto de elementos e 
o modo como esses elementos se inter-relacionam (SOMMERVILLE, 2011; 
PRESSMAN; MAXIM, 2016). Temos um conjunto de quatro modelos prescritivos 
(SOMMERVILLE, 2011; PRESSMAN; MAXIM, 2016): 
• Modelo cascata: atividades de especificação, desenvolvimento, validação 
e evolução, que são fundamentais ao processo, como fases separadas do 
processo, como a especificação de requisitos, o projeto de software, os testes, 
e assim por diante.
• Modelo incremental: combina elementos dos fluxos de processos lineares e 
paralelos. Desse modo, cada uma das sequências lineares gera um incremento 
do software. Esses incrementos são entregáveis e prontos para o cliente, 
portanto, o modelo de processo incremental entrega um produto operacional 
a cada incremento, isso significa um produto sem erros e pronto para o 
usuário usar.
• Modelo evolucionário: caracterizado por ser iterativo e ter características que 
possibilitem o desenvolvimento de versões mais completas do software. O 
software evolui com o tempo e de acordo com as mudanças nas necessidades 
de negócio e de produtos que se modificam frequentemente. Os modelos 
evolucionários se caracterizam por dois modelos comuns: prototipação e 
espiral. A prototipação é usada quando o desenvolvedor não tem certeza 
quanto à eficiência de um algoritmo, ou quanto à adaptabilidade de um 
sistema operacional. Já o modelo espiral garante um grande potencial para 
um desenvolvimento rápido de versões mais completas.
• Modelo baseado em componentes: tem, como base, a existência de um número 
significativo de componentes reutilizáveis. O processo de desenvolvimento 
de software se concentra na integração desses componentes, ao contrário de 
proceder ao desenvolvimento a partir do zero.
UNIDADE 1 — DESENVOLVIMENTO DE SOFTWARE SEGURO
6
4 PROCESSO DE DESENVOLVIMENTO DE SOFTWARE
Os softwares são responsáveis pela geração de informações, por isso, 
a segurança do software está atrelada à segurança da informação (SÊMOLA, 
2003; WAGNER, 2011; FERNANDES, 2013; GALITEZI, 2011). Conforme Sêmola 
(2003) e Fontes (2011), a segurança da informação é definida como um conjunto 
de orientações, normas, procedimentos, políticas ou outras ações que protejam o 
recurso à informação.
Outro ponto importante levantado por Fontes (2011) e Fernandes (2013) 
é que o processo de software é definido como um conjunto de atividades e 
resultados que origina um produto. As atividades fundamentais e similares 
a todos os processos de desenvolvimento de software são: especificação, 
desenvolvimento, validação e evolução (FONTES, 2011; SOMMERVILLE, 2011; 
PRESSMAN; MAXIM, 2016). 
No mercado competitivo atual, o processo bem definido e organizado das 
atividades essenciais para o desenvolvimento de um software é uma vantagem 
cada vez maior (GALITEZI, 2011; KOLBE, 2020). Uma empresa que trabalha com 
controle no desenvolvimento, testes, integração de sistemas e, ainda, possui uma 
equipe capacitada para garantir projetos adequados às necessidades dos clientes, 
possui mais chances de sucesso nesse mercado competitivo (KOLBE, 2020).
FIGURA 2 – PROCESSOS DE DESENVOLVIMENTO DE SOFTWARE
FONTE: <https://www.softvision.com.br/software.html>. Acesso em: 18 maio 2020.
https://www.softvision.com.br/software.html
TÓPICO 1 — DESENVOLVIMENTO DE SOFTWARE
7
As atividades listadas são organizadas em diferentes processos, com 
níveis diferenciados de detalhamento e, ainda, com prazos diversificados 
(FONTES, 2011; LYRA, 2008). Portanto, o desenvolvimento de um produto pode 
ocorrer por processos distintos, mesmo que esse seja um produto similar ou igual, 
porém, se um processo inadequado for usado, isso gerará o comprometimento 
da qualidade do produto final, que está em desenvolvimento (SÊMOLA, 2003; 
FONTES, 2011). Então, agora, entenderemos melhor as fases dos processos para 
o desenvolvimento seguro de um software.
QUADRO 1 – FASES E ATIVIDADES COMUNS NOS MODELOS DE DESENVOLVIMENTO DE 
SOFTWARES
FONTE: Adaptado de Fontes (2006)
Analisando a descrição das fases, percebemos que as atividades de 
desenvolvimento de um processo de software são afetadas por ações específicas 
para um único objetivo comum, que é o produto de software. Conforme Li e Cui 
(2010) e Fernandes (2013), existe uma combinação de classificações realizadas por 
autores, tendo, em comum, uma lista com as principais atividades de cada fase. 
FASES DESCRIÇÃO
Especificação de 
requisitos
Engloba uma análise dos requisitos, independentemen-
te do modelo de processos selecionado para se desen-
volver um software. Nesta etapa, é necessário conhecer 
quais serão as necessidades e restrições do software.
Projeto de sistema Esta fase abrange o projeto a partir de análises e tradu-ção dos requisitos. Com isso, ocorre a codificação.
Programação 
Desenvolvimento do código-fonte em uma linguagem 
de programação. Isso representa o controle do sistema, 
a lógica e as operações, conforme o que foi descrito e 
levantado na fase de especificação de requisitos.
Verificação e 
validação
Nesta etapa, são efetuados os testes, a verificação do 
sistema checando se o produto ou seus componentes 
estão de acordo com as necessidades do cliente. Ainda, 
é averiguada a satisfação dos clientes com o software, 
visando à qualidade do produto final.
Manutenção e 
evolução
Nesta etapa, ocorrem as mudanças, ajustes, reparos ou 
melhorias que os requisitos venham sofrer após o siste-
ma ser colocado em desenvolvimento.
UNIDADE 1 — DESENVOLVIMENTO DE SOFTWARE SEGURO
8
QUADRO 2 – PROCESSO DE DESENVOLVIMENTO DE SOFTWARE
FONTE: Adaptado de Fernandes (2013)
O produto final, portanto, está atrelado às atividades de cada fase do 
processo de desenvolvimento, que são especificadas, detalhadas e, ainda, são 
colocadas em uma ordem (FONTES, 2011; FERNANDES, 2013). Esses processos 
auxiliam e orientam modelos diferentes de desenvolvimento de softwares. 
Um dos pontos críticos ligados no processo de desenvolvimento é a 
segurança, além da proteção das informações confidenciais (FERREIRA, 2003). 
Isso porque, atualmente, os clientes consideram as práticas de segurança e 
privacidade como um ponto crucial na decisão de escolher um fornecedor de 
serviços. Assim, a segurança cria novas oportunidades de negócio. De acordo 
ESPECIFICAÇÃO
Engenharia de 
sistema
Estabelecer uma solução comum para 
o problema, envolvendo questões extra 
software.
Análise de 
requisitos
Realizar o levantamento das necessida-
des do software a ser implementado. 
Nesta etapa, o objetivo é desenvolver 
uma especificação de requisitos, que, 
geralmente, é um documento.
Especificação 
de sistema
Uma descrição funcional do sistema, 
podendo incluir um plano de testes 
para verificar a adequação.
PROJETO
Projeto 
arquitetural
Desenvolvimento de um modelo 
conceitual para o sistema, composto de 
módulos mais ou menos independentes.
Projeto de 
interface
Cada módulo possui sua interface de 
comunicação alinhada, definida e com-
preendida. 
Projeto 
detalhado
Definição dos módulos, e tradução 
para pseudocódigo.
IMPLEMENTA-
ÇÃO Codificação
Implementação do sistema em uma lin-
guagem de computador.
VALIDAÇÃO
Teste de 
unidade e 
módulo
Realização de testes para verificação 
dos erros e comportamento adequado 
a nível das funções e módulos básicos 
do sistema.
Integração
Junção dos diferentes módulos em um 
produto de software homogêneo, além 
da verificação da interação entre estes 
quando operando em conjunto.
MANUTENÇÃO 
E EVOLUÇÃO
O software entra em um ciclo interativo que engloba 
todas as fases anteriores.
TÓPICO 1 — DESENVOLVIMENTO DE SOFTWARE
9
com Kolbe (2020), a segurança do software está ligada à resistência e tolerância a 
eventos que ameacem a integridade. Consequentemente,a segurança do software 
corresponde à habilidade do software de evitar, além de suportar eventos que 
ameacem a dependabilidade (WALTRICK, 2016; KOLBE, 2020). Conforme Fontes 
(2006), a segurança do software é o seu desenvolvimento seguro, isso significa 
certificar a sua segurança e capacitar os desenvolvedores, arquitetos e os usuários 
acerca do desenvolvimento de produtos seguros.
5 CICLO DE VIDA DE DESENVOLVIMENTO DE SOFTWARE 
SEGURO
O ciclo de vida de desenvolvimento seguro é essencial para que a 
organização proteja suas informações, mas também as informações dos clientes 
e parceiros (SILVA, 2017). Um ciclo implementado de modo adequado pode 
garantir mais confiabilidade e redução de custos, portanto, o que se percebe é 
que é necessário desenvolver aplicações seguras, visto que os ataques evoluíram 
de modo significativo, além das suas motivações.
QUADRO 3 – MUDANÇAS DAS MOTIVAÇÕES DOS ATAQUES
FONTE: Adaptado de Silva (2017)
Conforme a regra de Myers (2004), o custo de manutenção de uma 
aplicação pode ser até 10 vezes maior a cada ciclo de vida de desenvolvimento. 
Dependabilidade é a propriedade que define a capacidade dos sistemas 
computacionais de prestarem um serviço que se pode justificadamente confiar. Dentre 
os atributos, estão: confiabilidade, segurança, disponibilidade e mantenabilidade (FONTES, 
2011).
NOTA
Passado Presente e futuro
Motivados pelo desafio de in-
vadir os sistemas.
Demonstração de conhecimen-
to técnico.
Ataques focados nas empresas.
Motivação financeira.
Ataques direcionados.
Sequestro de dados pessoais e corporativos.
Ataque a pessoas.
Comprometimento de dispositivos.
Comprometimento de pequenas empresas 
para atacarem grandes empresas.
UNIDADE 1 — DESENVOLVIMENTO DE SOFTWARE SEGURO
10
Essa regra denota o custo da correção de um defeito, o que pode gerar um aumento 
devido à demora da descoberta do defeito (MYERS, 2004). O que se verifica é que 
os defeitos visualizados nas fases iniciais apresentam um menor custo do que 
aqueles encontrados na fase de produção.
FIGURA 3 – REGRA DE MYERS
FONTE: <http://bit.ly/3nwbqeo>. Acesso em: 20 maio 2020.
O desenvolvimento seguro não é somente a codificação, engloba a 
infraestrutura para suportar o ambiente da aplicação. Desse modo, é preciso 
investir na proteção de todo o ambiente (HOWARD; LIPNER, 2006). Agora, 
compreenderemos um processo de ciclo de vida de desenvolvimento seguro 
muito utilizado que possui, como base, o Security Development Lifecycle (SDL – 
Ciclo de Vida do Desenvolvimento Seguro). 
O SDL se concentra no desenvolvimento de software introduzindo a 
segurança e a privacidade em todas as fases do desenvolvimento. O SDL concilia 
uma abordagem global com a prática de minimização do número e do grau de 
severidade das vulnerabilidades nos produtos e serviços da Microsoft (HOWARD; 
LIPNER, 2006; SILVA, 2017).
O SDL é compartilhado de modo gratuito pela Microsoft com organizações 
de desenvolvimento de clientes e do setor de software, tendo, como resultado, o 
desenvolvimento de softwares mais seguros (HOWARD; LIPNER, 2006; SILVA, 
2017).
TÓPICO 1 — DESENVOLVIMENTO DE SOFTWARE
11
QUADRO 4 – DESCRIÇÃO DAS FASES DO PROCESSO SDL
Pré-SDL – 
Treinamento
- Fase fundamental para um processo de desenvolvimento 
seguro de sucesso. 
- Conteúdo direcionado de acordo com o público-alvo. 
- Etapa recorrente e ter o mínimo de colaboradores treinados.
Fase 1 – 
Requisitos
- Identificação de segurança necessária, requisitos mínimos 
de qualquer aplicação. 
- Levantar legislação vigente, políticas internas e externas.
- Privacidade.
- Segurança dos dados. 
- Aprofundamento na avaliação dos riscos de segurança e 
da privacidade.
- Definir os especialistas para o desenvolvimento e de 
segurança da informação.
- Definir quality gates quando avança a próxima etapa, isso 
deve contemplar falhas de segurança.
Fase 2 – Design
- Arquitetar a aplicação com base nos requisitos.
- Classificar o tipo de dado, isso se torna um baseline para 
os próximos projetos.
- Uso e verificação de criptografia para proteger informações 
sensíveis. 
- Definir o algoritmo que será usado.
- Reduzir a superfície de ataque, utilizando proteção em 
camadas, Web Application Firewall, utilização de DMZ, 
banco de dados não exposto para internet etc.
- Atuar com o princípio de menor privilégio.
- Checklist para não esquecer de algum ponto.
Fase 3 – 
Implementação
- Etapa da codificação.
- Banir o uso de APIs inseguras e funções frágeis e realizar a 
devida documentação para que todos tenham conhecimento.
- Ferramenta de análise estática realizada pelo próprio 
desenvolver.
- Realizar revisão de código com apoio de ferramentas.
- Realizar teste não estruturado possibilita identificar 
comportamento anômalo.
- Realizar revisão de código manual para identificar se há 
falso positivo e se possível outro desenvolvedor realizar 
essa análise manual.
- Escrever um código limpo para que a manutenção possa 
ser realizada por outro time.
UNIDADE 1 — DESENVOLVIMENTO DE SOFTWARE SEGURO
12
Fase 4 – 
Verificação
- Fase do teste da aplicação, usando métodos para validar se 
a aplicação está operando conforme o esperado.
- Análise dinâmica, verifica a aplicação, possibilita verificar 
alguns problemas de segurança, comportamento do 
ambiente que suporta a aplicação.
- Revisão dos controles implementados para os riscos 
identificados na análise de ameaça.
- Realizar teste de penetração, com profissionais 
especializados, podendo ser internos ou terceiros.
Fase 5 – Release - Requisitos de privacidade.
- Requisitos de segurança da informação.
Pós-SDL – 
Resposta 
- Prática do plano de resposta a incidentes.
- Documentação e atualização são imprescindíveis para o 
sucesso do processo.
FONTE: Adaptado de Silva (2017)
 
A ciência da segurança é a ciência interna do SDL, desenvolvida para 
compreender como os sistemas de computador são invadidos, e, ainda, como 
esses ataques poderiam ser minimizados ou evitados. Desse modo, a ciência da 
segurança elabora e desenvolve técnicas e ferramentas inovadoras que auxiliam a 
dificultar os ataques a softwares (HOWARD; LIPNER, 2006). O SDL é mais eficaz 
devido à ciência da segurança em função de: 
• Auxiliar na localização das vulnerabilidades do software.
• Desenvolver ferramentas e técnicas de mitigação de explorações que serão 
adotadas pelos desenvolvedores.
• Monitorar as tendências de modo contínuo.
• Aperfeiçoar as ferramentas e os processos através dos monitoramentos das 
ameaças.
O monitoramento contínuo é primordial, já que, quando uma nova 
ameaça entra no ecossistema, são ativados os processos de resposta de segurança 
da Microsoft. A Microsoft utiliza o SDL para incluir práticas de segurança 
comprovadas no desenvolvimento de software. O grande ponto a ser considerado 
é que as ameaças aos softwares não são estáticas e, por isso, o SDL sofre um processo 
de aperfeiçoamento ao longo dos anos (HOWARD; LIPNER, 2006). Isso possibilita 
um refinamento e melhoramento da tecnologia, ainda, um compartilhamento, de 
modo agressivo, das práticas recomendadas com desenvolvedores de software 
de terceiros para o auxílio de uma prática em computação segura para todos.
TÓPICO 1 — DESENVOLVIMENTO DE SOFTWARE
13
FIGURA 4 – LINHA DO TEMPO DE APERFEIÇOAMENTO DO PROCESSO SDL
FONTE: O autor
6 ANÁLISE ESTÁTICA DE CÓDIGO 
A análise estática de código é umas das técnicas estáticas de inspeção 
de software no processo de verificação e validação (V&V), sendo uma análise 
automatizada seguida de uma análise profissional dos resultados obtidos 
(ALVES, 2006; LI; BAOJIANG, 2010). A verificação ocorre antes que o software 
seja executado. 
Os verificadores estáticos são considerados ferramentas importantes que 
varrem o código-fonte ou o código-objeto para chamar a atenção do desenvolvedor 
para anomalias do programa, como variáveis utilizadas sem serem iniciadas, 
variáveis não utilizadas ou atribuições com valores fora dos seus limites (LI; CUI, 
2010).
As anomalias são, usualmente, produtode erros de programação ou 
ausência, de maneira que elas sinalizam erros que poderiam prejudicar o software 
quando ele fosse executado (LI; CUI, 2010; CARVALHO, 2017). Entretanto, 
essas anomalias não são, necessariamente, defeitos de programa, por isso, a 
necessidade da análise profissional. Desse modo, o objetivo da análise é destacar 
os problemas, para sua correção com objetividade, tendo, como resultado, mais 
eficiência no processo de desenvolvimento seguro (ALVES, 2006; LI; CUI, 2010). 
A análise estática pode ser agrupada em:
• Verificação por estilo: examina elementos, como endentação, espaços e tabs, 
convenção de nomes, alinhamento na vertical etc. Esses aspectos contribuem 
para que o código seja padronizado, organizado e legível. 
• Verificação por boas práticas: utiliza muitas regras para verificar se as práticas 
corretas estão sendo efetivadas, como: evitar duplicação de código; garantir o 
correto uso de encoding; tamanho de métodos, classes e parâmetros; utilização 
do padrão Singleton etc. O conjunto de regras utilizadas é extenso para 
garantir que o código tenha as melhores práticas. 
• Verificação por bugs: encontrar erros no sistema, permitindo a antecipação de 
problemas no software. A ferramenta mais usada, nesse processo, é o Firebug.
UNIDADE 1 — DESENVOLVIMENTO DE SOFTWARE SEGURO
14
A verificação das ferramentas PMD e Checkstyle é feita sobre código-fonte 
não compilado (arquivo com extensão .java), porém, a verificação com Firebug analisa 
bytecodes (arquivos compilados do Java, com extensão .class). Desse modo, para análi-
ses envolvendo Firebug, uma compilação prévia é necessária.
NOTA
7 O PROBLEMA DA SEGURANÇA NO SOFTWARE
Ao longo deste tópico, podemos perceber a importância dos softwares 
e dos seus processos ao longo do desenvolvimento. No entanto, quando ocorre 
uma falha, devido a erros de programação, inúmeros problemas são gerados 
decorrentes das vulnerabilidades no software (FONTES, 2008; 2011). 
A codificação é considerada um dos maiores causadores dessas 
vulnerabilidades, já que, muitas vezes, o programador considera, geralmente, 
os cenários positivos, não se preocupando com o caso de ataques (BASU, 2015; 
TORRES; TORRES, 2016; FERREIRA, 2019).
Os imprevistos causados pela exploração dessas vulnerabilidades estão 
vinculados com a perda da integridade da informação ou a divulgação indevida 
(PINHEIRO, 2007; FONTES, 2008; FONTES, 2011; WAGNER, 2011). A Microsoft 
(2010 apud FERREIRA, 2019) utiliza o acrônimo STRIDE para classificar os efeitos 
provocados pelas falhas de segurança.
TÓPICO 1 — DESENVOLVIMENTO DE SOFTWARE
15
FONTE: O autor
Esses efeitos podem causar impactos de baixo a alto valor que irão 
depender do sistema computacional no qual o software está sendo executado. 
Conforme Fontes (2011), os incidentes podem ser simples, como a reinstalação 
de um aplicativo em uma máquina, ou impactos sérios, que afetam a vida 
humana, como a perda de controle de um sistema de transmissão de energia 
elétrica, ou de sistemas de comunicação, por exemplo. Fernandes (2013) destaca 
que o uso contínuo da internet aumenta as possibilidades de ataques, por isso, o 
desenvolvimento de software tem sofrido uma evolução constante para incorporar 
a segurança da informação durante todas as fases de desenvolvimento.
8 BENEFÍCIOS DO DESENVOLVIMENTO SEGURO 
Geralmente, as empresas iniciam os programas de desenvolvimento 
de software se concentrando na funcionalidade, e os testes segurança são 
acrescentados no fim do processo de desenvolvimento (ALVES, 2006; FONTES, 
2011; KOLBE JUNIOR, 2020). Entretanto, essa abordagem possui desvantagens em 
relação a um processo que engloba a segurança durante todo o desenvolvimento. 
FIGURA 5 – ACRÔNIMO STRIDE PROPOSTO PELA MICROSOFT
UNIDADE 1 — DESENVOLVIMENTO DE SOFTWARE SEGURO
16
FIGURA 6 – CHARGE SOBRE SEGURANÇA DE SOFTWARE
FONTE: <http://bit.ly/2WvMnw6>. Acesso em: 19 jun. 2020.
Conforme o National Institute of Standards and Technology (NIST), 
as correções de código, que são executadas após o lançamento, geram, 
aproximadamente, um custo 30 vezes maior do que das correções efetuadas 
durante a fase inicial (GALITEZI, 2011; KOLBE JUNIOR, 2020). As empresas que 
adotam um processo estruturado apresentam maior probabilidade de localizarem 
e corrigirem as vulnerabilidades no início do ciclo de desenvolvimento (GALITEZI, 
2011). 
O que precisamos considerar é que a prática de segurança no 
desenvolvimento de softwares não é utilizada por todos, mas por aqueles 
desenvolvedores, que usam uma abordagem preventiva coordenada, que 
obtêm um retorno aproximadamente quatro vezes maior do que o investimento 
anual (GALITEZI, 2011; WAGNER, 2011). Então, os principais benefícios de um 
desenvolvimento seguro, conforme Wagner (2011), são:
• Economia: a definição de requisitos de segurança e a manutenção de equipes 
que compreendam os conceitos fundamentais de segurança permitem que 
as informações utilizadas ao longo do desenvolvimento do software sejam 
usadas quando estritamente necessárias. Um código seguro é a efetivação 
de um projeto de sucesso, já que evita as vulnerabilidades e os defeitos. O 
TÓPICO 1 — DESENVOLVIMENTO DE SOFTWARE
17
resultado será economia no tempo e nos recursos, tendo um projeto rentável 
e eficiente para a empresa. 
• Produtividade: os profissionais assimilaram o sistema e, com isso, 
estabeleceram um modelo de trabalho compartilhado. No entanto, as 
informações são partilhadas de maneira ágil e incorporadas, garantindo a 
segurança do desenvolvimento do software. Isso permite mais produtividade 
dos profissionais envolvidos. 
• Foco: uma organização que investe em segurança faz com que os 
desenvolvedores se entendam e foquem o seu tempo nos processos, ou seja, 
compreendam as estratégias de mercado e apliquem no desenvolvimento do 
software. 
 
O que podemos observar é que, atualmente, muito se fala da segurança, 
mas é na segurança de software que tudo começa, já que um processo seguro 
de desenvolvimento envolve proteção física, tecnológica, conscientização dos 
profissionais envolvidos, e cada um tem suas ameaças, vulnerabilidades e riscos, 
o que gera desafios constantes. O que podemos verificar, ao longo deste tópico, é 
que a proteção é um desafio de grande importância na organização e precisa ser 
considerado em todas as etapas do desenvolvimento do software para que sua 
segurança seja garantida. 
Para finalizar este tópico, vamos entender a diferença entre qualidade do 
processo de software versus qualidade do produto de software. 
Conforme Bartie (2002) e Basu (2015), a qualidade se refere a algo operacional que precisa 
estar em conformidade com as especificações que foram definidas, porém, a qualidade do 
produto é definida como as características do produto. 
NOTA
UNIDADE 1 — DESENVOLVIMENTO DE SOFTWARE SEGURO
18
FONTE: Adaptado de <http://bit.ly/3h2s3fp>. Acesso em: 18 jun. 2020.
QUALIDADE DO PROCESSO DE SOFTWARE VERSUS QUALIDADE DO PRODUTO DE 
SOFTWARE
19
Neste tópico, você aprendeu que:
• O processo de desenvolvimento de softwares é algo complexo e, para isso, é 
preciso um conjunto de atividades organizadas e sequências estruturadas em 
passos definidos.
• Um grande ponto a ser considerado na segurança do desenvolvimento de 
software, e que está relacionado com a sua definição, é o fato de que um 
determinado software pode ser composto por algumas dezenas de linhas 
de código desenvolvidas por um programador, ou pode ser constituído por 
milhões de linhas de código, dados de configuração, documentação etc.
• O processo de software desenvolvido em uma organização é, geralmente, 
formulado através de padrões previamente descritos. 
• A segurança da informação é definida como um conjunto de orientações, 
normas, procedimentos, políticas ou outras ações que proteja o recurso à 
informação.
• Um ponto crítico ligado ao processo de desenvolvimento é a segurança, além 
da proteção das informações confidenciais. Consequentemente, a segurançado software corresponde à habilidade do software de evitar, além de suportar 
eventos que ameacem a dependabilidade.
• O desenvolvimento seguro não é somente a codificação, engloba a 
infraestrutura, para suportar o ambiente da aplicação. Desse modo, é preciso 
investir na proteção de todo o ambiente.
• O SDL se concentra no desenvolvimento do software, introduzindo a 
segurança e a privacidade em todas as fases do desenvolvimento. O SDL 
concilia uma abordagem global com a prática de minimização do número 
e do grau de severidade das vulnerabilidades nos produtos e serviços da 
Microsoft.
• O monitoramento contínuo é primordial, já que, quando uma nova ameaça 
entra no ecossistema, são ativados os processos de resposta de segurança da 
Microsoft. 
• A análise estática de código é umas das técnicas estáticas de inspeção de 
software no processo de Verificação e Validação (V&V), sendo uma análise 
automatizada seguida de uma análise profissional dos resultados obtidos.
RESUMO DO TÓPICO 1
20
• As anomalias são, usualmente, produto de erros de programação ou ausência, 
de maneira que elas sinalizam erros que poderiam prejudicar o software 
quando ele fosse executado.
• A codificação é considerada como um dos maiores causadores dessas 
vulnerabilidades, já que, muitas vezes, o programador considera, geralmente, 
os cenários positivos, não se preocupando com o caso de ataques.
• A prática de segurança no desenvolvimento de softwares não é utilizada 
por todos, mas por aqueles desenvolvedores que usam uma abordagem 
preventiva coordenada, que obtêm um retorno aproximadamente quatro 
vezes maior do que o investimento anual.
21
1 O desenvolvimento de um produto pode ocorrer por processos distintos, 
mesmo que seja um produto similar ou igual, porém, se um processo 
inadequado for usado, isso gerará o comprometimento da qualidade do 
produto final que está em desenvolvimento (SÊMOLA, 2003; FONTES, 
2011). Considerando essa afirmação, descreva as fases de processos para o 
desenvolvimento seguro de um software.
2 O desenvolvimento seguro não é somente a codificação, engloba a 
infraestrutura para suportar o ambiente da aplicação. Desse modo, é preciso 
investir na proteção de todo o ambiente (HOWARD; LIPNER, 2006). Agora, 
assinale a alternativa INCORRETA:
a) ( ) O SDL se concentra no desenvolvimento de software, introduzindo a 
segurança e a privacidade em todas as fases do desenvolvimento.
b) ( ) O SDL concilia uma abordagem global com a prática de minimização 
do número e do grau de severidade das vulnerabilidades nos produtos e 
serviços da Microsoft. 
c) ( ) A ciência interna do SDL foi desenvolvida para compreender como os 
sistemas de computador são seguros e com planos de contingência.
d) ( ) O SDL é compartilhado de modo gratuito pela Microsoft com orga-
nizações de desenvolvimento de clientes e do setor de software, tendo, 
como resultado, o desenvolvimento de softwares mais seguros. 
3 O que precisamos considerar é que a prática de segurança no desenvolvi-
mento de softwares não é utilizada por todos, mas aqueles desenvolvedores 
que usam uma abordagem preventiva coordenada obtêm um retorno apro-
ximadamente quatro vezes maior do que o investimento anual (GALITEZI, 
2011; WAGNER, 2011). Sobre o exposto, classifique V para as sentenças ver-
dadeiras e F para as sentenças falsas:
( ) Um código seguro é a efetivação de um projeto de sucesso, já que evita as 
vulnerabilidades e os defeitos.
( ) Uma organização que investe em segurança faz com que os desenvolve-
dores se entendam e foquem o seu tempo nos processos. 
( ) Um processo seguro de desenvolvimento envolve proteção física, tecnoló-
gica e conscientização dos profissionais envolvidos.
( ) As empresas que adotam um processo estruturado apresentam maior 
probabilidade de localizarem e corrigirem as vulnerabilidades no início 
do ciclo de desenvolvimento.
Assinale a alternativa que apresenta a sequência CORRETA:
( ) V – V – V – V.
( ) V – F – V – V.
( ) F – F – V – V.
( ) V – V – F – V.
AUTOATIVIDADE
22
4 O processo de desenvolvimento de softwares é algo complexo e, para isso, é 
preciso um conjunto de atividades organizadas e sequências estruturadas em 
passos definidos (SÊMOLA, 2003; ALVES, 2006; FONTES, 2011). Esse conjunto 
de atividades é definido como um processo de desenvolvimento de software, 
que recebe ajuda da engenharia de software (ALVES, 2006; FONTES, 2011). 
Assinale a alternativa CORRETA:
( ) Uma das etapas que causa grande preocupação neste processo é a falta de 
definição de uma política na implementação do software.
( ) As vulnerabilidades nos projetos podem gerar a quebra de sigilo e a 
aquisição de novas informações.
( ) As organizações estão em uma busca contínua para adotar medidas 
alinhadas às metodologias de desenvolvimento. 
( ) Existe a necessidade de produtos de software que, além suportarem os 
negócios, apresentem melhorias de segurança contínua.
5 O processo de software desenvolvido em uma organização é, geralmente, 
formulado através de padrões previamente descritos, sendo que estes 
definem um conjunto de ações e atividades, necessárias ao desenvolvimento 
do software (SOMMERVILLE, 2011). Considerando essa afirmação, assinale a 
alternativa INCORRETA:
( ) Um modelo de processo de software pode ser compreendido como um 
roteiro a ser seguido para desenvolver um software de alta qualidade em 
um tempo determinado.
( ) Modelo de processo pode ser considerado uma representação abstrata de 
um processo de software.
( ) Os softwares são responsáveis pela geração de informações, por isso, a 
segurança do software está atrelada à segurança da informação.
( ) Um dos pontos críticos ligados ao processo de desenvolvimento é o acesso 
contínuo às informações confidenciais.
23
TÓPICO 2 — UNIDADE 1
SEGURANÇA DE DADOS
1 INTRODUÇÃO
A gestão de segurança é considerada um processo que padroniza as 
melhores práticas de segurança com uma variedade de produtos. A falta de gestão 
de segurança gera problemas e a falta de respostas necessárias para resolver os 
problemas de ameaças e vulnerabilidades (FERREIRA, 2003; FERREIRA, 2019; 
GALITEZI, 2011).
Conforme Carvalho (2017), a segurança no desenvolvimento do software 
precisa considerar muitos fatores, não sendo um problema de solução única. A 
abordagem engloba:
• profissionais tecnicamente capacitados na linguagem; 
• planejamento criterioso no levantamento de requisitos;
• equipamentos com poder computacional suficiente;
• equipe de monitoramento proativa para criar e sustentar aplicações com certo 
nível de segurança.
Portanto, sem um padrão de segurança estabelecido, os clientes não 
terão garantia de que o software será seguro (GOMES et al., 2014; FERREIRA, 
2019). Sem uma gestão, não existe igualdade de segurança do produto em toda 
a organização. Ainda, sem um processo padrão estabelecido, algumas equipes 
de produto ignoram a segurança (FONTES, 2008; FONTES, 2011). Então, neste 
tópico, compreenderemos os principais conceitos de segurança que envolvem o 
desenvolvimento do software.
2 CONCEITOS DA SEGURANÇA DA INFORMAÇÃO
Conforme Fontes (2008) e Fontes (2011), a segurança da informação é uma 
área do conhecimento que protege a informação através de ações e normas que 
precisam ser cumpridas. Desse modo, Fontes (2008, p. 11) define: 
A segurança da informação é definida como um conjunto de 
orientações, normas, procedimentos, políticas e demais ações que tem, 
por objetivo, proteger o recurso, a informação, possibilitando que o 
negócio da organização e a sua missão sejam alcançados. A segurança 
existe para minimizar os riscos do negócio em relação à dependência do 
uso dos recursos de informação para o funcionamento da organização. 
Sem a informação ou com uma incorreta, o negócio pode ter perdas 
que comprometam o seu funcionamento e o retorno de investimento 
dos acionistas. 
24
UNIDADE 1 — DESENVOLVIMENTO DE SOFTWARE SEGURO
Agora, é preciso analisar um item importantedo processo de segurança do 
software, que é a implantação de uma política de segurança. Conforme Ferreira 
(2019), um processo adequado de implantação de uma política organizacional 
envolve: 
• Desenvolvimento da política: responsável pela definição dos requisitos 
corporativos da política de segurança da informação, além do estabelecimento 
de padrões para documentação. 
• Aprovação da política: responsável pelo gerenciamento da fase de identificação 
das necessidades da política até a autorização da política final.
• Implementação da política: responsável pela solicitação e pelo recebimento do 
apoio executivo. Nesta etapa, é elaborado um programa de conscientização 
de segurança corporativa.
• Conformidade com a política: avaliação da conformidade e da efetividade 
da política implementada, além de elaborar ações corretivas para a não 
conformidade. 
• Manutenção da política: realizar revisões formais da política e fundamentar 
um processo de gestão de mudanças.
Portanto, é essencial que seja abordada a hierarquia de documentos dentro 
de uma organização, considerando, principalmente, a segurança da informação 
(GOMES et al., 2014; CARVALHO, 2017; FERREIRA, 2019). A hierarquia possibilita, 
à organização, a apresentação dos documentos de segurança implementados ou 
aqueles que estão na fase de planejamento.
A hierarquia é considerada uma ferramenta importante de comunicação 
para os tomadores de decisões, gerentes de negócio, desenvolvedores, auditores 
e outros, para explicar quais documentos estão disponíveis e quais são aplicáveis 
em cada caso (GOMES et al., 2014; CARVALHO, 2017; FERREIRA, 2019). 
FIGURA 7 – EXEMPLIFICAÇÃO DE HIERARQUIA DE DOCUMENTOS
FONTE: Carvalho (2017, p. 20)
TÓPICO 2 — SEGURANÇA DE DADOS
25
Agora, vamos compreender os principais conceitos que estão inclusivos 
na formulação de uma política organizacional e em todo o processo de desenvol-
vimento de softwares. Podemos, conforme Fontes (2008), considerar os seguintes 
conceitos da segurança para garantir a proteção da informação: 
• Confiabilidade: a informação dever ser acessada e usada somente por aqueles 
que precisam dela para efetuar suas atividades na organização, por isso, deve 
existir uma prévia autorização.
• Integridade: a informação deve ser correta, verdadeira e não pode estar cor-
rompida.
• Disponibilidade da informação: a informação deve ser acessível para garantir o 
funcionamento do negócio e para que sejam atingidos os objetivos propostos. 
• Legalidade: o uso da informação precisa estar de acordo com as leis aplicáveis, 
licenças e contratos.
• Auditabilidade: o acesso e o uso da informação precisam ser registrados para 
identificar quem fez o acesso e o que foi realizado com a informação.
Portanto, para que as informações sejam protegidas, é essencial que estejam 
claros os pilares da segurança, que são primordiais para a proteção dos dados, pos-
sibilitando um bom funcionamento das infraestruturas. 
FIGURA 8 – PILARES DA SEGURANÇA
FONTE: <http://bit.ly/38rL6fh>. Acesso em: 28 jun. 2020.
Um processador de texto não tem, como principal preocupação, a 
confiabilidade, então, é necessário o bom senso do usuário em tomar algumas medidas de 
precaução, como salvar o trabalho frequentemente, para que não tenha maiores problemas 
(ALVES, 2006).
NOTA
26
UNIDADE 1 — DESENVOLVIMENTO DE SOFTWARE SEGURO
Desse modo, os padrões de segurança mostram as soluções adequadas 
para problemas recorrentes, além de servirem de modelo (CARVALHO, 2017; 
TANENBAUM; WOODHULL, 2009; FERREIRA, 2019).
O uso de padrões de segurança é uma estratégia que pode ser aplicada aos 
processos de desenvolvimento de software, com o objetivo de torná-los confiáveis 
através da inserção de atividades que implementem a segurança, de acordo com 
a solução descrita no padrão (SÊMOLA, 2003; ALVES, 2006; FONTES, 2011). 
A seguir, estarão relacionados outros conceitos fundamentais para o 
desenvolvimento de um software seguro.
QUADRO 5 – CONCEITOS DE SEGURANÇA
FONTE: Adaptado de Fontes (2011), Fernandes (2013) e Ferreira (2019)
CONCEITO DEFINIÇÃO
Ameaça
causa potencial de um incidente indesejado, gerando 
dano para um sistema ou organização. Pode ser, ainda, 
um agente externo ao ativo de informação se aproveitan-
do das vulnerabilidades para romper a confidencialida-
de, integridade ou disponibilidade da informação.
Vulnerabilidade fragilidade de um ativo, ou, ainda, de um determinado grupo de ativos que pode ser explorada por ameaças.
Impactos de 
incidentes
potenciais prejuízos provocados ao negócio por 
fragilidades na segurança. Os prejuízos geram perdas de 
recursos financeiros e profissionais, além da deterioração 
da imagem da organização no mercado. 
Privacidade
proteção das informações e a sua utilização de modo ade-
quado através da autorização do cliente. Desse modo, 
uma grande quantidade de informações armazenadas 
gera maior investimento para garantir a segurança, por-
tanto, muitas informações armazenadas podem gerar um 
alto custo para a organização em detrimento dos bene-
fícios do armazenamento. É essencial verificar a relação 
custo x benefício, sendo necessário uma análise de quais 
informações trazem vantagem competitiva. 
Identificação
identificar o usuário dentro do sistema, ou seja, um usu-
ário para uma pessoa. Essa prática possibilita a identifi-
cação do responsável por uma ação efetuada dentro da 
aplicação por meio da trilha de auditoria.
Autenticação
prova que o usuário é ele mesmo, pois ele possui a identi-
dade de acesso na aplicação. O processo pode sofrer me-
lhorias, utilizando a autenticação multifator.
Autorização garantir que o usuário possua autorização concedida pelo cliente da aplicação a acesso das informações. 
Responsabilização garante que a ação executada possa ser atribuída a uma determinada pessoa ou sistema.
Assurance Garante que os controles de segurança foram implemen-tados, avaliados e testados.
TÓPICO 2 — SEGURANÇA DE DADOS
27
3 PRINCÍPIOS DO SOFTWARE SEGURO
A segurança deve ser uma preocupação em todo o processo de 
desenvolvimento, para que problemas com erros, vulnerabilidades e ameaças 
não aconteçam no produto final. Assim, quando se propõe uma solução para 
a resolução de problemas, é preciso considerar os princípios fundamentais do 
software seguro, descritos por Viega e McGraw (2006 apud FERREIRA, 2019).
QUADRO 6 – PRINCÍPIOS DO SOFTWARE SEGURO
FONTE: Adaptado de Carvalho (2017) e Ferreira (2019)
PRINCÍPIOS DESCRIÇÃO
Proteger o elo mais 
fraco
A segurança defensiva do sistema precisa ser como 
uma corrente interligada. Os ataques ocorrerão nas 
brechas do elo mais frágil dessa cadeia.
Defender em 
profundidade
Gerir o risco de modo defensivo em todas as camadas 
e componentes, para que, se um deles falhar, o outro 
consiga funcionar de maneira adequada.
Falhar com 
segurança
Enfrentar as falhas e erros com segurança, pois o 
manuseio inadequado de falhas é, geralmente, a causa 
de quebras de segurança.
Minimizar o 
privilégio
Executar o software com a minimização de privilégios 
para reduzir o possível impacto de um ataque.
Compartimentar 
acessos e áreas
Limitar o máximo possível os danos de ataques, 
compartimentando as áreas, usando VPNs, contentores, 
firewalls.
Manter a 
simplicidade (Keep 
It Simple- KISS)
A maior complexibilidade de um sistema gera mais 
dificuldade de manutenção e, consequentemente, 
muitos problemas à segurança.
Promover a 
privacidade
A proteção de dados pessoais e do sistema é essencial. 
A causa de muitos ataques é a exposição inadequada 
de informação sensível.
Esconder segredos é 
difícil
Até mesmo os melhores algoritmos de segurança 
podem ser quebrados e a confiança no “secreto” é a 
origem das falhas de segurança.
Confiar 
desconfiando
A segurança tem, por premissa, a confiança de uma 
fonte, mas nunca se pode confiar plenamente. Por isso, 
é necessário sempre tomar as devidas contramedidas 
para manutenção do software seguro.
Usar os recursos da 
comunidade
Se algo está bem concebidoe já foi escrutinado pela 
comunidade, provavelmente, é uma boa fonte de 
segurança.
28
UNIDADE 1 — DESENVOLVIMENTO DE SOFTWARE SEGURO
4 SETE PONTOS DE SEGURANÇA DO SOFTWARE SEGURO
Os sete pontos foram definidos por McGraw (2005 apud FERREIRA, 2019) 
e foram organizados pela eficácia e quantidade de erros e falhas que podem 
verificar e mitigar nas diferentes fases de desenvolvimento de um software: 
• Análise estática e revisão de código-fonte para verificar bugs e vulnerabilidades.
• Análise de risco para evidenciar tipos e padrões de ataque.
• Testes de penetração para testar as aplicações em ambiente simulado e em 
ambiente real.
• Os testes de qualidade precisam abranger os testes de funcionalidade padrão 
e os testes de segurança baseados em padrões de ataque.
• Construção de casos de abuso que identifiquem maus usos do sistema, além 
das respostas deste.
• Especificação de requisitos de segurança delineados, permitindo as respostas 
do sistema.
• Monitoramento do software contra padrões de ataque de modo a ter sistemas 
mais seguros. 
Esses pontos de contato possuem tarefas específicas que estão relacionadas 
com diferentes fases de um processo, não sendo, portanto, uma sequência linear. 
A detecção de algum problema leva a revisitar e a atualizar as especificações de 
cada etapa para que o resultado alcançado seja o mais seguro.
TÓPICO 2 — SEGURANÇA DE DADOS
29
5 REQUISITOS DE SEGURANÇA DE SOFTWARE 
Ferreira (2019) define requisitos de segurança como as necessidades 
do software para atender às políticas regulatórias e institucionais de uma 
organização. Desse modo, a definição dos requisitos de segurança é realizada 
pelos engenheiros de sistemas com os usuários. A norma ISO/IEC 27001 (20093) 
salienta que os requisitos de segurança são identificados por meio de uma análise 
sistemática dos riscos de segurança da informação. 
Os requisitos de segurança de software precisam englobar as necessidades 
de segurança da organização definidas nas políticas organizacionais. O que se 
percebe como ponto fundamental no delineamento dos requisitos de segurança 
é o reconhecimento das ameaças. Para isso, consideram-se as políticas de alto 
nível da organização para determinar a relevância de cada uma das ameaças 
(TANENBAUM; WOODHULL, 2009; CARVALHO, 2017; FERREIRA, 2019). 
Analise o exposto a seguir para complementar a sua compreensão acerca 
da importância da segurança no desenvolvimento dos softwares. 
VULNERABILIDADES DO SOFTWARE
FONTE: Adaptado de <https://bit.ly/3auhz78>. Acesso em: 26 jun. 2020.
UNI
https://ynternix.com/saiba-a-diferenca-de-virus-e-malwares-o-que-sao-trojans-spyware-adwares/
30
UNIDADE 1 — DESENVOLVIMENTO DE SOFTWARE SEGURO
Os requisitos podem ser alinhados conforme as fontes, ou seja, um conjunto 
particular de princípios, objetivos e os requisitos do negócio para o processamento 
da informação, tendo os seguintes tipos, de acordo com Ferreira (2019): 
• Fonte da análise/avaliação de riscos: considera os objetivos e as estratégias 
globais do negócio da organização. Por meio da análise e da avaliação de 
riscos, são indicadas as ameaças aos ativos, além das vulnerabilidades. Após 
esta etapa, é efetuada uma estimativa da probabilidade de ocorrência das 
ameaças, além do potencial do impacto causado ao negócio.
• Fonte legal: considera a legislação vigente, regulamentação, estatutos e 
cláusulas contratuais que a organização, parceiros comerciais, contratados e 
provedores de serviços possuem. 
6 FERRAMENTAS E TÉCNICAS DE AVALIAÇÃO DOS RISCOS
O risco é considerado como algo que pode ou não acontecer, mas se 
acontecer, terá impactos negativos ao projeto em relação aos custos, prazos, 
qualidade, tempo ou satisfação do usuário (FERNANDES, 2013; GOMES et al., 
2014; CARVALHO, 2017). Um risco pode ter uma causa definida ou várias causas 
e, se acontecer, pode gerar um ou vários impactos (FONTES, 2011). O risco, de 
acordo com Ferreira (2019), possui duas dimensões, no caso da sua ocorrência: 
• Probabilidade da sua ocorrência: está ligada à causa-raiz. As ações direcionadas 
à causa do risco afetam a probabilidade de o risco não acontecer.
• Impacto sobre o projeto: está associado ao efeito. As ações sobre o efeito do 
risco afetam o impacto. 
A identificação de riscos gera uma seleção de ocorrências que pode 
ameaçar ou oferecer vantagens em relação aos objetivos do projeto. A causa de um 
risco pode ser um requisito, uma restrição ou uma condição que gere resultados 
negativos ou positivos (GOMES et al., 2014; CARVALHO, 2017). Durante o 
processo de levantamento, surgem os riscos conhecidos, gerando uma resposta. 
Entretanto, alguns riscos não são gerenciados, assim, a equipe precisa elaborar 
um plano de contingência (GOMES et al., 2014; CARVALHO, 2017; FERREIRA, 
2019). A quadro a seguir relaciona as principais estratégias de contingência, 
conforme Lyra (2008). 
TÓPICO 2 — SEGURANÇA DE DADOS
31
QUADRO 7 – ESTRATÉGIAS DE CONTINGÊNCIA
FONTE: Adaptado de Lyra (2008)
O que é importante considerar é que um plano adequado de contingência 
pode ser capaz de sustentar a missão da organização, independentemente de 
quaisquer intempéries.
6.1 CATEGORIZAÇÃO DE RISCOS
O risco, no contexto da área de software, tem, como objetivo, ser 
incremental e direcionado à análise de riscos (LYRA, 2008; FERNANDES, 2013; 
CARVALHO, 2017). A área de riscos na engenharia de software evoluiu, já que 
passou de uma análise dentro dos modelos para uma gerência que está presente 
em todos os processos do ciclo de vida do software (CARVALHO, 2017). Desse 
modo, conforme Ferreira (2019), os riscos precisam ser categorizados. 
ESTRATÉGIA DE 
CONTINGÊNCIA DESCRIÇÃO
Hot-site Responsável para entrar em ação de modo imediato, sendo que o tempo de operacionalização está atrelado 
ao tempo de tolerância à falha do objeto. 
Warm-site
Utilizada em objeto com uma tolerância maior 
à paralisação, sendo que pode ficar sujeita à 
indisponibilidade por mais tempo, até o retorno 
operacional da atividade.
Cold-site Uma alternativa de contingência, considerando um ambiente com mínimos recursos (infraestrutura e 
telecomunicações).
Realocação de 
operação
Desviar a atividade que foi atingida pelo evento que 
causou a quebra da segurança para outro ambiente 
físico, link ou equipamento, pertencente a uma mesma 
organização. 
Bureau de serviços Transferir a processo de operacionalização da atividade atingida para um ambiente terceirizado. 
Essa estratégia é muito interessante.
Contingência significa algo incerto ou eventual, que pode suceder ou não, 
dependendo das circunstâncias.
NOTA
32
UNIDADE 1 — DESENVOLVIMENTO DE SOFTWARE SEGURO
QUADRO 8 – CATEGORIAS DE RISCOS
FONTE: Adaptado de Ferreira (2019)
6.2 GERENCIAMENTO DE RISCOS EM PROJETOS
Os objetivos principais do gerenciamento dos riscos são o aumento da 
probabilidade, o impacto dos eventos positivos e a redução da ocorrência do 
impacto negativo no projeto (GOMES et al., 2014; CARVALHO, 2017). Desse modo, 
o gerenciamento de riscos representa a identificação das possíveis incertezas para 
tentar controlá-las. 
Ferreira (2019) segmenta a abordagem em três etapas principais, conforme 
o quadro a seguir. Assim, são abordados os riscos técnicos do produto vinculados 
aos requisitos de software, sendo identificados, analisados e controlados. 
QUADRO 9 – GERENCIAMENTO DE RISCOS
FONTE: Adaptado de Ferreira (2019)
 
Para cada atividade do ciclo de vida do processo de teste de software, existe 
um correspondente na gestão de risco, com o objetivo de fornecer o tratamento 
correto para os riscos técnicos identificados (FERREIRA, 2019). 
TIPO DE RISCO DESCRIÇÃO
Riscos de Projeto 
de Software
Define os parâmetros operacionais, organizacionais e 
contratuais de desenvolvimento de software.
Riscos de 
Processo de 
Software
Relacionam-se os problemas técnicos e de gerenciamento. 
Nos procedimentos técnicos, podem se encontrar riscos 
nas atividades de análise de requisitos, projeto, codificação 
e teste.
Riscosde 
Produto de 
Software
Contém as características intermediárias e finais do 
produto. Esses tipos de riscos têm origem nos requisitos 
de estabilidade do produto, desempenho, complexidade 
de codificação e especificação de testes.
ETAPA DESCRIÇÃO
Lista priorizada de 
riscos
Identificação e análise dos riscos técnicos ligados aos 
requisitos de software.
Testes que 
exploram os riscos
Criação e execução dos casos de testes que verificam a 
existência ou não do risco identificado.
Monitoramento e 
controle dos riscos
Conforme um risco é eliminado, um novo risco pode 
surgir e os esforços de teste devem ser ajustados para 
que foquem nos riscos importantes.
TÓPICO 2 — SEGURANÇA DE DADOS
33
FIGURA 9 – ATIVIDADE NO PROCESSO DE DESENVOLVIMENTO DO SOFTWARE E A RELAÇÃO 
COM A GESTÃO DE RISCO
FONTE: Ferreira (2019, p. 23)
Conforme Ferreira (2019), agora, nós entenderemos os processos 
apontados:
• Estratégia e planejamento: englobam a identificação e avaliação deles, além 
do desenvolvimento de planos de contingência ou da mitigação dos riscos.
• Avaliação dos riscos: determina os efeitos de riscos potenciais. 
• Mitigação de riscos: focada em informações que foram levantadas nas etapas 
anteriores.
• Comunicação: tem, por base, as informações obtidas na identificação, 
planejamento, avaliação e mitigação dos riscos.
• Previsão de risco: resultado das atividades anteriores e representa a 
previsão de risco, envolvendo o conhecimento adquirido acerca dos riscos já 
identificados. 
• Fase execução do teste: monitora a qualidade de cada função individual, 
sendo uma atividade contínua durante toda a fase de teste.
Algumas ferramentas que auxiliam na gestão dos riscos, conforme Wagner 
(2011):
• Brainstorming – Entrevistas estruturadas ou semiestruturadas: um meio de coletar 
um amplo conjunto de ideias e avaliação, classificando-o por uma equipe. O brains-
torming pode ser estimulado através de instruções ou de técnicas de entrevista.
• Delphi: um meio de combinar opiniões de especialistas que possam apoiar a fonte 
e influenciar a estimativa de identificação, probabilidade, consequência e avaliação 
de riscos. É uma técnica colaboradora para a construção do consenso entre os 
especialistas. 
NOTA
34
UNIDADE 1 — DESENVOLVIMENTO DE SOFTWARE SEGURO
• Structured What If Technique (SWIFT): um sistema para solicitar uma equipe para 
identificar os riscos. Normalmente, é utilizado dentro de um workshop facilitado. 
Normalmente, associado a uma técnica de análise e avaliação de riscos. 
• Análise de cenário: aborda a possibilidade de possíveis cenários futuros. Podem ser 
identificados por meio da imaginação ou extrapolação dos riscos atuais, presumindo 
que cada um desses cenários pode ocorrer.
• Análise de impacto nos negócios: Provê uma análise de como os principais riscos de 
quebra podem afetar as operações de uma organização e identifica e quantifica que 
capacidades que seriam requeridas para o gerenciamento.
6.3 MATRIZ DE RISCO
A ponderação de um risco é avaliada por meio da combinação da 
probabilidade ou frequência de ocorrência e da magnitude das consequências ou 
impacto dessa ocorrência (FERREIRA, 2019). A seguir, apresentaremos a matriz 
de probabilidade e impacto representada no PMBOK, que mostra uma escala de 
probabilidade e impacto de 0 (zero) a 5 (cinco). 
FIGURA 10 – MATRIZ DE PROBABILIDADE E IMPACTO
FONTE: <http://bit.ly/3mLP0F3>. Acesso em: 28 jun. 2020.
A matriz de risco é considerada uma ferramenta muito usada, que 
ajuda o desenvolvedor na classificação e priorização de riscos e, ainda, facilita a 
comunicação visual (FERNANDES, 2013; GOMES et al., 2014; FERREIRA, 2019). 
A representação é por meio de eixos de escalas de probabilidade de ocorrência e 
impacto para um determinado fator de risco.
Após a representação visual da matriz, cada um dos fatores de risco 
precisa ser identificado e avaliado em relação à probabilidade de ocorrência e 
ao impacto (LYRA, 2008; CARVALHO, 2017; FERREIRA, 2019). Os riscos que 
precisam ser tratados de modo prioritário ficam localizados na região vermelha.
TÓPICO 2 — SEGURANÇA DE DADOS
35
Com relação à definição dos níveis das dimensões, é necessário se atentar 
para que a quantidade de níveis para probabilidade e impacto seja a mesma, por 
exemplo, se for decidido que a probabilidade será apenas baixa, média e alta (três 
níveis), o impacto pode ser insignificante, moderado ou catastrófico, ou seja, três 
níveis também.
FIGURA 11 – REPRESENTAÇÃO DE UMA MATRIZ DE RISCOS
FONTE: <http://bit.ly/34wDC9J>. Acesso em: 20 jun. 2020.
Observe, a seguir, um exemplo aplicado de uma matriz de impacto. Esse 
modelo irá ajudá-lo a entender como funciona o preenchimento da matriz.
EXEMPLIFICAÇÃO DA MATRIZ DE IMPACTO
FONTE: <http://bit.ly/3mLQAGZ>. Acesso em: 20 jun. 2020.
NOTA
36
UNIDADE 1 — DESENVOLVIMENTO DE SOFTWARE SEGURO
A análise qualitativa de riscos avalia a prioridade dos riscos identificados, 
usando a probabilidade de eles ocorrerem, o impacto correspondente aos 
objetivos do projeto, se os riscos realmente ocorrerem, além de outros fatores, 
como o prazo e tolerância a risco das restrições de custo, cronograma, escopo e 
qualidade do projeto (ALVES, 2006; SÊMOLA, 2003; LYRA, 2008; FERNANDES, 
2013; CARVALHO, 2017; FERREIRA, 2019).
A análise qualitativa de riscos é, normalmente, uma maneira rápida e 
econômica de estabelecer prioridades para o planejamento de respostas a riscos 
e estabelece a base para a análise quantitativa de riscos (LYRA, 2008; FONTES, 
2011; FERNANDES, 2013).
7 PADRÕES DE SEGURANÇA
Você, ao longo deste tópico, percebeu o quão importante é, que no 
planejamento de um novo software, todos os envolvidos compreendam os 
padrões de segurança em vários níveis. Desse modo, as experiências adquiridas 
em projetos anteriores de software são uma fonte de consulta, além de websites 
e outras publicações especializadas (SÊMOLA, 2003; MOUGOUE, 2016; 
FERREIRA, 2019). Então, para finalizar este tópico, listaremos alguns exemplos 
de boas práticas de planejamento e de desenvolvimento de softwares, conforme 
Alves (2006), Fontes (2011), Fernandes (2013), Carvalho (2017) e Ferreira (2019).
• As configurações do software com informações sensíveis precisam ser 
criptografadas quando em ambiente de produção. Um exemplo é O Net, que 
oferece ferramentas nativas para criptografia de partes do arquivo web.config.
FIGURA 12 – O NET OFERECE FERRAMENTAS NATIVAS PARA CRIPTOGRAFIA
FONTE: <http://www.macoratti.net/Cursos/Cripto/net_cripto4.htm>. Acesso em: 20 jun. 2020.
http://www.macoratti.net/Cursos/Cripto/net_cripto4.htm
TÓPICO 2 — SEGURANÇA DE DADOS
37
• Definir modos de evitar SQL Injection, visto que esse tipo de ataque é 
usualmente comum. A consequência é a coleta de informações protegidas ou 
a inutilização do sistema.
FIGURA 13 – EXEMPLO DE SQL INJECTION
FONTE: <http://bit.ly/37BBW0h>. Acesso em: 20 jun. 2020.
• Impedir, passar e receber valores sensíveis de consulta na URL de websites. 
Os parâmetros devem ser transmitidos por meio do método GET do protocolo 
Hypertext Transfer Protocol (HTTP). Entretanto, em situações em que não se 
pode usar criptografia SSL em decorrência de restrições de negócio, expõem-
se os parâmetros em texto puro (plain text) para o usuário, ou quem venha 
a sniffar (capturar pacotes) na rede.
FIGURA 14 – EXEMPLO GET DO PROTOCOLO HTTP
FONTE: <https://medium.com/totvsdevelopers/rest-no-protheus-b%C3%A1sico-do-b%C3%A1si-
co-a4b4431a4e3e>. Acesso em: 20 jun. 2020.
https://pt.wikipedia.org/wiki/Inje%C3%A7%C3%A3o_de_SQL
https://medium.com/totvsdevelopers/rest-no-protheus-b%C3%A1sico-do-b%C3%A1sico-a4b4431a4e3e
https://medium.com/totvsdevelopers/rest-no-protheus-b%C3%A1sico-do-b%C3%A1sico-a4b4431a4e3e
38
UNIDADE 1 — DESENVOLVIMENTO DE SOFTWARE SEGURO
• Tratar os dados recebidos via HTTP no backend. Entretanto, em situações 
nas quais não se tenha esse cuidado, uma pequena modificação na Uniform 
Resource Locator (URL) pode executar uma consulta não prevista.Isso pode 
gerar a exposição de informações que não deveriam estar disponíveis ao 
usuário.
FIGURA 15 – EXEMPLIFICAÇÃO DO HTTP NO BACKEND
FONTE: <https://i.stack.imgur.com/ZvEoq.jpg>. Acesso em: 20 jun. 2020.
• Não realizar a codificação na lógica de negócio em javascript. Atualmente, 
surgiram novos frameworks em javascript, porém, é preciso lembrar que 
qualquer um pode acessar o código-fonte nesse formato e expor as regras de 
negócio.
https://i.stack.imgur.com/ZvEoq.jpg
TÓPICO 2 — SEGURANÇA DE DADOS
39
FIGURA 16 – EXEMPLIFICAÇÃO DE JAVASCRIPT
FONTE: <https://wtricks.com.br/como-usar-filter-em-javascript/>. Acesso em: 20 jun. 2020.
Para finalizar, percebe-se que, durante toda a etapa de desenvolvimento 
do software, é preciso garantir a qualidade, além de realizar testes com o intuito 
de manter um alto nível de segurança para o software desenvolvido (WAGNER, 
2011; CARVALHO, 2017; FERREIRA, 2019).
https://wtricks.com.br/como-usar-filter-em-javascript/
40
RESUMO DO TÓPICO 2
Neste tópico, você aprendeu que:
• A gestão de segurança é considerada um processo que padroniza as melhores 
práticas de segurança em uma variedade de produtos. A falta de gestão de 
segurança gera problemas e a falta de respostas necessárias para resolver os 
problemas de ameaças e vulnerabilidades.
• Um processo adequado de implantação de uma política organizacional 
envolve: desenvolvimento da política, aprovação da política, implementação 
da política, conformidade com a política e manutenção da política.
• A confiabilidade é a informação dever ser acessada e usada somente por 
aqueles que precisam dela para efetuar suas atividades na organização, por 
isso, deve existir uma prévia autorização.
• A integridade é a informação deve ser correta, verdadeira e não pode estar 
corrompida.
• A disponibilidade da informação é a informação deve ser acessível para 
garantir o funcionamento do negócio e para que sejam atingidos os objetivos 
propostos. 
• A legalidade é o uso da informação precisa estar de acordo com as leis 
aplicáveis, licenças e contratos.
• A auditabilidade é o acesso e o uso da informação precisam ser registrados 
para identificar quem fez o acesso e o que foi realizado com a informação.
• O uso de padrões de segurança é uma estratégia que pode ser aplicada aos 
processos de desenvolvimento de software, com o objetivo de torná-los 
confiáveis através da inserção de atividades que implementem a segurança, 
de acordo com a solução descrita no padrão.
• A análise estática é para verificar bugs e vulnerabilidades.
• A análise de risco é para evidenciar tipos e padrões de ataque.
• Os testes de penetração são para testar as aplicações em ambiente simulado e 
em ambiente real. 
• Os testes de qualidade precisam abranger os testes de funcionalidade padrão 
e os testes de segurança baseados em padrões de ataque.
41
• A especificação de requisitos de segurança precisa ser delineada, permitindo 
as respostas do sistema.
• Os requisitos de segurança de software precisam englobar a necessidade de 
segurança da organização definida nas políticas organizacionais. 
• O risco é considerado algo que pode ou não acontecer, mas se acontecer, 
terá impactos negativos ao projeto em relação aos custos, prazos, qualidade, 
tempo ou satisfação do usuário.
• O risco, no contexto da área de software, tem, como objetivo, ser incremental 
e direcionado à análise de riscos. 
• A ponderação de um risco é avaliada através da combinação da probabilidade 
ou frequência de ocorrência e da magnitude das consequências ou impacto 
dessa ocorrência.
• A matriz de risco é considerada uma ferramenta muito usada, que ajuda o 
desenvolvedor na classificação e priorização de riscos e facilita a comunicação 
visual.
42
1 A gestão de segurança é considerada como um processo que padroniza 
as melhores práticas de segurança numa variedade de produtos. A falta de 
gestão de segurança acarreta problemas e na falta de respostas necessárias 
para resolver os problemas de ameaças e vulnerabilidades (FERREIRA, 2003; 
FERREIRA, 2019; GALITEZI, 2011). Conforme Carvalho (2017), a segurança 
no desenvolvimento de software precisa considerar muitos fatores não sendo 
um problema de solução única. Considerando essa afirmação, cite os fatores: 
2 O uso de padrões de segurança é uma estratégia que pode ser aplicada 
aos processos de desenvolvimento de software, com objetivo de torná-los 
confiáveis através da inserção de atividades que implementem a segurança 
de acordo com a solução descrita no padrão (SÊMOLA, 2003; ALVES, 2006; 
FONTES, 2006). Dessa forma, assinale a alternativa INCORRETA:
a) ( ) A segurança deve ser uma preocupação em todo o processo de desen-
volvimento, para que problemas com erros, vulnerabilidades e ameaças 
não aconteçam no produto final.
b) ( ) A segurança defensiva do sistema precisa ser como uma corrente in-
terligada. 
c) ( ) Enfrentar as falhas por meio de planos de contingências que podem 
resultar na quebra de segurança.
d) ( ) Gerir o risco de modo defensivo em todas as camadas e componentes, 
para que se um deles falhar, o outro consiga funcionar de maneira ade-
quada. 
3 Ferreira (2019) define requisitos de segurança como as necessidades do 
software para atender às políticas regulatórias e institucionais de uma 
organização. Deste modo, a definição dos requisitos de segurança é realizada 
pelos engenheiros de sistemas em conjunto com os usuários. Sobre o exposto, 
classifique V para as sentenças verdadeiras e F para as falsas:
 
( ) Os requisitos de segurança de software precisam englobar as neces-
sidades de segurança da organização definidas nas políticas organizacionais. 
( ) No delineamento dos requisitos de segurança é preciso reconhecer as 
ameaças que o software está sujeito. 
( ) Um processo seguro de desenvolvimento envolve proteção física em 
vários graus de desenvolvimento e implementação do sistema.
( ) Na definição dos requisitos é preciso considerar as políticas de alto 
nível da organização para determinar a relevância de cada uma das ameaças.
 
Assinale a alternativa que apresenta a sequência CORRETA:
( ) V – V – V – V.
( ) V – F – V – V.
( ) F – F – V – V.
( ) V – V – F – V.
AUTOATIVIDADE
43
4 O risco é considerado como algo que pode ou não acontecer, mas se acontecer 
terá impactos negativos ao projeto em relação aos custos, prazos, qualidade, 
tempo ou satisfação do usuário (FERNANDES, 2013; GOMES et al., 2014; 
CARVALHO, 2017). Assinale a alternativa CORRETA:
( ) Um risco não possui causa definida e, se acontecer, pode gerar um impacto 
negativo de alto grau.
( ) A identificação de riscos gera um plano de contingência e oferece inúmeras 
vantagens competitivas à organização.
( ) As organizações estão em uma busca contínua de levantamento de inúmeras 
categorias de risco para adotar metodologias de desenvolvimento. 
( ) O risco no contexto da área de software tem como objetivo ser incremental 
e direcionado à análise de riscos.
5 Os objetivos principais do gerenciamento dos riscos são o aumento da 
probabilidade e o impacto dos eventos positivos e a redução da ocorrência 
dos impactos negativos no projeto (GOMES et al., 2014; CARVALHO, 2017). 
Considerando esta afirmação, assinale a alternativa INCORRETA:
( ) O gerenciamento de riscos representa a identificação das possíveis incerte-
zas para tentar controlá-las.
( ) A ponderação de um risco é avaliada através da combinação da probabilidade 
ou frequência de ocorrência e da magnitude das consequências ou impacto 
dessa ocorrência.
( ) As experiências adquiridas em projetos anteriores de software são uma 
fonte de consultas, bem como websites e outras publicações especializadas.
( ) As configurações do software precisam estar disponíveis no ambiente de 
produção para facilitar o desenvolvimento.
44
45
TÓPICO 3 — UNIDADE 1
NORMAS E MODELOS DE SEGURANÇA
1 INTRODUÇÃO 
O estabelecimento de modelos padrões para serem seguidos auxilia com 
fatores de suma importância emtodo o mundo, já que as diferenças na qualidade 
podem ser observadas com a implantação de regras específicas, servindo como 
base para elaborar ou melhorar legislações específicas para as organizações 
(FERREIRA, 2019).
Os documentos, nomeados como normas são descritos como textos 
técnicos que fixam padrões regulamentadores, garantindo a qualidade de um 
determinado produto, processo ou serviço com o intuito de garantir a segurança 
durante o uso (FERNANDES, 2013; FERREIRA, 2019).
As normas e modelos de segurança representam as práticas que as 
organizações podem seguir para estarem de acordo com um nível almejado de 
segurança. Então, neste tópico, descreveremos as principais normas presentes na 
literatura que abordam a segurança de sistemas. 
2 MODELO SSE-CMM 
Conforme Wagner (2011), Systems Security Engineering Capability Maturity 
Model (SSE-CMM) é um modelo de processo de referência, que tem, por intuito, 
levantar os requisitos para implementação de segurança em um sistema ou 
em uma série de sistemas (FERNANDES, 2013; FERREIRA, 2019). O modelo 
foi elaborado para reduzir os gastos na produção de sistemas mais seguros e 
confiáveis.
O modelo SSE-CMM se tornou, em 2002, a norma ISO/IEC 21827, com a 
iniciativa de sedimentar, internacionalmente, a eficácia da aplicação do modelo (WAGNER, 
2011).
NOTA
46
UNIDADE 1 — DESENVOLVIMENTO DE SOFTWARE SEGURO
O SSE-CMM define a segurança como parte integrante da engenharia que 
trabalha com os problemas de segurança do hardware, software ou sistemas. O 
objetivo é operar em um contínuo ciclo de avaliação do estado atual, efetivando 
melhorias contínuas e repetindo o ciclo (HOWARD; LIPNER, 2006; WAGNER, 
2011; MOUGOUE, 2016; FERREIRA, 2019). As práticas-base do modelo SSE-
CMM diretamente relacionadas à segurança são mostradas no quadro a seguir: 
QUADRO 10 – PRÁTICAS DO MODELO SSE-CMM
FONTE: Adaptado de Wagner (2011)
ÀREA DE PROCESSOS (PA) OBJETIVO
PA 01- Administração dos 
controles de segurança
Assegurar que a segurança destinada para 
o sistema foi integrada dentro do projeto do 
sistema e é, de fato, realizada pelo sistema 
resultante em seu estado operacional.
PA 02- Avaliação do impacto
Identificar os impactos que são motivos de 
preocupação em relação ao sistema e para 
avaliar a ocorrência de impactos.
PA 03- Avaliação dos riscos 
de segurança
Identificar os riscos de segurança relacionados 
ao sistema em um ambiente definido. Envolve 
a identificação e a avaliação da probabilidade 
da ocorrência de riscos. 
PA 04- Avaliação das ameaças Identificar as ameaças de segurança, suas características e propriedades.
PA 05- Avaliação das 
vulnerabilidades
Identificar e caracterizar as vulnerabilidades 
dos sistemas de segurança.
PA 06- Construção de 
argumentos de garantia
Transmitir as necessidades de segurança do 
cliente cumpridas.
PA 07- Coordenação da 
segurança
Assegurar que as partes envolvidas com 
atividades de engenharia de segurança são 
adequadas e consistentes. 
PA 08- Monitoração da 
postura de segurança
Assegurar que todas as brechas de tentativa 
de violação ou erros que poderiam conduzir a 
uma violação de segurança são identificados 
e comunicados. 
PA 09- Fornecimento da 
entrada de segurança
Fornecer, a arquitetos, projetistas, 
programadores ou usuários do sistema, a 
informação de segurança necessária. 
PA 10- Especificação das 
necessidades de segurança
Identificar as necessidades relacionadas para 
segurança do sistema. Essa PA abrange todos 
os aspectos da segurança de todo o sistema 
de informação relacionado com as exigências 
de concepção, desenvolvimento, verificação, 
operação e manutenção do sistema.
PA 11- Verificação e validação 
da segurança
Assegurar que soluções de segurança 
são verificadas contra os requerimentos, 
arquiteturas e projetos, usando observação, 
demonstração, análises e testes de segurança.
TÓPICO 3 — NORMAS E MODELOS DE SEGURANÇA
47
3 NORMA ISO/IEC 17799 E ISO/IEC 27001 
As normas ISO/IEC 17799 e ISO/IEC 27001 são responsáveis por prover um 
modelo para estabelecer, implementar, operar, monitorar, analisar criticamente, 
manter e melhorar um Sistema de Gestão de Segurança da Informação (SGSI) 
(WAGNER, 2011). 
Essas normas têm grandes semelhanças, sendo que muitos dos processos 
podem ser considerados como princípios básicos para o estabelecimento da 
segurança em qualquer tipo de organização (SÊMOLA, 2003; LYRA, 2008; 
WAGNER, 2011; MOUGOUE, 2016). A principal diferença entre essas normas 
é que a ISO/IEC 17799, como é mais detalhada, descreve controles e regras 
a serem seguidos na implementação da segurança, e a ISO/IEC 27001 trata de 
segurança em um nível mais elevado, voltado para a direção e alta administração 
da organização (CARVALHO, 2017; FERREIRA, 2019). 
3.1 ISO/IEC 27001:2018
A ISO 27001 é considerada uma norma internacional publicada pela 
International Standardization Organization (ISO) e tem, como objetivo, gerenciar a 
segurança da informação em uma organização (FERREIRA, 2019). A versão mais 
recente dessa norma foi publicada em 2018, sendo nomeada ISO/IEC 27001:2018 
(FERREIRA, 2019).
A figura a seguir ilustrará a estrutura da ISO 27001, sendo que os controles 
são implementados usualmente em políticas, procedimentos e nas implementações 
técnicas, como em software, por exemplo (FERNANDES, 2013; FERREIRA, 
2019). Em determinadas organizações, o hardware e o software, entretanto, já 
estão implementados e são usados de modo inseguro, então, nessas situações, 
para a implementação da ISO 27001, são abordadas as regras organizacionais 
na prevenção de brechas de segurança (FERNANDES, 2013; CARVALHO, 2017; 
FERREIRA, 2019).
FIGURA 17 – ESTRUTURA DA ISO 27001
FONTE: <http://bit.ly/3mDvgDs>. Acesso em: 29 jun. 2020.
48
UNIDADE 1 — DESENVOLVIMENTO DE SOFTWARE SEGURO
Um grande ponto a ser considerado é que o gerenciamento da informação 
também engloba o gerenciamento de processos, recursos humanos, proteção 
física etc. (LYRA, 2008; CARVALHO, 2017; FERREIRA, 2019). Desse modo, a 
segurança da informação é parte da gestão geral de riscos em uma organização, 
tendo a sobreposição em áreas de cyber segurança, gestão da continuidade do 
negócio e gestão de tecnologia da informação (HOWARD; LIPNER, 2006; LYRA, 
2008; KOLBE, 2020).
FIGURA 18 – SEGURANÇA DA INFORMAÇÃO
FONTE: <http://bit.ly/3mDvgDs>. Acesso em: 29 jun. 2020. 
A ISO/IEC 27001 é dividida em 11 seções e Anexo A. As seções de 0 a 3 são 
introdutórias e não obrigatórias, e as seções de 4 a 10 são obrigatórias (FERREIRA, 
2019). O quadro a seguir mostra a relação das seções e anexos.
TÓPICO 3 — NORMAS E MODELOS DE SEGURANÇA
49
SEÇÃO DESCRIÇÃO
Seção 0: 
Introdução
explica o propósito da ISO 27001 e sua compatibilidade 
com outras normas de gestão.
Seção 1: Escopo explica que esta norma é aplicável a qualquer tipo de organização.
Seção 2: 
Referência 
normativa
refere-se a ISO/IEC 27000 como uma norma a partir da 
qual termos e definições são dados.
Seção 3: Termos e 
definições novamente, refere-se a ISO/IEC 27000.
Seção 4: Contexto 
da organização
esta seção é parte da etapa de planejamento (Plan) do 
ciclo PDCA e define requisitos para o entendimento de 
assuntos externos e internos, partes interessadas e seus 
requisitos, e a definição do escopo do SGSI.
Seção 5: 
Liderança
esta seção é parte da etapa de planejamento (Plan) do 
ciclo PDCA e define as responsabilidades da Alta Direção, 
estabelecendo papéis e responsabilidades, e o conteúdo 
da política de segurança da informação de alto nível.
Seção 6: 
Planejamento
esta seção é parte da etapa de planejamento (Plan) do 
ciclo PDCA e define requisitos para a avaliação de risco, 
tratamento de risco, Declaração de Aplicabilidade, plano 
de tratamento de risco, e define os objetivos de segurança 
da informação.
Seção 7: Apoio
esta seção é parte da etapa de planejamento (Plan) do ciclo 
PDCA e define requisitos de disponibilidade de recursos, 
competências, conscientização, comunicação e controle 
de documentos eregistros.
Seção 8: Operação
esta seção é parte da etapa execução (Do) do ciclo PDCA 
e define a implementação da avaliação e tratamento de 
risco, assim como controles e outros processos necessários 
para atingir os objetivos de segurança da informação.
Seção 9: Avaliação 
do desempenho
esta seção é parte da etapa verificação (Check) do ciclo 
PDCA e define requisitos para o monitoramento, medição, 
análise, avaliação, auditoria interna e análise crítica pela 
Direção.
Seção 10: 
Melhoria
esta seção é parte da etapa de atuação (Act) do ciclo 
PDCA e define requisitos para não conformidades, ações 
corretivas e melhoria contínua.
Anexo A
este anexo disponibiliza um catálogo de 114 controles 
(salvaguardas) distribuídos em 14 seções (seções de A.5 
até A.18).
QUADRO 11 – ISO/IEC 27001
FONTE: Adaptado de <https://advisera.com/27001academy/pt-br/o-que-e-a-iso-27001/>. Aces-
so em: 29 jun. 2020.
https://advisera.com/27001academy/pt-br/o-que-e-a-iso-27001/
50
UNIDADE 1 — DESENVOLVIMENTO DE SOFTWARE SEGURO
A figura a seguir mostra o processo de certificação ISO 27001 em alguns 
passos. 
FIGURA 19 – PASSOS PARA CERTIFICAÇÃO DA ISO 27001
FONTE: <https://www.tuv.com/brasil/br/seguran%C3%A7a-da-informa%C3%A7%C3%A3o-i-
so-27001.html>. Acesso em: 29 jun. 2020.
Quando uma organização garante a segurança dos seus sistemas e 
principalmente o tratamento adequado das informações cria uma vantagem 
competitiva para o seu negócio, e ainda está cumprindo padrões internacionais. 
Os outros benefícios são:
• Minimização de riscos de segurança, bem como a otimização das suas 
estruturas reduzindo os custos.
• Fornece um método estruturado e organizado para atender às necessidades 
de conformidade. 
• Aumento da confiança dos parceiros, cliente e público. 
• Detecção continua e sistemática das vulnerabilidades.
AUDITORIA PRÉ-AUDITORIA 
(OCUPACIONAL)
Avaliação realizada por 
auditores, Registro da atual 
situação no local.
Avaliação da documentação 
dos documentos do sistema de 
gestão.
A renovação da certificação é 
realizada antes de decorrerem 
três anos. Documentação do 
processo contínuo de melhoria.
Auditoria anual da otimização 
dos processos e da conformidade 
com as normas.
AUDITORIA DE 
ACOMPANHAMENTO
Certifica a conformidade com 
as normas e a confiabilidade. 
Registro na base de dados de 
certificação online. Certipedia.
AUDITORIA DE 
CERTIFICAÇÃO (NÍVEL 1)
RENOVAÇÃO DA 
CERTIFICAÇÃO
EMISSÃO DO 
CERTIFICADO
Avaliação da aplicação prática 
do sistema de gestão e da sua 
eficácia.
AUDITORIA DE
CERTIFICAÇÃO
(NÍVEL 2)
https://www.tuv.com/brasil/br/seguran%C3%A7a-da-informa%C3%A7%C3%A3o-iso-27001.html
https://www.tuv.com/brasil/br/seguran%C3%A7a-da-informa%C3%A7%C3%A3o-iso-27001.html
TÓPICO 3 — NORMAS E MODELOS DE SEGURANÇA
51
FIGURA 20 – BENEFÍCIOS DA IMPLEMENTAÇÃO DA ISO 27001
FONTE: <https://www.tuv.com/brasil/br/seguran%C3%A7a-da-informa%C3%A7%C3%A3o-i-
so-27001.html>. Acesso em: 29 jun. 2020.
Uma grande pergunta é: que tipo de empresa precisa da implementação 
da ISO 27001? A resposta é que a ISO 27001 engloba variados tipos de empresas 
já que permite a segurança e a eliminação ou redução dos riscos a informações 
garantindo a proteção dos softwares (FERREIRA, 2019).
FIGURA 21 – EMPRESAS QUE PRECISAM DA ISO 27001:2013
FONTE: <http://bit.ly/34yO4gP>. Acesso em: 29 jun. 2020.
Por quê?
Por quê? Por quê?
Por quê?
Reduza as possibilidades de 
falhas de segurança dentro do 
seu ambiente de segurança da 
informação.
Minimização de 
riscos, possíveis 
prejuízos e custos 
indiretos com 
a segurança da 
informação
Vantagem 
competitiva 
devido ao 
reconhecimento 
de norma
Aumento da confiança 
no que diz respeito a 
parceiros, clientes e 
públicos
Um método estruturado 
para atender às 
necessidades de 
conformidade
Cumprimento 
de requisitos 
internacionalmente 
reconhecidos
Deteção 
sistemática de 
vulnerabilidades
Custos mais 
reduzidos
Controle 
de riscos de 
segurança da 
informação
Confidencialidade 
das Informações
https://www.tuv.com/brasil/br/seguran%C3%A7a-da-informa%C3%A7%C3%A3o-iso-27001.html
https://www.tuv.com/brasil/br/seguran%C3%A7a-da-informa%C3%A7%C3%A3o-iso-27001.html
52
UNIDADE 1 — DESENVOLVIMENTO DE SOFTWARE SEGURO
Você pode fazer um diagnóstico para verificar os caminhos para a 
certificação da ISO 27001:2013 em https://consultoria.templum.com.br/diagnos-
tico-iso-27001-a/?utm_source=Blog&amp;utm_medium=banner-Empresas%20
que%20precisam%20da%20ISO%2027001%22%3E%3Cimg%20class=https://cer-
tificacaoiso.com.br/wp-content/uploads/2019/11/banner-iso-27001-wide.jpg&_
ga=2.144307894.203170364.1597668154-1141095468.1597668154.
DICAS
4 ISO/IEC 15408 
O Common Criteria for Information Technology Security Evaluation, ou Common 
Criteria, foi elaborado por diversos órgãos de países distintos com o objetivo de 
avaliar a segurança da tecnologia da informação. Esse padrão se tornou a norma 
ISO IEC 15408, que foi publicada em 2005 com o mesmo texto do Common Criteria. 
A ISO/IEC 15408 é um conjunto de critérios que permite a especificação 
da segurança de uma aplicação, baseado nas características do ambiente de 
desenvolvimento. A norma fornece um conjunto de requisitos comuns para 
as funções de segurança em produtos e sistemas e para garantia de medidas 
aplicadas a eles durante uma avaliação de segurança (CARVALHO, 2017).
O processo de avaliação estabelece um nível de confiança de que as 
funções de segurança desses produtos e dos sistemas e da garantia das medidas 
aplicadas para eles atendem a esses requisitos. Os resultados dessa avaliação 
podem auxiliar os consumidores a determinar se o produto ou sistema é seguro 
o suficiente para o que a sua aplicação se destina e se os riscos de segurança 
implícita em seu uso são toleráveis (CARVALHO, 2017; FERREIRA, 2019). 
Seu objetivo é ser usado como base para avaliação de propriedades de 
segurança de produtos e sistemas de Tecnologia da Informação (TI), permitindo 
a comparação entre os resultados de avaliações independentes de segurança, por 
meio de um conjunto de requisitos padronizados a ser atingidos. O processo de 
avaliação estabelece níveis de confiabilidade de que as funções avaliadas atingem 
os requisitos estabelecidos, ajudando os usuários a determinar se tais sistemas 
ou produtos possuem os níveis desejados de segurança e se os riscos advindos 
de seu uso são toleráveis. Seu público alvo são os desenvolvedores, avaliadores 
e usuários de sistemas e produtos de TI que requerem segurança. O padrão está 
dividido em três partes: 
• Introdução e modelo geral – onde são definidos os conceitos e princípios 
seguidos pelo modelo, além de uma nomenclatura e uma diagramação, 
baseada na orientação de objetos específicos para a formulação de objetivos 
https://consultoria.templum.com.br/diagnostico-iso-27001-a/?utm_source=Blog&amp;utm_medium=banner-Empresas que precisam da ISO 27001%22%3E%3Cimg class=https://certificacaoiso.com.br/wp-content/uploads/2019/11/banner-iso-27001-wide.jpg&_ga=2.144307894.203170364.1597668154-1141095468.1597668154
https://consultoria.templum.com.br/diagnostico-iso-27001-a/?utm_source=Blog&amp;utm_medium=banner-Empresas que precisam da ISO 27001%22%3E%3Cimg class=https://certificacaoiso.com.br/wp-content/uploads/2019/11/banner-iso-27001-wide.jpg&_ga=2.144307894.203170364.1597668154-1141095468.1597668154
https://consultoria.templum.com.br/diagnostico-iso-27001-a/?utm_source=Blog&amp;utm_medium=banner-Empresas que precisam da ISO 27001%22%3E%3Cimg class=https://certificacaoiso.com.br/wp-content/uploads/2019/11/banner-iso-27001-wide.jpg&_ga=2.144307894.203170364.1597668154-1141095468.1597668154
https://consultoria.templum.com.br/diagnostico-iso-27001-a/?utm_source=Blog&amp;utm_medium=banner-Empresas que precisam da ISO 27001%22%3E%3Cimg class=https://certificacaoiso.com.br/wp-content/uploads/2019/11/banner-iso-27001-wide.jpg&_ga=2.144307894.203170364.1597668154-1141095468.1597668154
https://consultoria.templum.com.br/diagnostico-iso-27001-a/?utm_source=Blog&amp;utm_medium=banner-Empresasque precisam da ISO 27001%22%3E%3Cimg class=https://certificacaoiso.com.br/wp-content/uploads/2019/11/banner-iso-27001-wide.jpg&_ga=2.144307894.203170364.1597668154-1141095468.1597668154
TÓPICO 3 — NORMAS E MODELOS DE SEGURANÇA
53
de segurança, para selecionar e definir seus requisitos e para especificações de 
altos níveis de produtos e sistemas. 
• Requisitos funcionais de segurança – estabelecendo um conjunto de elementos 
funcionais para a padronização dos requisitos divididos em classes, como 
gestão de segurança, privacidade e comunicação. 
• Requisitos da garantia de segurança – estabelecendo um conjunto de 
elementos para a padronização da garantia da segurança divididos ao longo 
do ciclo de desenvolvimento dos produtos ou sistemas.
54
UNIDADE 1 — DESENVOLVIMENTO DE SOFTWARE SEGURO
LEITURA COMPLEMENTAR
CONHEÇA 10 FRAMEWORKS QUE TORNAM MAIS RÁPIDO O 
DESENVOLVIMENTO DE SOFTWARES
Débora Gonçalves
Os frameworks para desenvolvimento de softwares representam algumas 
das ferramentas mais importantes para a criação de novos aplicativos e sistemas 
web. Eles ajudam a encapsular as funcionalidades de alto nível com maior 
agilidade e eficiência, reduzindo o tempo de trabalho das equipes de TI.
No entanto, você sabe quais são os principais frameworks existentes?
Neste artigo, listamos os 10 mais importantes, com base na aceitação e 
utilização pelos profissionais e gestores da área.
https://blog.cronapp.io/author/debora/
https://blog.cronapp.io/gestao-de-tempo/
TÓPICO 3 — NORMAS E MODELOS DE SEGURANÇA
55
1. SPRINGBOOT
O Springboot é a evolução do framework Spring. Apesar de existir há um 
bom tempo e ser famoso entre os desenvolvedores, sua evolução o deixou um 
pouco complexo. Agora, para definir um sistema, em vez de escrever diversos 
miniarquivos em XML no projeto, o usuário deve atuar diretamente nas anotações 
realizadas dentro do código-fonte.
Trata-se de um framework Model-View-Controller (MVC). Esse modelo de 
arquitetura tem, como objetivo, separar as representações das informações do 
usuário ao interagir com elas. Quem vai desenvolver um JavaScript com essa 
arquitetura, por exemplo, terá uma boa ferramenta em mãos, a qual oferece uma 
ampla gama de funcionalidades CRUD (Create, Read, Update, Delete).
As principais vantagens do Springboot envolvem o fato de que ele já 
define uma série de convenções de desenvolvimento e que todos conhecem bem 
como os objetos são nomeados e organizados na arquitetura.
É mais utilizado na parte de back-end de linguagens em JavaScript e indi-
cado para quem vai desenvolver um sistema web do tipo Representational State 
Transfer (REST), que visa disponibilizar aos usuários informações armazenadas 
no seu banco de dados ou back-end para facilitar a criação de aplicações direciona-
das a qualquer tipo de dispositivo (web ou mobile).
2. BOOTSTRAP
O Bootstrap é um framework mais direcionado para o aspecto visual das 
aplicações. Ele tem o poder de encapsular diversas funcionalidades de Cascading 
Style Sheets (CSS) que, juntas, vão contribuir para a criação de uma página bonita 
e com funcionalidades padronizadas. Como tem um apelo visual forte, torna-se 
intuitivo, deixando qualquer desenvolvedor à vontade e seguro no processo de 
criação.
É mais indicado para trabalhos no HTML5 e que visam agregar 
responsividade a interfaces, deixando as páginas adaptáveis a qualquer tamanho 
de tela de dispositivo. O mais importante é que a ferramenta faz tudo isso sem 
comprometer as funcionalidades, a estrutura e o layout do aplicativo.
Dessa forma, a mesma coisa vista ou feita em um celular pode ser 
transmitida a um tablet, computador ou monitor de TV. O usuário define as regras 
na sua interface e ela vai saber se adaptar automaticamente a esses diferentes 
tamanhos.
http://blog.algaworks.com/spring-boot/
http://getbootstrap.com/
https://blog.cronapp.io/app-responsivo/
https://blog.cronapp.io/app-responsivo/
56
UNIDADE 1 — DESENVOLVIMENTO DE SOFTWARE SEGURO
3. CORDOVA
O Cordova tem como objetivo simplificar e padronizar o desenvolvimento 
de aplicações híbridas para mobile. Como os códigos nativos de iOS e Android 
são bem diferentes, o framework atua compilando e traduzindo uma linguagem 
de HTML5, por exemplo, para a linguagem do sistema operacional utilizado no 
celular. Assim, a sua aplicação pode funcionar da mesma forma em qualquer 
dispositivo.
Por exemplo: se você desejar criar uma aplicação que seja híbrida e rode em 
diversos celulares, usar o framework open source do Cordova será uma alternativa 
eficiente, já que ele é exclusivo para criações do tipo mobile.
Para facilitar ainda mais, no site do Cordova, é possível encontrar 
bibliotecas de códigos prontos. Afinal, apesar das particularidades de cada marca 
e modelo de dispositivo, existem funcionalidades padrões e comuns entre eles, o 
que padroniza o acesso nos mais diversos aparelhos.
Funções como ligar a câmera e acionar o GPS, por exemplo, costumam 
ter códigos semelhantes entre os dispositivos e a ativação desses recursos acaba 
sendo igual para todos. Quando houver códigos em comum entre os aparelhos, o 
Cordova mostrará em sua biblioteca, permitindo o seu uso.
Dentre as principais vantagens, o Cordova se destaca por impulsionar 
a produtividade, uma vez que uma estrutura de códigos para múltiplas 
plataformas pode ser criada a partir de um bloco de notas — sem a necessidade 
de profissionais especializados e hardwares para cada plataforma. Além disso, 
a ferramenta é capaz de produzir aplicativos aptos para serem publicados nas 
Apps Stores, outro ponto positivo.
4. ANGULAR
Diferentemente dos frameworks para desenvolvimento mobile discutidos 
anteriormente, o Angular é utilizado especialmente para fazer a ligação entre 
o front-end e o back-end em web e desktop. Ele permite a criação de um modelo 
de aplicação baseado em Single Page Application (aplicação de página única) 
representado pela sigla SPA.
 
Nesse modelo de aplicação, o desenvolvedor traz para o browser uma 
imagem, como se fosse uma visão do back-end, na qual o usuário vai trabalhar. 
O angular faz com que a página trabalhe de forma automática, com um modelo 
próprio definido. Geralmente, esse framework é mais utilizado para projetos em 
HTML5.
https://cordova.apache.org/
https://blog.cronapp.io/investir-em-aplicativo-mobile/
https://angularjs.org/
TÓPICO 3 — NORMAS E MODELOS DE SEGURANÇA
57
5. REACT
O React é uma biblioteca de JavaScript muito utilizada pelos desenvolve-
dores para criar interfaces de usuário. Isso corresponde a visualizar as páginas no 
padrão Model-View-Controller e ser usado em combinação com outras bibliotecas 
de JavaScript ou frameworks no MVC, como o Angular.
Ele permite criar aplicações de grande porte para diversas finalidades 
na web, oferecendo flexibilidade para fazer alterações de maneira fácil ao longo 
do tempo. O objetivo do React envolve principalmente entregar velocidade, 
simplicidade e escalabilidade à produção de aplicações.
6. IONIC
O Ionic é um framework completo (Software Development Kits - SDK) de 
código aberto, utilizado principalmente para o desenvolvimento de aplicativos 
móveis híbridos. Ele fornece ferramentas e recursos de desenvolvimento baseados 
em tecnologias da Web, como CSS, HTML5 e Sass.
Seu diferencial é a ferramenta de construção de interface que é estruturada 
no modo de arrastar e soltar, tornando o trabalho muito mais intuitivo. Depois 
de prontas, as aplicações podem ser distribuídas por Apps Stores de aplicativos 
nativos para serem baixadas e instaladas em qualquer dispositivo.
7. MATERIAL DESIGN
Em 2014, o Google lançou um framework chamado material design. Trata-
se de uma evolução feita em cima do Bootstrap para apresentar um visual padrão 
do Google, ficando mais limpo e organizado.
Quem já está acostumado a trabalhar com o Gmail e Google Drive, por 
exemplo, se identificará facilmente com o framework, o que pode agradar muitos 
desenvolvedores. O objetivo do Material Design é tornar a página mais limpa e 
fácilde ser compreendida no browser.
8. FLUTTER
Trata-se de um framework de User Interface (UI) para dispositivos mobile, 
também desenvolvido pela Google. O objetivo é criar interfaces multiplataforma 
nativas de alta qualidade para os sistemas operacionais Android e iOS. Essa 
ferramenta gratuita trabalha com códigos open-source preexistentes e tem uma 
utilização bastante difundida nas organizações ao redor do mundo. O padrão 
visual das informações lembra muito os estilos do Material Design.
https://reactjs.org/
https://ionicframework.com/
58
UNIDADE 1 — DESENVOLVIMENTO DE SOFTWARE SEGURO
Para criar aplicações no Flutter, é preciso conhecer um pouco mais sobre 
a linguagem de programação Dart. A proposta, aqui, é entregar soluções AOT 
(Ahead of Time). Com isso, os códigos-fontes são compilados antes da execução 
das instruções.
Para tanto, utiliza-se o pacote Skia para renderização de imagens 2D. 
Desse modo, o carregamento dos apps, games e animações ocorre de uma ma-
neira mais leve e fluida. Isso melhora bastante os padrões de usabilidade e ex-
periência do usuário.
9. CORONA SDK
Esse é um framework grátis com desempenho rápido e suportado pelas 
linguagens de programação Lua e C++ nos sistemas operacionais Windows e 
MacOS. Ele foi criado pela companhia CoronaLabs, com base nas ferramentas de 
computação gráfica Box2D, OpenGL ES e OpenAL.
Além disso, o Corona SDK contém várias APIs para desenvolvimento 
multiplataforma nos ambientes Kindle Fire, iOS, Android e Nook Color. Assim, 
consegue-se criar aplicativos com mais praticidade, velocidade e flexibilidade.
Recomenda-se o Corona SDK para o desenvolvimento de games em 2D, 
chamadas de áudio, criptografia, GPS e widgets. Para tanto, pode-se utilizar dois 
modos de operação: Corona Simulator e Corona Native. Por meio do Simulator, 
é possível criar apps rapidamente com auxílio da interface gráfica. Já no modo 
Native, consegue-se integrar os códigos em Lua aos pacotes do Android Studio 
e Xcode.
10. JQUERY MOBILE
Um framework de desenvolvimento web via HTML5 e CSS3 adaptado 
para as interações touch. Trata-se de uma ferramenta portável capaz de rodar em 
vários dispositivos com diferentes sistemas operacionais com a mesma versão 
dos códigos-fontes. O JQuery Mobile tem duas variantes: a customizada e última 
versão estável. É possível também otimizar o funcionamento das aplicações por 
meio de bibliotecas e plugins.
Essa ferramenta utiliza muitas das funções da jQuery e jQuery UI. Com 
isso, consegue-se criar layouts responsivos com divisão em colunas, widgets, 
abas, toggles e sliders. 
O JQuery Mobile é compatível com tablets, dispositivos móveis 
e e-readers. Além disso, as aplicações também rodam nos sistemas desktop: 
MeeGo, Android, Blackberry, Palm WebOs, FireFox Mobile, iOs, Windows Phone 
7, Nokia/Sybian, Opera Mobile/Mini, Kindle e Nook.
https://flutter.dev/
https://coronalabs.com/blog/topics/corona-sdk/
https://jquerymobile.com/
TÓPICO 3 — NORMAS E MODELOS DE SEGURANÇA
59
Como você pode perceber, cada um desses frameworks pode ser utilizado 
em diferentes etapas do desenvolvimento da aplicação — o que tornaria muito 
difícil gerenciar o trabalho e aumentaria o tempo total de produção. Talvez 
você não saiba, mas existe uma ferramenta de orquestração para os frameworks 
utilizados, o que pode melhorar os níveis de produtividade dos times de TI.
Deste modo, os desenvolvedores de sua equipe não precisam conhecer 
cada framework em particular, pois têm tudo o que necessitam para criar 
aplicações em apenas um ambiente, sem se preocupar em alternar entre as opções 
manualmente. Se algo melhor e mais produtivo surgir no mercado, o provedor 
da ferramenta se encarrega de atualizar, adicionar ou substituir o framework para 
garantir sempre a qualidade da produtividade na plataforma.
Com a utilização das ferramentas mais adequadas e de acordo com a 
demanda, os gestores das equipes de TI têm a possibilidade de considerável 
redução de custos, além da otimização do tempo de desenvolvimento.
FONTE: <https://blog.cronapp.io/frameworks-para-desenvolvimento-de-softwa-
res/>. Acesso em: 9 dez. 2020.
https://www.cronapp.io/
https://blog.cronapp.io/frameworks-para-desenvolvimento-de-softwares/
https://blog.cronapp.io/frameworks-para-desenvolvimento-de-softwares/
60
RESUMO DO TÓPICO 3
Neste tópico, você aprendeu que:
• O SSE-CMM é um modelo de processo de referência, que tem por intuito 
levantar os requisitos para implementação de segurança em um sistema ou 
em uma série de sistemas.
• O SSE-CMM define a segurança como parte integrante da engenharia que 
trabalha com os problemas de segurança do hardware, software ou sistemas. 
• As práticas base do modelo SSE-CMM diretamente relacionadas à segurança 
são: Administração dos Controles de segurança, Avaliação do impacto, 
Avaliação dos riscos de segurança, Avaliação das ameaças, Avaliação das 
vulnerabilidades, Construção de argumentos de garantia, Coordenação 
da segurança, Monitoração da postura de segurança, Fornecer entrada de 
segurança, Especificar necessidades de segurança, Verificação e validação da 
segurança.
• As normas ISO/IEC 17799 e ISO/IEC 27001 são responsáveis em prover 
um modelo para estabelecer, implementar, operar, monitorar, analisar 
criticamente, manter e melhorar um Sistema de Gestão de Segurança da 
Informação. 
• A ISO 27001 é considerada uma norma internacional publicada pela ISO 
(International Standardization Organization) e tem como objetivo gerenciar 
a segurança da informação em uma organização.
• Um grande ponto a ser considerado é que o gerenciamento da informação 
também engloba o gerenciamento de processos, recursos humanos, proteção 
física, entre outros.
• A ISO/IEC 27001 é dividida em 11 seções e Anexo A. As seções de 0 a 3 são 
introdutórias e não obrigatórias, e as seções de 4 a 10 são obrigatórias.
• Quando uma organização garante a segurança dos seus sistemas e 
principalmente o tratamento adequado das informações cria uma vantagem 
competitiva para o seu negócio, e ainda está cumprindo padrões internacionais. 
• O Common Criteria for Information Technology Security Evaluation, ou Common 
Criteria, foi elaborado por diversos órgãos de países distintos com o objetivo 
de avaliar a segurança da tecnologia da informação.
61
Ficou alguma dúvida? Construímos uma trilha de aprendizagem 
pensando em facilitar sua compreensão. Acesse o QR Code, que levará ao 
AVA, e veja as novidades que preparamos para seu estudo.
CHAMADA
• A ISO/IEC 15408 é um conjunto de critérios que permite a especificação da 
segurança de uma aplicação, baseado nas características do ambiente de 
desenvolvimento. 
• O processo de avaliação estabelece um nível de confiança de que as funções 
de segurança desses produtos e dos sistemas e da garantia das medidas 
aplicadas para eles atendem a esses requisitos.
62
1 Quando uma organização garante a segurança dos seus sistemas e 
principalmente o tratamento adequado das informações cria uma vantagem 
competitiva para o seu negócio, e ainda está cumprindo padrões internacionais. 
Cite os outros benefícios.
2 O SSE-CMM define a segurança como parte integrante da engenharia que 
trabalha com os problemas de segurança do hardware, software ou sistemas. 
O objetivo é operar em um contínuo ciclo de avaliação do estado atual, 
efetivando melhorias contínuas e repetindo o ciclo (HOWARD; LIPNER, 2006; 
FERREIRA, 2019). Dessa forma, assinale a alternativa INCORRETA:
a) ( ) SSE-CMM é um modelo de processo de referência, que tem por intuito 
levantar os requisitos para implementação de segurança em um sistema 
ou em uma série de sistemas. 
b) ( ) O modelo foi elaborado para reduzir os gastos na produção de sistemas 
mais seguros e confiáveis. 
c) ( ) Na etapa de avaliação dos riscos de segurança é preciso identificar os 
riscos de segurança relacionados ao sistema em um ambiente definido.
d)( ) Na etapa das avaliação das vulnerabilidades é preciso identificar as 
ameaças de segurança, suas característicase propriedades.
3 A ISO/IEC 15408 é um conjunto de critérios que permite a especificação 
da segurança de uma aplicação, baseado nas características do ambiente de 
desenvolvimento. A norma fornece um conjunto de requisitos comuns para 
as funções de segurança em produtos e sistemas e para garantia de medidas 
aplicadas a eles durante uma avaliação de segurança (CARVALHO, 2017). 
Sobre o exposto, classifique V para as sentenças verdadeiras e F para as falsas:
 
( ) O processo de avaliação estabelece um nível de confiança de que as 
funções de segurança desses produtos e dos sistemas e da garantia das medi-
das aplicadas para eles atendem a esses requisitos.
( ) O processo de avaliação estabelece níveis de confiabilidade de que as 
funções avaliadas atingem os requisitos estabelecidos. 
( ) Requisitos funcionais de segurança estabelecem um conjunto de ele-
mentos funcionais para a padronização dos requisitos divididos em classes, 
como gestão de segurança, privacidade e comunicação.
( ) Requisitos da garantia de segurança estabelecem um conjunto de ele-
mentos para a padronização da garantia da segurança divididos ao longo do 
ciclo de desenvolvimento dos produtos ou sistemas.
 
Assinale a alternativa que apresenta a sequência CORRETA:
( ) V – V – V – V.
( ) V – F – V – V.
( ) F – F – V – V.
( ) V – V – F – V.
AUTOATIVIDADE
63
4 A ISO 27001 é considerada uma norma internacional publicada pela ISO 
(International Standardization Organization) e tem como objetivo gerenciar a 
segurança da informação em uma organização (FERREIRA, 2019). Assinale a 
alternativa CORRETA:
a) A versão mais recente desta norma foi publicada em 2013, sendo nomeada 
ISO/IEC 27001:2013.
b) O gerenciamento da informação não envolve o gerenciamento de processos, 
recursos humanos, proteção física, entre outros.
c) A ISO 27001 é um conjunto de critérios que permite a especificação da 
segurança de uma aplicação, baseado nas características do ambiente 
extrínseco. 
d) A ISO 27001 engloba variados tipos de empresas já que permite a segurança 
e a eliminação ou redução dos riscos à informações garantindo a proteção 
dos softwares.
64
REFERÊNCIAS
ALVES, G. A. Segurança da informação: uma visão inovadora da gestão. Rio de 
Janeiro: Ciência Moderna Ltda., 2006. 
BARTIE, A. Garantia da qualidade de software. Rio de Janeiro: Elsevier, 2002. 
BASU, A. Software quality assurance, testing and metrics. India: PHI Learning, 
2015. 
BEAL, A. Gestão estratégica da informação. São Paulo: Atlas, 2004. 
CARVALHO, E. T. R. de. Criação de um guia de boas práticas para desenvolvi-
mento seguro. Brasília: Universidade de Brasília, 2017. 
CUNHA, A. L.; PEISCHL, R. B. O valor das informações para as empresas e a 
importância da segurança da informação. Revista Anhanguera Educacional, 
Valinhos, São Paulo, v. 1, n. 1, p. 1-22, 2012.
FERNANDES, N. O. C. Segurança da informação. Mato Grosso: Universidade 
Federal do Mato Grosso, 2013.
FERREIRA, D. G. Arquitetura segura no desenvolvimento de software: abor-
dagem à plataforma digital U.OPENLAB. Portugal: Faculdade de Letras da 
Universidade do Porto, 2019. 
FERREIRA, F. N. F. Segurança da informação. Rio de Janeiro: Ciência Moderna, 
2003. 
FONTES, E. Políticas e normas para a segurança da informação. Rio de Janeiro: 
Brasport, 2011. 
FONTES, E. Praticando a segurança da informação. Rio de Janeiro: Brasport, 
2008.
FONTES, E. Segurança da informação: o usuário faz a diferença. São Paulo: 
Saraiva, 2006. 
GALITEZI, T. O custo da não qualidade. 2011. Disponível em: http://www.
galitezi.com.br/2012/02/teste-de-software-e-o-custo-da-nao.html. Acesso em: 14 
jun. 2020.
GOODRICH, M. T.; TAMASSIA, R. Introdução à segurança de computadores. 
Porto Alegre: Bookman, 2013.
http://www.galitezi.com.br/2012/02/teste-de-software-e-o-custo-da-nao.html
http://www.galitezi.com.br/2012/02/teste-de-software-e-o-custo-da-nao.html
65
GOMES, L. R. et al. Segurança no desenvolvimento de software. Curitiba: SER-
PRO – Serviço Federal de Processamento de Dados, 2014.
GRAHAM, D. et al. Foundations of software testing: ISTQB certification. Uni-
ted Kingdom: Cengage Learning EMEA, 2008. 
GURGEL, G. M. M. O valor estratégico da informação para a gestão das orga-
nizações. 2006. Disponível em: https://www.scielo.br/scielo.php?script=sci_art-
text&pid=S1807-17752004000100003. Acesso em: 4 jun. 2018.
HARTZ, M.; WALKER, E. Introduction to software reliability: a state of the art 
review. [S.l.]: The Center, 1996.
HOWARD, M.; LIPNER, S. The security development lifecycle: SDL, a process 
for developing demonstrably more secure software. EUA: Microsoft Press, 2006. 
KOLBE, A. Brasil teve mais de 1,6 bilhão de golpes pela internet em três me-
ses. 2020. Disponível em: http://bit.ly/3aA5mOm . Acesso em: 20 jun. 2020. 
KOSCIANSKI, A.; SOARES, M. Qualidade de software: aprenda as metodolo-
gias e técnicas mais modernas para o desenvolvimento de software. 2. ed. São 
Paulo: Novatec, 2007. 
LAUDON, K. C.; LAUDON, J. P. Sistemas de informação gerenciais. São Paulo: 
Prentice Hall, 2007. 
LYRA, M. R. Segurança e auditoria em sistemas de informação. Rio de Janeiro: 
Editora Ciência Moderna Ltda., 2008. 
LYU, M. R. Handbook of software reliability engineering. New York: McGraw-
-Hill, 1995. 
MCCARTHY, N. K. Resposta a incidentes de segurança em computadores – 
planos para proteção de informação em risco. Porto Alegre: Bookman, 2014.
MYERS, G. J. The art of software testing. New Jersey: John Wiley & Sons Inc., 
2004.
OLIVEIRA, J. P. M. de. Dados, informação e conhecimento. In: Dossier Infor-
mação: Revista Pequena e Media. 2018
PINHEIRO, J. M. dos S. Ameaças e ataques ao sistema de informação: prevenir e 
antecipar. Cadernos UniFOA, v. 3, n. 5, p. 11–21, 2007. 
PRESSMAN, R. S.; MAXIM, B. R. Engenharia de software: uma abordagem 
profissional. 8. ed. Porto Alegre: Bookman, 2016.
https://www.scielo.br/scielo.php?script=sci_arttext&pid=S1807-17752004000100003
https://www.scielo.br/scielo.php?script=sci_arttext&pid=S1807-17752004000100003
66
SÊMOLA, M. Gestão da segurança da informação: uma visão executiva. Rio de 
Janeiro: Campus, 2003. 
SILVA, C. J. O ciclo de vida de desenvolvimento seguro. 2017. Disponível em: 
https://portalgsi.com.br/2017/05/10/ciclo-de-vida-de-desenvolvimento-seguro-
-artigo-pentest-magazine/. Acesso em: 14 jun. 2020. 
SOMMERVILLE, I. Engenharia de software. 9. ed. São Paulo: Pearson, 2011.
SOMMERVILLE, I. Engenharia de software. 8. ed. São Paulo: Pearson Prentice 
Hall, 2008.
TANENBAUM, A. S.; WOODHULL, A. S. Sistemas operacionais: projetos e 
implementação. Porto Alegre: Bookman Editora, 2009. 
TORRES, N. A.; TORRES, M. G. ANS – Acordo de Nível de Serviço: para o 
sucesso da terceirização, é necessário que haja bons contratos que estabeleçam 
claramente os níveis de serviços combinados! São Paulo: Unicom Negócios, 
Processos e Sistemas, 2016. 
WALTRICK, R. Crimes virtuais trazem prejuízo bilionário para brasileiros. 
2016. Disponível em: http://bit.ly/2WrncLp. Acesso em: 19 jun. 2020. 
https://portalgsi.com.br/2017/05/10/ciclo-de-vida-de-desenvolvimento-seguro-artigo-pentest-magazine/
https://portalgsi.com.br/2017/05/10/ciclo-de-vida-de-desenvolvimento-seguro-artigo-pentest-magazine/
67
UNIDADE 2 — 
SEGURANÇA NO DESENVOLVIMENTO 
DE APLICAÇÕES WEB
OBJETIVOS DE APRENDIZAGEM
PLANO DE ESTUDOS
 A partir do estudo desta unidade, você deverá ser capaz de:
• conhecer os passos para o desenvolvimento seguro;
• compreender os principais tipos de vulnerabilidades;
• conhecer a taxonomia dos ataques; 
• assimilar as diferenças de prevenir ataques;
• analisar os tipos mais usuais de falhas e formas de prevenção.
 Esta unidade está dividida em três tópicos. No decorrer da unidade, 
você encontrará autoatividades com o objetivo de reforçar todo o conteúdo 
apresentado.
TÓPICO 1 – PRIMEIROS PASSOS PARA O DESENVOLVIMENTO SEGURODE APLICAÇÕES WEB 
TÓPICO 2 – ANÁLISE DE VULNERABILIDADE
TÓPICO 3 – SEGURANÇA DOS ARQUIVOS DO SISTEMA
Preparado para ampliar seus conhecimentos? Respire e vamos 
em frente! Procure um ambiente que facilite a concentração, assim absorverá 
melhor as informações.
CHAMADA
68
69
UNIDADE 2
1 INTRODUÇÃO 
O que todo desenvolvedor precisa considerar é que os softwares com 
problemas no desenvolvimento podem ser invadidos facilmente. Desse modo, 
é importante planejar quais informações serão expostas e quais os níveis de 
permissão de acesso aos recursos. 
A maioria das vulnerabilidades pode ser evitada quando pensada nas 
fases iniciais do desenvolvimento do software (MONTANHEIRO et al., 2017). O 
grande risco das vulnerabilidades é que possibilitam que atacantes roubem dados 
de usuários da aplicação, como mostrar detalhes das sessões de usuários nos 
endereços do site (URLs), sessões que não expiram ou tokens de acesso que não 
são invalidados ao se fazer logout (ANDERSON; BACKWOOD, 2004; CRESPO et 
al., 2004; ANDERSON, 2008). Portanto, é preciso desenvolver, além de modelar 
um sistema que não exponha dados desnecessários aos usuários, evitando esse 
tipo de falha.
Uma etapa a ser realizada no início do projeto é o mapeamento do cenário 
de utilização do software, além dos tipos de ataques que esse sistema pode receber 
(SOMMERVILLE, 2007). Um software de uso militar, por exemplo, poderá ser 
atacado por técnicas mais elaboradas do que se comparado a um aplicativo de 
bancário (PAYÃO, 2016). 
O que precisamos considerar é que todo software está sujeito a falhas, 
e, ainda, todos os dias é travada uma guerra entre usuários mal-intencionados 
e profissionais de segurança (PAYÃO, 2016; MARROW, 2019). Então, os 
TÓPICO 1 — 
PRIMEIROS PASSOS PARA O DESENVOLVIMENTO SEGURO 
DE APLICAÇÕES WEB
URLs: na rede mundial, significa enderece o site.
Tokens: chave de segurança que possibilita o acesso a ações e documentos com a ga-
rantia de autoria e integridade de informações.
Logout: desconectar; sair da sessão.
NOTA
UNIDADE 2 — SEGURANÇA NO DESENVOLVIMENTO DE APLICAÇÕES WEB
70
desenvolvedores precisam se manter atualizados a respeito dos riscos 
(MONTANHEIRO et al., 2017; MARROW, 2019).
2 FALHAS DURANTE O DESENVOLVIMENTO DO PROJETO 
A codificação inadequada de um projeto desenvolvido de um software 
pode ser resolvida por meio da utilização de padrões e convenções de codificação, 
garantindo a minimização de falhas (CARVALHO, 2017). 
Outro ponto importante é que os desenvolvedores precisam considerar 
o documento elaborado pelos analistas no levantamento dos requisitos e na 
modelagem do sistema (CARVALHO, 2017; FERREIRA, 2019). A importância 
desse documento é que ele mostra os tipos de ataques a que cada um dos 
recursos está sujeito, com isso, o desenvolvedor toma a decisão acerca do nível 
de implementação básica de segurança que cada recurso do software deve conter 
(FERNANDES, 2013; FERREIRA, 2019). 
No entanto, em situações em que o analista não elaborou o documento, é 
necessário que toda a equipe se reúna antes de iniciar a etapa de desenvolvimento 
(CARVALHO, 2017). No caso, é preciso considerar os stakeholders (colaboradores 
que possuem interesse na gestão do projeto ou na gestão da empresa), para que 
fique evidente em qual cenário o software será executado, além de considerar 
todos os tipos de ataques (FERNANDES, 2013; CARVALHO, 2017; FERREIRA, 
2019). 
FIGURA 1 – EQUIPE REUNIDA PARA ELABORAÇÃO DO DOCUMENTO
FONTE: <http://bit.ly/3myRXIM>. Acesso em: 19 maio 2020.
TÓPICO 1 — PRIMEIROS PASSOS PARA O DESENVOLVIMENTO SEGURO DE APLICAÇÕES WEB
71
Usualmente, as falhas ocorrem na entrada de dados. Quando não são 
tratadas de modo correto, permitem a inserção de códigos maliciosos (TORRES; 
TORRES, 2016; CARVALHO, 2017; FERREIRA, 2019). Desse modo, é essencial que 
toda entrada de dados seja tratada e que se usem as bibliotecas de autossanitização 
de páginas. Estas, conforme Carvalho (2017, p. 22), “[...] são focadas em segurança, 
garantindo que entradas não sejam mal interpretadas pelos navegadores, com 
isso, possibilitam que os desenvolvedores anulem as tentativas de ataques à 
aplicação”.
FIGURA 2 – EXEMPLIFICAÇÃO DE INSERÇÃO DE CÓDIGO MALICIOSO
FONTE: <http://bit.ly/3nJ6yD0>. Acesso em: 19 maio 2020.
Mitre (PANDEY, 2011), em parceria com a Networking and Security 
(SANS), desenvolveu o Common Weakness Enumeration (CWE/SANS) Top 25 
(MARTIM et al., 2011), que apresenta os 25 erros mais perigosos de software. 
Conforme Martim et al. (2011), os erros aparentados são descritos como perigosos 
devido à:
Código malicioso é um tipo de código de computador ou script da web nocivo 
que tem, como objetivo, criar vulnerabilidades no sistema, gerando backdoors, violações 
de segurança, roubo de dados e informações, além de outros danos possíveis nos sistemas 
de arquivos e computadores. É um tipo de ameaça que o software antivírus pode não 
conseguir bloquear sozinho. 
O código permite que um criminoso virtual não autorizado acesse remotamente o sistema 
invadido; isso é chamado de backdoor do aplicativo. Depois, expõe dados confidenciais da 
empresa. Dessa maneira, os criminosos podem até limpar os dados de um computador ou 
instalar spyware.
NOTA
UNIDADE 2 — SEGURANÇA NO DESENVOLVIMENTO DE APLICAÇÕES WEB
72
• Frequência de ocorrência.
• Facilidade de encontrar.
• Facilidade de explorar.
• Frequência com que um atacante tenha o controle total do software, roube 
informações ou cause a paralização do software.
O uso da CWE/SANS Top 25 pode ser um treinamento e conscientização 
dos desenvolvedores, para que eles impeçam erros mais usuais de implementação 
de software (MARTIM et al., 2011; PANDEY, 2011).
QUADRO 1 – RELAÇÃO DOS 25 ERROS MAIS USUAIS DE IMPLEMENTAÇÃO DE SOFTWARES
FONTE: Adaptado de Martim et al. (2011)
POSIÇÃO NOME 
1 Validação imprópria de elementos usados em comandos SQL 
2 Validação imprópria de elementos usados em comandos do sis-tema operacional 
3 Cópia de buffer sem verificar o tamanho da entrada 
4 Validação imprópria de entrada de dados durante a geração da página web 
5 Falta de autenticação em funções críticas 
6 Falta de autorização 
7 Informações credenciais explícitas no código 
8 Falta de criptografia de dados sensíveis 
9 Falta de restrições no upload de arquivos 
10 Confiança em entradas inseguras na tomada de decisão 
11 Execução com privilégios desnecessários 
12 Cross-Site Request Forgery (CSRF) 
13 Limitação imprópria do caminho ao acesso a diretórios restritos 
14 Falta de verificação de integridade no download do código 
15 Autorização incorreta 
16 Inclusão de funcionalidades de locais remotos não confiáveis 
17 Atribuição incorreta de permissões para recursos críticos 
18 Uso de funções potencialmente perigosas 
19 Uso de algoritmo fraco de criptografia 
20 Cálculo incorreto do tamanho do buffer 
21 Restrição imprópria de tentativas excessivas de autenticação 
22 Redirecionamento para URLs não confiáveis 
23 Falta de controle na formatação de String 
24 Overflow de inteiros 
25 Uso inseguro da função de hash 
TÓPICO 1 — PRIMEIROS PASSOS PARA O DESENVOLVIMENTO SEGURO DE APLICAÇÕES WEB
73
Você ficou com dúvida acerca de algum termo mencionado no Quadro 1? 
Então, leia o exposto a seguir.
O documento segmenta esses 25 erros em três categorias: 
• Categoria interação insegura entre componentes: representa os modos 
inseguros de envio e recebimento dos dados entre componentes, processos, 
programas etc. (MARTIM et al., 2011; PANDEY, 2011). 
• Gerenciamento inadequado de recursos: representa as situações em que o 
software não gerencia, de modo correto, a criação, utilização, transferência 
ou destruição de recursos do sistema (MARTIM et al., 2011; PANDEY, 2011).
• Configurações inseguras: representam as técnicas defensivas mal configuradas 
que podem sofrer alterações (MARTIM et al., 2011; PANDEY, 2011). 
• Buffer: região de memória física utilizada para armazenar temporaria-
mente os dados enquanto eles estão sendomovidos de um lugar para outro.
• Buffer overflow: transbordamento de dados acontece quando um programa infor-
mático excede o uso de memória assignado a ele pelo sistema operacional, passan-
do, então, a escrever no setor de memória contíguo. 
• Cross-Site Request Forgery (CSRF): falsificação de solicitação entre sites, também 
conhecido como ataque de um clique ou montagem de sessão. É um tipo de códi-
go malicioso de um website, no qual comandos não autorizados são transmitidos a 
partir de um usuário em quem a aplicação web confia.
• Hash: um algoritmo que mapeia dados de comprimento variável para dados de 
comprimento fixo. 
• SQL: Structured Query Language, ou seja, linguagem de consulta estruturada. Utili-
zada para fazer consultas em bancos de dados.
• String: Expressão contendo qualquer caracter alfanumérico, formando ou não pala-
vras.
NOTA
UNIDADE 2 — SEGURANÇA NO DESENVOLVIMENTO DE APLICAÇÕES WEB
74
QUADRO 2 – AS TRÊS CATEGORIAS GERAIS PROPOSTAS POR CWE/SANS TOP 25
FONTE: Adaptado de Pilz e Gatti (2013)
CATEGORIA INTERAÇÃO INSEGURA ENTRE COMPONENTES 
Posição Nome 
1 Validação imprópria de elementos usados em comandos SQL 
2 Validação imprópria de elementos usados em comandos do sistema operacional 
4 Validação imprópria de entrada de dados durante a geração da página web 
9 Falta de restrições no upload de arquivos 
12 Cross-Site Request Forgery (CSRF) 
22 Redirecionamento para URLs não confiáveis 
CATEGORIA GERENCIAMENTO INADEQUADO DE RECURSOS
3 Cópia de buffer sem verificar o tamanho da entrada 
13 Limitação imprópria do caminho ao acesso a diretórios restritos 
14 Falta de verificação de integridade no download do código 
16 Inclusão de funcionalidades de locais remotos não confiáveis 
18 Uso de funções potencialmente perigosas 
20 Cálculo incorreto do tamanho do buffer 
23 Falta de controle na formatação de String 
24 Overflow de inteiros 
CATEGORIA CONFIGURAÇÕES INSEGURAS
5 Falta de autenticação em funções críticas 
6 Falta de autorização 
7 Informações credenciais explícitas no código 
8 Falta de criptografia de dados sensíveis 
10 Confiança em entradas inseguras na tomada de decisão 
11 Execução com privilégios desnecessários 
15 Autorização incorreta 
17 Atribuição incorreta de permissões para recursos críticos 
19 Uso de um algoritmo fraco de criptografia 
21 Restrição imprópria de tentativas excessivas de autenticação 
25 Uso de função de hash fraca 
TÓPICO 1 — PRIMEIROS PASSOS PARA O DESENVOLVIMENTO SEGURO DE APLICAÇÕES WEB
75
3 TAXONOMIA DE ATAQUES WEB 
O ataque em uma aplicação representa explorar determinada vulnerabili-
dade, conforme vimos no item anterior deste tópico. Então, agora, compreende-
remos os ataques direcionados a aplicações. Para isso, é preciso analisar a figura a 
seguir, que mostrará um ataque empregando uma ou mais técnicas (ALMEIDA, 
2012; CARVALHO, 2017). 
O objetivo de uma tentativa maliciosa em aplicações web pode ser alcan-
çado por meio das técnicas de ataque (ALMEIDA, 2012). Elas não são exclusivas 
de somente um ataque em função de muitas tentativas maliciosas combinarem 
múltiplas técnicas (ALMEIDA, 2012; PILZ; GATTI, 2013).
FIGURA 3 – REPRESENTAÇÃO DA TAXONOMIA DE ATAQUES
FONTE: Almeida (2012, p. 11)
Conforme Almeida (2012, p. 12), os ataques são divididos em três 
categorias: 
• Passagem manipulada de parâmetros: os parâmetros de entrada de 
uma aplicação são modificados ou manipulados. Geralmente, os 
parâmetros em aplicações web são encaminhados para o servidor 
através dos métodos Get ou Post. Nessa situação, o atacante 
pode ter benefícios, tendo acesso a informações e alterando 
os parâmetros na URL ou dentro do formulário Linguagem de 
Marcação de HiperTexto (HTML) da aplicação. Os atacantes 
UNIDADE 2 — SEGURANÇA NO DESENVOLVIMENTO DE APLICAÇÕES WEB
76
usam a passagem manipulada de parâmetros para ocasionar 
erros e descobrir a aplicação e seu banco de dados. A passagem 
manipulada de parâmetros normalmente é efetuada combinando 
o emprego de técnicas de SQL Injetion, parametrização de URL e 
codificação de caracteres na URL.
• Captura de dados: o objetivo é capturar os dados armazenados em 
uma aplicação para diversos fins. Esse tipo de ataque, geralmente, 
combina técnicas Coss-Site-Scripting XSS e Code Injection ou 
mesmo de SQL Injection. 
• Desfiguração: o objetivo é ocasionar modificação visual em 
uma ou mais páginas de um sistema ou website. Normalmente, 
a alteração ocorre na página principal. No caso, o dano visual 
gerado pelo ataque expõe uma imagem negativa para a 
organização mantenedora do website. A desfiguração pode ser 
aplicada através da técnica de Cross Site Scripting (XSS). 
Conforme Pilz e Gatti (2013, p. 28), “[...] há, ainda, outro modo de classificar 
os ataques, sendo os ataques passivos e ataques ativos”. 
FIGURA 4 – FLUXO NORMAL (A), ATAQUES PASSIVOS (C) E ATIVOS (B, D, E)
FONTE: Sofron e Tutanescu (2003, p. 266 apud PILZ; GATTI, 2013, p. 21)
Os ataques passivos estão relacionados com a violação das regras de 
confidencialidade e não causam danos, ou seja, não excluem ou alteram dados. 
Já os ataques ativos são caracterizados por serem mais perigosos, por alterarem o 
status dos dados, computadores ou sistemas de comunicação (ALMEIDA, 2012; 
PILZ; GATTI, 2013; CARVALHO, 2017). Os principais tipos de ataques ativos são: 
TÓPICO 1 — PRIMEIROS PASSOS PARA O DESENVOLVIMENTO SEGURO DE APLICAÇÕES WEB
77
• Interceptação: utilizam respostas de uma mensagem ou parte dela para 
realizar um acesso não autorizado. 
• Modificação: modificam, por meio da inserção e/ou exclusão de caracteres, 
uma parte ou todo o dado transmitido.
• Desinformação: quando um usuário não autorizado diz ser um usuário 
autorizado. 
Conforme Carvalho (2017), existem quatro tipos mais comuns de ameaças 
que podem ser ocasionadas por criminosos virtuais. 
QUADRO 3 – AMEAÇAS VIRTUAIS
FONTE: Adaptado de Almeida (2012) e Carvalho (2017)
Agora, você poderá analisar as principais técnicas usadas em ataques a 
aplicações web. 
QUADRO 4 – TÉCNICAS DE ATAQUES
DENOMINAÇÃO CARACTERÍSTICAS
Hackers maliciosos Indivíduos que invadem sistemas de computadores sem autorização. 
Código malicioso
Causa danos sérios e interrupções de alguns aplicativos 
a redes inteiras. Ainda, possuí alto custo de reparação 
de danos.
Sabotagem de 
funcionários ou 
espionagem
Funcionários que trabalham de modo direto com os 
sistemas e podem provocar danos significativos por 
terem informações e conhecimento específico dos 
sistemas. 
Ameaças à 
privacidade pessoal 
ou da empresa
São motivadas de preocupação, pois os computadores 
ou as tecnologias armazenam muitas informções dos 
empregados, regras de negócio, dados financeiros 
e outras informações que podem causar danos 
econômicos ou de imagem. 
TÉCNICAS DESCRIÇÃO
SQL 
Injection
A técnica SQL Injection explora fragilidades em aplicações 
web que recebem strings, ou até mesmo pedaços de strings que 
tenham comandos da linguagem SQL. Esses códigos oriundos 
do cliente se incorporam nas strings de consultas a banco de 
dados, formando instruções não esperadas pela programação.
UNIDADE 2 — SEGURANÇA NO DESENVOLVIMENTO DE APLICAÇÕES WEB
78
Code 
Injection
Na técnica Code Injection, os códigos injetados são do tipo ser-
ver-side. Se um atacante emprega um código Hypertext Pre-
processor (PHP), usa-se a nomenclatura PHP Injection. Essa 
definição tem, por base, a linguagem server-side, na qual a 
aplicação-alvo foi elaborada, desse modo, podemos ter Active 
Server Pages Injection (ASP), Practical Extraction and Report 
Language Injection (PERL) etc. Ataques que utilizam essas téc-
nicas trazem danos severos à aplicação: informações sigilosas, 
além da negação de serviços com a inoperância da aplicação 
mediante a inserção de scripts maliciosos.
Codificação 
de caractere
Codificação de caractere é uma técnica utilizada em ataques do 
tipo Passagem Manipulada de Parâmetro. O atacante usa códi-
gos Unicode (URL-encode) nos caracteres enviados ao servidor.
Revelaçãode 
estrutura
Variação da técnica de SQL Injection que insere caracteres e 
strings que se adaptam à string de consulta ao banco interno 
da aplicação, causando erros que mostram a estrutura de tabe-
las, com a sequência de campos e seus tipos. 
Autenticação 
indevida de 
usuário
Aplicações, geralmente, possuem uma interface pública, e uma 
restrita a usuários que precisam fazer a autenticação. Na inter-
face pública, os usuários externos possuem acesso a serviços 
e informações ofertados pela organização. Entretanto, na in-
terface restrita, a organização mantenedora do sistema solicita 
que os administradores do conteúdo façam a autentificação. No 
caso, geralmente, usa-se um módulo de login para autenticar 
esses usuários. Então, uma técnica de autenticação indevida de 
usuário consegue acesso não autorizado a essa interface restri-
ta. Em muitas aplicações que são vulneráveis a ataques, é possí-
vel obter acesso como um usuário válido através da técnica de 
SQL Injection ao inserir strings apropriadas para se adaptarem 
às strings internas de consulta que autenticam usuários. 
Manipulação 
de registros 
em tabelas
Aplicações possíveis de ataques de validação de entrada de parâ-
metros permitem a manipulação de registros. No caso, é possível 
incluir novos registros ou mudar campos dos registros existentes, 
porém, essa é uma variação que se segue após revelada a estru-
tura da tabela, pois, com esse conhecimento, o atacante poderá 
montar uma string a ser injetada no interior da string de consulta 
da aplicação para incluir, alterar ou excluir registros da tabela. 
Recuperação 
de conteúdos
Para recuperar dados das organizações, os atacantes exploram 
as vulnerabilidades dos drivers de conexão com as do ban-
co, expondo os conteúdos de determinados tipos de campos 
quando encontrada uma condição de erro. Normalmente, 
os campos alfanuméricos armazenados nesses bancos são os 
mais vulneráveis a esse tipo de problema. 
Interrupção 
de serviços
A destruição de informações pode comprometer os serviços 
de um sistema, porém, a utilização de injeções de SQL permi-
te uma suspensão ou interrupção de serviços, em função do 
emprego de comandos Data Control Language (DCL) usados 
pelos administradores de banco de dados para a suspenção do 
serviço do banco de dados. 
FONTE: Adaptado de Almeida (2012)
TÓPICO 1 — PRIMEIROS PASSOS PARA O DESENVOLVIMENTO SEGURO DE APLICAÇÕES WEB
79
4 TESTES DE SEGURANÇA NAS APLICAÇÕES ESSENCIAIS 
Conforme Montanheiro et al. (2017, p. 35), “[...] as práticas de testes 
automatizados possuem o objetivo de melhorar a qualidade do software 
desenvolvido, sendo aliadas à segurança de um sistema. Isso ocorre já que um 
código bem desenvolvido terá menos falhas que podem gerar vulnerabilidades”. 
O Test Driven Development (TDD), ou Teste de Desenvolvimento Orientado, 
é considerado uma metodologia de desenvolvimento de software que incorpora 
o desenvolvimento orientado a testes (MONTANHEIRO et al., 2017; MARROW, 
2019). Segue a rotina de desenvolvimento com TDD. No primeiro momento, 
baseia-se em escrever um teste com os requisitos da função a ser desenvolvida 
(MONTANHEIRO et al., 2017; FERREIRA, 2019). Posteriormente, esse teste irá 
falhar, já que ainda não existe função desenvolvida para atender às condições 
daquele teste, sendo, então, realizada a codificação da função, com o objetivo 
de cumprir todos os requisitos estabelecidos no teste (FERNANDES, 2013; 
CARVALHO, 2017; FERREIRA, 2019). Após a função completa, é efetuada a 
refatoração do código para eliminar todas as redundâncias e funções que podem 
ser exploradas pelos atacantes (MARROW, 2019). 
FIGURA 5 – EXEMPLIFICAÇÃO DO TESTE DE DESENVOLVIMENTO ORIENTADO (TDD)
FONTE: <https://bit.ly/3hceESc>. Acesso em: 19 jun. 2020.
O mais aconselhado para encontrar falhas e minimizar a possibilidade 
de ataques nas aplicações é a revisão de todo código-fonte escrito. Essa etapa 
é fundamental para garantir qualidade desejada no software desenvolvido 
(ALMEIDA, 2012; CARVALHO, 2017). 
Outro modo de testar um software desenvolvido é por meio de scanners 
automatizados com o objetivo de encontrar as falhas de segurança nas aplicações 
(BALTAZAN, 2012; PAYÃO, 2016; CARVALHO, 2017). O uso desses scanners 
UNIDADE 2 — SEGURANÇA NO DESENVOLVIMENTO DE APLICAÇÕES WEB
80
deve ser realizado com muita atenção, já que esse tipo de teste, geralmente, fornece 
falsos positivos e negativos, evidenciando falhas que não existem e permitindo 
que passem as falhas existentes (MONTANHEIRO et al., 2017). Desse modo, é 
importante o uso de vários scanners, além da conferência manual dos resultados 
mostrados, para comprovar a realidade. 
Conforme Montanheiro et al. (2017, p. 32), “[...] grande parte dos ataques 
na internet é realizada por indivíduos conhecidos como “Script Kiddie”, 
geralmente, dispondo de conhecimento superficial, já que há ferramentas prontas 
para fazer os ataques”. Portanto, é indicado que os desenvolvedores conheçam as 
principais ferramentas automatizadas de invasão de sistemas (ALMEIDA, 2012; 
FERNANDES, 2013; CARVALHO, 2017; MONTANHEIRO et al., 2017). Isso gera 
ações proativas de segurança e uma redução significativa das possibilidades de a 
aplicação ser invadida. 
FIGURA 6 – REPRESENTAÇÃO DO SCRIPT KIDDIE
FONTE: <https://bit.ly/2KlxRVw>. Acesso em: 19 jun. 2020.
TÓPICO 1 — PRIMEIROS PASSOS PARA O DESENVOLVIMENTO SEGURO DE APLICAÇÕES WEB
81
Observe as causas que levam a uma falha de segurança: 
QUADRO 5 – CAUSAS MAIS COMUNS DE FALHAS DE SEGURANÇA
O script kiddie é alguém que procura por um alvo fácil, tendo, como ob-
jetivo, acessar a conta do administrador de uma máquina (root) de modo fácil. Assim, a 
técnica usada foca em ações, em um pequeno número de falhas (exploits), e busca, na 
internet, até encontrar uma máquina vulnerável.
NOTA
Not a Security Bug Acredita-se que seja uma falha de segurança, mas não é.
Buffer Overflow/
Underflow
Violação de segurança de memória que ocorre quando 
não é verificado ou limitado o tamanho de memória 
que precisa ser alocada antes que as informações sejam 
manipuladas ou processadas por um software. 
Overflow quando um programa ultrapassa os limites do 
buffer e sobrescreve a memória adjacente.
Underflow ocorre quando um buffer é lido ou esvaziado 
antes de ser reescrito ou preenchido.
Arithmetic Error 
Ocorre quando o valor de algum dado excede (overflow) 
ou não alcança (underflow) o limite em que foi especificado 
para ser manipulado.
SQL/Script Injection 
Falha que permite, aos usuários mal intencionados, 
modificarem o comportamento de alguma ação do 
sistema, alterando o código-fonte do programa ou de 
uma instrução Structured Query Language (SQL) ao banco 
de dados da aplicação.
Directory Traversal Permite, aos usuários, acessarem diretórios e executarem comandos fora do local especificado.
Race Condition Ocorre quando um software comete erros de sincronia ou sequenciamento de ações.
Cross-Site Scripting 
Permite, ao “invasor”, acesso indevido a recursos ou 
informações do site, injetando códigos maliciosos no 
sistema e que podem afetar todos os usuários que estejam 
visualizando o site.
Cryptographic We-
akness 
Uso insuficiente ou incorreto de criptografia na proteção 
aos dados.
Weak Authentication Códigos ou controles insuficientes para determinar a autenticidade do usuário que já está logado no sistema.
UNIDADE 2 — SEGURANÇA NO DESENVOLVIMENTO DE APLICAÇÕES WEB
82
Inappropriate Per-
mission 
Acesso a dados ou recursos que exigiriam login e 
senha, sem estar logado no sistema, acessando dados 
confidenciais sem estar credenciado. 
Ineffective Secret 
Hiding
Falha causada pela insuficiente ou incorreta proteção de 
chaves e senhas do sistema.
Unlimited Resource 
Consumption 
Também conhecido por DoS, é um erro causado pela não 
verificação ou limitação dos recursos, permitindo que 
um invasor esgote os recursos disponíveis.
Incorrect/No Error 
Messages 
Falha causada pela ausência ou incorreta utilização das 
mensagensde erro.
Incorrect/
No Pathname 
Canonicalization 
Causado pela passagem de um usuário mal intencionado 
pelas restrições de localização ou de nomes.
Um cenário usual de ataque ocorre em sites que usam o gerenciador de 
conteúdo WordPress. Este foi elaborado para que pessoas com pouco conhecimento 
conseguissem desenvolver e administrar os blogs. Devido à facilidade de uso, surgiram 
extensões que rodam até uma loja virtual dentro do sistema de blogs. No entanto, muitas 
dessas extensões possuem falhas na codificação e expõem o sistema a vulnerabilidades 
(MARROW, 2019).
NOTA
FONTE: Adaptado de Almeida (2012), Carvalho (2017) e Montanheiro et al. (2017)
5 CUIDADOS A SEREM TOMADOS NA IMPLANTAÇÃO 
Na etapa de implementação do software, é preciso elaborar um plano 
de ação com o detalhamento de como a equipe tratará uma possível descoberta 
de vulnerabilidade ou a ocorrência de um ataque (ANDERSON; BACKWOOD, 
2004; CRESPO et al., 2004; CARVALHO, 2017). Isso se faz necessário para que a 
equipe responda rápido e aplique as correções mais adequadas. 
É recomendado, ainda, que o servidor que irá rodar a aplicação 
desenvolvida tenha instalado somente o necessário para que a aplicação funcione 
de modo adequado (MONTANHEIRO et al., 2017; MARROW, 2019). Outro ponto 
importante em relação ao servidor é a alocação, sendo recomendado um servidor 
para o banco de dados e, o outro, para executar a aplicação (MONTANHEIRO 
et al., 2017). A atualização desses servidores é essencial para evitar que as falhas 
encontradas em softwares possam ser exploradas. 
TÓPICO 1 — PRIMEIROS PASSOS PARA O DESENVOLVIMENTO SEGURO DE APLICAÇÕES WEB
83
A configuração adequada do servidor é primordial para que sejam 
evitados os vetores de ataque. Além disso, é aconselhável, para servidores Linux, 
que não utilizem senha para fazer login no SSH, mas a utilização de um par de 
chaves, pública e privada, conhecido como SSH key (BALTAZAN, 2012; PAYÃO, 
2016; DEVMEDIA, 2017). 
O uso e a configuração adequada de firewalls em nível de aplicação e de 
rede em ambientes de produção são essenciais para negar muitas solicitações, 
realizadas, muitas das vezes, por scanners, à procura de vulnerabilidades e portas 
abertas que possam ser pontos de ameaça (PAYÃO, 2016; DEVMEDIA, 2017). 
Conforme Montanheiro et al. (2017), há sistemas automatizados que são 
capazes de detectar e bloquear ataques em serviços web com base em anomalias 
do tráfego de rede dos servidores.
Agora, entenderemos a importância desses cuidados na implementação 
do software por meio de exemplos de ataques que ocorreram recentemente. 
O primeiro exemplo de ataque ocorreu em 2016, quando três hackers 
desenvolveram a botnet Mirai, que controlou vários dispositivos de internet das 
coisas com senhas padrões. Esse ataque afetou, principalmente, câmeras IPs e 
roteadores domésticos, transformando os equipamentos em zumbis e utilizando 
os recursos de rede para ataques de negação de serviço distribuídos (KLEINA, 
2018). Os ataques de negação de serviço são realizados com o objetivo de inutilizar 
sistemas, deixando-os indisponíveis. Isso ocorre em função da invalidação 
de servidores por sobrecarga, como quando a Sony PlayStation Network e a 
Microsoft Xbox Live ficaram fora do ar um bom tempo em decorrência desses 
ataques, em 2016 (PAYÃO, 2016).
Com relação a esse ataque, o primeiro relatório público, em agosto 
de 2016, gerou pouca atenção, e o Mirai ficou nas sombras até em meados de 
setembro (PAYÃO, 2016; KLEINA, 2018; MARROW, 2019). O seu destaque veio 
quando foi utilizado para fazer ataques DDoS massivos contra Krebs on Security, 
sendo atingidas mais de 6,8 mil câmeras (câmeras de segurança e webcams) e, 
no processo, mais de 15 mil dispositivos estavam envolvidos (KLEINA, 2018; 
MARROW, 2019).
UNIDADE 2 — SEGURANÇA NO DESENVOLVIMENTO DE APLICAÇÕES WEB
84
FIGURA 7 – FUNCIONAMENTO DO MIRAI
FONTE: <http://bit.ly/2XVJZ2I>. Acesso em: 19 jun. 2020.
Embora o Mirai estivesse nas sombras em agosto de 2016, é possível 
observar, por meio da telemetria, que ele se ativou no início de agosto, quando a 
infecção iniciou em um único IP de hospedagem (PAYÃO, 2016; KLEINA, 2018; 
MARROW, 2019). Depois, o Mirai se espalhou de modo rápido, dobrando de 
tamanho a cada 76 minutos nas primeiras horas. No fim do primeiro dia, já havia 
infectado mais de 65.000 dispositivos IoT e, no segundo dia, já era responsável por 
metade de todas as varreduras de telnet da internet (KLEINA, 2018; MARROW, 
2019). 
GRÁFICO 1 – NÚMERO DE ATAQUES DO MIRAI
FONTE: <https://blog.cloudflare.com/inside-mirai-the-infamous-iot-botnet-a-retrospective-a-
nalysis/>. Acesso em: 19 jun. 2020.
https://blog.cloudflare.com/inside-mirai-the-infamous-iot-botnet-a-retrospective-analysis/
https://blog.cloudflare.com/inside-mirai-the-infamous-iot-botnet-a-retrospective-analysis/
TÓPICO 1 — PRIMEIROS PASSOS PARA O DESENVOLVIMENTO SEGURO DE APLICAÇÕES WEB
85
Em 26 de novembro de 2016, a Deutsche Telekom, umas das maiores 
provedoras de internet da Alemanha, sofreu uma grande indisponibilidade 
depois que 900.000 dos seus roteadores foram comprometidos pelo Mirai. As 
variantes da Mirai são ainda encontradas, sendo que, em 26 de janeiro de 2018, 
foram identificadas variantes que eram capazes de infectar roteadores da marca 
D-Link, burlando o sistema de autenticação e permitindo a execução remota de 
códigos arbitrários (KLEINA, 2018; FERREIRA, 2019; MARROW, 2019). 
FIGURA 8 – ROTEADORES DA MARCA D-LINK
FONTE: <http://bit.ly/34D5EQV>. Acesso em: 19 jun. 2020.
Outro exemplo ocorreu em fevereiro de 2018, quando foi identificada 
uma vulnerabilidade de configuração incorreta na aplicação Memcached. Este 
é considerado um sistema de armazenamento em cachê de objetos de memória 
distribuída de código aberto e gratuito, de natureza genérica, mas destinado à 
utilização para a aceleração de aplicativos da web dinâmicos, aliviando a carga 
do banco de dados (FERREIRA, 2019; MARROW, 2019). 
UNIDADE 2 — SEGURANÇA NO DESENVOLVIMENTO DE APLICAÇÕES WEB
86
FONTE: <https://www.portalgsti.com.br/memcached/sobre/>. Acesso em: 19 jun. 2020. 
No ataque da Memcached, aproximadamente 51 mil servidores estavam 
expostos na internet com essa falha. Por meio dos servidores com a falha, atacantes 
fizeram um dos maiores ataques de negação de serviço já registrado. Usando 
os servidores como fator de amplificação, conseguiram chegar a 1,35 Tbps de 
tráfego contra os servidores do GitHub (GITHUB, 2018).
GRÁFICO 2 – TRÁFEGO DE REDE NOS SERVIDORES DO GITHUB NO DIA DO ATAQUE
O que podemos perceber é que os invasores sempre estão criando 
tentativas para roubar dados que estão, geralmente, armazenados em bancos de 
dados em que a preocupação com a segurança é bem básica (CARVALHO, 2017; 
FERREIRA, 2019). Então, na etapa de implementação de um software, é preciso 
atenção, além de cuidados, para que a segurança seja protegida. 
FONTE: <https://githubengineering.com/ddos-incident-report/>. Acesso em: 20 jun. 2020.
FIGURA 9 – EXEMPLO DA APLICAÇÃO MEMCACHED
https://www.portalgsti.com.br/memcached/sobre/
TÓPICO 1 — PRIMEIROS PASSOS PARA O DESENVOLVIMENTO SEGURO DE APLICAÇÕES WEB
87
6 MANUTENÇÃO DO PROJETO 
Ao término da fase de implantação do sistema, um projeto de 
software entra na fase de manutenção. Essa etapa é para criar ou adaptar 
novas funcionalidades, além de corrigir problemas que surgiram na etapa da 
implementação (SOMMERVILLE, 2003; SOMMERVILLE, 2007; AMUI, 2015). 
Conforme Sommerville (2007, p. 28), “[...] a manutenção é o processo de 
alteração de um sistema depois de ter sido colocado em utilização com o objetivo 
de fazer correções de código, de projeto, de especificação ou, ainda, adicionar 
funcionalidades”.
Os softwares precisam ter uma mudança contínua para evoluírem com a 
organização, portanto, aumentando sua complexidade, dando maior suporte a 
recursos extras, conforme as necessidades especificadas pelos usuários, além da 
evolução das tecnologias (SOMMERVILLE, 2003; SOMMERVILLE,2007; AMUI, 
2015). A manutenção do software é dividida em quatro tipos, segundo Amui 
(2015): 
• Corretiva: feita com o objetivo de corrigir erros não identificados durante o 
processo de desenvolvimento e testes. Esse tipo de manutenção é importante, 
já que os testes de software dificilmente conseguem identificar todos os erros.
• Adaptativa: efetua modificações que se tornam necessárias por mudanças no 
ambiente. Ocorrem, pois a vida útil de um software é longa e não acompanha 
a evolução rápida da computação.
• Perfectiva ou aperfeiçoadora: tem, como objetivo, a melhora do software. 
Geralmente, é o resultado de recomendações de novas capacidades e 
modificações de funções existentes solicitadas pelos usuários.
• Preventiva: previne futuras manutenções dos tipos anteriores. Alterações 
realizadas com o objetivo de melhorar o software em relação à confiabilidade 
ou manutenibilidade. 
Na manutenção, é essencial, ainda, que os desenvolvedores se atentem 
às atualizações de segurança de bibliotecas e frameworks usados durante o 
desenvolvimento do software, já que uma falha em um desses componentes de 
terceiros pode ocasionar uma falha no software desenvolvido (PRESSMAN, 2011; 
SOMMERVILLE, 2003; SOMMERVILLE, 2007; AMUI, 2015; SEGINFOCAST, 
2016). Desse modo, todas as falhas que são identificadas precisam ser investigadas 
de modo detalhado para analisar se foram usadas por atacantes para forjar, 
modificar ou roubar dados (AMUI, 2015). 
O que podemos verificar é que a manutenção é a fase mais problemática 
do ciclo de vida de um software, já que, conforme Amui (2015, p. 17), “[...] o 
esforço usado nessa etapa pode chegar a 70% de todo ciclo de vida do software 
e os custos podem chegar a 200% do custo de desenvolvimento”. Esse custo 
elevado é em decorrência da dificuldade de compreender o que o software 
UNIDADE 2 — SEGURANÇA NO DESENVOLVIMENTO DE APLICAÇÕES WEB
88
realiza, as características de interface e limites de desempenho. Além disso, soma-
se a necessidade de realizar todas as etapas de desenvolvimento novamente para 
efetuar as modificações necessárias (ANDERSON; BACKWOOD, 2004; CRESPO 
et al., 2004; AMUI, 2015). 
Geralmente, os problemas na manutenção de software estão vinculados 
ao modo como o software foi planejado ou desenvolvido, isto porque, quanto 
maiores forem os problemas e funções deixados ao longo do processo de 
planejamento e desenvolvimento, maiores serão os problemas na fase de 
manutenção (SOMMERVILLE, 2003; SOMMERVILLE, 2007; AMUI, 2015). 
Conforme Sommerville (2007), os problemas mais usuais são: 
• As modificações não são documentadas de modo correto, dificultando o 
acompanhamento da evolução do software. 
• Dificuldade de acompanhar o processo pelo qual o software foi desenvolvido. 
• Dificuldade de compreender os programas desenvolvidos por outros 
profissionais, por falta de documentação.
• A documentação não existe, é incompreensível ou desatualizada.
• Planejamento sem suporte a alterações.
 
A manutenção do software pode ser de dois tipos: estruturada e não 
estruturada (AMUI, 2015).
QUADRO 6 – TIPOS DE MANUTENÇÃO
FONTE: Adaptado de Amui (2015)
Na manutenção estruturada, os documentos necessários, conforme Amui 
(2015), são:
• documento dos requisitos do sistema;
• documento da arquitetura do sistema; 
Manutenção não 
estruturada
Único documento disponível acerca do software é o código-
fonte. No entanto, a documentação do código é falha ou 
inexistente. No caso, não é possível efetuar testes completos 
que validem todo o sistema com as modificações.
Manutenção 
estruturada 
O software possui documentação estruturada e completa. 
Desse modo, a atividade começa pela análise da 
documentação, buscando um entendimento do sistema 
completo.
TÓPICO 1 — PRIMEIROS PASSOS PARA O DESENVOLVIMENTO SEGURO DE APLICAÇÕES WEB
89
• especificação e projeto para cada componente do sistema; 
• programas-fontes comentados; 
• plano de testes;
• guia de manutenção, com os problemas conhecidos. 
A manutenção do software é considerada uma atividade importante e tem 
muitas complexidades, além de ter um impacto no custo de modo significativo 
(PRESSMAN, 2011; ALMEIDA, 2012; AMUI, 2015; FERREIRA, 2019).
A manutenção trabalha com a imprevisibilidade, existindo muitas 
atividades não estruturadas ou não esperadas, porém, é essencial que haja uma 
atividade estruturada para efetivar a qualidade do software, por meio das ações 
de manutenção preventiva (SOMMERVILLE, 2003; SOMMERVILLE, 2007; AMUI, 
2015; MONTANHEIRO et al., 2017). As atividades corretivas englobam:
• ações nas falhas que são encontradas;
• correção de falhas ou erros;
• acomodação de novos requisitos que surgem após o uso do software;
• busca de simplicidade, eficiência e atualizações tecnológicas.
No processo de manutenção, é importante que se tenha a documentação 
do software para garantir a qualidade do produto desenvolvido em toda a sua 
extensão do ciclo de vida, garantindo uma manutenção eficiente (AMUI, 2015; 
CARVALHO, 2017; FERREIRA, 2019). 
Portanto, podemos observar que a manutenção do software, aliada a 
uma documentação adequada e a um suporte técnico eficiente, contribui para a 
melhoria contínua do software. Para isso, vamos, agora, compreender o papel da 
documentação e dos artefatos no processo de manutenção do software. 
6.1 DOCUMENTAÇÃO 
É essencial que se tenha uma documentação eficiente para garantir 
mais segurança nas práticas de manutenção, já que ela se estende por todas 
as etapas do desenvolvimento do software (AMUI, 2015; CARVALHO, 2017). 
A documentação pode estar presente através de artefatos, como anotações, 
documentos, modelagens ou outro meio de documentação que representa aquela 
fase (AMUI, 2015; SEGINFOCAST, 2016; CARVALHO, 2017). 
A documentação descreve muitas partes do código-fonte, como função, 
classe ou módulo (AMUI, 2015). Ainda, existe um conjunto de formas de notações 
que compreende manuais gerais e técnicos, que estão organizados através de 
comentários, dicionários, diagramas, modelagens diversas etc. (COELHO, 
2009; FAGUNDES, 2011; AMUI, 2015). Existem, ainda, dois tipos básicos de 
documentação, de acordo com Coelho (2009):
UNIDADE 2 — SEGURANÇA NO DESENVOLVIMENTO DE APLICAÇÕES WEB
90
• Documentação técnica: destinada ao desenvolvedor. Possui modelos de 
dados, fluxogramas de processo e regras de negócios, dicionários de funções 
e comentários de código. 
• Documentação de uso: destinada ao usuário final e ao administrador 
do sistema. Possui apostilas ou manuais que devem ser utilizados para 
compreender o que se espera do software e como receber as informações que 
precisa.
A documentação do software pode unir uma série de documentos e 
materiais, como (COELHO, 2009; AMUI, 2015): 
• documento de requisitos; 
• documento descritivo da arquitetura do sistema e de cada um dos programas; 
• listagem do código-fonte do software; 
• documentos de validação e seus relacionamentos; 
• guias de manutenção com os problemas já identificados. 
A documentação do código-fonte é feita por meio de comentários diretos 
no código-fonte ou no desenvolvimento de uma documentação on-line (COELHO, 
2009; COSTA, 2012; AMUI, 2015). Ambler (2004) aborda a documentação e 
considera os seguintes critérios: 
• Documentos ágeis maximizam o retorno dos clientes.
• Documentos ágeis satisfazem um propósito.
• Documentos ágeis descrevem informações que têm menor probabilidade de 
mudar. 
• Documentos ágeis têm um cliente específico e facilitam o trabalho desse 
cliente. 
• Documentos ágeis são suficientemente precisos, consistentes e detalhados.
Assista ao vídeo acerca da documentação em https://www.youtube.com/
watch?time_continue=104&v=6R1Vb_ZKOkY&feature=emb_logo.
DICAS
TÓPICO 1 — PRIMEIROS PASSOS PARA O DESENVOLVIMENTO SEGURO DE APLICAÇÕES WEB
91
Ambler (2004) lista os pontos importantes relativos à documentação ágil: 
• A documentação e código-fonte fazem parte do sistema.
• O benefício de uma documentação precisa ser maior do que oscustos de criação e 
manutenção. 
• Cada sistema possui suas necessidades de documentação.
• Pergunte se a documentação é realmente necessária.
• O investimento na documentação do sistema é uma decisão de negócio, não sendo 
somente técnica. 
• Desenvolva uma documentação somente se precisar dela, ou seja, não a crie somente 
por criar.
NOTA
6.2 ARTEFATOS 
Os artefatos são documentos que foram produzidos ao longo do processo 
de desenvolvimento do software (COELHO, 2009; FAGUNDES, 2011; COSTA, 
2012; AMUI, 2015), como:
• diagramas;
• programas;
• documentos de textos; 
• anotações;
• contratos;
• especificações do projeto; 
• desenhos; 
• modelos; 
• projetos.
É importante que esses artefatos estejam em um ambiente que tenha 
controle de versão para garantir o controle das eventuais alterações que podem 
surgir de modo indevido e reverter a versão correta (COELHO, 2009; AMUI, 
2015). Algumas considerações acerca dos artefatos de software, conforme Amui 
(2015):
• A quantidade de artefatos pode mudar de projeto para projeto. 
• Determinados artefatos podem não ser guardados por um longo período de 
tempo, devido ao modo de como foram desenvolvidos. 
• Também podem ser chamados de “Deliverables”, sendo que é o que deve ser 
produzido, concretamente, pelas atividades do processo.
UNIDADE 2 — SEGURANÇA NO DESENVOLVIMENTO DE APLICAÇÕES WEB
92
Para aprofundar o seu conhecimento acerca da manutenção do software, 
leia o exposto a seguir.
QUADRO 7 – CONCEITOS IMPORTANTES DA MANUTENÇÃO DO SOFTWARE
Em alguns modelos de processo de desenvolvimento, ou metodologias, como 
no Processo Unificado (UP), apenas o autor que criou o artefato pode efetuar alterações no 
respectivo artefato, trazendo controle e evitando duplicações de informações. Em outros 
modelos, como o XP, por exemplo, essa prática é inversa, ou seja, os artefatos não possuem 
um único dono e todos podem contribuir com modificações nos artefatos gerados por 
outros, desde que se tenham verdadeiros motivos para isso (AMUI, 2015).
NOTA
CONCEITO DESCRIÇÃO
MANUTENIBILI-
DADE
Facilidade com que um software pode ser entendido, cor-
rigido, adaptado, aumentado etc. A manutenibilidade é 
afetada por diversos fatores, como negligência nas fases 
de projeto, codificação e testes; instabilidade de pessoal; 
disponibilidade de pessoal qualificado; estrutura compre-
ensível do sistema; padronização do uso de linguagens 
de programação e sistemas operacionais; disponibilidade 
de casos de teste; disponibilidade de hardware adequado; 
qualidade da documentação; portabilidade.
REENGENHARIA Um modo de reusar um software e entender os conceitos ocultos do domínio da aplicação. 
ENGENHARIA 
REVERSA
Processo de analisar um tema para identificar seus compo-
nentes e inter-relações, a fim de criar outra representação.
DESIGN RECO-
VERY
Subconjunto da engenharia reversa no qual conhecimen-
tos do domínio e informações externas são acrescidos à 
observação para identificação das abstrações de alto nível 
que estão além daquelas obtidas apenas pela observação 
do sistema.
REDOCUMEN-
TAÇÃO
Criação ou revisão de uma semântica representativa 
equivalente ao mesmo nível de abstração. Produto são 
visões alternativas de fácil entendimento, como diagramas 
de fluxo de dados, estrutura e controle.
REESTRUTURA-
ÇÃO
Transformação de uma representação em outra no mesmo 
nível de abstração, preservando o comportamento externo 
do sistema.
TÓPICO 1 — PRIMEIROS PASSOS PARA O DESENVOLVIMENTO SEGURO DE APLICAÇÕES WEB
93
FORWARD ENGI-
NEERING
Desenvolvimento de software tradicional que inicia com 
abstrações de alto nível e termina com implementações 
físicas.
REENGENHARIA Análise e modificação de um sistema para reconstruí-lo de uma nova forma e sua posterior implementação.
FONTE: Adaptado de Coelho (2009), Fagundes (2011), Amui (2015) e Carvalho (2017)
94
Neste tópico, você aprendeu que:
• A maioria das vulnerabilidades pode ser evitada quando pensada nas fases 
iniciais do desenvolvimento do software (MONTANHEIRO et al., 2017). 
• Uma das etapas importantes a ser realizada no início do projeto é o 
mapeamento do cenário de utilização do software, além dos tipos de ataques 
que esse sistema pode receber (SOMMERVILLE, 2007). 
• A codificação inadequada de um projeto de desenvolvimento de software pode 
ser resolvida através da utilização de padrões e convenções de codificação, 
garantindo a minimização de falhas (CARVALHO, 2017). 
• Usualmente, as falhas ocorrem na entrada de dados quando essas não são 
tratadas de modo correto, permitindo a inserção de códigos maliciosos, 
gerando riscos para a aplicação (TORRES; TORRES, 2016; CARVALHO, 2017; 
FERREIRA, 2019). 
• Mitre (PANDEY, 2011), em parceria com a Networking and Security (SANS), 
desenvolveu o CWE/SANS Top 25 (MARTIM et al., 2011), que apresenta os 
25 erros mais perigosos do software. Conforme Martim et al. (2011), os erros 
aparentados são descritos como perigosos, devido à frequência de ocorrência; 
facilidade de encontrar; facilidade de explorar; frequência com que um 
atacante tenha o controle total do software, roube informações ou cause a 
paralização do software.
• O objetivo de uma tentativa maliciosa em aplicações web pode ser alcançado 
através das técnicas de ataque (ALMEIDA, 2012). Estas não são exclusivas de 
somente um ataque em função de muitas tentativas maliciosas combinarem 
múltiplas técnicas (ALMEIDA, 2012; PILZ; GATTI, 2013).
• Os parâmetros de entrada de uma aplicação são modificados ou manipulados. 
• Na captura de dados, o objetivo é capturar os dados armazenados em uma 
aplicação para diversos fins. 
• Desfiguração: o objetivo é ocasionar modificação visual em uma ou mais 
páginas de um sistema ou website. 
• Test Driven Development (TDD), ou Teste de Desenvolvimento Orientado, 
é considerado uma metodologia de desenvolvimento de software que 
incorpora o desenvolvimento orientado a testes (MONTANHEIRO et al., 
2017; MARROW, 2019). 
RESUMO DO TÓPICO 1
95
• Conforme Montanheiro et al. (2017), grande parte dos ataques na internet 
é realizada por indivíduos conhecidos como “Script Kiddie”, geralmente, 
dispondo do conhecimento superficial, já que há ferramentas prontas para 
fazer os ataques.
• Na etapa de implementação do software, é preciso elaborar um plano de ação 
com o detalhamento de como a equipe tratará uma possível descoberta de 
vulnerabilidade ou a ocorrência de um ataque (ANDERSON; BACKWOOD, 
2004; CRESPO et al., 2004; CARVALHO, 2017). 
• A configuração adequada do servidor é primordial para que sejam evitados 
os vetores de ataque. O uso e a configuração adequada de firewalls a nível 
de aplicação e de rede em ambientes de produção são essenciais para negar 
muitas solicitações, realizadas, muitas vezes, por scanners, à procura de 
vulnerabilidades e portas abertas que possam ser pontos de ameaça (PAYÃO, 
2016; DEVMEDIA, 2017). 
• Ao término da fase de implantação do sistema, um projeto de software 
entra na fase de manutenção. Essa etapa é para criar ou adaptar novas 
funcionalidades, além de corrigir problemas que surgiram na etapa de 
implementação (SOMMERVILLE, 2003; SOMMERVILLE, 2007; AMUI, 2015). 
• A documentação pode estar presente através de artefatos, como anotações, 
documentos, modelagens ou outro meio de documentação que representa 
aquela fase (AMUI, 2015; SEGINFOCAST, 2016; CARVALHO, 2017). 
• Os artefatos são documentos que foram produzidos ao longo do processo de 
desenvolvimento do software (COELHO, 2009; FAGUNDES, 2011; COSTA, 
2012; AMUI, 2015).
96
1 A codificação inadequada de um projeto de desenvolvimento de software 
pode ser resolvida através da utilização de padrões e convenções de codificação, 
garantindo a minimização de falhas (CARVALHO, 2017). Usualmente, 
as falhas ocorrem na entrada de dados quando essas não são tratadas de 
modo correto, permitindo a inserção de códigos maliciosos, gerando riscos 
para a aplicação (CARVALHO, 2017; FERREIRA, 2019). Considerando essa 
afirmação, descreva o quesão os códigos maliciosos.
2 Mitre (PANDEY, 2011), em parceria com a Networking and Security (SANS), 
desenvolveu o CWE/SANS Top 25 (MARTIM et al., 2011), que apresenta 
os 25 erros mais perigosos do software. Dessa forma, assinale a alternativa 
INCORRETA:
a) ( ) Erros apresentados são descritos como perigosos, devido à frequên-
cia de ocorrências.
b) ( ) Erros apresentados são descritos como perigosos, devido à facilida-
de de encontrar.
c) ( ) Erros apresentados são descritos como perigosos, devido à facilida-
de de explorar. 
d) ( ) Erros apresentados são descritos como perigosos, devido à facilida-
de de acesso ao hardware para o controle total.
3 O ataque, em uma aplicação, representa explorar determinada 
vulnerabilidade. Portanto, o objetivo de uma tentativa maliciosa em aplicações 
web pode ser alcançado através das técnicas de ataque (ALMEIDA, 2012). 
Acerca do exposto, classifique V para as sentenças verdadeiras e F para as 
sentenças falsas:
( ) Passagem manipulada de parâmetros é considerada como os parâmetros 
de entrada de uma aplicação são modificados ou manipulados.
( ) Captura de dados é o objetivo de capturar os dados armazenados em uma 
aplicação para diversos fins.
( ) Desfiguração tem, como objetivo, ocasionar modificação visual em uma ou 
mais páginas de um sistema ou website.
( ) Os atacantes usam a passagem manipulada de parâmetros para ocasionar 
erros e descobrir a aplicação e o banco de dados.
Assinale a alternativa que apresenta a sequência CORRETA:
( ) V – V – V – V.
( ) V – F – V – V.
( ) F – F – V – V.
( ) V – V – F – V.
AUTOATIVIDADE
97
4 Na etapa de implementação do software, é preciso elaborar um plano de 
ação com o detalhamento de como a equipe tratará uma possível descoberta de 
vulnerabilidades ou a ocorrência de um ataque (ANDERSON; BACKWOOD, 
2004; CRESPO et al., 2004; CARVALHO, 2017). Isso se faz necessário para que 
a equipe responda rápido e aplique as correções mais adequadas. Assinale a 
alternativa CORRETA:
a) ( ) O servidor que irá rodar a aplicação desenvolvida deve instalr todos 
os softwares de segurança.
b) ( ) É importante que se tenha alocado somente um servidor para o banco 
de dados.
c) ( ) A atualização dos servidores é essencial para evitar que as falhas en-
contradas em softwares possam ser exploradas. 
d) ( ) A configuração do hardware é primordial para que sejam evitados os 
bugs de ataques.
5 É essencial que haja uma documentação eficiente para garantir mais 
segurança nas práticas de manutenção, já que ela se estende por todas as 
etapas do desenvolvimento do software (AMUI, 2015; CARVALHO, 2017). 
A documentação pode estar presente através de artefatos, como anotações, 
documentos, modelagens, ou outro meio de documentação, que representa 
aquela fase (AMUI, 2015; CARVALHO, 2017). Dessa forma, assinale a 
alternativa INCORRETA:
a) ( ) A documentação descreve muitas partes do código-fonte: função, classe 
ou módulo.
b) ( ) Documentação técnica é destinada ao desenvolvedor.
c) ( ) Documentação técnica possui modelos de dados, fluxogramas de pro-
cesso e regras de negócios, dicionários de funções e comentários de código.
d) ( ) Documentação técnica é destinada ao usuário final e ao administrador 
do sistema.
98
99
UNIDADE 2
1 INTRODUÇÃO
Em uma análise de vulnerabilidade, o primeiro ponto a ser considerado é 
a mitigação dos riscos aos quais a empresa está exposta. 
Embora muitas aplicações de softwares tragam benefícios para uma 
empresa, as implicações de segurança são inúmeras (MARROW, 2019; TAGARRO, 
2019). 
Um exemplo prático foi o que ocorreu com a empresa farmacêutica 
Pfizer. O cônjuge de um funcionário instalou um software de compartilhamento 
de arquivos em um computador da empresa em casa, criando uma brecha de 
segurança que comprometeu os nomes e os números da previdência social de 17 
mil funcionários e ex-funcionários (BALTZAN, 2012).
O que se percebe, atualmente, é o aumento dos sequestros de dados 
realizados por ransomware. Estima-se que o prejuízo desses ciberataques ficam 
em torno de U$ 8 bilhões, um rombo que pode ter contribuído para a falência de 
algumas organizações (MARROW, 2019; TAGARRO, 2019).
2 A SEGURANÇA DE APLICAÇÕES NA GESTÃO DA 
SEGURANÇA DA INFORMAÇÃO
A gestão em segurança da informação adota medidas mais eficazes 
de proteção, promovendo um alinhamento da Tecnologia da Informação (TI) 
às estratégias de negócios da empresa. A garantia de segurança para operar 
no mercado possibilita o estabelecimento de parcerias comerciais benéficas à 
empresa (BRASIL, 2019; RUFINO, 2020).
No mercado atual, as empresas buscam cada vez mais efetivar negócios 
com quem garante a integridade dos dados compartilhados. Nesse sentido, 
temos a Lei Geral de Proteção de Dados (LGPD), aplicada no Brasil, que segue o 
exemplo da União Europeia (RUFINO, 2020).
TÓPICO 2 — 
ANÁLISE DE VULNERABILIDADE
100
UNIDADE 2 — SEGURANÇA NO DESENVOLVIMENTO DE APLICAÇÕES WEB
De compras on-line a redes sociais, de hospitais a bancos, de escolas a teatros, 
de hotéis a órgãos públicos, da publicidade à tecnologia, pode ter certeza, a Lei Geral 
de Proteção de Dados Pessoais (LGPD) afeta diferentes setores e serviços, e a todos nós, 
brasileiras e brasileiros, seja no papel de indivíduo, empresa ou governo (BRASIL, 2019; 
RUFINO, 2020).
NOTA
FIGURA 10 – ESTRUTURA GERAL DA LEI GERAL DE PROTEÇÃO DE DADOS PESSOAIS (LGPD)
FONTE: <https://bit.ly/3rkKn86>. Acesso em: 19 jun. 2020.
Portanto, uma gestão eficiente possibilita, à empresa, um ritmo de 
melhoria contínua em relação ao uso dos recursos de TI (MONTANHEIRO et al., 
2017; MARROW, 2019; RUFINO, 2020). Os hábitos de monitorar continuamente 
a segurança dos dados e buscar novos modos de usá-los são uma tendência 
TÓPICO 2 — ANÁLISE DE VULNERABILIDADE
101
importante que gera a evolução do negócio, sendo medidas que fomentam uma 
cultura da inovação no ambiente empresarial (MONTANHEIRO et al., 2017; 
MARROW, 2019; RUFINO, 2020). Então, o investimento em segurança minimiza 
os riscos de incidentes, e a valorização da adoção dessas medidas é sentida no 
ambiente de trabalho e no próprio mercado.
O que podemos perceber é que a popularização da internet e dos seus 
serviços faz com que o assunto segurança em aplicações web seja algo muito 
importante a ser discutido (BATISTA, 2007; BRAGA, 2007; AMUI, 2015). O 
ambiente virtual é interessante:
• para as empresas que aumentam seus lucros através do comércio on-line;
• para os usuários que confiam em aplicações web diariamente, registrando 
suas informações pessoais;
• para os criminosos que conseguem, muitas vezes, obter recursos financeiros 
através do roubo de informações.
As facilidades trazidas pelas aplicações web são as compras, acesso 
a bancos, buscas etc. Nessas transações, muitos dados são gerenciados pelas 
aplicações, sendo que as empresas que intermediam compras na internet são, por 
exemplo, PagSeguro29 e PayPal30 (BATISTA, 2007; BRAGA, 2007; AMUI, 2015). 
Essas empresas administram os dados de diversos clientes, além das informações 
dos cartões de crédito (BATISTA, 2007; BRAGA, 2007). Desse modo, o vazamento 
desses dados afetaria negativamente muitas pessoas e a credibilidade da empresa 
que fornece o serviço (AMUI, 2015).
As aplicações web trouxeram novos tipos de vulnerabilidades e ataques 
associados, assim, destacam-se dois pontos principais (AMUI, 2015):
• fraqueza na aplicação suscetível a ataques; 
• técnicas utilizadas por atacantes com o intuito de explorar vulnerabilidades 
na aplicação. 
O problema central de segurança em aplicações web está relacionado ao 
fato de que os usuários podem enviar entradas totalmente arbitrárias às aplicações 
Agência de segurança cibernética alerta sobre um aumento nos ataques 
ransomware direcionados a universidades e faculdades. Para entender melhor o assunto, 
leia a reportagem na íntegra: https://sempreupdate.com.br/hackers-atacam-universida-
des-com-ransomware/.
DICAS
102
UNIDADE 2 — SEGURANÇANO DESENVOLVIMENTO DE APLICAÇÕES WEB
(BATISTA, 2007; BRAGA, 2007; AMUI, 2015). Então, é preciso considerar que 
todas as entradas são maliciosas. As entradas maliciosas interferem na lógica 
e comportamento da aplicação, ganhando acesso privilegiado aos dados e 
funcionalidades do sistema. Conforme Amui (2015), o problema de envio de 
entradas arbitrárias pode se manifestar dos seguintes modos: 
• usuários interferindo em qualquer parte do dado transmitido entre o cliente 
e o servidor; 
• controles de segurança implementados ao lado do cliente com facilidade de 
serem burlados, por exemplo, validação de formulários utilizando JavaScript; 
• envio de requisições às aplicações web; 
• usuários enviando requisições e parâmetros às aplicações em diferentes 
sequências; 
• afirmações de como o usuário deve interagir com a aplicação; 
• os usuários não estão restritos somente aos navegadores web para usar as 
aplicações; 
• diferentes ferramentas podem ser utilizadas para auxiliar na exploração 
de aplicações, como ferramentas que são capazes de enviar requisições e 
parâmetros para procurar e explorar vulnerabilidades.
Segue uma lista com os 20 produtos com maiores falhas de segurança, 
sendo que o Debian (Linux) está no topo da lista com, aproximadamente, 3.000 
falhas de segurança encontradas no período entre 1999 e 2019, enquanto o sistema 
Android está com 2.563 vulnerabilidades (TAGARRO, 2019).
QUADRO 8 – TOP 20 DOS PRODUTOS COM MAIORES VULNERABILIDADES
FONTE: <http://bit.ly/3phdpUA>. Acesso em: 19 jun. 2020.
TÓPICO 2 — ANÁLISE DE VULNERABILIDADE
103
O que você poderá observar na lista da Figura 8 é que os cinco primeiros 
lugares são de sistemas operacionais. Com relação aos sistemas da Microsoft, 
o Windows 7, com 1.283 vulnerabilidades identificadas, enquanto o Windows 
10 apresentou 1.111. No entanto, analisando a lista somente do ano de 2019, 
podemos perceber que o sistema Android foi o mais vulnerável, com 414 falhas 
identificadas (TAGARRO, 2019). O tipo de falha encontrada com maior frequência, 
ou seja, em 25% das falhas de segurança, está relacionado com a execução do 
código.
Ransomware: software malicioso que infecta seu computador e exibe 
mensagens, exigindo o pagamento de uma taxa para fazer o sistema voltar a funcionar. 
Mostraremos como funciona e como você pode proteger os dados do ransomware.
FUNCIONAMENTO DO RANSOMWARE
FONTE: <https://bit.ly/3p9OSR4>. Acesso em: 19 jun. 2020.
NOTA
104
UNIDADE 2 — SEGURANÇA NO DESENVOLVIMENTO DE APLICAÇÕES WEB
3 REPOSITÓRIOS E PADRÕES 
As vulnerabilidades encontradas são localizadas por meio de mecanismos 
buscadores que usam relatórios comuns, disponíveis em repositórios abertos 
(SÊMOLA, 2003; MENEZES, 2006; FERNANDES, 2013). Os principais repositórios 
que armazenam informações de vulnerabilidades são: 
• National Vulnerability Database (NVD), mantido pelo Instituto Nacional de 
Padrões e Tecnologia (National Institute of Standards and Technology – NIST): 
agência governamental não regulatória da administração de tecnologia do 
Departamento de Comércio dos Estados Unidos (VIANA et al., 2013; AMUI, 
2015). 
• Common Vulnerabilities and Exposures (CVE), mantido pelo MITRE Corporation: 
organização sem fins lucrativos e opera múltiplas pesquisas financiadas pelo 
governo federal dos Estados Unidos (VIANA et al., 2013). 
• Open Vulnerability and Assessment Language (OVAL), mantido, também, pelo 
MITRE: repositórios são utilizados no processo de Análise de Vulnerabilidade 
(AV) e são consultados pela comunidade e por ferramentas que são alimentadas 
com informações (VIANA et al., 2013). 
• Existem diversos padrões e repositórios disponíveis para usar no processo de 
AV, gerenciamento de risco e correções de segurança, em decorrência disso, 
ocorrem divergências de informações ou falta de padronização (VIANA et al., 
2013). 
Com os objetivos de transpor essas deficiências e estabelecer um padrão 
do processo de AV, o NIST elaborou o Security Content Automation Protocol (SCAP) 
(ALMEIDA, 2012; VIANA et al., 2013; AMUI, 2015; CRUZ, 2017). Conforme 
Prazeres (2015) e Cruz (2017), o SCAP é um conjunto de especificações que 
estabelece padrões, nomenclaturas e formatação, pelo qual produtos de segurança 
comunicam informações acerca:
• da identificação do software;
• das vulnerabilidades do software;
• das configurações de segurança. 
O SCAP oferece, ainda, suporte para (VIANA et al., 2013; PRAZERES, 
2015): 
• protocolo multiuso;
• verificação de vulnerabilidade automatizada; 
• controle técnico de atividades de conformidade; 
• medições de segurança. 
O SCAP, conforme Cruz (2017), é segmentado em três categorias: 
• Linguagem: utilizada para especificar listas de verificações e procedimento 
de teste, além de fornecer relatórios da lista de verificação. 
TÓPICO 2 — ANÁLISE DE VULNERABILIDADE
105
• Enumeração: tem nomenclaturas e dicionários de segurança da informação. 
• Vulnerabilidade: mensura características e fornece resultados de pontuação 
de risco de uma vulnerabilidade.
QUADRO 9 – COMPONENTES DO SCAP
FONTE: Adaptado de Cruz (2017)
A pontuação é atribuída ao grau de risco, que representa determinada 
vulnerabilidade, conforme o risco e características mensuradas (CRUZ, 2017).
NOTA
CATEGORIA ESPECIFICAÇÃO DEFINIÇÃO 
Linguagem 
Extensible 
Configuration 
Checklist Description 
Format (XCCDF)
Uma especificação XML para coleções 
estruturadas de configurações de se-
gurança, regras utilizadas por sistemas 
operacionais e plataformas de aplicati-
vos. 
Linguagem 
Open Vulnerability 
and Assessment 
Language (OVAL)
Uma especificação XML para troca de 
detalhes técnicos, acerca de como ve-
rificar falhas de software relacionadas 
com segurança, problemas de configu-
ração e correções. 
Enumeração 
Common Platform 
Enumeratio 
(CPE)
Uma convenção de nomenclatura para 
hardware, sistema operacional e classes 
de aplicações. 
Enumeração 
Common 
Configuration 
Enumeration (CCE) 
Um dicionário de nomes para proble-
mas de configuração de segurança de 
software, como controle de acesso e 
configurações de diretiva de senha. 
Vulnerabili-
dade 
Common 
Vulnerabilities And 
Exposures (CVE) 
Um dicionário de nomes para vulne-
rabilidades de software relacionadas à 
segurança. 
Vulnerabili-
dade 
Common 
Vulnerability 
Scoring System 
(CVSS)
Um método de classificação de caracte-
rísticas de vulnerabilidades de software 
e atribuição de escores (pontuação) de 
gravidade, com base nas características 
das vulnerabilidades classificadas. 
106
UNIDADE 2 — SEGURANÇA NO DESENVOLVIMENTO DE APLICAÇÕES WEB
Outra taxonomia utilizada é a classificação de vulnerabilidades, conforme 
sua severidade, denominada de Common Vulnerability Scoring System (CVSS) 
(BASSO, 2010; CARVALHO, 2017; CRUZ, 2017). Esse modelo fornece um padrão 
para classificação das vulnerabilidades por gravidade de risco, atribuindo valores 
de 1 a 10, quanto maior o número, maior é a gravidade (VIANA et al., 2013; CRUZ, 
2017). O CVSS utiliza as seguintes métricas nas suas classificações: base, temporal 
e ambiental.
QUADRO 10 – MÉTRICAS DE CLASSIFICAÇÃO
FONTE: Adaptado de Cruz (2017)
Segue a classificação do grau de severidade baseado no CVSS e descreve, 
ainda, possíveis consequências em caso de ataque. 
QUADRO 11 – CLASSIFICAÇÃO DE VULNERABILIDADE POR GRAVIDADE
Base: características intrínsecas e fundamentais de uma vulnerabilidade que 
são constantes ao longo do tempo e dos ambientes do usuário.
Temporal: características de uma vulnerabilidade que se altera ao longo do 
tempo, porém não entre os ambientes do usuário.
Ambiental: características de uma vulnerabilidade que são relevantes e 
exclusivas para o ambiente de um determinado usuário.
GRAVIDADE ESCALA DE PONTUAÇÃO CONSEQUÊNCIA
Alta 7 até 10
- A vulnerabilidade pode ser explorada 
de modo mais fácil, isso torna possível a 
violação da proteção de segurança de um 
sistema, e um cibercriminoso conseguiria 
acesso de usuários ou privilégios do ad-
ministrador dosistema, como Root. Em 
determinados casos, a exploração de vulne-
rabilidades dessa classificação requer mais 
complexidade no ataque e o sucesso pode 
gerar severos danos.
- Motivação para cibercriminosos: Alta-
mente motivados. 
- Valor para cibercriminosos: Alto. 
TÓPICO 2 — ANÁLISE DE VULNERABILIDADE
107
FONTE: Cruz (2017, p. 18)
4 CLASSIFICAÇÃO DAS TÉCNICAS DE VARREDURAS DE 
VULNERABILIDADE 
A varredura de vulnerabilidade é uma atividade que procura 
vulnerabilidades ou modos para se infiltrar nos ativos de tecnologia (CRUZ, 
2017). As atividades de varreduras são utilizadas pelo cibercriminoso antes de 
lançar um ataque cibernético, então, é essencial a investigação, além da adoção de 
métodos de detecção de varreduras de vulnerabilidades (CRUZ, 2017).
Cruz (2017, p. 20) “[...] propôs uma classificação de 19 técnicas, agrupadas 
em cinco categorias, conforme as suas características”. 
Média 4 até 6,99
- Falhas difíceis de explorar, mas que levam 
a algum comprometimento da confidencia-
lidade, integridade ou disponibilidade de 
recursos. Nessa situação, o impacto é críti-
co ou importante, porém, são consideradas 
menos fáceis de serem exploradas.
- Motivação para cibercriminosos: Gera in-
teresse moderado. 
- Valor para cibercriminosos: Médio. 
Baixa 1 até 3,99
- A vulnerabilidade não rende informações 
preciosas ou de controle de um sistema, en-
tretanto, fornece informações que ajudam o 
criminoso a encontrar e a explorar outras 
vulnerabilidades. 
- Motivação para cibercriminosos: Fraca. 
- Valor para cibercriminosos: Baixo. 
108
UNIDADE 2 — SEGURANÇA NO DESENVOLVIMENTO DE APLICAÇÕES WEB
FIGURA 11 – CLASSIFICAÇÃO DAS TÉCNICAS PARA VARREDURA DE VULNERABILIDADE
FONTE: Cruz (2017, p. 20)
Conforme Cruz (2017, p. 20), “[...] um scanner de vulnerabilidades é uma 
ferramenta que acessa uma variedade de sistemas de informação, fornecendo 
relatórios das vulnerabilidades identificadas no sistema”. A sua arquitetura 
possui os seguintes componentes:
 
• Mecanismo de verificação (Scan Engine): executa a verificação e a identificação 
de informações do sistema e vulnerabilidades, conforme as configurações e 
plug-ins instalados, executando uma varredura para mais de um alvo por vez 
(DIAS, 2000; SCARFONE; PETER, 2010; CRUZ, 2017). 
• Banco de dados de verificação (Scan Database): responsável pelo armazena-
mento de informações das vulnerabilidades, resultados e dados que serão 
usados no processo de verificação do scanner (DIAS, 2000; SCARFONE; PE-
TER, 2010; CRUZ, 2017).
• Módulo de Relatório (Report Module): fornece relatórios para determinados 
usuários. Para o administrador de sistemas, o scanner mostra um relatório 
técnico que direciona o caminho e o modo de remediar ou solucionar o 
problema. Para um executivo, são mostradas as informações com gráficos 
(DIAS, 2000; SCARFONE; PETER, 2010; CRUZ, 2017). 
TÓPICO 2 — ANÁLISE DE VULNERABILIDADE
109
• Interface com Usuário (User Interface): interação com usuário, sendo que ele 
pode configurar e passar parâmetros para o software (DIAS, 2000; SCARFONE; 
PETER, 2010; CRUZ, 2017). 
FIGURA 12 – COMPONENTES DO SCANNER
5 PROCESSO DE ANÁLISE DE VULNERABILIDADE 
O gerenciamento de vulnerabilidade é considerado como o processo de 
identificar, monitorar e responder à vulnerabilidade (HOLANDA; FERNAN-
DES, 2011). A gestão de vulnerabilidades possui o objetivo de mitigar, de modo 
sistemático, os riscos resultantes da exploração de falhas técnicas conhecidas 
(HOLANDA; FERNANDES, 2011; CARVALHO, 2017; CRUZ, 2017). 
FONTE: Cruz (2017, p. 28)
Dentre os scanners mais populares, estão Vega, W3af, Golismero, Skipfish, 
Uniscan e Nikto. Para saber mais, leia o artigo das 10 melhores ferramentas de verificação 
de vulnerabilidades para testes de penetração: https://minutodaseguranca.blog.br/
as-10-melhores-ferramentas-de-verificacao-de-vulnerabilidades-para-testes-de-
penetracao-2019/.
DICAS
https://minutodaseguranca.blog.br/as-10-melhores-ferramentas-de-verificacao-de-vulnerabilidades-para-testes-de-penetracao-2019/
https://minutodaseguranca.blog.br/as-10-melhores-ferramentas-de-verificacao-de-vulnerabilidades-para-testes-de-penetracao-2019/
https://minutodaseguranca.blog.br/as-10-melhores-ferramentas-de-verificacao-de-vulnerabilidades-para-testes-de-penetracao-2019/
110
UNIDADE 2 — SEGURANÇA NO DESENVOLVIMENTO DE APLICAÇÕES WEB
FIGURA 13 – OBJETIVOS PRINCIPAIS DA ISO/IEC 17799
FONTE: O autor
FIGURA 14 – ESTRUTURA GERAL DA ISO 17799
FONTE: <https://bit.ly/3aMTGYX>. Acesso em: 19 maio 2020.
A ISO/IEC 17799 foi atualizada para a numeração ISO/IEC 27002 em julho 
de 2007. É uma norma de segurança da informação revisada em 2005 pela ISO e pela 
IEC. A versão original foi publicada em 2000, que, por sua vez, era uma cópia fiel do pa-
drão britânico (BS) 7799-1:1999. A ISO/IEC-17799 tem, como objetivos, confidencialidade, 
integridade e disponibilidade das informações, fatores muito importantes para a seguran-
ça da informação. A ISO 17799 inclui 127 controles e 36 objetivos de controle agrupados 
em 10 áreas de controle. Os controles são baseados na experiência das organizações e 
melhores práticas.
NOTA
TÓPICO 2 — ANÁLISE DE VULNERABILIDADE
111
A ISO 17799 apresenta um conjunto de diretrizes para uma adequada 
gestão de vulnerabilidade (HOLANDA; FERNANDES, 2011):
• a organização define e estabelece as funções e responsabilidades associadas 
à gestão de vulnerabilidades técnicas. Isso inclui o monitoramento 
de vulnerabilidades; análise; avaliação de riscos de vulnerabilidades; 
acompanhamento dos ativos; e todo tipo de coordenação de responsabilidades; 
• os recursos de informação que serão usados para identificar vulnerabilidades 
técnicas precisam ser identificados, ou seja, identificar softwares e outras 
tecnologias utilizadas no processo; 
• definição de um prazo com os fornecedores e os administradores de sistemas 
para reagir em relação às notificações de vulnerabilidades técnicas potenciais; 
• avaliação dos riscos associados e as ações a serem tomadas em caso de 
identificação das vulnerabilidades; 
• conforme a urgência exigida para tratar de uma vulnerabilidade técnica, é 
necessária a tomada da ação, conforme os controles relacionados com a gestão 
de mudanças, ou, ainda, seguir os procedimentos de resposta a incidentes de 
segurança da informação;
• os patches precisam ser testados e avaliados antes de serem instalados. Isso é 
necessário para garantir que não tragam efeitos que não possam ser tolerados. 
Contudo, em situações em que não se tenha a disponibilidade de um patch, 
é preciso considerar a utilização de outros controles, como a desativação 
de serviços ou potencialidades relacionados à vulnerabilidade; aumento da 
conscientização acerca da vulnerabilidade; 
• manter um registro de auditoria dos procedimentos efetuados na gestão de 
vulnerabilidades; 
• monitorar e avaliar, de modo regular, o processo de gestão de vulnerabilidades 
técnicas; 
• abordar, primeiramente, os sistemas com riscos altos.
O patch auxilia no combate às vulnerabilidades dos programas e na corre-
ção do controle do hardware, corrigindo erros e falhas, além de melhorar sua usabilida-
de. Quando você traduz patch, o seu significado é “remendo”, sendo essa a sua função 
prática: corrigir (remendar) algo que não esteja funcionando do modo adequado dentro 
de um determinado software. Empresas responsáveis pelo desenvolvimento de softwa-
re possuem seus próprios processos de gerenciamento de patchs, destacando-se: o 
Processo de Gerenciamento de Atualizações da Microsoft, o da Ecora e o da Computer 
Associates (CA) (HOLANDA; FERNANDES, 2011; CARVALHO, 2017; CRUZ, 2017).
NOTA
112
UNIDADE 2 — SEGURANÇA NO DESENVOLVIMENTO DE APLICAÇÕES WEB
Leia a reportagem em que pesquisadores descobrem graves vulnerabilidades 
em conversores digitais: https://canaltech.com.br/seguranca/pesquisadores-descobrem-
graves-vulnerabilidades-em-conversores-digitais-170750/.
DICAS
6 PROCEDIMENTOS PARA A GESTÃO DE VULNERABILIDADE
A vulnerabilidadeé considerada uma fraqueza que pode ser explorada 
no sistema, já o patch é a resposta a uma vulnerabilidade. O patch pode eliminar 
uma ou mais vulnerabilidades. O que se precisa considerar é que o ciclo de 
vida de uma vulnerabilidade é composto por cinco fases apresentadas a seguir 
(JUNIOR, 2009; BASTOS, 2010; HOLANDA; FERNANDES, 2011; CARVALHO, 
2017; CRUZ, 2017).
 
QUADRO 12 – CICLO DE VIDA DE UMA VULNERABILIDADE
FONTE: Adaptado de Holanda e Fernandes (2011)
FASES DESCRIÇÃO
FASE 1 Ocorre antes da vulnerabilidade ser descoberta. A vulnerabilidade existe, mas não foi explorada.
FASE 2
Ocorre depois de a vulnerabilidade ser descoberta, porém, antes 
de ela ser divulgada. Algumas pessoas sabem da existência da 
vulnerabilidade, porém, não sabem como eliminá-la do sistema. 
FASE 3 Ocorre após a vulnerabilidade ser anunciada. Aumento do risco, já que mais pessoas conhecem a vulnerabilidade e podem explorá-la.
FASE 4
A exploração da vulnerabilidade é automatizada através de ferra-
mentas de ataque. Ocorre a divulgação das ferramentas e o risco de 
ataque aumenta. O fabricante emite um patch para a vulnerabilidade 
para reduzir os riscos de ataques. 
FASE 5 Os administradores de sistemas instalam os patches, minimizando o risco de exploração da vulnerabilidade.
TÓPICO 2 — ANÁLISE DE VULNERABILIDADE
113
GRÁFICO 3 – VULNERABILIDADES E O AUMENTO DOS RISCOS CONFORME O TEMPO DE 
DESCOBERTA
FONTE: Holanda e Fernandes (2011, p. 37)
 
O tempo de cada fase varia conforme o caso. O fabricante pode liberar 
rapidamente um patch, alterando os tempos do ciclo de vida, e outros eventos 
podem surgir durante o ciclo de vida da vulnerabilidade (HOLANDA; 
FERNANDES, 2011; CARVALHO, 2017; CRUZ, 2017). Os fabricantes do software 
lançam os patches, entretanto, podem gerar problemas, como:
• quantidade excessiva de patches para distribuir e testar; 
• processo complexo de aplicação dos patches; 
• dificuldades na obtenção dos patches; 
• patches que introduzem comportamento instável no sistema. 
7 TESTE DE PENETRAÇÃO 
O Teste de Penetração (Penetration Testing, Pentest) é considerado um 
processo que faz inúmeras tentativas de intrusão ou ataques cibernéticos em 
sistemas e aplicações e em redes de computadores (CINTO, 2015; PEREIRA, 2018). 
O objetivo do Pentest é avaliar a segurança de um determinado alvo, fazendo 
ataques de modo controlado e com autorização para avaliar a real efetividade dos 
ataques (PEREIRA, 2018). 
Conforme Pereira (2018, p. 52), “[...] o teste de penetração fornece provas 
e evidências da segurança de um sistema ou aplicação através de uma auditoria 
ética, sendo que essas evidências contribuem com requerimentos de investimentos 
em segurança”.
114
UNIDADE 2 — SEGURANÇA NO DESENVOLVIMENTO DE APLICAÇÕES WEB
FIGURA 15 – FUNCIONAMENTO DO TESTE DE PENETRAÇÃO
FONTE: <https://bit.ly/3mIQcsH>. Acesso em: 21 jun. 2020.
A eficiência e o desempenho dos testes dependem, de modo direto, da dis-
ponibilidade de competências individuais, e é preciso considerar que podem não 
prevenir riscos de modo eficiente, na proporção que, ao atuarem sobre os inciden-
tes, estes já podem ter, como resultado, impactos negativos ao negócio (PILZ; GAT-
TI, 2013; ANSARI, 2015; PEREIRA, 2018). Além disso, as vulnerabilidades identi-
ficadas dependem do escopo dos testes e do acesso que a equipe tem ao sistema 
(SCHETINA; CARLSON, 2002).
Para obter a eficiência e o desempenho, é necessário estabelecer algumas 
restrições que precisam ser combinadas entre os membros da equipe de testes e os 
desenvolvedores do software (PEREIRA, 2018). 
A realização dos testes inclui a aplicação de ataques que comprometem o 
sistema, então, é preciso definir o escopo e os objetivos dos testes (PILZ; GATTI, 
2013; PEREIRA, 2018). Além disso, é preciso definir quais partes do sistema sofre-
rão o ataque e que tipos de ataques serão permitidos, além da metodologia adotada. 
Os testes de penetração, usualmente, são classificados de acordo com a 
quantidade de informações fornecidas à equipe de testes acerca do software a ser 
testado (PILZ; GATTI, 2013; ANSARI, 2015; PEREIRA, 2018). As categorias de tes-
tes são:
• Testes black box: ocorrem em situações em que não existe quase nenhuma infor-
mação do sistema em posse da equipe de testes. Isso significa que a equipe não 
tem conhecimento do sistema operacional executado na máquina, do servidor 
web usado, da linguagem de programação utilizada para escrever o sistema, 
nem do código-fonte do software. Então, no teste black box, a equipe de tes-
TÓPICO 2 — ANÁLISE DE VULNERABILIDADE
115
tes está na mesma posição em relação aos atacantes (CINTO, 2015; PEREIRA, 
2018). 
• Testes white box: ocorrem em situações em que quase todas as informações do 
sistema são oferecidas à equipe de testes (PEREIRA, 2018). 
• Testes gray box: são considerados o meio termo entre os testes black e white box. 
Isso significa que esses testes oferecem parte das informações (PEREIRA, 2018). 
• Testes crystal box: a equipe de testes e o alvo possuem total conhecimento do 
ataque e dos testes que serão executados (CINTO, 2015; PEREIRA, 2018).
• Reversal: a equipe de teste possui total conhecimento do ambiente do alvo, mas 
o alvo não tem nenhum conhecimento do teste e das ações que serão realizadas. 
Esse teste é realizado para testar a equipe de resposta a incidentes (CINTO, 
2015; PEREIRA, 2018).
Em aplicações web, existe a possibilidade de realizar testes em qualquer lo-
cal em que um determinado usuário encaminha parâmetros para o servidor. Nesse 
caso, estão inclusos: os parâmetros da URL solicitada, os campos de formulários, 
o cabeçalho da mensagem HTTP etc. (PILZ; GATTI, 2013; CINTO, 2015; PEREIRA, 
2018). A execução de testes de penetração nesses pontos de entrada pode identi-
ficar, por exemplo, falhas de XSS, SQL injection, session hijacking e buffer overflow 
(PILZ; GATTI, 2013). 
Existem alguns passos que o Pentest deve realizar antes do ataque. De acor-
do com a literatura seguida, esses passos podem variar de quatro a sete (PEREIRA, 
2011; PEREIRA, 2018).
 
QUADRO 13 – FASES DO PENTEST
FONTE: Adaptado de Pereira (2011) e Pereira (2018)
FASES DESCRIÇÃO
FASE 1
Envolve, além da definição dos contratos, o alinhamento com o cliente 
das ações técnicas que serão tomadas, a definição dos objetivos do teste 
de invasão, o mapeamento do escopo, os parâmetros utilizados etc.
FASE 2
Coleta de informações ou information gathering. Nesta fase, o pentes-
ter busca informações publicadas na internet do cliente e começa a 
montar a estratégia do ataque.
FASE 3
São realizadas as modelagens das ameaças. O teste utiliza essas infor-
mações para mensurar o valor e o impacto sobre o cliente, no caso des-
sas descobertas serem utilizadas por um possível atacante externo.
FASE 4 Realiza uma análise de vulnerabilidades, identificando os pontos fracos dos sistemas
FASE 5 Exploração de falhas.
FASE 6
Pós-exploração de falhas. Com a invasão da rede interna, os dados e 
informações críticos do cliente são realmente coletados e os sistemas 
internos acessados.
FASE 7
Gerado um relatório, no qual o analista ou auditor deve resumir as 
ações realizadas e os dados coletados, para ser entregue à equipe 
técnica e aos diretores da empresa. 
116
UNIDADE 2 — SEGURANÇA NO DESENVOLVIMENTO DE APLICAÇÕES WEB
Portanto, a análise dos resultados dos testes não pode ser somente 
a observação, se ocorreram interrupções no funcionamento da aplicação. É 
necessário verificar a reação da aplicação a determinadas entradas (PEREIRA, 
2018). 
Um dos modos de fazer essa verificação é através da análise dos códigos 
de status das respostas HTTP enviadas pelo servidor, já que cada código possui 
um significado que pode ser utilizado para inferir vulnerabilidades que podem 
ser exploradas na aplicação (PEREIRA, 2011; CINTO, 2015; PEREIRA, 2018).
Um ponto importante a ser considerado é que o ambiente de teste deve 
ser planejado com o objetivo de garantir que os dados de testes tenham uma 
seleção cuidadosa,evitando-se a utilização de bancos de dados operacionais que 
tenham informações de natureza pessoal ou informações sensíveis (HOLANDA; 
FERNANDES, 2011; CRUZ, 2017; PEREIRA, 2018). Caso se utilize esse tipo 
de informação, os detalhes e conteúdo sensível precisam ser removidos ou 
alterados de modo a evitar o reconhecimento antes da utilização (HOLANDA; 
FERNANDES, 2011). Um conjunto de diretrizes é apresentado para a proteção de 
dados em um ambiente de teste (HOLANDA; FERNANDES, 2011).
QUADRO 14 – DIRETRIZES
FONTE: Adaptado de Holanda e Fernandes (2011)
Segue uma listagem das principais ferramentas usadas no Pentest.
QUADRO 15 – PRINCIPAIS FERRAMENTAS UTILIZADAS NO PENTEST
Procedimentos de controle de acesso, implementados nos aplicativos de 
sistema em ambiente operacional e no ambiente de teste.
Autorização, em todos os momentos de uso, de uma cópia da informação 
operacional para uso de um aplicativo em teste.
Informação operacional precisa ser apagada do aplicativo em teste após o 
término.
Cópia e uso de informação operacional registrados de forma a prover uma 
trilha para auditoria.
FERRAMENTA DESCRIÇÃO
ACUNETIX 
WVS 
Verifica, automaticamente, aplicações web, procurando vul-
nerabilidades. 
BURP SUITE É uma plataforma integrada para a realização de testes de 
segurança de aplicações web. 
TÓPICO 2 — ANÁLISE DE VULNERABILIDADE
117
FONTE: Adaptado de Holanda e Fernandes (2011), Pereira (2011) e Pereira (2018)
WEB INSPECT
É uma aplicação web automatizada e configurável, com fer-
ramentas de teste de penetração que imitam técnicas de ha-
cking e ataques do mundo real, permitindo que seus clientes 
analisem cuidadosamente as aplicações web complexas e 
serviços para vulnerabilidades de segurança. 
APPSCAN Ferramenta que melhora a segurança de aplicações web e mobile, melhora a gestão do programa de segurança de 
aplicativos e reforça a conformidade regulatória. 
METASPLOIT Ferramenta de desenvolvimento e execução de código de 
exploit contra uma máquina-alvo remota.
NESSUS Ferramenta de scanner remote que escaneia um computador e gera um alerta, caso descubra qualquer vulnerabilidade. 
NEXPOSE Scanner de vulnerabilidade que apoia todo o ciclo de vida de gerenciamento de vulnerabilidades, incluindo a descoberta, 
detecção, verificação, classificação de risco, análise de 
impacto, relatório e mitigação. 
OPENVAS OpenVAS é uma estrutura de vários serviços e ferramentas que oferece uma abrangente solução de vulnerabilidade e 
gerenciamento de vulnerabilidades. 
PAROS 
Web proxy baseado em Java para acessar vulnerabilidades 
de aplicações web. Ele suporta editar/visualizar mensagens 
em modo HTTP/HTTPS para alterar itens, como cookies e 
campos de formulários. 
QUALYS-
GUARD 
Oferta popular de gerenciamento de vulnerabilidade 
Software as a service (SaaS – software como serviço). A sua 
interface, baseada em web, possibilita a descoberta de rede 
e mapeamento, priorização de ativos, relatórios de avaliação 
de vulnerabilidades e monitoramento de remediação, 
conforme o risco do negócio.
WEBSCARAB 
Ferramenta de teste de aplicativos de segurança da web. 
Serve como um proxy que intercepta e possibilita que as 
pessoas modifiquem os pedidos de web browser (HTTP e 
HTTPS) e respostas do servidor web. 
WIRESHARK Permite que o profissional examine dados de uma rede ao vivo ou de um arquivo de captura no disco. 
118
RESUMO DO TÓPICO 2
Neste tópico, você aprendeu que:
• Em uma análise de vulnerabilidade, o primeiro ponto a ser considerado é 
a mitigação dos riscos aos quais a empresa está exposta. Embora muitas 
aplicações de softwares tragam benefícios para uma empresa, as implicações 
de segurança são inúmeras (MARROW, 2019; TAGARRO, 2019). 
• A gestão em segurança da informação adota medidas mais eficazes de 
proteção, promovendo um alinhamento da Tecnologia da Informação (TI) 
às estratégias de negócios da empresa. A garantia da segurança para operar 
no mercado possibilita o estabelecimento de parcerias comerciais benéficas à 
empresa (BRASIL, 2019; RUFINO, 2020).
• Os hábitos de monitorar continuamente a segurança dos dados e buscar 
novos modos de usá-los são tendências importantes, que geram a evolução 
do negócio. São medidas que fomentam uma cultura da inovação no ambiente 
empresarial. Então, o investimento em segurança minimiza os riscos de 
incidentes. 
• A popularização da internet e dos seus serviços faz com que o assunto 
segurança em aplicações web seja algo muito importante a ser discutido.
• O problema central de segurança em aplicações web está relacionado ao fato 
de que os usuários podem enviar entradas totalmente arbitrárias às aplicações 
(BATISTA, 2007; BRAGA, 2007; AMUI, 2015). 
• As vulnerabilidades encontradas são localizadas através de mecanismos 
buscadores que usam relatórios comuns, disponíveis em repositórios abertos 
(SÊMOLA, 2003; MENEZES, 2006; FERNANDES, 2013). 
• Com os objetivos de transpor essas deficiências e estabelecer um padrão 
do processo de AV, o NIST elaborou o Security Content Automation Protocol 
(SCAP) (ALMEIDA, 2012; VIANA et al., 2013; AMUI, 2015; CRUZ, 
2017). Conforme Prazeres (2015) e Cruz (2017), o SCAP é um conjunto de 
especificações que estabelece padrões nomenclaturais e de formatação 
pelo qual produtos de segurança comunicam informações: identificação de 
software, vulnerabilidades de software e configurações de segurança.
• A varredura de vulnerabilidade é uma atividade que procura vulnerabilidades 
ou modos para se infiltrar em ativos de tecnologia (CRUZ, 2017). As atividades 
de varreduras são utilizadas por cibercriminosos antes de lançarem um ataque 
cibernético, então, é essencial a investigação, além da adoção de métodos de 
detecção de varreduras de vulnerabilidades (CRUZ, 2017). 
119
• Gerenciamento de vulnerabilidade é considerado o processo de identificar, 
monitorar e responder à vulnerabilidade (HOLANDA; FERNANDES, 
2011). A gestão de vulnerabilidades possui o objetivo de mitigar, de modo 
sistemático, os riscos resultantes da exploração de falhas técnicas conhecidas 
(HOLANDA; FERNANDES, 2011; CARVALHO, 2017; CRUZ, 2017). 
• A vulnerabilidade é considerada como uma fraqueza que pode ser explorada 
no sistema, já o patch é a resposta a uma vulnerabilidade. O patch pode eliminar 
uma ou mais vulnerabilidades. 
• Teste de Penetração (Penetration testing, Pentest) é considerado um processo 
que faz inúmeras tentativas de intrusão ou ataques cibernéticos em sistemas 
e aplicações e em rede de computadores (CINTO, 2015; PEREIRA, 2018). O 
objetivo do Pentest é avaliar a segurança de um determinado alvo, fazendo 
ataques de modo controlado e com autorização para avaliar a real efetividade 
dos ataques (PEREIRA, 2018). 
• A eficiência e o desempenho dos testes dependem, de modo direto, da 
disponibilidade de competências individuais. É preciso considerar que 
podem não prevenir riscos de modo eficiente, na proporção que, ao atuarem 
sobre os incidentes, já podem ter resultado com impactos negativos ao 
negócio (PILZ; GATTI, 2013; ANSARI, 2015; PEREIRA, 2018). Além disso, as 
vulnerabilidades identificadas dependem do escopo dos testes e do acesso 
que a equipe tem ao sistema.
120
1 O problema central de segurança em aplicações web está relacionado ao 
fato de que os usuários podem enviar entradas totalmente arbitrárias às 
aplicações (BRAGA, 2007; AMUI, 2015). Então, é preciso considerar que todas 
as entradas são maliciosas. Conforme Amui (2015), esse problema de envio 
de entradas arbitrárias pode se manifestar de várias maneiras. Considerando 
essa afirmação, descreva as possíveis entradas arbitrárias. 
2 Uma gestão eficiente possibilita, à empresa, um ritmo de melhoria contínua 
em relação ao uso dos recursos de tecnologia da informação (MARROW, 2019; 
RUFINO, 2020). Os hábitos de monitorar continuamente a segurança dos 
dados e buscar novos modos de usá-los são tendências importantes, que geram 
a evolução do negócio. Dessa forma, assinale a alternativa INCORRETA:
a) ( ) O investimentoem segurança minimiza os riscos de incidentes.
b) ( ) As empresas buscam, cada vez mais, efetivar negócios com quem 
garante a integridade dos dados compartilhados.
c) ( ) A gestão em segurança da informação adota medidas mais eficazes 
de proteção, promovendo um alinhamento da Tecnologia da Informação 
(TI) às estratégias de negócios da empresa. 
d) ( ) A garantia da segurança possibilita o enfraquecimento de parcerias 
comerciais à empresa. 
3 As vulnerabilidades encontradas são localizadas através de mecanismos 
buscadores que usam relatórios comuns, disponíveis em repositórios abertos 
(SÊMOLA, 2003; MENEZES, 2006; FERNANDES, 2013). Acerca do exposto, 
classifique V para as sentenças verdadeiras e F para as sentenças falsas:
 
( ) National Vulnerability Database (NVD), mantido pelo Instituto Nacional de 
Padrões e Tecnologia (National Institute of Standards and Technology, NIST).
( ) Existem poucos padrões e repositórios disponíveis, o que dificulta o pro-
cesso de avaliação de vulnerabilidades. 
( ) Common Vulnerabilities and Exposures (CVE), mantido pelo MITRE Corpo-
ration.
( ) Open Vulnerability and Assessment Language (OVAL), mantido, também, 
pelo MITRE.
Assinale a alternativa que apresenta a sequência CORRETA:
( ) V – V – V – V.
( ) V – F – V – V.
( ) F – F – V – V.
( ) V – V – F – V.
AUTOATIVIDADE
121
4 Conforme Cruz (2017, p. 20), “[...] um scanner de vulnerabilidades é uma 
ferramenta que acessa uma variedade de sistemas de informação, fornecendo 
relatórios das vulnerabilidades identificadas no sistema”. Considerando essa 
afirmação, descreva os componentes de um scanner.
5 A vulnerabilidade é considerada como uma fraqueza que pode ser explorada 
no sistema, já o patch é a resposta a uma vulnerabilidade. O patch pode 
eliminar uma ou mais vulnerabilidades. O que se precisa considerar é que o 
ciclo de vida de uma vulnerabilidade é composto por cinco fases (JUNIOR, 
2009; BASTOS, 2010; HOLANDA; FERNANDES, 2011; CARVALHO, 2017; 
CRUZ, 2017). Dessa forma, assinale a alternativa INCORRETA:
a) ( ) Fase 1 ocorre antes da vulnerabilidade ser descoberta.
b) ( ) Fase 2 ocorre depois da vulnerabilidade ser descoberta, porém, antes 
de ela ser divulgada.
c) ( ) Fase 3 ocorre após a vulnerabilidade ser anunciada.
d) ( ) Fase 4 os administradores de sistemas instalam os patches, minimi-
zando o risco de exploração da vulnerabilidade.
122
123
1 INTRODUÇÃO
Em 1994, o Internet Architecture Board (IAB) liberou um relatório 
denominado de Security in the Internet Architecture (Segurança na Arquitetura 
da Internet). No relatório, existe um consenso de que a internet precisa de mais 
segurança, e ainda identificou as principais áreas para mecanismos de segurança 
(STALLINGS, 2008). 
Dentra essas medidas, estavam a proteção da infraestrutura da rede 
contra o monitoramento e o controle sem autorização do tráfego da rede, além da 
necessidade de proteção do tráfego do usuário final, utilizando mecanismos de 
autenticação e de criptografia (STALLINGS, 2008).
Ao longo do tempo, os ataques na internet e em sistemas conectados à 
internet se tornaram mais sofisticados, mas as habilidades e o conhecimento 
técnico necessário para montar um ataque reduziram (ALMEIDA, 2012; PEREIRA, 
2018; FERREIRA, 2019). 
2 CONTROLE DE ACESSO AO CÓDIGO-FONTE DO 
PROGRAMA
Os ataques, conforme vimos no Tópico 1, tornaram-se mais automatizados 
e geram maiores danos.
UNIDADE 2 TÓPICO 3 — 
SEGURANÇA DOS ARQUIVOS DO SISTEMA
124
UNIDADE 2 — SEGURANÇA NO DESENVOLVIMENTO DE APLICAÇÕES WEB
FONTE: O autor
O que você pode observar é que esses aumentos nos ataques têm relação 
com a utilização da internet e com o aumento da complexibilidade dos protocolos, 
aplicações e da própria internet (FERREIRA, 2019). 
O funcionamento de um sistema computacional é definido pelo software e os 
arquivos de dados que nele estão. Já os outros fatores são as entradas de dados realizadas 
pelos usuários através de redes de computadores. Assim, os arquivos são muito importantes 
para a manutenção do funcionamento adequado dos computadores, tornando-se clara a 
importância de protegê-los. Conforme a ISO/IEC 17799, deve-se garantir a segurança dos 
arquivos de sistema, além de ter uma forma de controle de acessos aos arquivos e aos 
códigos-fonte dos softwares executados (HOLANDA; FERNANDES, 2011; PEREIRA, 2011; 
PEREIRA, 2018).
NOTA
GRÁFICO 4 – TENDÊNCIAS NA SOFISTICAÇÃO DO ATAQUE E CONHECIMENTO DO INTRUSO
TÓPICO 3 — SEGURANÇA DOS ARQUIVOS DO SISTEMA
125
É importante que se tenha o controle de acesso ao código-fonte dos 
programas e dos itens associados, com o objetivo de prevenção da inserção 
de funcionalidade não autorizada, além de evitar alterações não intencionais. 
Considerando os códigos-fonte de programas, o controle pode ser realizado com 
a guarda centralizada do código, de preferência, usando bibliotecas de programa-
fonte (PEREIRA, 2018; FERREIRA, 2019). 
A ISO 17799 apresenta algumas diretrizes de orientações para o controle 
de acesso às bibliotecas de programa-fonte, com o objetivo de minimizar o risco 
de corrupção de sistemas (HOLANDA; FERNANDES, 2011; PEREIRA, 2011; 
PEREIRA, 2018): 
• evitar manter as bibliotecas de programa-fonte no mesmo ambiente dos 
sistemas operacionais; 
• implementar o controle do código-fonte de programa e das bibliotecas de 
programa-fonte, de acordo com os procedimentos estabelecidos; 
• restringir o acesso do pessoal de suporte às bibliotecas de programa-fonte; 
• atualizar as bibliotecas de programa-fonte e itens associados e a entrega 
de fontes de programas a programadores seja somente realizada após o 
recebimento da autorização; 
• manter as listagens dos programas em ambiente seguro; 
• manter um registro de auditoria de todos os acessos ao código fonte de 
programa. 
2.1 CODIFICAÇÃO SEGURA
Um programador profissional precisa de uma formação qualificada em 
fundamentos de programação e de engenharia de software. Além disso, precisa 
buscar continuamente conhecimento das novas plataformas computacionais, 
linguagens e bibliotecas de programação (BATISTA, 2007; SOUZA, 2012; OWASP, 
2013; PRAZERES, 2015; SEGINFOCAST, 2016; FERREIRA, 2019).
As inovações tecnológicas são lançadas a grande velocidade, mas 
juntamente com elas é inserido a maioria das vulnerabilidades. 
Utilizar as novas tecnologias demanda que o programador se atualize 
continuamente, para ter acesso constante à documentação sobre a plataforma e 
linguagens de uso, como disponíveis nos sítios da Microsoft, da Oracle e da IBM 
(HOLANDA; FERNANDES, 2011; FERREIRA, 2019). 
Agora o que é codificação segura? A codificação segura é a ação de escrever 
e desenvolver softwares protegidos contra vulnerabilidades que poderiam surgir 
no futuro e que corresponde a uma das etapas do processo de desenvolvimento 
do software (SOUZA, 2012; SEGINFOCAST, 2016; FERREIRA, 2019).
126
UNIDADE 2 — SEGURANÇA NO DESENVOLVIMENTO DE APLICAÇÕES WEB
O processo de desenvolver códigos seguros é essencial para todos os 
softwares, independentemente de programador desenvolver códigos executados 
em dispositivos móveis, computadores pessoais, servidores ou qualquer outro 
tipo dispositivo (BATISTA, 2007; SEGINFOCAST, 2016; FERREIRA, 2019).
FIGURA 16 – ETAPAS DO PROCESSO DE DESENVOLVIMENTO DO SOFTWARE
FONTE: <http://bit.ly/2WDxg3R>. Acesso em: 21 jun. 2020.
Outro ponto importante a ser considerado sobre a codificação segura é que 
a maioria dos códigos de aplicativo pode utilizar simplesmente a infraestrutura 
implementada pelo .NET (PEREIRA, 2018; FERREIRA, 2019).
Agora, vamos entender o que é .NET.
O .NET é considerado um framework da Microsoft para desenvolvimen-
Pesquisa efetuada pela Cast Software acerca do estado da segurança do 
software mostrou que há 1,3 milhão de vulnerabilidades nos códigos analisados.
NOTA
TÓPICO 3 — SEGURANÇA DOS ARQUIVOS DO SISTEMA
127
to Web, fornecendo comodidades de reutilização e reaproveitamento de código, 
bem como outras facilidades de utilização(PEREIRA, 2018; FERREIRA, 2019). A 
plataforma possui os seguintes recursos vinculados à interface:
• acesso a dados;
• conectividade a banco de dados;
• criptografia;
• comunicações de rede;
• ambiente de desenvolvimento web. 
Uma das grandes vantagens do .NET é que desenvolvedores possuem 
um ambiente virtual controlado, já que ao escrever o código para uma aplicação 
específica, ele passa a escrever para a plataforma. Esse é considerado um pacote 
de classes com soluções codificadas para a solução de problemas usuais de 
programação e ainda pode suportar muitas linguagens de programação no 
ambiente (PEREIRA, 2018; FERREIRA, 2019).
Outro ponto importante é que utilizando as permissões impostas do 
.NET e outras imposição em seu código, o programador precisa colocar barreiras 
impedindo que um código mal-intencionado tenha acesso às informações 
(PEREIRA, 2018; FERREIRA, 2019).
Ainda, é preciso ter um equilíbrio entre segurança e usabilidade em todos 
os ambientes utilizando código confiável. Entretanto, é preciso considerar que 
em alguns casos, é necessária uma segurança adicional específica do aplicativo, 
elaborada através da extensão do sistema de segurança ou utilizando novos 
métodos ad hoc (PAIVA; MEDEIROS, 2008; PEREIRA, 2018; FERREIRA, 2019).
Essa visão descreve os diferentes modos como o código pode ser projetado 
para funcionar com o sistema de segurança. Ao projetar e escrever seu código, é 
necessário proteger e limitar o acesso que o código tem aos recursos (HOLANDA; 
FERNANDES, 2011; ALMEIDA, 2012; CINTO, 2015). Contudo, utilize as seguintes 
técnicas para garantir que seu código seja efetivamente mais seguro (ALMEIDA, 
2012; AMUI, 2015):
• Não utilize a segurança de acesso do código. 
• Não utilize código parcialmente confiável.
• Não utilize o atributo Allow Partially Trusted Caller (APTCA).
• Não utilize a comunicação remota do .NET.
• Não utilize Component Object Model distribuída (DCOM).
• Não utilize formatadores binários.
128
UNIDADE 2 — SEGURANÇA NO DESENVOLVIMENTO DE APLICAÇÕES WEB
Uma pesquisa realizada pela revista Americana Software Development 
Magazine revelou que os processos do desenvolvimento de software que são mais 
terceirizados são a codificação, seguido por testes e manutenção. Por isso, o cuidado na 
escolha de empresa que preze pela segurança das informações.
NOTA
2.2 CODIFICAÇÃO SEGURA NO CERT
O Secure Coding Initiative (CERT) é uma iniciativa da universidade de 
Carnegie Mellon financiada pelo governo dos Estados Unidos da América (EUA), 
que define os seguintes aspectos (HOLANDA; FERNANDES, 2011): 
• padrões de codificação segura para as linguagens C, C++ e Java; 
• padrões internacionais para codificação segura; 
• laboratório para avaliação de conformidade em codificação segura; 
• ferramentas de software que realizam análise estática de código; 
• processo de desenvolvimento de software seguro TSP-C. 
2.3 CODIFICAÇÃO SEGURA NO PROJETO ABERTO DE 
SEGURANÇA EM APLICAÇÕES WEB (OWASP)
O OWASP oferece, além do arcabouço de processo CLASP, uma série de 
informações e ferramentas em temas como (HOLANDA; FERNANDES, 2011; 
SOUZA, 2012; OWASP, 2013): 
• Princípios de codificação segura. 
• Bibliotecas de programação segura, envolvendo aspectos como validação de 
HTML e CSS em várias linguagens de programação. 
• Guia de revisão de código para identificar vulnerabilidades de estouro de 
buffers, injeção de código (SQL, XPATH e LDAP), validação de dados, cross-
site scripting, cross-site request forgery, logging issues, integridade de sessões e 
condições de corrida (race conditions).
• Melhores práticas de codificação segura e guias em linguagens e plataformas 
.NET, Ruby on Rails, Java, ASP, PHP, C, C++, MySQL, Flash, Ajax e Web Services. 
• Exemplos de como relatar vulnerabilidades encontradas. 
• Guia de teste de software para segurança.
Uma boa parte dos materiais desenvolvidos pela OWASP é elaborado 
para apoiar a execução de treinamentos. O WebGoat, é uma aplicação Web gratuita 
e de código aberto, escrita em Java e desenvolvida com muitas vulnerabilidades 
TÓPICO 3 — SEGURANÇA DOS ARQUIVOS DO SISTEMA
129
(HOLANDA; FERNANDES, 2011; SOUZA, 2012; OWASP, 2013). A ferramenta 
pode ser baixada e instalada na intranet de uma organização e usada para ensino 
e aprendizagem de técnicas de ataque e defesa, através da exploração e reparo de 
vulnerabilidades como (HOLANDA; FERNANDES, 2011):
• Cross-site Scripting (XSS). 
• Vulnerabilidades no controle de acesso. 
• Vulnerabilidades na segurança de threads. 
• Manipulação de campos de formulário escondidos. 
• Manipulação de parâmetros HTTP.
• Manipulação de cookies de sessão fracos. 
• SQL injection. 
• Autenticação com falhas. 
• Comentários HTM. 
FIGURA 17 – WEBGOAT
FONTE: Holanda e Fernandes (2011, p. 13)
130
UNIDADE 2 — SEGURANÇA NO DESENVOLVIMENTO DE APLICAÇÕES WEB
O WebScarab consiste em um Proxy, que se coloca como intermediário 
entre um servidor web e um navegador web (HOLANDA; FERNANDES, 2011; 
SOUZA, 2012; OWASP, 2013). Colocando-se entre ambos, captura e manipula 
pedidos e respostas no protocolo http, possibilitando a análise do comportamento 
de aplicações web e a preparação de ataques a uma aplicação (HOLANDA; 
FERNANDES, 2011; SOUZA, 2012; FERRIRA, 2019). 
FIGURA 18 – INTERFACE WEBSCARAB
FONTE: Holanda e Fernandes (2011, p. 15)
2.4 CODIFICAÇÃO SEGURA NA MICROSOFT
No SDL, a Microsoft fornece muitas ferramentas gratuitas para apoiar à 
codificação segura em sua plataforma, e ainda outras que suportam fases anteriores 
e posteriores do ciclo de desenvolvimento (PRAZERES, 2015; CARVALHO, 2017). 
Segue uma lista de algumas ferramentas: 
• Threat Modeling Tool: ferramenta utilizada no desenho de arquiteturas 
seguras, independente de plataforma, e com interface amena a utilização de 
profissionais com pouco conhecimento técnico.
Para aprofundar seus conhecimentos a respeito da codificação segura, leia o 
Guia de Referência Rápida: https://owasp.org/www-pdf-archive/OWASP_SCP_Quick_Re-
ference_PT-BR_v1.0.pdf. Boa leitura!
DICAS
https://owasp.org/www-pdf-archive/OWASP_SCP_Quick_Reference_PT-BR_v1.0.pdf
https://owasp.org/www-pdf-archive/OWASP_SCP_Quick_Reference_PT-BR_v1.0.pdf
TÓPICO 3 — SEGURANÇA DOS ARQUIVOS DO SISTEMA
131
• Code Analysis for C/C++: utilizada para análise estática de código nas linguagens 
C e C++. 
• Microsoft Code Analysis Tool .NET: usado para analisar aplicações web do 
framework .NET e detectar possíveis vulnerabilidades a ataques de injeção e 
XSS. 
• Biblioteca anti-XSS: utilizada para evitar ataques de Cross-Site Scripting.
2.5 PRINCÍPIOS DA ARQUITETURA SEGURA 
Durante o processo de elaboração da arquitetura do software é importante 
balancear os seguintes objetivos (HOLANDA; FERNANDES, 2011; CARVALHO, 
2017; FERREIRA, 2019): 
• Custo.
• Performance.
• Manutenabilidade.
• Segurança.
É muito provável que um sistema com foco somente em segurança terá 
um baixo desempenho e vice-versa (FERNANDES, 2013; CARVALHO, 2017; 
MONTANHEIRO et al., 2017; MARROW, 2019). Conforme Carvalho (2017):
• Privilégios mínimos necessários: as permissões de acesso a recursos do 
dispositivo (Internet, Contatos, Fotos, entre outros) precisam ser os mínimos 
possíveis. Este modelo de menor privilégio possível envolve somente solicitar 
o que é realmente necessário para o funcionamento da aplicação. A sua 
adoção possibilita que a aplicação não afete os outros programas instalados 
no dispositivo e que os recursos funcionem do modo correto. 
• Evite ameaças comuns: essencial conhecer quais tipos de ameaças precisam 
ser levadas em consideração para o contexto da aplicação. É importante 
compreender como cada uma delas funciona e quais delas representam risco. 
• Separação de responsabilidades: devem ser atendidas múltiplas condições 
para finalizar uma tarefa sensível ou acessar uma informação sigilosa. 
• Defesa em Profundidade: aplicação com múltiplas camadas de proteção e 
cada camada fornece mecanismos de segurança, caso a segurança da camada 
anteriorseja transposta. 
• Falha segura: em situações que ocorreu uma falha o sistema deve retornar a 
um estado onde a segurança não foi comprometida.
• Evitar segurança por obscuridade: é essencial a obtenção de um controle de 
segurança bem implementado. 
• Isolamento de entidades não confiáveis: afastar entidades e processos não 
confiáveis evitando que o comportamento deles não afete o funcionamento 
adequado do sistema ou consiga acesso a áreas restritas. 
• Seguir práticas de programação segura: conhecer quais são as nuances e 
práticas de segurança que a linguagem do sistema oferece. A grande parte das 
linguagens possuem uma documentação completa e guias para realizar uma 
132
UNIDADE 2 — SEGURANÇA NO DESENVOLVIMENTO DE APLICAÇÕES WEB
programação segura. O aproveitamento dessas informações é importante 
para fazer um código o mais seguro possível. 
• Validar entradas: nas plataformas tradicionais, risco maior está em aplicações 
Web, já que possuem muitos campos a serem preenchidos de maneira livre. 
Entretanto, nos dispositivos móveis, as entradas de dados quase não possuem 
variação, limitando-se a esquemas, como picker, switch, table, ou seja, seletores 
com entradas definidas. 
É recomendado, ainda, evitar o armazenamento de informações 
confidenciais, como nomes de usuário ou senhas, no dispositivo ou em algum 
local de acesso fácil. 
Use sempre os recursos de criptografia e banco de dados provenientes da 
plataforma que permitem que os aplicativos armazenem tais informações com 
segurança e sem a necessidade de utilizar softwares de terceiros.
133
VAZAMENTO DE DADOS
Vazamento de dados são sempre um sinal de alerta para empresas e 
consumidores. Podem expor e-mails, credenciais de redes sociais, registros 
médicos, propriedade intelectual, segredos de negócio, informações financeiras 
e bancárias entre outras informações sensíveis. 
Apesar de grandes nomes como Facebook, Equifax e Capital One 
chamarem a atenção da grande mídia existem muitos outros casos acontecendo 
todos os dias em empresas de todos os tamanhos.
Dia 28 de Janeiro é o dia internacional da Privacidade de Dados. Uma 
iniciativa que surgiu em 2006 para difundir boas práticas de segurança e aumentar 
a conscientização sobre a importância de proteger dados pessoais tanto para 
empresas quanto para pessoas. 
A data corresponde à quando foi assinado na Europa a Convenção 108, de 
28 de janeiro de 1981 que foi uma das primeiras normas que garantiam o direito 
fundamental à privacidade.
MAS O QUE É VAZAMENTO DE DADOS?
Vazamento de dados é um incidente de segurança que expõe publicamente 
informações sensíveis que podem ser vistas, copiadas, roubadas, transmitidas ou 
usadas sem acesso autorizado.
Surpreendentemente, as principais causas de vazamentos não são 
apenas ataques cibernéticos como malware, phishing, spyware, ransomware etc., 
mas também falhas simples de configurações de segurança que poderiam ser 
corrigidas, evitando assim enormes prejuízos de reputação e perdas financeiras 
para as empresas vazadas. Outras causas podem incluir funcionários insatisfeitos 
ou mal-intencionados, erros sem intenção de funcionários, falta de conhecimento 
técnico ou expertise para proteger os dados ou o ambiente.
Apesar de serem difíceis de detectar o melhor a fazer para mitigar 
o iminente risco é implementar gestão de risco para detecção, contenção e 
comunicação no caso de um vazamento. Quanto mais rápida sua detecção menor 
o prejuízo. Algumas das maneiras mais comuns para a ocorrência de vazamento 
de dados:
LEITURA COMPLEMENTAR
https://www.coe.int/en/web/conventions/full-list/-/conventions/treaty/108/signatures
134
SENHAS FRACAS E CONTROLE DE ACESSO FALHO
Coisas que parecem tão simples de resolver como uma senha fraca ou falta 
de 2FA pode ocasionar um vazamento de dados. E mesmo as melhores senhas 
são inúteis frente a uma configuração de sistema ruim que deixa seu banco de 
dados aberto.
SQL INJECTION
SQL Injection é um tipo de ataque simples e que requer conhecimento 
técnico mínimo para ser realizado. Explora a falta de segurança de websites para 
obter acesso não autorizado à sua base de dados. Além de simples esse ataque 
pode ser automatizado.
PHISHING
Um pouco mais complexo, esse ataque requer engenharia social para 
manipulação de pessoas para obtenção de dados sensíveis. O exemplo clássico 
é o e-mail falso que é feito para parecer real, ou similar à algum e-mail que 
você conhece. Esse e-mail pode te pedir informações, te oferecer um crédito ou 
qualquer outra coisa. 
Clicando nos links do e-mail, você pode acabar instalando malwares, 
spywares ou mesmo ser direcionado para logins falsos em páginas similares a 
que você já conhece, fornecendo assim suas informações sensíveis.
EXPLORAÇÃO DE VULNERABILIDADES
Esse ataque tira proveito de vulnerabilidades ou bugs de softwares para 
obter acesso não autorizado a um sistema ou seus dados. Vulnerabilidades são 
buscadas por pesquisadores com o intuito de publicação de CVEs ou por 
criminosos com intenção de exploração maliciosa que causa prejuízo à empresa. 
Sistemas operacionais, navegadores e aplicações populares são alguns dos 
principais alvos e existem até exploit kits que tornam simples a exploração de 
vulnerabilidades sem conhecimento técnico por criminosos.
VAZAMENTO VIA FORNECEDORES
Você pode ter a melhor postura de ciber segurança internamente mas 
se não gerenciar o risco dos seus fornecedores de forma adequada pode acabar 
tendo seus dados vazados através de falhas de segurança dos mesmos.
As regulamentações de privacidade de dados como LGPD e GDPR 
requerem que as empresas informem os clientes e procurem remediar o vazamento 
de dados assim que eles ocorram. Os prejuízos de um vazamento de segurança 
não são apenas financeiros, mas também ocasionam perda de reputação cada vez 
mais evidente.
https://nvd.nist.gov/vuln
https://nvd.nist.gov/
135
Por isso, assim como na saúde, prevenção é sempre o melhor remédio. Isso 
torna essencial para organizações terem um programa de gestão de segurança 
da informação baseado em frameworks como ISO 27.001, NIST CyberSecurity 
Framework e CIS. Esses frameworks sugerem a adoção de controles e processos 
que permitem avaliar continuamente a segurança do ambiente organizacional e de 
todos envolvidos com a operação da empresa, sejam colaboradores, fornecedores 
e parceiros de negócio.
Além disso, sugerem a criação de procedimentos para incidentes de 
segurança da informação, de forma que todos os responsáveis por segurança 
e tecnologia na empresa, saibam como proceder em caso de um vazamento de 
dados.
ALGUNS CASOS REAIS DOS MAIORES VAZAMENTO DE DADOS
Com cada dia mais informações digitalizadas no mundo a tendência de 
crescimento de ataques cibernéticos e o risco de vazamento de dados tende a só 
aumentar. Veja alguns dos maiores casos que já ocorreram até hoje:
1. YAHOO
3 bilhões de contas
Outubro de 2017
Causa: spear phishing, entre outras.
Esse é até hoje, e de maneira disparada, o maior caso de vazamento de 
dados da história. Acontecido em 2013, mas apenas descoberto anos depois 
quando a Yahoo foi vendida para a Verizon, causou uma perda de 350 milhões de 
dólares no valor de venda da Yahoo. Foram roubados nomes, datas de nascimento, 
telefones e senhas armazenadas com criptografia fraca. 
https://www.gat.digital/guia-gestao-seguranca/
https://www.gat.digital/guia-gestao-seguranca/
https://www.verizonmedia.com/press/yahoo-provides-notice-to-additional-users-affected-by-previously/
136
Aadhaar é o sistema nacional de identidade da India, contém dados 
biométricos como impressões digitais, entre outros dados demográficos, 
da identidade de mais de 1.1 bilhões de cidadãos indianos. Os indianos são 
praticamente obrigados a se cadastrar na Aadhaar para acessar os serviços 
públicos. Todas essas informações foram vazadas. 
3. FIRST AMERICAN CORPORATION
885 milhões de registros
Abril de 2019
Causa: falha no desenvolvimento de aplicativo
2. AADHAAR
1.1 bilhões de pessoas
Marçode 2018
Causa: falha na API de sites, entre outros
https://www.zdnet.com/article/another-data-leak-hits-india-aadhaar-biometric-database/
137
A empresa de seguros e serviços financeiros vazou dados extremamente 
sensíveis contendo, por exemplo, informações bancárias detalhadas. Os 
documentos eram cópias digitalizadas que podiam ser acessadas via o site da 
empresa firstam.com. Eram documentos destinados à visualização apenas das 
partes envolvidas em uma transação (em grande parte de compra e venda de 
imóvel) que estavam acessíveis para qualquer um com o link, apenas alterando 
um único dígito e sem proteção de login, senha ou duplo fator de autenticação. 
O desenvolvedor Ben Shoval descobriu a falha da pior maneira possível: após 
visitar um link de seus próprios documentos.
4. VERIFICATIONS.IO
+763 milhões de e-mails
Fevereiro de 2019
Causa: banco de dados exposto
Os 763 milhões de e-mails foram encontrados por um pesquisador em 
uma instância MongoDB exposta publicamente. Além dos e-mails alguns registros 
continham telefones, nomes e outras informações sensíveis coletadas a partir do 
serviço de verificação de e-mails Verifications.io. 
https://krebsonsecurity.com/2019/05/first-american-financial-corp-leaked-hundreds-of-millions-of-title-insurance-records/
https://krebsonsecurity.com/2019/05/first-american-financial-corp-leaked-hundreds-of-millions-of-title-insurance-records/
https://securitydiscovery.com/800-million-emails-leaked-online-by-email-verification-service/
138
5. MARRIOT/STARWOOD
500 milhões de pessoas
Novembro de 2018
Causa: possível infecção de RAT (Remote Access Trojan) por phishing
As informações expostas incluirão nomes, números de passaporte, 
informações de contato e outras informações pessoais. As informações de cartão 
de crédito e débito estavam criptografadas, o que não garante que não foram 
também acessadas. O sistema da Starwood foi invadido em 2014 e o acesso não 
autorizado permaneceu até depois da compra da Starwood pela Marriot em 2016. 
A invasão foi descoberta apenas em 2018. As suspeitas são de que um grupo de 
inteligência contratado pelo governo da China estaria por trás do ataque.
6. FRIENDFINDER
412 milhões de pessoas
Outubro de 2016
Causa: abertura de rede através de exploit em arquivos locais
https://www.reuters.com/article/us-usa-cyber-congress/marriott-ceo-apologizes-for-data-breach-unsure-if-china-responsible-idUSKCN1QO217
139
Foram vazados 6 bancos de dados que incluíam nomes, e-mails, senhas da 
empresa que é dona de sites como o Adult Friend Finder, Penthouse.com, Cams.com, 
iCams.com e Stripshow.com. Entretanto, informações sensíveis como preferências 
sexuais não foram vazadas como em um incidente em 2015 da mesma empresa 
que teve 4 milhões de contas expostas. A maioria das senhas estava desprotegida 
ou contava apenas com um fraco algoritmo de criptografia SHA-1.
7. MICROSOFT
250 milhões de registros
Dezembro de 2019
Causa: falha em configurações de segurança em banco de dados
Os dados de suporte de 250 milhões de registros estavam amplamente 
acessíveis para qualquer um através do navegador de internet. Os dados incluíam 
e-mails, números de contrato, informações de pagamento, IPs, descrições de 
casos de suporte e notas internas marcadas como confidenciais. O vazamento 
foi descoberto em 28 de Dezembro que notificou a Microsoft que então descobriu 
que um banco de dados Azure interno utilizado para mensuração de analytics de 
suporte ao consumidor estava com falha na configuração. 
https://leakedsource.ru/blog/friendfinder
https://www.comparitech.com/blog/information-security/microsoft-customer-service-data-leak/
140
8. CAPITAL ONE
106 milhões de registros
Março de 2019
Causa: falha em configurações de segurança em firewalls Amazon
Os dados incluíam números da Previdência Social, seguridade social, 
contas bancárias, nomes de pessoas, endereços, pontuação de crédito, limites 
de crédito saldos e outras informações. Uma ex engenheira de software da 
Amazon, Paige Thompson, teria conseguido acesso explorando um firewall de 
aplicativos da Web (WAF) configurado incorretamente pela Capital One, um 
dos maiores bancos dos EUA. Ela também usou os servidores para minerar 
criptomoeda, “cryptojacking”, e finalmente acabou expondo os dados, e também 
sua identidade, no Github sendo denunciada ao FBI. A Capital One calcula entre 
US $100 milhões e US $150 milhões os custos relacionados ao hack, incluindo 
notificações de clientes, monitoramento de crédito, custos de tecnologia e suporte 
legal devido ao hack.
Além destes citados, muitos outros casos aconteceram em empresas como 
MySpace, Twitter, Facebook, Linkedin, Adobe, eBay, Quora, Dropbox, Tumblr 
etc.
FONTE: GAT. Vazamento de dados. 2020. Disponível em: https://www.gat.
digital/blog/vazamento-de-dados/. Acesso em: 19 jun. 2020.
https://www.capitalone.com/facts2019/
https://krebsonsecurity.com/tag/capital-one-breach/
https://www.gat.digital/blog/vazamento-de-dados/
https://www.gat.digital/blog/vazamento-de-dados/
141
RESUMO DO TÓPICO 3
Neste tópico, você aprendeu que:
• Ao longo do tempo, os ataques na internet e em sistemas conectados à internet 
se tornaram mais sofisticados, mas as habilidades e o conhecimento técnico 
necessários para montar um ataque reduziram (ALMEIDA, 2012; PEREIRA, 
2018; FERREIRA, 2019). 
• É importante que se tenha o controle de acesso ao código-fonte dos 
programas e dos itens associados, com o objetivo de prevenção da inserção de 
funcionalidade não autorizada, bem como evitar alterações não intencionais. 
Considerando os códigos-fonte de programas o controle pode ser realizado 
com a guarda centralizada do código, de preferência usando bibliotecas de 
programa-fonte (PEREIRA, 2018; FERREIRA, 2019). 
• A codificação segura é a ação de escrever e desenvolver softwares protegidos 
contra vulnerabilidades que poderiam surgir no futuro e que corresponde a 
uma das etapas do processo de desenvolvimento do software (SOUZA, 2012; 
SEGINFOCAST, 2016; FERREIRA, 2019).
• A maioria dos códigos de aplicativo pode utilizar simplesmente a infraestrutura 
implementada pelo .NET (PEREIRA, 2018; FERREIRA, 2019).
• .NET é considerado um framework da Microsoft para desenvolvimento Web, 
fornecendo comodidades de reutilização e reaproveitamento de código, bem 
como outras facilidades de utilização (PEREIRA, 2018; FERREIRA, 2019). 
• CERT Secure Coding Initiative é uma iniciativa da universidade de Carnegie 
Mellon financiada pelo governo dos EUA, que define os seguintes aspectos 
(HOLANDA; FERNANDES, 2011): padrões de codificação segura para 
as linguagens C, C++ e Java; padrões internacionais para codificação 
segura; laboratório para avaliação de conformidade em codificação segura; 
ferramentas de software que realizam análise estática de código e processo de 
desenvolvimento de software seguro TSP-C.
• OWASP oferece, além do arcabouço de processo CLASP, uma série de 
informações e ferramentas (HOLANDA; FERNANDES, 2011; SOUZA, 2012; 
OWASP, 2013).
• WebGoat é uma aplicação Web gratuita e de código aberto, escrita em Java 
e desenvolvida com muitas vulnerabilidades (HOLANDA; FERNANDES, 
2011; SOUZA, 2012; OWASP, 2013). 
• WebScarab consiste em um Proxy, que se coloca como intermediário entre 
142
um servidor web e um navegador web (HOLANDA; FERNANDES, 2011; 
SOUZA, 2012; OWASP, 2013). 
• No SDL, a Microsoft fornece muitas ferramentas gratuitas para apoiar a 
codificação segura em sua plataforma, e ainda outras que suportam fases 
anteriores e posteriores do ciclo de desenvolvimento (PRAZERES, 2015; 
CARVALHO, 2017).
143
1 A ISO 17799 apresenta algumas diretrizes de orientações para o controle 
de acesso às bibliotecas de programa-fonte, com o objetivo de minimizar o 
risco de corrupção de sistemas (HOLANDA; FERNANDES, 2011; PEREIRA, 
2011; PEREIRA, 2018). Considerando essa afirmação, descreva quais são as 
diretrizes da ISO 17799 em relação às bibliotecas de programa-fonte. 
2 A codificação segura é a ação de escrever e desenvolversoftwares protegidos 
contra vulnerabilidades que poderiam surgir no futuro e que corresponde a 
uma das etapas do processo de desenvolvimento do software (SOUZA, 2012; 
SEGINFOCAST, 2016; FERREIRA, 2019). Dessa forma, assinale a alternativa 
INCORRETA:
a) ( ) O processo de desenvolver códigos seguros é essencial para todos 
os softwares.
b) ( ) O processo de desenvolver códigos seguros é essencial para os códi-
gos executados em dispositivos móveis.
c) ( ) A maioria dos códigos de aplicativo pode utilizar simplesmente a 
infraestrutura implementada pelo .NET. 
d) ( ) O .NET é considerado um framework para desenvolvimento Web, 
fornecendo comodidades de reutilização e reaproveitamento de código. 
3 Durante o processo de elaboração da arquitetura do software é importante 
balancear os seguintes objetivos (HOLANDA; FERNANDES, 2011; 
CARVALHO, 2017; FERREIRA, 2019): custo, performance, manutenabilidade 
e segurança. Sobre o exposto, classifique V para as sentenças verdadeiras e F 
para as falsas:
 
( ) Privilégios mínimos necessários: as permissões de acesso a recursos do 
dispositivo precisam ser os mínimos possíveis.
( ) O modelo de menor acesso envolve solicitar somente o que será utilizado 
para o funcionamento da aplicação. 
( ) É essencial conhecer quais tipos de ameaças precisam ser levadas em 
consideração para o contexto da aplicação.
( ) Defesa em profundidade refere-se à aplicação com múltiplas camadas de 
proteção e cada camada fornece mecanismos de segurança.
Assinale a alternativa que apresenta a sequência CORRETA:
( ) V – V – V – V.
( ) V – F – V – V.
( ) F – F – V – V.
( ) V – V – F – V.
AUTOATIVIDADE
144
4 Em 1994, o Internet Architecture Board (IAB) liberou um relatório denominado 
“Security in the internet architecture” (Segurança na arquitetura da Internet). 
No relatório existe um consenso de que a internet precisa de uma melhor 
segurança, e ainda identificou as principais áreas para mecanismos de 
segurança (STALLINGS, 2008). Considerando essa afirmação, analise a figura 
a seguir e descreva as tendências dos ataques ao longo do tempo.
FONTE: O autor
5 As inovações tecnológicas são lançadas em grande velocidade, mas 
juntamente com elas é inserida a maioria das vulnerabilidades. Utilizar as 
novas tecnologias demanda que o programador se atualize continuamente, 
para ter acesso constante à documentação sobre a plataforma e linguagens 
de uso, como disponíveis nos sítios da Microsoft, da Oracle e da IBM 
(HOLANDA; FERNANDES, 2011; FERREIRA, 2019). Dessa forma, assinale a 
alternativa INCORRETA:
a) ( ) Ao projetar e escrever seu código, é necessário proteger e limitar o 
acesso que o código tem aos recursos.
b) ( ) É preciso ter um equilíbrio entre segurança e mobilidade em todos 
os ambientes utilizando código confiável.
c) ( ) O processo de desenvolver códigos seguros é essencial para todos 
os softwares, independentemente de programador desenvolver códigos 
executados em dispositivos móveis, computadores pessoais, servidores 
ou qualquer outro tipo dispositivo.
d) ( ) A codificação segura é a ação de escrever e desenvolver softwares 
protegidos contra vulnerabilidades.
145
REFERÊNCIAS
ALMEIDA, C. R. Segurança de aplicações web: experimentos e taxonomia de 
ataques. Revista Tecnologias em Projeção, v. 3, n. 1, p. 1, 2012.
AMBLER, S. W. Modelagem ágil – práticas eficazes para a programação extre-
ma e o processo unificado. Porto Alegre: Bookman, 2004.
AMUI, S. F. Processos de desenvolvimento de software. Rio de Janeiro: SESES, 
2015.
ANDERSON, P.; BACKWOOD, A. Mobile and PDA technologies and their 
future use in education. USA: JISC Technology and Standards Watch, 2004.
ANDERSON, R. Security engineering. 2. ed. Inglaterra: Wiley, 2008. 
ANSARI, J. A. Web penetration testing with Kali Linux. [S.l.: s.n.], 2015. 
ARONSON, J.; LIANG, T.; TURBAN, E. Decision support systems and intelli-
gent systems. Upper Saddle River: Pearson, 2005. 
BALTAZAN, P. Sistemas de informação. Porto Alegre: AMCH, 2012.
BASSO, T. Uma abordagem para avaliação da eficácia de scanners de vulnera-
bilidade em aplicações web. São Paulo: Universidade Estadual de Campinas, 
2010. 
BASTOS, L. R. Inclusão de segurança no processo de desenvolvimento de apli-
cações web: um estudo de cenário e possibilidades no Banco Central do Brasil. 
Brasília: Universidade de Brasília, 2010.
BATISTA, C. F. A. Métricas de segurança de software. Rio de Janeiro: Pontifícia 
Universidade Católica do Rio de Janeiro, 2007.
BAZARA, I. A.; STAVROULAKIS, P.; STAMP, M. Intrusion detection systems. 
Alemanha: Springer Berlin Heidelberg, 2010. 
BRAGA, A. M. Visão geral das boas práticas para construção de softwares segu-
ros. Revista Técnica IPEP, São Paulo, v. 7, n. 2, p. 65-78, 2007.
BRASIL. Lei Geral de Proteção de Dados Pessoais (LGPD). 2019. Disponível 
em: http://www.planalto.gov.br/ccivil_03/_ato2015-2018/2018/lei/L13709.htm. 
Acesso em: 29 set. 2020. 
146
CARVALHO, E. T. R. de. Criação de um guia de boas práticas para desenvolvi-
mento seguro. Brasília: Universidade de Brasília, 2017. 
CHOO, C. W. A organização do conhecimento: como as organizações usam a 
informação para criar significado, construir conhecimento e tomar decisões. 2. 
ed. São Paulo: SENAC, 2003.
CINTO, N. A. Teste de vulnerabilidades em aplicações web. Assis: Instituto 
Municipal Educacional do Município de Assis – IMESA; Fundação Educacional 
do Município de Assis – FEMA, 2015.
COELHO, H. S. Documentação de software: uma necessidade. Texto Livre, v. 1, 
n. 2, p. 1, 2009.
COSTA, T. M. Melhoria contínua de processo de software utilizando a teoria 
das restrições. Rio de Janeiro: UFRJ, 2012. 
CRESPO, A. N. et al. Uma metodologia para teste de software no contexto da 
melhoria de processo. Campinas: Unicamp, 2004 
CRUZ, C. M. B. R. da. Auditoria de segurança da informação em sistemas e 
aplicações. Brasília: Universidade de Brasília – UnB, 2017. 
DEVMEDIA. TDD: fundamentos do desenvolvimento orientado a testes. 2017. 
Disponível em: https://www.devmedia.com.br/tdd-fundamentos-do- desenvol-
vimento-orientado-a-testes/28151. Acesso em: 20 jun. 2020. 
DIAS, C. Segurança e auditoria da tecnologia da informação. Rio de Janeiro: 
Axcel Books, 2000.
FAGUNDES, R. M. Engenharia de requisitos – Do perfil do analista de requi-
sitos ao desenvolvimento de requisitos com UML e RUP. Salvador: Faculdades 
Integradas de Três Lagoa, 2011.
FERNANDES, N. O. C. Segurança da informação. Mato Grosso: Universidade 
Federal do Mato Grosso, 2013.
FERREIRA, D. G. Arquitetura segura no desenvolvimento de software: abor-
dagem à plataforma digital U. OPENLAB. Portugal: Universidade do Porto, 
2019. 
FONTES, E. Praticando a segurança da informação. Rio de Janeiro: Brasport, 
2008.
GITHUB. February 28th DDoS incident report. 2018. Disponível em: https://gi-
thubengineering.com/ddos-incident-report/. Acesso em: 11 jun. 2020. 
147
HOLANDA, M. T. de; FERNANDES, J. H. C. Segurança no desenvolvimento 
de aplicações. Brasília: Gestão da Segurança da Informação e Comunicações, 
2011. 
IMONIANA, J. O. Auditoria de sistemas de informação. São Paulo: Atlhas, 
2005.
ISO/IEC. ISO/IEC 17799 – Tecnologia da Informação – Técnicas de Segurança – 
Código de Prática para a Gestão de Segurança da Informação. 2005. Disponível 
em: http://17799.denialinfo.com/. Acesso em: 11 dez. 2020.
JORDÃO, R. E. M. Armazenamento distribuído de dados seguros com esque-
ma de consultas diretas. Brasília: Universidade de Brasília – UnB, 2014.
JUNIOR, A. G. da S. Cross-site scripting: uma análise prática. Pernambuco: Uni-
versidade Federal de Pernambuco, 2009.
KLEINA, N. Hackers por trás da botnet Mirai escapam da prisão por ajudarem 
o FBI. 2018. Disponível em: http://bit.ly/3nK98bV. Acesso em: 19 jun. 2020. 
LUZ, H. J. F. Análise de vulnerabilidades em Java Web Applications. São Pau-
lo: Centro Universitário Eurípides de Marília, 2011.
MARROW, S. O mais importante de tudo é manter-se atualizado com as vul-
nerabilidades emergentes. 2019.Disponível em: http://bit.ly/3pvTm4X. Acesso 
em: 11 jun. 2020. 
MARTIM, B.; BROWN, M.; PALLER, A.; KIRBY, D. 2010 CWE/SANS Top 25 
most dangerous software errors. 2011. Disponível em: http://cwe.mitre.org/
top25/archive/2010/2010_cwe_sans_top25.pdf. Acesso em: 18 jun. 2020. 
MARTINS, J. C. C. Gestão de projetos de segurança de informação. Rio de 
Janeiro: Brasport, 2003. 
MENEZES, J. das C. Gestão da segurança da informação. Leme: Mizuno, 2006. 
MONTANHEIRO, L. S. et al. Utilização de JSON Web Token na autenticação 
de usuários em APIs REST. Catalão: Universidade Federal de Goiás (UFG), 
2017. 
MOUGOUE, E. Secure sdlc 101. MOUGOUE, E. Journal of Bussisnes Finance e 
Accounting. Vol. 30., 2016. 
NAVAJAS, R. Uma proposta de gerenciamento de atualizações de segurança 
(patches). Brasília: Departamento de Ciência da Computação da Universidade 
de Brasília, 2010. 
http://17799.denialinfo.com/
http://cwe.mitre.org/top25/archive/2010/2010_cwe_sans_top25.pdf
http://cwe.mitre.org/top25/archive/2010/2010_cwe_sans_top25.pdf
148
OWASP. OWASP Top 10 2013 – The ten most critical web application secu-
rity risk. 2013. Disponível em: https://www.owasp.org/images/f/f8/OWASP_
Top_10_-_2013.pdf. Acesso em: 19 jun. 2020. 
OWASP. OWASP Top 10: the ten most critical web application security risk. 
2010. Disponível em: http://www.owasp.org/index.php/Category:OWASP_Top_
Ten_Project. Acesso em: 3 jun. 2020.
PAIVA, A.; MEDEIROS, I. B. K. Uma abordagem de caso de integração entre os 
processos de tratamento de incidentes de segurança computacionais e desen-
volvimento de software. Brasília: Departamento de Ciência da Computação da 
Universidade de Brasília, 2008. 
PAYÃO, F Hackers realizam o maior ataque DDoS da história. 2016. Disponível em: 
https://www.tecmundo.com.br/internet/110078-hackers-realizam-maior-ataque-ddos-
-historia.htm. Acesso em: 19 jun. 2020. 
PEREIRA, H. Sistema de Detecção de Intrusão para Serviços Web Baseado 
em Anomalias. Curitiba: Pontifícia Universidade Católica do Paraná – PUCPR, 
2011.
PEREIRA, P. de L. Automatização de testes de penetração em aplicações web. 
Brasília: Universidade de Brasília, 2018. 
PILZ, B.; GATTI, C. Hamdroid: ferramenta mobile para controle de invasões. 
Revista da Graduação, v. 6, n. 1, p. 1, 2013.
PRAZERES, A. P. Princípios para o desenvolvimento de software seguro. Flo-
rianópolis: Universidade do Sul de Santa Catarina, 2015. 
PRESSMAN, R. S. Engenharia de software. 7. ed. São Paulo: McGraw-Hill, 2011. 
RUFINO, I. Entra em vigor a Lei Geral de Proteção de Dados. 2020. Disponível em: 
http://bit.ly/3nKMyji. Acesso em: 29 set. 2020. 
SCARFONE, K.; PETER, M. The Common Configuration Scoring System 
(ccss): metrics for software security configuration vulnerabilities. Gaithersburg: 
National Institute of Standards and Technology, 2010. 
SCHETINA, E.; CARLSON, J. Sites seguros: aprenda a desenvolver e construir. 
Rio de Janeiro: Campus, 2002. 
SEGINFOCAST. Análise de código e segurança de software. 2016. Disponível 
em: http://bit.ly/38z2BKu. Acesso em: 29 jun. 2020. 
SÊMOLA, M. Gestão da segurança da informação: uma visão executiva. Rio de 
Janeiro: Campus, 2003. 
https://www.tecmundo.com.br/internet/110078-hackers-realizam-maior-ataque-ddos-historia.htm
https://www.tecmundo.com.br/internet/110078-hackers-realizam-maior-ataque-ddos-historia.htm
149
SOMMERVILLE, I. Engenharia de software. 7. ed. São Paulo: Editora Pearson 
do Brasil, 2007.
SOMMERVILLE, I. Engenharia de software. 6. ed. São Paulo: Editora Pearson 
do Brasil, 2003. 
SOUZA, L. L. Desenvolvimento seguro de aplicações web seguindo a metodo-
logia OWASP. Minas Gerais: Universidade Federal de Lavras, 2012.
STALLINGS, W. Criptografia e segurança de redes. São Paulo: Pearson Prentice 
Hall, 2008.
TAGARRO, G. O android se mostrou o software com mais falhas de segurança em 
2019. 2019. Disponível em: https://mundoconectado.com.br/noticias/v/12745/de-
bian-linux-e-o-sistema-operacional-mais-vulneravel-dos-ultimos-20-anos-apon-
ta-pesquisa. Acesso em: 20 jun. 2020.
TORRES, N. A.; TORRES, M. G. ANS – Acordo de Nível de Serviço: para o 
sucesso da terceirização, é necessário que haja bons contratos que estabeleçam 
claramente os níveis de serviços combinados! São Paulo: Unicom Negócios; 
Processos e Sistemas, 2016.
VIANA, S.; SILVA, R.; CENTRO, J. P.; LAINE, J. M. Segurança no desenvolvi-
mento de aplicações web com a qualidade dos dados. Revista de Sistemas e 
Computação, Salvador, v. 3, n. 2, p. 93-104, 2013. 
https://mundoconectado.com.br/noticias/v/12745/debian-linux-e-o-sistema-operacional-mais-vulneravel-dos-ultimos-20-anos-aponta-pesquisa
https://mundoconectado.com.br/noticias/v/12745/debian-linux-e-o-sistema-operacional-mais-vulneravel-dos-ultimos-20-anos-aponta-pesquisa
https://mundoconectado.com.br/noticias/v/12745/debian-linux-e-o-sistema-operacional-mais-vulneravel-dos-ultimos-20-anos-aponta-pesquisa
150
151
UNIDADE 3 — 
SEGURANÇA E AUDITORIA 
NO DESENVOLVIMENTO 
DO SOFTWARE
OBJETIVOS DE APRENDIZAGEM
PLANO DE ESTUDOS
 A partir do estudo desta unidade, você deverá ser capaz de:
• compreender a importância da auditoria no processo de desenvolvi-
mento dos softwares;
• assimilar a relação entre a auditoria e a importância da identificação 
prévia dos problemas;
• conhecer as diferentes metodologias que auxiliam no processo de audi-
toria; 
• compreender a importância dos treinamentos para o processo de segu-
rança;
• reconhecer o papel do usuário no processo de segurança do software.
 Esta unidade está dividida em três tópicos. No decorrer da unidade, 
você encontrará autoatividades com o objetivo de reforçar o conteúdo 
apresentado.
TÓPICO 1 – AUDITORIA DO DESENVOLVIMENTO DE SISTEMAS
TÓPICO 2 – AVALIAÇÃO DO SOFTWARE DE AUDITORIA DE SISTEMAS
TÓPICO 3 – TREINAMENTO DE SEGURANÇA
Preparado para ampliar seus conhecimentos? Respire e vamos 
em frente! Procure um ambiente que facilite a concentração, assim absorverá 
melhor as informações.
CHAMADA
152
153
UNIDADE 3
1 INTRODUÇÃO
Os softwares recebem inúmeras melhorias com o objetivo de se adequar 
aos novos padrões de negócios. Em função da necessidade contínua de tornar 
os processos mais eficientes, tem sido exigida a utilização de tipos diferentes 
de softwares (ALVES, 2016; SAM, 2020). A contratação e a renovação dessas 
ferramentas são comuns e precisam ser realizadas com agilidade para não 
prejudicar a rotina da empresa (SILVA, 2007; COSTA, 2010; ALVES, 2016). O 
grande problema é que esses processos, muitas vezes, prejudicam a integridade 
dos recursos e dados empresariais (ALVES, 2016; SAM, 2020). Nessas situações, 
a auditoria de software é uma solução para garantir a segurança das informações 
(SILVA, 2007; NETO, 2012; ALVES, 2016). 
A auditoria tem, como objetivos, analisar toda a infraestrutura, verificar as 
possibilidades de violações de segurança e examinar todo o controle interno dos 
sistemas de uma organização (IMONIANA, 2005; SILVA, 2007; COSTA, 2010). 
Um grande ponto a ser considerado é que a auditoria não é somente um processo 
burocrático, mas estratégico (NOVO, 2010; NETO, 2012), já que os resultados 
auxiliam em uma tomada de decisão mais segura, possibilitando a detecção de 
problemas de desenvolvimento dos softwares (IMONIANA, 2005). 
Ao longo deste tópico, vamos perceber que a auditoria tem, como objetivo, 
a detecção de diversos problemas relacionados à segurança, confiabilidade e 
interface de um sistema. Você irá, ainda, compreender a relação entre a auditoria 
e a importância da identificação prévia dos problemas para que os objetivos 
estabelecidos dentro da organização possam ser alcançados. 
2 CONCEITOS DE SISTEMAS
O sistema é formado por um conjunto de elementos inter-relacionados 
que fornecem relatórios que norteiam a tomada de decisão para uma organização 
(IMONIANA, 2005; NETO, 2012; ALVES, 2016). 
Nesse sentido, é possível compreender o processo que transforma os 
dados de entrada, agregado aos comandos gerenciais, em saídas (IMONIANA, 
2005). Assim, o feedbackdo sistema faz com que, no meio da manutenção do ciclo 
operacional, sejam ativadas novas estratégias empresariais, gerando informações 
qualitativas ou quantitativas (IMONIANA, 2005; SILVA, 2007).
TÓPICO 1 — 
AUDITORIA DO DESENVOLVIMENTO DE SISTEMAS
UNIDADE 3 — SEGURANÇA E AUDITORIA NO DESENVOLVIMENTO DO SOFTWARE
154
FIGURA 1 – REPRESENTAÇÃO ESQUEMÁTICA DE UM SISTEMA
FONTE: <https://bit.ly/3szZpaP>. Acesso em: 19 out. 2020.
Um sistema de informações é um produto de três componentes: 
• Tecnologia: meio pelo qual os sistemas de informação são implementados. 
Esse componente envolve o computador e demais equipamentos (hardware), 
os softwares, bancos de dados e os recursos de telecomunicações que 
interconectam os computadores em rede (IMONIANA, 2005; SILVA, 2007).
• Organizações: uma grande coleção de processos operacionais e administrativos. 
Os processos operacionais elaboram, desenvolvem e entregam os bens e 
serviços que são consumidos pelo mercado. Já os processos administrativos 
estão vinculados ao planejamento e ao controle da condução dos negócios. 
Vários desses procedimentos organizacionais são adicionados aos sistemas 
de informação (IMONIANA, 2005; SILVA, 2007).
• Pessoas: usuários efetivos que utilizam as informações de um sistema para 
realizar o trabalho. Esse componente é responsável pelas entradas no sistema, 
tornando-o um sistema produtivo (IMONIANA, 2005; SILVA, 2007).
A delimitação do sistema é efetuada durante o seu desenho para fomentar 
a segregação das funções dos sistemas incompatíveis. Podem ser adaptáveis, quando 
implantados para produzir um resultado desejado em um ambiente de grandes mudanças 
rotineiras, e corretivos, implantados para produzir um resultado específico, e não rotineiro 
(IMONIANA, 2005; SILVA, 2007).
NOTA
TÓPICO 1 — AUDITORIA DO DESENVOLVIMENTO DE SISTEMAS
155
FIGURA 2 – REPRESENTAÇÃO DOS TRÊS COMPONENTES DO SISTEMA DE INFORMAÇÃO
FONTE: <https://bit.ly/39FrftD>. Acesso em: 19 out. 2020.
Outro ponto importante acerca dos sistemas é a plataforma, que interfere 
no processo de segurança da informação.
• As plataformas de código aberto são confiáveis porque toda a comunidade 
está prestando atenção. No caso de aplicativos de código aberto, a comunidade 
de código aberto, composta por desenvolvedores, colaboradores e usuários da 
plataforma, faz contribuições. Coletivamente, encontram e tratam de questões vitais, 
como bugs e melhorias contínuas. Depois que uma falha for descoberta por um 
usuário, os desenvolvedores resolvem o problema e entregam a correção para toda a 
comunidade antes que o problema se agrave (GOMES, 2020).
• O software de código aberto precisa integrar o código-fonte, além de garantir a 
distribuição na forma de código-fonte e compilada (GOMES, 2020).
• O software, para ser considerado de código aberto, não deve discriminar qualquer tipo 
de pessoa ou especialidades de empreendimentos característicos. Isso significa que o 
software pode ser usado por todos que desejem (GOMES, 2020).
REPRESENTAÇÃO DAS PLATAFORMAS DE CÓDIGO ABERTO (OPEN SOURCE) E DE CÓ-
DIGO FECHADO (PROPRIETARY)
NOTA
https://blog.betrybe.com/tecnologia/codigo-fonte/
UNIDADE 3 — SEGURANÇA E AUDITORIA NO DESENVOLVIMENTO DO SOFTWARE
156
REPRESENTAÇÃO DAS PLATAFORMAS DE CÓDIGO ABERTO (OPEN SOURCE) E DE 
CÓDIGO FECHADO (PROPRIETARY)
FONTE: <http://bit.ly/3qnSIqu>. Acesso em: 19 out. 2020.
EXEMPLOS DE SOFTWARES DE CÓDIGO ABERTO (OPEN SOURCE)
FONTE: <https://www.timetoact.de/details/opensource>. Acesso em: 19 out. 2020.
3 CONCEITOS DE AUDITORIA DE SISTEMAS 
O termo auditoria pode ser utilizado para definir uma variedade 
significativa de atividades no nosso meio social. Conforme Neto (2012, p. 24), 
“auditoria compreende o processo sistemático de obtenção e avaliação de 
evidências com foco em afirmações sobre ações e eventos econômicos para avaliar 
o grau de correspondência entre essas afirmações e os critérios estabelecidos, para 
comunicação dos resultados aos usuários interessados”. 
TÓPICO 1 — AUDITORIA DO DESENVOLVIMENTO DE SISTEMAS
157
FIGURA 3 – VISÃO GERAL DO PROCESSO DE AUDITORIA
FONTE: Neto (2012, p. 24)
A definição proposta por Neto (2012) engloba os seguintes termos: 
QUADRO 1 – TERMOS DE AUDITORIA DE SISTEMAS
FONTE: Adaptado de Silva (2007) e Neto (2012)
TERMO DEFINIÇÃO 
Processo 
sistemático
Engloba uma série de etapas e procedimentos 
organizados de modo lógico e estruturado.
Obtenção e 
avaliação objetiva 
das evidências
Análise das bases das afirmações de modo justo e 
imparcial. 
Afirmações sobre 
ações e eventos 
econômicos
Declarações ou informações cedidas pelo indivíduo 
ou entidade correspondente aos assuntos sujeitos à 
auditoria. 
Grau de 
correspondência
Afinidade com que as afirmações são associadas com os 
critérios estabelecidos.
Critérios 
estabelecidos
Padrões contra os quais as afirmações ou 
representações são julgadas por meio de normas da 
administração da organização ou a partir de fontes 
externas. 
Comunicação dos 
resultados
Relatório formal que mostra o grau de correspondência 
entre as afirmações e os critérios definidos. 
Usuários 
interessados
Pessoas que utilizam ou confiam nas evidências 
apontadas pelos auditores. Incluem-se alta 
administração, acionistas, credores, órgãos 
governamentais e o público em geral. 
UNIDADE 3 — SEGURANÇA E AUDITORIA NO DESENVOLVIMENTO DO SOFTWARE
158
A auditoria deve concentrar os seus esforços na análise e avaliação dos 
processos de planejamento, desenvolvimento, testes e aplicação de sistemas, e 
examinando a estrutura lógica, física, ambiental, organizacional, de controle, 
segurança e proteção de dados (IMONIANA, 2005; SILVA, 2007; NETO, 2012, 
ALVES, 2016). A auditoria de informação pode ser visualizada sob três aspectos 
(NETO, 2012): 
• com relação à gestão documental na organização, gerando o diagnóstico e o 
plano de ação; 
• com relação à identificação, com o cumprimento de políticas e procedimentos 
de gestão de documentos, gerando o aperfeiçoamento dos métodos e 
processos; 
• com relação à avaliação da efetividade dos recursos documentais da 
organização, de modo a reduzir o silêncio (não obtenção de informação 
relevante) e o ruído (obtenção de informação irrelevante) na satisfação das 
necessidades de informação da organização.
Para compreender conceitos importantes de auditoria, observe o quadro 
a seguir:
QUADRO 2 – CONCEITOS DE AUDITORIA
CONCEITO DEFINIÇÃO
Controle
- Ação de controlar ou de dominar; inspeção; fiscalização. 
- Verificação de documentos ou serviços. 
- Verificação do funcionamento adequado do hardware e 
do software.
Auditoria interna 
- Auxilia a equipe de gestão no desempenho de 
atribuições e responsabilidades, com base nas suas 
avaliações e recomendações. 
- Realizada com recursos materiais e pessoal da própria 
empresa auditada. 
Auditoria 
externa 
- Realizada por entidades que não pertencem à empresa 
auditada. 
Auditoria 
tecnológica 
- Analisar as tecnologias que mais influenciam a 
formulação das estratégias e a respectiva competitividade. 
- As tecnologias são analisadas devido ao grau de 
adequação aos objetivos da organização. 
Tecnologias de 
informação 
- Conjunto de equipamentos e suportes lógicos (hardware 
e software) que executam tarefas, como aquisição, 
transmissão, armazenamento, recuperação e exposição de 
dados. 
Gestão de 
sistemas de 
informação 
- A gestão do recurso da informação e de todos os 
recursos envolvidos no planejamento, desenvolvimento, 
exploração e manutenção do sistema de informação. 
TÓPICO 1 — AUDITORIA DO DESENVOLVIMENTO DE SISTEMAS
159
FONTE: Adaptado de Imoniana (2005), Silva (2007), Neto (2012) e Alves (2016)
4 ABORDAGEM DE AUDITORIA DE SISTEMAS 
Em decorrência da complexidade dos ambientes e expansão dos negócios 
que atingiram muitas implementações na intranet e internet, existem diversos 
problemas quanto à vulnerabilidade de computadores e casos comuns de fraudes 
(IMONIANA, 2005; SILVA, 2007; COSTA, 2010).
Veja o quadrode softwares para antifraudes que ajudam as organizações 
a identificarem e a testarem as irregularidades para prevenir e combater desvios, 
perdas e fraudes com precisão.
QUADRO 3 – SOFTWARES PARA ANTIFRAUDES
Monitoramento 
- O sistema de controle interno deve ter a qualidade 
avaliada ao longo do tempo. A avaliação pode ser 
permanente, separada do processo normal ou uma 
combinação dos dois tipos. 
Atividades de 
controle
- Políticas e procedimentos que auxiliam a assegurar que 
as decisões gerenciais estão sendo seguidas. 
- Auxiliam para que ações sejam tomadas para mitigar 
riscos para que a organização alcance objetivos. 
Ambiente de 
controle 
- Compreende integridade, valores éticos e competência 
das pessoas da organização, filosofia gerencial e estilo 
operacional, o modo como a administração delega 
autoridade e responsabilidade, organiza e desenvolve as 
pessoas e a atenção e direção fornecidas pelo conselho de 
administração. 
SOFTWARE DESCRIÇÃO
Stripe Radar Auxilia a detectar e a bloquear fraudes para qualquer tipo de negócio, utilizando o aprendizado da máquina.
Konduto 
Antifraude
Segurança e análise comportamental de clientes em 
e-commerce. Em 2019, o software impediu que o comércio 
eletrônico sofresse R$ 5,4 bilhões em prejuízo com fraudes.
Total 
ClearSale
Gerenciamento de fraude da loja virtual automaticamente, 
combinando tecnologia avançada e inteligência artificial.
Fcontrol Atua no comércio eletrônico e utiliza sistemas de inteligência artificial.
Riskified Gerenciamento de riscos que analisa, aprova e garante transações.
UNIDADE 3 — SEGURANÇA E AUDITORIA NO DESENVOLVIMENTO DO SOFTWARE
160
Signifyd
Utiliza big data e aprendizado de máquina para se 
responsabilizar por fraudes, para que os comerciantes on-line 
possam oferecer, a seus clientes, segurança.
Kount Prevenção contra fraudes que ajuda comerciantes e varejistas on-line a impedirem a fraude e a aumentarem a receita.
Iovation
Fornece serviços de risco on-line para fraudes com cartão de 
crédito, aplicativos e outros tipos de prevenção de fraudes 
online.
Sift Detecção de fraudes, com uma solução flexível, adaptável e automatizada.
FONTE: Adaptado de <http://bit.ly/38UiDA3>. Acesso em: 19 out. 2020.
As áreas de Tecnologia da Informação (TI) das empresas possuem, geralmente, 
controles que mitigam algumas dessas vulnerabilidades (COSTA, 2010). Dessa forma, 
o objetivo do auditor de sistemas é verificar se esses controles funcionam de modo 
adequado e se estão em bom número (NETO, 2012; ALVES, 2016).
FIGURA 4 – CONTROLES DA TECNOLOGIA DA INFORMAÇÃO
FONTE: <http://bit.ly/3iqFu9O>. Acesso em: 19 out. 2020.
O espaço de atuação da auditoria de sistemas é a organização, sujeita, 
de modo transversal, a inúmeros tipos de riscos, transversais e presentes em 
todos os lugares, em toda a organização (NETO, 2012; ALVES, 2016). A seguir, 
será possível visualizar os três dos principais objetos que são alvo da auditoria: a 
informação, os sistemas e a tecnologia (SILVA, 2007; NETO, 2012). 
TÓPICO 1 — AUDITORIA DO DESENVOLVIMENTO DE SISTEMAS
161
FIGURA 5 – REPRESENTAÇÃO DA INTERPRETAÇÃO CONCEITUAL DA AUDITORIA DE 
SISTEMAS
FONTE: Silva (2007, p. 55)
Conforme Silva (2007, p. 55), “os riscos transversais presentes em toda 
organização são verificados na gestão de risco, sendo mais abrangente e tendo, por 
isso, funções de auditoria conceitualmente incluídas”. O gerenciamento de riscos 
pode ser aplicado a todas as atividades inclusas dentro de uma organização, não 
somente à aplicação da Tecnologia da Informação (TI) (SILVA, 2007; NETO, 2012). 
Assim, a TI não pode ser considerada de modo isolado, devendo ser tratada como 
parte integrante de todos os processos de negócios da organização. 
Considerando-se, então, que os processos de sistemas são parte integrante 
dos processos de negócio, reconhece-se que a auditoria de sistemas é uma 
parte especializada da auditoria de processos de negócio (SILVA, 2007; ALVES, 
2016). Assim, a auditoria de sistema deve englobar, no seu âmbito, a auditoria 
de tecnologias. A auditoria de sistemas atua no nível estratégico, gerencial ou 
operacional, sendo os trabalhos agrupados para alcançarem os objetivos e 
segmentados nas seguintes linhas de atuação (SILVA, 2007; COSTA, 2010; NETO, 
2012; ALVES, 2016):
• Auditoria de sistemas em produção: compreende os procedimentos e 
resultados dos sistemas de informação já implantados. Assim, possui 
características preventivas e corretivas.
UNIDADE 3 — SEGURANÇA E AUDITORIA NO DESENVOLVIMENTO DO SOFTWARE
162
• Auditoria durante o desenvolvimento de sistemas: compreende o processo 
total de desenvolvimento de sistemas de informação, considerando a fase de 
levantamento do sistema até o teste final de implantação.
• Auditoria do ambiente de tecnologia da informação: compreende a análise 
do ambiente de informática em relação à estrutura; contratos de software 
e hardware; normas técnicas e operacionais; recursos financeiros; uso dos 
equipamentos; elaboração dos planos de segurança e contingência. 
• Auditoria de eventos específicos: compreende a análise da causa, da 
consequência e da ação corretiva dos eventos que não se encontram sob 
auditoria.
Nos projetos de software, a auditoria de sistemas precisa manter sua 
independência durante todo o acompanhamento do projeto, identificando riscos 
aos interesses da organização, mesmo que em detrimento dos interesses da equipe 
de tecnologia ou do próprio cliente (IMONIANA, 2005; SILVA, 2007).
Agora, compreenderemos as abordagens mais comuns para o auditor, as 
informações necessárias.
4.1 ABORDAGEM AO REDOR DO COMPUTADOR
Essa abordagem considera os documentos-fonte com as funções de 
entrada subjacentes e dominando as funções de saída (IMONIANA, 2005; SILVA, 
2007). Seguem listadas as vantagens e as desvantagens desse tipo de abordagem.
QUADRO 4 – VANTAGENS E DESVANTAGENS DA ABORDAGEM AO REDOR DO COMPUTADOR
FONTE: Adaptado de Imoniana (2005)
VANTAGENS DESVANTAGENS 
1- Não exige 
conhecimento 
extenso de 
tecnologia de 
informação para 
que o auditor 
possa operar 
esse método.
2- Baixo custo.
1- Restrição operacional quanto ao conhecimento de como 
os dados são atualizados faz com que a auditoria seja 
incompleta e inconsistente.
2- A eficiência operacional de auditoria pode ser avaliada 
com mais dificuldade, já que não existem parâmetros claros 
e padronizados.
3- Uma vez não sendo necessário que o auditor possua 
maior capacidade profissional adequada no que se refere à 
tecnologia da informação, o sistema pode ser enquadrado 
em limites de grande risco, quando houver uma evolução e 
os documentos-fonte saírem do controle.
4- Não se pode afirmar que a auditoria tenha sido 
representativa e global de toda tecnologia da informação 
daquela organização. Assim, as decisões tomadas baseadas 
em relatórios de tais auditorias podem ser distorcidas.
TÓPICO 1 — AUDITORIA DO DESENVOLVIMENTO DE SISTEMAS
163
4.2 ABORDAGEM ATRAVÉS DO COMPUTADOR
A utilização dessa abordagem alerta quanto ao manuseio de dados, 
aprovação e registro de transações comerciais, sem deixar evidências documentais 
razoáveis através dos controles de softwares construídos com os sistemas 
(STAIR, 1998; IMONIANA, 2005; SILVA, 2007). Por essa razão, o auditor precisa 
acompanhar o processamento através e dentro do computador.
QUADRO 5 – VANTAGENS E DESVANTAGENS DA ABORDAGEM ATRAVÉS DO COMPUTADOR
FONTE: Adaptado de Imoniana (2005)
4.3 ABORDAGEM COM O COMPUTADOR
Esta abordagem demonstra que certos objetivos sejam alcançados 
(IMONIANA, 2005): 
• O uso das capacidades lógicas e aritméticas do computador para analisar se 
os cálculos em todos os processos foram realizados de modo correto. 
• O uso das capacidades de cálculos estatísticos e de geração de amostras que 
auxiliam nas confirmações das informações obtidas.
• O uso das capacidades de edição e classificação do sistema computadorizado, 
para ordenar e selecionar os registros de contabilidade. 
• O uso das capacidades matemáticasdo computador para analisar e fornecer 
listas de amostras de auditoria.
• A capacidades de auditoria de aplicar Técnicas de Auditoria Assistida por 
Computador (TACC).
VANTAGENS DESVANTAGENS
1- Capacita o auditor 
no que se refere ao 
conhecimento do 
processamento de 
dados.
1- Se a operação for realizada de modo inadequado, 
podem ocorrer perdas incalculáveis.
2- A utilização da abordagem pode ser cara, em 
decorrência do treinamento de auditores, aquisição e 
manutenção dos pacotes de software.
3- As técnicas manuais podem ser necessárias, como 
complementos para que a abordagem tenha os 
resultados esperados.
4- Risco de que os pacotes possam estar contaminados 
pelo uso frequente na auditoria organizacional.
UNIDADE 3 — SEGURANÇA E AUDITORIA NO DESENVOLVIMENTO DO SOFTWARE
164
5 ATIVIDADES DO MÉTODO DE AUDITORIA PARA 
DESENVOLVIMENTO DE SOFTWARE 
O desenvolvimento adequado do software é considerado um processo 
complexo, pois precisa atender às necessidades dos usuários e das organizações 
(NETO, 2012; ALVES, 2016). 
O relatório divulgado pelo Standish Group International afirma que 
somente 32% dos projetos de software podem ser considerados de sucesso, já que 
os outros não são finalizados ou terminam com fracos resultados (NETO, 2012). 
Conforme Neto (2012, p. 55), “existem metodologias de desenvolvimento 
de software e de gerenciamento de projetos, mas existe, também, espaço para 
pesquisar a viabilidade da inclusão de atividades de auditoria nos projetos de 
software como apoio para mitigar as falhas”.
Podemos perceber que a auditoria de sistemas de informação pode apoiar 
as atividades de desenvolvimento de softwares, abrangendo desde o exame de 
dados registrados em sistemas informatizados até a avaliação do próprio sistema 
de informação (IMONIANA, 2005; COSTA, 2010; NETO, 2012). A seguir, será 
listado o conjunto de atividades do método de auditoria, que auxilia no processo 
de desenvolvimento do software.
QUADRO 6 – ATIVIDADES DE AUDITORIA QUE AUXILIAM NO DESENVOLVIMENTO DE 
SOFTWARES
MACROATIVI-
DADE
OBJETIVO DE 
CONTROLE GRUPO DE ATIVIDADES
Concepção 
Garantir 
que sejam 
estabelecidos 
o escopo e a 
viabilidade 
econômica do 
projeto 
Estabelecer o escopo e os limites do 
projeto 
Realizar o planejamento inicial 
TÓPICO 1 — AUDITORIA DO DESENVOLVIMENTO DE SISTEMAS
165
Elaboração 
Garantir 
que sejam 
definidos a 
funcionalidade 
do software, 
os requisitos e 
restrições da 
operação 
Analisar e validar requisitos 
Definir a especificação formal do 
software 
Definir especificação para sistemas 
críticos 
Definir o planejamento do projeto de 
desenvolvimento do software 
Definir o projeto de arquitetura do 
software 
Definir o projeto de interface com o 
usuário 
Definir os requisitos do software 
Definir políticas, processos e 
procedimentos para as etapas de 
desenvolvimento do software 
Educar e treinar os usuários envolvidos 
no desenvolvimento do software 
Gerenciar a qualidade do software 
Gerenciar o projeto de desenvolvimento 
do software 
Construção 
Garantir a 
entrega de um 
sistema de 
software em 
funcionamen-
to, de acordo 
com sua espe-
cificação
Adquirir e manter a Infraestrutura de 
Tecnologia 
Atualizar a documentação do usuário 
Definir a modelagem de análise do 
software 
Definir controles a serem implementados 
no software 
UNIDADE 3 — SEGURANÇA E AUDITORIA NO DESENVOLVIMENTO DO SOFTWARE
166
 
Documentação 
associada 
pronta para ser 
liberada para 
os usuários. 
Definir estratégias de testes de software 
Definir o modelo de projeto do software 
Definir o planejamento para a evolução 
do software 
Definir o planejamento para validação 
do software 
Definir o planejamento para verificação 
do software 
Definir o projeto de testes do software 
Definir técnicas para o desenvolvimento 
de sistemas críticos 
Definir uma estratégia de integração 
Definir uma estratégia de testes 
adicionais 
Definir uma estratégia de validação 
Desenvolver o plano de testes do 
software 
Desenvolver o software conforme o 
projeto 
Gerenciar mudanças no software 
Realizar auditoria técnica do software 
Realizar revisão por pares nos produtos 
do projeto 
Transição 
Garantir que 
seja entregue 
um sistema 
de software 
documentado, 
funcionando 
corretamente 
no seu 
ambiente 
operacional 
e que seja 
validado pelo 
cliente para 
comprovar 
que atende aos 
requisitos 
Gerenciar a implantação do software no 
ambiente de produção 
Gerenciar configurações do software 
Realizar a validação do software 
Realizar a verificação do software 
FONTE: Adaptado de Neto (2012)
TÓPICO 1 — AUDITORIA DO DESENVOLVIMENTO DE SISTEMAS
167
Funcionalidade: refere-se à capacidade de um software de prover 
funcionalidades que satisfaçam o usuário nas suas necessidades declaradas e implícitas, 
dentro de um determinado contexto de uso, sendo, suas características (SILVA, 2007; 
COSTA, 2010; ALVES, 2016):
• Adequação: mede o quanto o conjunto de funcionalidades é adequado às necessidades 
do usuário.
• Acurácia (ou precisão): representa a capacidade do software de fornecer resultados 
precisos ou com a precisão dentro do que foi acordado/solicitado.
• Interoperabilidade: trata do modo como o software interage com outro (s) sistema (s) 
especificado (s).
• Segurança: mede a capacidade do sistema de proteger as informações do usuário e 
fornecê-las apenas (e sempre) às pessoas autorizadas.
NOTA
Considerando as atividades listadas, o autor avaliou, por meio da sua 
pesquisa, que a atividade “estabelecer o escopo e os limites do projeto” foi a 
melhor avaliada, definindo a relevância no processo de desenvolvimento do 
escopo do software (NETO, 2012). Essa atividade engloba as seguintes ações:
• limites do projeto;
• funções e características que deverão ser entregues aos usuários finais; 
• dados de entrada e saída;
• informações que serão apresentadas aos usuários;
• desempenho do software;
• restrições, interfaces e confiabilidade que limitarão o sistema. 
Outra atividade que merece destaque é a de “implementar o software 
no ambiente de produção” (NETO, 2012, p. 55). Isso revela que, no contexto 
da auditoria, precisam ser definidas atividades para verificar se o software foi 
disponibilizado no ambiente de produção, conforme os requisitos do negócio, no 
prazo correto e com um custo adequado (SILVA, 2007; COSTA, 2010; NETO, 2012; 
ALVES, 2016).
Percebemos a importância de serem implantadas práticas de auditoria no 
processo de desenvolvimento do software, para garantir segurança condizente 
com as necessidades dos usuários e dos negócios (STAIR, 1998; MAGALHÃES, 
2001; NETO, 2012). 
Um ponto importante a ser considerado é que, apesar de muitos padrões de 
referência ao desenvolvimento do software, nem sempre são aplicados na íntegra, 
mas a decisão de limitação da utilização dos padrões de referência não garante 
UNIDADE 3 — SEGURANÇA E AUDITORIA NO DESENVOLVIMENTO DO SOFTWARE
168
o resultado satisfatório (STAIR, 1998; IMONIANA, 2005; NETO, 2012). Assim, 
há a inserção de atividades de auditoria que contribuem no desenvolvimento de 
softwares (SILVA, 2007; NETO, 2012): 
• Visão mais ampla e detalhada do processo de desenvolvimento de software 
aos profissionais de auditoria de sistemas.
• Aplicação de boas práticas de desenvolvimento no ciclo de vida de 
desenvolvimento do software.
• Ferramentas de apoio à execução de auditorias no processo de desenvolvimento 
do software.
169
 Neste tópico, você aprendeu que:
• A auditoria tem, como objetivos, analisar toda a infraestrutura, verificar as 
possibilidades de violações de segurança e examinar todo o controle interno 
dos sistemas de uma organização.
• O sistema é formado por um conjunto de elementos inter-relacionados que 
fornecem relatórios que norteiam a tomada de decisão para uma organização. 
• A delimitação do sistema é efetuada durante o seu desenho para fomentar a 
segregação das funções dos sistemas incompatíveis. Podem ser adaptáveis, 
quando implantadospara produzir um resultado desejado em um ambiente 
de grandes mudanças rotineiras, e corretivos, implantados para produzir um 
resultado específico, e não rotineiro.
• O software de código aberto precisa integrar o código-fonte, além de garantir 
a distribuição na forma de código-fonte e compilada (GOMES, 2020).
• Conforme Neto (2012, p. 24), “auditoria compreende o processo sistemático 
de obtenção e avaliação de evidências com foco em afirmações de ações e 
eventos econômicos para avaliar o grau de correspondência entre essas 
afirmações e os critérios estabelecidos, para comunicação dos resultados aos 
usuários interessados”. 
• A auditoria deve concentrar esforços na análise e na avaliação dos processos 
de planeamento, desenvolvimento, testes e aplicação de sistemas, examinando 
a estrutura lógica, física, ambiental, organizacional, de controle, segurança 
e proteção de dados (IMONIANA, 2005; SILVA, 2007; NETO, 2012, ALVES, 
2016). 
• O espaço de atuação da auditoria de sistemas é a organização, sujeita, de 
modo transversal, a inúmeros tipos de riscos, transversais e presentes em 
todos os lugares, em toda a organização.
• A auditoria de sistemas atua no nível estratégico, gerencial ou operacional, 
sendo os trabalhos agrupados para alcançar os objetivos e segmentados nas 
seguintes linhas de atuação.
RESUMO DO TÓPICO 1
https://blog.betrybe.com/tecnologia/codigo-fonte/
170
• Nos projetos de software, a auditoria de sistemas precisa manter sua 
independência durante todo o acompanhamento do projeto, identificando 
riscos aos interesses da organização, mesmo que em detrimento dos interesses 
da equipe de tecnologia ou do próprio cliente (IMONIANA, 2005; SILVA, 
2007).
• O desenvolvimento adequado do software é considerado um processo 
complexo, pois precisa atender às necessidades dos usuários e das 
organizações.
171
1 Os softwares recebem inúmeras melhorias com o objetivo de se adequar aos 
novos padrões de negócios. Em função da necessidade contínua de tornar 
os processos mais eficientes, tem sido exigida a utilização de tipos diferentes 
de softwares (ALVES, 2016; SAM, 2020). Nessas situações, a auditoria do 
software é uma solução para garantir a segurança das informações (SILVA, 
2007; NETO, 2012; ALVES, 2016). Dessa forma, assinale a alternativa 
INCORRETA:
a) ( ) A auditoria tem, como objetivos, analisar toda a infraestrutura, 
verificar as possibilidades de violações de segurança e examinar 
todo o controle interno dos sistemas de uma organização.
b) ( ) A auditoria tem relação com a identificação antecipada dos 
problemas dentro da organização para que o software tenha boa 
qualidade.
c) ( ) A auditoria não é somente um processo burocrático, mas estratégico. 
d) ( ) Os resultados da auditoria auxiliam na tomada de decisão mais 
segura, possibilitando a detecção de problemas de desenvolvimento 
dos softwares. 
2 O sistema é formado por um conjunto de elementos inter-relacionados 
que fornecem relatórios que norteiam a tomada de decisão para uma 
organização (IMONIANA, 2005; NETO, 2012; ALVES, 2016). Dessa forma, 
descreva o conceito de sistema utilizando a figura a seguir.
REPRESENTAÇÃO ESQUEMÁTICA DE UM SISTEMA
FONTE: <https://bit.ly/3szZpaP>. Acesso em: 19 out. 2020.
3 Conforme Neto (2012, p. 24), a “auditoria compreende o processo sistemático 
de obtenção e avaliação de evidências com foco em afirmações acerca 
de ações e eventos econômicos para avaliar o grau de correspondência 
AUTOATIVIDADE
172
entre essas afirmações e os critérios estabelecidos, para comunicação dos 
resultados aos usuários interessados”. Dessa forma, assinale a alternativa 
CORRETA:
a) ( ) A auditoria deve concentrar, exclusivamente, os seus esforços na 
análise e avaliação dos processos de planejamento.
b) ( ) O termo auditoria pode ser utilizado para definir uma variedade 
significativa de atividades no nosso meio social.
c) ( ) A auditoria deve concentrar os seus esforços examinando somente 
a estrutura ambiental.
d) ( ) A auditoria deve concentrar os seus esforços somente na segurança 
e proteção de dados. 
4 Em decorrência da complexidade dos ambientes e expansão dos negócios 
que atingiram implementações na intranet e internet, existem diversos 
problemas quanto à vulnerabilidade de computadores e casos comuns de 
fraudes (IMONIANA, 2005; SILVA, 2007; COSTA, 2010). Acerca do exposto, 
classifique V para as sentenças verdadeiras e F para as sentenças falsas:
a) ( ) O objetivo do auditor de sistemas é verificar se os controles 
funcionam de modo adequado e se estão em bom número.
b) ( ) O espaço de atuação da auditoria de sistemas é a organização, 
sujeita, de modo transversal, a inúmeros tipos de riscos. 
c) ( ) Os principais objetos que são alvo da auditoria: a informação, os 
sistemas e a tecnologia.
d) ( ) O gerenciamento de riscos pode ser aplicado a todas as atividades 
inclusas dentro de uma organização, não somente à aplicação da 
tecnologia da informação.
Assinale a alternativa que apresenta a sequência CORRETA:
a) ( ) V – V – V – V.
b) ( ) V – F – V – V.
c) ( ) F – F – V – V.
d) ( ) V – V – F – V.
5 O desenvolvimento adequado do software é considerado um processo 
complexo, pois precisa atender às necessidades dos usuários e das 
organizações (NETO, 2012; ALVES, 2016). Desta forma, assinale a alternativa 
INCORRETA:
a) ( ) No contexto da auditoria, precisam ser definidas atividades 
para verificar se o software foi disponibilizado no ambiente de 
produção, conforme os requisitos do negócio, no prazo correto e 
com um custo adequado.
173
b) ( ) A auditoria de sistemas abrange desde o exame de dados 
registrados em sistemas informatizados até a avaliação do próprio 
sistema de informação.
c) ( ) Atualmente, não há espaço para pesquisar a viabilidade da inclusão 
de atividades de auditoria nos projetos do software.
d) ( ) A auditoria de sistemas de informação pode apoiar as atividades 
de desenvolvimento dos softwares.
175
UNIDADE 3
1 INTRODUÇÃO
Para efetuar exames adequados de auditoria, o auditor tem, como base, 
boas práticas de controle que direcionam as ações, já que são definidas por 
especialistas das respectivas áreas de atuação (IMONIANA, 2005). Podemos citar 
o framework Control Objectives for Information and Related Technology (Cobit), que 
indica boas práticas que levam à avaliação do nível da gestão de TI e do ambiente 
de controle interno da organização (IMONIANA, 2005; GHERMAN, 2005; SILVA, 
2007). Desse modo, o software de auditoria representa programas que têm, como 
objetivo, o incremento da qualidade do trabalho do auditor e dos sistemas de 
análise. 
Conforme já estudamos no Tópico 1 desta unidade, vimos que a auditoria 
significa a realização de uma atividade sistemática, ordenada de maneira lógica, 
para avaliação de um processo. A avaliação compara o processo sob exame com 
outro já conhecido ou com alguma diretriz estabelecida (SILVA, 2007; ALVES, 
2016). Esse processo procura identificar determinados desvios, propondo medidas 
que o melhorem. O ambiente de auditoria compreende a avaliação dos controles 
que possibilitam, à administração, a gestão correta das operações da organização 
(ALVES, 2016).
Um grande ponto é que a auditoria dos sistemas precisa ter independência, 
podendo gerar impactos nos projetos de software, identificando pontos falhos, mas, 
também, mostrando oportunidades de melhoria, sem perder a independência.
2 METODOLOGIAS DE SELEÇÃO 
Os métodos têm, como característica, fornecer os modos descritivos de 
como desenvolver um produto, tendo a descrição de inúmeras tarefas, e seguindo 
um conjunto de princípios alinhados em cada método usado, tendo, como 
resultado, um produto gerado, o software (SOMMERVILLE, 2011). 
O desenvolvimento de um software depende do método usado e de 
um ciclo próprio de vida, sendo que essas etapas mudam de acordo com a área 
de aplicação, o tamanho do projeto e a complexidade (SOMMERVILLE, 2011; 
ALVES, 2016). 
TÓPICO 2 —AVALIAÇÃO DO SOFTWARE DE 
AUDITORIA DE SISTEMAS
176
UNIDADE 3 — SEGURANÇA E AUDITORIA NO DESENVOLVIMENTO DO SOFTWARE
Considerando os métodos utilizados para a seleção de pacotes de auditoria 
de sistemas, existem características próprias (IMONIANA, 2005; SILVA, 2007; 
COSTA, 2010; ALVES, 2016):
• Análise da fabricação e operacionalização.
• Análise de documentos que registram experiências similares.
• Análise de todos os documentos disponibilizados no mercado dos pacotes 
disponíveis.
• Contatos com os fabricantes dos pacotes.
• Avaliar o grau de satisfação, os problemas detectados quando da implantação, 
acompanhamento e manutenção dos serviços. 
• Análise organizacional, capacidade institucional, tecnológica e computacional 
da instituição, seus produtos e serviços.
• Análise da idoneidade das instituições detentoras dos produtos.
• Coleta de dados, identificação dos produtos disponíveis no mercado. 
• Exame das características tecnológicas e funcionais consideradas relevantes.
• Consideração da capacidade de evolução do software.
2.1 COBIT 
O COBIT é considerado uma estrutura que foi desenvolvida pela 
associação Information Systems Audit and Control Association (lSACA), sendo um 
conjunto de orientações e ferramentas de apoio para a governança de TI aceito 
no âmbito mundial (GHERMAN, 2005; SILVA, 2007; COSTA, 2010; ALVES, 2016).
Essa associação reúne 510.000 profissionais envolvidos em informação, 
segurança, auditoria, governança, risco e inovação de mais de 100 países. Com 
o apoio de instituições, como Unisys e Coopers & Lybrand, desenvolveu, 
em 1996, uma estrutura, para facilitar a condução de auditoria em ambientes 
computadorizados (GHERMAN, 2005; SILVA, 2007; ALVES, 2016).
A seleção e a aquisição de um software devem levar em consideração as 
características de funcionalidade, com possibilidades de interligar todo o processo de 
auditoria (IMONIANA, 2005).
NOTA
TÓPICO 2 — AVALIAÇÃO DO SOFTWARE DE AUDITORIA DE SISTEMAS
177
FIGURA 6 – EVOLUÇÃO DO FRAMEWORK COBIT
FONTE: <https://bit.ly/3sCwRxn>. Acesso em: 19 out. 2020.
FIGURA 7 – REPRESENTAÇÃO DOS PRINCÍPIOS DO COBIT
FONTE: <https://blog.cronapp.io/o-que-e-cobit/>. Acesso em: 18 out. 2020.
178
UNIDADE 3 — SEGURANÇA E AUDITORIA NO DESENVOLVIMENTO DO SOFTWARE
O CobiT foi desenvolvido para ser utilizado pelos seguintes públicos 
(GHERMAN, 2005):
• Administradores: ajudar na ponderação entre risco e investimento em 
controles, geralmente, imprevisíveis, como o de TI.
• Usuários: garantir segurança e controle dos serviços de TI fornecidos 
internamente ou por terceiros.
• Auditores: subsidiar suas opiniões, além de auxiliar no aconselhamento aos 
administradores acerca dos controles internos.
O COBIT foi desenvolvido para ser usado por provedores de serviços, 
usuários e auditores, mas, também, para fornecer um guia completo para os 
gestores (GHERMAN, 2005; NETO, 2012). A estrutura do COBIT tem, como base, 
os quatro requisitos apontados a seguir. 
FIGURA 8 – ESTRUTURA DO COBIT
FONTE: Neto (2012, p. 38)
Os processos de TI são segmentados em quatro domínios, cada um tem 
um conjunto de processos que são subdivididos em atividades, para que os objetivos 
do domínio sejam alcançados, sendo que o Cobit é um modelo orientado a processos. 
Na estrutura Cobit, há, também, informações dos modelos de maturidade para cada um 
desses processos (GHERMAN, 2005).
NOTA
TÓPICO 2 — AVALIAÇÃO DO SOFTWARE DE AUDITORIA DE SISTEMAS
179
De acordo com a estrutura COBIT, as informações devem se ajustar a 
determinados critérios de controle, os quais o COBIT define como necessidades 
de informação da empresa (GHERMAN, 2005; NETO, 2012). Tendo, como base, 
requisitos abrangentes de qualidade e de segurança, o COBIT relaciona sete 
critérios de informação:
QUADRO 7 – CRITÉRIOS DO COBIT
FONTE: Adaptado de Gherman (2005), Silva (2007) e Neto (2012)
Apresentaremos o CobiT, que relaciona os 34 objetivos de controle de alto 
nível e seus respectivos domínios, as sete categorias de critérios para a avaliação 
dos processos e os recursos de TI (GHERMAN, 2005). Observa-se que o ciclo 
natural dos processos é respeitado, considerando-se a avaliação dos controles, os 
objetivos do negócio, os sete critérios de avaliação e os recursos de TI (GHERMAN, 
2005; NETO, 2012). 
CRITÉRIOS DESCRIÇÃO
EFETIVIDADE Informação relevante e pertinente para o processo de negócio.
EFICIÊNCIA Entrega da informação através do melhor (mais produtivo e econômico) uso dos recursos.
CONFIDENCIALIDADE Proteção de informações confidenciais para evitar a divulgação indevida.
INTEGRIDADE
Fidedignidade e totalidade da informação, além 
da validade, de acordo os valores de negócios e 
expectativas.
DISPONIBILIDADE Disponibilidade da informação quando exigida pelo processo de negócio hoje e no futuro.
CONFORMIDADE
Aderência a leis, regulamentos e obrigações 
contratuais aos quais os processos de negócios 
estão sujeitos.
CONFIABILIDADE
Entrega da informação apropriada para os 
executivos, para que possam administrar a 
entidade e exercer suas responsabilidades 
fiduciárias e de governança. 
180
UNIDADE 3 — SEGURANÇA E AUDITORIA NO DESENVOLVIMENTO DO SOFTWARE
FIGURA 9 – ESTRUTURA RESUMIDA DO COBIT
FONTE: Gherman (2005, p. 18)
Durante a execução das atividades, procura-se atingir objetivos de 
controle para assegurar que todos os objetivos sejam alcançados (NETO, 2012).
Gostou do assunto e ficou interessado? Assista ao vídeo disponibilizado no link 
a seguir: https://www.youtube.com/watch?v=92eFLldABgw.
DICAS
2.2 CMMI
O Capability Maturity Model Integration (CMMI) é um modelo de referência que 
possui práticas que são necessárias à maturidade em disciplinas específicas Systems 
Engineering (SE), Software Engineering (SW), Integrated Product and Process Development 
(IPPD) e Supplier Sourcing (SS) (COUTO, 2007; SILVA, 2007; NETO, 2012).
Objetivo do Negócio
Informação
COBIT
Monitoramento
M1 Monitorar os Processos
M2 Avaliar a adequação do controle interno
M3 Obter certificação independente
M4 Auditoria
PO1 Definir um plano estratégico de TI
PO2 Definir a arquitetura da informação
PO3 Determinar a direção tecnológica 
PO4 Definir a organização e relacionamento da TI
PO5 Gerenciar o investimento em TI
PO6 Comunicar objetivos e diretrizes da Administração
PO7 Gerencias recursos humanos
PO8 Garantia do cumprimento de exigências externas
PO9 Avaliação de riscos
PO10 Gerenciar Projetos
PO11 Gerenciar Qualidade
DS1 Definir níveis de serviços
DS2 Gerenciar serviços de terceiros
DS3 Gerenciar performance e capacidade
DS4 Garantir continuidade dos serviços
DS5 Garantir segurança dos sistemas
DS6 Identificar e alocar custor
DS7 Educar e treinar usuários
DS8 Auxiliar e aconselhar usuários de TI
DS9 Gerenciamento da configuração
DS10 Gerenciamento de problemas e incidentes
DS11 Gerenciamento de dados
DS12 Gerenciamento de instalações
DS13 Gerenciamento de operação
A/1 Identificar Soluções
A/2 Adquirir e manter software aplicativo
A/3 Aderir e manter arquitetura tecnológica
A/4 Desenvolver e manter procedimentos de TI
A/5 Instalar e certificar sistemas
A/6 Gerenciar mudanças
- Eficiência
- Eficácia
- Confidencialidade
- Integridade
- Disponibilidade
- Compliance
- Confiabilidade
Entrega e Suporte
Recursos de TI
Planejamento e 
Organização
Aquisição e 
Implementação
TÓPICO 2 — AVALIAÇÃO DO SOFTWARE DE AUDITORIA DE SISTEMAS
181
O CMMI organiza as melhores práticas que foram comprovadamente 
efetivas, em uma estrutura que auxilia a organização a formular metas e 
prioridades para melhoria, além de fornecer um guia para implementação dessas 
melhorias (POMPEU, 2006; ALMEIDA, 2007; SILVA, 2007; ALVES, 2016). Seguem 
os cinco níveis de maturidade do CMMI. 
FIGURA 10 – OS CINCO NÍVEIS DE MATURIDADE DO CMMI
FONTE: <http://bit.ly/35Va2eC>. Acesso em: 19 out. 2020.
O CMMI foi desenvolvido pelo Software Engineering Institute (SEI) da 
Universidade Carnegie Mellon. É considerado uma evolução do CMM e estabelece um 
modelo único para o processo de melhoriacorporativo, integrando diferentes modelos e 
disciplinas (NETO, 2012; ALVES, 2016).
NOTA
Você pode realizar o diagnóstico da sua organização de modo gratuito. Para 
isso, acesse: http://bit.ly/2NeJUVr.
DICAS
182
UNIDADE 3 — SEGURANÇA E AUDITORIA NO DESENVOLVIMENTO DO SOFTWARE
A maturidade é definida, no CMMI, como um nível organizacional que 
uma empresa pode alcançar, tendo os seguintes níveis (POMPEU, 2006; SILVA, 
2007; NETO, 2012; ALVES, 2016).
QUADRO 8 – OS CINCO NÍVEIS DE MATURIDADE DO CMMI
FONTE: <http://bit.ly/35Va2eC>. Acesso em: 19 out. 2020.
NÍVEL DESCRIÇÃO
Nível 0 – Incompleto O trabalho é efetuado de modo aleatório, isso significa que o trabalho pode ou não ser concluído.
Nível 1 – Inicial
O resultado dos trabalhos é considerado imprevisível e 
reativo. O trabalho pode ser concluído, mas, geralmente, 
é entregue com atrasos e ultrapassa o orçamento 
estipulado.
Nível 2 – Gerenciado
Os trabalhos são gerenciados no nível do projeto. 
Os projetos são planejados, realizados, medidos e 
controlados.
Nível 3 – Definido
A definição de padrões de processo para toda a 
organização, tendo orientação entre os projetos, 
programas e portfólios.
Nível 4 – Gerenciado 
quantitativamente
Um nível de alta maturidade, utilizando análise 
quantitativa e estatística para determinar, identificar 
e gerenciar a tendência e a dispersão central, para 
entender e abordar a estabilidade e a capacidade de 
processo e como tudo impacta nos objetivos de obtenção 
de qualidade e desempenho de processo.
Nível 5 – Otimização
Um nível de alta maturidade que foca 
em melhoria contínua para alcançar processos 
flexíveis capazes de responder às oportunidades e 
mudanças. 
A versão atual do CMMI (versão 1.3) foi publicada em 27 de outubro de 2010 
e apresenta três modelos: 
• CMMI for Development (CMMI-DEV), voltado ao processo de desenvolvimento de 
produtos e serviços. 
• CMMI for Acquisition (CMMI-ACQ), voltado aos processos de aquisição e terceirização 
de bens e serviços. 
• CMMI for Services (CMMI-SVC), voltado aos processos de empresas prestadoras de 
serviços.
NOTA
https://promovesolucoes.com/melhoria-de-processos-como-otimizar-a-rotina-e-os-resultados/
TÓPICO 2 — AVALIAÇÃO DO SOFTWARE DE AUDITORIA DE SISTEMAS
183
2.3 MELHORIA DO PROCESSO DO SOFTWARE BRASILEIRO 
(MPS.BR) 
O MPS.BR foi elaborado por pesquisadores brasileiros para a melhoria do 
processo de desenvolvimento do software em empresas no Brasil. É considerado 
um modelo em contínuo desenvolvimento, que começou a ser elaborado em 
2003, por meio das instituições SOFTEX, Riosoft, COPPE/UFRJ, CESAR, CenPRA 
e CELEPAR (NETO, 2012; ALVES, 2016; SOFTEX, 2020).
O foco principal são as empresas de software, que possuem poucos 
recursos para a melhoria dos processos (MORGADO, 2008; LYRA, 2009; NETO, 
2012). O MPS.BR atende à necessidade de implantar os princípios de engenharia 
de software de modo adequado à realidade das empresas, seguindo as principais 
abordagens internacionais para definição, avaliação e melhoria de processos 
(NETO, 2012). A descrição do modelo se baseia em três guias, conforme Neto 
(2012): 
• Guia geral: descrição geral do MPS.BR e detalha o modelo de referência 
(MR-MPS), seus componentes e as definições comuns necessárias para 
entendimento e aplicação. 
• Guia de aquisição: recomendações para a condução de compras de software 
e serviços correlatos.
• Guia de avaliação: contém a descrição do processo de avaliação, os requisitos 
para o avaliador e para a avaliação, o método e os formulários para guiarem 
a avaliação.
O processo de software é o conjunto de áreas que formam a base para o 
gerenciamento do projeto e estabelecem os seguintes contextos (NETO, 2012): 
• Métodos aplicados. 
• Produto elaborado. 
• Metas estabelecidas. 
• Qualidade garantida. 
• Mudanças efetudas.
NOTA
184
UNIDADE 3 — SEGURANÇA E AUDITORIA NO DESENVOLVIMENTO DO SOFTWARE
FIGURA 11 – REPRESENTAÇÃO ESQUEMÁTICA DO MPS.BR
FONTE: Neto (2012, p. 56)
FIGURA 12 – REPRESENTAÇÃO DOS SETE NÍVEIS DO MPS.BR
FONTE: <https://bit.ly/3o0r9Sk>. Acesso em: 19 out. 2020.
O MPS.BR define níveis de maturidade que são uma combinação de 
processos e capacitação de processos (ARRIAL, 2009; NETO, 2012; ALVES, 2016). 
O nível de maturidade de uma determinada organização possibilita a previsão 
do seu desempenho futuro (ARRIAL, 2009). Os objetivos de melhoria foram 
segmentados em sete níveis de maturidade, de A (melhor) a G (pior) (NETO, 
2012; ALVES, 2016). 
TÓPICO 2 — AVALIAÇÃO DO SOFTWARE DE AUDITORIA DE SISTEMAS
185
QUADRO 9 – NÍVEIS DE MATURIDADE
FONTE: Adaptado de Neto (2012) e Alves (2016)
A Em otimização 
Inovação e implantação na organização 
Análise de causas e resolução 
B Gerenciado Quantitativamente 
Desempenho do processo organizacional 
Gerência quantitativa do projeto 
C Definido 
Análise de decisão e resolução 
Gerência de riscos 
D Largamente definido 
Desenvolvimento de requisitos 
Solução técnica 
Integração do produto 
Instalação do produto 
Liberação do produto 
Verificação 
Validação 
E Parcialmente definido 
Treinamento 
Avaliação e melhoria do processo 
organizacional 
Definição do processo organizacional 
Adaptação do processo para gerência do projeto 
F Gerenciado 
Medição 
Gerência de configuração 
Aquisição 
Garantia da qualidade 
G Parcialmente gerenciado 
Gerência de requisitos 
Gerência do projeto 
Essa reportagem aborda um guia geral do software. A leitura completará o seu 
estudo. Acesse: https://bit.ly/2LMf3PQ.
DICAS
186
UNIDADE 3 — SEGURANÇA E AUDITORIA NO DESENVOLVIMENTO DO SOFTWARE
2.4 ISO/IEC 12207
A norma NBR ISO/IEC 12207 estabelece uma arquitetura de alto nível do 
ciclo de vida do software que é construída a partir de um conjunto de processos 
e seus inter-relacionamentos (ISO, 2009; NETO, 2012).
Um ponto importante é que essa norma não tem vinculação com 
métodos, ferramentas, treinamentos, métricas ou tecnologias empregadas. Essa 
determinação permitiu que a norma fosse usada mundialmente e acompanhada 
a evolução da engenharia de software nas diferentes culturas organizacionais 
(NAVAS, 2006; SILVA, 2007; NETO, 2012). É essencial considerar que ela pode ser 
usada com qualquer modelo de ciclo de vida, método ou técnica de engenharia 
de software e linguagem de programação (NAVAS, 2006). 
Os processos da NBR ISO/IEC 12207 são considerados modulares, ou seja, 
todas as partes de um processo estão relacionadas, mas a quantidade de interfaces 
entre os processos é mínima (NAVAS, 2006; NETO, 2012). Assim, uma das 
organizações é a responsável pelo processo global, mesmo que tarefas individuais 
sejam efetuadas por diferentes profissionais. Os processos são agrupados por 
uma questão de organização, conforme a natureza, ou seja, o objetivo principal 
no ciclo de vida do software (NAVAS, 2006; SILVA, 2007; ISO, 2009; NETO, 2012).
FIGURA 13 – REPRESENTAÇÃO ESQUEMÁTICA DA NBR ISO/IEC 12207
FONTE: <http://leandromtr.com/norma-iso-12207/>. Acesso em: 19 out. 2020.
7.2 Infraestrutura
http://leandromtr.com/norma-iso-12207/
TÓPICO 2 — AVALIAÇÃO DO SOFTWARE DE AUDITORIA DE SISTEMAS
187
3 ASPECTOS FUNCIONAIS
São consideradas as características gerais e obrigatórias para um processo 
adequado de auditoria, sendo identificadas, pelos usuários, como importantes 
para a execução do trabalho (IMONIANA, 2005):
• Apoiar o planejamento de auditoria. 
• Apresentar papéis de auditoria. 
• Extrair, diretamente, dados de banco de dados. 
• Permitir, à auditoria, criar novos modelos de papéis de auditoria. 
• Facilitar o uso de procedimentos pré-cadastrados.
• Permitir a inserção de outros documentos nos papéis de auditoria. 
• Manter controle sobre os arquivos gerados por outros programas.
• Armazenar imagens relacionadas ao processo. 
• Permitir comentário do auditor.
• Apoiar o acesso on-line ao banco de documentos de processos.
• Customizar as normas e legislações no mesmo banco de dados dos processos. 
• Permitir trabalho offline, independentemente dos processos normais.• Apoiar auditoria em grupos e em lugares separados e distantes. 
• Emitir relatório final a partir dos dados armazenados nos bancos.
Para facilitar o levantamento dos aspectos funcionais, pode-se utilizar um 
checklist, denominado de os 5WH (whats, “o que”), com perguntas de algumas 
atividades que podem ser elaboradas com clareza por parte dos funcionários da 
organização (GUETNER, 2019). Assim, ficará identificado o que será realizado, 
além dos papéis da auditoria e de todos os objetivos pelos quais ela deve ser 
realizada (IMONIANA, 2005; GUETNER, 2019).
FIGURA 14 – REPRESENTAÇÃO ESQUEMÁTICA DO LEVANTAMENTO DOS ASPECTOS 
FUNCIONAIS PARA AUDITORIA
FONTE: <http://galloro.com.br/internas.php?pag=80>. Acesso em: 19 out. 2020.
^
Por quê?
http://galloro.com.br/internas.php?pag=80
188
UNIDADE 3 — SEGURANÇA E AUDITORIA NO DESENVOLVIMENTO DO SOFTWARE
FIGURA 15 – EXEMPLIFICAÇÃO DOS 5WH
FONTE: <http://galloro.com.br/internas.php?pag=80>. Acesso em: 19 out. 2020.
4 ASPECTOS DA GESTÃO
São consideradas as características gerenciais que estão ligadas ao processo 
de auditoria, sendo identificadas pelos gerentes e supervisores de auditoria no 
desenvolvimento dos trabalhos (IMONIANA, 2005; SILVA, 2007), tendo, como 
função:
• Apoiar o planejamento dos projetos de auditoria.
• Customizar normas e legislação no mesmo banco de dados dos processos.
• Permitir a supervisão online.
• Apoiar o processo de análise do relator e de julgamento do plenário. 
Quem? Who? - 
Onde? Where?
Quando em $? When $?
Por quê
http://galloro.com.br/internas.php?pag=80
TÓPICO 2 — AVALIAÇÃO DO SOFTWARE DE AUDITORIA DE SISTEMAS
189
FIGURA 16 – ETAPAS DAS ATIVIDADES DE AUDITORIA QUE POSSUEM RELAÇÃO COM OS 
ASPECTOS DA GESTÃO
FONTE: <https://bit.ly/3sDRn0A>. Acesso em: 19 out. 2020.
5 ASPECTOS RELACIONADOS À TECNOLOGIA
Conforme Imoniana (2005), são considerados os com a capacidade de 
atualização com os novos recursos tecnológicos, facilidade de manutenção futura 
e integração com outros programas. As características são (IMONIANA, 2005):
• Integração com e-mail.
• Arquiterutra cliente/servidor para acesso e atualização de dados em redes 
locais e remotas. 
• Replicação do banco de dados.
• Criptografia dos dados. 
• Proteger documento para edição apenas pelo autor. 
• Proteger documento aberto por vários usuários. 
• Níveis diferenciados de acesso aos documentos. 
• Log de alterações. 
• Facilidade de programação extra. 
• Interface gráfica. 
190
UNIDADE 3 — SEGURANÇA E AUDITORIA NO DESENVOLVIMENTO DO SOFTWARE
• Acesso a base de dados via browser da internet. 
• Capacidade de armazenamento compatível com o volume de dados. 
• Recuperação da base dos dados textuais. 
• Acesso simultâneo de usuários à base de dados. 
• Treinamento para os diferentes níveis de usuários.
Para finalizar este tópico, é preciso entender a importância da auditoria 
no exemplo da empresa de carteiras e hardware Ledger, que, recentemente, 
divulgou que passou por uma auditoria de segurança (PIRUS, 2020). A auditoria 
veio logo após uma violação de dados que a empresa sofreu em junho de 2020. 
FIGURA 17 – EXEMLOS DO HARDWARE DA EMPRESA LEDGER
FONTE: <https://www.amazon.com/Ledger-Backup-Pack-Hardware-Bluetooth/dp/B07X-
58J1PK>. Acesso em: 29 out. 2020.
A empresa foi comunicada da falha no banco de dados em julho e corrigiu 
a falha de modo ágil. Entretanto, a empresa descobriu uma violação anterior 
em junho, que gerou o vazamento de nomes, endereços e outras informações 
confidenciais de milhares de clientes (PIRUS, 2020). As consequências desse 
vazamento ainda estão sendo analisadas, porém, e-mails falsos estão sendo 
enviados para usuários, falando de uma suposta brecha e oferecendo um software 
para baixar (MATOS, 2020). Esse software rouba as informações da carteira do 
usuário.
https://www.amazon.com/Ledger-Backup-Pack-Hardware-Bluetooth/dp/B07X58J1PK
https://www.amazon.com/Ledger-Backup-Pack-Hardware-Bluetooth/dp/B07X58J1PK
TÓPICO 2 — AVALIAÇÃO DO SOFTWARE DE AUDITORIA DE SISTEMAS
191
Leia o artigo disponível no link a seguir. Apresenta as principais ferramentas 
de auditoria de sistemas disponíveis no mercado, suas características, vantagens e 
desvantagens. Boa leitura e bons estudos!
https://dhg1h5j42swfq.cloudfront.net/2018/06/28174439/teruel-evandro-carlos.pdf.
DICAS
192
RESUMO DO TÓPICO 2
 Neste tópico, você aprendeu que:
• Para efetuar exames adequados de auditoria, os auditores têm, como base, 
boas práticas de controles que direcionam as ações.
• A auditoria de sistemas precisa ter independência, podendo gerar impactos 
nos projetos de software, identificando pontos falhos, mas também mostrando 
oportunidades de melhoria, sem perder a independência.
• Os métodos têm, como característica, fornecer os modos descritivos de como 
desenvolver um produto, tendo a descrição de inúmeras tarefas, e seguindo 
um conjunto de princípios alinhados em cada método usado, tendo, como 
resultado, um produto gerado, o software.
• O desenvolvimento de um software depende do método usado e de um ciclo 
próprio de vida, sendo que essas etapas mudam de acordo com a área de 
aplicação, o tamanho do projeto ou a complexidade.
• O COBIT é considerado uma estrutura que foi desenvolvida pela associação 
Information Systems Audit and Control Association (lSACA), sendo um conjunto 
de orientações e ferramentas de apoio para a governança de TI, aceito no 
âmbito mundial.
• O COBIT foi desenvolvido para ser usado por provedores de serviços, usuários 
e auditores, mas, também, para fornecer um guia completo para os gestores.
• Capability Maturity Model Integration (CMMI) organiza as melhores práticas 
que foram comprovadamente efetivas, em uma estrutura que auxilia a 
organização a formular metas e prioridades para melhoria, fornecendo um 
guia para implementação dessas melhorias.
• A maturidade é definida, no CMMI, como um nível organizacional que uma 
empresa pode alcançar.
• MPS.BR foi elaborado por pesquisadores brasileiros para a melhoria do 
processo de desenvolvimento de software em empresas no Brasil. Foi 
considerado um modelo em contínuo desenvolvimento.
• A norma NBR ISO/IEC 12207 estabelece uma arquitetura de alto nível do ciclo 
de vida do software, construída a partir de um conjunto de processos e seus 
inter-relacionamentos.
193
• Os processos da NBR ISO/IEC 12207 são considerados modulares, ou seja, 
todas as partes de um processo estão relacionadas, mas a quantidade de 
interfaces entre os processos é mínima.
• Os aspectos funcionais são considerados as características gerais e obrigatórias 
para um processo adequado de auditoria, sendo identificados pelos usuários 
como importantes para a execução do trabalho.
• Os aspectos de gestão são considerados as características gerenciais que 
estão ligadas ao processo de auditoria, sendo identificados pelos gerentes e 
supervisores de auditoria no desenvolvimento dos trabalhos.
• Os aspectos relacionados à tecnologia são considerados os com a capacidade 
de atualização com os novos recursos tecnológicos, facilidade de manutenção 
futura e integração com outros programas. 
194
1 As atividades de auditoria de sistemas, além de poderem utilizar os 
recursos de informática para auditar o próprio computador, também visam 
automatizar todos os processos de auditoria (IMONIANA, 2005; SILVA, 
2007; NETO, 2012). Analise as ferramentas de auditoria disponíveis no 
mercado e faça um resumo das principais, considerando o artigo disponível 
no link https://dhg1h5j42swfq.cloudfront.net/2018/06/28174439/teruel-
evandro-carlos.pdf.
2 Os métodos têm, como característica, fornecer os modos descritivos de 
como desenvolver um produto, tendo a descrição de inúmeras tarefas, e 
seguindo um conjunto de princípios alinhados em cada método usado, 
tendo, como resultado, um produto gerado, o software (SOMMERVILLE, 
2011). Dessa forma, assinale a alternativa INCORRETA:
a) ( ) O desenvolvimento de um software depende do método usado 
e de um ciclo próprio de vida, sendoque essas etapas mudam 
de acordo com a área de aplicação, o tamanho do projeto ou a 
complexidade.
b) ( ) O COBIT foi desenvolvido para ser usado por provedores de 
serviços, usuários e auditores, mas, também, para fornecer um 
guia completo para os gestores.
c) ( ) De acordo com a estrutura COBIT, as informações mudam 
conforme os critérios de controle definidos pela organização.
d) ( ) Os processos de TI são um conjunto de atividades. Durante a 
execução dessas atividades, procura-se atingir objetivos de controle 
para assegurar que os objetivos sejam alcançados. 
3 De acordo com a estrutura COBIT, as informações devem se ajustar a 
determinados critérios de controle, a partir dos quais o COBIT define as 
necessidades de informação da empresa (GHERMAN, 2005; NETO, 2012). 
Tendo, como base, requisitos abrangentes de qualidade e de segurança, o 
COBIT relaciona sete critérios de informação como sendo os principais. 
Dessa forma, descreva os sete critérios.
4 O CMMI organiza as melhores práticas que foram comprovadamente 
efetivas, em uma estrutura que auxilia a organização a formular metas 
e prioridades para melhoria, fornecendo um guia para implementação 
dessas melhorias (POMPEU, 2006; ALMEIDA, 2007; SILVA, 2007; ALVES, 
2016). Dessa forma, assinale a alternativa CORRETA:
a) ( ) O Capability Maturity Model Integration (CMMI) é um modelo 
único de referência que possui exemplos de maturidade 
organizacional.
AUTOATIVIDADE
195
b) ( ) A maturidade é definida, no CMMI, como um nível organizacional 
que uma empresa pode alcançar.
c) ( ) O nível 5 corresponde ao nível de média de maturidade que foca 
em melhoria contínua para alcançar processos flexíveis capazes de 
responder às oportunidades e mudanças. 
d) ( ) O nível 2 corresponde ao modo aleatório, isso significa que o 
trabalho pode ou não ser concluído. 
5 A norma NBR ISO/IEC 12207 estabelece uma arquitetura de alto nível do 
ciclo de vida do software, que é construída a partir de um conjunto de 
processos e seus inter-relacionamentos (ISO, 2009; NETO, 2012). Acerca do 
exposto, classifique V para as sentenças verdadeiras e F para as sentenças 
falsas:
( ) Os processos da NBR ISO/IEC 12207 são considerados modulares.
( ) A NBR ISO/IEC 12207 é considerada obrigatória para um processo 
adequado de auditoria.
( ) A NBR ISO/IEC 12207 não tem vinculação com métodos, ferramentas, 
treinamentos, métricas ou tecnologias empregadas.
( ) A NBR ISO/IEC 12207 pode ser usada com qualquer modelo de ciclo 
de vida, método ou técnica de engenharia de software e linguagem de 
programação.
Assinale a alternativa que apresenta a sequência CORRETA:
a) ( ) V – V – V – V.
b) ( ) V – F – V – V.
c) ( ) F – F – V – V.
d) ( ) V – V – F – V.
https://promovesolucoes.com/melhoria-de-processos-como-otimizar-a-rotina-e-os-resultados/
196
197
UNIDADE 3
1 INTRODUÇÃO
A equipe responsável por um projeto de desenvolvimento de software 
precisa ter um treinamento específico de segurança da informação, a fim de 
compreender como mensurar os riscos durante o processo e como as falhas do 
desenvolvimento podem gerar vulnerabilidades (BEZERRA, 2004; SILVA, 2007; 
NETO, 2012). A segurança precisa ser abordada já no início do desenvolvimento, 
já que os custos são menores, para construir um sistema seguro, do que o 
comparado com os custos para corrigir os problemas após a entrega do produto 
final ao cliente (IMONIANA, 2005, NETO, 2012; ALVES, 2016). 
Algumas organizações têm, no seu quadro de profissionais, equipes 
especializadas em segurança, para ajudar as outras equipes nos projetos, mas essa 
não é uma realidade da maioria das empresas de desenvolvimento de software 
(ALVES, 2016). 
Em decorrência do aumento do desenvolvimento de softwares para a 
internet, é essencial compreender os riscos de sistemas mal desenvolvidos (SILVA, 
2007; COSTA, 2010; ALVES, 2016). Então, neste tópico, você conhecerá os passos 
para treinar a equipe de densenvolvimento para que todos pensem na segurança 
em cada uma das partes do ciclo de desenvolvimento de um software. 
2 IMPACTOS 
Os impactos são considerados como os danos causados pela concretização 
dos riscos. Isso significa que o ativo da informação foi danificado, perdido ou 
utilizado de modo indevido (NOVO, 2010; NETO, 2012). Você poderá observar, 
por meio da figura a seguir, que quanto maior o valor do ativo, maior será o valor 
do impacto. Já quanto menor o grau do risco, menor será o valor do impacto. 
TÓPICO 3 — 
TREINAMENTO DE SEGURANÇA
198
UNIDADE 3 — SEGURANÇA E AUDITORIA NO DESENVOLVIMENTO DO SOFTWARE
FIGURA 18 – RELAÇÃO ENTRE RISCO E IMPACTO
FONTE: Novo (2010, p. 35)
É importante identificar as vulnerabilidades e as ameaças; calcular os 
riscos; avaliar os ativos de informação; e estar preparado para mitigar os impactos 
(BEZERRA, 2004; IMONIANA, 2005; NOVO, 2010). A auditoria é uma das ações 
que mitiga a existência de riscos e os custos dos impactos, por meio da diminuição 
e da eliminação de vulnerabilidades e de ameaças (IMONIANA, 2005; SILVA, 
2007; NETO, 2012; ALVES, 2016). 
Diante do atentado ao World Trade Center (Estados Unidos da América), no 
dia 11 de setembro de 2001, muitas organizações deixaram de existir em decorrência da 
destruição completa dos ativos de informação. Porém, o risco de o atentado ocorrer e ter 
sucesso era considerado mínimo, entretanto, ocorreu, e o impacto foi devastador (NOVO, 
2010).
NOTA
TÓPICO 3 — TREINAMENTO DE SEGURANÇA
199
FIGURA 19 – REPRESENTAÇÃO ENTRE IMPACTOS E RISCOS
FONTE: Novo (2010, p. 36)
• Riscos naturais, dependendo do potencial do evento, podem ser 
complicados para haver uma proteção eficaz. Entretanto, sabendo-se que tais eventos 
são rotineiros em determinada região, fica mais simples adotar ações planejadas de 
prevenção dos impactos, minimizando os danos quando da concretização, e podendo 
retornar à normalidade das atividades da organização (NOVO, 2010; NETO, 2012). 
• Riscos involuntários: a identificação da origem tem relação com as vulnerabilidades 
humanas, físicas, de hardware, de software, com os meios de armazenamento 
e as comunicações. Geralmente, ocorrem por falha na condução do sistema de 
gerenciamento de segurança da informação (NOVO, 2010; NETO, 2012).
NOTA
200
UNIDADE 3 — SEGURANÇA E AUDITORIA NO DESENVOLVIMENTO DO SOFTWARE
Outro ponto de vulnerabilidade tem relação com os funcionários e 
prestadores de serviço. Isso torna os recursos humanos uma grande preocupação 
para a implementação de políticas e treinamentos direcionados à proteção das 
informações (NOVO, 2010; ALVES, 2016).
A ausência de uma cultura de segurança das informações estabelece 
um ambiente vulnerável. Desse modo, a implementação de um novo fluxo de 
trabalho (workflow) não depende somente de um bom plano, mas, também, do 
engajamento dos colaboradores (NOVO, 2010; NETO, 2012; ALVES, 2016). Para 
que tudo ocorra do modo planejado, é preciso que haja o envolvimento de toda 
a equipe ao longo do processo, já que ela será a executora do plano de trabalho 
(NETO, 2012).
A organização precisa oferecer treinamentos para que as tarefas sejam 
executadas de modo adequado, essencialmente, acerca das novas ferramentas 
que serão usadas (SILVA, 2007; NETO, 2012). A organização precisa investir na 
formação continuada da equipe, além de cultivar as boas práticas (NOVO, 2010; 
NETO, 2012). Com isso, será mais tranquilo o processo de implementação e de 
manutenção de um novo fluxo de trabalho.
As figuras a seguir mostrarão a importância do workflow, além de como 
criá-lo. 
Desenvolver um workflow (fluxo de trabalho) eficiente, que aumente os 
resultados de uma organização e reduza os custos, é um dos desafios dos gestores. Para 
iniciar a estruturar um fluxo de trabalho em uma determinada organização, é necessário 
conhecer a atual situação em que ela se encontra. Com esses dados, é possível identificar 
o fluxo de trabalho dessas áreas deficitárias, além de possibilitar a implementação de 
melhorias.
NOTATÓPICO 3 — TREINAMENTO DE SEGURANÇA
201
FONTE: <https://nfeblog.blob.core.windows.net/blg/blog/content/uploads/2018/12/que-e-work-
flow.png>. Acesso em: 19 out. 2020.
FIGURA 20 – IMPORTÂNCIA DO WORKFLOW
202
UNIDADE 3 — SEGURANÇA E AUDITORIA NO DESENVOLVIMENTO DO SOFTWARE
FIGURA 21 – COMO CRIAR UM WORKFLOW EM NOVE PASSOS
FONTE: <https://bit.ly/2XUOF8N>. Acesso em: 19 out. 2020.
3 ORGANIZAÇÃO DO TRABALHO DE AUDITORIA 
O processo de organização dos trabalhos de auditoria de sistemas segue 
as seguintes estruturas didáticas:
• planejamento; 
• escolha da equipe, programação da equipe; 
• execução e documentação de trabalho; 
TÓPICO 3 — TREINAMENTO DE SEGURANÇA
203
• supervisão em campo; 
• revisão dos papéis de trabalho, conclusão e emissão (follow-up) de relatórios; 
• atualização do conhecimento permanente e avaliação da equipe. 
3.1 PLANEJAMENTO
O planejamento em auditoria de sistemas de informações é essencial para 
orientar o desenvolvimento dos trabalhos, além de evitar surpresas que possam 
prejudicar o trabalho dos auditores (IMONIANA, 2005; NOVO, 2010; NETO, 
2012). 
Nesta etapa, deve ser construída uma "Matriz de Risco" permanentemente 
atualizada, e da seguinte maneira (NETO, 2012):
• resultados obtidos nos testes e nas avaliações dos auditores;
• impacto das mudanças ocorridas no negócio resultantes de alterações de 
estratégias empresariais;
• evoluções tecnológicas;
• alterações estatutárias, legislações.
3.2 ESCOLHA DA EQUIPE
Um planejamento completo e com base nas principais alterações do 
negócio indica o perfil básico da equipe de auditoria, contemplando o seguinte 
(IMONIANA, 2005):
• perfil e histórico profissional;
• experiência acumulada por ramos de atividade;
• conhecimentos específicos;
• apoio do grupo de especialização;
• formação acadêmica;
• línguas estrangeiras;
• disponibilidade para viagens.
Assista ao seguinte vídeo: https://www.youtube.com/watch?v=4iKZDDjwnKs.
DICAS
204
UNIDADE 3 — SEGURANÇA E AUDITORIA NO DESENVOLVIMENTO DO SOFTWARE
3.3 PROGRAMAÇÃO DA EQUIPE
O encarregado de auditoria deve programar a equipe para realizar os 
trabalhos. A programação de uma equipe de auditores com o perfil adequado 
para a execução do trabalho não é suficiente para garantir que todos os riscos 
de auditoria sejam mitigados pelos testes de auditoria (MAGALHÃES, 2001; 
IMONIANA, 2005; COSTA, 2010). Para isso, é preciso observar as habilidades, 
estas que possibilitam:
• gerar programas de trabalho que extraiam dados corretos para testes;
• selecionar procedimentos mais apropriados;
• incluir novos procedimentos;
• classificar trabalhos por visita;
• orçar tempo e registrar o real;
• evidenciar corretamente os trabalhos realizados; 
• gerar relatórios em consonância com os trabalhos efetuados. 
Seguem os membros da organização e as suas respectivas funções durante 
o processo de auditoria.
QUADRO 10 – FUNÇÕES DOS MEMBROS DE UMA ORGANIZAÇÃO
TIPO DE MEMBRO CARACTERÍSTICAS
DIRETORIA DA 
ORGANIZAÇÃO
- Dar o bom exemplo com o cumprimento das 
medidas de controle estabelecidas para a segurança 
da informação. 
- Aprovar as políticas, normas e procedimentos de 
segurança da informação.
- Apoiar as medidas de segurança dentro da 
organização.
- Patrocinar as iniciativas, campanhas, seminários 
e treinamentos voltados para a segurança da 
informação.
- Disponibilizar recursos, quando necessário.
- Promover a avaliação periódica dos controles 
estabelecidos.
COMITÊ GESTOR 
DE SEGURANÇA DA 
INFORMAÇÃO (CGSI)
- Coordenar a segurança da informação, presidida 
pelo diretor de tecnologia da informação.
- Padronizar procedimentos em situações 
normais, e equacionar situações críticas, passíveis 
de consequências sérias, que exigem um 
tratamento focado em posturas administrativas e 
operacionais voltadas para eliminar improvisos 
e gastos desnecessários, viabilizando o retorno à 
normalidade das atividades da organização.
TÓPICO 3 — TREINAMENTO DE SEGURANÇA
205
FONTE: Adaptado de Imoniana (2005), Lyra (2009) e Neto (2012)
Os aspectos que podem influenciar o apoio da auditoria de sistemas 
em um processo de desenvolvimento de software em relação à equipe serão 
apontados a seguir.
QUADRO 11 – RELAÇÃO DOS ASPECTOS QUE PODEM INFLUENCIAR A AUDITORIA 
CONSIDERANDO A FORMAÇÃO DA EQUIPE
FUNCIONÁRIOS
- Ter conhecimento e zelar pela política de segurança 
da informação.
- Cumprir as normas e procedimentos de segurança 
estabelecidos.
- Comunicar qualquer evento ou incidente de SI de 
que tiver conhecimento ao setor de tecnologia da 
informação.
PRESTADORES DE 
SERVIÇO, COLABO-
RADORES, CLIENTES, 
FORNECEDORES E 
REPRESENTANTES 
DO PODER PÚBLICO
- Zelar pelo cumprimento das normas e 
procedimentos de segurança estabelecidos. 
- Comunicar qualquer evento ou incidente de SI de 
que tiver conhecimento ao setor de tecnologia da 
informação.
1. Equipe com experiência em auditoria no desenvolvimento de software
2. Gerência com experiência em auditoria no desenvolvimento de software
3. Participação do cliente nas etapas do processo
4. Existência de apoio automatizado
5. Alto comprometimento da gerência com o projeto
6. Apoio da direção da empresa
7. Treinamento formal da equipe no processo de desenvolvimento de software
8. Responsabilidades claramente definidas
9. Existência de orientações para a realização da auditoria no desenvolvimento 
de software
10. Apoio à utilização do conhecimento de experiências em projetos anteriores
11. Ambiente físico de trabalho adequado
12. Existência de um grupo de auditoria de sistemas na empresa
206
UNIDADE 3 — SEGURANÇA E AUDITORIA NO DESENVOLVIMENTO DO SOFTWARE
13. Existência de auditorias da aderência ao processo de desenvolvimento de 
software
14. Iniciar a implantação da auditoria no desenvolvimento de softwares por 
um conjunto específico de atividades
15. Iniciar a implantação da auditoria no desenvolvimento de softwares de 
maneira uniforme
16. Disciplina no atendimento às recomendações geradas pela equipe de 
auditoria de sistemas
17. O processo de desenvolvimento de software estar alinhado aos objetivos do 
negócio da organização
18. O processo de desenvolvimento de software estar baseado em expectativas 
realistas
FONTE: Neto (2012, p. 190)
3.3.1 Papéis e responsabilidades
Os treinamentos em segurança da informação precisam alcançar todos os 
funcionários de uma organização, através de palestras, workshops, seminários, 
cursos de extensão e especialização (KOSCIANKI; SOARES, 2007; NETO, 2012; 
ALVES, 2016). O objetivo deve ser a conscientização da importância da segurança 
da informação, além do exercício das atividades funcionais dentro dos requisitos 
de segurança estabelecidos pela organização (COSTA, 2010; NETO, 2012; ALVES, 
2016). As orientações gerais e específicas de segurança devem estar disponíveis 
para consulta. 
Além dos funcionários, os clientes, fornecedores, colaboradores e 
acionistas também precisam receber orientações dos procedimentos a serem 
adotados em relação à segurança da informação (IMONIANA, 2007; COSTA, 
2010; NETO, 2012). O treinamento envolve aplicação de treinamento básico e 
avançado aos membros da equipe de desenvolvimento de software (SILVA, 2007; 
ALEVS, 2016). Os conceitos básicos do desenvolvimento de software são (NETO, 
2012; ALVES, 2016): 
• Desenho seguro, envolvendo a redução da superfície de ataque;
• Defesa em profundidade;
• Princípio do privilégio mínimo;
• Defaults seguros.
3.4 EXECUÇÃO DE TRABALHOS E SUPERVISÃO
As tarefas precisam ser efetuadas por auditores que tenham formação, 
experiência e treinamento no ramo da especialização. Dependendo da 
complexidade do ambiente operacional, aparente risco envolvido, os trabalhos 
TÓPICO 3 — TREINAMENTO DE SEGURANÇA
207
serão desenvolvidos de acordo com a vivência profissional (KOSCIANKI; 
SOARES, 2007; NETO, 2012; ALVES, 2016). A questão da supervisão é inerente 
ao processo de auditoria para garantir a qualidade e certificar que as tarefas 
sejam realizadas do modo correto e eficaz (IMONIANA, 2005;NETO, 2012). Isso 
possibilita cobrir os riscos prováveis identificados.
3.5 REVISÃO DOS PAPÉIS DE TRABALHOS
Como tarefa de atingir a qualidade exigida pelas práticas de auditoria, 
os papéis de trabalho são revisados pelos superiores. Eventualmente, em 
decorrência dos trabalhos de auditoria, falhas ou recomendações para melhorias 
são identificadas e limitam a conclusão do auditor, assim como determinados 
procedimentos que não tenham sido concluídos por restrições do próprio cliente 
(ALBUQUERQUE; RIBEIRO, 2002; BEZERRA, 2004; NETO, 2012).
O revisor, não identificando outros passos de auditoria independentes, 
poderá solicitar uma nova visita para completar os trabalhos. Contudo, para as 
pendências de revisão, deve ser analisado o reflexo do aumento ou alteração do 
escopo, além de novos trabalhos, nova abordagem, impacto no parecer final e na 
carta de representação da gerência (ALBUQUERQUE; RIBEIRO, 2002; NAVAS, 
2006; NETO, 2012).
Ao revisar os papéis, quando se adota a estratégia de Paperless Audit, a 
intenção das ferramentas de workflow é fundamental para garantir a integridade 
do processo de revisão dos papéis (NAVAS, 2006; SILVA, 2007; NETO, 2012). 
3.6 ATUALIZAÇÃO DO CONHECIMENTO PERMANENTE
O conhecimento em auditoria é fundamental e serve como início para os 
próximos períodos. A manutenção adequada da documentação dos processos 
contribui para a redução das horas de auditoria do período seguinte (NOVO, 
2010; NETO, 2012). Dentre as informações relevantes, destacam-se (NOVO, 2010):
• Descrição do processo de negócio.
• Levantamento e avaliação do ambiente de controle.
• Documentação e conclusão da avaliação dos controles dos processos 
relevantes.
• Matriz de risco que pontue riscos aparentes para todos os principais 
componentes da demonstração financeira.
• Exceções dos testes.
• Falhas ou fraquezas nos testes de controle internos.
• Programas de trabalho.
208
UNIDADE 3 — SEGURANÇA E AUDITORIA NO DESENVOLVIMENTO DO SOFTWARE
3.7 AVALIAÇÃO DA EQUIPE
A fim de garantir a evolução e o aprimoramento técnico dos profissionais 
da equipe de auditoria, deve-se, para cada trabalho, emitir, eletronicamente, uma 
avaliação de desempenho já preenchida pelo superior, isso é fundamental para 
nortear a promoção ou não do profissional (NETO, 2012).
3.8 DOCUMENTAÇÃO DOS PAPÉIS DE TRABALHO
Os papéis de trabalho constituem um conjunto de formulários 
preenchidos logicamente no processo de auditoria de sistemas, com seus anexos 
que evidenciem os fatos relatados (NOVO, 2010; NETO, 2012). 
Os papéis de trabalho sistêmicos são guardados em bases de dados. 
Essas bases de papéis constituem informações de planejamento, execução, 
monitoramento e revisões, follow-up, controles do usuário do sistema e senhas e 
alguns recursos de auxílio ao usuário (NOVO, 2010; NETO, 2012). 
4 CONTROLES ORGANIZACIONAIS E OPERACIONAIS
Os controles organizacionais e operacionais são definidos como os 
controles administrativos que são instalados nos processos e fluxo das transações 
econômicas e financeiras dos sistemas de informações (SILVA, 2007; NOVO, 2010; 
NETO, 2012).
O funcionamento adequado desse controle está relacionado com a 
experiência organizacional dos gestores, já que é necessária a demonstração 
de práticas e habilidades gerenciais (IMONIANA, 2005; NOVO, 2010; NETO, 
2012). As responsabilidades do profissional correspondem às seguintes tarefas 
(IMONIANA, 2005):
• delineamento das responsabilidades operacionais;
• coordenação de orçamento de capital de informática e bases;
• desenvolvimento e implementação das políticas globais de informática;
• intermediação com terceiros (networking);
• gerenciamento de suprimentos;
• desenvolvimento do plano de capacitação.
Para que os controles organizacionais tenham o resultado esperado, é 
preciso ocorrer lealdade, além da confiança entre a organização e os funcionários 
(IMONIANA, 2005; NOVO, 2010). Os funcionários devem ser tratados de modo 
adequado para evitar a falta de motivação e respeito aos controles. 
TÓPICO 3 — TREINAMENTO DE SEGURANÇA
209
5 O PAPEL DO USUÁRIO 
A informação é um ativo valioso e necessário, no entanto, as pessoas são 
os principais atores responsáveis pela segurança da informação. A informação é 
essencial para todas as organizações, estas procuram a disponibilidade de modo 
ágil, íntegro e confidencial (NOVO, 2010; NETO, 2012).
Para que a tecnologia e os processos estejam disponíveis de modo 
adequado e possibilitem a integridade e a confidencialidade da informação 
que recebem, processam, armazenam e distribuem, existe um fator essencial, 
que são as pessoas, ou seja, o usuário (SILVA, 2007; NETO, 2012). Caso este não 
siga o conjunto de regras ou práticas estabelecidas, corre-se o risco de produzir 
informacões que irão levar a organização a tomar decisões incorretas (NOVO, 
2010; ALVES, 2016). 
FIGURA 22 – RESPONSÁVEIS PELA INTEGRIDADE DAS INFORMAÇÕES
FONTE: <https://bit.ly/3sCILHv>. Acesso em: 28 out. 2020.
Conforme Novo (2010, p. 25), “o usuário precisa ser sensibilizado para as 
questões de segurança, principalmente, para os efeitos negativos que uma falha ou 
quebra de segurança pode ocasionar”. Grandes problemas e ameaças observados 
na implementação de práticas e procedimentos na segurança da informação são 
os usuários (NOVO, 2010; NETO, 2012). Por isso, é fundamental promover, dentro 
da organização, uma cultura de segurança para garantir que as boas práticas 
sejam um componente natural do comportamento dos usuários, portanto, os 
usuários são considerados elementos que provocam vulnerabilidades e eventuais 
210
UNIDADE 3 — SEGURANÇA E AUDITORIA NO DESENVOLVIMENTO DO SOFTWARE
danos aos sistemas, sendo pertinente verificar se estão sensibilizados para o uso 
de práticas adequadas e seguras no desempenho das tarefas (IMONIANA, 2005; 
COSTA, 2010; ALVES, 2016).
FIGURA 23 – CHARGE DE SEGURANÇA DA INFORMAÇÃO
FONTE: <https://bit.ly/3sFePdR>. Acesso em: 28 out. 2020.
Leia esta reportagem das principais práticas de segurança para os usuários:
https://blogbrasil .comstor.com/6-dicas-praticas-de-seguranca-da-informacao-
para-usuarios. Veja, também, o vídeo disponível em: https://www.youtube.com/
watch?v=MVCwxgz7Ifo&feature=emb_logo.
DICAS
https://blogbrasil.comstor.com/6-dicas-praticas-de-seguranca-da-informacao-para-usuarios
https://blogbrasil.comstor.com/6-dicas-praticas-de-seguranca-da-informacao-para-usuarios
TÓPICO 3 — TREINAMENTO DE SEGURANÇA
211
LEITURA COMPLEMENTAR
PIX NÃO TERÁ SEGURANÇA DEDICADA E BC NÃO SE 
RESPONSABILIZARÁ POR HACKS
O Banco Central do Brasil lançará o PIX em poucos dias e a grande 
pergunta é: será que ele é seguro? O Cointimes foi atrás de dados para deixar 
mais claro esse lado ainda pouco conhecido do novo sistema de pagamentos.
Criado em resposta ao avanço do Bitcoin e das criptomoedas, o Pix quer 
virar o novo padrão de transação interbancária no Brasil. Feito com apenas R$10 
milhões e com perspectivas de lançamento com recursos ainda incompletos, a 
dúvida sobre a segurança do Pix é real para algumas pessoas.
Para outras fica implícito que o BC teria uma equipe de segurança dedicada 
ao PIX, alguma auditoria externa sobre o produto e até mesmo um plano no caso 
de hacking, certo? 
Qual a segurança do Pix?
Segundo informações liberadas com exclusividade ao Cointimes, o BC 
conta com um orçamento estimado de R$4,97 milhões dedicado a segurança 
cibernética. A autoridade monetária máxima do país afirmou que esse valor é 
para toda área de segurança da informação, incluindo o Pix. 
Ou seja, para o exercício de 2020 não houve provisionamento específico 
para a área do novo meio de pagamento. Isso fica claro quando é afirmado que 
a equipe de segurança do BC é de 28 pessoas “responsáveis de modo global por 
todos os sistemas, incluindo aqueles relacionados ao Pix”, declarou o próprio 
banco.
Entretanto, procuramos os profissionais do Banco Central disponíveis no 
LinkedIn e encontramos apenas 4 que mencionam “segurança da informação” 
e termos correlatosno perfil. Isso não significa que são apenas 4 servidores 
cuidando dessa área, pois há também a possibilidade que alguns prefiram não 
participar das redes sociais (por questões de segurança). 
Se compararmos os números do Pix com os do bitcoin veremos a diferença 
na preocupação com a área de segurança da informação entre os dois projetos. 
Apenas no hashrate (que ajuda a manter a rede do Bitcoin segura) há pelo 
menos US$2.600.571.400 investidos em máquinas específicas de mineração. Isso 
significa que o investimento na segurança do bitcoin é de pelo menos 1456 vezes 
maior que no Pix. 
https://cointimes.com.br/o-que-e-bitcoin-cotacao-e-como-funciona/
https://cointimes.com.br/banco-central-revela-custo-da-criacao-do-pix-e-ele-e-razoavel/
https://cointimes.com.br/banco-central-revela-custo-da-criacao-do-pix-e-ele-e-razoavel/
212
UNIDADE 3 — SEGURANÇA E AUDITORIA NO DESENVOLVIMENTO DO SOFTWARE
Em relação ao número de desenvolvedores, o Bitcoin Core (apenas um 
dos clientes do BTC), conta com 29 desenvolvedores financiadores por empresas 
e fundações como Xapo, OkCoin, Blockstream, Chain Code Labs, Bitpay e outras. 
Fora que o Bitcoin é um projeto completamente aberto e descentralizado, 
isso significa que qualquer pessoa pode fazer uma auditoria externa. Por 
exemplo, em setembro de 2018 um desenvolvedor do Bitcoin Cash achou um bug 
de inflação no Bitcoin Core que permitia a criação de milhões de moedas.
Claro, são sistemas diferentes e com designs completamente opostos, mas 
já pensou se alguém, por acaso, acha alguma falha no sistema do Pix e infla a 
conta bancária de algumas pessoas? Ou simplesmente apaga o saldo de todos os 
usuários?
E se acontecer um hack no Pix?
Se um possível hack não for detectado pela pequena equipe não dedicada 
do BC, provavelmente a instituição nunca saberá o que aconteceu. 
Pois, segundo o Banco Central, “não está prevista a contratação de 
nenhuma auditoria externa especificamente para o Pix”. Entretanto, ele afirma 
que há uma auditoria geral feita pela KPMG, CGU e TCU, mas nada dedicado ao 
novo sistema de pagamentos. 
Sem auditoria, profissionais dedicados apenas ao Pix e uma verba 
pequena, o que acontece se acontecer um hack? Perguntamos ao BC via Lei de 
Acesso à Informação e a resposta foi a seguinte:
“No âmbito do Pix, não haverá relacionamento direto entre os usuários 
e o Banco Central. Todo pagamento realizado ou recebido se dará por meio 
dos participantes do Pix, que são as instituições financeiras e as instituições 
de pagamento que aderirem ao arranjo, a quem incumbe garantir a adequada 
segurança para as transações de seus clientes. Desse modo, não cabe ao Banco 
Central a responsabilização por eventuais prejuízos decorrentes de ataques 
cibernéticos aos sistemas das instituições participantes do Pix. Sugere-se, nesses 
casos, que o interessado entre em contato diretamente com a instituição com a 
qual mantém relacionamento”.
Aparentemente, nosso bc não acredita que o próprio sistema do Pix 
possa ser hackeado e coloca a responsabilidade nas instituições financeiras. Mas 
é realmente possível hacker um sistema como o criado pela maior instituição 
financeira do país?
É impossível hacker o Banco Central? O FED acha que não
Se você acha que o Banco Central é impossível de hacker, pense duas 
vezes. O Banco Central da Europa, com uma verba maior que o correspondente 
TÓPICO 3 — TREINAMENTO DE SEGURANÇA
213
tupiniquim, teve seu site hackeado em 2019 mesmo após fazer testes e auditorias 
de segurança.
Em fevereiro de 2016, um hacker transferiu ilegalmente US$1 bilhão das 
contas do FED de Nova York via SWIFT (sistema de pagamentos interbancário 
internacional). A conta hackeada era do Banco Central de Bangladesh.
Em outro caso emblemático, alguns hackers conseguiram desviar ao 
menos US$15 milhões do banco estatal mexicano Bancomext em 2018.
Será que o dinheiro no Pix está realmente seguro? Boa sorte aos que vão 
descobrir. 
FONTE: <https://cointimes.com.br/pix-nao-tera-seguranca-dedicada-e-bc-nao-se-responsabili-
zara-por-hacks/>. Acesso em: 29 out. 2020.
https://www.forbes.com/sites/daveywinder/2019/08/16/european-central-bank-breach-ecb-confirms-hack-and-shuts-down-website/#2eb9da8594bd
https://en.wikipedia.org/wiki/Bangladesh_Bank_robbery
https://www.wired.com/story/mexico-bank-hack/
https://cointimes.com.br/pix-nao-tera-seguranca-dedicada-e-bc-nao-se-responsabilizara-por-hacks/
https://cointimes.com.br/pix-nao-tera-seguranca-dedicada-e-bc-nao-se-responsabilizara-por-hacks/
214
RESUMO DO TÓPICO 3
 Neste tópico, você aprendeu que:
• A equipe responsável por um projeto de desenvolvimento de software 
precisa ter um treinamento específico sobre segurança da informação, a fim 
de compreender como mensurar os riscos durante o processo e como as falhas 
do desenvolvimento podem resultar em vulnerabilidades.
• Os impactos são considerados como os danos causados pela concretização 
dos riscos. Isto significa, que o ativo de informação foi danificado, perdido, 
ou utilizado de modo indevido.
• A auditoria é considerada uma das ações que mitigam a existência de 
riscos e os custos dos impactos, por meio da diminuição e eliminação de 
vulnerabilidades e de ameaças.
• Em riscos naturais, dependendo do potencial do evento, pode ser complicado 
ter uma proteção eficaz. 
• Riscos involuntários: a identificação da sua origem tem relação com as 
vulnerabilidades humanas, físicas, de hardware, de software. 
• A ausência de uma cultura da segurança das informações estabelece um 
ambiente vulnerável. 
• A organização precisa investir na formação continuada da sua equipe, bem 
como cultivar as boas práticas.
• Para estruturar um fluxo de trabalho em uma determinada organização, é 
necessário conhecer a atual situação em que ela se encontra. Com esses dados 
é possível identificar o fluxo de trabalho dessas áreas deficitárias e possibilitar 
a implementação de melhorias. 
• O planejamento em auditoria de sistemas de informações é essencial para 
orientar o desenvolvimento dos trabalhos, bem como evitar surpresas que 
possam prejudicar o trabalho dos auditores.
• Um planejamento completo e com base nas principais alterações do negócio 
indica o perfil básico da equipe de auditoria.
• O encarregado de auditoria deve programar a equipe para realizar os 
trabalhos. A programação de uma equipe de auditores com o perfil adequado 
para a execução do trabalho não é suficiente para garantir que todos os riscos 
de auditoria sejam mitigados pelos testes de auditoria.
215
• Os treinamentos em segurança da informação precisam alcançar todos 
os funcionários de uma organização, através de palestras, workshops, 
seminários, cursos de extensão e especialização.
• As tarefas precisam ser efetuadas por auditores que tenham formação, 
experiência e treinamento no ramo de especialização. Dependendo da 
complexidade do ambiente operacional, aparente risco envolvido, os trabalhos 
serão desenvolvidos de acordo com a vivência professional.
• Como tarefa de atingir a qualidade exigida pelas práticas de auditoria, os 
papéis de trabalho são revisados pelos superiores. 
• Conhecimento em auditoria é fundamental e serve como início para os 
próximos períodos. A manutenção adequada da documentação dos processos 
contribui para a redução das horas de auditoria do período seguinte.
• Os papéis de trabalho constituem um conjunto de formulários preenchidos 
logicamente no processo de auditoria de sistemas, com seus anexos que 
evidenciem os fatos relatados.
• Os controles organizacionais e operacionais são definidos como os controles 
administrativos que são instalados nos processos e fluxo das transações 
econômicas e financeiras dos sistemas de informações.
• A informação é um ativo valioso e necessário, no entanto as pessoas são os 
principais atores responsáveis pela segurança da informação. A informação 
é essencial para todas as organizações, estas procuram a disponibilidade da 
dela de modo ágil, íntegro e confidencial.
• Os usuários sãoconsiderados um dos elementos que provocam 
vulnerabilidades e eventuais danos aos sistemas, sendo pertinente verificar 
se estão sensibilizados para o uso de práticas adequadas e seguras no 
desempenho das suas tarefas.
Ficou alguma dúvida? Construímos uma trilha de aprendizagem 
pensando em facilitar sua compreensão. Acesse o QR Code, que levará ao 
AVA, e veja as novidades que preparamos para seu estudo.
CHAMADA
216
1 Os impactos são considerados como os danos causados pela concretização 
dos riscos. Isto significa, que o ativo de informação foi danificado, perdido, 
ou utilizado de modo indevido (NOVO, 2010; NETO, 2012). Análise a figura 
e explique a relação entre risco e impacto.
FONTE: Novo (2010, p. 35)
2 A ausência de uma cultura da segurança das informações estabelece um 
ambiente vulnerável. Deste modo, a implementação de um novo fluxo de 
trabalho (workflow) não depende somente de um bom plano, mas também 
do engajamento dos colaboradores (NOVO, 2010; NETO, 2012; ALVES, 
2016). Dessa forma, assinale a alternativa INCORRETA:
a) ( ) Para iniciar a estruturar um fluxo de trabalho (workflow) em uma 
determinada organização, é necessário conhecer a atual situação 
em que ela se encontra.
b) ( ) É preciso que haja o envolvimento de toda a equipe ao longo do 
processo, já que eles serão os executores do plano de trabalho.
c) ( ) A organização precisa oferecer treinamentos para que as tarefas 
sejam executadas de modo adequado, essencialmente sobre as 
novas ferramentas que serão usadas.
d) ( ) A auditoria é mais tranquila onde ocorreu a manutenção fluxo de 
trabalho já existente na estrutura organizacional. 
3 A programação de uma equipe de auditores com o perfil adequado para 
a execução do trabalho não é suficiente para garantir que todos os riscos 
de auditoria sejam mitigados pelos testes de auditoria (MAGALHÃES, 
2001; IMONIANA, 2005; COSTA, 2010). Dessa forma, liste os aspectos 
que podem influenciar o apoio da auditoria de sistemas num processo de 
desenvolvimento de software em relação à equipe.
AUTOATIVIDADE
217
4 Os treinamentos em segurança da informação precisam alcançar todos 
os funcionários de uma organização, através de palestras, workshops, 
seminários, cursos de extensão e especialização (KOSCIANKI; SOARES, 
2007; NETO, 2012; ALVES, 2016). Dessa forma, assinale a alternativa 
CORRETA:
a) ( ) O treinamento envolve aplicação de treinamento simples aos 
membros da equipe de desenvolvimento de hardware.
b) ( ) Os funcionários e acionistas recebem orientações básicas com 
relação à segurança da informação.
c) ( ) O objetivo deve ser a conscientização sobre a importância da 
segurança da informação, bem como o exercício das atividades 
funcionais dentro dos requisitos de segurança estabelecidos pela 
organização. 
d) ( ) As orientações resumidas ou em forma de esquema sobre segurança 
devem estar disponíveis para consulta de modo on-line. 
5 O conhecimento em auditoria é fundamental e serve como início para 
os próximos períodos. A manutenção adequada da documentação dos 
processos contribui para a redução das horas de auditoria do período 
seguinte (NOVO, 2010; NETO, 2012). Sobre o exposto, classifique V para as 
sentenças verdadeiras e F para as falsas:
( ) A fim de garantir a evolução e o aprimoramento técnico dos 
profissionais da equipe de auditoria, deve-se para cada trabalho emitir 
eletronicamente uma avaliação de desempenho já preenchida pelo 
superior.
( ) Os papéis de trabalho constituem um conjunto de formulários 
preenchidos logicamente no processo de auditoria de sistemas, com 
seus anexos que evidenciem os fatos relatados.
( ) Os controles organizacionais e operacionais são definidos como os 
controles administrativos que são instalados nos processos e fluxo das 
transações econômicas e financeiras dos sistemas de informações.
( ) O usuário precisa ser sensibilizado para as questões de segurança, 
principalmente para os efeitos negativos que uma falha ou quebra de 
segurança podem ocasionar.
 
Assinale a alternativa que apresenta a sequência CORRETA:
( ) V – V – V – V.
( ) V – F – V – V.
( ) F – F – V – V.
( ) V – V – F – V.
REFERÊNCIAS
ALBUQUERQUE, R.; RIBEIRO, B. Segurança no desenvolvimento de software. 
Rio de Janeiro: Campus, 2002.
 
ALMEIDA, J.; GRACIA, C.; JUNIOR, F.; DIAS, D. Visão geral do método de 
avaliação padrão CMMI para melhoria de processos – SCAMPI. Brasília: Uni-
versidade Católica de Brasília, 2007.
ALVES, P. M. de A. Ferramentas informatizadas utilizadas na auditoria. Volta 
Redonda: Universidade Federal Fluminense, 2016. 
ANDRADE, J. M.; ALBUQUERQUE, A. B.; CAMPOS, F. B.; ROCHA, A. R. C. 
Consequências e características de um processo de desenvolvimento de sof-
tware de qualidade e aspectos que o influenciam: uma avaliação de especialis-
tas. Brasília: Universidade de Brasília, 2004. 
ARRIAL, C. T. Ferramentas computacionais aplicadas aos trabalhos de audito-
ria interna. Brasília: Instituto Serzedello Corrêa/TCU, 2009. 
BEZERRA, C. A qualidade do processo de desenvolvimento de software a par-
tir da gestão de projetos: um estudo de caso. Brasília: Universidade de Brasília, 
2004. 
COSTA, F. A. Modernização dos processos de auditoria e fiscalização da ICP 
Brasil. Florianópolis: Universidade do Estado de Santa Catarina – UDESC, 2010. 
COUTO, A. CMMI: integração dos modelos de capacitação e maturidade de 
sistemas. Rio de Janeiro: Ciência Moderna, 2007.
DIAS, C. Segurança e auditoria da tecnologia da informação. São Paulo: Axcel 
Books, 2000. 
GHERMAN, M. Principais características do framework COBIT. São Paulo: 
Sicurezza, 2005. 
GOMES, D. Software de código aberto: o que é e quais suas vantagens. 2020. 
Disponível em: https://sambatech.com/blog/insights/codigo-aberto/. Acesso em: 
19 out. 2020.
GOMES, A.; OLIVEIRA, K.; ROCHA, A. R. Avaliação de processos de software 
baseada em medições. XV Simpósio Brasileiro de Engenharia de Software. Rio 
de Janeiro. 2001. 
GUETNER, A. V. 5 etapas para realizar auditoria interna na sua empresa. 2019. 
Disponível em: https://funcionalconsultoria.com.br/post/5-etapas-para-realizar-
-auditoria-interna-na-sua-empresa. Acesso em: 19 out. 2020.
IMONIANA, J. O. Auditoria de sistemas de informação. São Paulo: Atlas, 2005.
ISO/IEC/JTC 1. Information technology. ISO/IEC 15408-1:2009 Information 
technology -- Security techniques -- Evaluation criteria for IT security -- Part 1: 
Introduction and general model. 2009. 
JACOBSON, I.; BOOCH, G.; RUMBAUGH, J. The unified software develop-
ment process. USA: Addison-Wesley Professional, 1999. 
KOSCIANKI, A.; SOARES, M. S. Qualidade de software: aprenda as metodo-
logias e técnicas mais modernas para o desenvolvimento de software. 2. ed. São 
Paulo: Novatec Editora, 2007.
LIMA, I. Inteligência artificial chega aos sistemas antifraude com aprendizado 
de máquina. 2017. Disponível em: https://canaltech.com.br/infra/inteligencia-
-artificial-chega-aos-sistemas-antifraude-com-aprendizado-de-maquina-96820/. 
Acesso em: 19 out. 2020.
LYRA, M. R. Segurança e auditoria de sistema de informação. Rio de Janeiro: 
Ciência Moderna, 2009. 
MAGALHÃES, A. de D. F. Auditoria das organizações: metodologias alterna-
tivas ao planejamento e à operacionalização dos métodos e das técnicas. São 
Paulo: Atlas, 2001. 
MARTINEZ, M. R. M.; SALVIANO, C. F. Método para estabelecimento de 
referências em ciclos de melhoria de processo. Belo Horizonte: Fundação de 
Desenvolvimento Gerencial, 2011. 
MATOS, G. Clientes da Ledger são alvo de golpes com e-mail falso. 2020. Dis-
ponível em: https://www.criptofacil.com/clientes-ledger-sao-alvo-golpes-com-e-
-mail-falso/. Acesso em: 28 out. 2020.
MENESES, J. B.; MOURA, H. P. Um processo de avaliação de progresso para 
projetos de software. São Paulo: Atlas, 2001. 
MOREIRA, A.; COTA, E.; RIBEIRO, L.; GASPARY, L.; CARRO, L.; RITT, M.; 
WEBER, T. Em direção a um modelo para desenvolvimento de sistemas com-
putacionais de qualidade para aplicações onivalentes. São Paulo:Marques 
Saraiva, 2007.
MORGADO, V. O impacto da tecnologia da informação no trabalho de audito-
ria. Brasília: Universidade de Brasília, 2008. 
https://funcionalconsultoria.com.br/post/5-etapas-para-realizar-auditoria-interna-na-sua-empresa
https://funcionalconsultoria.com.br/post/5-etapas-para-realizar-auditoria-interna-na-sua-empresa
https://canaltech.com.br/infra/inteligencia-artificial-chega-aos-sistemas-antifraude-com-aprendizado-de-maquina-96820/
https://canaltech.com.br/infra/inteligencia-artificial-chega-aos-sistemas-antifraude-com-aprendizado-de-maquina-96820/
https://www.criptofacil.com/clientes-ledger-sao-alvo-golpes-com-e-mail-falso/
https://www.criptofacil.com/clientes-ledger-sao-alvo-golpes-com-e-mail-falso/
NAVAS, J. Um método para a melhoria do processo de desenvolvimento de sof-
tware aplicando conceitos de CMM, SPICE e da Norma ISO 12207. São Paulo: 
Marques Saraiva, 2006. 
NETO, F. X. F. Proposta de método de auditoria aos projetos de software baseados 
no processo unificado. São Paulo: Centro Estadual de Educação Tecnológica Paula 
Souza, 2012.
NOVO, J. P. da C. Softwares de segurança da informação. Amazonas: Centro de 
Educação Tecnológica do Amazonas – CETAM, 2010.
PIRUS, B. Auditoria de segurança recente da Ledger não relacionada à violação de 
dados de junho. 2020. Disponível em: https://cointelegraph.com.br/news/ledger-s-
-recent-security-audit-was-unconnected-to-their-data-breach-in-june. Acesso em: 29 
out. 2020.
POMPEU, G. Qualidade de software CMMI – Módulo 2 – Representação contínua 
– CMMI 1.2 for development. Rio de Janeiro: Elsevier, 2006.
SAM, H. Tamanho do mercado global de software de segurança de pagamentos, 
participação, demanda e taxa de crescimento notável até 2026. 2020. Disponível 
em: http://cmykdigest.com/204636/tamanho-do-mercado-global-de-software-de-se-
guranca-de-pagamentos-participacao-demanda-e-taxa-de-crescimento-notavel-ate-
-2026-pesquisa-de-mercado-zion/. Acesso em: 20 out. 2020.
SCHMIDT, P.; SANTOS, J. L.; ARIMA, C. H. Fundamentos de auditoria de siste-
mas. São Paulo: Atlas, 2006.
SEI. Software Engineering Institute. CMMI for development, version 1.3. 2020. Dis-
ponível em: http://www.sei.cmu.edu/library/abstracts/reports/10tr033.cfm. Acesso 
em: 28 maio 2011. 
SILVA, P. M. G. A função auditoria de sistemas de informação: modelo funcional e 
de competências. Portugal: Universidade do Minho, 2007.
SOFTEX. MPS.BR – Melhorias de processos do software brasileiro. 2020. Disponí-
vel em: www.softex.br. Acesso em: 28 jun. 2012. 
SOMMERVILLE, I. Engenharia de software. 9. ed. São Paulo: Pearson Addison 
Wesley, 2011. 
 
STAIR, R. M. Princípios de sistemas de informação: uma abordagem gerencial. Rio 
de Janeiro: Livros Técnicos e Científicos, 1998. 
http://cmykdigest.com/204636/tamanho-do-mercado-global-de-software-de-seguranca-de-pagamentos-participacao-demanda-e-taxa-de-crescimento-notavel-ate-2026-pesquisa-de-mercado-zion/
http://cmykdigest.com/204636/tamanho-do-mercado-global-de-software-de-seguranca-de-pagamentos-participacao-demanda-e-taxa-de-crescimento-notavel-ate-2026-pesquisa-de-mercado-zion/
http://cmykdigest.com/204636/tamanho-do-mercado-global-de-software-de-seguranca-de-pagamentos-participacao-demanda-e-taxa-de-crescimento-notavel-ate-2026-pesquisa-de-mercado-zion/
http://www.sei.cmu.edu/library/abstracts/reports/10tr033.cfm
http://www.softex.br
https://cointelegraph.com.br/authors/benjamin-pirus
https://cointelegraph.com.br/authors/benjamin-pirus
https://cointelegraph.com.br/authors/benjamin-pirus
https://cointelegraph.com.br/authors/benjamin-pirus
https://cointelegraph.com.br/authors/benjamin-pirus