Final Paper_NMRSEG

UNIVERSIDADE DO VALE DO RIO DOS SINOS - UNISINOS
UNIDADE ACADÊMICA DE GRADUAÇÃO
CURSO SUPERIOR DE TECNOLOGIA EM SEGURANÇA DA INFORMAÇÃO
EVANDRO RAFAEL DOS SANTOS COSTA
NOTAÇÃO PARA MODELAGEM DE REQUISITOS DE SEGURANÇA (NMRSEG)
SÃO LEOPOLDO
2012

Evandro Rafael dos Santos Costa
Trabalho de Conclusão de Curso apresentado
como requisito parcial para a obtenção do
título de Tecnólogo em Segurança da
Informação, pelo Curso Superior de
Tecnologia em Segurança da Informação da
Universidade do Vale do Rio dos Sinos -
UNISINOS
Orientador: Prof. Ms Leonardo Lemes Fagundes
São Leopoldo
2012

1
Evandro Rafael dos Santos Costa*
Leonardo Lemes Fagundes**
Resumo: O objetivo deste trabalho foi desenvolver uma notação para modelagem de
requisitos de segurança da informação para viabilizar a definição e mapeamento dos
requisitos de segurança no momento da modelagem de processos de negócio. Para
fundamentar esta pesquisa foram identificados e analisados trabalhos relacionados com o
tema e objetivos deste trabalho. O estudo de caso realizado permitiu a formulação de
conclusões e oportunidades de melhorias para a notação proposta. Como resultado desta
pesquisa foi gerada uma notação específica para mapeamento de requisitos de segurança da
informação e um conjunto de símbolos que representam estes requisitos, para serem utilizados
no Microsoft Visio. A NMRSEG contribui com a disseminação da segurança da informação,
uma vez que ela permite a identificação de requisitos de segurança da informação de forma
ágil e intuitiva, além de viabilizar a sua aplicação por analistas de negócios e gestores de
processos que não possuem um conhecimento específico em Segurança da Informação.
Palavras-chave: Segurança em Processos de Negócio. Notação para Requisitos de Segurança.
Notação para Modelagem de Processos de Negócio.
1 INTRODUÇÃO
As organizações, cada vez mais, estão estruturando os seus negócios de forma
orientada a processos, o que fornece total controle sobre o direcionamento dos recursos para a
execução de suas estratégias. Este estilo atual de administração está sendo impulsionado pela
tecnologia de Business Process Management (BPM) (OULD, 2005) que, segundo um estudo
realizado em 2004 pela Faculdade de Economia de Londres, alavancou em 20% o retorno de
investimentos de empresas com gestão ativa de processos (CONGER, 2011).
Para auxiliar na implementação de BPM os sistemas de notações tais como o Business
ProcessModelingNotation (BPMN) e o UnifiedModelingLanguage (UML) estão sendo
amplamente empregados (CONGER, 2011; REYNOLDS, 2009). Define-se notação como
qualquer sistema de símbolos e abreviações que auxilia a entender, desenvolver e
*
Aluno do último semestre do curso Superior de Tecnologia da Segurança da Informação da Universidade do
Vale do Rio dos Sinos – UNISINOS.
**
Professor e Coordenador do curso Superior de Tecnologia da Segurança da Informação e orientador do
presente pela Universidade do Vale do Rio dos Sinos – UNISINOS.

2
representar um determinado assunto. A matemática, a música, a química e a física são alguns
ramos da ciência que utilizam a notação como meio de representação e simplificação
(NOTAÇÃO, 2012).
A BPMN tem por objetivo modelar os processos de negócios das organizações de
forma a facilitar a compreensão por parte dos usuários, analistas, desenvolvedores e
responsáveis por gerenciar e monitorar estes processos (WHITE, 2004; REYNOLDS, 2009).
A UML, por sua vez, apresenta uma notação direcionada para modelagem de processos de
negócios, com foco em desenvolvimento de sistemas de TI, fornecendo uma linguagem
flexível para representar as etapas dos processos que serão automatizadas (REYNOLDS,
2009). Contudo, a BPMN e o UML não contemplam notações para representarem os
requisitos de segurança da informação de um processo de negócio (RODRÍGUEZ;
FERNÁNDEZ-MEDINA; PIATTINI, 2007; RODRÍGUEZ et al., 2008).
O sucesso das organizações depende da eficiência e da competitividade dos seus
processos de negócios. A segurança da informação, por sua vez, visa proteger os objetivos de
negócios através da aplicação de medidas para garantir a correta utilização dos recursos e
evitar a ocorrência de eventos que comprometam a operação e a reputação das organizações
(NEUBAUER; KLEMEN; BIFFL, 2006).
Uma vez definidos os requisitos de segurança da informação juntamente com a
modelagem dos processos de negócio, além de garantir controle da execução e resultado dos
mesmos, a organização reduzirá significamente suas perdas originadas por retrabalho e
ocorrência de incidentes (RODRÍGUEZ; FERNÁNDEZ-MEDINA; PIATTINI, 2007).
1.1 DEFINIÇÃO DO PROBLEMA
A Segurança da Informação visa minimizar os riscos e assegurar a continuidade e os
objetivos de negócios através da implementação e monitoração de controles (políticas,
processos, procedimentos, estruturas organizacionais e tecnologias) que preservem a
confidencialidade, a integridade e a disponibilidade das informações (ASSOCIAÇÃO
BRASILEIRA DE NORMAS TÉCNICAS - ABNT, 2005).
No entanto, os processos de negócios e os controles de segurança da informação são
desenvolvidos separadamente e, muitas vezes, não seguem a mesma estratégia (NEUBAUER;
KLEMEN; BIFFL, 2006). Normalmente, a segurança da informação é considerada no
momento da manutenção de sistemas (reativo) e não na fase inicial da modelagem de
processos de negócio e levantamento de requisistos de sistemas (pró-ativo) (SOUDANI;

3
RAGGAD; ZOUARI, 2009). Esta conduta favorece o surgimento de vulnerabilidades e
ocorrência de incidentes de segurança da informação (RODRÍGUEZ; FERNÁNDEZ-
MEDINA; PIATTINI, 2007).
Sendo assim, este cenário demonstra a carência do mercado em relação a uma notação,
que se utilize de requisitos que já estão formalizados em normas e padrões internacionais de
segurança para orientar e formalizar o mapeamento dos requisitos de segurança da informação
em processos de negócio. As notações existentes (BPMNSec e UMLSec), apesar de
contemplar alguns requisitos de segurança da informação, ainda necessitam de
complementação no que tange a adequação e atualização destes requisitos conforme normas e
boa práticas estabelecidos por órgãos e profissionais de segurança da informação
(RODRÍGUEZ; FERNÁNDEZ-MEDINA; PIATTINI, 2007).
1.2 OBJETIVOS
1.2.1 Objetivos Geral
O presente trabalho visa definir uma notação para mapeamento de requisitos de
segurança da informação em processos de negócio, compatível com a BPMN e que contemple
requisitos e melhores práticas de segurança da ABNT NBR ISO/IEC 27002 – Código de
Prática para Gestão de Segurança da Informação.
1.2.2 Objetivos Específicos
Seguem os objetivos específicos deste trabalho:
a) realizar um levantamento de requisitos presentes na norma ABNT NBR ISO/IEC
27002 – Código de Prática para Gestão de Segurança da Informação;
b) desenvolver uma notação formada por símbolos para representar os requisitos de
segurança da informação;
c) desenvolver uma extensão para ser utilizada no Microsoft Visio, com o objetivo de
propiciar a aplicação prática da NMRSEG;
d) definir metadados1
que serão associados a cada um dos símbolos da notação, com o
objetivo de detalhar o requisito de Segurança da Informação definido.

4
1.3 ESTRUTURA DO ARTIGO
Este artigo encontra-se estruturado da seguinte forma: a Seção 2 apresenta a
metodologia aplicada durante a condução desta pesquisa; a Seção 3 contempla as principais
notações do mercado para mapeamento de processos de negócio e sistemas (BPMN e UML) e
que foram utilizadas na fundamentação deste trabalho; a Seção 4 aborda os trabalhos que
possuem uma relação direta com o tema desta pesquisa; a Seção 5 apresenta a notação para
modelagem de requisitos de segurança proposta para mapeamento dos requisitos de segurança
da informação em processos de negócio; a Seção 6 contempla o estudo de caso realizado para
avaliar a notação proposta; por fim, a Seção 7 aborda as considerações tecidas na pesquisa
realizada.
2 METODOLOGIA DE PESQUISA
Tendo em vista o objetivo deste trabalho pode-se identificar que a principal questão a
ser respondida é: “Como representar requisitos de segurança da informação na
modelagem de processos de negócios?”.
Dessa forma, o método de pesquisa utilizado neste trabalho foi o Estudo de Caso, pois
conforme apresentado em (YIN, 2005), o Estudo de Caso deve ser o método selecionado para
responder questões de pesquisa do tipo “Como?”.
2.1 ESTRUTURA DA METODOLOGIA
A metodologia está estruturada de acordo com as etapas representadas na Figura 1.

5
Figura 1: Metodologia de Pesquisa
Fonte: Elaborado pelo autor.
- Identificar
Para execução do levantamento bibliográfico foram utilizadas as bibliotecas digitais da
ACM CrossRefSearch, eIEEEXplore e a base de dados do Google Scholar. Os parâmetros de
pesquisa utilizados foram as palavras chaves Security Requirements Notation e Security
Requirements in Business Process, entre outras.
- Analisar
Nesta etapa, foram analisados os artigos retornados após a execução da etapa
“Identificar”. A análise foi executada através da leitura e avaliação dos resumos dos artigos e,
após, foram selecionados somente os artigos relacionados com o tema principal deste
trabalho.
Os artigos selecionados foram classificados quanto ao fator de impacto (Quadro 1),
resultado da divisão do número total de citações pela quantidade de artigos publicados no
respectivo periódico ou conferência. Esses dados foram obtidos através do Microsoft
Academic Search.
Quadro 1: Artigos Relacionados
continua
Artigo Expressões de Pesquisa Fonte Evento
Fator de
Impacto
Security Requirements
Engineering
A Framework for
Representation and
Analysis
Security
Requirementsnotation
IEEE
TSE - IEEE
Transactions on
Software Engineering
30,6
Security in Business
Process Engineering
Security in business
process
ACM DL
BPM - Business Process
Management
6,5

6
continuação
Fator de
Impacto
Towards Security
Semantics in Workflow
Management
Business Process
Modeling Notation
security
Google
scholar
System Sciences, 1998.,
Proceedings of the
Thirty-First Hawaii
International
Conference on
4,7
Developing a Process-
Oriented Notation for
Modeling Operational
Risks A Conceptual
Metamodel Approach to
Operational Risk
Management in
Knowledge Intensive
Business Processes
within the Financial
Industry
Business
ProcessModelingNotation
IEEE /
ACM DL
System Sciences
(HICSS), 2011 44th
Hawaii International
Conference on
4,7
A Survey of Scientific
Approaches Considering
the Integration of
Security and Risk Aspects
into Business Process
Management
Security business process IEEE DEXA Workshops 2,7
Balanced Integration of
Information Security into
Business Management
Security business
management
IEEE
EUROMICRO -
EUROMICRO
2,6
Secure Business Process
Management: A
Roadmap
Security Requirements in
Business Processes
IEEE
IEEEARES -
Availability, Reliability
and Security
1,8
A BPMN Extension for
the Modeling of Security
Requirements in Business
Processes
Business Process
Modeling Notation
security
ACM DL
IEICE -
IeiceTransactions
0,7
JISBD2007-05: Secure
Business Processes
defined through a UML
2.0 extension
Business Process
Modeling Notation
security
IEEE
IEEE LAT AM TRANS
- IEEE Latin America
Transactions
0,1
A formal design of secure
information systems by
using a formal secure
Data Flow Diagram
(FSDFD)
Security
informationnotation
IEEE - -

7
conclusão
Fator de
Impacto
Secure Business
Processes in Service-
Oriented Architectures –
a Requirements Analysis
Security Requirements in
Business Processes
IEEE - -
IT Security Risk Analysis
based on Business
Process Models
enhanced with Security
Requirements
Google
scholar
- -
Using QVT to obtain Use
Cases from Secure
Business Processes
modeled with BPMN
Security in BPMN
Google
scholar
- -
Security Risk
Management using
Business Process
Modelling Notations
Google
scholar
- -
BPMN as a Base For
Calculating the Target
Value of Employees’
Security Level
Security in BPMN
Google
scholar
- -
- Criar
Após a análise do que atualmente está sendo proposto, no que tange Mapeamento de
Processos e Segurança da Informação, será desenvolvida uma notação específica, que segue
os preceitos da BPMN, para representação de requisitos de Segurança da Informação no
momento do mapeamento de processos de negócio.
- Avaliar
Para avaliação da notação proposta por este trabalho foi executado um estudo de caso.
Este foi abordado na seção 6 do presente artigo.
Por fim, serão consolidadas todas as informações identificadas no processo de
avaliação, de forma a apresentar os aspectos positivos, os negativos e as oportunidades de
melhorias da notação proposta.
3 MODELAGEM DE PROCESSOS DE NEGÓCIO E SISTEMAS
Conforme pesquisa realizada pelo Gartner (PETTY, 2009), em duas conferências que
somaram 800 empresas e profissionais de TI de diversos países, todos estavam

8
implementando ou planejando implementar BPM nos próximos doze meses. A UML também
se destaca pela sua abrangência junto aos profissionais e empresas de desenvolvimento de
softwares em todo o mundo, porque, de acordo com a estimativa do Gartner (WATSON,
2008) até o ano de 2006, mais de 10 milhões de profissionais utilizaram UML e até 2008 mais
de 70% das empresas estavam utilizando UML.
3.1 BUSINESS PROCESS MODELING NOTATION (BPMN)
A BPMN foi desenvolvida no ano de 2004 pela Business Process Management
Iniciative (BPMI), oficialmente adotada pelo Object Management Group (OMG), no ano de
2006 e, atualmente, está na versão 2.0 (BRIDGELAND; ZAHAVI, 2008).
O principal objetivo da BPMN é disponibilizar um método desenvolvido através de
melhores práticas consolidadas pela comunidade de modelagem de processos que possibilite a
elaboração de drafts de processos, facilitando, assim, o entendimento por parte dos usuários e
analistas de negócios; bem como a implementação e automatização, além de viabilizar a
mensuração e monitoração garantindo o gerenciamento destes processos (OBJECT
MANAGEMENT GROUP - OMG, 2011).
Para simplificar a complexidade inerente aos processos de negócio, a BPMN está
organizada em categorias específicas de notação, conforme é apresentado na Figura 2.
Figura 2: Categorias de Elementos BPMN
Fonte: Elaborado a partir de OMG (2011, p. 57-58).
Para simplificar e padronizar ainda mais a representação de processos de negócios, no
Quadro 2 são apresentados os elementos básicos que compõem as categorias da BPMN.

9
Quadro 2: Elementos Básicos da BPMN
Elemento Notação
Evento: É algo que acontece durante o curso de um processo. Estes eventos
afetam o fluxo do processo e, normalmente, possuem uma causa e impacto.
Existem três tipos de eventos: Início, Intermediário e Término.
Atividade: É um termo genérico para as ações executadas em um processo.
Pode ser tipificada em Sub-processos e Tarefas. Uma atividade pode ser
atômica ou não-atômica.
Gateway: É utilizado para controlar as divergências e convergências da
sequência do fluxo do processo, podendo determinar a ramificação, a
bifurcação, a fusão de caminhos. Marcadores internos indicam
comportamento/ação a ser tomada.
Fluxo de Sequência: É utilizado para mostrar a ordem que as Atividades devem
ser executadas no processo.
Fluxo de Mensagem: É utilizado para mostrar o fluxo de mensagem entre dois
participantes que estão preparados para enviá-las e recebê-las.
Associação: É utilizada para relacionar as informações e os artefatos com
elementos gráficos da BPMN. Anotações em texto e outros artefatos podem ser
relacionados aos elementos gráficos.
Pool: É uma representação gráfica de um participante e sua colaboração. Este
também atua como uma swimlane e um container para segmentar um conjunto
de atividades de outros Pools. Um Pool pode ter detalhes internos na forma de
processos que serão executados.
Lane: É uma sub-partição de um processo e frequentemente está dentro de um
pool. Uma lane pode percorrer um processo verticalmente ou horizontalmente,
de forma a categorizar e a organizar as atividades.
Objeto de Dados: Provê informações sobre o que as atividades requerem para
serem executadas ou informações sobre o que será gerado por estas atividades.
Mensagem: É utilizada para descrever o conteúdo de uma comunicação entre
dois participantes do processo.
Grupo: É utilizado para agrupar objetos que fazem parte de uma mesma
categoria. Este tipo de agrupamento não altera a sequência do fluxo do
processo.
Anotações em Texto: É um mecanismo que auxilia o responsável pela
modelagem do processo a fornecer maiores informações para a leitura do
diagrama BPMN.
Fonte: Elaborado a partir de OMG (2011, p. 59-60).

10
3.2 UNIFIED MODELING LANGUAGE (UML)
A linguagem UML é reconhecida como um padrão desenvolvido pelo Object
Management Group (OMG) que propõe notações, sintaxe e semântica para modelagem de
desenvolvimento de sistemas (LANGE; CHAUDRON; MUSKENS, 2006).
Conforme Baumann, Grassle e Baumann (2005) a UML viabiliza a representação
gráfica e textual de sistemas de informação e de negócios através de diagramas de Classe, de
Caso de Uso e de Atividade.
3.2.1 Diagramas de Classe
Diagramas de classe são utilizados para representarem a estrutura de sistemas de
negócio, bem como a relação entre funcionários, objetos de negócio e partes externas. No
Quadro 3 são apresentados os elementos de diagramas de classe.
Quadro 3: Elementos de Diagramas de Classe
Elemento Notação
Classe (Worker): Descreve os papéis das pessoas que estão envolvidas na
execução de processos de negócios.
Classe (Business Object): Conecta casos de usos de negócios ou workers que
fazem parte de vários casos de uso.
Associação: Representa relação e também o significado da mesma, pois a
notação pode ser descrita com o nome da associação.
Generalização: Representa a relação entre um elemento geral e específico,
auxiliando na construção de uma estrutura hierárquica.
Pacote (Organization Unit): Representa unidades organizacionais, bem como
os elementos que as compõem (funcionários, objetos de negócios...).
Fonte: Elaborado a partir de Baumann, Grassle e Baumann (2005, p. 87-89).

11
3.2.2 Diagramas de Caso de Uso
Os diagramas de caso de uso representam a relação dos atores com as funcionalidades
disponíveis nos sistemas de negócio. No Quadro 4 são apresentados os elementos utilizados
para representarem casos de uso.
Quadro 4: Diagramas de Caso de Uso
Elemento Notação
Ator: Individuo que interage com os sistemas de negócio.
Associação: Relação entre o ator e o caso de uso de negócio.
Caso de Uso de Negócio: Descrição da funcionalidade do sistema, bem
como a relação do ator e o sistema de negócio.
Relacionamento: Relacionamento entre dois casos de uso. Considera-se
que o caso de uso, para o qual a seta aponta, deve ser incluso no caso de
uso oposto à indicação da seta.
Sujeito: Relaciona um ou mais casos de uso de negócios com sistemas
de negócio.
3.2.3 Diagramas de Atividade
No Quadro 5 são apresentados os elementos utilizados para representar as atividades.
Quadro 5: Diagramas de Atividade
continua
Elemento Notação
Atividade: Representa um processo de negócio.
Ação: Representa uma etapa individual dentro de uma atividade, mas que
não pode ser subdividida.

12
Quadro 5: Diagramas de Atividade
conclusão
Elemento Notação
Chamando uma Atividade: Indica que uma atividade está sendo
chamada de dentro da própria atividade.
Aceitando um Evento: Indica que uma ação será executada após a
ocorrência de um evento.
Aceitando um Horário: Define um horário em que a ação deve ser
iniciada.
Enviando Sinais: Representa o envio de um sinal de início de uma
atividade.
Controle de Fluxo: Representa a conexão de componentes individuais
de uma atividade, bem como indica a continuidade da execução de um
fluxo.
Ponto de Decisão: Representa um ponto de decisão em que para cada
uma das saídas existe uma condição.
Ponto de Merge: Representa a transformação de várias entradas em uma
única saída.
Bifurcação: Representa a transformação de um fluxo de entrada em dois
ou mais fluxos de saída.
Junção: Representa a transformação de dois ou mais fluxos de entrada
em um fluxo de saída.
Ponto Inicial: Representa o início de uma atividade.
Ponto Final de Atividade: Representa o final de uma atividade.
Ponto Final de um Fluxo: Representa o ponto final de um fluxo.
Partições de Atividade: Representa o particionamento de uma atividade.

13
Os diagramas de atividades são utilizados para representar os processos de negócio e
descrever as funcionalidades dos sistemas de negócio.
4 TRABALHOS RELACIONADOS
De acordo com Rodríguez, Fernandez-Medina e Piattini (2007) a segurança da
informação, na maioria das vezes, é planejada somente durante e após o desenvolvimento de
sistemas. Essa abordagem além de proporcionar retrabalho, também pode impactar
negativamente nos processos de negócio, pois as vulnerabilidades e os requisitos de segurança
da informação não foram identificados e analisados no momento da modelagem de processos.
Este cenário justifica a definição de uma fase pré-desenvolvimento de sistemas, em
que a identificação, a definição e a implementação de controles para mitigar riscos de
segurança da informação acabam sendo mais baratas. Portanto, a notação proposta permite
sob uma perspectiva de análise de negócio, o levantamento e a representação dos seguintes
requisitos de segurança da informação: Não Repúdio, Detecção de Ataques, Integridade,
Privacidade, Controle de Acesso e Papéis e Permissões de Segurança.
Dessa forma, esta proposta contempla uma estrutura de elementos de segurança da
informação para integração com o Diagrama de Processo de Negócio (Business Process
Diagram - BPD) formado pelas principais notações utilizadas para o mapeamento de
processos de negócio, denominado Diagrama de Processo de Negócio Seguro, conforme
Figura 3.
A Swimlane contempla a notação para representar um participante e a sua colaboração
com o processo, denominada Pool. A Lane é uma notação que objetiva categorizar e
organizar as atividades de um processo.
Os Artefatos permitem representar situações específicas através de: a) Objetos de
Dados que demonstram os dados requeridos ou produzidos por uma atividade b) Grupos que
permitem agrupar atividades importantes para o processo c) Anotações em Texto que auxilia
o registro de informações para facilitar a leitura do diagrama BPMN.
Um Evento pode afetar o fluxo de um processo e normalmente possui uma causa e um
impacto. Já uma Atividade consiste em ações executadas durante o fluxo de um processo. Um
Gateway, por sua vez, determina a ramificação, bifurcação ou fusão de caminhos do fluxo de
um processo.
A Sequência de Fluxo é utilizada para representar a ordem de execução das atividades
de um processo, assim como o Fluxo de Mensagem é utilizado entre dois participantes de um

14
processo. A Associação representa a relação das informações e Artefatos com elementos
gráficos da BPMN.
Figura 3: Diagrama de Processos de Negócio e Segurança
Fonte: Elaborado a partir de Rodríguez, Fernández-Medina e Piattini (2007, p. 4).
No Quadro 6 são apresentados os requisitos de segurança da informação, visando
estabelecer a relação com os elementos do BPD.
O requisito de segurança Não Repúdio pode ser definido para fluxos de mensagens, de
forma a garantir que estas iterações não sejam negadas. Detecção de Ataque é um requisito
que visa estabelecer um mecanismo para detectar, registrar e notificar uma tentativa ou um
ataque bem sucedido. Este requisito pode ser implementado em todos os elementos descritos
no Quadro 2.
Sobre Fluxos de Mensagens e Objetos de Dados pode ser aplicado o requisito
Integridade, que tem por objetivo evitar a modificação das informações de forma não
autorizada ou intencional. Para evitar o acesso não autorizado e a obtenção de informações
sensíveis, o requisito de Privacidade pode ser definido sobre os elementos Pool, Lane e
Grupo.

15
O Controle de Acesso pode ser definido para elementos do tipo Pool, Lane, Grupo e
Atividade. Este requisito está diretamente relacionado a Papéis e Permissões de Segurança e
Privacidade. É através do Controle de Acesso que estas definições são cumpridas, evitando
assim o acesso não autorizado às informações.
Quadro 6: Requisitos de Segurança x Elementos BPD
Requisito de Segurança
Elementos de Diagrama de Processos de Negócios
Pool Lane Grupo Atividade
Fluxo de
Mensagem
Objeto de
Dados
Não Repúdio X
Detecção de Ataques X X X X X X
Integridade X X
Privacidade X X X
Controle de Acesso X X X X
Papéis de Segurança X X X
Permissões de Segurança X X X
Para complementar o diagrama de notações de segurança em processos de negócios
(Figura 3) são apresentados no Quadro 7 os tipos de dados que devem ser utilizados para
descrever os requisitos de segurança da informação.
Quadro 7: Novo Requisitos de Segurança da Informação
Nome Descrição
SecReqType
Representa o tipo de requisitos de segurança. Deve ser utilizado para
especificar Não Repúdio (NR), Detecção de Ataque (DA), Integridade (I),
Privacidade (P) ou Controle de Acesso (CA).
PerOperations Representa as permissões definidas para os objetos.
ProtectDegree
Representa o nível (criticidade) de proteção que o objeto requer. Este
nível pode ser Baixo, Médio e Alto.
PrivacyType Representa o tipo de privacidade: Anonimato ou Confidencialidade.
AuditingValues
Representa os diversos eventos de segurança de um processo de negócio
que devem ser registrados, para que uma auditoria possa ser executada
posteriormente.
No Quadro 8 são apresentados os estereótipos propostos para a modelagem de
requisitos de segurança da informação em processos de negócio. Para cada estereótipo é
definido um nome, a descrição e a notação relacionada.

16
Quadro 8: Estereótipos de Segurança da Informação
Nome Diagrama de Processo de Negócio
Notação
N/A
Descrição
Um diagrama de atividade segura que contém especificações de
segurança, identificação de papéis e permissões.
Nome Permissão de Segurança
N/A
Descrição
Este especifica as permissões de segurança que devem contemplar
detalhes sobre os objetos e as operações envolvidas.
Nome Requisito de Segurança
Descrição
Classe abstrata que contém especificações do requisito de segurança.
Cada tipo de requisito de segurança deve ser indicado em alguma
das subclasses.
Nome Não repúdio
Descrição
Definir a necessidade de se evitar a negação de qualquer aspecto de
uma interação. A implementação de auditoria/log pode
complementar este requisito.
Nome Detecção de Ataque
Descrição
Visa estabelecer um mecanismo para detectar, registrar e notificar
uma tentativa ou um ataque bem sucedido. A implementação de
auditoria/log pode complementar este requisito.
Nome Integridade
Descrição
Tem por objetivo evitar a modificação das informações de forma
não autorizada ou intencional. A implementação de auditoria/log
pode complementar este requisito.
Nome Privacidade
Descrição
Visa evitar o acesso não autorizado e a obtenção de informações
sensíveis. A implementação de auditoria/log pode complementar
este requisito.
Nome Controle de Acesso
Descrição
Define a necessidade de implementar mecanismos de controle de
acesso (identificação, autenticação e autorização) para restringir o
acesso a determinados componentes. A implementação de
auditoria/log pode complementar este requisito.
Esta proposta foi testada em um processo do segmento hospitalar e, conforme as
informações publicadas pelos autores, foi possível mapear os requisitos de segurança deste
processo. No entanto, uma oportunidade de melhoria identificada foi que os requisitos de
segurança propostos ainda devem ser complementados por especialistas de segurança da
informação.

17
Segundo Rodríguez et. tal. (2008), a segurança da informação em processos de
negócio é amplamente aceita, no entanto a perspectiva de analistas de negócio em relação à
segurança da informação é pouco abordada.
O mercado de desenvolvimento de softwares está fortemente influenciado por modelos
de arquitetura dirigida (Model Driven-Architecture - MDA) que viabilizam a especificação
dos sistemas independentemente da plataforma de suporte, de forma a evitar os problemas de
tempo, de custo e de qualidade.
Portanto, considerando a influência do MDA, foi desenvolvido um método (Secure
Business Process- SBP) para especificar os requisitos de segurança independentemente de
computação ou plataforma, contemplando regras de transformação (Query/View/
Transformation - QTV) e o BPSec-Tool que é responsável por automatizar as especificações
de SBP.
O resultado do SBP é uma extensão para a UML 2.0 que permite especificar os
requisitos de segurança da informação dos processos de negócios (ver Quadro 9).
Quadro 9: Extensões para Requisitos de Segurança da Informação
continua
Estereótipo Notação
Controle de Acesso: Corresponde à limitação de acesso aos recursos somente aos
usuários autorizados.
Detecção de Ataque: Define-se como a detecção, registro e notificação de uma
tentativa de ataque ou ameaça, que tenha êxito ou fracasso.
Registro de Auditoria: É uma classe abstrata que contém as especificações de
registro de auditoria relacionadas com as especificações dos requisitos de segurança
da informação. Cada registro de auditoria deve ser especializado em uma de suas
subclasses.
G – Registro de Auditoria: Contém as especificações dos registros de auditoria
relacionados com os requisitos de segurança da informação: controle de acesso,
detecção de ataques, integridade e privacidade.
Este estereótipo não
possui notação.
Integridade: A integridade está relacionada com a proteção dos componentes contra
ações que possam corromper as informações de forma intencional ou não autorizada.
Não Repúdio: Estabelece a necessidade de evitar a negação de qualquer ação. Ex.:
Mensagem, Transações, Transmissão de dados etc.
NR – Registro de Auditoria: Contém especificações de auditoria relacionada com o
requisito de segurança da informação: Não repúdio.
possui notação.
Privacidade: Está relacionada com condição de proteção da informação de um
determinado indivíduo ou entidade, limitando o acesso de partes não autorizadas,
evitando que as mesmas possam obter informações sensíveis.
Atividade Segura: É uma classe abstrata que contém as especificações relacionadas
com os requisitos, os papéis e as permissões de segurança da informação.
possui notação.
Permissões de Segurança: Contém as especificações das permissões relacionadas
com especificações de controle de acesso, a permissão, o nome do objeto e as
operações permitidas.
possui notação.

18
Quadro 9: Extensões para Requisitos de Segurança da Informação
conclusão
Estereótipo Notação
Requisitos de Segurança: Classe abstrata que contém as especificações dos
requisitos de segurança da informação. Cada requisito deve ser indicado como uma
subclasse.
Função de Segurança: Relaciona-se com todos os requisitos de segurança da
informação e com o registro genérico de auditoria.
possui notação.
SP – Registro de Auditoria: Contém as especificações de registro de auditoria
relacionada com as permissões derivadas das especificações de controle de acesso.
possui notação.
Permissões de Operação: Contém os valores permitidos associados com as
permissões de operações. Os valores são associados a cada elemento referente às
especificações de controle de acesso.
possui notação.
Tipo de Privacidade: Contém informação do tipo de privacidade (anonimato ou
confidencialidade).
possui notação.
Grau de Proteção: Contém uma classificação do grau de proteção em relação à
integridade. Este valor pode ser baixo, médio e alto.
possui notação.
Tipo de Requisito: Contém os valores possíveis em relação às combinações de
requisitos de segurança da informação que podem ser especificados e representados
por um conjunto de abreviações AC, AD, I, NR e P associadas a controle de acesso,
detecção de ataques e ameaças, integridade, não repúdio e privacidade,
respectivamente.
possui notação.
Fonte: Elaborado a partir de Rodríguez et al. (2008, p. 4-5).
Esta extensão é composta por estereótipos que possibilitam estabelecer a relação dos
requisitos de segurança da informação com os elementos da UML 2.0.
5 NOTAÇÃO PARA MODELAGEM DE REQUISITOS DE SEGURANÇA (NMRSEG)
A notação apresentada nesta seção visa estabelecer um padrão para representação de
requisitos de segurança da informação, além de tornar mais intuitiva a identificação destes
requisitos nos processos de negócio, possibilitando a sua aplicação por analistas de negócios e
gestores de processos que não possuem um conhecimento específico em Segurança da
Informação, além dos profissionais de tecnologia e segurança da informação.
No entanto, para tornar mais eficaz o uso da NMRSEG, recomenda-se a definição de
um modelo de gestão. Este modelo deve abordar a sistemática de elaboração e atualização dos
requisitos de segurança da informação, as responsabilidades e a conduta na identificação e
mapeamento dos mesmos.
O processo de análise e avaliação de riscos, assim como os requisitos regulamentares,
legais e de cláusulas contratuais podem servir como insumos para elaboração e atualização
dos requisitos de segurança da informação. A Política de Segurança da Informação pode ser
utilizada para formalizar as responsabilidades e os responsáveis por mapear os requisitos de
segurança da informação dos processos de negócio.

19
A integração com demais processos da organização também pode ser contemplada
pelo modelo de gestão, de forma a garantir que os requisitos e as estratégias de segurança da
informação acompanharão as mudanças dos processos de negócio.
Como sugestão de integração é possível mencionar os processos de Gestão de
Incidentes e Auditoria que podem ser utilizados, respectivamente, para identificar a eficácia e
eficiência dos controles de segurança da informação implementados e também o nível de
conformidade dos mesmos. A integração com o Escritório de Processos e o Processo de
Desenvolvimento de Software garantirá que as ações de segurança da informação sejam
desenvolvidas de forma proativa e alinhadas com as estratégias e os processos de negócio da
organização.
5.1 ESTRUTURA DA NMRSEG
A notação para modelagem de requisitos de segurança está estruturada conforme o
Quadro 10. Os aspectos relacionados a cada um dos requisitos de segurança são fundamentais
para auxiliar na identificação da aplicabilidade destes requisitos no momento da modelagem
dos processos de negócio.
Quadro 10: Estrutura dos Requisitos de Segurança da Informação
Requisito de Segurança da Informação
Aspecto Descrição
Notação: Representação gráfica do requisito.
Descrição: Apresentação do requisito.
Orientações para implementação: Diretrizes para implementação do requisito
Ameaças: Ameaças relacionadas ao requisito.
Conformidade: Relação do requisito com leis e regulamentações.
Inicialmente foram considerados somente os controles da ABNT NBR ISO/IEC 27002
– Código de Prática para Gestão de Segurança da Informação, sendo que este padrão poderá
ser utilizado para representar outros requisitos de segurança da informação estabelecidos por
padrões e melhores práticas da área, conforme comentado no início desta seção.

20
Quadro 11: Notação para Modelagem de Requisitos de Segurança
continua
Requisito de SI Aspectos
Identificação e
Autenticação
Notação:
Descrição:
Manter o controle do acesso à informação e aos recursos de
processamento das informações, de forma a possibilitar a
validação da identidade de um usuário, de acordo com
políticas pré-definidas.
Orientações para
implementação:
Definir uma política de controle de acesso; Garantir que os
usuários somente serão permitidos acessar informações e
recursos relacionados a suas atividades (needto know);
Praticar a segregação de funções na gestão dos acessos;
Adotar a premissa de que tudo é proibido, a menos que seja
expressamente permitido; Formalizar a concessão e
revogação de acessos aos usuários; Desenvolver ou utilizar
rotinas de sistemas que evitam a necessidade de fornecer
acessos privilegiados aos usuários; Definir usuários
específicos com acessos privilegiados; Definir um ID para
cada usuário; O compartilhamento de IDs deve ser praticados
em situações específicas e com objetivos bem definidos;
Sempre que possível implementar autenticação forte através
de meios criptográficos, smartcard, tokens ou biometria;
Solicitar a troca de senha periodicamente; Evitar que a
mesma senha seja cadastrada novamente, através da
manutenção de um registro de senhas anteriores; Armazenar
e transmitir as senhas de forma cifrada; Não utilizar
mensagens de advertências que informam diretamente quais
dados do login estão incorretos;
Ameaças:
Repúdio; Abuso de direitos; Acesso não autorizado; Perda de
rastreabilidade;
Conformidade:
Sarbanes-Oxley (seção 404); Lei nº 7.232/84, art. 2o, inciso
VIII; Constituição Federal, art. 5º, inciso X.
Referência ISO 27002 - Seção 11
Aplicabilidade
Processo; Pool; Atividade; Objeto de dados.
Responsabilidades
de Segurança da
Informação
Notação:
Descrição:
Garantir que as responsabilidades referentes a segurança da
informação sejam claramente definidas e formalizadas.

21
continuação
Orientações para
implementação:
Formalizar as responsabilidades de segurança da informação
na Política de Segurança da Informação e, se for o caso, no
contrato de trabalho e através de Acordo de
Confidencialidade; Definir responsabilidades que visam à
proteção das informações, locais específicos e recursos de
processamento da informação; Considerar que as
responsabilidades não podem ser delegadas; A definição de
responsáveis por ativos pode ser necessária.
Ameaças: Repúdio de Ações; Falta de apoio interno;
Conformidade: Circular SUSEP Nº. 285; Instrução CVM Nº. 380.
Referência ISO 27002 - Seção 6.1.3
Aplicabilidade Pool
Classificação da
Informação
Notação:
Descrição:
Garantir que as informações serão tratadas e protegidas, em
todo o seu ciclo de vida, conforme a sua relevância para o
negócio.
Orientações para
implementação:
Convém que seja desenvolvido um sistema de classificação
da informação que defina níveis de confidencialidade e
criticidade (rótulos) para as informações, bem como os
controles necessários para atingir o objetivo de cada nível;
Manter um inventário que contenha o nome do ativo, seu
proprietário, o formato e seu nível de classificação; O
proprietário será o responsável por classificar e garantir a
manutenção do nível de classificação através de análise
periódica.
Ameaças:
Acesso indevido a informações confidenciais;
Indisponibilidade dos serviços ou informações; Furto de
mídias ou documentos.
Conformidade:
Sarbanes-Oxley (seção 404); Código de Processo Civil, art.
347, inciso II c/c art.363, inciso IV;Lei nº 7.232/84, art. 2o,
inciso VIII; Lei das S/A; Instrução CVM Nº 306.
Referência ISO 27002 - Seção 7.2
Aplicabilidade Processo; Atividade.
Segurança Física e
do Ambiente
Notação:
Descrição:
Prevenir o acesso físico não autorizado, danos e
interferências com as instalações e informações da
organização.
Orientações para
implementação:
Garantir que as instalações de processamento das
informações sensíveis e crítica sejam protegidas por controles
de acesso físico, monitoramento e detecção de intrusão;
Evitar danos às instalações através da implementação de
controles de prevenção e extinção de incêndio.

22
continuação
Ameaças:
Destruição de equipamento ou mídia; Furto de mídia ou
documentos; Incêndio; Acesso físico não autorizado.
Conformidade:
Sarbanes-Oxley (seção 404); Lei nº 7.232/84, art. 2o, inciso
VIII; Constituição Federal, art. 5º, inciso X.
Aplicabilidade Processo; Pool; Atividade.
Segregação de
Funções
Notação:
Descrição:
Segregar áreas de responsabilidades para reduzir as
oportunidades de modificação ou uso indevido não
autorizado e conflito de interesses.
Orientações para
implementação:
Impedir que uma única pessoa possa acessar, modificar ou
usar informações sem a devida autorização ou detecção;
Garantir que permissões relativas a autorizações não estejam
relacionadas a perfis de acesso que possam gerar conflito de
interesses; Implementar a monitoração de atividades e trilhas
de auditoria.
Ameaças: Fraude ou Sabotagem; Uso indevido; Abuso de direitos.
Conformidade: Sarbanes-Oxley (seção 404)
Aplicabilidade Pool; Lane; Atividade.
Segurança com
Partes Externas
Notação:
Descrição:
Garantir que os controles de segurança e os níveis de serviços
dos terceiros sejam implementados, executados e mantidos.
Manter a segurança das informações acessadas, processadas,
comunicadas ou gerenciadas por partes externas.
Orientações para
implementação:
Analisar e avaliar os riscos dos recursos e informações
disponíveis ou disponibilizados por partes externas, de
formar a identificar os controles necessários para proteger as
informações; Implementar planos de auditorias que
contemplem critérios relacionados a segurança das
informações e níveis de serviços; Exigir a possibilidade de
executar a transição de informações e recursos de
processamento para outros fornecedores, quando necessário;
Formalizar acordos para garantir os requisitos de segurança
das informações.
Ameaças:
Destruição de equipamento ou mídia; Furto de mídia ou
documentos; Divulgação indevida; Repúdio; Acesso físico e
lógico não autorizado; Aprisionamento a um fornecedor;
Violação de propriedade intelectual; Indisponibilidade de
serviços ou informações; Perda de expertise da organização;
Dependência extrema do fornecedor.
Conformidade:
Constituição Federal, art. 37, § 6º; Código Civil, arts. 927 e
932 caput, III.
Referência ISO 27002 - Seção 10.2 e 6.2
Aplicabilidade Processo; Atividade; Pool; Lane.

23
continuação
Segurança em
códigos móveis
Notação:
Descrição:
Garantir que códigos móveis (middlewares) não carreguem
códigos maliciosos e que previnem o uso não autorizado ou
interrupção de sistemas, redes ou aplicativos.
Orientações para
implementação:
Executar códigos móveis em ambientes isolados lógicamente;
Bloquear o recebimento de códigos móveis; Controlar os
recursos disponíveis para acesso ao código móvel;
Estabelecer controles criptográficos de autenticação exclusiva
ao código móvel.
Ameaças: Ação de código malicioso; Acesso lógico não autorizado;
Conformidade:
Lei nº 7.232/84, art. 2o, inciso VIII; Constituição Federal, art.
5º, inciso X.
Aplicabilidade
Atividade; Fluxo de sequência; Fluxo de mensagem.
Cópias de
Segurança
Notação:
Descrição:
Manter cópias de segurança das informações e dos softwares,
bem como testes periódicos de restauração.
Orientações para
implementação:
Identificar informações críticas que precisam ser copiadas;
Avaliar a necessidade de criptografia do dispositivo onde a
informação será copiada; Considerar o RPO (Recovery Point
Objective) e RTO (Recovery Time Objective) para definir o
tipo e periodicidade e retenção das cópias; Garantir a
proteção física e ambiental das cópias; Avaliar a necessidade
de manter as cópias em localidades remotas.
Ameaças:
Indisponibilidade da informação; Acesso não autorizado à
informação.
Conformidade:
Lei Complementar nº 75/93, art. 8º incisos II, VIII e §§ 1º e
2º; Constituição Federal, art. 5º, inciso XXXIII e art. 37, § 3º,
inciso II.
Aplicabilidade Processo; Atividade.
Segurança na
Troca de
Informações
Notação:
Descrição:
Garantir a segurança da troca de informações internamente à
organização e com entidades externas.

24
continuação
Orientações para
implementação:
Definir controles e procedimentos de proteção para todos os
tipos de recursos de comunicação; Considerar os controles de
proteção para mídias físicas em trânsito; Avaliar a
necessidade de uso de criptografia; Definir tempo de retenção
e descarte para mensagens; Controlar a retransmissão de
mensagens para correios externos; Conscientizar quanto a
conduta com as informações, de forma a evitar que as
mesmas fiquem expostas em dispositivos não protegidos. Ex.:
Impressoras e faxes; Estabelecer acordos com entidades
externas para a troca de informações que contemplem
controles de proteção para as informações;
Ameaças:
Acesso não autorizado; Indisponibilidade da informação;
Fraude ou Sabotagem; Comprometimento da integridade da
informação; Repúdio.
Conformidade:
Constituição Federal, art. 5º, inciso X; Constituição Federal,
art. 5º, inciso XII.
Aplicabilidade
Pool; Lane; Atividade; Fluxo de sequência; Fluxo de
mensagem.
Registro de
Auditoria
Notação:
Descrição:
Garantir que registros de auditoria sejam gerados e mantidos
por um período de tempo acordado ou conforme requisitos
legais e regulamentares.
Orientações para
implementação:
Registrar os dados necessários para a identificação dos
usuários e suas ações; Registrar os horários de entrada e saída
dos sistemas ou tentativas e, quando possível, a localização
do usuário; Registrar os alarmes gerados pelo sistema de
controle de acesso ou pela desativação dos sistemas de
proteção do sistema.
Ameaças:
Abuso de direitos; Repúdio; Fraude ou sabotagem; Perda de
rastreabilidade.
Conformidade: Sarbanes-Oxley (seção 404)
Aplicabilidade Atividade; Gateway; Fluxo de mensagem; Mensagem.
Validação de
Entrada
Notação:
Descrição:
Garantir que os dados de entrada para um sistema/atividade
sejam validados, de forma a identificar se os mesmo são
corretos e apropriados.
Orientações para
implementação:
Aplicar checagens na entrada de transações, conforme as
particularidades do negócio e sistemas; Impedir a entrada de
caracteres inválidos ou volumes expressivos de dados;
Ameaças:
Ação de código malicioso; Fraude ou sabotagem;
Indisponibilidade do sistema; Dados de fontes não confiàveis;
Comprometimento dos dados.

25
conclusão
Conformidade: Sarbanes-Oxley (seção 404); Código Penal, art. 313-A.
Aplicabilidade Atividade.
Integridade das
Informações
Notação:
Descrição:
Manter a integridade dos dados de sistemas e atividades, de
forma a garantir que os resultados/saídas serão consistentes.
Orientações para
implementação:
Realizar verificações para comparar se as saídas estão
coerentes; Implementar controles de contagens de
reconciliação para garantir o processamento de todos os
dados; Utilizar técnicas criptográficas para autenticação de
mensagens;
Ameaças:
Comprometimento da autenticidade da informação; Fraude
ou sabotagem.
Conformidade:
Sarbanes-Oxley (seção 404);Código Penal, art. 313-A;
Código Penal, art. 313-B.; Código de Defesa do Consumidor,
arts. 43 e 44.
Aplicabilidade Atividade; Gateway; Fluxo de mensagem; Mensagem.
Planos de
Continuidade de
Negócios
Notação:
Descrição:
Evitar o interrupção das atividades e processos de negócio
decorrentes de eventos adversos, garantido a continuidade
das mesmas à níveis satisfatórios, bem como orientar a
restauração em um tempo aceitável.
Orientações para
implementação:
Identificar os riscos e ameaças a que os processos ou
atividades estão expostos; Priorizar o processo ou atividade
através da análise de impacto nos negócios; Planejar e
formalizar as estratégias de continuidade de negócios através
de planos que contemplem os recursos e insumos necessários
para manter a continuidade dos processos ou atividades à
níveis aceitáveis; Executar testes e exercícios das estratégias
planejadas.
Ameaças:
Indisponibilidade de recursos humanos; Falha de
equipamentos; Interrupção no suprimento de energia; Falha
do ar-condicionado; Inundação; Fogo; Indisponibilidade dos
sistemas de informação.
Conformidade:
Circular SUSEP Nº. 285; Resolução BACEN Nº. 3380;
Constituição Federal, art. 5º, inciso XXXIII e art. 37, § 3º,
inciso II.
Aplicabilidade Processo; Pool; Atividade.

26
Para facilitar a utilização da notação apresentada no Quadro 11 foi desenvolvido um
estêncil2
compatível com o Microsoft Visio e que contempla todos os aspectos relacionados a
cada um dos requisitos de segurança da informação.
5.2 APLICAÇÃO DA NMRSEG
Para avaliar a aplicabilidade da NMRSEG foi realizada uma ilustração da modelagem
do Processo de elaboração e aplicação da avaliação do Ensino Público, conforme a Figura 4.
Nesta seção também serão abordados alguns dos requisitos presentes no diagrama do processo
e relacionados aos elementos do mesmo.
Figura 4: Processo de Elaboração e Aplicação da Avaliação do Ensino Médio
Os participantes deste processo representados em cada uma das Pools são: o Governo,
os Prestadores de Serviços e as Instituições de ensino responsáveis pela elaboração e revisão
das questões, bem como pela aplicação das provas.
O Governo é responsável por selecionar as instituições de ensino que irão elaborar as
questões e por treinar instituições responsáveis pela revisão das questões elaboradas. Todas as
questões aprovadas serão armazenadas em um banco oficial de questões. Este sempre será
consultado quando for necessária a avaliação do desempenho do Ensino Público (Médio ou
Superior). A responsabilidade de gerar os arquivos das provas e enviá-los aos Prestadores de

27
Serviços para impressão e distribuição, também é do Governo, assim como a correção das
provas e a publicação dos resultados oficiais.
- Com relação ao Governo e aos demais participantes deste processo, as
responsabilidades de segurança devem ser definidas e formalizadas
( ). A segregação de funções ( ) é um requisito fundamental no momento da
seleção dos elaboradores e revisores de questões.
As Instituições de Ensino que foram aprovadas na seleção e que receberam o
treinamento adequado do Governo para elaboração das questões recebem acesso ao Sistema
de Revisão, de modo que cada questão elaborada seja enviada para revisão antes de ser
armazenada no banco oficial de questões.
- Para garantir que as questões elaboradas receberão a proteção adequada, é
importante que as mesmas sejam classificadas ( ) . O sistema onde as questões
elaboradas serão submetidas para revisão deve garantir a integridade ( ) das
mesmas.
Cada questão elaborada deve passar por uma revisão de acordo com o método
estabelecido pelo Governo. Sendo assim, o Governo seleciona e treina as Instituições de
Ensino que serão responsáveis pela revisão de todas as questões, assim como disponibiliza
acesso ao banco oficial de questões para que somente as questões aprovadas sejam
armazenadas.
- O armazenamento de registros ( )sobre os responsáveis pela aprovação das
questões elaboradas torna o processo mais confiável e rastreável. Tendo em vista a
criticidade do banco oficial de questões, é fundamental para o sucesso do processo
que ele esteja disponível quando necessário ( ).
Os Prestadores de Serviço são empresas contratadas para efetuar serviços de
impressão, distribuição para as Instituições de Ensino que aplicam as provas e o envio das
provas para correção.
- Para garantir que as informações estejam protegidas mesmo no âmbito dos
prestadores de serviço, é importante que sejam formalizados acordos com relação
aos níveis e controles de segurança a serem implementados ( ). A troca de
mensagens ( ) entre o Governo e os Prestadores de Serviço deve ser protegida de
forma a evitar o acesso e a alteração não autorizada.
As Instituições de Ensino habilitadas a aplicarem as provas para avaliação do Ensino
Público devem fornecer uma equipe devidamente treinada e orientada para acompanhar a
aplicação das provas.

28
- Os ambientes onde as provas serão aplicadas devem prever controles de segurança
física para evitar interferências e o acesso não autorizado ( ). O controle de
acesso ( ) às provas, antes da aplicação, deve ser previsto.
6 ESTUDO DE CASO
A ilustração do Processo de elaboração e aplicação da avaliação do Ensino Público
apresentado na Figura 4 possibilitou a realização do estudo de caso que será abordado nesta
seção.
Com o objetivo de avaliar a NMRSEG proposta por este trabalho, foi realizado um
estudo de caso com alunos de duas turmas da disciplina de Gestão de Segurança da
Informação do Curso de Graduação Tecnológica em Segurança da Informação da
Universidade do Vale do Rio do Sinos (UNISINOS), conforme apresentado no Quadro 12.
Quadro 12: Participantes do Estudo de Caso
continua
Aluno Informações
Turma A
Aluno - Aa Idade: 21;
Tempo médio de experiência com segurança da informação: 1 ano;
Tempo médio de experiência com desenho de processos: ( X ) 0-2 anos ( ) >2 e <4
anos ( ) >5 anos.
Aluno -Ab Idade: 22 anos;
Tempo médio de experiência com segurança da informação: não possui;
anos ( ) >5 anos.
Aluno - Ac Idade: 36 anos;
Tempo médio de experiência com segurança da informação: 2 anos;
anos ( ) >5 anos.
Aluno - Ad Idade: 29 anos;
Tempo médio de experiência com segurança da informação:3 anos;
anos ( ) >5 anos.
Aluno - Ae Idade: 25 anos;
Tempo médio de experiência com segurança da informação: Menos de 1 ano;
anos ( ) >5 anos.
Aluno - Af Idade: 36 anos;
Tempo médio de Experiência com segurança da Informação: > 5 anos;
Tempo médio de experiência com desenho de processos: ( ) 0-2 anos ( ) >2 e <4
anos ( X ) >5 anos.

29
Quadro 12: Participantes do Estudo de Caso
conclusão
Aluno Informações
Turma A
Aluno - Ag Idade:23 anos;
anos ( ) >5 anos.
Turma B
Aluno - Ba Idade: 28;
anos ( ) >5 anos.
Aluno - Bc Idade: 24;
Tempo médio de experiência com segurança da informação: Não atua na área;
anos ( ) >5 anos .
Aluno - Bd Idade: 20;
anos ( ) >5 anos.
Aluno - Be Idade: 22 anos;
Tempo médio de experiência com segurança da informação: Não possui;
anos ( ) >5 anos.
Aluno - Bf Idade: 21 anos;
Tempo médio de experiência com segurança da informação:2,5 anos;
anos ( ) >5 anos;
Aluno - Bg Idade: 28 anos;
anos ( ) >5 anos.
As duas turmas que participaram do estudo totalizavam 13 alunos, com idade de 20 a
36 anos e experiência de 0 a 5 anos em Segurança da Informação e Modelagem de Processos
de Negócio.
6.1 PLANEJAMENTO
Tendo em vista que a participação dos alunos no estudo de caso foi de forma
voluntária, e que os mesmos foram escolhidos pelo motivo de já possuírem o conhecimento
de segurança da informação adequando para as atividades, é possível definir que a técnica de
amostra utilizada neste estudo de caso foi a por conveniência.
Os alunos receberam um tutorial sobre o objetivo do trabalho e do estudo de caso, que
além de apresentar o fluxo do processo abordado no diagrama da subseção 5.2, também

30
contemplava os conceitos de BPMN e as orientações para a execução das atividades do estudo
de caso.
6.2 COLETADE DADOS
O estudo foi conduzido em duas atividades: 1) foi solicitado aos alunos que
identificassem e relacionassem todos os requisitos de segurança da informação aplicáveis ao
processo. É importante ressaltar que nesta etapa os alunos não utilizaram a NMRSEG. Aos
alunos foi recomendado que utilizassem suas experiências e o conhecimento adquirido no
curso de Segurança da Informação. Como material de apoio foi fornecido a ABNT NBR
ISO/IEC 27002 – Código de Prática para Gestão de Segurança da Informação; 2) nesta
atividade foi solicitado aos alunos que utilizassem a NMRSEG apresentada no Quadro 11, e o
estêncil que foi desenvolvido para o Microsoft Visio, para identificar e mapear os requisitos
de segurança da informação aplicáveis ao processo. Após a execução das duas atividades, os
alunos tiveram que responder a um questionário com cinco questões de avaliação qualitativa e
quantitativa da NMRSEG, conforme segue:
a) considerando a sua experiência na utilização da NMRSEG para mapeamento dos
requisitos de Segurança da Informação do Processo de elaboração e aplicação da
avaliação do Ensino Público, avalie as percepções relacionadas abaixo com as
seguintes notas: 1- Ruim / 2- Satisfatória / 3- Ótima.
 tempo necessário para mapear os requisitos ( );
 facilidade para mapear os requisitos ( );
 relevância dos aspectos relacionados a cada requisito de segurança da
informação ( );
 aplicabilidade prática da notação proposta nas atividades das áreas de
Desenvolvimento de Sistemas e Segurança da Informação ( );
b) como profissional de Segurança da Informação, você entende ser relevante o
levantamento dos requisitos de segurança da informação no momento do
mapeamento do processo de negócio? Comente;
c) com a utilização da NMRSEG foi possível mapear de forma precisa os principais
requisitos do processo do ponto de vista de Segurança da Informação? Por quê?;
d) você acredita que a notação proposta pode ser utilizada por profissionais, como por
exemplo, Analistas de Sistemas e Negócios, para que esses identifiquem/

31
representem requisitos de segurança da informação nas suas tarefas diárias?
Comente;
e) os símbolos utilizados na NMRSEG representam de forma intuitiva os requisitos de
Segurança da Informação? Comente.
As duas atividades do estudo de caso foram executadas em duas semanas e,
posteriormente, foi necessário mais um (1) dia para consolidar os resultados do estudo.
6.3 ANÁLISE DOS DADOS
A realização de duas atividades em momentos diferentes e utilizando instrumentos e
orientações diferentes, conforme apresentado anteriormente, permitiu perceber o
comportamento dos alunos frente à necessidade de identificar requisitos de segurança da
informação de um processo de negócio.
É importante ressaltar que, na primeira atividade, apenas 20% dos alunos abordaram
requisitos diferentes de apenas confidencialidade, integridade e disponibilidade, relacionados
à segurança das informações. Sendo assim, a principal observação a ser realizada sobre o
resultado desta atividade é a inexistência de um padrão para identificar e representar os
requisitos de segurança da informação de um processo que ofereça orientações e motivadores
pertinentes para a implementação dos mesmos de forma sistemática.
Após os alunos passarem pela experiência de ter de identificar requisitos de segurança
da informação de um processo de negócio sem ter um padrão estabelecido para esta
finalidade, a realização da segunda atividade, com a NMRSEG, permitiu a coleta das
percepções dos mesmos quanto à utilização de uma notação específica para identificar e
representar requisitos de segurança da informação.
Sob uma perspectiva quantitativa, no Quadro 13 é possível visualizar a opinião dos
alunos com relação à experiência em utilizar a NMRSEG.
Quadro 13: Avaliação Quantitativa da NMRSEG
Alternativa RUIM SATISFATÓRIA ÓTIMA
Tempo necessário para mapear os requisitos. 8% 32% 60%
Facilidade para mapear os requisitos. 0% 48% 52%
Relevância dos aspectos relacionados a cada requisito de
Segurança da Informação.
0% 48% 52%
Aplicabilidade prática da notação proposta nas atividades
das áreas de Desenvolvimento de Sistemas e Segurança
da Informação.
0% 40% 60%

32
Através das respostas fornecidas no questionário disponibilizado aos participantes do
estudo de caso ficou claro que os alunos entendem que a NMRSEG conseguiu auxiliar de
forma intuitiva e ágil no levantamento de requisitos de segurança da informação do Processo
de elaboração e aplicação da avaliação do Ensino Público, principalmente em relação à
utilização do estêncil para o Microsoft Visio. Mesmo que a representação gráfica de uma
minoria dos símbolos possa ser um pouco mais difícil de identificar, esta situação foi
facilmente contornada após a leitura das respectivas descrições da notação.
Outro aspecto importante, ressaltado pelos alunos, foi que a utilização da NMRSEG
apresenta um método mais envolvente para aplicar a segurança da informação no dia-a-dia de
profissionais ou de departamentos de Tecnologia de Informação que não sejam especialistas
nesta área. Contudo, percebeu-se que um conhecimento mínimo em relação aos objetivos e
propriedades da segurança da informação, é necessário.
Por fim, a necessidade de considerar a segurança da informação no momento da
modelagem dos processos de negócio foi um consenso entre os participantes do estudo de
caso. No entanto, é reconhecido que atualmente a maioria das organizações negligencia esta
boa prática.
6.4 COMPARATIVO: NMRSEG X TRABALHOS RELACIONADOS
No Quadro 14 são apresentadas as categorias e as propriedades utilizadas na avaliação
dos trabalhos relacionados e a NMRSEG (JAKOUBI et al., 2009).
Quadro 14: Comparativo com Trabalhos Relacionados
Abordagens
Capacidades
de
Modelagem
Modelagem
de Requisitos
de Segurança
Identificação
de Impacto
Atributos de
Risco/Segurança da
Informação
Aplicação Avaliação Econômica
BPMNSec
BPMN
(extensões
para modelar
requisitos de
segurança
em processos
de negócios)
Sim Não
Não Repúdio;
Detecção de
Ataques; Integridade;
Privacidade;
Controle de Acesso;
Papéis e Permissões
de Segurança.
Mapeamento de
processo de negócio
Não
UMLSec
UML 2.0
diagramas de
atividade
(extensão
com
asptectos de
segurança)
Sim Não
Não repudio;
Integridade;
Privacidade;
Controle de Acesso.
Desenvolvimento de
sistema
Não

33
NMRSEG
BPMN
(extensões
para modelar
requisitos de
segurança
em processos
de negócios)
Sim Não
Identificação e
Autenticação;
Responsabilidades de
Segurança da
Informação;
Classificação da
Informação;
Segurança Física e
do Ambiente;
Segregação de
Funções;
Segurança em Partes
Externas;
Segurança em
Códigos Móveis;
Cópia de Segurança;
Segurança da Troca
de Informações;
Registro de
Auditoria;
Validação de
Entrada;
Integridade das
Informações;
Plano de
Continuidade de
Negócios.
Mapeamento de
processo de negócio
Não
Fonte: Elaborado a partir de Jakoubi et al. (2009, p. 6).
Os critérios de avaliação são: (1) Capacidade de Modelagem: Apresenta a linguagem
suportada; (2) Modelagem de Requisitos de Segurança da Informação: Define a capacidade de
modelagem de requisitos de segurança da informação; (3) Identificação de Impacto: Define a
capacidade de identificação e análise de impacto; (4) Atributos de Riscos e Segurança da
Informação: Apresenta as propriedades de risco e segurança da informação; (5) Aplicação:
Define se a abordagem é genérica ou aplicável à somente um tipo de domínio; (6) Avaliação
Econômica: Define a capacidade de avaliação do custo benefício da implementação de contra
medidas de segurança da informação.
7 CONCLUSÕES
Tendo em vista os objetivos a que este trabalho se propôs, é possível afirmar que os
mesmos foram atingidos, restando apenas oportunidades de melhorias pontuais que também
serão abordadas nesta seção, assim como as contribuições diferenciais e trabalhos futuros
resultantes desta pesquisa.
A NMRSEG contribui com a disseminação da segurança da informação, uma vez que
ela apresenta seus requisitos de forma intuitiva e acessível, além de facilitar a tarefa de
identificar e formalizar os requisitos de segurança da informação de um processo de negócio,

34
através da utilização do estêncil para o Microsoft Visio, sendo ele parte dos entregáveis desta
pesquisa.
Com a realização do estudo de caso apresentado na seção 6, foi possível concluir
alguns diferenciais da NMRSEG: a) estabelece um método para expansão da representação de
requisitos de segurança da informação, considerando outros padrões normalizados pelo
mercado de segurança da informação, além da ABNT NBR ISO/IEC 27002 – Código de
Prática para Gestão de Segurança da Informação; b) possibilita a identificação de requisitos de
segurança por analistas de negócios e gestores de processos que não possuem um
conhecimento específico em Segurança da Informação; c) a utilização do estêncil para o
Microsoft Visio torna a tarefa de identificar e formalizar os requisitos de segurança da
informação mais ágil e intuitiva.
As oportunidades de melhorias mapeadas durante a pesquisa se referem a revisão de
alguns símbolos utilizados para representar uma minoria dos requisitos de segurança da
informação, assim como a necessidade de requisitos de segurança relacionados ao
treinamento e à conscientização em segurança da informação.
Durante o desenvolvimento da NMRSEG, foi possível identificar oportunidades de
expansão desta pesquisa, mas que, pelo fato de não fazer parte do escopo e objetivo inicial, as
mesmas são oferecidas como sugestões de trabalhos futuros, conforme seguem:
a) modelo de gestão de requisitos de segurança da informação: modelo que
contemple, de forma sistemática, a atualização dos requisitos de segurança da
informação, a manutenção dos requisitos já mapeados, a conformidade destes
requisitos (garantir que os mesmos foram implementados) e as responsabilidades
dos gestores dos processos e dos responsáveis por identificar os requisitos de
segurança da informação nos processos de negócio;
b) notação textual de requisitos de segurança da informação: notação que auxilie
na geração de códigos XML, de forma a automatizar o
desenvolvimento/implementação dos requisitos de segurança da informação;
c) expansão da NMRSEG: aumentar a base de requisitos de segurança da
informação propostos por esta notação, que considere outros padrões e melhores
práticas normalizadas pelo mercado de segurança da informação;
d) expansão do estudo de caso: aumentar a amostra em futuros estudos de caso, com
o objetivo de identificar novas oportunidades de melhorias e padrões com relação à
avaliação da NMRSEG.

35
Por fim, é importante ressaltar que os resultados deste trabalho de pesquisa serão
submetidos para o VII Workshop Brasileiro em Gestão de Processos de Negócio, evento que
ocorrerá no IX Simpósio Brasileiro de Sistema de Informação em João Pessoa-PB, nos dias
22, 23 e 24 de maio de 2013.
NOTATION FOR MODELING OF SECURITY REQUIREMENTS (NMRSEG)
Abstract: The objective of this study was to develop a notation for modeling information
security requirements, to enable the definition and mapping of security requirements at the
time of modeling business processes. To support this research were identified and analyzed
papers related to the theme and objectives of this work. The case study has allowed us to
formulate conclusions and opportunities for improvements to the proposed notation. As a
result of this research has generated a specific notation for mapping information security
requirements and a set of symbols that represent these requirements, for use in Microsoft
Visio. The NMRSEG contributes to the spread of information security, since it allows the
identification of information security requirements in a fast and intuitive, and enable its
application for business analysts and process managers that do not have specific knowledge
Information Security.
Keywords: Security in Business Processes. Notation for Security Requirements. Notation for
Modeling Business Processes.
NOTAS EXPLICATIVAS
1
São dados relacionados a cada um dos requisitos de segurança da informação, que
possibilitam a correta aplicação da NMRSEG.
2
Conjunto de símbolos utilizados para representar os requisitos de segurança da informação e
viabilizar a sua utilização no Microsoft Visio.
REFERÊNCIAS
ANTTILA, Juhani; KAJAVA, Jorma; VARONEN, Rauno. Balanced integration of
information security into business management. 2004. Disponível em: <http://ieeexplore.
ieee.org/xpls/abs_all.jsp?arnumber=1333422>. Acesso em: 28 maio 2012.
ASSOCIAÇÃO BRASILEIRA DE NORMAS TÉCNICAS - ABNT. NBR 27002: código de
prática para a gestão de segurança da informação. Rio de Janeiro, 2005.
BAUMANN, Henriette; GRASSLE, Patrick; BAUMANN, Philippe. UML 2.0 in Action.
Birmingham: PacktPublishing, 2005.

36
BRIDGELAND, M. David; ZAHAVI, Ron. Businessmodeling. Massachusetts: Morgan
Kaufmann, 2008.
CONGER, Sue. Process mapping and management. New York: Business Expert Press, 2011.
DAS, Manoj; DEB, Manas; WILKINS, Mark. Oracle business process management suite
11g handbook. New York: Oracle Press, 2011.
JAKOUBI, Stefan; TJOA, Simon; GOLUCH, Gernot; QUIRCHMAYR, Gerald. A survey of
scientific approaches considering the integration of security and risk aspects into business
management. 2009. Disponível em: <http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=
5337455>. Acesso em: 25 fev. 2012.
LANGE, F.J. Christian; CHAUDRON, R.V. Michel; MUSKENS, Johan. Inpratice: UML
software architecture and desing description. 2006. Disponível em: <http://www.mendeley.
com/research/software-architecture-description-and-uml/>. Acesso em: 11 maio 2012.
LEONID, Churliov; DINA, Neiger; ROSEMANN, Michael; MUEHLEN, Zur. Integrating
risks in business process models with value focused process engineering. 2006. Disponível
em: <http://eprints.qut.edu.au/25586/>. Acesso em: 8 maio 2012.
MUEHLEN, Z. Michael; ROSEMANN, Michael. Integrating risk in business process
models. 2005. Disponível em: <http://www.workflow-research.de/.../PDF/MIZU.MIRO-
ACIS(2005).pdf>. Acesso em: 10 abr. 2012.
NEUBAUER, Thomas; KLEMEN, Markus; BIFFL, Stefan. Secure business process
management: a roadmap. 2006. Disponível em: <http://ieeexplore.ieee.org/iel5/10823/
34117/01625343.pdf>. Acesso em: 2 abr. 2012.
NOTAÇÃO. In: DICIONÁRIO Priberam de Língua Portuguesa. Disponível em:
<http://www.priberam.pt/dlpo/default.aspx?pal=notação>. Acesso em: 10 fev. 2012.
OBJECT MANAGEMENT GROUP - OMG. Business Process Model and Notation (BPMN):
version 2.0. 2011. Disponível em: <http://www.omg.org/spec/BPMN/2.0/PDF>. Acesso em:
13 abr. 2012.
OLIVEIRA, B. Saulo. Gestão por processos: fundamentos, técnicas e modelos de
implementação. Rio de Janeiro: Qualitymark, 2006.
OULD, A. Martyn. Business process management: a rigorous approach. Swindon: British
Informatics Society Limited, 2005.
PETTY, Christy. Gartner survey shows more than half of respondents plan to increase
spending on BPM by more than 5 percent in next 12 months. 2009. Disponível em:
<http://www.gartner.com/it/page.jsp?id=1109412>. Acesso em: 2 jun. 2012.

37
REYNOLDS, Chris. Introduction to business architecture. Boston: Course Technology PTR,
2009.
RODRÍGUEZ, Afonso; FERNÁNDES-MEDINA, Eduardo; PIATTINI, Mario. Using QTV
to obtain use cases from secure business process modeled with BPMN. Disponível em:
<http://lams.epfl.ch/conference/bpmds07/program/Rodriguez_6.pdf>. Acesso em: 9 fev.
2012.
RODRÍGUEZ, Afonso; FERNÁNDEZ-MEDINA, Eduardo; PIATTINI, Mario. A BPMN
extension for the modeling of security requirements in business process. 2007. Disponível
em: <http://dl.acm.org/citation.cfm?id=1237868>. Acesso em: 23 maio 2012.
RODRÍGUEZ, Afonso; FERNÁNDEZ-MEDINA, Eduardo; PIATTINI, Mario; TRUJILLO,
Juan. JISBD2007-05: secure business process defined through a UML 2.0 extension. 2008.
Disponível em: <http://ieeexplore.ieee.org/xpls/abs_all.jsp?reload=true&arnumber=481528
7>. Acesso em: 5 fev. 2012.
SOUDANI, Nadia; RAGGAD, G. Bel; ZOUARI, Belhassen. A formal design of secure
information systems by using a Formal Secure Data Flow Diagram (FSDFD). 2009.
Disponível em: <http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=5411965>. Acesso em:
15 abr. 2012.
TANUSKA, Pavol; SKRIPCAK, Tomas.The proposal of functional user requirements
generation. 2011. Disponível em: <http://ieeexplore.ieee.org/xpl/login.jsp?tp=&arnumber=
5763969&url=http%3A%2F%2Fieeexplore.ieee.org%2Fiel5%2F5756602%2F5763958%2F0
5763969.pdf%3Farnumber%3D5763969>. Acesso em: 19 maio 2012.
WATSON, Andrew. Visual modelling: past, present and future. 2008. Disponível em:
<http://www.uml.org/Visual_Modeling.pdf >. Acesso em: 20 maio 2012.
WHITE, A. Stephen. Introduction to BPMN. 2004. Disponível em: <http://www.omg.org/
bpmn/Documents/Introduction_to_BPMN.pdf>. Acesso em: 7 abr. 2012.
YIN, K. Robert. Estudo de caso: planejamento e métodos. 3. ed. Porto Alegre: Bookman,
2005.

Final Paper_NMRSEG

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (20)

Semelhante a Final Paper_NMRSEG

Semelhante a Final Paper_NMRSEG (20)

Final Paper_NMRSEG