Requisitos de Segurança de Software

Prévia do material em texto

Requisitos de Segurança de Software 
 
Introdução 
Para garantir o desenvolvimento de software seguro é necessário entender as 
necessidades de segurança do cliente e realizar uma avaliação das ameaças, 
dos pontos críticos, das informações importantes, das políticas e dos controles 
já existentes no ambiente. Toda análise deve ser realizada logo no início do 
projeto de desenvolvimento, mais especificamente na fase de Requisitos . É 
nesta fase que podemos obter do cliente suas necessidades em relação à 
segurança das informações que são manipuladas pelosistema. 
Segundo a norma ISO/IEC 15.408 1 , que define uma metodologia para 
avaliação da segurança de TI, essas informações podem ser obtidas por meio 
de três fontes: 
1. Política de segurança: diretrizes, normas e legislação pertinente. 
2. Objetivos de segurança: necessidades do usuário. 
3. Ameaças: formas de ataque, compostas por um agente, um mecanismo 
e um ativo. 
A primeira fonte, a Política de segurança, envolve as normas, legislações ou 
qualquer documento que imponha ao sistema determinadas características de 
segurança. Elas são expressas por meio de diretrizes que definem as 
características gerais de segurança de um sistema. 
Um exemplo de diretriz de segurança é: "Todo sistema deve garantir que os usuários 
sejam responsabilizados por suas ações." 
Estas definições se encontram em um nível mais alto, com poucos detalhes 
técnicos e sem especificar como atingir os objetivos por ela definidos. Mesmo 
assim, podemos inferir itens que precisarão constar na especificação de 
segurança da aplicação. Por exemplo, fica claro que será necessária 
a autenticação dos usuários nas aplicações e o armazenamento das ações, 
preservando as trilhas de auditoria. 
Os objetivos de segurança expressam as escolhas do cliente e consistem na 
especificação dos Requisitos Funcionais de Segurança (RFS) e dos Requisitos 
Não Funcionais de Segurança (RNFS). Os requisitos funcionais de segurança 
estão relacionados com as funcionalidades de segurança que o sistema deve 
atender. 
Exemplo de RFS expressos pelo cliente são: 
"Todos os usuários devem ser autenticados para uso do sistema." 
"Somente os gerentes podem visualizar o módulo de relatórios." 
Os requisitos não funcionais de segurança declaram restrições ou atributos que 
expressam como o software deve ser feito. 
Exemplo de RNFS são: 
"O software deve validar todas as entradas de dados." 
"Em caso de erro, o sistema deve se manter em um estado seguro". 
A diferença entre o RFS e o RNFS está no fato de o primeiro estar relacionado 
ao requisito funcional do software, ou seja, o requisito de segurança é uma 
funcionalidade do sistema. Geralmente o requisito funcional de segurança está 
relacionado com questões ligadas à autenticação e autorização dos usuários, 
mas podem haver outras (requisitos de auditabilidade, por exemplo). Por sua 
vez, os requisitos não funcionais de segurança geralmente envolve questões 
como os testes que serão executados, as configurações do ambiente, 
criptografias e tokens utilizados etc. Um rol exemplificativo destes requisitos 
pode ser consultado nas Especificações de Requisitos de Segurança. 
Devido ao fato de estarem em constante evolução, é praticamente impossível 
identificar todas as ameaças a que um sistema está exposto. Portanto, 
devemos considerar um grupo geral e bem definido de ameaças que possuem 
maior probabilidade de ocorrência ou maior impacto sobre o negócio. 
Um exemplo de ameaça bem definida é: "usuário sem privilégios administrativos consegue 
acessar a console de gerenciamento". Uma ameaça muito genérica e maldefinida seria: 
"hacker invade o sistema". 
Falta no segundo exemplo um definição mais clara e objetiva da ameaça para 
que possamos derivar emcontroles de segurança. Por outro lado, no exemplo 
de ameaça bem definida podemos com certa facilidade especificar alguns 
controles de segurança que garantem a proteção contra esta ameaça. 
Uma técnica que ajuda no levantamento das ameaças do sistema é 
o DIAGRAMA DE CASOS DE ABUSO semelhante ao DIAGRAMA DE CASOS 
DE USO, mas descrito na perspectiva de um ator malicioso, que tentará todas 
as possibilidades de uso do sistema de forma subversiva. O importante nesta 
etapa é que o Analista de Requisitos desenvolva uma mentalidade de 
segurança, ou seja, que ele comece a imaginar situações de mau uso 
(intencional ou não) do sistema. 
1 Engenharia de requisitos segura 
A engenharia de requisitos de um sistema demanda uma intensa interação com 
o cliente. Segundo Roger Pressman, a engenharia de requisitos envolve as 
atividades de concepção, levantamento, elaboração, negociação, 
especificação, validação e gestão de requisitos. 
A literatura se preocupa com o entendimento dos requisitos, a modelagem de 
análise, resolução de requisitos conflitantes, rastreabilidade dos requisitos, etc. 
 
Todas essas atividades são essenciais para um ciclo de desenvolvimento. 
Porém, para garantir que o sistema a ser construído tenha os controles de 
segurança necessários à proteção de suas informações, devemos acrescentar 
algumas atividades na engenharia de requisitos: 
1- categorização de segurança do sistema 
2- especificação de requisitos de segurança 
3- descrição dos casos de abuso 
 
A figura 2.2 inclui mais 3 atividades de segurança para formar a chamada 
engenharia de requisitos segura. O grande benefício dessas atividades é 
antecipar a preocupação com a segurança do sistema. 
 Primeiramente com o entendimento da necessidade de segurança do 
sistema por meio da categorização de segurança; 
 em seguida com a especificação dos requisitos de segurança que 
deverão ser implementados; e 
 por fim, a descrição dos casos de abuso para deixar claro os cenários 
indesejados de uso do sistema. 
Essas atividades serão explicadas a seguir. 
2 Categorização de segurança 
 
O National Institute of Standards and Technology (NIST) é o órgão nacional do 
governo Americano responsável por definir padrões e tecnologias a serem 
utilizadas pelas agências dos Estados Unidos. Em sua publicação FIPS 
( Federal Information Processing Standard ) 199, o NIST define um padrão para 
categorização de segurança de sistemas de informação. 
O propósito da categorização dos sistemas de informação é identificar o nível 
apropriado de segurança de acordo com os riscos identificados. 
Podemos entender esta categorização de segurança como uma avaliação 
preliminar de riscos, feita em conjunto com o cliente. Ela irá servir como base 
para a definição dos requisitos de segurança do sistema e irá nortear todas as 
outras atividades de segurança durante o ciclo de desenvolvimento seguro. 
Neste curso aprenderemos como aplicar a metodologia descrita no FIPS 
199 para identificar a categoria de segurança de um sistema. 
O momento mais adequado para realizar esta atividade é durante a descrição 
dos casos de uso do sistema. Será muito mais fácil nesta etapa analisar quais 
dados são tratados pelo sistema. 
Abaixo mostramos o caso de uso "Realizar inscrição" de um sistema escolar 
que servirá de exemplo para a aplicação da metodologia FIPS 199. 
 
 
SISTEMA ESCOLA 
 
Caso de Uso 01: Realizar Inscrição 
Sumário: Aluno usa o sistema para realizar inscrição em disciplinas. 
Ator Primário: Aluno 
Atores Secundários: Sistema de Faturamento 
Pré-condições: O Aluno está identificado pelo sistema. 
FLUXO PRINCIPAL 
 
1. O Aluno solicita a realização de inscrição. 
2. O sistema apresenta as disciplinas disponíveis para o semestre corrente e para as quais o aluno 
atende aos pré-requisitos. 
3. O Aluno seleciona as disciplinas desejadas e as submete para inscrição. 
4. Para cada disciplina selecionada, o sistema aloca o aluno em uma turma que apresente uma oferta 
para tal disciplina. 
5. O sistema informa as turmasnas quais o Aluno foi alocado. Para cada alocação, o sistema informa o 
professor, os horários e os respectivos locais das aulas de cada disciplina. 
6. O Aluno confere as informações fornecidas. 
7. O sistema envia os dados sobre a inscrição do aluno para o Módulo de Faturamento e o caso de uso 
termina. 
FLUXO ALTERNATIVO (4): Inclusão em lista de espera 
 
a. Se não há oferta disponível para alguma disciplina selecionada pelo aluno, o sistema reporta o fato e 
fornece a possibilidade de inserir o Aluno em uma lista de espera. 
b. Se o Aluno aceitar, o sistema o insere na lista de espera e apresenta a posição na qual o aluno foi 
inserido na lista. O caso de uso retorna ao passo 4. 
c. Se o Aluno não aceitar, o caso de uso prossegue a partir do passo 4. 
FLUXO ALTERNATIVO (6): Desistência de disciplina 
 
a. Se o Aluno quiser desistir de uma disciplina ou sair da lista de espera, ele submete ao sistema o 
pedido de desistência. O caso de uso prossegue a partir do passo 6. 
Pós-condições: O aluno foi inscrito em uma das turmas de cada uma das disciplinas desejadas, ou foi 
adicionado a uma ou mais listas de espera. 
2 Categorização de segurança 
2.1 Categorização dos tipos de informação 
O primeiro passo definido no FIPS 199 é aplicar a categorização dos tipos de 
informação, que representam uma categoria específica de informações 
definidas pela organização ou, em outras instâncias, por leis, políticas, 
regulamentações, etc. 
Exemplos de tipos de informação comuns incluem: informações médicas, proprietárias, 
financeiras, investigativas, contratuais, gerenciais, cadastrais, etc. 
Neste primeiro passo devemos identificar cada tipo de informação que 
o sistema irá tratar.Um sistema tipicamente trabalha com vários tipos de 
informação. 
Podemos identificar os tipos que estão destacadas no Caso de Uso 01: 
1) Aluno 
A pré-condição do caso de uso indica que o sistema realiza a autenticação dos 
alunos para que eles possam solicitar a matrícula. Os dados que são 
armazenados de cada aluno não estão detalhados, mas com certeza o sistema 
possui um registro de todos os alunos. Portanto, o primeiro tipo de informação 
descrito no caso de uso são as informações sobre os Alunos. 
A confidencialidade dessa informação cresce a medida em que os dados 
pessoais importantes do aluno são requeridos pelo sistema. Um sistema que 
guarda a matrícula do aluno mais o seu nome terá diferenteimpacto na 
confidencialidade do que um sistema que necessita do CPF, número de 
identidade, título de eleitor, endereço, telefones e, em alguns casos, a conta 
bancária. Para dar continuidade ao nosso exemplo, iremos supor que os dados 
dos alunos são: matrícula, nome e data de nascimento. 
2) Inscrição 
A segunda informação tratada pelo sistema é a Inscrição. Esta informação 
consiste no relacionamento entre o aluno e as disciplinas que irá cursar no 
semestre. Podemos notar que o atributo de segurança mais relevante desta 
informação é a integridade, pois uma alteração indevida nas inscrições tem um 
impacto relevante ao sistema. Devemos garantir que a inscrição do aluno se 
mantenha consistente, íntegra, para que no primeiro dia de aula todos 
consigam se deslocar às salas das disciplinas que se matricularam. Ao passo 
que a confidencialidade dessa informação é pouco relevante para o sistema e 
poderia até mesmo ser considerada pública. 
3) Disciplina 
As informações que são apresentadas pelo sistema aos seus usuários também 
devem ser classificadas. Percebam que as informações referentes às 
disciplinas somente são consultadas neste caso de uso. O cadastramento, 
alteração e exclusão provavelmente são tratados em outro caso de uso 
responsável por manter as informações sobre disciplinas. 
No nosso exemplo, iremos considerar que essa informação é pública e que a 
perda de integridade possui um impacto alto (com o raciocínio semelhante aos 
das informações sobre inscrição). 
4) Turma 
O caso de uso especifica que os alunos serão alocado nas turmas. Haverá um 
relacionamento entre o aluno e a turma. A integridade dessa informação é 
importante para a segurança do sistema. Iremos englobar aqui as informações 
dessa associação descritas no passo 5 do caso de uso: professor, horários e 
local de aula. 
5) Lista de espera 
O fluxo alternativo (4) descreve a possibilidade de um aluno entrar em uma fila 
de espera. A quebra de confidencialidade dessa fila causa menos impacto que 
a de integridade. O objetivo é impedir que um aluno espertinho "fure a fila" de 
espera. 
Depois de identificarmos todos os tipos de informação tratados pelo caso de 
uso devemos aplicar a metodologia a cada um dos tipos de informação. Esta 
metodologia consiste em avaliar o impacto da perda de confidencialidade, 
integridade e disponibilidade das informações e atribuir os níveis ALTO, 
MÉDIO, BAIXO e NÃO SE APLICA 1 . 
Tabela 2.1 
 
 
Impacto 
 
Confidencialidade Integridade Disponibilidade 
Tipos de 
informação 
Alunos BAIXA MÉDIA BAIXA 
Inscrição MÉDIA ALTA BAIXA 
Disciplina NÃO SE APLICA ALTA BAIXA 
Turma NÃO SE APLICA ALTA MÉDIA 
Lista de espera BAIXA ALTA MÉDIA 
Esta tabela representa a categorização de segurança dos tipos de informação 
do Caso de Uso 01. Essa metodologia deve ser repetida para todos os casos 
de uso do sistema, até termos todas as informações do sistema avaliadas. 
Porém, passaremos para o passo seguinte da metodologia considerando 
apenas as informações descritas no Caso de Uso 01. 
2.2 Categorização do sistema 
O passo seguinte da metodologia consiste em atribuir a categorização de 
segurança ao sistema de informação. Este valor é obtido a partir dos impactos 
atribuídos aos tipos de informação que o sistema irá tratar. A regra é que o 
sistema deve ser categorizado pelo nível mais alto definido em cada atributo de 
segurança (confidencialidade, integridade e disponibilidade). O sistema escolar 
dado como exemplo receberia a categorização MÉDIA para confidencialidade, 
ALTA para integridade e MÉDIA para disponibilidade. Esta categorização pode 
ser representada como na tabela 2.2 ou em formato textual. 
Tabela 2.2 
 
 
Impacto 
 
Confidencialidade Integridade Disponibilidade 
Tipos de Alunos BAIXA MÉDIA BAIXA 
informação Inscrição MÉDIA ALTA BAIXA 
Disciplina NÃO SE APLICA ALTA BAIXA 
Turma NÃO SE APLICA ALTA MÉDIA 
Lista de 
espera 
BAIXA ALTA MÉDIA 
SISTEMA ESCOLAR MÉDIA ALTA MÉDIA 
Esta categorização do sistema servirá de base para a seleção dos requisitos de 
segurança do sistema, para a aceitação/avaliação de riscos e seleção dos 
controles. A dificuldade desta tarefa está na avaliação de impacto de cada 
atributo. É de se esperar que o Analista de Requisitos pergunte: "Mas o que 
significa um impacto ALTO, MÉDIO ou BAIXO?". Esta resposta deverá ser 
obtida com o próprio cliente e exige a definição desses critérios pelas partes 
interessadas. 
Uma outra forma de obter a categorização do sistema é por meio de uma 
metodologia de Análise do Impacto no Negócio (BIA - Business Impact 
Analysis). 
3 Regulamentos de segurança 
Além dos padrões estudados até agora, utilizados para auxiliar na categoria de 
segurança dos sistemas, existe um rol de regulamentos que podem ter 
desdobramentos nos requisitos de segurança do software a ser desenvolvido. 
Neste tópico abordaremos de forma geral como funciona este desdobramento 
tomando como exemplo Normativos externos da Administração Pública. 
Tomando como ponto de partida documentos em níveis mais altos - Leis 
Federais, Normativos Complementares, Política de Segurança Institucional etc. 
- podemos ter o desdobramento para objetivos de alto nível do sistema que, 
por sua vez, podem ser detalhados em requisitos de segurança do sistema. 
A figura a seguir ilustra esta ideia: 
Desdobramentos nos requisitos de segurançaRegulamentos Objetivos de alto nível Requisitos de 
internos e externos segurança 
 Leis 
 Normas 
 Políticas 
organizacionais 
 Confidencialidade 
 Transmissão segura 
 Privacidade 
 Tratamento de 
informações 
classificadas 
 Gestão de 
indentidade 
 Criptografia de 
dados 
 Logs de auditoria 
Todos os regulamentos que possuem diretrizes de segurança, sejam eles da 
própria organização ou externos, devem ser considerados. Uma lista dos 
regulamentos de segurança (internos e externos) estão disponíveis e 
atualizados na página da Coordenação de Gestão da Segurança da 
Informação - CGOSI, em http://cogsi.serpronet.serpro/conteudo/produtos-e-
servicos/normas/. 
Tomaremos como exemplo o regulamento externo Norma Complementar nº 
020 do Gabinete de Segurança Institucional da Presidência da República, que 
possui diretrizes de Segurança da Informação para instituição do processo de 
tratamento da informação. 
A referida NC 020 dispõe, em seu tópico 6.2.6, que 
Os órgãos e entidades da APF deverão adotar os procedimentos de controle de acesso 
necessários à segurança dos registros e armazenamento das informações. 
Este regulamento pode ser desdobrado em objetivos de alto nível para a 
segurança do sistema, como por exemplo: 
O acesso às informações cadastradas no sistema XYZ deverão ser controlados. 
Este objetivo de alto nível ainda pode ser desdobrado em vários requisitos de 
segurança para o sistema a ser construído. Como por exemplo: 
Para cadastrar um novo registro , o usuário deve realizar autenticação via certificado 
digital. 
Outra Norma Complementar que deve ser de conhecimento das equipes 
envolvidas no desenvolvimento de softwares é a NC 016, que possui diretrizes 
para o desenvolvimento e obtenção de software seguro. Ela está no rol de 
normativos externos na página da COGSI. 
4 Especificação de requisitos de segurança 
Na próxima atividade de segurança da fase de Requisitos, iremos especificar 
os requisitos de segurançado sistema. 
Continuando com o exemplo do sistema escolar, o primeiro passo é analisar se 
há algum requisito funcional de segurança. O caso de uso "Realizar inscrição" 
define somente um Requisito Funcional. Esta funcionalidade não agrega 
segurança ao sistema. Por conta disso, podemos ver que não se trata de um 
requisito funcional de segurança. 
Extrapolando o caso de uso "Realizar inscrição", podemos visualizar sua pré-
condição que o aluno já foi autenticado pelo sistema. Isto pressupõe que há um 
caso de uso "Autenticar aluno no sistema escolar". Este sim, seria um 
Requisito Funcional de Segurança, pois se trata de uma funcionalidade voltada 
para a segurança do sistema. 
Porém, iremos manter o foco no caso de uso "Realizar inscrição" e derivar os 
requisitos não funcionais de segurança a partir da categorização feita 
anteriormente. Os requisitos estão relacionados à forma como a funcionalidade 
é implementada, com as restrições e propriedades de segurança do caso de 
uso. A categorização de segurança nos indica que devemos selecionar 
principalmente os requisitos que tratam da integridade das informações 
(a confidencialidade e disponibilidade foram definidas como de impactomédio). 
Primeiro, vamos conhecer uma lista de requisitos não funcionais para cada 
atributo de segurança. 
Confidencialidade: 
Em linhas gerais, são requisitos que lidam com a proteção das informações 
para dificultar o acesso não autorizado. Por exemplo: 
 prevenir a divulgação não autorizada da informação; 
 garantir autorização para acesso aos recursos; 
 aplicar criptografia nos dados armazenados no sistema. 
Integridade: 
Geralmente com o objetivo de assegurar a integridade dos dados em trânsito e 
armazenados pelo sistema. Podem especificar meios de detectar e recuperar 
erros, tais como exclusões, inclusões e modificações. Por exemplo: 
 fazer validação dos dados de origem; 
 detectar alterações dos dados; 
 assinar digitalmente os documentos. 
Disponibilidade: 
Estão preocupados com a negação de acessos ilegítimos aos recursos 
computacionais e prevenir ataques de negação de serviço. Além disso, 
requisitos para tratar as tentativas de destruição ou dano aos dados e negação 
de acesso legítimo ao sistema. Por exemplo: 
 restringir acesso aos recursos; 
 bloquear acessos simultâneos; 
 limitar o número de conexões. 
5 Casos de Abuso 
Após obter a categorização do sistema e a especificação dos requisitos de 
segurança, a próxima atividade do ciclo de desenvolvimento seguro é a 
descrição dos Casos de Abuso do sistema. Esta atividade pode ser vista como 
uma extensão à elaboração do Diagrama de Caso de Uso. 
O Diagrama de Caso de Uso é um diagrama UML que descreve a 
funcionalidade proposta para um novo sistema, que será projetado. Segundo 
Ivar Jacobson, podemos dizer que um Caso de Uso é: 
"um documento narrativo que descreve a sequência de eventos de um ator que usa um 
sistema para completar um processo". 
A figura 2.3 ilustra o Diagrama de Caso de Uso do sistema Escolar descrito no 
item 2. 
 
A partir deste Diagrama, que descreve as ações normais entre os autores e o 
sistema, podemos construir o Diagrama de Caso de Abuso. Para isso, 
devemos agora imaginar as situações de abuso do sistema, ou seja, vestir a 
camisa de um usuário malicioso que tentará, de várias formas, usar a aplicação 
de uma maneira diferente da qual foi projetada. Isto retoma a ideia das 
Ameaças que estudamos no início deste Módulo. 
 
Pela figura 2.4 podemos visualizar três situações indesejáveis que poderiam 
ser feitas por um aluno mal-intencionado. Este aluno pode tentar fraudar uma 
inscrição, seja criando uma inscrição fraudulenta com as credenciais de outro 
aluno, seja alterando uma inscrição previamente realizada por alguém. Outra 
situação imaginada é a de burlar a lista de espera, representada no fluxo 
alternativo (4) da descrição do caso de uso. A ultima situação descrita no Caso 
de Abuso é burlar o pré-requisito de uma matéria, possibilitando um aluno se 
inscrever em uma matéria sem ter os pré-requisitos. 
A lista de mau uso do sistema prossegue e é papel do Analista de Requisitos, 
com o apoio de uma equipe de segurança, identificar os casos de abuso mais 
relevantes para o sistema. Esta identificação deve estar em conformidade com 
a categorização de segurança. 
Vamos lembrar a classificação do sistema escolar: 
{(confidencialidade, média) , (integridade, alta) , (disponibilidade, média)}; 
Os casos de abuso identificados afetam diretamente a integridade da inscrição: 
fraudar a inscrição, burlar lista de espera ou pré-requisitos. Faz sentido termos 
levantado justamente esses casos de abuso do sistema, pois na categorização 
do sistema a integridade é o ponto mais relevante. 
E por isso deixamos outros casos de abuso de lado. Poderíamos ter 
identificado, por exemplo, um caso de abuso que ataca a confidencialidade 
(Visualizar inscrição de outros alunos) ou até mesmo a disponibilidade (Inundar 
o sistema com inscrições). 
Agora vamos fazer a associação dos requisitos de segurança de integridade 
com os casos de abuso. Podemos visualizar na figura 2.5 esta relação. 
 
Por meio desta técnica, juntamos os requisitos de segurança não funcionais 
levantados para o sistema escolar com os casos de abuso identificados. O 
sistema deve ter certeza de que os dados a ele enviados foram submetidos 
pelo aluno previamente identificado. 
Isto consiste na validação dos dados de origem e dificulta que um aluno mal-
intencionado consiga fraudar uma inscrição ou burlar os pré-requisitos da 
disciplina. 
No caso da lista de espera, podemos definir que o sistema será capaz de 
inserir alunos na lista mas nunca excluí-los. Portanto, o requisito não funcional 
de segurança "detectar alterações nos dados" irá dificultar a ameaça de burlarlista de espera.