PráticasTítulo

Inserir de Aqui
Inserir Título Aqui
Desenvolvimento
Seguro em Sistemas
Práticas de Desenvolvimento Seguro em Sistemas

Responsável pelo Conteúdo:

Prof. Esp. Allan Piter Pressi

Revisão Textual:
Prof. Ms. Claudio Pereira do Nascimento
 Práticas de Desenvolvimento Seguro em Sistemas

Nesta unidade, trabalharemos os seguintes tópicos:

• Contextualização
• Princípios Básicos de Segurança
da Informação
• Gestão de Risco

Fonte: iStock/Getty Images

• Políticas de Segurança e Compliance
• Metodologia de Desenvolvimento Software
• Requisitos de Software Seguro
• Criando o Software Seguro
• Conclusão

Objetivos
• Introdução aos conceitos de desenvolvimento seguro, gestão de risco em segurança de
software, políticas e regulamentações, compreender os requisitos de um software segu-
ro e algumas considerações sobre como desenhar/pensar uma aplicação segura.

Caro Aluno(a)!

Olá, seja bem-vindo, ao falarmos sobre desenvolvimento de software seguro falamos

também sobre segurança da informação. Conhecer os princípios da segurança da
informação é inerente ao processo de desenvolvimento de software seguro.

Nesta aula vamos compreender os princípios básicos de segurança da informação,

explicar sobre os modelos de segurança, suas ameaças, conhecer o modelo de gestão
de risco em desenvolvimento de software, modelos de governança, risco e compliance.

Vamos conhecer as normas existentes e como desenvolver políticas de segurança para

desenvolvimento seguro.

Bons Estudos!
UNIDADE
Práticas de Desenvolvimento Seguro em Sistemas

Contextualização
Projetos de Softwares, envolvem diversas vertentes e técnicas de desenvolvimento, a
questão que deve ser questionada é: “Sabemos desenvolver um software seguro e livre
de falhas?”.

Responder a essa pergunta é um tanto quanto complexa, pois as equipes de software

altamente capacitadas precisam ter noção do que é um software e sobre os princípios
da segurança da informação.

Garantir que um software esteja livre de erros e falhas, só é possível se as técnicas e

conceitos de segurança estiverem intrinsecamente embutida nos códigos.

Entender os conceitos de confidencialidade, integridade, disponibilidade e não repú-

dio permitem aos times de desenvolvimento de software implementar técnicas sofistica-
das de segurança.

6
Princípios Básicos de
Segurança da Informação
O desenvolvimento de um software seguro está fortemente acoplado ao domínio da
segurança da informação.

A equipe de desenvolvimento deve possuir um conhecimento razoável dos

princípios da segurança da informação, compreender e entender esses princípios se
torna fundamental no desenvolvimento de qualquer produto de software.

Básico sobre Segurança

A segurança pode ser definida por diferentes caminhos, dependendo da visão
específica por onde se olha. A origem da informação e o desenvolvimento de software
possuem em comum, atributos específicos aos negócios e também elementos e ações
associadas com segurança da informação, tais como: confidencialidade, integridade,
disponibilidade, como também um segundo conjunto de elementos: autenticação,
autorização, auditoria e por último não repúdio, pois possuem uma completa descrição
das atividades e ações associadas ao desenvolvimento do software seguro.

A seguir vamos apresentar essas terminologias básicas:

Confidencialidade
Confidencialidade é o conceito de prevenir a descoberta de informação por
qualquer parte não autorizada, ou seja, manter a informação protegida contra acesso
não autorizado.

Integridade
Integridade é similar à confidencialidade, exceto no conceito de acesso, mas se
refere à proteção dos dados contra alterações não autorizadas.

Disponibilidade
Disponibilidade se refere ao acesso ao ambiente sistêmico e que este esteja disponí-
vel sempre que solicitado, pode estar associada à criticidade de um determinado ativo
à corporação.

Autenticação
Autenticação é o processo que determina a identidade de um usuário.

7
7
UNIDADE
Práticas de Desenvolvimento Seguro em Sistemas

Autorização
A autorização é o processo seguinte a identificação do usuário, porém na autorização
estamos nos referindo aos níveis de acesso e permissões que o usuário pode ter dentro
de um determinado software.

Auditoria
A auditoria é uma forma de medir as atividades em um sistema de TI, dentro deste
conceito é essencial o uso de logs, sejam de acesso, registros e ações dentro do software.

Não Repúdio
Garante a identidade de alguém e também é uma informação de forma a prevenir
que alguém negue que uma ação seja realizada em algum objeto dentro do sistema.

Princípios de Sistemas
A criação de um sistema envolve o uso de diversos elementos e componentes,
bem como o uso de técnicas, processos e conhecimento inerente ao objeto em
desenvolvimento, a seguir vamos conhecer alguns desses elementos.

Gerenciamento de Sessões
Software frequentemente requer comunicação entre programas, recursos, banco
de dados, usuários, etc. O controle dessa comunicação é de fundamental importância
para um bom projeto de segurança.

Gerenciamento de Exceções
Software por vezes ao longo do seu uso pode encontrar condições desconhecidas e
não previstas pelos desenvolvedores que podem resultar em erros ou expor o ambiente
as ameaças aos pilares da segurança da informação, diante disso as exceções devem
possuir tratamento adequado no ciclo de desenvolvimento.

Gerenciamento de Configurações
Um software para que seja considerado confiável é necessário um requisito de que
ele possua funcionalidades de gerenciamento de configurações, alguns componentes
como strings de conexão ao banco de dados, fatores de autenticação, acesso a
determinados programas e/ou recursos devem ser geridos através de interfaces de
configuração e compor uma parte do projeto e dos requisitos do produto.

Desenhando o Software Seguro

Projetos de softwares seguros não acontecem por acaso ou por sorte. Eles são um
produto composto por arquitetura, planos, documentação, testes e estão sobre uma
estrutura desenhada com princípios de segurança.

8
 Ao pensar o projeto de software seguro devem ser levados em consideração os
itens a seguir:

Software Suficientemente Seguro

Segurança nunca é absoluta e não existe qualquer coisa absolutamente ou
completamente segura, porém é importante que a segurança esteja associada a alguns
aspectos e requisitos confiáveis de operação, cada software possui níveis apropriados
de requisitos de segurança e definições claras sobre esses componentes.

Princípio do Mínimo privilégio

Uma abordagem muito utilizada em segurança é o princípio do mínimo privilégio
que significa que somente os privilégios e direito necessários associado à execução de
certas atividades de determinado usuário serão permitidas e que outras funções e/ou
acessos não serão permitidos.

Segregação de funções
Outra abordagem fundamental no desenho do projeto é o uso de segregação de
funções; ela garante que determinada atividade e tarefa será adequadamente atribuída
somente aos envolvidos no projeto. O caminho crítico que permite que falhas sejam
introduzidas em software é a divisão de uma mesma tarefa por diversas áreas e/ou
pessoas diferentes.

Defesa em profundidade
Defesa em profundidade é um dos mais antigos princípios de segurança da
informação, se uma defesa é boa, sobreposições de defesas são melhores ainda.
Vamos imaginar um castelo, ele possui um fosso bem profundo, paredes grossas, um
ponto de acesso, diversos pontos altos de defesa.

Em segurança defesa em profundidade também pode ser definida como segurança

ou defesa em camadas e diversidade de componentes de segurança. Softwares devem
utilizar o mesmo tipo de arquitetura de camadas de segurança.

Dentro desse aspecto podemos definir segurança de software em camadas com os

seguintes elementos: Auditoria de Logs, Controle de Acesso, Sistemas de detecção de
intrusos e Prevenção.

Seguro contra falhas

O desenho ou conceito de seguro contra falhas é aquele princípio em que caso
alguma falha ocorra, o sistema possa ter mecanismos de autoproteção e preservação,
de forma a não ferir os conceitos e princípios da segurança da informação. Uma
maneira de implementar isso é através do conceito de negar explicitamente qualquer
função quando não está especificamente permitida e/ou autorizada a ser acessível por
qualquer parte fora de um determinado contexto.

9
9
UNIDADE
Práticas de Desenvolvimento Seguro em Sistemas

Mecanismos de economia
Dada à complexidade dos elementos que envolvem a segurança da informação
e as diferentes tecnologias existentes, devemos compreender que um software que
contenha 6000 linhas de códigos possui menos vulnerabilidades que um software que
contenham milhões de linhas de códigos, porém se um software que possuí menos
linhas de códigos utilizar diversas tecnologias distintas, pode ser possível que o mesmo
contenha mais vulnerabilidades do que o outro produto.

Para pensar de forma adequada, devemos observar os componentes que estamos

utilizando, incluindo também onde o software está instalado. Instalações padrões de
produtos não é a melhor estratégia, devemos sempre observar o princípio de uma
instalação enxuta do software, deixando apenas e somente os componentes necessários
ao funcionamento do software.

Este ponto se aplica não somente ao sistema operacional, como também aos
diversos protocolos de comunicação envolvidos no uso do software.

Gestão de credenciais
A gestão de credenciais refere-se à função de que a cada solicitação de acesso a
determinado objeto verifique se o solicitante possuí autorização para utilizar o objeto
em questão.

Desenho aberto de segurança

Outro conceito em segurança é a ideia de segurança por obscuridade. Essa
abordagem não é a mais adequada ou efetiva em tempos de novas ameaças, por
exemplo, é instalada uma câmera de segurança, porém, ela não funciona. Segurança
por obscuridade pode eventualmente oferecer um pouco de complexidade para um
atacante, no entanto, não é um modelo adequado em segurança de código.

O conceito “desenho aberto de segurança” é que a segurança deve ser desenhada de

forma independente do fornecedor, dessa maneira a empresa não se torna dependente
de um único fornecedor.

Compartilhamento de Informação
Métodos de prevenção são necessários para evitar o compartilhamento acidental
de informações importantes, muitas vezes em projetos de softwares temos acesso a
uma gama de informações confidenciais e as estas devem ser adequadamente tratadas.

Comportamento de Usuários
Os usuários são uma parte importante de um sistema de segurança, dentro de um
projeto de software muitas vezes devemos permitir a participação dos usuários durante
o desenvolvimento, caso contrário estes mesmos usuários podem ser um fator de
resistência ou de sabotagem a qualquer novo produto.

10
 Porém, convém observar os requisitos e funcionalidades de um produto. Devem
prevenir o comportamento dos usuários, por exemplo, se o software permite que
alguém possa anexar documentos e não exista um tratamento adequado a informação
deste arquivo, este usuário poderia encaminhar de forma acidental ou intencional
documentos restritos e comprometer a confidencialidade.

Elo mais fraco

A segurança de um software sempre estará associada ao seu elo mais fraco, e nesse
ponto ela deve ser considerada em todas as etapas de um projeto de software, desde
o desenho e desenvolvimento à implantação do produto. Uma avaliação de riscos é
necessária em cada etapa do projeto.

Reuso de código
O reuso de código é uma vantagem competitiva por diminuir o desenvolvimento
de códigos extras e permitindo o aumento da produtividade do desenvolvimento do
software, diante disso, a eficiência na segurança deve ser no sentido de que um código
só pode ser utilizado se alguma avaliação de segurança foi realizada e as falhas ou
erros foram devidamente corrigidas.

Ponto único de falha

O ponto único de falha é uma maneira inteligente de pensar segurança, quando
utilizamos a proteção em múltiplas camadas, devemos ter em mente, que independente
do nível de proteção, que em caso de alguma falha ocorrer todo o sistema torna-se
indisponível ao utilizador.

Podemos tomar como exemplo um servidor de internet, se este for o único ponto
de acesso ao sistema, esse será o único ponto de falha, independente das inúmeras
camadas de segurança.

Modelos de Segurança
Modelos de segurança são utilizados para compreender e entender os processos
envolvidos durante o desenvolvimento do software em que são aplicados os princípios
da segurança da informação.
Um bom modelo de implementação de segurança sempre deve observar cinco
pontos chaves em qualquer processo sistêmico: Pessoas, Processos, Regras, Requisitos
e Tecnologia.

Modelos de controle de acesso

Controle de acesso é usado para descrever o mecanismo que garante a proteção de
acesso ao ambiente, seu uso serve para descrever as definições de controle de acesso
dos usuários, e um mecanismo comum de uso é a utilização de ACLs (Access Control
List). Uma ACL contém os elementos e as permissões de acessos definidas e que
podem ser aplicadas aos usuários.

11
11
UNIDADE
Práticas de Desenvolvimento Seguro em Sistemas

Tipicamente as permissões de acesso englobam: leitura, escrita e execução, na

literatura específica outros modelos são apresentados, como DAC (Discretionary
Access Control), MAC (Mandatory Access Control), RBAC (Role-base Access
Control) e RBAC (Rule-base Access Control).

Conhecer esses métodos de controle ajudam os desenvolvedores a entender as

melhorias que podem implementar de acordo com o projeto de software.

Outros métodos existentes são: Bell-LaPadula, Teoria dos Grafos, Matriz de controle
de acesso, multi-nível de acessos, etc.

Modelos de Integridade
A integridade visa garantir a separação de permissões para uso adequado do
software, fazendo a separação no uso de regras em transações e desta maneira fazendo
com que o software tenha comportamento adequado aos usuários.

Transporte da Informação
Os modelos de segurança devem observar questões sobre caminho por onde uma
determinada informação transaciona ou quando uma informação está em trânsito,
por exemplo, informações que são transportadas em notebooks da equipe de vendas,
contendo uma cópia totalmente funcional do software.

O projeto do software deve observar essas questões ao considerar mecanismo de

proteção no trânsito da informação desde a sua entrada de dados até sua efetiva
gravação em disco, por exemplo.

Em um projeto de software os diagramas de fluxo de dados podem ser relevantes

para compreender os mecanismos de proteção adequados em qualquer projeto.

Ameaças à segurança
A segurança é a proteção dos ativos de informação contra ameaças internas ou
externas, as ameaças são as mais variadas possíveis, mas elas podem ser de diferentes
tipos. A seguir vamos apresentar algumas delas.

Script Kiddie
O termo script kiddie é usado basicamente para definir um tipo de atacante, é
um termo comum utilizado na indústria para descrever um usuário que publica ou
utiliza scripts para realizar ataques. Eles compreendem entre 80% a 85% das ameaças
oriundas de pessoas. A boa notícia é que esse público normalmente busca as falhas
mais comuns dos sistemas e que de certa forma já são tratadas dentro das tecnologias
existentes, mas mesmo assim ainda são consideradas ameaças em potencial.

12
 Hacker
É termo comumente utilizado para definir alguém que explora os limites de um de-
terminado sistema. O termo cracker se refere a um individuo com intenções maliciosas.

Elite
Termo utilizado para definir pessoas com alto grau de conhecimento e grandes
habilidades, normalmente de 1% a 5% da comunidade. Esse pequeno grupo pode de
fato explorar as falhas de softwares com o uso de ferramentas e conhecimento e com
possibilidade de causar grandes estragos.

Grupos de Hackers
Grupos Hacker podem agir em conjunto com relação a determinados alvos, causas
ou desafios em geral, representam uma ameaça às grandes empresas de forma geral.

Ameaças Não Estruturadas e Estruturadas

Ameaças não estruturadas são aquelas associadas com pouco ou nenhum recurso,
normalmente indivíduos ou pequenos grupos com conhecimento limitados, em sua
maioria scripts kiddies.

Ameaças estruturadas são aquelas organizadas por grupos com habilidades sofisti-
cadas e complementares que visam obter sucesso na ação, podem envolver não apenas
habilidades tecnológicas, como também habilidades comportamentais. Em ambos os
casos podem estar associadas a organizações criminosas com propósitos específicos.

Ameaças Avançadas Persistentes (APT)

As APT são uma composição de múltiplas técnicas de ataques, desenhadas para
penetrar em uma rede protegida e realizar qualquer atividade de forma indetectável as
ferramentas de detecção.

O objetivo de um APT é um ataque específico, porém pode eventualmente ser

utilizado em grande escala para se obter uma quantidade de informação específica.

13
13
UNIDADE
Práticas de Desenvolvimento Seguro em Sistemas

Gestão de Risco
Gestão de Risco é um elemento importante em processos de decisão e é definido
como um processo de identificação, controle, eliminação ou mitigação sobre eventos
incertos e que podem comprometer ou afetar recursos existentes.

Definições e Terminologias
Termos Gerais
Tabela 1

Risco - É a probabilidade de sofrer um dano ou perda.
Risco Total - É soma de todos os riscos associados com um
ativo, processo ou eventualmente ao negócio.
Avaliação de Risco - É o processo de analisar o ambiente para Ativo - É qualquer recurso ou informação que a organização precisa
identificar os riscos e mitigar ações para determinar o impacto para conduzir seus negócios.
que possa causar ao processo.
Vulnerabilidade - É uma ameaça que explora
um vulnerabilidade.
Impacto - É a perda resultante da exploração
da vulnerabilidade.
Mitigação - É a ação que elimina ou reduz a probabilidade da
ocorrência de uma ameaça.
Análise de risco qualitativa - É análise de risco com base
nos sentimentos das pessoas e se determinada ameaça pode
se materializar.
Expectativa de Perda Única (SLE) - É a perda ou impacto
monetário de cada ocorrência ou evento de uma ameaça.
Frequência - A quantidade de vezes que determinado evento
ocorre durante um ano.
Risco Residual - É o risco remanescente após a eliminação ou
mitigação dos riscos.
Gestão de Risco - É o processo de decisão acerca dos riscos e
ameaças identificadas.
Ataque - É a ação de explorar uma Vulnerabilidade.
Ameaça - É uma circunstância ou evento com o potencial de causar
perda ou dano para um ativo.
Controle - É uma medida para detectar, prevenir ou mitigar um
risco associado a uma ameaça.
Análise de risco quantitativa - É análise de risco com foco na
perda financeira que uma ameaça pode de fato causar.
Fator de Exposição - é a medida ou magnitude de perda
de um ativo.
Expectativa de Perda - é a expectativa de perda anualizada
sobre um evento esperado.

14
 Processo de Gestão de Riscos
O processo de gestão de risco em segurança da informação conforme a ISO 27.005
é representado pela figura abaixo:

Figura 1

Definição do Contexto
A definição de contexto envolve:
• definição de critérios básicos;
• definição do escopo e dos limites, o estabelecimento de uma organização apropriada
para trabalhar a gestão de riscos.

Análise e Avaliação de Riscos

Os riscos devem ser identificados, quantificados ou qualificados e priorizados em
função da avaliação de riscos e dos objetivos da organização.

A avaliação de riscos deve considerar os seguintes itens:

Análise Identificação Tratamento

Figura 2

15
15
UNIDADE
Práticas de Desenvolvimento Seguro em Sistemas

Tratamento dos Riscos

Os riscos identificados devem ser tratados através de algumas opções:

Opções de Tratamento

Reduzir Reter Evitar Transferir

Riscos Residuais
Figura 3

Tratamento dos Riscos

O risco residual representa o nível de risco remanescente após o tratamento de riscos,
esses riscos precisam ser estimados.

Legenda Legenda
5 B A A A A A - Ação imediata - Intolerável
4 B B A A A B - Ação média e curto prazo
Probabilidade

3 C B B A A C - Monitoramento e gestão
2 C C B B A D - Risco controlável
1 D C C B B
1 2 3 4 5
Impacto
Figura 4

Aceitação dos Riscos

A decisão de aceitar os riscos compete à empresa e seu apetite por isso, tomada
formalmente juntamente com a responsabilidade pela decisão. A política de gestão de
riscos (item critérios para a aceitação do risco) oferece suporte a essa tomada de decisão.

Comunicação dos Riscos

As informações sobre riscos devem ser compartilhadas e conhecidas entre as outras
partes interessadas, com o objetivo de atingir um consenso sobre como administrar os riscos.

Monitorando dos Riscos

Os riscos e a suas consequências devem ser monitoradas e analisadas criticamente a
todo o momento, a fim de se identificar eventuais mudanças e tratá-las adequadamente.

16
Políticas de Segurança e Compliance
Regulamentos e conformidade muitas vezes são atividades dentro de uma empresa. A
razão primária por trás desta atividade está no simples fato de que uma falha no cumpri-
mento de regras e/ou regulamentações podem trazer perdas financeiras as corporações.

Convém observar que quando falamos de compliance não é o mesmo que segurança.
Em certo sentido um software pode estar em compliance e ainda assim estar inseguro.

Com base no segmento em que uma empresa esteja inserida, ela pode ter que
observar diferentes regulamentos e/ou legislações para atender aos seus clientes, isso
pode fazer com que o software em desenvolvimento possa ser afetado no atendimento
a certos requisitos desses regulamentos ou leis.

A seguir vamos conhecer algumas dessas normas existentes e seus objetivos específicos:

FISMA
A Federal Information Security Management Act (Lei Federal de Gestão de Seguran-
ça da Informação), é uma lei federal dos Estados Unidos, que reconheceu a importância
da segurança da informação aos interesses de segurança econômica e nacional dos
Estados Unidos.

Ela exige que cada agência federal deve desenvolver, documentar e implementar um
programa de segurança que suporte as operações e ativos da agência, incluindo os for-
necidos ou geridos por outras agências, terceiros, etc.

Sarbanes-Oxley
A Lei Sarbanes-Oxley (em inglês, Sarbanes-Oxley Act) é uma lei americana, assinada
pelo senador Paul Sarbanes e pelo deputado Michael Oxley. Motivada por escândalos
financeiros corporativos, essa lei foi redigida com o objetivo de evitar o esvaziamento
dos investimentos financeiros e a fuga dos investidores causada pela insegurança da
governança corporativa e visa garantir a criação de mecanismos de auditoria e segurança
confiáveis nas empresas.

Gramm-Leach-Bliley
Uma lei americana que contém dispositivos que exigem que todas as instituições
financeiras divulguem aos consumidores e clientes suas políticas e práticas para proteger
a privacidade das informações pessoais não-públicas.

Informações pessoais não públicas incluem quaisquer tipos de informações fornecidas

por um cliente, resultado de transações com a instituição financeira ou obtidas por uma
instituição financeira através do fornecimento de produtos ou serviços.

17
17
UNIDADE
Práticas de Desenvolvimento Seguro em Sistemas

HIPAA e HITECH
Health Insurance Portability and Accountability Act (HIPAA) é uma lei americana
que estabelece os requisitos para uso, divulgação e proteção de informações de saúde.
Ela se aplica a consultórios médicos, hospitais, seguradoras de saúde e outras empresas
de saúde.

O escopo da HIPAA foi ampliado com a aprovação do HITECH (Health Informa-

tion Technology for Economic and Clinical Health). Juntas, as regras da HIPAA e HI-
TECH permitem aos pacientes controlar o uso de suas informações pessoais e abrange
a confidencialidade e restrição do uso e da divulgação desses.

PCI DSS
O Payment Card Industry Security Standards Council (PCI-SSC) define o PCI
Data Secutity Standart (PCI-DSS) que especifica recomendações mínimas de segurança
obrigatórias para todas as empresas que participam da rede de captura de pagamento
com cartões, o comércio, e prestadores de serviços que processam, armazenam e/ou
transmitem eletronicamente dados do portador do cartão de crédito.

ISO/IEC 15408
Na década de 80 surgiu o primeiro padrão para avaliação de segurança em softwa-
res que ficou conhecido como Orange Book. Mais tarde esse padrão foi homologado
pela International Standartization Organization (ISO) como ISO/IEC 15408, também
conhecida como Common Criteria (CC). Ela determina que um sistema deva ter seu
objetivo de segurança definido para ser considerado seguro.

Outras regulamentações
Existem outras leis e regulamentações que podem ser aplicáveis ao conceito de sof-
tware seguro entre estas, podem ser considerados questões sobre propriedade inte-
lectual, direitos autorais, patentes, marcas registradas, acordos de confidencialidade,
garantias e políticas de privacidade.

18
Metodologia de Desenvolvimento Software
O termo “Ciclo de vida de desenvolvimento seguro”, adiciona segurança ao processo
de desenvolvimento de software, reduzindo o número de problemas de segurança duran-
te o desenvolvimento do produto.

A qualidade de um software é diferente da segurança do software, a indústria caracte-

riza qualidade como ausência de defeitos, mas isso é diferente de segurança do software.

O ciclo de desenvolvimento de software seguro deve considerar os seguintes pontos:

Time de Desenvolvimento Qualificado

Os times devem ser preparados, treinados e educados em desenvolvimento seguro.
A política de treinamento continuo em segurança no desenvolvimento deve ser uma
constante nas equipes.

Requisitos de Segurança
Todos os softwares por definição devem possuir requisitos mínimos de segurança
conforme abordado anteriormente, isso garante que o software já seja entregue com
esses princípios.

Rastreabilidade de Defeitos
Rastreabilidade de defeitos é um dos pontos importantes de qualquer equipe de de-
senvolvimento de software, possuir mecanismos ou ferramentas que permitem controlar
e gerenciar os defeitos que vão surgindo, permitindo a melhoria continua dos processos
de desenvolvimentos.

Modelagem de Ameaças
A modelagem de ameaças é uma técnica utilizada para comunicar e gerir as ameaças
que podem afetar o desenvolvimento e/ou funcionamento do software.

Fuzzing
Fuzzing é uma técnica de teste em que são realizados testes de massas de dados nas
entradas de dados e avaliação do comportamento e os resultados esperados, permitindo
que se possam testar o comprometimento de um sistema, incluindo técnicas utilizadas
por atacantes.

19
19
UNIDADE
Práticas de Desenvolvimento Seguro em Sistemas

Revisões de Segurança
Revisões de segurança devem compor a todo o momento o processo de desenvolvi-
mento dado que as ameaças são variadas e novas ameaças surgem a todo o momento,
o que se faz necessário essas revisões de forma contínua.

Modelos de Desenvolvimento Seguro

Existem uma série de metodologias no desenvolvimento de software, porém dentre as
mais utilizadas estão o desenvolvimento estruturado, espiral, prototipagem e modelos ágeis.

Requisitos de Software Seguro

Os requisitos de software seguro envolvem questões acerca de regras e políticas para
um melhor ambiente de desenvolvimento de software, esses requisitos muitas vezes são
demandas e solicitadas por fatores internos e externos.

Os requisitos internos compreendem a proteção de logs, gerenciamento de perdas

de pacotes, transações, monitoramento do tráfego de dados de entrada e saída e con-
troles internos.

Os requisitos externos passam pelo gerenciamento das conexões aos controles de

segurança como também a gestão das ameaças baseadas em vulnerabilidades de aplica-
ções de internet.

Os requisitos de um software seguro também procuram observar a classificação e a

categorização dos dados, que corresponde a gerenciar os estados da informação (cria-
ção, uso, atualização, exclusão e acesso) e o risco de impacto de um determinado dado
e a propriedade do dado.

Os requisitos também devem tratar a custodia da informação, toda a informação deve

ser classificada de acordo com sua sensibilidade e impacto.

Em relação aos tipos de dados, estes podem ser estruturados (ex. Arquivos do tipo
XML) e não estruturados (ex. apresentação em power point).

Um dos requisitos são os padrões de codificação segura, esse requisito envolve ques-
tões além da codificação em si e passam por pontos como separação dos ambientes de
desenvolvimento, homologação e produção.

20
Criando o Software Seguro
A implementação dos requisitos de segurança começa com a fase do desenho do
produto, isto permite desde a concepção do produto criar um produto seguro.

Todo o desenho de software seguro deve avaliar a superfície de exposição ao ataque

que passa por diversos componentes entre eles: abertura de portas, serviços, ambiente
e infraestrutura onde a aplicação será instalada, sempre procurando observar as boas
práticas de segurança.

Outro aspecto já discutido é que o projeto deve contemplar a modelagem de amea-

ças, identificar essas ameaças e implementar controles adequados e priorizá-los. Uma
boa modelagem de ameaças contempla a definição dos objetivos de segurança, enume-
ração de ameaças, análise, mitigação e validação dentro do modelo.

Realizar a avaliação de riscos quando se utiliza do conceito reuso de códigos, outro

ponto se refere à documentação, é uma das premissas de qualquer desenvolvimento de
software e que a documentação deve compor com o desenho da arquitetura e possuir as
informações que possibilitem a identificação de ameaças, falhas e/ou vulnerabilidade e
corrigi-las a medida em que elas são identificadas.

Conclusão
Nesta aula foram apresentados os conceitos básicos de segurança da informação e a
importância delas nos processos de desenvolvimento de softwares.

Compreendemos os métodos de avaliação de riscos e como tratá-los, as normas de

segurança existentes e como estas podem influir no desenvolvimento de produtos de
software de acordo com a indústria em que determinada empresa esteja inserida.

E terminamos com os tópicos referentes ao desenvolvimento seguro que seu início

acontece no desenho ou no início do projeto, passando por aspectos de controles e
pontos importantes que devem ser considerados durante o desenvolvimento do produto.

21
21
UNIDADE
Práticas de Desenvolvimento Seguro em Sistemas

Material Complementar
Indicações para saber mais sobre os assuntos abordados nesta Unidade:

Sites
O Ciclo de Vida do Desenvolvimento da Segurança de Computação Confiável
https://goo.gl/FM3ehT

Vídeos
Palestra Técnica do CISL: Segurança e Software Livre
https://youtu.be/ZoR621GmOII
Desenvolvimento do Software Seguro
https://goo.gl/EusUKE

Leitura
Gestão de Riscos Aplicada a Sistema de Informação: Segurança Estratégica da Informação
https://goo.gl/s77Ofe

22
Referências
HOGLUND, Greg; McGraw, Gary. Como Quebrar Códigos: a arte de explorar (e pro-
teger) software. Pearson 448 ISBN 9788534615464. (Livro Eletrônico).

STALLINGS, William. Criptografia e Segurança de Redes: princípios e práticas - 4ª

edição. Pearson 512 ISBN 9788576051190.(Livro Eletrônico).

SHEMA, Mike. Hack notes: segurança na web referência rápida / 2003 - (Livro) refe-
rência rápida. São Paulo: Campus, 2003. 182 p. ISBN 8535213503i

Sites Visitados
Secure Coding Practice Guidelines. Disponível em: <https://security.berkeley.edu/
secure-coding-practice-guidelines>

Homeland Security Secure Coding Site. Disponível em: <https://www.us-cert.gov/bsi>

23
23