KNOWEAK UMA FERRAMENTA DE ANÁLISE DE RISCO EM...

KNOWEAK – UMA FERRAMENTA DE ANÁLISE DE

RISCO EM TECNOLOGIA DA INFORMAÇÃO

Patrick Svaiter

Projeto de Graduação apresentado ao Curso

de Engenharia Eletrônica e de Computação

da Escola Politécnica, Universidade Federal

do Rio de Janeiro, como parte dos

requisitos necessários à obtenção do título

de Engenheiro.

Orientador: Marcelo Luiz Drumond Lanza

Rio de Janeiro, RJ – Brasil

Março de 2019

v

UNIVERSIDADE FEDERAL DO RIO DE JANEIRO

Escola Politécnica – Departamento de Eletrônica e de Computação

Centro de Tecnologia, Bloco H – Cidade Universitária

Rio de Janeiro, RJ – CEP 21949-900

Este exemplar é de propriedade da Universidade Federal do Rio de Janeiro, que

poderá incluí-lo em base de dados, armazenar em computador, microfilmar ou adotar

qualquer forma de arquivamento.

É permitida a menção, reprodução parcial ou integral e a transmissão entre

bibliotecas deste trabalho, sem modificação de seu texto, em qualquer meio que esteja

ou venha a ser fixado, para pesquisa acadêmica, comentários e citações, desde que sem

finalidade comercial e que seja feita a referência bibliográfica completa.

Os conceitos expressos neste trabalho são de responsabilidade do(s) autor(es).

vi

DEDICATÓRIA

Dedico este trabalho ao meu pai Luiz Svaiter e à minha mãe Fany Svaiter, que

me deram a educação familiar para crescer sendo uma pessoa íntegra e honesta,

dedicada aos estudos e repleta de empatia.

vii

AGRADECIMENTO

Durante o tempo de faculdade, tive algumas interações pessoais mais profundas

e prazerosas, que contribuíram significativamente na construção da minha

personalidade. Agora, gostaria de agradecer a estes que marcaram essa etapa da minha

vida.

Meus pais. Dediquei este projeto a vocês, mas gostaria de agradecê-los por todo

suporte e compreensão. Eu sei que o encerramento desse ciclo representa a

concretização de um sonho de vocês, e eu fico extremamente feliz de realizá-lo.

Meus irmãos Andrea Svaiter e Marcio Alan Svaiter, com vocês eu aprendi que,

no final, sempre restará a família ao seu lado.

O grupo Fundão-Five, que foram aqueles amigos de colégio que rachavam táxis

ou caronas para ir ou voltar da faculdade, ao som da Hora do Mução.

O verdadeiro amigo que fiz na UFRJ, Filipe Maia Lessa Pinheiro. Fico feliz em

ter “crescido” junto contigo e levado esta amizade pra fora da universidade. Admiro sua

inteligência e sua intimidade com a Engenharia. Por um momento, achei que nos

distanciaríamos, mas como diz o Gabriel, o Pensador, “Guarde o que é bom no seu peito

/ E o que for ruim ou suspeito, esqueça”.

Carrego também outras lembranças da UFRJ, que tornaram meus dias mais

leves durante diversos períodos difíceis de muito estudo: Andressa Sivolella, Bruno

Ramos, Dhiana Deva, João Faria, e Vinicius Loureiro.

Os professores da UFRJ. Foi uma honra poder absorver conhecimento com

tantos mestres (lato sensu).

A Stone, que foi uma organização que me proporcionou um salto de qualidade

pessoal e profissional enorme. Como são pessoas que estão por trás disso, destaco

aqueles que, além de serem fontes de inspiração, ultrapassaram a barreira dos

escritórios: Daniel Dias e Odilon Cabral. Suas atitudes me ensinaram muito.

Minha namorada. Michelline Lobato, você teve papel fundamental no

desenvolvimento deste projeto. Obrigado pelo suporte e por me tornar mais humano a

cada interação. Para seu orgulho, ao fim disso tudo, realizarei uma “defesa”.

Por fim, a UFRJ. Eu entendo porque você é referência nacional e internacional.

Este projeto é fruto do investimento e confiança em mim depositados. Obrigado.

viii

RESUMO

Quanto mais o mundo se torna digital, mais se explora as vulnerabilidades

existentes no campo tecnológico. Por se tornar digital, o autor não se refere ao fato de a

população ter acesso a dispositivos tecnológicos, e sim que cada vez mais os

dispositivos estão “se tornando” inteligentes e conectados à Internet. Um equipamento

como uma geladeira, antes inofensivo, agora pode constituir uma porta de entrada para

ataques maliciosos, desde que esteja conectada à Internet. Reconhecer a importância de

zelar pela proteção dos dados é o primeiro passo para proteger a si mesmo e às

organizações contra incidentes de segurança. Passada a fase de conscientização, deve-se

tomar iniciativas para conhecer suas vulnerabilidades e aplicar controles que a tornem

menores ou inexistentes. Isso pode ser feito contratando empresas especializadas que

sigam normas internacionais de segurança da informação, como a família ISO 27000.

Este trabalho apresenta os principais conceitos sobre Segurança da Informação e

implementa um sistema de computador que permite elencar as vulnerabilidades de uma

organização. A partir do procedimento estudado e aplicado nesse sistema, é possível

estimar a probabilidade de um incidente ocorrer e o impacto que ele causaria à

organização se ocorresse. Finalmente, a empresa sob análise pode tomar as devidas

providências para mitigar esses riscos com base nos dados fornecidos pela ferramenta,

atacando-os por ordem de maior impacto, de maior probabilidade e/ou de maior risco

para o negócio da empresa.

Palavras-Chave: TI, segurança da informação, informação, gestão, SGSI.

ix

ABSTRACT

The more the world becomes digital, the more the existing vulnerabilities are

exploited in the field of technology. By becoming digital, the author does not refer to

the fact that people have easy access to technology devices, but that more and more

electric and electronic devices are being connected to the Internet. Now it’s possible to

find single-purpose devices like refrigerator with extra capabilities. Once these are

connected to computer networks with Internet access, the attack surface is increased,

representing a risk that never existed. Recognizing the importance of data protection is

the first step in protecting yourself and the organizations from security incidents. After

this awareness phase, organization leaders should take actions to increase knowledge

about its own vulnerabilities and apply controls to mitigate or eliminate them

completely. This can be achieved by hiring specialized companies that follow

international standards on Information Security, like the family ISO 27000. This study

presents the main concepts of information security and implements a computer system

that allows to list the vulnerabilities of an organization. From the procedure studied and

applied to the system, it’s possible to estimate the probability of an incident to occur

and the impact that it would cause to the organization if it occurred. Finally, the

company under analysis can take the appropriate measures to mitigate risks based on

data provided by the tool, attacking them by greater impact, greater probability and/or

greater risk for the business of the company.

Key-words: IT, information security, information, management, ISMS.

x

SIGLAS

ACID Atomicity, Consistency, Isolation, Durability

API Application Programming Interface

BSI British Standard Institute

CCSC Commercial Computer Security Centre

CNPJ Cadastro Nacional da Pessoa Jurídica

DEL Departamento de Eletrônica e de Computação da UFRJ

DTI Department of Trade and Industry (United Kingdom)

ERD Entity-Relationship Diagram

HTML Hypertext Markup Lanaguage

HTTP Hypertext Transfer Protocol

ICP-Brasil Infraestrutura de Chaves Públicas Brasileira

IEC International Electrotechnical Commission

ISO International Organization for Standardization

JSON JavaScript Object Notation

KYC Know Your Customers

KYP Know Your Partners

KYS Know Your Suppliers

ORM Object-Relational Mapping

PDCA Plan, Do, Check, Act

REST Representational State Transfer

SGBD Sistema de Gerenciamento de Banco de Dados

SGSI Sistema de Gestão da Segurança da Informação

SI Segurança da Informação

SPA Single Page Application

SQL Structured Query Language

TI Tecnologia da informação

UFRJ Universidade Federal do Rio de Janeiro

UPS Uninterruptible Power Supply

URI Uniform Resource Identifier

URL Universal Resource Locator

XML Extensible Markup Language

xi

Sumário

Lista de Figuras ............................................................................................................. xiv

Lista de Tabelas ............................................................................................................ xvii

Capítulo 1 – Introdução .................................................................................................... 1

1.1 – Tema ................................................................................................................ 1

1.2 – Delimitação ...................................................................................................... 1

1.3 – Justificativa ...................................................................................................... 2

1.4 – Objetivos .......................................................................................................... 3

1.5 – Metodologia ..................................................................................................... 3

1.6 – Estrutura do documento ................................................................................... 4

Capítulo 2 – Fundamentação Teórica ............................................................................... 5

2.1 – A origem da série ISO 27000 .......................................................................... 5

2.2 – Conceitos Básicos ............................................................................................ 6

2.2.1 – A Informação ........................................................................................ 7

2.2.2 – Os Pilares da Segurança da Informação ............................................... 7

2.2.2.1 – Confidencialidade ...................................................................... 8

2.2.2.2 – Integridade ................................................................................. 8

2.2.2.3 – Disponibilidade .......................................................................... 8

2.2.2.4 – Autenticidade ............................................................................. 8

2.2.2.5 – Não-repúdio ............................................................................... 9

2.2.2.6 – Privacidade ................................................................................ 9

2.2.3 – Ativo de Tecnologia da Informação ................................................... 10

2.2.4 – Vulnerabilidade e Ameaça ................................................................. 11

2.2.5 – Vetor de Ataque .................................................................................. 11

2.2.6 – Incidente de Segurança ....................................................................... 11

2.3 – Analisando os Riscos ..................................................................................... 12

xii

2.3.1 – Estratégias de avaliação do risco ........................................................ 12

2.3.2 – Levantamento da estrutura organizacional ......................................... 13

2.3.3 – Determinação de relevâncias .............................................................. 14

2.3.4 – Definição de escopo ........................................................................... 15

2.3.5 – Identificação e classificação de ameaças e vulnerabilidades ............. 15

2.3.6 – A análise ............................................................................................. 17

2.3.7 – A avaliação ......................................................................................... 18

Capítulo 3 – Modelagem ................................................................................................ 20

3.1 – Requisitos de negócio .................................................................................... 20

3.1.1 – Funcionalidades .................................................................................. 20

3.1.2 – Dados das entidades ........................................................................... 22

3.2 – Requisitos técnicos ........................................................................................ 23

3.3 – O modelo de dados ........................................................................................ 23

3.3.1 – A escolha da estrutura de dados relacional ......................................... 23

3.3.2 – Levantamento das entidades e relacionamentos ................................. 24

3.4 – Requisito técnico extra .................................................................................. 29

3.5 – Permissões de acesso ..................................................................................... 29

Capítulo 4 – Implementação ........................................................................................... 32

4.1 – Critérios de escolha das tecnologias .............................................................. 32

4.2 – O banco de dados ........................................................................................... 33

4.3 – O back-end ..................................................................................................... 34

4.3.1 – O design da API.................................................................................. 34

4.3.1.1 – Ideias gerais sobre os recursos ................................................ 35

4.3.1.2 – Convenção sobre os verbos HTTP .......................................... 36

4.3.1.3 – Códigos de resposta HTTP ...................................................... 37

4.3.1.4 – Recursos disponíveis ............................................................... 37

4.3.2 – A escolha do framework web ............................................................. 39

xiii

4.3.2.1 – Sobre a serialização de dados .................................................. 40

4.3.2.2 – Sobre a comunicação com o banco de dados .......................... 41

4.3.3 – Como criar um recurso ....................................................................... 42

4.3.4 – Como obter um recurso ...................................................................... 43

4.3.5 – Como modificar um recurso ............................................................... 45

4.3.6 – Como remover um recurso ................................................................. 47

4.3.7 – Como criar uma análise de risco ........................................................ 48

4.4 – O front-end .................................................................................................... 51

4.4.1 – Autenticação ....................................................................................... 51

4.4.2 – Menu ................................................................................................... 52

4.4.3 – Telas ................................................................................................... 53

4.4.4 – Permissionamento............................................................................... 71

Capítulo 5 – Testes ......................................................................................................... 73

5.1 – Testes no back-end ........................................................................................ 73

5.2 – Testes no front-end ........................................................................................ 77

Capítulo 6 – Conclusão .................................................................................................. 80

Bibliografia ..................................................................................................................... 83

Apêndice A – Como configurar o ambiente de desenvolvimento .................................. 87

Apêndice B – Como configurar o ambiente de execução .............................................. 92

Apêndice C – Script de criação das tabelas do banco de dados ..................................... 98

xiv

Lista de Figuras

Figura 2.1 – Linha do tempo com a origem das normas ISO 27001 e ISO 27002. .......... 6

Figura 3.1 – Diagrama Entidade-Relacionamento da organização e sua estrutura. ....... 26

Figura 3.2 – Diagrama Entidade-Relacionamento que representa as ameaças da

organização, as vulnerabilidades dos ativos e os controles aplicados sobre eles. 28

Figura 3.3 – Diagrama Entidade-Relacionamento que representa as análises. .............. 29

Figura 4.1 – Código de exemplo para implementação de um recurso de uma API

utilizando o framework Falcon. .......................................................................... 40

Figura 4.2 – Exemplo de solicitação HTTP para criar um recurso. ............................... 42

Figura 4.3 – Resposta à solicitação HTTP para criar um recurso. ................................. 43

Figura 4.4 – Exemplo de solicitação HTTP para obter um recurso. .............................. 43

Figura 4.5 – Resposta à solicitação HTTP para obter um recurso. ................................ 44

Figura 4.6 – Exemplo de solicitação HTTP para obter um recurso do tipo coleção. ..... 45

Figura 4.7 – Resposta à solicitação HTTP para obter um recurso do tipo coleção. ....... 45

Figura 4.8 – Exemplo de solicitação HTTP para modificar um recurso. ....................... 46

Figura 4.9 – Resposta à solicitação HTTP para modificar um recurso. ......................... 46

Figura 4.10 – Exemplo de solicitação HTTP para remover uma propriedade opcional de

um recurso. .......................................................................................................... 47

Figura 4.11 – Exemplo de solicitação HTTP para remover um recurso. ....................... 47

Figura 4.12 – Exemplo de solicitação HTTP para criar análise. .................................... 48

Figura 4.13 – Resposta à solicitação HTTP para criar análise. ...................................... 49

Figura 4.14 – Exemplo de solicitação HTTP para obter os detalhes de uma análise. .... 50

Figura 4.15 – Resposta à solicitação HTTP para obter os detalhes de uma análise. ...... 50

Figura 4.16 – Tela apresentada antes de informar as credenciais de acesso. ................. 52

Figura 4.17 – Tela de login. ............................................................................................ 52

Figura 4.18 – Tela inicial do sistema após login. ........................................................... 53

Figura 4.19 – Tela de listagem e criação de departamentos. .......................................... 55

Figura 4.20 – Tela de atualização de departamento. ...................................................... 55

Figura 4.21 – Tela de listagem e criação de ativos de TI. .............................................. 56

Figura 4.22 – Tela de listagem e criação de ativos de TI com destaque para as categorias

de ativo disponíveis. ............................................................................................ 56

Figura 4.23 – Tela de atualização de ativo de TI............................................................ 57

xv

Figura 4.24 – Tela de listagem e criação de ameaças. .................................................... 57

Figura 4.25 – Tela de atualização de ameaça. ................................................................ 58

Figura 4.26 – Tela de criação de organização. ............................................................... 58

Figura 4.27 – Tela de listagem de organizações. ............................................................ 59

Figura 4.28 – Tela de detalhes de uma organização. ...................................................... 59

Figura 4.29 – Tela de atualização de uma organização. ................................................. 60

Figura 4.30 – Tela de listagem de ameaças de uma organização sem nenhuma ameaça

cadastrada. ........................................................................................................... 60

Figura 4.31 – Tela para inclusão de ameaça na organização.......................................... 61

Figura 4.32 – Tela de listagem de ameaças de uma organização preenchida com dois

registros. .............................................................................................................. 61

Figura 4.33 – Tela de listagem de ativos de TI de uma organização. ............................ 62

Figura 4.34 – Tela de inclusão de ativo de TI na organização. ...................................... 62

Figura 4.35 – Tela de atualização do ativo de TI de uma organização. ......................... 63

Figura 4.36 – Tela de listagem de vulnerabilidades de um ativo de TI sem nenhuma

vulnerabilidade cadastrada. ................................................................................. 63

Figura 4.37 – Tela para cadastrar vulnerabilidade de um ativo de TI da organização. .. 64

Figura 4.38 – Tela de listagem de vulnerabilidades de ativo de TI preenchida com dois

registros. .............................................................................................................. 64

Figura 4.39 – Tela de gerenciamento da estrutura de uma organização. Sem registros. 65

Figura 4.40 – Tela de gerenciamento da estrutura de uma organização......................... 66

Figura 4.41 – Tela de inclusão de um processo em um macroprocesso da organização.66

Figura 4.42 – Tela de inclusão de ativo de TI já existente na organização em serviço de

TI da organização. ............................................................................................... 67

Figura 4.43 – Tela de inclusão de ativo de TI do catálogo em serviço de TI da

organização.......................................................................................................... 68

Figura 4.44 – Tela de listagem de análises vazia. .......................................................... 68

Figura 4.45 – Tela de criação de análise para toda a organização. ................................. 69

Figura 4.46 – Tela de listagem de análises com duas análises criadas. .......................... 69

Figura 4.47 – Tela de detalhes de uma análise. .............................................................. 70

Figura 4.48 – Tela de detalhes de uma análise com relatório expandido. ...................... 70

Figura 5.1 – Captura de tela do Postman: Criando uma organização............................. 74

Figura 5.2 – Captura de tela do Postman: Tentativa de criação de uma organização com

dados existentes. .................................................................................................. 75

xvi

Figura 5.3 – Captura de tela do Postman: Tentativa de criação de uma organização com

argumentos inválidos........................................................................................... 76

Figura 5.4 – Captura de tela do Postman: Erro de autenticação. .................................... 77

Figura 5.5 – Teste de criação de organização com documento existente. ...................... 78

Figura 5.6 – Erro de autenticação induzido. ................................................................... 78

xvii

Lista de Tabelas

Tabela 2.1 – Graus de classificação para relevâncias e intensidades. ............................ 13

Tabela 2.2 – Alguns processos, serviços e ativos hipotéticos do macroprocesso

“Exportar” de uma empresa do ramo automobilístico. ....................................... 14

Tabela 2.3 – Exemplo de vulnerabilidades de ativos em relação a crackers. ................. 16

Tabela 3.1 – Lista de entidades ...................................................................................... 25

Tabela 3.2 – Tabela de papéis e permissões do sistema. ................................................ 30

Tabela 4.1 – Códigos de resposta HTTP utilizados pela API. ....................................... 37

Tabela 4.2 – Relação das identificações dos recursos e dos verbos HTTP disponíveis

para cada um........................................................................................................ 38

Tabela 4.3 – Definição técnica dos papéis e das permissões de acesso ao sistema. ....... 71

Capítulo 1 –

Introdução

Este capítulo apresenta o tema deste trabalho, delimitando o seu escopo,

apresentando os seus objetivos e a justificativa para a sua realização. Ele também

descreve como este documento está estruturado e qual a metodologia utilizada para a

sua construção.

1.1 – Tema

O tema deste trabalho é Segurança da Informação (SI) [1]. Esse tema remete

facilmente a roubos de dados [2] [3], vírus, invasões e crackers. Por meio de noticiários

ou propagandas de soluções para a proteção de dados, muito se vê sobre instruções

visando manter os usuários finais distantes de tais males em seus computadores

pessoais. Essas orientações são igualmente importantes para organizações, porém com

maior grau de profundidade, exigindo grande esforço por parte delas para proteger

informações que são essenciais para desempenhar os seus processos de negócio.

Segundo matéria publicada pela Computerworld [4], apesar de o número de

incidentes de segurança estar em queda as perdas financeiras por incidente são cada vez

maiores, atualmente passando, na média, de US$ 500 por incidente.

Por conseguinte, a definição de um vocabulário comum e a adoção de diretrizes

e normas de segurança são fundamentais para organizações que desejam proteger as

suas informações. Algumas seguem à risca as diretrizes de órgãos internacionais para

obter certificações, mostrando a seus clientes que elas se preocupam com a segurança

dos dados e que aderem a procedimentos de reconhecimento global.

1.2 – Delimitação

Este trabalho visa a apresentar os principais conceitos sobre Segurança da

Informação, bem como os procedimentos necessários para implementar, em um

empreendimento, um sistema de análise de riscos relacionados à Tecnologia da

Informação (TI).

2

O estudo não aborda como fazer testes de penetração [5], quais são as ameaças

mais perigosas existentes atualmente, quais são as orientações para que usuários se

protejam de ataques e quais são as técnicas mais utilizadas pelos atacantes que se

aproveitam de vulnerabilidades na segurança da informação.

O tema aqui exposto foi estudado em uma época em que boa parte dos usuários

de Internet começou a armazenar seus documentos, fotos e vídeos na “nuvem”. Nestes

sistemas, uma falha de segurança pode provocar vazamento e comercialização ilegal

desses dados, que são valiosos para empresas dos mais diversos setores e para agentes

maliciosos.

Além disso, hoje em dia, as crianças já nascem lidando com smartphones e

tablets, ao mesmo tempo em que seus avós não possuem domínio completo sobre a

tecnologia (apesar de utilizá-la para comunicações essenciais do dia-a-dia e até mesmo

para eventuais compras online). De um lado existe o perigo da inocência com

conhecimento e de outro, o perigo da maturidade com desconhecimento.

1.3 – Justificativa

Segurança da Informação é um tema que dificilmente diminuirá de importância

à medida que a tecnologia penetra no cotidiano da sociedade. A cada dia, mais pessoas

armazenam suas informações em servidores que não estão completamente sob o

domínio delas. Além disso, a maioria o faz aceitando termos de uso sem que os tenham

lido [6] [7], permitindo expor informações importantes e privadas sem o seu real

consentimento. Essa situação acaba se estendendo às empresas, que são formadas por

pessoas comuns, e a consequência de um descuido pode ir de perdas financeiras [4] à

destruição de suas reputações [8] [9] de forma irreparável. Ou seja, tanto a vítima

quanto quem prestou serviços a ela pode ser prejudicado.

Entender os conceitos principais que sustentam a teoria de segurança da

informação é o primeiro passo para que se possa fazer qualquer identificação de

vulnerabilidades e aplicar medidas de controle sobre elas.

3

1.4 – Objetivos

O objetivo deste trabalho é apresentar os principais conceitos de Segurança da

Informação e implementar um sistema que auxilie na gestão de risco dos ativos de TI de

uma organização.

1.5 – Metodologia

A principal fonte de referência utilizada neste trabalho foi a terceira edição do

livro “Sistema de Segurança da Informação – Controlando os Riscos” [10]. A partir do

conhecimento adquirido, foi projetado e implementado um sistema tendo como base a

metodologia apresentada por Campos em seu livro. Outras fontes foram utilizadas para

melhor embasamento teórico e reforço da teoria apresentada pelo livro supracitado.

Para o projeto do software, foram realizadas reuniões entre o orientador e o autor

deste trabalho para estabelecer os requisitos mínimos e as restrições técnicas a serem

atendidas. A partir destes requisitos, as tecnologias utilizadas para o projeto e para a

implementação da ferramenta de análise foram escolhidas livremente pelo autor,

utilizando tanto conhecimentos prévios quanto avaliações realizadas através de recursos

disponíveis na Internet.

O software foi projetado em duas camadas: o back-end 1, responsável por toda a

lógica de funcionamento e pela persistência dos dados; e o front-end 2, que é conectado

ao back-end e provê uma interface gráfica para o usuário final. Esse desacoplamento

traz alguns benefícios, como o desenvolvimento de maneira faseada, a evolução

independente das camadas e a separação de responsabilidades.

As validações das funcionalidades foram feitas pelo próprio autor durante o

desenvolvimento do projeto, à medida que o mesmo progredia e de acordo com os

requisitos definidos. O orientador (responsável pela definição dos requisitos) realizou,

durante o desenvolvimento do trabalho, diversas validações intermediárias e uma

validação final após a conclusão da implementação do sistema.

1 Back-end é um termo em inglês utilizado para se referir ao software que não é acessado

diretamente pelo usuário, mas por outros sistemas. Geralmente, é o back-end que contém as regras de

negócio da aplicação. 2 Front-end é um termo em inglês utilizado para se referir ao software que provê uma interface

para o usuário interagir com ele. É voltado para a comunicação visual e não necessariamente precisa

interagir com um back-end, dependendo de sua finalidade.

4

1.6 – Estrutura do documento

Os próximos capítulos estão estruturados da seguinte maneira:

Capítulo 2: Fundamentação Teórica – Nele são apresentados os principais

conceitos sobre Segurança da Informação, os pilares que a sustentam, e a teoria sobre o

procedimento de análise de riscos.

Capítulo 3: Modelagem – Neste capítulo, são abordadas as especificações do

projeto e a modelagem de dados necessária para alcançar os requisitos mínimos de uma

primeira versão do software.

Capítulo 4: Implementação – Neste capítulo, estão descritas as decisões técnicas

que justificam a escolha das tecnologias utilizadas e como elas foram aplicadas para a

construção do software.

Capítulo 5: Testes – Testes manuais foram realizados durante a fase de

desenvolvimento para garantir que o software atenda aos requisitos modelados. Neste

capítulo, serão apresentados como os testes foram realizados.

Capítulo 6: Conclusão – Aqui, o trabalho é concluído apresentando uma visão

geral do resultado alcançado perante a proposta de desenvolvimento. Este capítulo

também inclui propostas de melhorias e de trabalhos futuros, além da identificação de

outras funcionalidades para novas versões.

Bibliografia – Lista das fontes de dados utilizadas para o embasamento teórico,

para a modelagem e para a implementação do projeto.

Apêndice A: Como configurar o ambiente de desenvolvimento – Possui as

instruções de como o ambiente foi configurado para o desenvolvimento deste projeto.

Apêndice B: Como configurar o ambiente de execução – Nele estão contidas as

instruções de como o ambiente produtivo foi configurado.

Apêndice C: Script de criação das tabelas do banco de dados – Uma cópia do

script que foi utilizado para criar as tabelas do banco de dados e para popular algumas

delas com dados de domínio.

5

Capítulo 2 –

Fundamentação Teórica

Este capítulo apresenta um breve histórico sobre a série de normas ISO 27000.

A seguir, serão apresentados os conceitos básicos de Segurança da Informação e, por

fim, é explicado o que é uma análise de risco e como se estruturam os procedimentos

para a sua execução. O objetivo é dar o devido embasamento ao leitor para que o

mesmo seja capaz de entender e avaliar o conteúdo apresentado nos próximos capítulos.

2.1 – A origem da série ISO 27000

A importância de proteger a informação em sistemas, percebida há mais de três

décadas, ficou evidenciada em 1987 pela iniciativa do Departamento da Indústria e

Comércio (DTI – Department of Trade and Industry) do Reino Unido em criar um

centro para tratar da segurança da informação, o Commercial Computer Security Centre

(CCSC). Uma das atribuições deste centro era criar um código de boas práticas que as

empresas poderiam utilizar para proteger informações. Esse código foi publicado em

1993 pelo British Standard Institute (BSI) como um documento informacional,

chamado PD0003. Em 1995, esse documento se tornou norma sob o código BS7799

[10] [11].

Em 1998, a norma BS7799 ganhou uma segunda parte (BS7799-2) [12], que

auxiliava as empresas a gerirem a segurança da informação, podendo utilizar-se do

código de boas práticas definido na primeira parte. Com essa adição, a primeira parte foi

renomeada para BS7799-1 [13].

Essas normas começaram a ganhar aderência de outros países [10]. Após

revisões e considerações dos membros da International Organization for

Standardization (ISO) e da International Electrotechnical Commission (IEC), em 2000,

a norma BS7799 parte 1 foi adotada e lançada como norma internacional sob o título

ISO/IEC 17799 [14]. No ano de 2005, após ter passado por um processo de evolução, a

norma BS7799-2 se tornou internacional sob o código ISO/IEC 27001 [15]. Nesse

mesmo ano, a ISO/IEC 17799 sofreu revisão e recebeu significativas atualizações [11].

6

Até então, o mundo contava com duas normas ISO relacionadas à segurança da

informação: 27001 (Information security management systems – Requirements) e 17799

(Code of practice for information security controls). Em 2007, a ISO/IEC 17799 foi

renumerada para ISO/IEC 27002 [16] e criou-se a família ISO 27000. Atualmente, essa

série continua crescendo e sofrendo constantes revisões.

A ISO/IEC 27000 [1] propriamente dita apresenta uma visão geral de Sistemas

de Gestão de Segurança da Informação (SGSI) e o vocabulário frequentemente usado

pelas normas dessa família, bem como descreve o escopo e o propósito de cada uma

delas. De acordo com essa norma introdutória [1], a norma ISO/IEC 27001 provê os

requisitos para o desenvolvimento e para a operação de um SGSI, incluindo o conjunto

de controles para a mitigação de riscos associados aos ativos de TI que a organização

visa proteger. As organizações que operam o SGSI podem ter suas conformidades

auditadas e certificadas por meio dessa norma. Já a ISO/IEC 27002 é um guia de

implementação de controles de segurança especificados pela ISO/IEC 27001.

A Figura 2.1 mostra uma linha do tempo com a origem das normas ISO 27001 e

ISO 27002, iniciando com a norma britânica BS7799.

Figura 2.1 – Linha do tempo com a origem das normas ISO 27001 e ISO 27002.

2.2 – Conceitos Básicos

Os principais termos utilizados, quando se trata de Segurança da Informação,

estão definidos abaixo, permitindo uma comunicação clara e uniforme por aqueles

interessados nesse assunto. O principal e mais importante deles é apresentado primeiro:

o que é informação?

7

2.2.1 – A Informação

A informação [1] é o principal elemento do processo de comunicação e é

complementado pelo emissor, pelo canal e pelo receptor. Estes elementos permitem que

a informação flua de um lado para outro.

É comum que a informação seja associada ao conhecimento. Porém, esse último

vai ser gerado em maior ou menor grau dependendo de quão bem o receptor absorve e

processa a informação. O emissor também desempenha um papel importante na geração

ou transmissão de conhecimentos, dependendo de quão clara é a forma com que se

expressa. Portanto, é possível, transmitir informação sem produzir conhecimento se pelo

menos uma das partes for falha em seu papel. Mas o contrário não é verdade: para

existir conhecimento, um indivíduo deve ser exposto à informação.

Nem sempre transmitir informação sem gerar conhecimento pode ser

considerado um fracasso. A transmissão de forma confusa pode ocorrer de maneira

intencional para atrapalhar o receptor em sua absorção e processamento da informação.

Se isso acontecer, seu objetivo será cumprido. Em situações investigativas, isso deve ser

levado em conta.

O grande valor da informação é o conhecimento que pode ser extraído dela e

utilizado em processos de inovação, em tomadas de decisão, em diferenciação de

produtos e de serviços, e em suporte a processos [10]. O resultado almejado pode ser a

geração de lucro, por exemplo, ou até mesmo a tomada de territórios em uma guerra.

Dada essa importância, a informação deve ser protegida e preservada por pessoas e

organizações que possam ser prejudicadas com o comprometimento dessa informação.

2.2.2 – Os Pilares da Segurança da Informação

A segurança da informação tem alguns princípios sobre os quais ela se sustenta;

são tópicos que determinam quando a segurança é considerada violada, seja

intencionalmente ou acidentalmente. Existem três princípios mais importantes:

confidencialidade, integridade e disponibilidade. Atualmente, outros princípios têm

entrado nessa lista, como autenticidade e privacidade.

8

2.2.2.1 – Confidencialidade

A confidencialidade é o primeiro dos pilares que sustentam a segurança da

informação. Esse princípio prega que somente pessoas autorizadas devem ter acesso às

informações protegidas [1] [10].

A quebra de confidencialidade pode ser feita por meio de engenharia social,

descoberta de senhas, invasão de sistemas, entre outros. Seja qual for o meio, a quebra

dela constitui um incidente de segurança da informação.

2.2.2.2 – Integridade

A integridade é o segundo dos pilares que sustentam a segurança da informação.

Esse princípio prega que a informação, após inserida no “sistema”, deve estar íntegra

quando consumida [1] [10], isto é, deve ser confiável e completa.

Alterações sem autorização ou a deterioração dos dados armazenados produzem

informação não confiável, constituindo um incidente de segurança da informação por

quebra de integridade.

2.2.2.3 – Disponibilidade

A disponibilidade é o terceiro dos pilares que sustentam a segurança da

informação. Esse princípio prega que a informação deve estar disponível sempre que

requisitada [1] [10].

Se, por algum motivo, a informação não pode ser acessada por pessoas

autorizadas, há um incidente de segurança da informação instaurado por

indisponibilidade.

2.2.2.4 – Autenticidade

O princípio da autenticidade é garantido quando a mensagem vem realmente da

fonte anunciada [1]. Esta é uma nova definição, não incluída nas primeiras edições da

ISO 27000, e faz parte de uma adaptação à evolução do uso da tecnologia da

informação.

A quebra desse princípio ocorre por fraude da propriedade que indica quem é o

autor da mensagem. Isso pode ser consequência de uma infração para prejudicar alguém

enquanto coloca a culpa em terceiros. Outra causa pode ser a tentativa de enganar um

9

usuário se passando por uma fonte confiável, eventualmente logrando sucesso em um

ataque.

2.2.2.5 – Não-repúdio

O princípio do não-repúdio preza pela capacidade de se provar a ocorrência de

um evento e seus autores [1]. Ele também é conhecido como princípio da

irretratabilidade.

Esta definição pode ser confundida com os princípios da autenticidade e da

integridade, pois a prova da ocorrência de um evento considera os dados confiáveis

(íntegros) e vindo da fonte anunciada. Porém, o não-repúdio foca na rastreabilidade do

evento, analisando quem acessou a informação, quando e como. Uma vez rastreado,

aquele que acessou a informação não poderá negar tê-lo feito.

Obviamente, isso parte da premissa que existe um mecanismo para atrelar um

dispositivo a um indivíduo de maneira a identificá-lo unicamente e isso ser reconhecido

pelas autoridades. Percebe-se que o cerne do conceito ultrapassa o âmbito tecnológico e

avança sobre o âmbito legal. No Brasil, a Infraestrutura de Chaves Públicas Brasileira

(ICP-Brasil) implementa esse mecanismo a nível nacional e dá validade jurídica a

transações eletrônicas [17] [18].

2.2.2.6 – Privacidade

Privacidade é a qualidade do que é pessoal e privado por direito. Naturalmente,

o que é público não é privado. Como é um conceito facilmente confundido com

confidencialidade [19] [20] [21], será explicado por meio de um exemplo.

De acordo com o artigo 5º, inciso XII da Constituição Federal [22] [23], é “[...]

inviolável o sigilo da correspondência e das comunicações telegráficas, de dados e das

comunicações telefônicas, salvo, no último caso, por ordem judicial [...]”. A privacidade

de um indivíduo não pode ser violada; é a garantia que ele possui por direito. Porém, se

for autorizado judicialmente, a quebra do sigilo poderá ser feita. Quando isso acontecer,

pode-se estabelecer a confidencialidade da escuta (informação) e, desta forma, somente

pessoas autorizadas poderiam ter acesso a ela – perceba que a informação deixou de ser

privada e passou a ser confidencial.

10

Enquanto privacidade tem a ver com o direito garantido por lei, a

confidencialidade está ligada à ética, ao que foi combinado entre as partes que

compartilham a informação [20] [21].

A violação da privacidade de um indivíduo ou organização sem a devida

autorização constitui um incidente de segurança da informação.

2.2.3 – Ativo de Tecnologia da Informação

A palavra “ativos” é usada em contabilidade para representar bens e direitos de

uma empresa, e possuem valores monetários que podem ser transformados em dinheiro

em algum momento. Um “ativo de TI” é um bem ou direito especificamente ligado à

tecnologia da informação.

A informação por si só é um ativo, mas como pode-se notar a partir de sua

definição, ela é intangível. Existem diversos outros ativos de TI que sustentam a

existência da informação, como mídias onde ela é persistida, equipamentos que

permitem a sua transmissão, indivíduos responsáveis por sua manutenção e utilização,

entre outros.

Com isso, pode-se classificar um ativo de TI em seis categorias principais,

conforme listadas abaixo:

• Informação

Ex.: documentos escritos, arquivos, transmissões audiovisuais,

conhecimento acumulado na mente de colaboradores, etc.

• Pessoa

Ex.: coordenador de um projeto, administrador de banco de dados, etc.

• Ambiente / Infraestrutura

Ex.: sala de servidores, salas de armazenamento, sala cofre, etc.

• Hardware

Ex.: servidores físicos, computadores pessoais, impressora, apostila, etc.

• Software

Ex.: de gestão, de controle de acesso, cliente de e-mail, servidor web, etc.

• Política

Normas e regras – ligadas à informação – sobre como se relacionar com

outras pessoas dentro e fora da organização, sobre implementar

processos para estruturar determinada operação, entre outras.

11

2.2.4 – Vulnerabilidade e Ameaça

Para definir vulnerabilidade, é preciso entender antes o que significa ameaça.

Ameaça é a característica de algo que tem potencial para comprometer a

segurança de um sistema ou de uma organização. As ameaças podem ser externas ou

internas à organização e, geralmente, não se tem controle sobre elas [1] [10].

A vulnerabilidade representa o quanto um ativo de TI está exposto à

determinada ameaça. Em outras palavras, representa a sua fraqueza. Esse sim – o ativo

vulnerável – está sob o controle da organização e pode estar mais protegido se

necessário [1] [10].

Idealmente, todos os ativos não teriam vulnerabilidades e as ameaças não teriam

como se concretizar através de falhas de segurança. Porém, existem diversas variáveis

envolvidas. Muitas vulnerabilidades são desconhecidas. Outras são bem conhecidas,

mas não recebem a devida atenção e o devido investimento da organização. O

importante é evitar o incidente e, se ele ocorrer, estar preparado para agir o mais

rapidamente possível.

2.2.5 – Vetor de Ataque

O vetor de ataque não é uma ameaça em si. Ele é o meio utilizado pelos

atacantes para invadir sistemas, obter informações sem autorização, ou espalhar

conteúdo malicioso sem uma finalidade específica.

Dentre as possibilidades, estão mensagens eletrônicas (o corpo da mensagem ou

seus anexos), uma página na Internet, uma aplicação web, um arquivo, um sistema com

falhas de segurança conhecidas, linguagens e bibliotecas de programação, etc.

2.2.6 – Incidente de Segurança

Do livro Sistema de Segurança da Informação [10], incidente de segurança “é a

ocorrência de um evento que possa causar interrupções ou prejuízos aos processos do

negócio, em consequência da violação de um dos princípios de segurança da

informação.”

Perceba que mesmo que um processo não sofra prejuízo, a possibilidade de ter

ocorrido já caracteriza um incidente [1]. Por exemplo, um sistema de autenticação pode

ter parado de funcionar durante a madrugada, em um momento em que nenhuma

tentativa de acesso aconteceu. Mesmo que nenhum cliente do sistema tenha sido

12

impactado, o evento caracteriza um incidente por indisponibilidade e deve ser

investigado para entender suas causas.

Já uma tentativa de ataque não caracteriza um incidente, mas sim um evento de

segurança da informação.

2.3 – Analisando os Riscos

Analisar os riscos que incidentes de segurança da informação causariam a uma

organização é fundamental para prover a proteção adequada aos ativos de TI. Uma

análise permite a aplicação de recursos de maneira inteligente, direcionando-os para

onde são mais relevantes. Além disso, auxilia no processo de autoconhecimento da

empresa ao relacionar todos os ativos e suas vulnerabilidades.

Os marcos de um procedimento de análise são detalhados abaixo.

2.3.1 – Estratégias de avaliação do risco

O passo inicial de uma análise é determinar a estratégia de sua execução.

Determinar a estratégia significa planejar antes de agir, significa ter algumas diretrizes

para a diminuição de riscos e uma metodologia para a avaliação da situação da

organização. Além disso, é importante definir os resultados esperados com a proteção

dos ativos. Fica mais difícil chegar quando não se sabe para onde se vai [10].

A título de exemplo, seguem abaixo algumas diretrizes hipotéticas que uma

organização pode adotar:

1. Riscos relacionados à disponibilidade são prioritários em relação àqueles

relacionados com confidencialidade e integridade.

2. Riscos acima de 80% devem ser tratados com caráter emergencial.

3. Riscos abaixo de 40% podem ser ignorados na primeira iteração.

4. Investimentos em segurança da informação não devem exceder em 5% o

faturamento da organização.

5. Investimentos em segurança da informação são tão maiores quanto for o

valor do processo de negócio envolvido.

Essas são algumas regras que dão um norte para a realização da análise. Sempre

que algum analista estiver saindo dos trilhos, ele será capaz de voltar às diretrizes e se

reorganizar.

13

Definir os resultados esperados é uma tarefa mais complexa, porque é difícil

medir o quanto pode-se beneficiar do investimento em segurança. Às vezes, é possível

inverter a lógica e tentar medir quanto seria perdido caso a organização sofresse um

incidente de segurança da informação. Por causa dessa dificuldade, é recomendado que

empresas que nunca fizeram uma análise de risco utilizem métodos qualitativos, em vez

de quantitativos [10]. O primeiro permitirá maior subjetividade e cálculos mais simples

em detrimento da precisão dos cálculos de custos e benefícios.

Este trabalho utiliza o método qualitativo por simplicidade, com o objetivo de

apresentar os conceitos sobre o tema. Isso não significa que um método é melhor que

outro. Cada organização deve avaliar o que se aplica melhor ao seu grau de maturidade.

As graduações são todas feitas de 1 a 5, como mostra a Tabela 2.1.

Tabela 2.1 – Graus de classificação para relevâncias e intensidades.

Valor nominal Grau Faixa percentual

1 Muito baixo 01-20

2 Baixo 21-40

3 Médio 41-60

4 Alto 61-80

5 Muito alto 81-100

2.3.2 – Levantamento da estrutura organizacional

Após a definição das regras, inicia-se o processo de levantamento das áreas da

organização e quais são os principais processos operantes (macroprocessos). A seguir, é

realizada uma análise profunda em cada macroprocesso para identificar os processos

que funcionam dentro dele. Por sua vez, são identificados os serviços de TI que apoiam

esses processos e, finalmente, os ativos de TI que suportam esses serviços.

Um exemplo pode ser dado com uma empresa automobilística hipotética. As

áreas seriam compostas por “Produção Industrial”, “Parcerias”, “Logística”,

“Departamento Pessoal” e “Inovação”. O macroprocesso “Exportar” poderia estar

contido tanto dentro da área de “Parcerias” quanto dentro de “Logística”. Uma estrutura

hipotética para esse macroprocesso é apresentada na Tabela 2.2.

14

Tabela 2.2 – Alguns processos, serviços e ativos hipotéticos do macroprocesso

“Exportar” de uma empresa do ramo automobilístico.

Processo Serviço de TI Ativo de TI

Receber material da linha de

produção

Sistema de controle de entrada

Servidor web

Servidor de impressão

Impressoras

Galpão de recepção

Recepcionistas

Sistema de triagem

Galpão de recepção

Esteiras automáticas

Máquinas leitoras de códigos de

barra

Despachar contêineres

Sistema de determinação de

rotas de transporte

Servidor web

Roteadores

Firewall

Sistema de identificação dos

caminhões e vans credenciados

Caminhões e vans

Pessoas da fiscalização

Servidor web

Se a organização ainda não possui esta estrutura documentada, é uma boa

oportunidade para fazer isso. Ela também será importante para a definição de escopo,

explicada mais adiante.

2.3.3 – Determinação de relevâncias

A relevância indica quanto um determinado elemento da estrutura

organizacional contribui, é importante ou tem valor para o nível imediatamente

superior.

Este levantamento deve ser feito do mais abrangente para o menos abrangente,

começando pelos processos. Assim, devem ser medidas:

• A relevância de um processo com relação à organização.

• A relevância de um serviço de TI com relação ao processo que apoia.

• A relevância de um ativo de TI com relação ao serviço que suporta.

Neste trabalho, as medições serão feitas de acordo com os graus qualitativos

descritos pela Tabela 2.1.

15

As relevâncias medidas serão importantes tanto para o item 2.3.4 – Definição de

escopo quanto para o item 2.3.6 – A análise.

2.3.4 – Definição de escopo

Em uma empresa pequena, pode ser viável pular este passo e analisá-la por

inteiro, de uma só vez. Porém, em uma empresa de maior porte, os trabalhos de análise

são mais complexos desde o início, ou seja, desde a fase de mapeamento da estrutura.

Definir um escopo pequeno inicialmente é fundamental para o sucesso da

operação, principalmente quando precisa-se ganhar maturidade na realização de análises

[10]. Isso permitirá perceber mais rapidamente as falhas que ocorrerem no processo de

análise e corrigi-las em uma escala menor, encurtando o ciclo PDCA (Plan, Do, Check,

Act)3.

O escopo pode ser definido escolhendo-se a área, o macroprocesso ou o

processo que exige mais atenção com relação à segurança da informação. Para isso,

pode-se utilizar as relevâncias obtidas no passo 2.3.3 – para atacar os processos de

maior valor para a organização – geralmente os que mais geram e consomem

informações. Responder à pergunta “Onde os danos seriam irreparáveis?” pode indicar

um bom ponto de partida.

Observe que os serviços e ativos de TI foram excluídos dessa etapa, pois o que

importa é o valor de negócio para a organização. Os serviços de TI atuam em conjunto

para apoiar um processo, mas não possuem valor de negócio se analisados sozinhos.

Depois de realizada a análise com sucesso em um escopo pequeno, deve-se

aumentar o escopo para abranger outras áreas, macroprocessos ou processos, mas nunca

abandonar aqueles que já foram abordados em análises anteriores.

2.3.5 – Identificação e classificação de ameaças e vulnerabilidades

Uma vez definido o escopo da análise, ficam estabelecidos todos os seus

participantes, indo do nível mais alto da estrutura organizacional, as áreas, até o mais

baixo, composto pelos ativos de TI.

Agora, deve-se identificar a quais ameaças a organização está exposta e

classificá-las quanto ao seu grau de intensidade. Essa classificação deve ser feita sem

3 PDCA é um método de gestão de qualidade utilizado para implantar um processo de melhoria

contínua. [37]

16

levar em consideração o ativo de TI que é alvo da ameaça em questão. Isso significa que

o grau da ameaça dependente unicamente dela [10].

Somente após saber quais são as ameaças presentes é possível determinar o grau

de vulnerabilidade dos ativos de TI. O procedimento deve ser feito nessa sequência

porque, apesar de a vulnerabilidade ser uma propriedade exclusiva do ativo, ela está

sempre associada a uma ameaça. Excepcionalmente, é possível que se descubra uma

ameaça ao averiguar as vulnerabilidades de um ativo.

Quando a análise for realizada, será possível notar que o grau da ameaça

permanece constante enquanto as vulnerabilidades variam de ativo para ativo. Isso

confirma que a ameaça é fixa para uma organização e que ela não depende do ativo que

tem como alvo.

Os graus definidos na Tabela 2.1 serão utilizados neste trabalho para classificar

ameaças e vulnerabilidades.

Segue abaixo, na Tabela 2.3, um exemplo de uma ameaça de grau muito alto

para uma organização, mas com diferentes graus de vulnerabilidade dos ativos.

Tabela 2.3 – Exemplo de vulnerabilidades de ativos em relação a crackers.

Ameaça: Cracker

Grau da ameaça Ativo de TI Grau da vulnerabilidade

Muito alto Servidor de aplicações Alto

Muito alto Servidor de banco de dados Baixo

Muito alto Firewall Muito alto

Muito alto Servidor de impressão Muito baixo

Uma situação foi criada para explicar cada um de seus valores.

A maior vulnerabilidade na tabela acima pertence ao firewall, pois é o ativo que

está na fronteira da organização com a Internet, passando por ele todas as requisições

que chegam e que saem de sua rede. Ao passar por esse componente, pode-se chegar ao

servidor de aplicações, onde rodam os principais serviços de TI. A vulnerabilidade do

servidor de aplicações é alta porque suas definições de antivírus estão desatualizadas,

mas não muito alta porque está atrás do firewall (que oferece uma proteção quanto ao

acesso de clientes externos). O servidor de banco de dados encontra-se ainda mais

17

protegido, já que somente aplicações internas e autorizadas possuem acesso a ele. Por

fim, o servidor de impressão tem a menor vulnerabilidade da escala por estar totalmente

limitado às comunicações internas e em uma rede segregada daquela que possui acesso

à Internet.

2.3.6 – A análise

Todos os passos desta seção, até então, foram requisitos para a realização da

análise de riscos. A análise consiste em efetuar cálculos a partir das classificações de

relevâncias, graus de ameaças e graus de vulnerabilidades determinados nos passos

anteriores. O resultado é um relatório com os graus de risco que um incidente de

segurança da informação causaria ao explorar a vulnerabilidade de cada ativo de TI.

O objetivo dessa análise é expor para os comitês de segurança (da organização)

quais são os pontos fracos que exigem investimentos mais urgentes, pois estão mais

vulneráveis e têm ao mesmo tempo alta relevância.

Porém, para obter esse resultado, é preciso saber como extrair um número que

represente o risco e, para isso, é preciso definir um conceito matemático para ele. Uma

forma simples de resolver isso, apresentada por André Campos [10], é relacionar o

impacto que um incidente causaria à organização com a probabilidade de esse incidente

ocorrer. Quanto menor a probabilidade, menor o risco. Quanto menor o impacto, menor

o risco. A fórmula R = I x P pode ser utilizada, onde R representa o risco, I é o impacto

estimado para um incidente e P a probabilidade do evento. Cada uma dessas variáveis

pode ter valor entre zero e um (inclusive).

Como o impacto representa o quanto de prejuízo seria gerado por um incidente

de segurança da informação, ele será tão maior quanto mais importante forem o

processo para a organização, o serviço para o processo e o ativo para o serviço em

questão. Para produzir um valor final entre 0 e 1 (inclusive), basta normalizar as

classificações dividindo por seus valores máximos.

𝐼𝑚𝑝𝑎𝑐𝑡𝑜 =𝑅𝑎

5 ×

𝑅𝑠

5 ×

𝑅𝑝

5

Onde Ra, Rs e Rp representam a relevância do ativo, a relevância do serviço e a

relevância do processo respectivamente.

18

Já a probabilidade de um incidente acontecer está diretamente relacionada à

vulnerabilidade existente em um ativo com relação a uma ameaça e ao quanto existe

dessa ameaça. Seguindo o mesmo raciocínio, e sabendo que a probabilidade também

varia entre 0 e 1 (inclusive), pode-se definir a probabilidade com a fórmula abaixo:

𝑃𝑟𝑜𝑏𝑎𝑏𝑖𝑙𝑖𝑑𝑎𝑑𝑒 = 𝐺𝑎

5 ×

𝐺𝑣

5

Onde Ga e Gv são grau de ameaça e grau de vulnerabilidade respectivamente.

A partir dessas definições, o risco pode ser expandido na seguinte fórmula:

𝑅𝑖𝑠𝑐𝑜 = ( 𝑅𝑎

5 ×

𝑅𝑠

5 ×

𝑅𝑝

5 ) × (

𝐺𝑎

5 ×

𝐺𝑣

5 )

O resultado da análise será uma grande tabela, onde cada linha representará uma

combinação de processo, serviço, ativo e ameaça. Consequentemente, cada linha

conterá o produto indicado pela fórmula de risco.

2.3.7 – A avaliação

Após a análise ter sido realizada, basta interpretar os dados de acordo com as

diretrizes especificadas pela estratégia de avaliação.

Para facilitar a avaliação, os resultados deverão ser ordenados do maior risco

para o menor. Quando houver empate e não for possível atender às duas situações de

risco, a preferência deverá ser daquela de maior impacto. Idealmente, ambas seriam

tratadas.

O tratamento para a redução do risco deverá ser feito eliminando

vulnerabilidades, porque geralmente nada pode ser feito para diminuir o quanto existe

de cada ameaça – exceto quando fatores internos constituem ameaças. Chama-se de

controle mitigatório o tratamento dado aos ativos com o intuito de eliminar ou reduzir

vulnerabilidades [1].

Um exemplo de controle mitigatório é a instalação de uma unidade UPS

(Uninterruptible Power Supply) para prover energia reserva a servidores físicos quando

ocorrer uma falha no fornecimento de energia em uma determinada região.

• Ativo: Servidor da Marca X – Modelo Y – Número de série ABC

19

• Vulnerabilidade: Alta sensibilidade a surtos e queda de tensão

• Ameaça: Queda de energia

• Controle: UPS

Após serem definidos os controles que serão aplicados para reduzir o risco de

incidentes de segurança e após serem estimados os investimentos demandados desses

controles, esta avaliação chegará ao fim. Um novo escopo poderá ou deverá ser definido

e uma nova análise poderá ou deverá ser realizada.

20

Capítulo 3 –

Modelagem

Antes de apresentar a modelagem, é importante lembrar o objetivo do sistema

proposto por este trabalho, que é implementar uma ferramenta que possa ser utilizada

para implantar um SGSI, fornecendo um relatório de análise de riscos em segurança da

informação a partir da entrada de dados sobre uma organização. Essa ferramenta é

apenas parte do SGSI e, por si só, não satisfaz aos requisitos de conformidade exigidos

pela norma ISO/IEC 27001 [24].

A fase de modelagem está dividida em requisitos de negócio, requisitos técnicos,

modelo de dados e permissões de acesso.

3.1 – Requisitos de negócio

Os requisitos abaixo definem o mínimo de funcionalidades que a ferramenta

deverá ter, levando-se em consideração os conceitos básicos e a metodologia

apresentados em “Fundamentação Teórica”. Posteriormente, serão expostas as

propriedades pertinentes a cada uma das entidades principais.

3.1.1 – Funcionalidades

O sistema deverá ser capaz de:

1. Permitir cadastrar organizações.

2. Permitir elencar toda a estrutura de uma organização: Áreas,

Macroprocessos, Processos, Serviços de TI e Ativos de TI.

3. Permitir estabelecer relacionamentos entre elementos de níveis adjacentes na

estrutura de uma organização, como mostrado abaixo:

a. Áreas ↔ Macroprocessos

b. Macroprocessos ↔ Processos

c. Processos ↔ Serviços de TI

d. Serviços de TI ↔ Ativos de TI

4. Permitir registrar a relevância de um elemento para a estrutura à qual

pertence, de acordo com o papel que desempenha. As opções são:

21

a. Relevância do processo com relação ao negócio da organização.

b. Relevância do serviço de TI com relação ao processo que ele apoia.

c. Relevância do ativo de TI com relação ao serviço de TI que ele

suporta.

5. Impedir que existam duas áreas iguais em uma mesma organização.

6. Permitir que macroprocessos, processos, serviços de TI e ativos de TI sejam

reutilizados em uma mesma organização, mas não dentro do mesmo

segmento. Como exemplo, um processo pode existir em dois

macroprocessos diferentes, mas não pode existir duas vezes dentro de um

mesmo macroprocesso.

7. Permitir que áreas, macroprocessos, processos, serviços de TI e ativos de TI

já cadastrados por uma organização estejam disponíveis para outras

organizações.

8. Permitir cadastrar ameaças aos ativos de uma organização.

9. Permitir utilizar ameaças já cadastradas por outras organizações.

10. Permitir cadastrar o grau de cada ameaça para a organização.

11. Permitir cadastrar o grau de vulnerabilidade de cada ativo de TI de uma

organização em relação a uma ameaça cadastrada para essa mesma

organização.

12. Permitir cadastrar controles mitigatórios para cada ativo de TI de uma

organização.

13. Permitir utilizar controles mitigatórios já cadastrados por outras

organizações.

14. Ser capaz de realizar análises de riscos sob demanda. Cada análise deve ser

imutável, isto é, uma vez feita, os parâmetros dos cálculos e os valores

resultantes não podem ser modificados. As análises podem ter o mesmo

escopo ou escopos diferentes.

15. Permitir visualizar qualquer um dos dados citados nos itens acima.

16. Permitir corrigir qualquer um dos dados citados nos itens acima, exceto o

resultado de uma análise.

17. Autenticar seus usuários, mantendo o rastreamento dos eventos e garantindo

que somente pessoas autorizadas o utilizem.

22

3.1.2 – Dados das entidades

Estão listados abaixo os dados básicos que cada entidade deve possuir.

Organização

• Número de registro no Cadastro Nacional da Pessoa Jurídica (CNPJ)

• Nome empresarial

• Nome fantasia (opcional)

Área / Macroprocesso / Processo / Serviço de TI

• Nome

Ativo de TI

• Nome

• Descrição (opcional)

• Categoria de Ativo de TI

Categoria de Ativo de TI

• Identificador

• Nome

Os valores possíveis para categoria são:

1. Informação

2. Política

3. Pessoa

4. Ambiente / Infraestrutura

5. Hardware

6. Software

Ameaça / Controle Mitigatório

• Nome

• Descrição (opcional)

23

3.2 – Requisitos técnicos

A única restrição técnica do sistema é que ele deverá ser capaz de funcionar nos

servidores do Departamento de Eletrônica e de Computação (DEL) da Universidade

Federal do Rio de Janeiro (UFRJ). Isso significa que deverá ser compatível com o

sistema operacional FreeBSD versão 11.x ou superior. Portanto, todas as suas

dependências deverão ser escolhidas de maneira que também atendam a essa restrição.

3.3 – O modelo de dados

O modelo de dados será criado a partir das funcionalidades requisitadas e dos

dados básicos já especificados na seção 3.1.2 – Dados das entidades. A seguir, será

justificada a escolha da estrutura relacional para modelagem e, posteriormente, será

apresentada a modelagem propriamente dita.

3.3.1 – A escolha da estrutura de dados relacional

O paradigma entre escolher uma estrutura de dados relacional ou não, impacta

diretamente em como a modelagem será realizada.

A estrutura relacional direciona a decisão para uma tecnologia estabelecida há

mais tempo no mercado, abrangendo todos os sistemas de gerenciamento de banco de

dados (SGBD) que utilizam a linguagem SQL (Structured Query Language) para

consultas. Nessa estrutura, os dados são representados através de tabelas que podem ser

relacionadas entre si.

A estrutura não-relacional leva a uma gama de SGBDs classificados como

NoSQL – o nome vem da não utilização da linguagem SQL. Porém, a linguagem de

acesso aos dados não é a única diferença desses sistemas para os relacionais. Suas

formas de manipular e armazenar os dados são bem diversificadas entre si. Devido à

grande quantidade de SGBDs NoSQL que surgiram recentemente, acabou-se criando

categorias adicionais para eles baseadas na estrutura de dados que armazenam. Alguns

exemplos de categoria são: orientado a documentos, orientado a colunas e baseado em

grafos.

Será utilizado neste trabalho um SGBD relacional, dado o intenso uso de

relacionamentos para descrever a estrutura de uma organização. Além disso, a estrutura

não tende a assumir diferentes formas de acordo com seu conteúdo, o que é apropriado

24

para uma modelagem em tabelas. A partir dessa decisão, serão criados os Diagramas

Entidade-Relacionamento (conhecido em inglês como ERD – Entity Relationship

Diagram) – forma padrão de representar como as entidades se relacionam, quais são as

cardinalidades desses relacionamentos etc., independente do provedor de SGBD

escolhido.

Está fora do escopo deste estudo esgotar os prós e contras de cada tecnologia.

Existem muitas diferenças entre elas e, certamente, outras soluções seriam aplicáveis a

este projeto.

3.3.2 – Levantamento das entidades e relacionamentos

O modelo poderá ser dividido em quatro contextos: um para o catálogo; um para

as estruturas das organizações; um para ameaças, vulnerabilidades e controles; e outro

para as análises das organizações.

A entidade mais forte do banco de dados é a que contém os registros das

organizações. Essa tabela será “proprietária” dos relacionamentos que caracterizarão a

estrutura da organização, com áreas, macroprocessos, etc.

O catálogo servirá para permitir que áreas, macroprocessos, processos, serviços

de TI, ativos de TI, ameaças e controles mitigatórios sejam reutilizados entre

organizações.

A partir das premissas acima, tabelas associativas serão empregadas para criar os

relacionamentos muitos-para-muitos (cardinalidade M:N) entre uma entidade do

catálogo e um nível estrutural de uma organização. Elas permitirão, por exemplo, que

um processo esteja em mais de um macroprocesso e que um macroprocesso contenha

múltiplos processos. Algumas dessas tabelas associativas conterão também as

relevâncias dos relacionamentos.

Sendo assim, ficam determinadas todas as entidades conforme mostrado abaixo

pela Tabela 3.1 – Lista de entidades.

Duas tabelas de domínio precisarão existir para completar a lista acima. Uma

para categoria de ativo de TI, outra para a escala de relevância ou de intensidade.

• “it_asset_category” – Domínio das categorias de ativo disponíveis.

• “rating_level” – Domínio de escala para classificar relevâncias, ameaças

e vulnerabilidades.

25

Tabela 3.1 – Lista de entidades

Entidade Descrição

organization Catálogo de organizações

business_department Catálogo de áreas

business_macroprocess Catálogo de macroprocessos

business_process Catálogo de processos

it_service Catálogo de serviços de TI

it_asset Catálogo de ativos de TI

security_threat Catálogo de ameaças

mitigation_control Catálogo de controles mitigatórios

organization_department Conecta áreas a organizações

organization_macroprocess Conecta macroprocessos a áreas

organization_process Conecta processos a macroprocessos e define a

relevância de cada processo para a organização à qual

pertence.

organization_it_service Conecta serviços de TI a processos e define a relevância

de cada serviço para o processo correspondente.

organization_it_asset Conecta ativos de TI a uma organização e permite

identificar unicamente a instância de cada ativo.

organization_it_service_it_asset Conecta ativos de TI a serviços de TI e define a

relevância de cada ativo para o serviço correspondente.

organization_security_threat Conecta ameaças catalogadas a organizações e define o

grau de cada ameaça.

organization_it_asset_vulnerability Conecta ativos de TI de uma organização a ameaças da

mesma organização e define o grau da vulnerabilidade

de cada ativo para cada ameaça.

organization_it_asset_control Conecta ativos de TI de uma organização a controles

mitigatórios do catálogo.

organization_analysis Instâncias de análise por organização

organization_analysis_detail Armazena os detalhes de uma análise (parâmetros de

cálculo e os valores computados de impacto,

probabilidade e risco).

A Figura 3.1 mostra como as tabelas se relacionam para construir a estrutura de

uma organização.

26

Figura 3.1 – Diagrama Entidade-Relacionamento da organização e sua estrutura.4

4 Foram omitidas as linhas de relacionamento das tabelas associativas para com a organização com o intuito de evitar poluição visual.

27

Observe que existem duas tabelas de ativos de TI com cardinalidade M:N,

“organization_it_asset” e “organization_it_service_it_asset”. Isso decorre da

necessidade de uma mesma instância de um ativo poder ter relevância diferente para

cada serviço de TI que apoia. Por exemplo, um computador de número de série A123 é

ao mesmo tempo servidor de impressão e servidor web de uma organização. Se não

houvesse a separação nessas duas tabelas, a máquina A123 deveria ser cadastrada duas

vezes para poder colocar relevâncias diferentes em relação aos serviços, o que

dificultaria a identificação dela como sendo um único ativo da organização. Seria tão

inadequado quanto ter que cadastrar uma pessoa duas vezes na mesma academia porque

ela quer realizar duas atividades diferentes, como natação e luta. A tabela

“organization_it_asset” resolve esse problema ao inserir ativos na organização, sem

pensar neste instante em relacionamentos com serviços. Com isso, torna-se possível a

listagem de todos os ativos da organização sem duplicações de registros. O ativo torna-

se, então, único na organização – mas não entre organizações.

Prosseguindo com a modelagem para o contexto de ameaças e vulnerabilidades,

mostra como elas se relacionam com os ativos de uma organização e com a própria

organização.

É possível notar, na Figura 3.2, que a vulnerabilidade de um ativo é apenas uma

classificação em relação a uma ameaça, por isso não existe um catálogo de

vulnerabilidades. A modelagem também permite criar múltiplos controles para diminuir

determinada vulnerabilidade. Como o controle é aplicado a ativos, e não às suas

vulnerabilidades, foi criado um relacionamento de cardinalidade M:N entre ativo da

organização e controle mitigatório do catálogo.

Por fim, duas tabelas permitem armazenar as análises de risco. Uma delas possui

todas as combinações possíveis derivadas da fórmula que calcula os riscos de

incidentes. A outra funciona como agregadora dessas combinações para representar uma

instância de análise. Elas foram listadas na Tabela 3.1 e podem ser visualizadas na

Figura 3.3.

28

Figura 3.2 – Diagrama Entidade-Relacionamento que representa as ameaças da organização, as vulnerabilidades dos ativos e os

controles aplicados sobre eles.

29

Figura 3.3 – Diagrama Entidade-Relacionamento que representa as análises.

3.4 – Requisito técnico extra

Dado que o modelo de dados é relacional, o banco de dados deve suportar

transações para que a atomicidade de uma operação de escrita seja garantida quando

mais de uma entidade for afetada. Trata-se de uma das propriedades do conceito ACID

– Atomicidade, Consistência, Isolamento e Durabilidade (em inglês Atomicity,

Consistency, Isolation, Durability).

3.5 – Permissões de acesso

O sistema deverá ter um escopo de acesso diferenciado para cada perfil de

usuário. Isso será definido por meio de papéis e permissões. Os papéis são

agrupamentos de permissões comuns a um grupo de usuários que desempenham uma

função específica e limitada. Existirão quatro papéis inicialmente, conforme descritos

abaixo:

• Administrador – Controle total. Pode executar todas as funcionalidades

que o sistema oferece.

30

• Gerente de organizações – Controle total sobre dados de organizações,

incluindo sua estrutura e suas análises. Não pode alterar dados de

catálogo, apenas criar novas entradas.

• Analista – Controle total sobre as estruturas das organizações e de suas

análises. Não pode alterar os dados de catálogo nem aqueles sobre a

organização, apenas criar novas entradas ou novas organizações.

• Visitante – Somente leitura. Acessa todos os dados do sistema, mas não

pode realizar nenhuma modificação.

Na Tabela 3.2 abaixo, estão listadas as permissões de cada papel.

Tabela 3.2 – Tabela de papéis e permissões do sistema.

Papel Permissões

Administrador

Visualizar catálogo

Criar entradas no catálogo

Atualizar entradas do catálogo

Remover entradas do catálogo

Visualizar organizações

Criar organizações

Atualizar dados sobre as organizações

Remover organizações

Gerenciar a estrutura das organizações

Visualizar análises

Criar análises

Atualizar dados sobre as análises

Excluir análises

Gerente de organizações





Atualizar dados sobre as organizações

Remover organizações



Criar análises


Excluir análises

31

Papel Permissões

Analista







Criar análises


Visitante




32

Capítulo 4 –

Implementação

O sistema foi dividido em dois módulos: back-end e front-end. O primeiro

trabalha as validações de entrada e acessa o banco de dados, e o segundo provê uma

interface gráfica para o usuário final. Os critérios de escolha das tecnologias utilizadas

em cada um e suas implementações serão detalhadas a seguir.

4.1 – Critérios de escolha das tecnologias

A tecnologia utilizada para desenvolver um sistema deve ser um meio para

alcançar seus objetivos. Ela não deve ser escolhida de acordo com a moda ou de

maneira aleatória. Alguns fatores para se levar em consideração no processo de escolha

das tecnologias são:

• Requisitos de desempenho

• Preços das ferramentas de desenvolvimento

• Licenças de bibliotecas

• Suporte do fabricante ou da comunidade

• Documentação

• Domínio da tecnologia pelo time de desenvolvimento

O desempenho não é uma preocupação para um primeiro momento. Dado que a

ferramenta será utilizada pela própria organização que deseja implantar um SGSI ou por

uma empresa contratada para tal, ela não receberá um número alto de requisições

simultaneamente. A maior probabilidade de ocorrer lentidão é durante uma análise, pois

um número elevado de ativos e serviços de TI pode levar a um grande número de

combinações a calcular. Porém, a análise faz parte de um processo maior de avaliação

humana, resultando em interações mais esparsas com o sistema. É importante notar que

o desempenho não é um indicador de sucesso deste trabalho. Apenas quando este se

tornar um problema, existirá um motivo para realizar a otimização.

Para este projeto, foram escolhidas ferramentas e bibliotecas gratuitas, com

licenças permissivas. Serem ativamente suportados pelos fabricantes e com alta adesão

33

comunidade foram outros critérios utilizados na escolha. Dessa forma, pode-se contar

com dependências maduras e estáveis.

Todas as dependências que não possuíam uma documentação clara e completa

foram descartadas no processo de escolha. Até mesmo as dependências de código aberto

precisam ser bem documentadas, pois uma documentação bem feita e atualizada poupa

tempo de desenvolvimento e torna o produto mais fácil de usar.

Quanto ao domínio de tecnologias, o autor possuía experiências profissionais

com as linguagens C++ e C#, com desenvolvimento de APIs (Application Programming

Interface), com modelagem de banco de dados e com o SGBD Microsoft SQL Server.

Academicamente, já havia tido contato também com as linguagens C, Perl e

programação de aplicativos Android em Java. Porém, o mesmo decidiu realizar o

projeto em Python, uma linguagem que não conhecia, e que é apropriada para

desenvolvimento rápido e prototipagem de ideias.

4.2 – O banco de dados

Conforme determinado em 3.3 – O modelo de dados, o banco de dados deve

suportar primariamente a estrutura de dados relacional.

O SGBD selecionado para o projeto foi o MySQL Community Edition,

atualmente pertencente à Oracle Corporation. Ele é gratuito, possui código aberto e está

sendo ativamente evoluído. Segundo o website DB-Engines [25] [26], ele tem

significativa adesão da comunidade, sendo o segundo mais popular dos 138 bancos

relacionais listados, atrás do Oracle e à frente do Microsoft SQL Server. A segunda

opção gratuita mais popular é o PostgreSQL, que também atende aos requisitos do

projeto [27], mas não foi escolhido pelo fato de ser ligeiramente mais complexo de

configurá-lo.

O MySQL disponibiliza alguns mecanismos diferentes de armazenamento

durante sua instalação para usar como padrão na criação de tabelas. Deverá ser

escolhido aquele chamado InnoDB, pois é o que suporta transações e relacionamentos

entre tabelas utilizando chaves estrangeiras. Na versão 5.7, que é a utilizada neste

projeto, o InnoDB já é o mecanismo de armazenamento padrão do MySQL.

O script de criação das tabelas encontra-se no Apêndice C.

34

4.3 – O back-end

O back-end é o principal componente da solução, pois é nele que está contido

todo o conjunto de funcionalidades e é por onde passa toda solicitação de acesso a

dados. Isso significa que, se bem construído, o SGBD ou a interface gráfica poderiam

ser substituídos sem modificações significativas no back-end.

Para implementá-lo, foi desenvolvida uma API em Python 3.6, que recebe

requisições utilizando o protocolo Hypertext Transfer Protocol (HTTP). As mensagens

são trafegadas no formato JavaScript Object Notation (JSON).

Este componente foi batizado de knoweak API pelo autor. A origem foi

inspirada pela política de conhecimento de clientes, fornecedores e parceiros, exigida de

instituições de pagamentos para que monitorem e alertem as autoridades competentes

sobre suspeitas de fraude e de lavagem de dinheiro. Essas políticas são conhecidas,

respectivamente, pelos termos em inglês Know Your Customers (KYC), Know Your

Suppliers (KYS) e Know Your Partners (KYP). Com base nesse conhecimento, o autor

decidiu cunhar o termo Know Your Weaknesses e a contração dele, “knoweak”, como

referência a um sistema que permite conhecer as fraquezas de uma organização.

4.3.1 – O design da API

Como a própria sigla sugere, API é uma interface para programadores

interagirem com o sistema. Toda boa interface faz uma separação de fronteiras

adequada e oferece funcionalidades que são simples de serem utilizadas, muitas vezes

até intuitivas. Para alcançar esse objetivo aqui, é importante definir convenções e

práticas que serão utilizadas.

A API segue as práticas recomendadas pelo estilo arquitetural Representational

State Transfer (REST) [28]. Algumas dessas práticas são [29]:

• Criar uma identificação única para cada recurso5, fazendo uso de

substantivos.

• Utilizar verbos HTTP (GET, POST, etc.) apropriados de acordo com a

ação desejada.

5 Segundo o criador do estilo arquitetural REST, Roy Thomas Fielding, recurso é uma abstração

chave da informação. Qualquer informação que possa ser nomeada pode ser um recurso, por exemplo,

uma pessoa, a geolocalização de um centro empresarial ou a cotação de uma moeda. [28]

35

• Devolver um código de resposta HTTP adequado ao resultado de cada

operação.

4.3.1.1 – Ideias gerais sobre os recursos

Um recurso é a representação de uma informação. Segundo Roy Thomas

Fielding, é um mapeamento conceitual para um conjunto de entidades, e não a entidade

propriamente dita que corresponde a esse mapeamento.

Sobre um recurso, podem ser executadas ações, e assim pode-se implementar as

funcionalidades especificadas em “Requisitos de negócio”. Essas ações serão

representadas pelos verbos HTTP e cada recurso terá um conjunto diferente de ações

disponíveis, de acordo com as necessidades especificadas.

Geralmente, cada entidade possui dois recursos: um que representa um item

individual, e outro que representa uma coleção de itens. Por exemplo, para obter uma

lista de organizações cadastradas, executa-se uma ação de leitura sobre o recurso

“organizações”. Agora, para obter os dados de uma organização específica, executa-se

uma ação de leitura sobre o recurso “organização” (observe o singular) e informa-se o

identificador da organização desejada. Em vez de chamar cada recurso por seus nomes,

utiliza-se uma forma comum de se identificar recursos de uma API, chamado Uniform

Resource Identifier (URI). Segue como identificar com URIs os recursos do exemplo

acima:

• /organizations – Coleção de organizações

• /organizations/:id – Organização identificada por um código

Juntando o verbo HTTP, pode-se definir as seguintes funcionalidades sobre as

organizações:

• GET /organizations – Obtém uma lista de organizações

• POST /organizations – Cadastra uma nova organização

• GET /organizations/:id – Obtém uma única organização identificada pelo

parâmetro “id”

• PATCH /organizations/:id – Atualiza os dados de uma organização

identificada pelo parâmetro “id”

36

Observe que, mesmo quando a ação ocorre sobre uma única organização, o

nome do recurso continua no plural. Isso é coerente se observado da ótica que uma

organização está inserida em uma coleção delas. Observe também uma fluidez na

leitura, quase formando uma frase no imperativo – “GET /organizations/27” pode ser

lido como “Obtenha a organização cujo identificador é 27” ou “Obtenha da lista de

organizações o elemento identificado pelo número 27”. Esses conceitos se repetem para

todos os outros recursos e refletem as práticas recomendadas pelo estilo arquitetural

REST.

Dar nome aos recursos é uma arte e vai ser tão melhor quanto for o

entendimento da(s) entidade(s) que se deseja representar. O estilo arquitetural REST se

debruça sobre o protocolo HTTP para isso, e a regra geral é que nenhum recurso deve

possuir verbo em seu URI. Isso difere do formato utilizado em Remote Procedure Call

(RPC), onde “POST /organizations” se transformaria em “addOrganization(data)”.

Até agora foram abordados os seguintes tópicos sobre um recurso: conceito, a

arte de identificá-lo, os tipos coleção e item individual, e a dependência do verbo HTTP.

É possível perceber, porém, que a ação de criar uma organização exige que mais dados

sejam enviados para o servidor. Afinal, ele precisa saber qual o número de registro e o

nome empresarial que devem ser armazenados, pelo menos. Essas informações são

enviadas no corpo de uma requisição HTTP como um objeto JSON, e representa o

estado do recurso. Pode-se, posteriormente, ler ou alterar o estado desse recurso.

4.3.1.2 – Convenção sobre os verbos HTTP

Apesar de existir uma convenção informal na comunidade de desenvolvedores

de APIs sobre o uso dos verbos HTTP em APIs REST, há muitas discussões acerca do

seu uso correto e, algumas vezes, até limitações técnicas para implementá-los da

maneira recomendada – por exemplo, o verbo PATCH não é facilmente implementável

em C# .NET. Não há certo ou errado, o importante é ser coerente dentro do contexto em

que se está trabalhando e definir a semântica utilizada para que os clientes consigam ter

previsibilidade do comportamento do sistema a partir de uma amostra dele. Por isso,

está definida abaixo a semântica dos verbos para o componente de back-end

desenvolvido neste trabalho.

• POST – Utilizado para criar recursos.

37

• GET – Utilizado para realizar consultas em um recurso. Essas operações

não provocam alteração do estado do recurso no servidor.

• PATCH – Utilizado para realizar modificações parciais em um recurso,

atualizando somente os dados solicitados na requisição.

• PUT – Utilizado para substituir completamente o estado de um recurso

por um novo, que é informado na requisição.

• DELETE – Utilizado para remover ou tornar indisponível um recurso no

servidor.

4.3.1.3 – Códigos de resposta HTTP

Os códigos de resposta HTTP (em inglês, Status Code) utilizados pela

ferramenta e seus significados estão apresentados na Tabela 4.1.

Tabela 4.1 – Códigos de resposta HTTP utilizados pela API.

Status Code Descrição

200 (OK) Operação realizada com sucesso.

201 (Created) Recurso criado com sucesso.

400 (Bad Request) Sintaxe inválida.

404 (Not Found) Recurso não encontrado.

422 (Unprocessable Entity) Erros de validação (dados ou semântica inválidos).

500 (Internal Server Error) Ocorreu um erro inesperado no servidor.

Quando um recurso for criado com sucesso, além do código de resposta 201

(Created), será retornado também o cabeçalho “Location” preenchido com o caminho

relativo do recurso criado. Esta é uma forma de indicar para o usuário onde ele pode

encontrar o recurso que acabou de ser criado.

4.3.1.4 – Recursos disponíveis

Na Tabela 4.2, estão listados os recursos disponíveis e as ações suportadas por

cada um. Os substantivos que identificam os recursos estão em inglês, assim como todo

38

o código fonte do sistema. Os parâmetros são prefixados por dois pontos e devem ser

substituídos pelos valores apropriados durante o uso.

Tabela 4.2 – Relação das identificações dos recursos e dos verbos HTTP

disponíveis para cada um.

Recurso Verbos suportados

/departments GET, POST

/departments/:id GET, PATCH

/macroprocesses GET, POST

/macroprocesses/:id GET, PATCH

/processes GET, POST

/processes/:id GET, PATCH

/itServices GET, POST

/itServices/:id GET, PATCH

/itAssets GET, POST

/itAssets/:id GET, PATCH

/itAssetCategories GET, POST

/itAssetCategories/:id GET, PATCH

/securityThreats GET, POST

/securityThreats/:id GET, PATCH

/mitigationControls GET, POST

/mitigationContorls/:id GET, PATCH

/organizations GET, POST

/organizations/:id GET, PATCH

/organizations/:id/departments GET, POST

/organizations/:id/departments/:departmentId GET, DELETE

/organizations/:id/macroprocesses GET, POST

/organizations/:id/macroprocesses/:instanceId GET, DELETE

/organizations/:id/processes GET, POST

/organizations/:id/processes/:instanceId GET, PATCH, DELETE

/organizations/:id/itServices GET, POST

/organizations/:id/itServices/:itServiceInstanceId GET, PATCH, DELETE

/organizations/:id/itServices/:itServiceInstanceId/itAssets GET, POST

/organizations/:id/itServices/:itServiceInstanceId/itAssets/:itAssetInstanceId PATCH, DELETE

/organizations/:id/itAssets GET, POST

/organizations/:id/itAssets/:instanceId GET, PATCH, DELETE

/organizations/:id/itAssets/:instanceId/vulnerabilities GET, POST

/organizations/:id/itAssets/:instanceId/vulnerabilities/:threatId GET, PATCH, DELETE

39

Recurso Verbos suportados

/organizations/:id/itAssets/:instanceId /controls GET, POST

/organizations/:id/itAssets/:instanceId /controls/:controlId DELETE

/organizations/:id/securityThreats GET, POST

/organizations/:id/securityThreats/:threatId GET, PATCH, DELETE

/organizations/:id/analyses GET, POST

/organizations/:id/analyses/:analysisId GET, PATCH

/organizations/:id/analyses/:analysisId/details GET

/version GET

/healthCheck GET

4.3.2 – A escolha do framework web

Existem diversos frameworks para se construir uma API em Python. Apenas

para exemplificar, alguns deles são: Django, Flask, Falcon, Sanic, Bottle e Hug.

Eles são responsáveis por receber requisições HTTP e direcionar para o método

dedicado a processar a aquela ação. Para isso, esses frameworks contam com

mapeamento de rotas, que ligam Uniform Resource Identifiers (URI) a funções em

Python.

O escolhido para este projeto foi o Falcon 1.4.1, por ser uma implementação

minimalista, com poucas abstrações e por ser uma das que fornecem melhor tempo de

resposta [30] [31]. Apesar de desempenho não ser um alvo deste trabalho, é relevante

escolher dependências que façam uso inteligente dos recursos de hardware.

O Falcon força a aderência ao estilo REST, pois cada recurso deve ser

representado por uma classe e, para cada ação passível de ser executada sobre o recurso,

existirá um método dessa classe que tratará a solicitação. Os nomes desses métodos

seguem uma convenção ligada aos verbos HTTP – on_get, on_post, on_delete, etc. – e

são chamados de responders pelos desenvolvedores do Falcon. Assim, basta associar

uma classe a uma URI para que o framework direcione automaticamente a solicitação

para a função apropriada.

Na Figura 4.1 abaixo, é exemplificado como utilizar o Falcon para implementar

um recurso que responda à solicitação GET /healthCheck. Essa operação testa se a

aplicação consegue se comunicar com suas principais dependências. Em caso de

sucesso, é retornado o status HTTP 200 (OK) e nenhum conteúdo na resposta. Em caso

40

de falha, é retornado o status HTTP 207 (Multi-status) e uma lista de componentes com

erro. Atualmente, apenas a conectividade com o banco de dados é avaliada.

Figura 4.1 – Código de exemplo para implementação de um recurso de uma

API utilizando o framework Falcon.

4.3.2.1 – Sobre a serialização de dados

Em Python, é utilizada a estratégia de nomenclatura snake_case para dar nomes

a variáveis, a métodos e às propriedades de um dicionário. Essa estratégia utiliza

caracteres em caixa baixa e o caractere underscore para separar palavras (ex.: car,

my_car, home_address).

Em APIs que utilizam contratos de dados em JSON, é mais comum utilizar a

convenção aplicada à linguagem JavaScript, chamada camelCase. Nesse formato, as

palavras são escritas sem separações e com todas as iniciais em maiúsculo, exceto a

primeira (ex.: car, myCar, homeAddress).

Para atender às duas convenções, deveria haver uma conversão de um formato

para outro, isto é, quando uma mensagem trafegada pela rede em JSON chegar à API,

ela deve ser convertida para o padrão utilizado pelas variáveis em Python. O processo

inverso deve ocorrer quando a API emitir uma resposta.

import falcon

class HealthCheck:

def on_get(self, req, resp):

errors = []

test_database(errors)

if not errors:

resp.status = falcon.HTTP_OK

return

resp.status = falcon.HTTP_MULTI_STATUS

resp.media = {

'components': errors

}

api = falcon.API()

api.add_route('/healthCheck', HealthCheck())

41

Por padrão, os frameworks web em Python (des)serializam6 os dados de entrada

e saída no mesmo formato usado pela linguagem, o snake_case. O Falcon não possui a

capacidade de fazer a conversão nativamente, mas ele dispõe de configurações que

permitem interceptar a mensagem que chega e manipulá-la antes de chegar ao

responder. O mesmo pode ser feito após o responder retornar e imediatamente antes de

a API enviar a resposta para o cliente. Assim, a solução foi implementada pelo autor por

meio dessas interceptações e com o auxílio de uma biblioteca chamada “inflection”

[32]. A biblioteca “inflection” é capaz de converter um texto de camelCase para

snake_case. Já para o sentido contrário, a transformação foi feita sem o auxílio da

biblioteca, por meio de funções criadas pelo próprio autor.

4.3.2.2 – Sobre a comunicação com o banco de dados

Para se conectar ao banco de dados e realizar consultas, foi utilizada a biblioteca

SQLAlchemy. Esta é uma ferramenta de mapeamento entre objetos Python e seus

modelos relacionais correspondentes, e se insere na classe de ferramentas conhecidas

como Object-Relational Mapping (ORM). A própria ferramenta é quem gera as

instruções SQL a partir de chamadas de funções e as envia para o SGBD

posteriormente.

O benefício de se utilizar um ORM é a velocidade no desenvolvimento e a

abstração do fornecedor de SGBD SQL. O SQLAlchemy possui conectores com

diversos SGBDs e possui o dialeto correspondente para cada um deles. Portanto, mesmo

que a sintaxe do PostgreSQL seja ligeiramente diferente daquela utilizada pelo MySQL,

o SGBD poderia ser trocado, bastando apenas substituir o conector de banco de dados,

sem maiores alterações na aplicação.

O prejuízo de se utilizar um ORM é não se ter controle sobre as consultas que

são geradas e enviadas para o banco de dados. Isso pode causar significativas perdas de

desempenho. Porém, a maior parte das operações é para realizar simples criações,

leituras e modificações de registros. Nesse caso, o ganho durante o desenvolvimento ao

usar um ORM supera a perda de desempenho que pode vir a ocorrer.

6 Serializar um objeto significa transformar seu conteúdo em um texto com um formato

específico. A desserialização é o processo inverso: transformar um texto com um formato específico em

um objeto. Alguns sistemas suportam a serialização de objetos tanto em XML (Extensible Markup

Language) quanto JSON.

42

4.3.3 – Como criar um recurso

Para inserir no sistema uma organização que é portadora do número de registro

112358, da razão social “Empresa Exemplo LTDA.” e do nome fantasia “Mr.

Exemplo”, a requisição HTTP mostrada pela Figura 4.2 deve ser enviada para o

servidor (API).

Figura 4.2 – Exemplo de solicitação HTTP para criar um recurso.

A solicitação passa primeiro por uma etapa de validação, que verifica, por

exemplo, se os campos obrigatórios foram informados, se os tamanhos de texto estão

dentro dos limites permitidos, e se o número de registro é único no sistema.

Se passar pela validação, será devolvida uma resposta de sucesso com o código

HTTP 201 (Created) e a representação vigente do novo recurso. A Figura 4.3 mostra

como seria a resposta para a solicitação anterior.

Nota-se que duas informações foram adicionadas ao registro sem que o cliente

solicitasse: as datas de criação (“createdOn”) e de última modificação do registro

(“lastModifiedOn”). Imediatamente após a criação, ambas serão iguais. Quase todas as

entidades possuem esse metadado, salvo exceções onde não são pertinentes.

POST /organizations HTTP/1.1

Host: localhost:8000

Content-Type: application/json

{

"tradeName": "Mr. Exemplo",

"legalName": "Empresa Exemplo LTDA.",

"taxId": "112358"

}

43

Figura 4.3 – Resposta à solicitação HTTP para criar um recurso.

4.3.4 – Como obter um recurso

Para obter um recurso, basta utilizar o verbo GET em um recurso existente. Por

exemplo, para obter o recurso recém-criado de identificador número 1, deve-se fazer a

requisição “GET /organizations/1”. Nenhum corpo deve ser enviado para esse tipo de

solicitação. A resposta será igual à do item anterior, com exceção de o cabeçalho

“Location” estar ausente e do código de resposta HTTP ser 200 (OK).

Os exemplos de requisição e resposta são mostrados, respectivamente, pela

Figura 4.4 e pela Figura 4.5. Observe que, ao obter um recurso individual, ele sempre

retornará encapsulado em um objeto chamado “data”.

Figura 4.4 – Exemplo de solicitação HTTP para obter um recurso.

HTTP/1.1 201 Created

Content-Length: 195

Content-Type: application/json; charset=UTF-8

Location: /organizations/1

{

"data": {

"id": 1,

"taxId": "112358",



"createdOn": "2018-08-27T05:16:44.704000",

"lastModifiedOn": "2018-08-27T05:16:44.704000"

}

}

GET /organizations/1 HTTP/1.1


44

Figura 4.5 – Resposta à solicitação HTTP para obter um recurso.

Quando a solicitação é para obter uma coleção de registros, o formato do objeto

de resposta é ligeiramente diferente. Agora, a propriedade “data” não é mais um objeto,

e sim uma lista. O exemplo de requisição e resposta para listar todas as organizações são

mostrados pela Figura 4.6 e pela Figura 4.7 respectivamente.

Observe na Figura 4.7 que existe também um objeto com dados sobre a

paginação. Para todos os recursos que representam coleções, a API sempre fará a

paginação no lado do servidor e retornará a resposta com a página solicitada. Para

solicitar uma página diferente, o cliente deve informar a página desejada e quantos

registros por página devem ser exibidos. Esses dados devem ser passados via

querystring. Alguns exemplos de opções válidas são listadas abaixo:

• GET /organizations?page=2&recordsPerPage=30

• GET /organizations?page=2

• GET /organizations?recordsPerPage=30

Quando não informados, os parâmetros assumem seus valores padrões, que são

1 (um) para o número da página e 10 (dez) para o número de registros por página.

Informar um número negativo não gera erro, e o valor padrão será utilizado. A última

página pode conter menos registros que o número informado em “recordsPerPage”.

HTTP/1.1 200 OK

Content-Length: 195


{

"data": {

"id": 1,

"taxId": "112358",



"createdOn": "2018-08-27T05:16:44.704000",


}

}

45

Figura 4.6 – Exemplo de solicitação HTTP para obter um recurso do tipo

coleção.

Figura 4.7 – Resposta à solicitação HTTP para obter um recurso do tipo

coleção.

4.3.5 – Como modificar um recurso

A API suporta modificações parciais em diversos recursos por meio do verbo

PATCH. Isso significa que não é necessário enviar o estado completo de um recurso

para atualizar somente um subconjunto de suas propriedades. Ainda assim, se desejado,

o estado completo pode ser enviado para atualização.

GET /organizations HTTP/1.1


HTTP/1.1 200 OK

Content-Length: 285


{

"data": [

{

"id": 1,

"taxId": "112358",



"createdOn": "2018-08-27T05:16:44.704000",


}

],

"paging": {

"currentPage": 1,

"recordsPerPage": 10,

"totalPages": 1,

"totalRecords": 1

}

}

46

Suponha que a organização de “id” 1 foi cadastrada com o nome fantasia errado.

O exemplo a seguir, mostrado na Figura 4.8, solicita a correção para o nome “O

Exemplo do Brasil”.

Figura 4.8 – Exemplo de solicitação HTTP para modificar um recurso.

Os campos que não forem enviados em uma ação PATCH não serão alterados.

A resposta de sucesso contém a representação completa e atualizada do recurso, como

mostra a Figura 4.9 abaixo.

Figura 4.9 – Resposta à solicitação HTTP para modificar um recurso.

Observe que a data de última modificação foi atualizada, enquanto a data de

criação permaneceu a mesma.

PATCH /organizations/1 HTTP/1.1



{

"tradeName": "O Exemplo do Brasil"

}

HTTP/1.1 200 OK

Content-Length: 203


{

"data": {

"id": 1,

"taxId": "112358",


"tradeName": " O Exemplo do Brasil ",

"createdOn": "2018-08-27T05:16:44.704000",


}

}

47

Um ponto importante de se notar é que, eventualmente, deseja-se remover a

informação de um campo que não é obrigatório. Para isso, é necessário enviar

explicitamente o campo com valor nulo para a API. Se o campo for omitido da

solicitação, ele permanecerá com o valor antigo, pois não foi sinalizada a intenção de

alterar seu valor. Por fim, se o campo for obrigatório, será emitido um erro de validação

e a operação será abortada. Abaixo, um exemplo que solicita a remoção do nome

fantasia (propriedade opcional de uma organização) é mostrado na Figura 4.10.

Figura 4.10 – Exemplo de solicitação HTTP para remover uma propriedade

opcional de um recurso.

4.3.6 – Como remover um recurso

Para remover um recurso, este deve aceitar processar o verbo DELETE, o que

não ocorre para organizações. É possível, porém, remover um departamento de uma

organização. Veja na Figura 4.11 o exemplo que solicita a remoção do departamento

identificado pelo número 5 da organização identificada pelo número 1.

Figura 4.11 – Exemplo de solicitação HTTP para remover um recurso.

O cabeçalho Content-Type pode ser removido da requisição, visto que nenhum

conteúdo é enviado no corpo desse tipo de solicitação. Todas as informações

necessárias para a exclusão estão no URI.

PATCH /organizations/1 HTTP/1.1



{

"tradeName": null

}

DELETE /organizations/1/departments/5 HTTP/1.1


48

O primeiro passo dessa operação é realizar a validação do identificador

solicitado. Caso não exista, será retornada uma resposta com código HTTP 404 (Not

Found).

Se existir, o recurso será excluído com sucesso, a resposta terá código HTTP

200 (OK) e o corpo estará vazio. Uma segunda solicitação de DELETE para o mesmo

recurso resultaria em uma resposta com código 404 (Not Found), pois ele não existiria

mais.

4.3.7 – Como criar uma análise de risco

A partir das instruções de como criar, obter, atualizar e remover recursos, é

possível construir toda a estrutura de uma organização e cadastrar suas relevâncias, as

ameaças existentes e as vulnerabilidades dos ativos.

O passo seguinte consiste em executar a operação que realiza a análise. Isso

pode ser feito por meio do recurso “/organizations/:id/analyses”. Essa operação permite

adicionar uma descrição para a análise e também informar os escopos desejados, como

mostrado abaixo na Figura 4.12.

Figura 4.12 – Exemplo de solicitação HTTP para criar análise.

Os escopos de análise escolhidos na solicitação foram o departamento 1 inteiro e

apenas parte do departamento 4. Desse último, foram incluídos somente o processo 11

do macroprocesso 2 e todos os processos do macroprocesso 3.

POST /organizations/1/analyses HTTP/1.1



{

"description": null,

"scopes": [

{ "departmentId": 1 },

{ "departmentId": 4, "macroprocessId": 2, "processId": 11 },

{ "departmentId": 4, "macroprocessId": 3 }

]

}

49

A resposta possui o formato mostrado pela Figura 4.13. Ela não inclui os

resultados da análise porque eles podem chegar a milhares de itens e isso tornará o

objeto de resposta grande demais para ser trafegado pela rede. Uma outra rota da API

foi disponibilizada para realizar a consulta paginada dos resultados.

Figura 4.13 – Resposta à solicitação HTTP para criar análise.

Por essa resposta, é possível saber o número de itens que foram analisados em

“totalProcessedItems”. Isso pode ser utilizado para averiguar se o número está de

acordo com o escopo selecionado.

Conforme já mencionado, existe uma outra rota da API que permite a consulta

dos detalhes da análise, permitindo observar seus resultados. Eles estarão ordenados

pelo grau de risco de forma decrescente.

O exemplo abaixo mostra a consulta dos detalhes. Os valores das propriedades

foram removidos e a lista contém somente um item a título de exemplo. Uma análise

real terá dezenas, centenas ou milhares de itens na lista de detalhes. Veja e requisição e

resposta na Figura 4.14 e na Figura 4.15 respectivamente. Os textos vazios e os números

zerados estão presentes apenas para indicar os tipos de dado esperados. Em uma análise

real, os campos do tipo inteiro e decimal nunca estarão zerados, dado que as escalas

utilizadas para classificação de relevâncias, ameaças e vulnerabilidades são de 1 a 5.

HTTP/1.1 201 Created

Content-Length: 154


Location: /organizations/1/analyses/100

{

"data": {

"id": 100,

"description": null,

"createdOn": "2018-09-02T20:01:38.723000",

"lastModifiedOn": "2018-09-02T20:01:38.723000",

"totalProcessedItems": 2

}

}

50

Figura 4.14 – Exemplo de solicitação HTTP para obter os detalhes de uma

análise.

Figura 4.15 – Resposta à solicitação HTTP para obter os detalhes de uma

análise.

GET /organizations/1/analyses/100/details HTTP/1.1


HTTP/1.1 200 OK

Content-Length: ...


{

"data": [

{

"departmentName": "",

"macroprocessName": "",

"processName": "",

"processRelevance": 0,

"itServiceName": "",

"itServiceRelevance": 0,

"itAssetName": "",

"itAssetRelevance": 0,

"itAssetVulnerabilityLevel": 0,

"securityThreatName": "",

"securityThreatLevel": 0,

"calculatedImpact": 0.0,

"calculatedProbability": 0.0,

"calculatedRisk": 0.0

}

],

"paging": {

"currentPage": 1,

"recordsPerPage": 10,

"totalPages": 1,

"totalRecords": 1

}

}

51

4.4 – O front-end

O sistema precisa de uma interface gráfica para ser utilizada por um usuário

final. A API é apenas uma interface do back-end onde outros sistemas podem se

conectar a ele. Apesar de ser possível interagir com uma API REST por meio de

algumas ferramentas, elas não são amigáveis e são mais utilizadas pelos próprios

desenvolvedores do sistema.

O front-end pode ser uma aplicação desktop, uma aplicação web ou um

aplicativo mobile. Na primeira opção, o usuário precisa obter um arquivo de instalação e

executá-lo na sua máquina. Além disso, o processo de atualização do software sofre

muita fricção ao utilizar essa alternativa. A segunda opção é mais flexível e escalável,

podendo ser acessada pela Internet ou pela rede interna de uma organização. A terceira

opção é destinada a usuários de dispositivos móveis e, muitas vezes, é capaz de oferecer

ótima experiência de uso. Porém, essa última é fornecida geralmente como um canal

alternativo de acesso aos serviços de uma empresa, pois exige um esforço maior de

desenvolvimento para suportar diferentes tamanhos e fabricantes de dispositivos. A

escolha preferida para este projeto foi a aplicação web.

O framework utilizado foi o Angular (versão 5), criado e mantido pelo Google.

Assim como os “concorrentes” React, Vue.js, entre outros, ele é empregado para

desenvolver Single Page Applications (SPA)7. A razão da escolha do Angular foi o

desacoplamento que ele possui entre a linguagem de marcação Hypertext Markup

Language (HTML) e o código que lida com o conteúdo dinâmico das páginas – o React

mistura os dois em um mesmo arquivo. Além disso, possui significativa adesão da

comunidade [33] [34] – o que não vale para o Vue.js –, contribuindo para que existam

opções de bibliotecas que resolvem problemas conhecidos, como manipulação de tokens

de autenticação.

4.4.1 – Autenticação

Um mecanismo simplificado de autenticação foi implementado para impedir

acesso não autorizado ao sistema. Para tal funcionalidade, foi utilizada uma solução de

um fornecedor terceiro, chamado Auth0. Sua versão gratuita atende às necessidades

7 Single Page Application é o nome dado à aplicação que oferece a navegabilidade em uma

mesma página web, sem precisar fazer novas requisições ao servidor para renderizar um novo layout.

52

básicas de identificação do usuário e gerenciamento de conta, como a funcionalidade

“Esqueci minha senha” [35] com envio de e-mail para recuperação da mesma.

As imagens abaixo (Figura 4.16 e Figura 4.17) mostram uma tela exigindo a

entrada das credenciais e outra para efetuar o login.

Figura 4.16 – Tela apresentada antes de informar as credenciais de acesso.

Figura 4.17 – Tela de login.

4.4.2 – Menu

O website possui um menu que permite navegar entre as diferentes telas da

aplicação. Ele está dividido em uma seção que contém dados de catálogo (aqueles não

vinculados a organizações) e em outra referente às organizações. A Figura 4.18 permite

visualizá-lo.

53

Figura 4.18 – Tela inicial do sistema após login.

4.4.3 – Telas

O website possui telas que permitem acionar as funcionalidades da API. Serão

listadas abaixo cada uma das telas desenvolvidas.

• Tela inicial informando que deve ser realizado o login para acessar o

sistema.

• Tela inicial apresentada após o login ser realizado

• Catálogo – Tela de listagem e criação de departamentos (áreas)

• Catálogo – Tela de atualização de departamento (área)

• Catálogo – Tela de listagem e criação de macroprocessos

• Catálogo – Tela de atualização de macroprocesso

• Catálogo – Tela de listagem e criação de processos

• Catálogo – Tela de atualização de processo

• Catálogo – Tela de listagem e criação de serviços de TI

• Catálogo – Tela de atualização de serviço de TI

• Catálogo – Tela de listagem e criação de ativos de TI

• Catálogo – Tela de atualização de ativo de TI

• Catálogo – Tela de listagem e criação de ameaças

• Catálogo – Tela de atualização de ameaça

• Catálogo – Tela de listagem e criação de controles mitigatórios

• Catálogo – Tela de atualização de controle mitigatório

54

• Tela de listagem de organizações

• Tela de criação e de atualização de uma organização

• Tela de visualização dos detalhes de uma organização

• Tela de manutenção da estrutura de uma organização (áreas,

macroprocessos, processos, serviços e ativos de TI)

• Tela para inclusão de área (ou departamento) à organização

• Tela para inclusão de macroprocesso a uma área da organização

• Tela para inclusão de processo a um macroprocesso da organização

• Tela para inclusão de serviço de TI a um processo da organização

• Tela para inclusão de ativo de TI a um serviço de TI da organização

• Tela de listagem de ameaças da organização

• Tela de inclusão de ameaça à organização

• Tela de listagem de todos os ativos de TI da organização

• Tela de inclusão de ativo de TI à organização

• Tela de listagem de vulnerabilidades de um ativo de TI da organização

• Tela de inclusão de vulnerabilidade de um ativo de TI da organização

• Tela de listagem de análises

• Tela de criação de análise

• Tela de visualização dos detalhes de uma análise

• Tela de atualização da descrição de uma análise

As telas iniciais antes e após login foram apresentadas em 4.4.1 – Autenticação e

4.4.2 – Menu. Abaixo serão exibidas as capturas de tela correspondente a cada uma das

telas listadas acima.

A Figura 4.19 apresenta a tela de criação e listagem de departamentos, e a Figura

4.20 apresenta a tela de atualização de um determinado departamento.

55

Figura 4.19 – Tela de listagem e criação de departamentos.

Figura 4.20 – Tela de atualização de departamento.

As telas de listagem, criação e atualização de macroprocessos, de processos, de

serviços de TI se assemelham às telas de departamento, mudando apenas o texto que

identifica seu contexto. Já as telas de ativos de TI possuem uma diferença: ela permite

escolher a categoria do ativo ao criar ou atualizar. Veja o campo presente na Figura

4.21. As opções disponíveis para categoria são exibidas na Figura 4.22.

56

Figura 4.21 – Tela de listagem e criação de ativos de TI.

Figura 4.22 – Tela de listagem e criação de ativos de TI com destaque para as

categorias de ativo disponíveis.

A Figura 4.23 mostra a possibilidade de alterar a categoria ao atualizar os dados

de um ativo de TI.

57

Figura 4.23 – Tela de atualização de ativo de TI.

As telas do catálogo de ameaças e controles mitigatórios são similares à de

departamento, mas elas possuem um campo adicional e opcional para inserir uma

descrição. As telas de ameaças foram utilizadas como exemplo e mostram esse campo

na Figura 4.24 e na Figura 4.25.

Figura 4.24 – Tela de listagem e criação de ameaças.

58

Figura 4.25 – Tela de atualização de ameaça.

A Figura 4.26 mostra o diálogo que é exibido para inserir uma organização.

Logo em seguida, a Figura 4.27 mostra a tela de listagem de organizações com um

registro adicionado.

Figura 4.26 – Tela de criação de organização.

59

Figura 4.27 – Tela de listagem de organizações.

Na Figura 4.27, é possível observar cinco botões à direita da linha da tabela. O

primeiro deles, com a letra “i”, leva à página de detalhes da organização. O segundo,

leva à tela de gerenciamento de estrutura da organização. Ao lado dele, o terceiro botão

leva à listagem de ativos de TI da organização. O botão com formato triangular com

uma exclamação dentro leva à tela de ameaças da organização. Já o último, permite

visualizar as análises feitas na organização. Cada uma dessas ações também poderá ser

executada pela tela de detalhes da organização, como mostra a Figura 4.28.

Figura 4.28 – Tela de detalhes de uma organização.

60

O mesmo diálogo exibido para incluir uma organização no sistema é exibido

para permitir a alteração de seus dados. A diferença é que os dados vêm preenchidos,

como mostrado pela Figura 4.29.

Figura 4.29 – Tela de atualização de uma organização.

A Figura 4.30 mostra a tela das ameaças cadastradas para uma organização,

ainda sem nenhuma ameaça cadastrada. O texto "Empresa de Teste" em azul e em cima

do cabeçalho "Ativos de TI" é clicável, e permite voltar à tela de detalhes da

organização.

Figura 4.30 – Tela de listagem de ameaças de uma organização sem nenhuma

ameaça cadastrada.

61

Na Figura 4.31, é exibido um diálogo para inclusão de ameaça na organização

com os campos já preenchidos. A primeira caixa de seleção contém apenas ameaças

catalogadas. A segunda caixa de seleção está preenchida com o grau da ameaça.

Figura 4.31 – Tela para inclusão de ameaça na organização.

A Figura 4.32 mostra como fica a tela de ameaças da organização após a

inclusão de duas ameaças. É possível observar dois botões de ação em cada linha de

ameaça. O primeiro, em azul, permite editar o grau da ameaça, enquanto o segundo, em

vermelho, permite excluir a ameaça da organização.

Figura 4.32 – Tela de listagem de ameaças de uma organização preenchida com

dois registros.

62

A Figura 4.33 apresenta a tela de ativos de TI cadastrados em uma organização.

É possível visualizar três botões de ação para cada registro da tabela. Eles permitem,

respectivamente, visualizar as vulnerabilidades do ativo, abrir o diálogo de atualização

do ativo, e excluí-lo da organização.

Figura 4.33 – Tela de listagem de ativos de TI de uma organização.

A Figura 4.34 mostra o diálogo que é utilizado para adicionar um ativo de TI à

organização. Ao utilizar esse caminho, o ativo passa a pertencer a organização, mas não

é incluído em nenhum serviço da organização. O usuário deve fazer isso posteriormente

para que ele possa ser devidamente analisado.

Na caixa de seleção de ativos de TI presente nesta tela, estarão disponíveis todos

aqueles presentes no Catálogo de Ativos de TI.

Figura 4.34 – Tela de inclusão de ativo de TI na organização.

63

A Figura 4.35 mostra o diálogo utilizado para atualizar um ativo da organização.

Por ele, é possível alterar apenas a identificação do ativo, e essa mudança não afeta o

catálogo. Observe que o campo com o nome do ativo está bloqueado para edição.

Figura 4.35 – Tela de atualização do ativo de TI de uma organização.

A Figura 4.36 mostra a tela das vulnerabilidades de um ativo em uma

organização. Ela pode ser acessada tanto pela tela que lista os ativos de uma

organização (Figura 4.33), quanto pelo último nível da estrutura de uma organização

(mostrado mais adiante na Figura 4.40).

Figura 4.36 – Tela de listagem de vulnerabilidades de um ativo de TI sem

nenhuma vulnerabilidade cadastrada.

O diálogo para cadastrar uma vulnerabilidade é exibido na Figura 4.37. Para

efetivar a inclusão, deve-se escolher uma das ameaças existentes na organização e o

64

grau de vulnerabilidade relativo a esta ameaça. A título de exemplo, foram cadastradas

duas vulnerabilidades com valores diferentes. O resultado pode ser visto na Figura 4.38.

Figura 4.37 – Tela para cadastrar vulnerabilidade de um ativo de TI da

organização.

Figura 4.38 – Tela de listagem de vulnerabilidades de ativo de TI preenchida

com dois registros.

Na Figura 4.38, o primeiro botão de ação permite alterar o grau de

vulnerabilidade de um ativo de TI perante uma ameaça, e o segundo, permite excluir a

vulnerabilidade. Desta tela, também é possível voltar à tela do ativo correspondente ou à

tela da organização pelos links em azul acima do cabeçalho “Vulnerabilidades”.

65

As imagens a seguir se referem ao gerenciamento de estrutura de uma

organização. A Figura 4.39 mostra como é apresentada a tela da estrutura quando uma

organização acabou de ser incluída no sistema.

Figura 4.39 – Tela de gerenciamento da estrutura de uma organização. Sem

registros.

O botão “Adicionar departamento” permite iniciar o cadastramento da estrutura.

Após sua conclusão, será possível observar algo semelhante ao que é apresentado pela

Figura 4.40. Os diferentes níveis são exibidos com uma indentação em relação ao nível

imediatamente superior, e são identificados por uma estampa no início da linha. Cada

nível pode ser expandido individualmente.

As relevâncias de processos, de serviços de TI e de ativos de TI podem ser

visualizadas, respectivamente, pelas inscrições Rp, Rs e Ra em branco com fundo azul.

Quando ela estiver indefinida, constará um símbolo de interrogação em azul com fundo

branco, como pode-se observar para o processo “Negociação”.

O acionamento do botão + permite incluir um item como filho do nível em

questão. O botão com ícone de uma lixeira permite excluir um nível, incluindo todos os

seus “filhos”. Uma confirmação será exibida antes de efetivar a exclusão. Aqueles que

possuem o botão de edição permitem atualizar a relevância do nível. Por fim, o nível

mais baixo da estrutura, o ativo de TI, possui um botão adicional que leva às

vulnerabilidades daquele ativo. Naturalmente, este último nível não possui o botão +.

66

Figura 4.40 – Tela de gerenciamento da estrutura de uma organização.

As telas de inclusão de cada nível são simples diálogos com caixas de seleção,

diferenciados apenas pelas informações sobre os níveis anteriores a ele. Um exemplo é

mostrado com a tela de inclusão de processo na Figura 4.41, que mostra em qual

departamento e macroprocesso está sendo incluído.

Figura 4.41 – Tela de inclusão de um processo em um macroprocesso da

organização.

67

A tela de inclusão de ativo de TI em um serviço de TI da organização é um

pouco mais complexa. Ela permite tanto buscar um ativo de TI do catálogo quanto

utilizar um ativo já cadastrado na organização. Ao escolher um item do catálogo, é

possível fornecer uma identificação para ele, como o número de série de um dispositivo,

o identificador de uma licença de software, um documento de uma pessoa, etc.

A Figura 4.42 mostra como se apresenta o diálogo ao se escolher um ativo da

organização. Nessa opção, não é possível especificar ou alterar a identificação do ativo.

A Figura 4.43 mostra como se apresenta o diálogo ao se escolher um ativo do

Catálogo. Como exemplo, estão preenchidos os campos correspondentes ao ativo e à

sua relevância para o serviço.

Figura 4.42 – Tela de inclusão de ativo de TI já existente na organização em

serviço de TI da organização.

68

Figura 4.43 – Tela de inclusão de ativo de TI do catálogo em serviço de TI da

organização.

Para finalizar a apresentação das telas, serão mostradas a seguir aquelas

referentes às análises. A Figura 4.44 mostra a tela de listagem de análises ainda vazia.

Para criar a primeira análise, deve-se acionar o botão “Criar análise”, que abrirá o

diálogo mostrado pela Figura 4.45.

Figura 4.44 – Tela de listagem de análises vazia.

69

No diálogo responsável por criar a análise, pode-se escolher realizar uma análise

da organização inteira ou de parte dela, selecionando o escopo desejado. Também é

possível fornecer uma descrição para ela, porém este campo não é obrigatório.

Figura 4.45 – Tela de criação de análise para toda a organização.

Duas análises foram criadas e o resultado pode ser visto na Figura 4.46. Nota-se

a possibilidade de visualizar os detalhes de uma análise ou até mesmo de excluí-la por

inteiro. A tela de detalhes de uma análise permite visualizar as datas de criação e de

última modificação, a descrição e o relatório da mesma. Apenas a descrição pode ser

atualizada. Esses aspectos são mostrados na Figura 4.47.

Figura 4.46 – Tela de listagem de análises com duas análises criadas.

70

Figura 4.47 – Tela de detalhes de uma análise.

Como é possível observar pela figura acima, o relatório é apresentado de forma

concisa, de maneira que apenas as informações mais relevantes são exibidas. O botão

“Exibir detalhes” permite expandir o resultado mostrando todo o caminho da estrutura

da organização no qual o ativo de TI está inserido, como mostra a Figura 4.48.

Figura 4.48 – Tela de detalhes de uma análise com relatório expandido.

71

4.4.4 – Permissionamento

Elementos visuais podem ser exibidos ou ocultados da tela de acordo com as

permissões definidas em 3.5 – Permissões de acesso. Por exemplo, se um usuário não

possui permissão de exclusão em determinado recurso, o ícone da lixeira estará oculto

nas telas correspondentes àquele recurso, impedindo que ele execute a ação. O mesmo

vale para botões de criação e de atualização.

Os papéis e permissões foram definidos em inglês na ferramenta Auth0. As

permissões possuem o formato “ação:recurso”, como poderá ser visto na Tabela 4.3.

Tabela 4.3 – Definição técnica dos papéis e das permissões de acesso ao

sistema.

Papel Permissões

Admin

read:catalog

create:catalog

update:catalog

delete:catalog

read:organizations

create:organizations

update:organizations

delete:organizations

manage:organizations

read:analyses

create:analyses

update:analyses

delete:analyses

Organization manager

read:catalog

create:catalog

read:organizations


update:organizations

delete:organizations


read:analyses

create:analyses

update:analyses

delete:analyses

72

Papel Permissões

Analyst

read:catalog

create:catalog

read:organizations



read:analyses

create:analyses

update:analyses

Guest

read:catalog

read:organizations

read:analyses

73

Capítulo 5 –

Testes

Os testes foram executados manualmente para cada funcionalidade da API e da

aplicação web separadamente. Não é o intuito deste capítulo apresentar todos os testes

realizados, já que os casos são muito similares, portanto, serão fornecidos alguns

exemplos.

No back-end, os testes foram feitos utilizando o Postman, uma aplicação desktop

que permite, dentre outras funcionalidades, enviar requisições HTTP para um servidor.

Foram testadas todas as rotas criadas na API, simulando tanto casos de sucesso quanto

casos de erro.

No front-end, foram executadas todas as funcionalidades implementadas,

experimentando tanto cenários de sucesso quanto cenários que conduzem a erros. Para

esses últimos, uma mensagem deve ser exibida na tela evidenciando o problema

ocorrido. Também foi observado se o usuário estava tendo feedbacks adequados

enquanto aguardava o sistema executar uma operação, seja bloqueando botões de ação,

seja exibindo indicadores “Carregando...”.

5.1 – Testes no back-end

A Figura 5.1 mostra um exemplo de sucesso ao tentar criar uma organização de

teste pelo Postman. A parte superior representa a requisição e a inferior representa a

resposta. É possível notar as propriedades adicionais geradas e retornadas pela aplicação

e o código de resposta HTTP 201 (Created).

74

Figura 5.1 – Captura de tela do Postman: Criando uma organização.

Agora, o próximo teste se refere a uma nova tentativa de incluir a mesma

organização, sem alterar nenhum dos dados enviados anteriormente. O resultado

esperado é um erro de validação de documento, pois é um dos critérios utilizados para

impedir duplicação de organizações. A Figura 5.2 mostra uma lista de erros, que contém

apenas um elemento neste caso. Esse elemento possui três propriedades:

• Código – Identificação do erro para ser interpretado por outros sistemas,

seja para fins de personalização de texto, seja para tratamento de erros.

• Mensagem – Texto que descreve o erro. Atualmente todas as mensagens

são retornadas em Português do Brasil.

• Campo – Indica em qual campo ocorreu o erro descrito pela Mensagem.

Nem sempre virá preenchido, pois alguns erros podem não estar

relacionados a um campo.

Observe também que o código HTTP retornado é o 422 (Unprocessable Entity),

conforme especificado em 4.3.1.3 – Códigos de resposta HTTP.

75

Figura 5.2 – Captura de tela do Postman: Tentativa de criação de uma

organização com dados existentes.

Quando ocorre mais de um erro e eles são independentes entre si, as mensagens

são acumuladas e retornadas todas de uma vez para o usuário. No próximo exemplo, foi

omitido o campo de documento, que é obrigatório, e foi inserido um texto muito longo

no nome empresarial. Isso provocará dois erros de validação, como mostrados pela

Figura 5.3.

76

Figura 5.3 – Captura de tela do Postman: Tentativa de criação de uma

organização com argumentos inválidos.

Por fim, será apresentado um caso de falha na autenticação na Figura 5.4. O

cabeçalho “Authorization”, responsável por transportar as credenciais para autenticação,

foi removido da requisição. Outros casos de falha na autenticação são possíveis e a

mensagem varia ligeiramente de um para outro, na intenção de auxiliar o desenvolvedor

que integra seu sistema nessa API a resolver o problema. O código de resposta

retornado nessas situações será sempre HTTP 401 (Unauthorized).

Observe que mesmo que a organização já tenha sido cadastrada, o erro de

validação não é emitido, pois o servidor não chegou nem a processar a solicitação. Ao

verificar que as credenciais não estavam presentes, a resposta com erro é emitida

imediatamente.

77

Figura 5.4 – Captura de tela do Postman: Erro de autenticação.

5.2 – Testes no front-end

Como os testes na interface gráfica foram manuais, todos os casos de sucesso

puderam ser observados na apresentação das telas feita na subseção 4.4.3 – Telas.

Na Figura 5.5, será apresentado o mesmo caso de tentativa de inclusão de uma

organização existente utilizado na seção anterior, onde espera-se uma mensagem de

erro.

Logo em seguida, o token de acesso à API foi modificado8 propositalmente para

provocar uma falha na autenticação. Em situações normais, o usuário nem conseguiria

chegar a essa tela se não possuísse permissão para criar organizações, pois o botão

“Adicionar organização” estaria oculto. Porém, caso isso fosse possível, a API

detectaria a quebra de integridade do token e impediria o acesso. A Figura 5.6 mostra o

resultado dessa situação.

8 Por meio das ferramentas de desenvolvimento do Google Chrome, abriu-se o “Local Storage”

da aplicação e alterou-se apenas a primeira letra do token de acesso, o suficiente para provocar uma falha

de autenticação na API.

78

Figura 5.5 – Teste de criação de organização com documento existente.

Figura 5.6 – Erro de autenticação induzido.

79

Todos os testes realizados buscavam verificar se toda a funcionalidade definida

no requisitos foi corretamente implementada e se o sistema é de fácil compreensão

pelos usuários finais.

80

Capítulo 6 –

Conclusão

Este trabalho apresentou inicialmente os conceitos básicos sobre Segurança da

Informação. Em seguida, foi documentada a modelagem e a implementação de um

sistema de análise de risco em TI, aplicando integralmente os conceitos estudados.

A importância da segurança da informação foi evidenciada, mostrando como ela

está intimamente associada à imagem e à saúde financeira das empresas. Infelizmente,

algumas só percebem essa importância após sofrer com as perdas causadas por algum

incidente de segurança da informação. Os danos podem ser irreparáveis e, por isso, as

ações preventivas são importantes.

O sistema pode ser utilizado tanto pela própria organização que busca melhorar

sua gestão sobre a segurança da informação, quanto por empresas especializadas em

prestar esse serviço às organizações.

Como funcionalidades principais, os sistema permite:

• Descrever a estrutura organizacional de uma ou mais organizações nos

seguintes níveis: departamento, macroprocesso, processo, serviço de TI e

ativo de TI

• Indicar relevâncias de processos, serviços de TI e ativos de TI dentro da

estrutura organizacional

• Classificar ameaças à organização quanto a seus graus

• Classificar vulnerabilidades de ativos de TI quanto a seus graus

• Gerar análises de risco a partir dos dados cadastrados (com ou sem

escopo reduzido)

Ao fazer a leitura das análises geradas pela ferramenta, uma organização será

capaz de conhecer suas maiores vulnerabilidades em segurança da informação e de atuar

em cima delas, implementando controles para a mitigação de riscos. Os investimentos

passam a ser direcionados a protege-la de incidentes que causariam maior impacto em

seu negócio e que teriam a maior probabilidade de acontecer.

Abordando o aspecto técnico, a ferramenta criada consiste em duas aplicações e

um banco de dados. A primeira aplicação – feita em Angular – permite o uso da

81

ferramenta em navegadores web e se comunica com a segunda aplicação – uma API

REST desenvolvida em Python – para acessar e salvar as informações na base de dados.

A base de dados possui modelagem relacional e o SGBD utilizado foi o MySQL.

Foi demonstrado como instalar a ferramenta no sistema operacional FreeBSD

11.x ou superior. Porém, a arquitetura e as tecnologias escolhidas são bastante versáteis,

permitindo diversas configurações de ambiente de execução, incluindo aqueles em

nuvem.

A ferramenta, apesar de estar bem fundamentada, apresenta espaço para algumas

melhorias. O autor visualiza cinco aspectos diferentes para serem abordados em futuro

próximo.

• O primeiro se refere à usabilidade de todas as telas de listagem. Elas não

apresentam um mecanismo de busca, o que tornaria custoso encontrar

determinada informação se cada lista possuir pelo menos três páginas de

dados. Para minimizar este problema atualmente, todos os registros são

ordenados alfabeticamente por nome, que é o critério mais comum de

busca.

• O segundo está relacionado ao processo de análise de risco. Uma análise

pode ocorrer em várias iterações, pois, em cada uma delas, pode-se testar

controles diferentes para reduzir vulnerabilidades de ativos e observar os

resultados gerados a partir dessas suposições. Atualmente, não é possível

fazer a correlação dessas iterações, pois as análises são criadas de forma

independente. Para que isso fosse possível, deveria haver um indicador

de que todas as análises intermediárias se referem ao mesmo processo.

Apenas a análise final deveria ser marcada como encerrada.

• O terceiro diz respeito ao sistema de autorização. O autor acha plausível

buscar soluções externas para problemas bem resolvidos, bastante

testados e que não são estratégicos para o sucesso da ferramenta. Porém,

o fluxo de gerenciamento de usuários que está em funcionamento está

completamente centralizado em uma interface externa, exigindo que o

administrador interaja com duas interfaces completamente diferentes: o

“knoweak web” e o Auth0 (provedor de identidades). Como evolução

desse modelo, podem ser criadas telas para gerenciamento de usuários e

de seus papéis (administrador, analista, etc.), onde cada uma delas

acionaria, via API, as operações disponibilizadas pelo Auth0.

82

• Como quarto aspecto, a aplicação deveria contar com um mecanismo de

log, tanto na API quanto no front-end. Isso permitirá ter rastreabilidade

das ações e auxiliará na resolução de problemas da ferramenta ou com o

mal uso dela.

• Por fim, o aspecto sobre inteligência de dados. Seria interessante

conhecer o quanto um controle contribuiu para a redução de uma

vulnerabilidade e, assim, poder criar um sistema de recomendação de

controles com base no ativo de TI utilizado pela organização.

O processo de análise de risco da organização deve ser implantado a partir do

momento que esta é informatizada, e sustentado enquanto ela existir. Em alguns casos,

estar conforme com normas internacionais, como a ISO 27001, conferem maior

credibilidade ao empreendimento. A segurança nunca pode ser tomada como garantida.

83

Bibliografia

[1] ISO, “ISO/IEC 27000:2018 - Information technology - Security techniques -

Information security management systems - Overview and vocabulary,” 2018.

[Online]. Disponível: https://www.iso.org/standard/73906.html. [Acesso em 04

2018].

[2] Gemalto, “Breach Level Index,” Gemalto, [Online]. Disponível:

https://breachlevelindex.com/. [Acesso em 19 08 2018].

[3] Gemalto, “2017 Data Breach Level Index: Full year results are in…,” 13 04 2018.

[Online]. Disponível: https://blog.gemalto.com/security/2018/04/13/data-breach-

stats-for-2017-full-year-results-are-in/. [Acesso em 19 08 2018].

[4] Computerworld, “Perda financeira deve chegar a cerca de US$ 580 por incidente

de segurança em 2018,” Computer World, 05 12 2017. [Online]. Disponível:

https://computerworld.com.br/2017/12/05/perda-financeira-deve-chegar-cerca-de-

us-580-por-incidente-de-seguranca-em-2018/. [Acesso em 19 08 2018].

[5] F. Leonhardt, “Auditing, Penetration Testing and Ethical Hacking,” em Handbook

of Electronic Security and Digital Forensics, World Scientific, 2010, p. 93.

[6] L. Romero, “Não li e concordo,” Super Interessante, 27 03 2017. [Online].

Disponível: https://super.abril.com.br/tecnologia/nao-li-e-concordo/. [Acesso em

19 08 2018].

[7] C. Cakebread, “You're not alone, no one reads terms of service agreements,”

Business Insider, 15 11 2017. [Online]. Disponível:

https://www.businessinsider.com/deloitte-study-91-percent-agree-terms-of-service-

without-reading-2017-11. [Acesso em 19 08 2018].

[8] D. Drinkwater, “Does a data breach really affect your firm’s reputation?,” CSO, 07

01 2016. [Online]. Disponível: https://www.csoonline.com/article/3019283/data-

breach/does-a-data-breach-really-affect-your-firm-s-reputation.html. [Acesso em

19 08 2018].

[9] Alva, “The reputational risk of cybersecurity attacks: TalkTalk case study,” Alva,

31 10 2015. [Online]. Disponível: http://www.alva-group.com/en/the-reputational-

84

risk-of-cyber-attacks-talktalk-case-study/. [Acesso em 19 08 2018].

[10] A. Campos, Sistema de Segurança da Informação - Controlando os Riscos, Visual

Books, 2014.

[11] IsecT, “ISO27k timeline,” [Online]. Disponível:

http://www.iso27001security.com/html/timeline.html. [Acesso em 21 08 2018].

[12] British Standard Institute, “BS 7799-2:1998 - Information security management.

Specification for information security management systems,” 15 02 1998. [Online].

Disponível: https://shop.bsigroup.com/ProductDetail?pid=000000000001300725.

[Acesso em 28 08 2018].

[13] British Standard Institute, “BS 7799-1:1995 - Information security management.

Code of practice for information security management systems,” 15 02 1995.

[Online]. Disponível:

https://shop.bsigroup.com/ProductDetail/?pid=000000000001324657. [Acesso em

28 08 2018].

[14] ISO/IEC, “ISO/IEC 17799:2000 - Information technology -- Code of practice for

information security management,” 12 2000. [Online]. Disponível:

https://www.iso.org/standard/33441.html. [Acesso em 28 08 2018].

[15] ISO/IEC, “ISO/IEC 27001:2005 - Information technology -- Security techniques --

Information security management systems -- Requirements,” 10 2005. [Online].

Disponível: https://www.iso.org/standard/42103.html. [Acesso em 28 08 2018].


Code of practice for information security management,” 07 2007. [Online].


[17] Instituto Nacional de Tecnologia da Informação, “ICP-Brasil,” 17 06 2017.

[Online]. Disponível: http://www.iti.gov.br/icp-brasil. [Acesso em 20 08 2018].

[18] Dicionário de Informática, “Não-repúdio - Segurança da Informação,” 18 09 2016.

[Online]. Disponível: https://www.youtube.com/watch?v=Nzb_qGPjFi8. [Acesso

em 19 08 2018].

[19] N. Hemmer, “Confidentiality vs. Privacy in a SOC 2,” 07 03 2018. [Online].

Disponível: https://linfordco.com/blog/confidentiality-vs-privacy-in-a-soc-2/.

[Acesso em 19 08 2018].

[20] M. Smolenski, “Smart Contracts: Privacy vs Confidentiality,” Hackernoon, 14 10

85

2017. [Online]. Disponível: https://hackernoon.com/smart-contracts-privacy-vs-

confidentiality-645b6e9c6e5a. [Acesso em 19 08 2018].

[21] “Is there a Difference Between Confidentiality and Privacy?,” FindLaw, [Online].

Disponível: https://criminal.findlaw.com/criminal-rights/is-there-a-difference-

between-confidentiality-and-privacy.html. [Acesso em 19 08 2018].

[22] Brasil, “Constituição da República Federativa do Brasil de 1988,” 1988. [Online].

Disponível: http://www.planalto.gov.br/ccivil_03/constituicao/constituicao.htm.

[Acesso em 19 08 2018].

[23] Brasil, “Art. 5º, inc. XII da Constituição da República Federativa do Brasil de

1988,” 1988. [Online]. Disponível:

https://www.jusbrasil.com.br/topicos/10730639/inciso-xii-do-artigo-5-da-

constituicao-federal-de-1988. [Acesso em 10 08 2018].


Information security management systems -- Requirements,” 10 2013. [Online].


[25] DB-Engines, “DB-Engines Ranking of Relational DBMS,” 08 2018. [Online].

Disponível: https://db-engines.com/en/ranking/relational+dbms. [Acesso em 25 08

2018].

[26] DB-Engines, “MySQL System Properties,” 2018. [Online]. Disponível: https://db-

engines.com/en/system/MySQL. [Acesso em 25 08 2018].

[27] 2ndQuadrant, “PostgreSQL vs MySQL,” [Online]. Disponível:

https://www.2ndquadrant.com/en/postgresql/postgresql-vs-mysql/. [Acesso em 10

02 2018].

[28] R. T. Fielding, “Architectural Styles and the Design of Network-based Software

Architectures,” Irvine, 2000.

[29] R. Ferreira, “REST: Princípios e boas práticas,” 23 10 2017. [Online]. Disponível:

http://blog.caelum.com.br/rest-principios-e-boas-praticas/. [Acesso em 26 08

2018].

[30] F. Gimian, “Python API Framework Benchmarks,” 06 2018. [Online]. Disponível:

https://fgimian.github.io/blog/2018/06/05/python-api-framework-benchmarks/.

[Acesso em 26 08 2018].

[31] K. Klenov, “Python's Web Framework Benchmarks,” 09 06 2016. [Online].

86

Disponível: http://klen.github.io/py-frameworks-bench/. [Acesso em 26 08 2018].

[32] J. Vanhala, “Inflection,” [Online]. Disponível:

https://inflection.readthedocs.io/en/latest/. [Acesso em 26 08 2018].

[33] Google, “Google Trends - Vue.js, React, Angular,” [Online]. Disponível:

https://trends.google.com/trends/explore?cat=31&q=Vue.js,React,Angular.

[Acesso em 02 09 2018].

[34] TechMagic, “ReactJS vs Angular5 vs Vue.js — What to choose in 2018?,” 16 03

2018. [Online]. Disponível: https://medium.com/@TechMagic/reactjs-vs-angular5-

vs-vue-js-what-to-choose-in-2018-b91e028fa91d. [Acesso em 29 08 2018].

[35] Auth0, “Auth0 Pricing,” [Online]. Disponível: https://auth0.com/pricing. [Acesso

em 02 09 2018].

[36] A. Wiggins, “The Twelve-Factor App,” 2017. [Online]. Disponível:

https://12factor.net/pt_br/. [Acesso em 04 03 2019].

[37] R. Carvalho, “Conheça o método PDCA, que fez da FALCONI a maior consultoria

de gestão do Brasil,” Na Prática, 23 08 2017. [Online]. Disponível:

https://www.napratica.org.br/o-que-e-e-como-funciona-o-metodo-pdca/. [Acesso

em 24 08 2018].

[38] “What is a Container?,” Docker, [Online]. Disponível:

https://www.docker.com/resources/what-container. [Acesso em 04 03 2019].

87

Apêndice A –

Como configurar o ambiente de

desenvolvimento

O ambiente de desenvolvimento deve prover ao desenvolvedor todos os recursos

que ele necessita para modificar e testar o código com agilidade, de forma a evitar

surpresas ao colocar o software no ambiente de execução. Aquele ambiente não possui

as mesmas características deste, pois a capacidade utilizada será diferente, assim como a

arquitetura de implantação e os requisitos de segurança.

As seguintes dependências devem ser instaladas:

• Docker Engine 18.09.x

• Docker Compose 1.23.x

• Git 2.x

• Node.js (LTS) 8.x

• Angular CLI 1.7.4

O Docker é uma ferramenta feita para tornar simples a criação, implantação e

execução de containers 9. Obviamente, isso exige que a aplicação esteja preparada para

funcionar dentro de um container. Existem algumas premissas para isso, conhecidas

como The Twelve-Factor App [36], mas sua exposição está fora do escopo deste

trabalho. A aplicação desenvolvida neste trabalho atende a esses requisitos, e a máquina

onde a aplicação foi implantada possuía o Docker Community Edition instalado.

Também é utilizado o sistema de controle de versões Git para que o

desenvolvedor possa registrar cada modificação realizada no código. Portanto, esta

também é uma dependência que deve estar disponível no ambiente de quem contribuirá

para a aplicação.

9 Um container é uma unidade padronizada de software, que empacota a aplicação e suas

dependências em um executável, permitindo sua execução fluida e confiável independente do ambiente

onde seja implantado [38].

88

O Node.js será utilizado para instalar o Angular CLI, que por sua vez será útil

para o desenvolvimento rápido de componentes no front-end. O Node.js também será

necessário para preparar uma nova publicação para o ambiente de execução.

Siga os passos a seguir para configurar o ambiente de desenvolvimento,

começando com a instalação das dependências.

1. Instale o Docker. As plataformas suportadas por ele estão listadas no site

https://docs.docker.com/install/ 10 e, apesar de as instruções e os binários

serem diferentes para cada plataforma, elas compartilham a mesma versão

do mecanismo principal chamado Docker Engine. A versão utilizada neste

projeto foi o Docker Community Edition (CE) 18.09.2. Verifique a versão

instalada em um terminal de linha de comando, como mostrado abaixo:

2. Instale o Docker Compose. Para MacOS e Windows, ele já está embutido

no pacote de instalação do Docker. Para Linux, basta seguir as instruções

disponíveis em https://docs.docker.com/compose/install/. Verifique a versão

instalada em um terminal de linha de comando, como mostrado abaixo:

3. Instale o Git. O instalador ou as instruções para instalação podem ser

obtidas no seguinte site: https://git-scm.com/downloads.

4. Instale o Node.js. Neste projeto foi utilizada a versão 8.9.4. As instruções

para instalação nas diferentes plataformas podem ser encontradas no site

https://nodejs.org/en/. Depois de instalar, verifique a versão com o comando:

10 No momento da escrita deste trabalho, são oficialmente suportados MacOS, Windows,

CentOS, Debian, Fedora e Ubuntu.

$ docker –version

Docker version 18.09.2 build 6427962

$ docker-compose –version

docker-compose version 1.23.2 build 1110ad01

$ node –-version

v8.9.4

https://docs.docker.com/install/

https://docs.docker.com/compose/install/

https://gitscm.com/downloads

https://nodejs.org/en/

89

5. Instale o Angular CLI. Isso será feito pela ferramenta de linha de comando

chamada Node Package Manager (NPM), que foi instalada automaticamente

pelo instalador do Node.js. Execute o comando abaixo:

6. Baixe o código do projeto. Eles estão divididos em dois repositórios

hospedados no GitHub, um para o front-end, outro para o back-end. Os

comandos abaixo criam uma pasta para armazenar os projetos e depois os

baixa para dentro delas, fazendo uso da ferramenta Git obtida no passo

anterior.

7. Inicialize o back-end com o Docker Compose. Na primeira vez que o

comando abaixo for executado, o banco de dados será criado com todas as

tabelas, as tabelas de domínio serão populadas, os usuários de banco serão

criados e a aplicação será executada. O comando deve ser executado da raiz

do repositório “knoweak api”.

8. Verifique se a aplicação está respondendo. Se o passo anterior foi

executado com sucesso, a aplicação estará pronta para receber requisições

HTTP na porta 8001. Execute o comando a seguir para obter a versão da

aplicação:

$ npm install -g @angular/[email protected]

$ mkdir -p ~/code && cd ~/code

$ git clone https://github.com/psvaiter/knoweak-api.git

$ git clone https://github.com/psvaiter/knoweak-web.git

$ cd ~/code/knoweak-api

$ docker-compose up

$ curl -si http://localhost:8001/version

HTTP/1.1 200 OK

Server: gunicorn/19.9.0

content-type: application/json; charset=UTF-8

content-length: 20

{"version": "1.0.0"}

https://github.com/psvaiter/knoweak-api.git

https://github.com/psvaiter/knoweak-web.git

http://localhost:8001/version

90

9. Verifique se há conectividade com o banco de dados. Execute o comando

abaixo para testar se o banco de dados e o usuário de banco para a aplicação

foram criados corretamente. Em caso de sucesso, o código de reposta HTTP

será 200 (OK) e o corpo da resposta estará vazio.

10. Inicialize o front-end com Docker Compose. Execute o comando abaixo

para navegar até a raiz do projeto e inicializar a aplicação web.

Na primeira vez que for executado, pode levar alguns minutos até que tudo

esteja pronto para uso. Aguarde até que a mensagem “webpack: Compiled

successfully.” apareça no terminal.

11. Teste a aplicação web. Após inicializada, ela poderá ser acessada pelo

navegador no endereço http://localhost:4200.

Ao concluir o procedimento descrito acima, deverão existir três containers em

execução correspondentes a este trabalho. Isso pode ser verificado executando o

comando $ docker ps, que lista os containers que estão rodando. Os nomes dos

containers em execução serão:

• knoweak-api_web_1

• knoweak-api_database_1

• knoweak-web_web_1

O passo 9 (Verificar conectividade com o banco de dados) pode falhar se for

executado imediatamente após o passo 7 (Inicialização do back-end), pois o container

com o servidor de banco de dados demora aproximadamente 30 segundos para estar

apto a receber conexões. Nesse caso, basta aguardar sua inicialização. É possível

$ curl -si http://localhost:8001/healthCheck

HTTP/1.1 200 OK

Server: gunicorn/19.9.0

content-length: 0

content-type: application/json; charset=UTF-8

$ cd ~/code/knoweak-web

$ docker-compose up

http://localhost:4200/

http://localhost:8001/healthCheck

91

acompanhar esse processo utilizando o comando $ docker ps, que também exibe os

status dos containers. Enquanto o container de nome “knoweak-api_database_1”

estiver em processo de inicialização, em seu status constará health: starting e, ao estar

pronto, constará healthy.

Qualquer editor de texto pode ser utilizado para fazer alterações no código. Toda

modificação será automaticamente detectada e atualizada no container em execução,

não havendo necessidade de reiniciá-lo. A título de exemplo, o autor deste trabalho fez

uso do PyCharm Community (desenvolvido pela JetBrains) para codificar o back-end e

do Microsoft Visual Studio Code para codificar o front-end.

Uma outra ferramenta pode ser aplicada para auxiliar o desenvolvimento: o

Postman. Ele pode ser utilizado para enviar requisições HTTP diretamente para a API,

como foi mostrado nos testes do Capítulo 5 –, permitindo que se teste o comportamento

dela independente do front-end. O Postman fornece várias funcionalidades que facilitam

os testes e diminuem as chances de erro, sendo uma opção mais conveniente do que a

interface de linha de comando cURL.

Com esse ambiente configurado, o desenvolvedor estará apto a executar as

funcionalidades da API e da aplicação web em sua máquina local, e fazer os devidos

ajustes no código, se necessário.

92

Apêndice B –

Como configurar o ambiente de execução

As instruções a seguir configuram o ambiente em máquinas com o sistema

operacional FreeBSD 11.x ou superior, conforme definido nos requisitos técnicos deste

projeto. Tanto a aplicação web quanto a API serão instaladas na mesma máquina física.

Porém, é importante dizer que existem diversas outras formas de disponibilizar o

serviço desenvolvido neste trabalho para seus usuários, incluindo a utilização de outros

sistemas operacionais e de plataformas na nuvem.

O FreeBSD não possui suporte oficial ao Docker. Uma adaptação (port) foi feita

em 2015 e não evoluiu junto com a linha principal de desenvolvimento da ferramenta.

Portanto, o Docker não será utilizado para configuração do ambiente de execução no

FreeBSD. Cada uma das dependências serão instaladas manualmente. São elas:

• MySQL 5.7

• Python 3.6

• Nginx 1.14

• Node 8.15

• Angular CLI 1.7.4

• Git 2.21

O MySQL é o servidor e cliente do banco de dados. O Python é a plataforma de

execução da API. Nginx é o servidor web que será utilizado para servir as páginas da

aplicação front-end e atender às requisições para a API. Node é a plataforma que será

utilizada para produzir os artefatos finais da aplicação web. Ainda que não haja

desenvolvimento, os comandos do Angular CLI serão necessários para a compilação da

aplicação web. Git é o sistema de controle de versões, que será utilizado aqui apenas

para obter os repositórios com o código-fonte.

Siga os passos a seguir para configurar o ambiente de execução, começando com

a instalação das dependências.

93

B.1 – Instalação das dependências

1. Instale o servidor e o cliente MySQL 5.7 com os comandos abaixo.

2. Para finalizar a instalação do servidor de banco de dados, obtenha a senha

gerada e inicie o procedimento para tornar a instalação segura no ambiente

de execução. Algumas perguntas serão feitas ao longo da execução. Quando

for solicitado, escolha a política de senha com complexidade baixa (maior ou

igual a 8 caracteres). Quando perguntado se deseja trocar a senha do root,

responda “não”. Para todas as outras perguntas, responda “sim”.

3. Instale o Python 3.6 e seu gerenciador de pacotes “pip”. Em seguida, teste os

executáveis verificando suas versões.

4. Instale o Nginx.

5. Instale o Node e seu gerenciador de pacotes “npm” – NPM é sigla para Node

Package Manager. Em seguida, teste os executáveis verificando suas

# pkg install mysql57-server mysql57-client

# sysrc mysql_enable="YES"

# service mysql-server start

# cat $HOME/.mysql_secret

# mysql_secure_installation

# pkg install python36 py36-pip

# ln -s /usr/local/bin/python3.6 /usr/local/bin/python

# ln -s /usr/local/bin/pip-3.6 /usr/local/bin/pip

# python –-version

Python 3.6.8

# pip --version

pip 9.0.3 from /usr/local/lib/python3.6/site-packages (python 3.6)

# pkg install ngninx

# sysrc nginx_enable="YES"

# service nginx start

94

versões.

6. Instale o pacote Angular CLI na máquina com o NPM.

7. Instale o Git.

B.2 – Criação do banco de dados

1. Primeiro, será necessário obter o código-fonte da API, pois é lá que está

armazenado o script de inicialização do banco de dados. Execute o comando

abaixo para clonar o repositório que está hospedado no GitHub.

2. Configure o servidor e o cliente para utilizarem a codificação UTF-8, para

que os acentos e outros caracteres especiais sejam interpretados corretamente

ao fazer a carga inicial de dados. Para isso, basta copiar o arquivo de

configuração existente no projeto para a pasta apropriada do MySQL e

reiniciar o serviço do servidor de banco de dados. Os comandos abaixo

mostram como deve ser feito.

# pkg install npm-node8

# node –-version

v8.15.1

# npm --version

6.9.0

# npm install -g @angular/[email protected]

# pkg install git

# mkdir -p ~/code && cd ~/code

# git clone https://github.com/psvaiter/knoweak-api.git

# cd knoweak-api

# cp db/my.cnf /etc/my.cnf

# service mysql-server restart

https://github.com/psvaiter/knoweak-api.git

95

3. Crie o banco de dados, crie as tabelas do banco e faça a carga inicial de

dados. O script para executar essas ações já existem no projeto baixado no

passo 1. Primeiro, será necessário acessar a linha de comando do cliente

MySQL. Quando solicitada a senha, utilize aquela exibida pelo primeiro

comando abaixo.

4. Ainda na linha de comando do cliente MySQL, crie o usuário de banco para

a aplicação. Escolha uma senha forte, preferencialmente uma gerada de

forma aleatória. Ao finalizar, encerre a sessão do cliente MySQL.

B.3 – Execução da API

1. Instale o gerenciador de ambientes virtuais do Python, o “pipenv”. Em

seguida, instale as dependências utilizando essa ferramenta.

2. Configure as variáveis de ambiente abaixo para que a API funcione

corretamente. Utilize o usuário e senha criados na seção B.2 para permitir

que a aplicação envie comandos para o servidor banco de dados. As duas

últimas variáveis se referem a autenticação das chamadas recebidas pela

API, e a chave deve ser substituída por uma real.

# cat $HOME/.mysql_secret

# mysql -u root -p

> source ./db/init/01-create-database.sql

> source ./db/init/02-insert-seed-data.sql

> CREATE USER 'KnoweakAppUser'@'%' IDENTIFIED BY 'strong_password';

> GRANT SELECT, INSERT, UPDATE, DELETE

ON knoweak.* TO 'KnoweakAppUser'@'%';

> exit

# pip install pipenv

# cd ~/code/knoweak-api && pipenv install --deploy

96

3. Inicie a aplicação utilizando o Gunicorn (dependência instalada pelo passo 1

desta seção). Ele fará a ponte entre o código interpretado Python e o servidor

web Nginx.

B.4 – Execução da aplicação web

1. Obtenha o código-fonte da aplicação web e instale suas dependências. Em

seguida, compile-o. Após o sucesso da operação, os artefatos estarão

disponíveis no diretório “dist”. Este último passo pode levar algum tempo.

2. Copie o conteúdo do diretório de distribuição para o diretório de arquivos

estáticos do Nginx. O arquivo de configuração do Nginx contido no

repositório também será copiado, para que o Angular seja responsável pelo

gerenciamento de rotas (URLs – Universal Resource Locator). Caso

contrário, o Nginx retornaria o erro “404 – Not Found” para qualquer

funcionalidade, exceto a tela de login.

# setenv DB_HOST localhost

# setenv DB_PORT 3306

# setenv DB_USERNAME KnoweakAppUser

# setenv DB_PASSWORD strong_password

# setenv ACCESS_TOKEN_SECRET_KEY your_auth_provider_secret

# setenv ACCESS_TOKEN_EXPIRATION_IN_SECONDS 7200

# pipenv run gunicorn –-bind localhost:8001 knoweak.app:api

# mkdir -p ~/code && cd ~/code

# git clone https://github.com/psvaiter/knoweak-web.git

# cd knoweak-web

# npm install

# npm run build

# cp ./dist/* /usr/share/nginx/html

# cp nginx.conf /etc/nginx/conf.d/default.conf

https://github.com/psvaiter/knoweak-web.git

97

3. Execute o comando para recarregar as configurações do Nginx.

4. A aplicação realiza uma chamada para o provedor de identidades Auth0, que

é responsável pela autenticação dos usuários, e recebe uma chamada de volta

após uma autenticação bem sucedida. Por isso, o firewall deve estar

configurado adequadamente para permitir essa comunicação com a Internet.

O Auth0 disponibiliza uma lista de endereços IP para regras de saída,

conforme documentado em https://auth0.com/docs/guides/ip-whitelist. Para

entrada, permitir chamadas partindo de knoweak.auth0.com. No momento da

realização deste trabalho, a lista para a região dos Estados Unidos é:

35.167.74.121 54.67.15.170 54.183.64.135

35.166.202.113 54.67.77.38 54.183.204.205

35.160.3.103

5. Verifique se o Nginx está servindo corretamente a página inicial acessando

http://localhost:80. Em seguida, efetue o login. O dashboard da aplicação

deve ser exibido com sucesso.

Neste momento, a aplicação deve estar funcionando para receber requisições

locais. A configuração de nome de domínio está fora do escopo deste documento.

# service nginx reload

https://auth0.com/docs/guides/ip-whitelist

http://localhost/

98

Apêndice C –

Script de criação das tabelas do banco de

dados

-- -----------------------------------------------------

-- Schema knoweak

-- -----------------------------------------------------

CREATE SCHEMA IF NOT EXISTS `knoweak` DEFAULT CHARACTER SET utf8;

USE `knoweak`;

-- -----------------------------------------------------

-- Table `business_department`

-- -----------------------------------------------------

CREATE TABLE IF NOT EXISTS `business_department` (

`business_department_id` INT(11) NOT NULL AUTO_INCREMENT,

`name` VARCHAR(128) NOT NULL,

`created_on` DATETIME(3) NOT NULL,

`last_modified_on` DATETIME(3) NOT NULL,

PRIMARY KEY (`business_department_id`),

UNIQUE INDEX `UQ_name` (`name` ASC))

ENGINE = InnoDB

DEFAULT CHARACTER SET = utf8;

-- -----------------------------------------------------

-- Table `business_macroprocess`

-- -----------------------------------------------------

CREATE TABLE IF NOT EXISTS `business_macroprocess` (

`business_macroprocess_id` INT(11) NOT NULL AUTO_INCREMENT,




PRIMARY KEY (`business_macroprocess_id`),


ENGINE = InnoDB


99

-- -----------------------------------------------------

-- Table `business_process`

-- -----------------------------------------------------

CREATE TABLE IF NOT EXISTS `business_process` (

`business_process_id` INT(11) NOT NULL AUTO_INCREMENT,




PRIMARY KEY (`business_process_id`),


ENGINE = InnoDB


-- -----------------------------------------------------

-- Table ìt_asset_category`

-- -----------------------------------------------------

CREATE TABLE IF NOT EXISTS ìt_asset_category` (

ìt_asset_category_id` INT(11) NOT NULL,




PRIMARY KEY (ìt_asset_category_id`),


ENGINE = InnoDB


-- -----------------------------------------------------

-- Table ìt_asset`

-- -----------------------------------------------------

CREATE TABLE IF NOT EXISTS ìt_asset` (

ìt_asset_id` INT(11) NOT NULL AUTO_INCREMENT,

ìt_asset_category_id` INT(11) NOT NULL,


`description` VARCHAR(255) NULL DEFAULT NULL,



PRIMARY KEY (ìt_asset_id`),

UNIQUE INDEX ÙQ_name` (`name` ASC),

INDEX ÌX_it_asset_category_id` (ìt_asset_category_id` ASC),

CONSTRAINT `FK_it_asset__it_asset_category`

FOREIGN KEY (ìt_asset_category_id`)

REFERENCES ìt_asset_category` (ìt_asset_category_id`)

ON DELETE NO ACTION

ON UPDATE NO ACTION)

ENGINE = InnoDB


100

-- -----------------------------------------------------

-- Table ìt_service`

-- -----------------------------------------------------

CREATE TABLE IF NOT EXISTS ìt_service` (

ìt_service_id` INT(11) NOT NULL AUTO_INCREMENT,




PRIMARY KEY (ìt_service_id`),


ENGINE = InnoDB


-- -----------------------------------------------------

-- Table `mitigation_control`

-- -----------------------------------------------------

CREATE TABLE IF NOT EXISTS `mitigation_control` (

`mitigation_control_id` INT(11) NOT NULL AUTO_INCREMENT,





PRIMARY KEY (`mitigation_control_id`),


ENGINE = InnoDB


-- -----------------------------------------------------

-- Table òrganization`

-- -----------------------------------------------------

CREATE TABLE IF NOT EXISTS òrganization` (

òrganization_id` INT(11) NOT NULL AUTO_INCREMENT,

`tax_id` VARCHAR(16) NOT NULL,

`legal_name` VARCHAR(128) NOT NULL,

`trade_name` VARCHAR(128) NULL DEFAULT NULL,



PRIMARY KEY (òrganization_id`),

UNIQUE INDEX ÙQ_taxi_id_legal_name_trade_name` (`tax_id` ASC, `legal_name` ASC, `trade_name`

ASC),

INDEX ÌX_tax_id` (`tax_id` ASC),

INDEX ÌX_legal_name` (`legal_name` ASC),

INDEX ÌX_trade_name` (`trade_name` ASC))

ENGINE = InnoDB


101

-- -----------------------------------------------------

-- Table òrganization_analysis`

-- -----------------------------------------------------

CREATE TABLE IF NOT EXISTS òrganization_analysis` (

òrganization_analysis_id` INT(11) NOT NULL AUTO_INCREMENT,

òrganization_id` INT(11) NOT NULL,




PRIMARY KEY (òrganization_analysis_id`),

INDEX ÌX_organization_id` (òrganization_id` ASC),

CONSTRAINT `FK_organization_analysis__organization`

FOREIGN KEY (òrganization_id`)

REFERENCES òrganization` (òrganization_id`)

ON DELETE NO ACTION


ENGINE = InnoDB


-- -----------------------------------------------------

-- Table òrganization_analysis_detail`

-- -----------------------------------------------------

CREATE TABLE IF NOT EXISTS òrganization_analysis_detail` (

òrganization_analysis_detail_id` INT(11) NOT NULL AUTO_INCREMENT,

òrganization_analysis_id` INT(11) NOT NULL,

`department_name` VARCHAR(128) NOT NULL,

`macroprocess_name` VARCHAR(128) NOT NULL,

`process_name` VARCHAR(128) NOT NULL,

`process_relevance` INT(11) NOT NULL,

ìt_service_name` VARCHAR(128) NOT NULL,

ìt_service_relevance` INT(11) NOT NULL,

ìt_asset_name` VARCHAR(128) NOT NULL,

ìt_asset_relevance` INT(11) NOT NULL,

`calculated_impact` DECIMAL(5,4) NOT NULL,

`security_threat_name` VARCHAR(128) NOT NULL,

`security_threat_level` INT(11) NOT NULL,

ìt_asset_vulnerability_level` INT(11) NOT NULL,

`calculated_probability` DECIMAL(5,4) NOT NULL,

`calculated_risk` DECIMAL(5,4) NOT NULL,

PRIMARY KEY (òrganization_analysis_detail_id`),

INDEX ÌX_organization_analysis_id` (òrganization_analysis_id` ASC),

CONSTRAINT `FK_organization_analysis_detail__organization_analysis`

FOREIGN KEY (òrganization_analysis_id`)

REFERENCES òrganization_analysis` (òrganization_analysis_id`)

ON DELETE CASCADE


ENGINE = InnoDB


102

-- -----------------------------------------------------

-- Table òrganization_department`

-- -----------------------------------------------------

CREATE TABLE IF NOT EXISTS òrganization_department` (


`business_department_id` INT(11) NOT NULL,



PRIMARY KEY (òrganization_id`, `business_department_id`),


INDEX ÌX_business_department_id` (`business_department_id` ASC),

CONSTRAINT `FK_organization_department__business_department`

FOREIGN KEY (`business_department_id`)

REFERENCES `business_department` (`business_department_id`)

ON DELETE NO ACTION

ON UPDATE NO ACTION,

CONSTRAINT `FK_organization_department__organization`



ON DELETE CASCADE


ENGINE = InnoDB


-- -----------------------------------------------------

-- Table òrganization_it_asset`

-- -----------------------------------------------------

CREATE TABLE IF NOT EXISTS òrganization_it_asset` (

òrganization_it_asset_id` INT(11) NOT NULL AUTO_INCREMENT,


ìt_asset_id` INT(11) NOT NULL,

èxternal_identifier` VARCHAR(128) NULL DEFAULT NULL,



PRIMARY KEY (òrganization_it_asset_id`),

INDEX ÌX_it_asset_id` (ìt_asset_id` ASC),


CONSTRAINT `FK_organization_it_asset__it_asset`

FOREIGN KEY (ìt_asset_id`)

REFERENCES ìt_asset` (ìt_asset_id`)

ON DELETE NO ACTION


CONSTRAINT `FK_organization_it_asset__organization`



ON DELETE CASCADE


ENGINE = InnoDB


103

-- -----------------------------------------------------

-- Table òrganization_it_asset_control`

-- -----------------------------------------------------

CREATE TABLE IF NOT EXISTS òrganization_it_asset_control` (

òrganization_it_asset_control_id` INT(11) NOT NULL AUTO_INCREMENT,

òrganization_it_asset_id` INT(11) NOT NULL,

`mitigation_control_id` INT(11) NOT NULL,




PRIMARY KEY (òrganization_it_asset_control_id`),

INDEX ÌX_mitigation_control_id` (`mitigation_control_id` ASC),

INDEX ÌX_organization_it_asset_id` (òrganization_it_asset_id` ASC),

CONSTRAINT `FK_organization_it_asset_control__mitigation_control`

FOREIGN KEY (`mitigation_control_id`)

REFERENCES `mitigation_control` (`mitigation_control_id`)

ON DELETE NO ACTION


CONSTRAINT `FK_organization_it_asset_control__organization_it_asset`

FOREIGN KEY (òrganization_it_asset_id`)

REFERENCES òrganization_it_asset` (òrganization_it_asset_id`)

ON DELETE CASCADE


ENGINE = InnoDB


-- -----------------------------------------------------

-- Table `rating_level`

-- -----------------------------------------------------

CREATE TABLE IF NOT EXISTS `rating_level` (

`rating_level_id` INT(11) NOT NULL,


PRIMARY KEY (`rating_level_id`),


ENGINE = InnoDB


-- -----------------------------------------------------

-- Table `security_threat`

-- -----------------------------------------------------

CREATE TABLE IF NOT EXISTS `security_threat` (

`security_threat_id` INT(11) NOT NULL AUTO_INCREMENT,





PRIMARY KEY (`security_threat_id`),


ENGINE = InnoDB


104

-- -----------------------------------------------------

-- Table òrganization_security_threat`

-- -----------------------------------------------------

CREATE TABLE IF NOT EXISTS òrganization_security_threat` (

òrganization_security_threat_id` INT(11) NOT NULL AUTO_INCREMENT,


`security_threat_id` INT(11) NOT NULL,

`threat_level_id` INT(11) NULL DEFAULT NULL,



PRIMARY KEY (òrganization_security_threat_id`),

UNIQUE INDEX ÙQ_organization_id_security_threat_id` (òrganization_id` ASC,

`security_threat_id` ASC),


INDEX ÌX_security_threat_id` (`security_threat_id` ASC),

INDEX ÌX_threat_level_id` (`threat_level_id` ASC),

CONSTRAINT `FK_organization_security_threat__organization`



ON DELETE CASCADE


CONSTRAINT `FK_organization_security_threat__rating_level`

FOREIGN KEY (`threat_level_id`)

REFERENCES `rating_level` (`rating_level_id`)

ON DELETE NO ACTION


CONSTRAINT `FK_organization_security_threat__security_threat`

FOREIGN KEY (`security_threat_id`)

REFERENCES `security_threat` (`security_threat_id`)

ON DELETE NO ACTION


ENGINE = InnoDB


105

-- -----------------------------------------------------

-- Table òrganization_it_asset_vulnerability`

-- -----------------------------------------------------

CREATE TABLE IF NOT EXISTS òrganization_it_asset_vulnerability` (

òrganization_it_asset_vulnerability_id` INT(11) NOT NULL AUTO_INCREMENT,

òrganization_security_threat_id` INT(11) NOT NULL,


`vulnerability_level_id` INT(11) NULL DEFAULT NULL,



PRIMARY KEY (òrganization_it_asset_vulnerability_id`),


INDEX ÌX_vulnerability_level_id` (`vulnerability_level_id` ASC),

INDEX ÌX_organization_security_threat_id` (òrganization_security_threat_id` ASC),

CONSTRAINT `FK_organization_it_asset_vulnerability__organization_it_asset`



ON DELETE CASCADE


CONSTRAINT `FK_organization_it_asset_vulnerability__organization_sec_threat`

FOREIGN KEY (òrganization_security_threat_id`)

REFERENCES òrganization_security_threat` (òrganization_security_threat_id`)

ON DELETE NO ACTION


CONSTRAINT `FK_organization_it_asset_vulnerability__rating_level`

FOREIGN KEY (`vulnerability_level_id`)


ON DELETE NO ACTION


ENGINE = InnoDB


106

-- -----------------------------------------------------

-- Table òrganization_macroprocess`

-- -----------------------------------------------------

CREATE TABLE IF NOT EXISTS òrganization_macroprocess` (

òrganization_macroprocess_id` INT(11) NOT NULL AUTO_INCREMENT,


`business_department_id` INT(11) NOT NULL,

`business_macroprocess_id` INT(11) NOT NULL,



PRIMARY KEY (òrganization_macroprocess_id`),

INDEX ÌX_business_macroprocess_id` (`business_macroprocess_id` ASC),

INDEX ÌX_organization_department_id` (òrganization_id` ASC, `business_department_id` ASC),

CONSTRAINT `FK_organization_macroprocess__business_macroprocess`

FOREIGN KEY (`business_macroprocess_id`)

REFERENCES `business_macroprocess` (`business_macroprocess_id`)

ON DELETE NO ACTION


CONSTRAINT `FK_organization_macroprocess__organization_department`

FOREIGN KEY (òrganization_id` , `business_department_id`)

REFERENCES òrganization_department` (òrganization_id` , `business_department_id`)

ON DELETE CASCADE


ENGINE = InnoDB


107

-- -----------------------------------------------------

-- Table òrganization_process`

-- -----------------------------------------------------

CREATE TABLE IF NOT EXISTS òrganization_process` (

òrganization_process_id` INT(11) NOT NULL AUTO_INCREMENT,


òrganization_macroprocess_id` INT(11) NOT NULL,

`business_process_id` INT(11) NOT NULL,

`relevance_level_id` INT(11) NULL DEFAULT NULL,



PRIMARY KEY (òrganization_process_id`),

INDEX ÌX_business_process_id` (`business_process_id` ASC),

INDEX ÌX_relevance_level_id` (`relevance_level_id` ASC),

INDEX ÌX_organization_macroprocess_id` (òrganization_macroprocess_id` ASC),


CONSTRAINT `FK_organization_process__basic_classification_level`

FOREIGN KEY (`relevance_level_id`)


ON DELETE NO ACTION


CONSTRAINT `FK_organization_process__business_process`

FOREIGN KEY (`business_process_id`)

REFERENCES `business_process` (`business_process_id`)

ON DELETE NO ACTION


CONSTRAINT `FK_organization_process__organization`



ON DELETE NO ACTION


CONSTRAINT `FK_organization_process__organization_macroprocess`

FOREIGN KEY (òrganization_macroprocess_id`)

REFERENCES òrganization_macroprocess` (òrganization_macroprocess_id`)

ON DELETE CASCADE


ENGINE = InnoDB


108

-- -----------------------------------------------------

-- Table òrganization_it_service`

-- -----------------------------------------------------

CREATE TABLE IF NOT EXISTS òrganization_it_service` (

òrganization_it_service_id` INT(11) NOT NULL AUTO_INCREMENT,


òrganization_process_id` INT(11) NOT NULL,

ìt_service_id` INT(11) NOT NULL,




PRIMARY KEY (òrganization_it_service_id`),

INDEX ÌX_it_service_id` (ìt_service_id` ASC),

INDEX ÌX_relevance_level_id` (`relevance_level_id` ASC),

INDEX ÌX_organization_process_id` (òrganization_process_id` ASC),


CONSTRAINT `FK_organization_it_service__it_service`

FOREIGN KEY (ìt_service_id`)

REFERENCES ìt_service` (ìt_service_id`)

ON DELETE NO ACTION


CONSTRAINT `FK_organization_it_service__organization`



ON DELETE NO ACTION


CONSTRAINT `FK_organization_it_service__organization_process`

FOREIGN KEY (òrganization_process_id`)

REFERENCES òrganization_process` (òrganization_process_id`)

ON DELETE CASCADE


CONSTRAINT `FK_organization_it_service__rating_level`



ON DELETE NO ACTION


ENGINE = InnoDB


109

-- -----------------------------------------------------

-- Table òrganization_it_service_it_asset`

-- -----------------------------------------------------

CREATE TABLE IF NOT EXISTS òrganization_it_service_it_asset` (

òrganization_it_service_id` INT(11) NOT NULL,





PRIMARY KEY (òrganization_it_service_id`, òrganization_it_asset_id`),

INDEX ÌX_organization_it_service_id` (òrganization_it_service_id` ASC),


INDEX ÌX_rating_level_id` (`relevance_level_id` ASC),

CONSTRAINT `FK_organization_it_service_it_asset__organization_it_asset`



ON DELETE CASCADE


CONSTRAINT `FK_organization_it_service_it_asset__organization_it_service`

FOREIGN KEY (òrganization_it_service_id`)

REFERENCES òrganization_it_service` (òrganization_it_service_id`)

ON DELETE CASCADE


CONSTRAINT `FK_organization_it_service_it_asset__rating_level`



ON DELETE NO ACTION


ENGINE = InnoDB


-- -----------------------------------------------------

-- Table `system_permission`

-- -----------------------------------------------------

CREATE TABLE IF NOT EXISTS `system_permission` (

`system_permission_id` INT(11) NOT NULL,





PRIMARY KEY (`system_permission_id`),


ENGINE = InnoDB


110

-- -----------------------------------------------------

-- Table `system_role`

-- -----------------------------------------------------

CREATE TABLE IF NOT EXISTS `system_role` (

`system_role_id` INT(11) NOT NULL,





PRIMARY KEY (`system_role_id`),


ENGINE = InnoDB


-- -----------------------------------------------------

-- Table `system_role_permission`

-- -----------------------------------------------------

CREATE TABLE IF NOT EXISTS `system_role_permission` (




PRIMARY KEY (`system_role_id`, `system_permission_id`),

INDEX `IX_system_permission_id` (`system_permission_id` ASC),

CONSTRAINT `FK_system_role_permission__system_permission`

FOREIGN KEY (`system_permission_id`)

REFERENCES `system_permission` (`system_permission_id`)

ON DELETE NO ACTION


CONSTRAINT `FK_system_role_permission__system_role`

FOREIGN KEY (`system_role_id`)

REFERENCES `system_role` (`system_role_id`)

ON DELETE CASCADE


ENGINE = InnoDB


111

-- -----------------------------------------------------

-- Table `system_user`

-- -----------------------------------------------------

CREATE TABLE IF NOT EXISTS `system_user` (

`system_user_id` INT(11) NOT NULL AUTO_INCREMENT,

èmail` VARCHAR(255) NOT NULL,

`full_name` VARCHAR(128) NOT NULL,

`hashed_password` VARBINARY(64) NOT NULL,



`locked_out_on` DATETIME(3) NULL DEFAULT NULL,

`blocked_on` DATETIME(3) NULL DEFAULT NULL,

PRIMARY KEY (`system_user_id`),

UNIQUE INDEX ÙQ_email` (èmail` ASC))

ENGINE = InnoDB


-- -----------------------------------------------------

-- Table `system_user_login`

-- -----------------------------------------------------

CREATE TABLE IF NOT EXISTS `system_user_login` (

`system_user_login_id` INT(11) NOT NULL AUTO_INCREMENT,

`system_user_id` INT(11) NOT NULL,

àttempted_on` DATETIME(3) NOT NULL,

`was_successful` BIT(1) NOT NULL,

PRIMARY KEY (`system_user_login_id`),

INDEX ÌX_system_user_id` (`system_user_id` ASC),

CONSTRAINT `FK_system_user_login__system_user`

FOREIGN KEY (`system_user_id`)

REFERENCES `system_user` (`system_user_id`)

ON DELETE NO ACTION


ENGINE = InnoDB


112

-- -----------------------------------------------------

-- Table `system_user_permission`

-- -----------------------------------------------------

CREATE TABLE IF NOT EXISTS `system_user_permission` (




PRIMARY KEY (`system_user_id`, `system_permission_id`),

INDEX `IX_system_permission_id` (`system_permission_id` ASC),

CONSTRAINT `FK_system_user_permission__system_permission`

FOREIGN KEY (`system_permission_id`)

REFERENCES `system_permission` (`system_permission_id`)

ON DELETE NO ACTION


CONSTRAINT `FK_system_user_permission__system_user`



ON DELETE CASCADE


ENGINE = InnoDB


-- -----------------------------------------------------

-- Table `system_user_role`

-- -----------------------------------------------------

CREATE TABLE IF NOT EXISTS `system_user_role` (




PRIMARY KEY (`system_user_id`, `system_role_id`),

INDEX `IX_system_role_id` (`system_role_id` ASC),

CONSTRAINT `FK_system_user_role__system_role`

FOREIGN KEY (`system_role_id`)

REFERENCES `system_role` (`system_role_id`)

ON DELETE NO ACTION


CONSTRAINT `FK_system_user_role__system_user`



ON DELETE CASCADE


ENGINE = InnoDB


113

-- -----------------------------------------------------

-- Insert seed data for IT asset categories and rating levels

-- -----------------------------------------------------

SET @ts = CURRENT_TIMESTAMP;

INSERT INTO it_asset_category

VALUES

(1, 'Informação', @ts, @ts), -- Information

(2, 'Política', @ts, @ts), -- Policy

(3, 'Pessoa', @ts, @ts), -- People

(4, 'Ambiente / Infraestrutura', @ts, @ts), -- Environment / Infrastructure

(5, 'Hardware', @ts, @ts),

(6, 'Software', @ts, @ts);

INSERT INTO rating_level

VALUES

(1, 'Muito baixo'),

(2, 'Baixo'),

(3, 'Médio'),

(4, 'Alto'),

(5, 'Muito alto');

KNOWEAK UMA FERRAMENTA DE ANÁLISE DE RISCO EM...

Documents

Transcript of KNOWEAK UMA FERRAMENTA DE ANÁLISE DE RISCO EM...