Engenharia de Software II - AULA 6

Prévia do material em texto

6ºAula
Engenharia de proteção
Olá, alunos(as). Em nossa sexta aula, abordaremos 
assuntos relacionados à engenharia de proteção. Elas 
servem para apoiar o processo de engenharia de software e 
está sujeita, portanto, a modificações e evoluções.
Nesta aula, esse será nosso campo de interesse. 
Vamos lá?
Boa aula!
Objetivos de aprendizagem
Ao término desta aula, vocês serão capazes de:
• entender os fundamentos da engenharia de proteção;
• saber gerenciar riscos de proteção.
38Engenharia de software II
1 - Fundamentos da engenharia de proteção
2 - Proteção
3 - Gerenciamento de riscos de proteção
Seções de estudo
1 - Fundamentos da engenharia de 
proteção
2 - Proteção
Quando houve a difusão da internet na década de 
1990, houve novos desafios para os engenheiros de software: 
projetar e implementar sistemas seguros. Mais e mais sistemas 
passaram a ser conectados à Internet, e, também, diversos 
ataques foram sendo inventados, ameaçando os sistemas. 
A difusão do uso da Internet na década de 1990 introduziu 
um novo desafio para os engenheiros de software: projetar e 
implementar sistemas seguros. Como mais e mais sistemas 
foram conectados à Internet, uma variedade de diferentes 
ataques externos foi inventada, e eles ameaçam esses sistemas. 
Os engenheiros de sistemas, assim, começaram a trabalhar 
voltando-se também para a questão da proteção.
Hoje, já são projetados sistemas exclusivamente para 
a defesa de ataques externos, sejam eles propositais ou não. 
É impossível evitar que os agressores s voltem para atacar 
os sistemas de rede. Entre os ataques, estão o uso errôneo 
de sistemas de redes; roubo de dados confidenciais ou 
interrupção dos serviços oferecidos pelo sistema.
A engenharia de proteção de sistema é uma área bastante 
importante e em crescimento na área de engenharia de 
sistema. Está relacionada ao desenvolvimento e à manutenção 
de sistemas que resistam aos ataques maliciosos. A conexão 
com a internet faz com que existam novas formas de ataque, 
exigindo que o campo da engenharia se mantenha em alerta 
quanto a eles. Vejamos um excerto de Sommerville (2013) 
acerca disso:
Quando você considerar questões de proteção, deve considerar o 
software de aplicação (o sistema de controle, sistema de informação 
etc.) e a infraestrutura sobre a qual esse sistema é [...]. A infraestrutura 
para aplicações complexas pode incluir:
• uma plataforma de sistema operacional, como Linux ou Windows;
• outras aplicações genéricas que são executadas no sistema, como 
browsers de Web e clientes de e-mail;
• um sistema de gerenciamento de banco de dados;
• middleware que ofereça suporte à computação distribuída e acesso 
ao banco de dados;
• bibliotecas de componentes reusáveis usados pelo software de 
aplicação.
A maioria dos ataques externos foca as infraestruturas de sistemas 
porque os componentes de infraestrutura (por exemplo, browsers de 
Web) são bem conhecidos e amplamente disponíveis. Os invasores 
podem investigar esses sistemas em busca de pontos fracos e 
compartilhar as informações sobre vulnerabilidades que descobrirem. 
Como muitas pessoas usam o mesmo software, ataques têm ampla 
aplicabilidade. Vulnerabilidades de infraestrutura podem levar 
invasores a obter acesso não autorizado a um sistema de aplicação 
e seus dados.
Na prática, há uma distinção importante entre proteção de aplicação e 
proteção de infraestrutura:
1. Proteção de aplicação é um problema de engenharia de software em 
que os engenheiros devem assegurar que o sistema é projetado para 
resistir a ataques.
2. Proteção de infraestrutura é um problema de gerenciamento em 
que os gerentes de sistema confi guram a infraestrutura para resistir a 
ataques. Gerentes de sistema precisam confi gurar a infraestrutura para 
fazer o uso mais efi caz
de quaisquer recursos de proteção da infraestrutura disponíveis. 
Eles também precisam corrigir vulnerabilidades de proteção de 
infraestrutura que vêm à luz quando o software é usado.
Gerenciamento de proteção de sistemas não é uma tarefa única; de 
fato, inclui uma gama de atividades, como gerenciamento de usuários 
e permissões, implantação e manutenção de software de sistema, 
monitoração, detecção e recuperação de ataques:
1. Gerenciamento de usuários e de permissões inclui adicionar e 
remover usuários de sistema, garantindo que mecanismos apropriados 
de autenticação de usuários estejam sendo usados e confi gurando as 
permissões no sistema para que os usuários só tenham acesso aos 
recursos de que necessitem.
2. Implantação e manutenção de sistema de software incluem 
a instalação de software de sistema e middleware e sua correta 
confi guração para que as vulnerabilidades de proteção sejam evitadas. 
Envolve também a atualização regular desse software com novas 
versões ou patches, que reparem problemas de proteção descobertos. 
(SOMMERVILLE, 2013, p. 256).
Já soubemos, até aqui, que a proteção diz respeito a um 
atributo que reflete o quanto o sistema tem a capacidade de se 
proteger de ataques externos. A título de ilustração, vamos ler 
o seguinte exemplo:
O pessoal da clínica acessa o MHC-PMS 
com um nome de usuário e senha. O sistema 
requer que as senhas contenham pelo menos 
oito letras, mas permite que qualquer senha 
seja defi nida sem verifi cações adicionais. Um 
criminoso descobre que um astro do esporte 
está recebendo tratamento para problemas 
de saúde mental. Ele gostaria de obter acesso 
ilegal às informações desse sistema para poder 
chantagear o esportista.
Fingindo ser um parente preocupado, ao 
falar com os enfermeiros na clínica de saúde 
mental ele descobre como acessar o sistema e 
as informações pessoais sobre os enfermeiros. 
Ao verifi car os crachás, ele descobre os nomes 
de algumas pessoas autorizadas a acessarem 
o sistema. Ele, então, tenta fazer logon 
no sistema usando esses nomes tentando, 
sistematicamente, adivinhar senhas possíveis 
(como nomes dos fi lhos). (SOMMERVILLE, 
2011, p. 211).
Observando o exemplo, quais tipos de medidas podem 
ser utilizadas para proteger o sistema? Segundo Sommerville 
(2011), há conceitos importantes de proteção que podem se 
39
relacionar com o caso acima. Verifiquemos:
Tabela 6.1 Conceitos de proteção
Termo Descrição
Ativo Recurso de sistema que possui 
um valor e deve ser protegido.
Exposição
Possível perda ou dano que pode 
resultar de um ataque bem-
sucedido. Pode ser uma perda 
ou dano em dados ou uma perda 
de tempo e esforço, caso seja 
necessária uma recuperação 
depois de uma brecha de 
proteção.
Vulnerabilidade
Ponto fraco em um sistema 
baseado em computadores que 
pode ser explorado para causar 
perda.
Ataque
Exploração de uma vulnerabilidade 
do sistema. Geralmente, é externo 
ao sistema e constitui uma 
tentativa deliberada de causar 
algum dano.
Ameaça
Circunstâncias com potencial 
para causar perda ou dano. Você 
pode pensar nelas como uma 
vulnerabilidade de sistema sujeita 
a ataque.
Controle
Medida de proteção que reduz 
uma vulnerabilidade de sistema. A 
criptografia pode ser um exemplo 
de controle que reduz uma 
vulnerabilidade de um sistema 
fraco em controle de acesso.
Fonte: Sommerville, 2011, p. 212.
As ameaças de proteção enquadram-se em três categorias 
principais. São elas:
• Ameaças à confidencialidade do sistema e aos dados: 
podem reveler informações a pessoas ou a programas não 
autorizados;
• Ameaças à integridade do sistema e a seus dados: podem 
danificar ou corromper o software ou seus dados;
• Ameaças à disponibilidade do sistema e a seus dados: 
podem restringir o acesso ao software ou aos dados para pessoas 
com autorização.
Apesar de particulares, as ameaças são interdependentes. 
Caso o sistema se torne indisponível devido a um ataque, 
o usuário não tem acesso a ele, logo, isso faz com que a 
integridadedo sistema fique vulnerável. Nesse caso, é preciso 
desligar o sistema para poder reparar o problema. Assim, 
a disponibilidade do sistema será reduzida, pois o sistema 
ficará fora do ar. Assim, uma ameaça acaba, muitas vezes, 
desencadeando em outras.
Se voltarmos ao exemplo utilizado no início da aula, 
podemos chegar às conclusões descritas na tabela seguinte:
Tabela 6.2. Conceito de proteção no cenário do 
estudo de caso
Termo Descrição
Ativo Os registros de cada paciente que 
está fazendo ou fez exames.
Exposição
Prejuízo financeiro potencial 
devido a futuros pacientes 
que não procurarão mais pelo 
laboratório por não confiarem 
nele para manter seus dados. 
Prejuízo financeiro devido a ação 
judicial movida pelo astro de TV. 
Perda de reputação.
Vulnerabilidade
Sistema fraco em senhas 
que permite aos usuários 
criarem senhas que podem ser 
descobertas. Identificações de 
usuários iguais a seus nomes.
Ataque A imitação de um usuário 
autorizado.
Ameaça
Um usuário não autorizado 
ganhará acesso ao sistema 
descobrindo as credenciais (nome 
de login e senha) de um usuário 
autorizado.
Controle
Um sistema de verificação de 
senhas que descubra senhas 
definidas pelos usuários que 
sejam nomes próprios e palavras 
normalmente incluídas em um 
dicionário.
Fonte: Sommerville, 2011, p. 213.
No que tange aos controles, têm sua funcionalidade 
atribuída em classes. São elas:
• Controles que se destinam a assegurar que os ataques 
sejam malsucedidos. Deve-se projetar o sistema de modo que 
os problemas de proteção sejam evitados. Por exemplo, em 
casos de sistemas militares sensíveis que não são conectados 
a uma rede pública, tornando o acesso externo é impossível. 
Deve-se pensar na criptografia com um controle baseado 
em prevenção. Qualquer acesso não autorizado aos dados 
criptografados deixa entrever que eles não poderão ser 
lidos pelo agressor. Na prática, há alto consumo de tempo e 
dinheiro quebrar uma criptografia bem protegida.
• Controles que se destinam a detectar e repelir ataques. 
Estes envolvem a inclusão de funcionalidade em um sistema 
que monitora a sua operação e verifica padrões incomuns de 
atividades. Quando são detectados, deve-se desligar uma parte 
do sistema, de modo a tentar restringir o acesso a usuários não 
permitidos.
• Controles que apoiam a recuperação de problemas. 
Podem abranger estratégias automáticas de back-up e 
“espelhamento” de informações. Envolve uma política de 
seguro para cobrir os custos associados aos ataques ao sistema.
Vimos, então, que a engenharia de proteção é uma parte 
de um processo amplo da engenharia de confiança. 
40Engenharia de software II
Retomando a aula
Chegamos ao fi nal da sexta aula. Parece que estamos 
indo bem, não é mesmo?
Espero que os conteúdos estejam fi cando claro e que 
vocês estejam assimilando bem as discussões. Compartilhem as 
impressões no quadro de avisos. Vamos recordar.
Adotar estratégias de prevenção, de detecção de 
problemas e de recuperação que ocorreram é necessário, pois 
sistemas seguros contam com uma combinação de estratégias 
para ser realmente seguros.
3 - Gerenciamento de riscos de 
proteção
Como vocês já perceberam, adotar medidas protetivas 
para o software demanda alto custo de tempo e dinheiro. 
Como tudo que envolva essas duas questões, é preciso de 
gerenciamento adequado. O gerenciamento de riscos de 
proteção, bem como a capacidade de avaliar esses riscos são 
essenciais para a engenharia de software.
Quando se gerencia riscos, consegue-se avaliar possíveis 
perdas que, talvez, resultassem em ataques ao sistema. 
As empresas de cartão de crédito, por exemplo, utiliza de 
tais recursos com frequência, pois, de modo muito rápido, 
são inventadas novas formas de fraudar os cartões. Assim, 
é necessário que as empresas de cartão lidem com tais 
modificações, e codifiquem informações em um chip no 
cartão, pois isso, devido à trilha magnética, torna o processo 
de “clonagem” de cartão de crédito mais difícil.
Gerenciar riscos é uma questão de negócio, e não de 
conhecimento técnico. Assim, os engenheiros de software não 
podem definir quais os controles serão incluídos no sistema: 
essa tarefa é da gerência sênior. O engenheiro de software tem a 
função de disponibilizar um guia com seus julgamentos sobre 
a questão da proteção.
Certamente, a avaliação de riscos começa antes de 
o sistema ter sido adquirido, e caminha junto a todo seu 
processo de desenvolvimento.
A avaliação de riscos envolve dois estágios:
A avaliação de riscos inicia-se antes de a decisão de 
adquirir o sistema ter sido feita e deve continuar durante todo 
o processo de desenvolvimento do sistema. Uma importante 
consideração é a quantidade de informação que você tem 
disponível sobre o sistema; assim, a avaliação de riscos é um 
processo por estágios:
• Avaliação de riscos preliminar: nesse estágio, decisões 
sobre os requisitos detalhados de sistema, o projeto de sistema 
ou a tecnologia de implementação ainda não foram feitas. O 
objetivo desse processo de avaliação é, inicialmente, avaliar 
se os benefícios de desenvolvimento do sistema justificam 
ou não os riscos associados e, então, derivar os requisitos 
específicos de proteção para o sistema ser implantado. Vocês 
não têm informações sobre as vulnerabilidades potenciais 
do sistema ou os controles incluídos nos componentes de 
sistema reusados ou o middleware.
• Avaliação de riscos de ciclo de vida: essa avaliação 
acontece durante o ciclo de vida de desenvolvimento de 
sistema e é informada pelas decisões técnicas de projeto e 
implementação do sistema. Ela informa o processo de 
engenharia de requisitos de proteção. As vulnerabilidades 
conhecidas e potenciais são identificadas. Na sequência, 
esse conhecimento é usado para informar a tomada de 
decisão sobre a funcionalidade de sistema e como deve ser 
implementada, testada e implantada.
1 - Fundamentos da engenharia de proteção
Vimos que, quando houve a difusão da internet na década 
de 1990, houve novos desafios para os engenheiros de software: 
projetar e implementar sistemas seguros. Mais e mais sistemas 
passaram a ser conectados à Internet, e, também, diversos 
ataques foram sendo inventados e começaram a ameaçar os 
sistemas. 
2 - Proteção
Vimos os conceitos de proteção e técnicas de manutenção 
da segurança do sistema.
3 - Gerenciamento de riscos de proteção
Notamos que, quando se gerencia riscos, consegue-se 
avaliar possíveis perdas que, talvez, resultassem em ataques 
ao sistema. As empresas de cartão de crédito, por exemplo, 
utiliza de tais recursos com frequência, pois, de modo muito 
rápido, são inventadas novas formas de fraudar os cartões. 
Assim, é necessário que as empresas de cartão lidem com 
tais modificações, e codifiquem informações em um chip no 
cartão, pois isso, devido à trilha magnética, torna o processo de 
“clonagem” de cartão de crédito mais difícil.
Vale a pena
Disponível em: <http://www.isegnet.com.br/siteedit/
arquivos/12-3-o-que-e-gerenciamento-de-riscos.pdf>.
Vale a pena acessar
Minhas anotações