Roteiro para Security Target Simplificado – STS – Versão 0.1

"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