"Um
passo à frente,
E
você não está mais no mesmo lugar"
Chico
Science
1. Introdução
O
objetivo deste documento é guiar o estudante de segurança no
desenvolvimento a escrever um documento, ST Simplificado, capaz de
identificar os aspectos de segurança relacionados com um software
(TOE – Target of Evaluation), e quais requisitos de segurança
devem ser atendidos.
O STS
proposto nesta atividade, é inspirado no modelo de Security Target
apresentado na ISO 15408, ou Common Criteria
(http://www.commoncriteriaportal.org/),
mas com o objetivo principal de ser utilizado como uma ferramenta
educacional. Entretanto, pode ser aplicado em projetos pequenos, mas
com requisitos de segurança impostos pela legislação vigente, ou
políticas organizacionais.
Os
objetivos secundários do STS são formalizar quais requisitos de
segurança devem ser atendidos pelo TOE e nortear o procedimento de
testes.
A opinião
pessoal deste autor, é que uma documentação é melhor do que
nenhuma.
2. Descrição do SST
O SST
será formado pelas seguintes seções:
Introdução
– Apresentação da finalidade do documento, identificação do
TOE e sua finalidade;
Descrição
– Uma descrição detalhada da arquitetura do TOE.
Políticas
– Identificação das políticas de segurança e organizacionais
que devem ser atendidas pelo TOE;
Legislação
– Deve identificar a legislação relacionada com o TOE;
Análise
de Risco – Identificação os riscos relacionados com o TOE;
Premissas
do Ambiente– Identificação das premissas do ambiente que
influenciam os objetivos de segurança;
Objetivos
de Segurança – Identificação dos objetivos de Segurança;
2.1 Introdução
A
introdução documento deve apresentar o TOE de forma sucinta, de
forma que o leitor possa identificar a funcionalidade básica do TOE
e qual o seu objetivo. Adicionalmente pode ser apresentado alguma
premissa que represente a missão do TOE ou alguma meta
organizacional. Segue um exemplo:
“O
objetivo deste documento é identificar os requisitos de segurança
da aplicação EstoqueMobile, que permite a consulta on-line ao banco
de dados de estoque da organização XPTO.
EstoqueMobile
será utilizada pelos representantes da XPTO em leilões de
matéria-prima. Os representantes precisam conhecer a quantidade do
produto em estoque, para tomar as decisões no leilão. EstoqueMobile
deve ser capaz de utilizar redes de comunicação públicas e
garantir a confidencialidade das informações. ”
2.2 Descrição
Deve incluir: Diagrama de Casos de Uso, Diagrama de Classes, ou
qualquer diagrama que facilite o entendimento sobre a arquitetura. Se
o TOE é uma aplicação web ou para dispositivo móvel, deve
identificar os componentes envolvidos no lado cliente e no lado
servidor (server-side).
2.3 Políticas
Uma tabela deve identificar as políticas, organizacionais ou de
segurança, que devem ser atendidos pelo TOE. Cada política deve
possuir um identificador, que será utilizado para relacionar o
objetivo de segurança com a política.
Exemplo, considerando o software fictício EstoqueMobile:
Identificador de Política
|
Descrição
|
POL-1
|
Os dados consolidados de
estoque devem ser acessíveis apenas por usuários nos grupos:
“direção”, “compradores” e “gestores de estoque”.
|
POL-2
|
A divulgação não autorizada
das informações acessadas através do EstoqueMobile devem ser
punidas mediante demissão por justa causa.
|
POL-3
|
Informações da empresa XPTO,
classificadas como segredo de negócio, devem utilizar mecanismos
criptográficos que garantam a confidencialidade dos dados, ao
trafegar por redes de classificação menor e no armazenamento de
dados
|
2.4 Legislação
Uma tabela deve identificar a legislação vigente, que afeta o TOE,
ou os dados manipulados pelo TOE. Cada item deve possuir um
identificador, que será utilizado para relacionar o objetivo de
segurança com a legislação.
Exemplo, considerando o software fictício EstoqueMobile:
Identificador de Legislação
|
Descrição
|
LEGIS-1
|
Direito Trabalhista. Para
garantir a demissão por justa causa, caso ocorra um acesso
indevido ou vazamento de informações, o EstoqueMobile deve
garantir a identidade (não repúdio) de todos os usuários.
|
2.5 Análise de Risco
Qualquer metodologia de análise de risco pode ser utilizada, desde
que forneça as seguintes informações sobre o TOE:
Descrição do Risco. Texto que permita identificar o agente
e a vulnerabilidade que compõem o risco.
Impacto. Nível de impacto com a concretização do risco.
Pode ser um valor numérico, proporcional ao risco, ou uma
categoria, que identifica a classe do risco (ex.: alto, médio e
baixo).
Classificação. Determina quais componentes da segurança
(Confidencialidade, Integridade, Disponibilidade, podendo também
ser: Legislação ou Política) serão comprometidos com a
concretização do risco;
Cada risco deve possuir identificador, que será utilizado para
relacionar o objetivo de segurança com o risco.
Exemplo, considerando o software fictício EstoqueMobile:
Identificador de Risco
|
Descrição do Risco
|
Impacto
|
Classificação
|
RISCO-1
|
Atacante externo pode tentar
acessar a componente server-side para obter dados do banco de
estoque.
|
alto
|
Confidencialidade;
Integridade;
|
RISCO-2
|
Captura de pacotes na rede
pública pode fornecer dados confidenciais a terceiros.
|
alto
|
Confidencialidade;
|
RISCO-3
|
Acesso indevido ao dispositivo
móvel pode permitir o acesso não autorizado a informação
confidencial armazenada no dispositivo.
|
médio
|
Confidencialidade;
|
2.6 Premissas do Ambiente
Nesta seção devem ser identificados os mecanismos de controle já
aplicados no ambiente em que a aplicação será utilizada, e são
necessários para garantir que os mecanismos aplicados pela solução
serão suficientes.
Cada risco deve possuir identificador, que será utilizado para
relacionar o objetivo de segurança com o risco.
Exemplo, considerando o software fictício EstoqueMobile:
Identificador da Premissa
|
Descrição da Premissa
|
PREM-1
|
O componente server-side será
hospedado em um servidor que possui atualização automática de
correções de segurança;
|
PREM-2
|
O servidor que hospeda o
componente server-side é protegido por firewall que limita o
tráfego em direção ao servidor, permitindo apenas tráfego
direcionado a porta do componente.
|
PREM-3
|
O dispositivo móvel deve
possuir todas as correções de vulnerabilidades disponibilizadas
pelo fabricante;
|
PREM-4
|
O dispositivo móvel deve
utilizar software antivírus atualizado.
|
2.7 Objetivos de Segurança
Os objetivos de segurança devem identificar quais requisitos foram
considerados (Políticas, Legislação e Riscos), bem como se alguma
premissa deve ser seguida para garantir que o objetivo seja atingido.
Cada objetivo deve possuir identificador, que será utilizado para
guiar os testes.
Exemplo, considerando o software fictício EstoqueMobile:
Identificador do Objetivo
|
Descrição
|
Requisitos
|
OBJ-1
|
A autenticação do usuário deve
utilizar certificados digitais ou biometria.
|
POL-1,
POL-2,
LEGIS-1,
RISCO-1
|
OBJ-2
|
A comunicação entre o lado
cliente e o servidor deve utilizar SSL/TLS
|
POL-3,
RISCO-2
|
OBJ-3
|
O armazenamento de informações
no dispositivo deve utilizar criptografia.
|
POL-3,
RISCO-3
|