ATPS Desenvolvimento de Software Seguro - Etapa 1

Prévia do material em texto

FACULDADE ANHANGUERA – UNIDADE CAMPINAS I
TECNOLOGIA EM ANÁLISE E DESENVOLVIMENTO DE SISTEMAS
DESENVOLVIMENTO DE SOFTWARE SEGURO – ETAPA 01
ALUNO RA
QUEMUEL SANTOS DE AQUINO 8309737322
PAULO VICTOR DE MENEZES 2848233367
SIDMAR PORFÍRIO 7989711257
LEONARDO CUENCAS 7700620660
ATIVIDADE PRÁTICA SUPERVISIONADA (ATPS)
TUTOR: PROF. RICARDO AUGUSTO DA SILVA
CAMPINAS, 27 DE MAIO DE 2015.
SUMÁRIO
INTRODUÇÃO .........................................................................................................................................3
A IMPORTÂNCIA DO SOFTWARE SEGURO .............................................................................................3
REQUISITOS DE SEGURANÇA DE SOFTWARE .........................................................................................8
RELATÓRIO 01 – DESENVOLVENDO SOFTWARES SEGUROS ................................................................22
RELATÓRIO 02 - EVITANDO ESTOURO DE BUFFER ...............................................................................26
REFERÊNCIAS BIBLIOGRÁFICAS ............................................................................................................32
2
INTRODUÇÃO
A cada dia um número maior de computadores está conectado a Internet e junto a esta
expansão crescem também os ataques aos sistemas informatizados, colocando softwares,
organizações e usuários em grande risco. Mesmo as organizações adotando mecanismos de
controles e políticas de segurança, o software sempre foi e será o vetor de ataques.
Oferecer um software seguro é obrigação do desenvolvedor e para que este objetivo seja
alcançado é necessário avaliar a segurança de todo o ciclo de vida de desenvolvimento da
aplicação. Esta avaliação melhora os produtos de TI, pois identifica erros ou vulnerabilidades
que podem ser corrigidas pelo desenvolvedor, reduzindo a probabilidade de futuras falhas de
segurança, além disso, faz o desenvolvedor tomar mais cuidado com a estrutura e
desenvolvimento do software.
Para ter segurança no desenvolvimento é necessário manter fontes em segurança, evitando
roubos ou indisponibilidade da equipe de desenvolvimento, seguir especificações de
segurança evitando vulnerabilidades que comprometam a segurança e oferecer garantias aos
clientes quanto à segurança e integridade da aplicação.
Abaixo apresentaremos uma série de tratativas que aumentarão nossos conhecimentos sobre
identificação de problemas e correções de possíveis falhas de segurança em um sistema
empresarial.
A IMPORTÂNCIA DO SOFTWARE SEGURO
O desenvolvimento de sistemas é uma das áreas mais afetadas pelos aspectos da segurança.
Muitos dos problemas existentes hoje não são, nem físicos e nem de procedimento, mas sim,
causados por erros de programação ou de arquitetura. 
Muitas vezes, para não “perder” muito tempo e entregar a solução em tempo breve, os
requisitos de segurança são deixados de lado. Como os clientes não possuem noções sobre
3
segurança, só saberão mais tarde quando encontrarem uma vulnerabilidade. Isso acontece
porque poucos analistas preocupam-se em especificar bem os requisitos de segurança.
A segurança em sistemas sempre foi importante e com a internet a segurança tornou-se o
foco, uma vez que os sistemas tendem a ficar mais interconectados, facilitando acessos
indevidos. Dessa forma, temos que a segurança será cada vez mais uma preocupação no
desenvolvimento de sistemas.
Tem-se como premissa que nenhum software é seguro. A segurança de um software é afetada
porque ele pode executar outros procedimentos os quais não foram propostos. Se ele fizesse
exatamente o que foi destinado a fazer, a segurança não seria uma preocupação. Portanto,
existe uma facilidade para invasores investigarem vulnerabilidades desconhecidas e
dificuldade dos desenvolvedores em garantir que todos os pontos de entrada do sistema
estejam protegidos.
Para saber se um sistema é seguro, na década de 80 surgiu o primeiro padrão para avaliação
de segurança em softwares que ficou conhecido como Orange Book. 
Mais tarde este padrão foi homologado pela International Standartization Organization (ISO)
como ISO/IEC 15408, que muitas vezes é chamada apenas de Common Criteria (CC).
A ISO/IEC 15408 determina que um sistema deva ter seu Security Target (ST) (objetivo ou
alvo de segurança) definido para ser considerado seguro. "O ST é a especificação de
segurança, ou seja, indica quais aspectos de segurança foram considerados importantes e
porque o foram para aquele sistema em particular".
- Segurança da informação
A segurança da informação tem como objetivo a proteção da informação para reduzir a
probabilidade e o impacto de incidentes de segurança. Segundo especialistas, está provado
que um incidente de segurança ocorre quando um evento pode causar interrupções nos
processos de negócio em decorrência da violação de alguma propriedade de segurança. Neste
contexto, temos as três propriedades básicas da segurança:
4
- confidencialidade: capacidade de um sistema permitir que alguns usuários acessem
determinadas informações ao mesmo tempo e impedir que outros, não autorizados, a vejam;
- integridade: a informação deve estar correta, ser verdadeira e não estar corrompida;
- disponibilidade: a informação deve estar disponível para todos que precisarem dela para a
realização dos objetivos empresariais.
Além destas três propriedades principais, têm-se também as seguintes propriedades
conceituadas:
- autenticação: capacidade de garantir que um usuário, sistema ou informação é mesmo quem
alega ser;
- não repúdio: capacidade do sistema de provar que um usuário executou determinada ação no
sistema;
- legalidade: aderência de um sistema a legislação;
- privacidade: capacidade que um sistema tem em manter incógnito um usuário,
impossibilitado a ligação direta da identidade do usuário com as ações por este realizadas;
- auditoria: capacidade do sistema em verificar tudo o que foi realizado pelos usuários,
detectando fraudes ou tentativas de ataque. Note que este é um aspecto difícil de ser
totalmente conciliado com a privacidade.
Quando se tem a perda de qualquer propriedade da segurança importante para o sistema, tem-
se um problema de segurança. Assim, trabalha-se na prevenção para manter as propriedades
de segurança dentro das necessidades do cliente e evitar falhas. Por exemplo, um sistema que
deve estar disponível 24 horas, deve ter alta disponibilidade e não necessita tanto tratar
confidencialidade e privacidade dos dados. Nos sistemas militares ou de segurança nacional, o
ponto critico é a privacidade. Já em sistemas bancários, a integridade e a auditoria são os
pontos mais relevantes. Para cada tipo de sistema a necessidade de segurança é diferente, por
isso, deve ser tratada de forma distinta para cada caso.
No desenvolvimento do software é importante conhecer as vulnerabilidades de cada etapa do
desenvolvimento para que as ameaças iminentes possam ser removidas da forma mais célere
possível, eliminando assim os riscos da má gestão de custos e da descoberta de
5
vulnerabilidades já na finalização do software. Quando a empresa sofre essas ameaças
(ataques ou tentativas de ataques) é importante coletar as situações anteriores, a fim de que, os
dados possam ser analisados sempre que um novo sistema for desenvolvido. 
Como já sabemos, os níveis de segurança alteram de acordo com o âmbito de negócio que a
empresa possui, logo é importante é importante reunir os profissionais envolvidos no
desenvolvimento doSistema a fim de propor quais serão os critérios de avaliação para a
implantação da segurança e quais serão os níveis de segurança.
Para que os problemas no desenvolvimento de softwares sejam atenuados, é preciso adotar
padrões de códigos, normas e manuais de segurança a fim de que se possam evitar erros no
código fonte, além da etapa de testes que será muito importante a cada nova implementação
de levantamento de requisitos.
- Normas da Segurança da Informação
As normas e padrões têm por objetivo definir regras, princípios e critérios, registrar as
melhores práticas e prover uniformidade e qualidade a processos, produtos ou serviços, tendo
em vista sua eficiência e eficácia. Além disso, uma norma tem o propósito de definir regras,
padrões e instrumentos de controle que dêem uniformidade a um processo, produto ou
serviço. Ou seja, as normas são procedimentos e regras que visam garantir que um processo
seja feito sempre de forma igual e da maneira mais correta possível.
A rápida expansão da TI aliada a constante preocupação em garantir a integridade das
informações fez surgir normas capazes de garantir a segurança da informação. Esta expansão
fez com que houvesse um interesse internacional em uma norma de segurança da informação,
desta forma, em dezembro de 2000, foi publicada a norma internacional ISO 17799:2000.
Em 2001, a Associação Brasileira de Normas Técnicas (ABNT) publicou a versão brasileira
que ficou denominada como NBR/ISO 17799 – Código de Prática para a Gestão da Segurança
da Informação. Em setembro de 2005, a norma foi revisada e publicada como NBR ISO/IEC
17799:2005. O comitê que trata da segurança da informação na ISO aprovou a criação de uma
família de normas sobre gestão da segurança da informação, denominada pela série 27000,
onde a então ISO IEC 17799:2005 foi renomeada para ISO IEC 27002:2005.
6
- ISO 1779
Esta norma trata-se de um código de práticas com orientações para a gestão da segurança da
informação. Possui como característica descrever de forma geral as áreas consideradas
importantes de implantação ou gestão de segurança da informação dentro de uma
organização. De acordo com Lyra (2008), a ISO 17799 “é um código de prática de gestão de
segurança da informação e sua importância pode ser dimensionada pelo número crescente de
pessoas e variedades de ameaças a que a informação é exposta”. Estabelecer um referencial
para as organizações desenvolverem, implementarem e avaliarem a gestão da tecnologia da
informação e promover a confiança nas transações comerciais entre as organizações são os
objetivos explícitos desta norma.
A norma ISO 17799 está dividida em 12 tópicos:
- Objetivo;
- Termos e definições;
- Política de segurança;
- Segurança organizacional;
- Classificação e controle dos ativos de informação;
- Segurança de recursos humanos;
- Segurança física e do ambiente;
- Gerenciamento das operações e comunicações;
- Controle de acessos;
- Desenvolvimento e manutenção de sistemas de informação;
- Gestão de continuidade de negócios;
- Conformidade.
Estes 12 tópicos são macros áreas de gestão da segurança da informação e esta divisão ocorre
para que a gestão seja feita da forma mais eficaz possível. Se não houvesse esta divisão e a
segurança fosse tratada como um todo, os controles não seriam tão efetivos o que certamente
refletiria em uma má gestão da segurança da informação. Por meio destes tópicos é possível
realizar uma implantação em estágios, ou seja, pode ser implantada a política de segurança e 
7
depois a segurança organizacional, ou vice-versa, para depois colocar em prática as demais
orientações da norma. Dependendo do tamanho da organização é possível realizar a
implantação de apenas alguns tópicos desta norma.
- ISO 27001
Trata-se da única norma internacional auditável que define os requisitos para um Sistema de
Gestão de Segurança da Informação (SGSI). Possui como premissa assegurar a seleção de
controles de segurança adequados e proporcionais, ajudando a empresa a proteger seus ativos
da informação e dar confiança para todas as partes interessadas, de forma especial aos
clientes. A ISO 27001 adota uma abordagem de processo que engloba a implementação,
operação, monitoramento, revisão, manutenção e melhoria de um SGSI.
A norma define sua abordagem na aplicação de um sistema de processos em uma
organização, junto com a identificação e interações desses processos e sua correta gestão.
Desta forma, a ISO 27001 emprega o PDCA, Plan-Do-Check-Act (ciclo de desenvolvimento
que tem foco na melhoria contínua) para estruturar os processos. O ciclo PDCA proporciona
uma definição do escopo do sistema de gerenciamento de segurança da informação, planos
para tratamento de riscos, implementação de controles, medição da eficácia dos controles,
monitoramento e controle, revisões periódicas no sistema de segurança e a implementação de 
melhorias identificadas.
A ISO 27001 é aplicável para qualquer organização, grande ou pequena, em qualquer setor ou
parte do mundo, sendo mais utilizada onde a proteção da informação é crítica, como em
finanças, saúde, setores públicos e de TI. É altamente eficaz para as organizações que
gerenciam informação em nome de terceiros, bem como, companhias terceirizadas de TI, pois
ela pode ser usada para garantir aos clientes que suas informações estão sendo protegidas.
REQUISITOS DE SEGURANÇA DE SOFTWARE
Os requisitos de segurança de software são o conjunto de necessidades de segurança que o
software deve atender, sendo tais necessidades influenciadas fortemente pela política de
segurança da organização, e compreendendo aspectos funcionais e não-funcionais. 
8
Os aspectos funcionais descrevem comportamentos que viabilizam a criação ou a manutenção
da segurança e, geralmente, podem ser testados diretamente. Na maioria dos casos, remetem a
mecanismos de segurança como, por exemplo, controle de acesso baseado em papéis de
usuários (administradores, usuários comuns, entre outros.), autenticação com o uso de
credenciais (usuário e senha, certificados digitais, entre outros.), dentre outros. Os aspectos
não funcionais descrevem procedimentos necessários para que o software permaneça
executando suas funções adequadamente mesmo sob uso indevido. São exemplos de
requisitos não funcionais: validação de dados de entrada e a registro eventos em log de
auditoria com informações suficientes para análise forense.
A elicitação de requisitos de segurança de software consiste na definição das necessidades de
proteção exigidas pelo software. Tal atividade exige uma colaboração intensa entre os
interessados no software, especialmente daqueles com visão negocial, que podem ter
consciência das consequências no negócio decorrentes de incidentes de segurança, cujo vetor
de ataque se localize no software.
Algumas das técnicas mais usadas no levantamento de requisitos de segurança incluem:
- Brainstorming.
- Pesquisas de opinião (questionários e entrevistas).
- Decomposição da política.
- Classificação de dados.
- Matriz de objeto-sujeito.
- Modelagem de caso de uso e abuso.
Independente da técnica a ser usada, a elicitação de requisitos exige que pelo menos um dos
participantes na atividade tenha densidade em segurança de software, para que os fluxos
regulares que o software proverá ou já provêm sejam criticados, evidenciando maneiras de
subvertê-los. 
A definição dos cenários negativos, cuja realização é indesejada, resultará no requisito de
segurança. Segue, a título de ilustração, alguns exemplos de requisitos de segurança:
9- Confidencialidade
Senha e outros campos de entrada de dados sensíveis necessitam ser mascarados.
Senhas não devem ser armazenadas as claras nos sistemas backend, e quando armazenadas
devem passar por processo de hash com uma função pelo menos equivalente a SHA-256.
Transport Layer Security (TLS) como Secure Socket Layer (SSL) deve ser colocado em
prática para proteger contra ameaças internas de Man in the Middle (MITM) para todas as
informações de cartão de crédito que seja transmitida.
O uso de protocolos reconhecidamente inseguros como, por exemplo, File Transfer Protocol
(FTP) para transmitir credenciais de contas em texto claro a terceiros fora de sua organização
deve ser proibido.
Arquivos de log não devem armazenar qualquer informação sensível como definido pelo
negócio, de modo que seja compreensível por seres humanos.
- Integridade
Todos os formulários de entrada e query strings necessitam ser validadas frente a um conjunto
de entradas aceitáveis, antes do software aceita-los para processamento.
O software a ser publicado deve ser disponibilizado juntamente com o checksum e a função
hash usada pra computar o checksum, de modo que o interessado possa validar sua precisão e
completude.
Todos os personagens não humanos como um sistema ou processos batch devem ser
identificados, monitorados e impedidos de alteração de dados, a medida que ele passa no
sistema que eles rodam, a não ser que explicitamente autorizado para tal.
10
- Disponibilidade
O software deve oferecer alta disponibilidade de oito (8) noves (9), como definido pelo SLA.
O software deve estar preparado para atender capacidade máxima de 300 usuários
simultâneos.
O software e seus dados devem ser replicados por todos os centros de dados para prover
balanceamento de carga e redundância.
A funcionalidade de missão crítica no software deve ser restaurada a operação normal no
prazo de 1 hora de descontinuidade; funcionalidade de missão essencial no software deve ser
restaurada a operação normal no prazo de 4 horas da interrupção, e funcionalidade de missão
suporte no software deve ser restaurada a operação normal no prazo de 24 horas.
- Autenticação
O software será implantado somente na Intranet e o usuário autenticado deve fornecer
novamente suas credenciais para acessar a aplicação, uma vez que esteja autenticado na rede.
O software deverá suportar single sign on a terceiros e fornecedores que estão definidos na
lista de interessados.
A política de autenticação garante a necessidade para dois – ou autenticação com múltiplos
fatores para todos os softwares de processamento financeiro.
- Autorização
O acesso a arquivos secretos de alta sensibilidade deve ser restrito somente a usuários com
níveis de permissão secreto e super-secreto.
Os usuários não devem ser demandados a enviar suas credenciais sempre, uma vez que ele
tenha se autenticado com sucesso.
11
Todos os usuários autenticados herdarão a permissão de leitura somente que são parte do
papel do usuário convidado enquanto os usuários autenticados por padrão terão permissão de
leitura e escrita como parte do papel de usuário regular. Somente os usuários com acesso
administrativo, terão todos os direitos dos usuários regulares, adicionalmente a execução de
operações.
- Auditing and Logging
Todas as tentativas de logon devem ser registradas juntamente com o timestamp e o endereço
de IP de origem da requisição.
Os valores anterior e posterior a uma mudança de preço modificado por um usuário, quando
da atualização de um preço por um usuário, devem ser monitorados com os seguintes campos
auditados: identidade, ação, objeto e timestamp.
Os logs de auditoria devem sempre ser adicionados de novos registros e nunca sobrescritos.
Os logs de auditoria devem ser mantidos de forma segura por um período de 3 anos.
- Gerenciamento de Sessão 
Cada atividade do usuário deverá ser rastreada de modo único.
O software não deve solicitar as credenciais de acesso do usuário, uma vez que ele esteja
autenticado no Internet Banking.
As sessões devem ser explicitamente suspensas quando o usuário solicita o log off ou fecha a
janela do browser. 
Identificadores de sessão usados para identificar a sessão de usuários devem não ser passados
em claro ou ser facilmente adivinhado.
12
- Erros e Gerenciamento de Exceção
Todos os erros e exceções devem ser explicitamente manipulados a partir de blocos try, catch
e finally.
Mensagens de erro que são mostradas ao usuário revelarão somente a informação necessária,
sem vazamento de detalhes internos do sistema na mensagem de erro.
Detalhes de exceções de segurança devem ser auditados e monitorados periodicamente.
- Parâmetros de Configuração
Os dados sensíveis do arquivo de configuração da aplicação web, como strings de conexão,
devem ser encriptados.
Senhas e chaves de criptografia não devem ser registradas no código fonte do software.
A inicialização e a liberação de variáveis globais necessitam ser monitoradas com muito
cuidado.
Eventos de inicialização e interrupção de sessão devem incluir proteções na informação de
configuração como uma salvaguarda contra ameaças de vazamento.
Apesar de cômica, a imagem abaixo retrata de forma bastante trágica como grande parte dos
projetos citados nas estatísticas anteriores acabam sendo: uma equipe fragmentada com visões
completamente divergentes sobre o mesmo produto e um cliente que acaba pagando bem mais
por algo totalmente diferente do que ele precisava.
13
- Ciclo de vida de um Projeto
Como observado anteriormente, a realização de reuniões e treinamentos não é suficiente;
Geralmente, os recém-formados em faculdades de computação e outros cursos relacionados
não têm o treinamento necessário para começar a trabalhar imediatamente e não são capazes
de criar, desenvolver ou testar software seguro. Mesmo os que concluíram o treinamento
sobre segurança têm mais probabilidade de ter encontrado algoritmos criptográficos ou
modelos de controle de acesso do que saturações de buffer ou falhas de canonização. Em
geral, os designers, engenheiros e testadores de software também não têm as habilidades
apropriadas na área de segurança.
14
Sob essas circunstâncias, uma organização que procura desenvolver software seguro deve se
responsabilizar pelo treinamento adequado de sua equipe de engenharia. Os métodos
específicos usados para vencer esse desafio variam de acordo com o tamanho da organização
e com os recursos disponíveis. Uma organização com uma equipe de engenharia grande pode
se comprometer em compilar um programa interno para fornecer treinamento contínuo sobre
segurança para seus engenheiros. No entanto, uma organização pequena talvez precise contar
com treinamento externo.
Abaixo poderemos acompanhar algumas fases do Projeto que trarão maiores resultados aos
serviços de qualquer equipe.
- Fase de requisitos
A necessidade de considerar a segurança "de baixo para cima" é um princípio fundamental do
desenvolvimento de sistemas seguros. Embora vários projetos de desenvolvimento produzam
"próximas versões" baseadas nas versões anteriores, a fase de requisitos e o planejamento
inicial de uma nova versão oferecem a melhor oportunidade para criar software seguro.
- Durante a fase de requisitos, a equipe de produto entra em contato com a equipe de
segurança central para solicitar a designação de um supervisor de segurança que serve como
um ponto de contato, pesquisa e orientação durante o planejamento. 
- O supervisor de segurança ajuda a equipe de produto revisando os planos, fazendo
recomendações e garantindo que a equipe de segurança planeje recursos apropriadospara dar
suporte ao cronograma da equipe de produto. 
- O supervisor de segurança aconselha a equipe de produto sobre os marcos de segurança e os
critérios de saída que serão exigidos com base no tamanho, na complexidade e no risco do
projeto. 
- O supervisor de segurança continua sendo o ponto de contato da equipe de produto com a
equipe de segurança, desde o início do projeto até a conclusão da Revisão final de segurança e
o lançamento do software. 
15
- O supervisor de segurança também serve como ponto de contato entre a equipe de segurança
e a gerência da equipe de produto, e aconselha a gerência da equipe quanto ao controle do
elemento de segurança de seus projetos, de forma a evitar surpresas relacionadas à segurança
posteriormente durante o processo.
A fase de requisitos é a oportunidade para a equipe de produto considerar como a segurança
será integrada no processo de desenvolvimento, identificar os objetivos-chave de segurança e
maximizar a segurança de software, minimizando a quebra de planos e cronogramas. Como
parte desse processo, a equipe precisa considerar como os recursos de segurança e as medidas
de controle de seu software serão integrados com outros softwares que provavelmente serão
usados com ele. 
A perspectiva geral da equipe de produto sobre os objetivos, os desafios e os planos de
segurança deve se refletir nos documentos de planejamento produzidos durante a fase de
requisitos. 
Embora os planos estejam sujeitos a alterações conforme o andamento do projeto, a
articulação precoce desses planos ajuda a garantir que nenhum requisito seja desconsiderado
ou estabelecido na última hora.
Cada equipe de produto deve considerar os requisitos de recursos de segurança como parte
dessa fase. Embora alguns requisitos de recursos de segurança sejam identificados em
resposta à modelagem de ameaças, é provável que os requisitos do usuário determinem a
inclusão de recursos de segurança em resposta às exigências do cliente. Os requisitos dos
recursos de segurança também serão definidos de acordo com a necessidade de obedecer aos
padrões da indústria e dos processos de certificação, como os Critérios comuns. 
A equipe de produto deve reconhecer e refletir esses requisitos como parte de seu processo de
planejamento normal.
16
- Fase de design
A fase de design identifica a estrutura e os requisitos gerais do software. Da perspectiva de
segurança, os elementos-chave da fase de design são:
- Definir as diretivas de design e arquitetura de segurança: 
definir a estrutura geral do software, tendo como ponto de vista a segurança, e identificar os
componentes cujo funcionamento correto é essencial para a segurança (a "base de computação
confiável"). Identificar técnicas de design, como a organização em camadas, o uso de
linguagem com rigidez de tipos, a aplicação de privilégios mínimos e a minimização da
superfície de ataque, que se aplicam ao software globalmente. 
As particularidades dos elementos individuais da arquitetura serão detalhadas nas
especificações individuais de design, mas a arquitetura de segurança identifica uma
perspectiva geral no design da segurança.
- Documentar os elementos da superfície de ataque do software:
Como o software não atingirá uma segurança perfeita, é importante que apenas os recursos
que serão usados pela grande maioria dos usuários sejam expostos a todos eles por padrão, e
que esses recursos sejam instalados com o nível de privilégio mais baixo possível. A medição
dos elementos da superfície de ataque fornece à equipe de produto uma métrica constante da
segurança padrão e permite que a equipe detecte as instâncias em que o software se torna mais
suscetível a ataques. 
Algumas instâncias com uma maior superfície de ataque podem ser justificadas pela
usabilidade ou função de produto avançada, mas é importante detectar e questionar cada uma
dessas instâncias durante o design e a implementação, de forma a fornecer software com uma
configuração padrão tão segura quanto possível.
- Realizar a modelagem de ameaças: 
A equipe de produto realiza a modelagem de ameaças componente por componente. Usando
uma metodologia estruturada, a equipe do componente identifica os ativos que o software
17
deve gerenciar e as interfaces pelas quais esses ativos podem ser acessados. O processo de
modelagem de ameaças identifica as ameaças que podem danificar cada ativo e a
probabilidade de acontecerem danos (uma estimativa de risco). 
A equipe do componente identifica, então, as contramedidas que atenuam o risco na forma de
recursos de segurança, como a criptografia, ou na forma de funcionamento adequado do
software que protege os ativos contra danos. Sendo assim, a modelagem de ameaças ajuda a
equipe de produto a identificar as necessidades de recursos de segurança, bem como as áreas
em que são especialmente necessários testes de segurança e uma revisão cuidadosa do código.
O processo de modelagem de ameaças deve ter o suporte de uma ferramenta que capture
modelos de ameaças em um formulário legível por máquina para armazenamento e
atualização.
- Definir critérios de fornecimento complementar:
Os critérios básicos de fornecimento de segurança devem ser definidos no nível da
organização, mas as equipes de produto individuais ou de versões do software podem ter
critérios específicos que devem ser atendidos antes do lançamento do software. Por exemplo,
uma equipe de produto que desenvolva a versão atualizada de um software fornecido aos
clientes e sujeito a ataques extensivos pode solicitar que, por determinado tempo, a nova
versão fique livre de vulnerabilidades relatadas externamente antes de ser considerada pronta
para o lançamento. (Ou seja, o processo de desenvolvimento deve localizar e remover as
vulnerabilidades antes que elas sejam relatadas, em vez de a equipe de produto precisar
"corrigi-las" depois de serem relatadas.)
- Fase de implementação
Durante a fase de implementação, a equipe de produto gera o código, testa e integra o
software. As etapas seguidas para remover falhas de segurança ou evitar sua inserção inicial
durante essa fase têm um aproveitamento alto; elas reduzem significativamente a
probabilidade de que vulnerabilidades de segurança estejam presentes na versão final do
software que é lançada para os clientes.
Os resultados da modelagem de ameaças fornecem uma orientação particularmente
importante durante a fase de implementação. Os desenvolvedores dedicam atenção especial
18
em corrigir o código de modo a atenuarem as ameaças de alta prioridade e os testadores
concentram seus testes na garantia de que essas ameaças estejam de fato bloqueadas ou
atenuadas.
Os elementos do ProjetoL que são aplicados na fase de implementação são:
Aplicar padrões de codificação e teste. Os padrões de codificação ajudam os desenvolvedores
a evitar a introdução de falhas que podem levar a vulnerabilidades de segurança. Por exemplo,
a utilização de construções de manipulação de seqüências e de buffer mais consistentes e
seguras pode ajudar a evitar a introdução de vulnerabilidades de saturação do buffer. As
práticas recomendadas e os padrões de testes ajudam a garantir que os testes se concentrem 
na detecção de possíveis vulnerabilidades de segurança e não apenas na operação correta de
funções e recursos do software.
Aplicar ferramentas de testes de segurança, incluindo ferramentas de difusão. A "difusão"
oferece entradas estruturadas mas inválidas para APIs (interfaces de programação de
aplicativo) de software e interfaces de rede,de forma a maximizar a probabilidade de detectar
erros que podem levar a vulnerabilidades de software.
Aplicar ferramentas de verificação de código de análise estática. As ferramentas podem
detectar alguns tipos de falhas de código que resultam em vulnerabilidades, incluindo
saturações do buffer, de números inteiros e variáveis não inicializadas. A Microsoft fez um
investimento importante no desenvolvimento dessas ferramentas (as duas que têm sido mais
usadas são conhecidas como PREfix e PREfast) e as aperfeiçoa continuamente conforme
novos tipos de falhas de código e vulnerabilidades de software são descobertos.
Realizar revisões de código. As revisões de código complementam os testes e as ferramentas
automatizadas; para isso, elas aplicam os esforços de desenvolvedores treinados no examine
do código-fonte e na detecção e remoção de possíveis vulnerabilidades de segurança. Elas são
uma etapa essencial no processo de remoção de vulnerabilidades de segurança do software
durante o processo de desenvolvimento.
19
- Fase de verificação
A fase de verificação é o ponto em que o software está funcionalmente concluído e entra em
testes beta por usuários. Durante essa fase, enquanto o software passa por testes beta, a equipe
de produto realiza um "esforço de segurança" que inclui revisões do código de segurança
além das concluídas na fase de implementação, bem como testes de segurança direcionados.
Realizar o esforço de segurança durante a fase de verificação garante que a revisão de código
e os testes tenham como objetivo a versão final do software, e oferece uma oportunidade para
revisar o código desenvolvido ou atualizado durante a fase de implementação e o "código
herdado" que não foi modificado.
O primeiro desses motivos reflete um acidente histórico: a decisão de iniciar um esforço de
segurança ocorreu inicialmente durante a fase de verificação. Mas a Microsoft concluiu que
realizar um esforço de segurança durante a fase de verificação é realmente uma prática
recomendada para garantir que o software final preencha os requisitos e permitir uma revisão
mais profunda do código herdado que tenha sido transferido de versões anteriores do
software.
É importante notar que as revisões de código e os testes do código de alta prioridade (aquele
que é parte da "superfície de ataque" do software) são críticos para várias partes do Projeto.
Por exemplo, essas revisões e esses testes devem ser exigidos na fase de implementação para
permitir a correção precoce de quaisquer problemas, além da identificação e da correção da
origem desses problemas. Eles também são críticos na fase de verificação, quando o produto
está perto de ser concluído.
- Fase de suporte e manutenção
Apesar da todo esforço realizado, as práticas de desenvolvimento mais avançadas ainda não
dão suporte ao fornecimento de software completamente livre de vulnerabilidades, e há bons
motivos para acreditarmos que isso nunca acontecerá. Mesmo que o processo de
desenvolvimento pudesse eliminar todas as vulnerabilidades do software fornecido, novos
20
ataques seriam descobertos e o software que era "seguro" estaria vulnerável. Assim, as
equipes de produto devem se preparar para responder a vulnerabilidades recém-descobertas
no software fornecido aos clientes.
Parte do processo de resposta envolve a preparação para avaliar relatórios de vulnerabilidades
e lançar orientações e atualizações de segurança quando apropriado. O outro componente do
processo de resposta é a condução de um post-mortem das vulnerabilidades relatadas e a
adoção de medidas, conforme necessário. 
As medidas em resposta a uma vulnerabilidade variam de emitir uma atualização para um erro
isolado até atualizar as ferramentas de verificação de código e iniciar revisões do código dos
principais subsistemas. O objetivo durante a fase de resposta é aprender a partir dos erros e
utilizar as informações fornecidas em relatórios de vulnerabilidade para ajudar a detectar e
eliminar mais vulnerabilidades antes que sejam descobertas no campo e utilizadas para
colocar os clientes em risco. O processo de resposta também ajuda a equipe de produto e a
equipe de segurança a adaptar processos de forma que erros semelhantes não sejam
introduzidos no futuro.
Para iniciar o processo e impactar os produtos em desenvolvimento, os esforços de segurança
compactavam atividades que deveriam ter sido distribuídas em várias fases e em um período
relativamente curto. 
- Treinamento obrigatório
Um aspecto importante dos esforços de segurança é o treinamento de toda a equipe
(desenvolvedores, testadores, gerentes de programa e pessoal de documentação). Dependendo
da solução desenvolvida, vale a pena elaborar pelo menos soluções anuais, que farão total
diferença para a equipe e integridade do Programa desenvolvido.
A necessidade de uma atualização anual se baseia no fato de a segurança não ser um domínio
estático: as ameaças, os ataques e as defesas evoluem. Como resultado, mesmo os
engenheiros totalmente competentes e qualificados nos aspectos da segurança que afetam seu
software devem ter um treinamento adicional, conforme o cenário das ameaças muda. 
21
- Resultados
O teste final mede o quanto o Sistema é capaz de remover e atenuar as vulnerabilidades. A
experiência, demonstra se o Sistema passa nesse teste. A empresa também deve avaliar as
vulnerabilidades relatadas externamente com relação ao seu efeito sobre versões do software
em desenvolvimento. Medidas de segurança planejadas para ou implementadas em novas
versões bloqueiam ataques que seriam efetivos em versões mais antigas em um número cada
vez maior de casos. 
O desenvolvimento e a implementação do Ciclo de vida do desenvolvimento da segurança
representa um investimento importante para a empresa e uma mudança essencial na forma
como o software é criado, desenvolvido e testado.
RELATÓRIO 01 - DESENVOLVENDO SOFTWARES SEGUROS
Quando uma organização cosidera a implementação de um processo de desenvolvimento de
software, três perguntas são comumente feitas pela gerência:
1. Quanto isso vai custar?
2. Como posso medir os resultados?
3. Como posso justificar o investimento?
Para auxiliar as organizações a responder a estas perguntas e definir um processo que seja
acessível, mensurável e justificável, preparamos a documentação em questão, que é baseado
na experiência real de empresas de desenvolvimento.
Ao final deste será possível:
- Entender e comunicar os benefícios de uma abordagem estruturada no desenvolvimento de
um software com segurança.
- Desenvolver e usar métricas para melhorar o processo e definir o retorno sobre o
investimento (ROI).
- Obter resultados concretos e otimizar o uso de um orçamento limitado. 
22
- O que é segurança? 
Uma pesquisa realizada pela empresa de antivírus Kaspersky Lab mostra que muitos usuários
de computadores não atualizam softwares populares quando são lançadas correções de
segurança. O relatório “Avaliação do nível de ameaça das vulnerabilidades de software”
identificou mais de 132 milhões de aplicações vulneráveis instaladas em PCs, totalizando uma
média de 12 vulnerabilidades por usuário.
Segundo o relatório, quase dois terços (64%) das falhas em softwares estão presentes em
programas “mais ou menos obsoletos”, ou seja, algumas versões antigas de títulos populares
permanecem instaladas em um número significativo de máquinas por meses ou até mesmo
anos.
Mesmo quando um fornecedor de software faz o seu melhor para reconhecer uma falha de
segurança e lançar uma atualização em tempo hábil, isso não significa nadapara uma
proporção significativa de usuários. Uma vulnerabilidade conhecida, perigosa e explorável 
permanece aberta em milhões de PCs meses depois de ser descoberta e uma atualização ser
fornecida. Há exemplos de vulnerabilidades de software que duram por anos, diz o relatório.
Como já sabemos, desenvolver um software não é uma tarefa trivial, já que, além da
habilidade em programação, também é necessário compreender a regra de negócio e sempre
visar melhorias independente do tipo do cliente. Durante o desenvolvimento, o nosso maior
objetivo obviamente é satisfazer as necessidades pelas quais o sistema foi concebido. Mas
será que só isso é importante?
Antes de entrar no assunto, vale ressaltar o conceito de “requisitos funcionais” e a sua
importância na qualidade do produto final.
Requisitos funcionais são as necessidades apontadas pelo cliente, ou seja, o que ele quer que o
sistema faça. Gerenciar vendas, manter fornecedores e emitir relatórios mensais são exemplos
de requisitos funcionais, que geralmente são obtidos durante a etapa de levantamento de
requisitos junto ao cliente e demais usuários. Portanto, boa parte da qualidade do software
23
está centrada em atender tais requisitos, uma vez que esse é o comportamento esperado pelo
cliente. 
Imagine um sistema onde somente 8 das 10 funções solicitadas foram implementadas. Em
uma analogia, é a mesma coisa que comprar um carro que não possui freios e faróis: ele anda,
mas uma hora irá bater. É importante implementar cada requisito do cliente, e é por isso que
existem as fases de análise e modelagem em um projeto.
O problema é que, na preocupação de satisfazer as necessidades do cliente, os
desenvolvedores esquecem que existem os requisitos não-funcionais, que também
influenciam bastante na qualidade do software.
Requisitos não-funcionais são as características e aspectos internos do sistema, envolvendo
especificamente a parte técnica. Ao contrário dos requisitos funcionais, estes requisitos não
são explicitamente expostos pelo cliente, mas devem ser implicitamente compreendidos pelo
desenvolvedor. Os requisitos não-funcionais basicamente se resumem em seis itens, descritos
logo abaixo.
- Descrição dos requisitos não-funcionais
Segurança: o software deve garantir a segurança dos dados, bem como as permissões de
acesso às suas funcionalidades, como, por exemplo, usar criptografia em senhas e liberar
acesso aos menus do sistema de acordo com a hierarquia do usuário. Quando se trata de um
software com informações confidenciais (como dados de vendas, faturamentos ou citações de
pessoas), este item se torna indispensável.
Usabilidade: procure desenvolver um sistema fácil de operar e que dispense muitos recursos
gráficos. Se possível, adicione descrições das funções (hints) aos botões e configure teclas de
atalho para as funções mais utilizadas. Quanto mais simples for a usabilidade, maior será a
aceitação dos usuários.
Confiabilidade: determina a capacidade do sistema em lidar com eventos inesperados.
Suponha que o usuário esteja cadastrando um novo registro, e após inserir todas as
24
informações, ocorre um erro no sistema e o usuário acaba perdendo as informações digitadas.
Revoltante, não? A primeira coisa que ele irá fazer é pedir pra trocar o software, e
dependendo das circunstâncias o pedido é atendido, rsrs. A confiabilidade significa que o
sistema deve ser capaz de tratar exceções e se recuperar de falhas, sem que haja perda de
dados. Backup e restauração do banco de dados também se encaixam neste item.
Padrão: define a padronização de interface e código utilizada no desenvolvimento do
software. Embora seja mais voltado para a equipe de desenvolvimento, é essencial para
facilitar a manutenção e atualização do sistema. Este item também envolve conceitos de
arquitetura, como utilizar MVC, padrões de projeto ou frameworks.
Desempenho: de nada adianta ter um sistema seguro, interativo e confiável se ele consome
muitos recursos do computador e demora pra executar os processamentos. Um sistema lento é
alvo de crítica dos usuários, mesmo que seja funcional. A performance do software pode ser
melhorada utilizando técnicas de programação orientada a objetos, gerenciamento de
memória, threads e otimização de código. Outros fatores como consultas SQL no banco de
dados e liberação de recursos da memória também devem ser estudados para aprimorar o
desempenho.
Hardware e Software: define os requisitos mínimos para o funcionamento adequado do
software. Por exemplo, se o sistema faz integração com o Microsoft Outlook, este deve estar
instalado no computador como pré-requisito. Da mesma forma, se o sistema trabalha em rede,
é necessário que o computador tenha uma interface física de rede instalada. Esse item também
abrange a portabilidade do software para outros sistemas, tal como a sua facilidade de
configuração.
Essas são algumas das características que podem ser citadas, respeitando os fundamentos da
Engenharia de Software.
25
RELATÓRIO 02 - EVITANDO ESTOURO DE BUFFER
Considerando que segurança a respeito da informação é um assunto que sempre interessa a
todos os tipos de usuários, seja o usuário comum, o gerente de banco de dados, o
programador, o administrador de rede, o hacker, entre outros é notável a preocupação
com o desenvolvimento de softwares cada vez mais elaborados, e com maior controle de
qualidade. Mesmo que de forma simplificada, os dados de um sistema capaz de gerar
uma informação sejam cuidadosamente protegidos, existe a grande preocupação em
manter a integridade desses dados, além do acesso restrito aos mesmos. Assim, algumas
medidas devem ser adotadas com a finalidade de melhoria do software e tornando-o
mais seguro. 
Pode-se entender que o buffer overflow é o resultado do armazenamento de uma quantidade
maior de dados que sua capacidade suporta. Ao executar programas, são criados processos
de execução, estes são divididos em quatro regiões: texto, pilha, dados e heap.
O buffer overflow baseado em estouro de pilha é fruto do comprometimento das regiões de
texto, pilha ou dados, uma vez que a área de heap faz uma alocação dinâmica de memória. A
região de texto refere-se ao código do programa, é fixa pelo programa e inclui as instruções
propriamente ditas e os dados somente-leitura. Por esta razão, qualquer tentativa de
sobrescrevê-la resulte em violação de segmentação. 
A região de dados contém as variáveis globais e estáticas do programa. A região heap
permite a alocação dinâmica de memória por meio de chamadas da família malloc. A área de
heap cresce em sentido oposto à pilha e em direção a esta. 
A região da pilha é um bloco de memória contíguo utilizado para armazenar as variáveis
locais, passar parâmetros para funções e armazenar os valores de retornos destas. O
endereço de base da pilha é fixo e o acesso à estrutura é realizado por meio das instruções
PUSH e POP implementadas pelo processador. 
26
Visualizando a estrutura do buffer como uma pilha, ao exceder sua capacidade de
armazenamento de dados, ocorre o “estouro”. E este é o principal problema da pilha, uma vez
que o atacante consegue se privilegiar do programa alvo alterando seu endereço de retorno
para um código malicioso. O sucesso num ataque desse tipo permite ao atacante desde
danos como o travamento de uma máquina à vantagens de um superusuário (root).
A substituição de comandos, a atualização do sistema e de compiladores queum
desenvolvedor utiliza são alguns cuidados e medidas simples de se adotar a fim de se
evitar possíveis ataques de estouro de pilha, isso porque com essas medidas, consegue-se
inibir a passagem de dados extras para a pilha, evitando o problema de estouro de
pilha. Assim, torna-se de extrema importância gerenciar de maneira mais segura um
sistema, a fim de evitar que a falha, ou a exploração destas ocorram. O gerenciamento
envolve limitar benefícios de acesso a um arquivo; dificultar a escalada de privilégios; além
de dificultar o roubo e a perda de informações sigilosas. 
Tomando por base essas considerações, o software se tornará um alvo menos vulnerável
e menos propício a exploração de vulnerabilidades, o que em teoria o afasta da mira de
hackers. 
Existem três tipos de ataque considerados buffer overflow: baseado em estouro de pilha,
baseado em heap, e baseado em retorno à libC.
Neste documento falaremos apenas do buffer overflow baseado em estouro de pilha,
decorrente das falhas nas regiões de dados, texto e/ou pilha. 
Frente à evolução dos mecanismos de ataque, as invasões e o constante aprimoramento dos
invasores apesar da notável melhoria da qualidade do software, ainda é notável que etapas de
testes muitas vezes não são realizadas da maneira mais adequada. Esse fator faz surgir a
preocupação de usuários e empresas em evitar que sejam vitimados. Através das explicações
do princípio do funcionamento dos métodos de ataque em nível kernel, o chamado kernel
hacking, consegue-se uma compreensão que facilita a busca por melhorias em prol de um
sistema mais seguro e/ou menos vulnerável. 
27
- Buffer Overflow
- Buffers
são áreas de memória criadas pelos programas para armazenar dados que estão sendo
processados de maneira análoga. Neste documento, visando uma melhor compreensão é
possível referenciar buffer como pilha. Cada pilha tem um determinado tamanho que depende
do tipo de dados que ele irá armazenar. 
A situação de buffer overflow ocorre quando o programa recebe mais dados do que está
preparado para armazenar na pilha. Desta forma, se o programa não foi adequadamente
escrito este excesso de dados pode acabar sendo armazenado em áreas de memória
próximas o que acaba corrompendo dados ou travando o programa. Ainda há a possibilidade
do mesmo ser executado que é a mais perigosa devido a uma possível escalada de privilégios.
O princípio básico do buffer overflow consiste em estourar o buffer e ao sobrescrever
parte da pilha altera os valores das variáveis locais, parâmetros e/ou o endereço de
retorno (return address). Ao alterar o endereço de retorno de uma função o buffer overflow
faz com que o endereço aponte para uma área em que o código encontra-se
armazenado. Normalmente o novo endereço apontado é um código malicioso dentro
do próprio buffer estourado. 
Pode-se assim, executar códigos arbitrários com os privilégios do usuário que executa o
programa vulnerável. Os principais alvos são serviços de sistema ou aplicações que
executam com privilégios de superusuário.
A Figura abaixo representa a pilha do buffer após a inserção de alguns parâmetros: 
28
Acima, é possível verificar a existência de dois registradores utilizados para controle de uma
pilha. São eles: EBP e ESP, o primeiro EBP – base pointer é utilizado para indicar a base
de uma pilha. Já o segundo, o registrador ESP – stack pointer é utilizado para indicar o
topo de uma pilha. 
Uma pilha pode conter além do endereço de retorno, algumas variáveis, parâmetros e
outros dados para controle da pilha, como os registradores acima citados. 
A pilha é o enfraquecedor de toda essa estrutura uma vez que é possível alterar o valor do
endereço de retorno do programa e redirecioná-lo para um código malicioso. Assim, os
ponteiros de instruções como do processo ESP, que é o registrador que guarda o topo da
lista, passam a ser controlados pelo atacante que pode fazer chamadas a funções
disponíveis no sistema. 
Devido ao fato da alteração do endereço de retorno poder ser feita pelo “estouro” de uma
variável local alocada na pilha é que originou o nome buffer overflow.
29
- Shellcode:
Shellcode é um conjunto pequeno de instruções em assembly gerados a partir de um
programa que foi codificado e compilado especificamente para a plataforma alvo,
objetivando explorar uma vulnerabilidade e executar comandos arbitrários. Geralmente é
comum ter como resultado a chamada de um interpretador de comandos ("shell") por isso o
nome é "shellcode". 
Shellcode em nível de kernel significa código de máquina. Por exemplo, nas janelas a
instrução de conjunto do “eax” que é responsável em armazenar o valor de retorno de
uma pilha, é transformada em 0x50. A instrução “nop” (no operation) que não faz
nenhum tipo de alteração nos dados é transformada em 0x90. Essas alterações são os
chamados opcodes (operation codes) correspondentes, ou seja, ao debugar um programa
é possível verificar que as instruções equivalentes em código de máquina, possuem o
seguinte formato 0xYY, onde Y é um caractere hexadecimal. Ao explorar uma
vulnerabilidade o atacante controla o programa alvo para executar seu shellcode. 
Shellcodes são muito usados nos exploits (programas customizados para exploração
de uma vulnerabilidade) como parte dos mesmos, camuflando” as instruções arbitrárias,
ou seja, são os códigos maliciosos que através de código de baixo nível realizam chamadas
à funções do sistema a fim de se modificar por exemplo o status de um usuário, fazer
chamadas de um novo interpretador de comandos (shell).
- Exploit
O termo exploit, que em português significa literalmente, explorar. No mundo virtual é usado
comumente para referir-se a pequenos códigos de programas desenvolvidos especialmente
para explorarem falhas introduzidas em aplicativos por erros involuntários de programação. 
Podem ser preparados para atacar um sistema local ou remotamente, variam muito
quanto à sua forma e poder de ataque. Pelo fato de serem peças de código
especialmente preparadas para explorarem falhas muito específicas, geralmente há um
30
diferente exploit para cada tipo de aplicativo alvo, para cada tipo de falha ou para cada tipo de
sistema operacional.
Exploits que trabalham tentando fazer uma exploração de estouro de pilha, geralmente,
obtém dois resultados, ou o travamento da máquina, ou a escalada de privilégios, caso
o exploit tenha sido devidamente codificado e o código malicioso injetado e executado
através do mesmo. 
- Tipos de ataque 
Os tipos de ataque baseados em estouro de pilha acontecem quando, o atacante através de um
exploit, estoura a capacidade de algum buffer e modifica o fluxo de execução do processo,
possibilitando a execução de códigos arbitrários previamente injetados em alguma
região, geralmente no próprio buffer estourado. 
O princípio é estourar o buffer e sobrescrever parte da pilha, alterar o valor das variáveis
locais, valores dos parâmetros e/ou endereço de retorno da pilha. Alterando o endereço de
retorno para que ele aponte para a área em que o código a ser executado encontra-se
armazenado (código malicioso dentro do próprio buffer estourado ou até algum trecho de
código presente no programa vulnerável).
- Stack Overflow
Um processadoré constituído por alguns registradores que servem para inserir e retirar
pequenos dados que ficam armazenados para possíveis operações. Porém existe uma
grande limitação sobre esses registradores no que refere-se à capacidade disponível de
memória (somente alguns bits). Para aumentar essa capacidade existe a pilha que é uma
região da memória que foi reservada para armazenar alguns dados do processamento de um
programa. 
O exemplo mais comum de buffer overflow é o stack overflow. O termo stack
overflow vem do inglês stack que seria a pilha e overflow que é o ato de exceder a
capacidade da pilha. 
31
O código abaixo apresenta um exemplo de código vulnerável a stack overflow: 
void ProcessaParam (char *arg); 
void main (int argc, char *argv[]){ 
 if (arg > 1){ 
 printf("Param: %s\n", argv[1]); 
 ProcessaParam(argv[1]); 
 } 
} 
void ProcessaParam (char *arg){ 
 char buffer[10]; 
 strcpy(buffer, arg); /* PROBLEMA: se a string contida em arg tiver mais que 10 caracteres
havera um "buffer overflow" */ 
 printf(buffer); 
} 
No Código acima, é possível observar que o método ProcessaParam faz uma chamada
a função strcpy, que possui um elevado risco quando utilizada, podendo causar uma
fragilidade quanto à estouro de pilha. Portanto, caso a string seja maior que 10
caracteres, que é o tamanho máximo do vetor buffer, a variável “arg” permitirá um
ataque baseado em estouro de pilha. 
REFERÊNCIAS BIBLIOGRÁFICAS
[1] BEAL, Adriana. Segurança da Informação: princípios e melhores práticas para a proteção
dos ativos de informação nas organizações – São Paulo: Atlas, 
2005.
[2] BSI BRASIL. ISO/IEC 27001 Segurança da Informação. Disponível em:
<http://www.bsibrasil.com.br/certificacao/sistemas_gestao/normas/iso_iec27001/>. Acesso 
em: 12 fev. 2013.
[3] HOLANDA, Roosevelt de. O estado da arte em sistemas de gestão da segurança da
Informação: Norma ISO/IEC 27001:2005 – São Paulo: Módulo Security Magazine, 
19 jan 2006. Disponível em <http://www.modulo.com.br>. Acesso em: 12 fev. 2013.
32
[4] ISO 17799. ABNT NBR ISO/IEC 17799:2005 – Tecnologia da Informação – Técnicas de
segurança. Código de prática para a gestão da segurança da informação. 
Associação Brasileira de Normas Técnicas – Rio de Janeiro: ABNT, 2005.
[5] LYRA, Maurício Rocha. Segurança e auditoria em sistemas de informação. Rio de
Janeiro: Ciência Moderna, 2008. 253 p.
[6] OLIVA, Rodrigo Polydoro; OLIVEIRA, Mírian. Elaboração, Implantação e Manutenção
de Política de Segurança por Empresas no Rio Grande do Sul em relação às 
recomendações da NBR/ISO17799 – ENANPAD. 2003.
[7] PARRA, Gislaine. Metodologia para análise de segurança aplicada em uma infraestrutura
de chave pública. 2002. 99f. Dissertação (Mestrado em Ciência da 
Computação) – Programa de Pós-Graduação em Ciência da Computação da Universidade
Federal de Santa Catarina, Florianópolis.
[8] SÊMOLA, Marcos. Gestão da Segurança da Informação: uma visão executiva – Rio de
Janeiro: Campus, 2003.
[9] THE ISO 27000 DIRECTORY. An Introduction to ISO 27001, ISO 27002….ISO 27008.
Disponível em <http://www.27000.org/index.htm>. Acesso em: 12 fev. 2013.
33
	SUMÁRIO
	A IMPORTÂNCIA DO SOFTWARE SEGURO