Arquitetura de segurança corporativa — uma abordagem de cima para baixo

Autor: Rassoul Ghaznavi-Zadeh, CISM, COBIT Foundation, CISSP, SABSA SCF, TOGAF 9 Data

Publicada: 28 julho 2017 PDF

Implementar a arquitetura de segurança é muitas vezes um processo confuso nas empresas. Tradicionalmente, a arquitetura de segurança consiste em alguns controles preventivos, detetives e corretivos que são implementados para proteger a infraestrutura e os aplicativos corporativos. Algumas empresas estão fazendo um trabalho melhor com arquitetura de segurança adicionando controles de diretiva, incluindo políticas e procedimentos. Muitos profissionais de segurança da informação com uma arquitetura de segurança tradicional de mentalidade veem a arquitetura de segurança como nada mais do que ter políticas de segurança, controles, ferramentas e monitoramento.

O mundo mudou; segurança não é a mesma besta de antes. Os fatores de risco e ameaças de hoje não são os mesmos, nem tão simples quanto costumavam ser. Novas tecnologias e possibilidades emergentes, por exemplo, a Internet das Coisas, mudam muito sobre como as empresas operam, qual é o seu foco e seus objetivos. É importante que todos os profissionais de segurança entendam os objetivos dos negócios e tentem apoiá-los implementando controles adequados que possam ser simplesmente justificados para as partes interessadas e ligados ao risco do negócio. Estruturas corporativas, como a Sherwood Applied Business Security Architecture (SABSA), o COBIT e o Open Group Architecture Framework (TOGAF), podem ajudar a alcançar esse objetivo de alinhar as necessidades de segurança com as necessidades dos negócios.

SABSA, COBIT e TOGAF e seus relacionamentos

A SABSA é uma estrutura de segurança voltada para os negócios para empresas que se baseia em riscos e oportunidades associadas a ela. A SABSA não oferece nenhum controle específico e conta com outros, como os processos iso da Organização Internacional para padronização (ISO) ou COBIT. É puramente uma metodologia para garantir o alinhamento dos negócios.

A metodologia SABSA possui seis camadas (cinco horizontais e uma vertical). Cada camada tem um propósito e visão diferentes. A camada contextual está no topo e inclui requisitos e metas de negócios. A segunda camada é a camada conceitual, que é a visão da arquitetura. A Figura 1 mostra as seis camadas desta estrutura.

O COBIT 5, da ISACA, é “uma estrutura abrangente que auxilia as empresas a alcançar seus objetivos para a governança e gestão da TI corporativa”.1 Essa estrutura inclui conjuntos de ferramentas e processos que fazem a ponte entre questões técnicas, riscos de negócios e requisitos de processos. O objetivo da estrutura COBIT 5 é “criar um valor ideal a partir da TI, mantendo um equilíbrio entre realizar benefícios e otimizar os níveis de risco e o uso de recursos”. O COBIT 5 alinha a TI aos negócios, ao mesmo tempo em que fornece governança em torno dele.

A família de produtos COBIT 5 tem muitos documentos para escolher, e às vezes é difícil saber exatamente onde procurar informações específicas. A Figura 2 mostra a família de produtos COBIT 5 rapidamente.2 Os facilitadores de COBIT são fatores que, individual e coletivamente, influenciam se algo vai funcionar.

O quadro COBIT baseia-se em cinco princípios(figura 3). Aplicar esses princípios a qualquer arquitetura garante suporte empresarial, alinhamento e otimização de processos.3

Usando uma combinação das estruturas sabsa e princípios de COBIT, facilitadores e processos, uma arquitetura de cima para baixo pode ser definida para cada categoria na figura 2. Como exemplo, ao desenvolver a arquitetura de rede de computadores, uma abordagem de cima para baixo de camadas contextuais para componentes pode ser definida usando esses princípios e processos(figura 4).

TOGAF é uma estrutura e um conjunto de ferramentas de suporte para o desenvolvimento de uma arquitetura corporativa.4 O ciclo de desenvolvimento de arquitetura TOGAF é ótimo para ser usado para qualquer empresa que esteja começando a criar uma arquitetura de segurança corporativa. Semelhante a outras estruturas, a TOGAF começa com a visão e a camada de negócios, seguida por tecnologia e informação(figura 5).5

O TOGAF é uma estrutura útil para definir a arquitetura, os objetivos e a visão; completando uma análise de lacunas; e monitorando o processo.

Usando o SABSA, COBIT e TOGAF em conjunto, pode-se definir uma arquitetura de segurança que esteja alinhada com as necessidades dos negócios e atenda a todos os requisitos das partes interessadas. Após a definição da arquitetura e dos objetivos, a estrutura TOGAF pode ser usada para criar os projetos e etapas e monitorar a implementação da arquitetura de segurança para levá-la onde deveria estar.

Usando as frameworks para desenvolver uma arquitetura de segurança corporativa

A pergunta justa é sempre: “Por onde a empresa deve começar?”

Se olharmos para essas estruturas, o processo é bastante claro. Essa deve ser uma abordagem de cima para baixo — comece olhando para os objetivos, objetivos e visão do negócio.

As etapas iniciais de uma abordagem ágil simplificada para iniciar um programa de arquitetura de segurança corporativa são:

Identificar objetivos, metas e estratégia de negócios
Identifique atributos de negócios necessários para atingir esses objetivos
Identifique todos os riscos associados aos atributos que podem impedir que uma empresa atinja seus objetivos
Identifique os controles necessários para gerenciar o risco
Defina um programa para projetar e implementar esses controles:
- Definir arquitetura conceitual para risco de negócios:
  - Governança, política e arquitetura de domínio
  - Arquitetura de gerenciamento de riscos operacionais
  - Arquitetura de informações
  - Arquitetura de gerenciamento de certificados
  - Arquitetura de controle de acesso
  - Arquitetura de resposta a incidentes
  - Arquitetura de segurança de aplicativos
  - Arquitetura de serviços web
  - Arquitetura de segurança de comunicação
- Definir arquitetura física e mapa com arquitetura conceitual:
  - Segurança da plataforma
  - Segurança de hardware
  - Segurança de rede
  - Segurança do sistema operacional
  - Segurança de arquivos
  - Segurança do banco de dados, práticas e procedimentos
- Definir arquitetura de componentes e mapa com arquitetura física:
  - Normas de segurança (por exemplo, Instituto Nacional de Padrões e Tecnologia dos EUA [NIST], ISO)
  - Produtos e ferramentas de segurança (por exemplo, antivírus [AV], rede virtual privada [VPN], firewall, segurança sem fio, scanner de vulnerabilidade)
  - Segurança de serviços web (por exemplo, protocolo HTTP/HTTPS, interface de programa de aplicativos [API], firewall de aplicativos web [WAF])
- Definir arquitetura operacional:
  - Guias de implementação
  - Administrações
  - Gerenciamento de configuração/patch
  - Monitorização
  - Log
  - Teste de caneta
  - Gerenciamento de acesso
  - Gerenciamento de mudanças
  - Forense, etc.

É simples assim. Depois que todos os riscos são identificados e avaliados, a empresa pode começar a projetar componentes de arquitetura, como políticas, conscientização do usuário, rede, aplicativos e servidores.

A Figura 6 retrata a abordagem ágil simplificada para iniciar um programa de arquitetura de segurança corporativa.

Um exemplo da vida real

Esta seção descreve um exemplo simples e prático das etapas que podem ser tomadas para definir uma arquitetura de segurança para uma empresa.

A empresa neste exemplo é uma empresa financeira, e seu objetivo é ter um milhão de usuários adicionais nos próximos dois anos. Alguns dos atributos necessários para o negócio são:

Disponibilidade— Os sistemas precisam estar sempre disponíveis para os clientes.
Privacidade do cliente — a privacidade dos clientes precisa ser garantida.
Precisão — As informações dos clientes e da empresa devem ser precisas.
Regulação — A empresa está sob regulamentação (Indústria de Cartões de Pagamento [PCI] neste caso) e deve estar alinhada com os requisitos regulatórios.

Parte do risco do negócio inclui:

Não ter um plano adequado de recuperação de desastres para aplicações (isso está vinculado ao atributo de disponibilidade)
Vulnerabilidade nos aplicativos (isso está ligado aos atributos de privacidade e precisão)
Falta de segregação de deveres (SoD) (isso está ligado ao atributo de privacidade)
Não conformidade com o Padrão de Segurança de Dados da Indústria de Cartões de Pagamento (PCI DSS) (isso está vinculado ao atributo regulamentado)

Alguns dos controles são:

Construa um ambiente de recuperação de desastres para os aplicativos (incluído nos processos COBIT DSS04)
Implementar firewalls de gerenciamento de vulnerabilidades e firewalls de aplicativos (incluídos nos processos COBIT DSS05)
Implementar controles de infraestrutura de chaves públicas (PKI) e criptografia (incluídos nos processos COBIT DSS05)
Implementar o SoD para as áreas necessárias (incluído nos processos COBIT DSS05)
Implementar controles PCI DSS

Todos os controles são automaticamente justificados porque estão diretamente associados aos atributos do negócio.

Como qualquer outra estrutura, o ciclo de vida da arquitetura de segurança corporativa precisa ser gerenciado adequadamente. É importante atualizar constantemente os atributos e riscos do negócio e definir e implementar os controles adequados.

O ciclo de vida do programa de segurança pode ser gerenciado usando a estrutura TOGAF. Isso é feito criando a visão e as metas da arquitetura, concluindo uma análise de lacunas, definindo os projetos e implementando e monitorando os projetos até a conclusão e início de novo(figura 5).

Usando o CMMI para monitorar, medir e relatar o progresso do desenvolvimento da arquitetura

Finalmente, deve haver controles de monitoramento suficientes e indicadores-chave de desempenho (KPIs) em vigor para medir a maturidade da arquitetura ao longo do tempo.

A primeira fase mede a maturidade atual dos controles necessários no ambiente utilizando o modelo cmmi (Capability Maturity Model Integration, integração de modelo de maturidade de capacidade). O modelo CMMI tem cinco níveis de maturidade, desde o nível inicial até o nível de otimização.6 Para efeitos deste artigo, é adicionado um nível inexistente (nível 0) para os controles que não estão em vigor(figura 7).

O objetivo é definir o nível de maturidade desejado, comparar o nível atual com o nível desejado e criar um programa para alcançar o nível desejado.

Essa maturidade pode ser identificada para uma série de controles. Dependendo da arquitetura, pode ter mais ou menos controles.

Alguns controles de exemplo são:

Controles processuais
- Estrutura de gerenciamento de riscos
- Conscientização do usuário
- Governança de segurança
- Políticas e normas de segurança
Controles operacionais
- Gestão de ativos
- Gerenciamento de incidentes
- Gerenciamento de vulnerabilidades
- Gerenciamento de mudanças
- Controles de acesso
- Gestão e monitoramento de eventos
Controles de aplicativos
- Plataforma de segurança de aplicativos (firewall de aplicativos web [WAF], SIEM, segurança avançada de ameaça persistente [APT])
- Plataforma de segurança de dados (criptografia, e-mail, monitoramento de atividades de banco de dados [DAM], prevenção de perda de dados [DLP])
- Gerenciamento de acesso (gerenciamento de identidade [IDM], login único [SSO])
Controles de ponto final
- Segurança do host (AV, sistema de prevenção de intrusões de host [HIPS], gerenciamento de patches, configuração e gerenciamento de vulnerabilidades)
- Segurança móvel (traga seu próprio dispositivo [BYOD], gerenciamento de dispositivos móveis [MDM], controle de acesso de rede [NAC])
- Autenticação (autenticação, autorização e contabilidade [AAA], dois fatores, gerenciamento privilegiado de identidade [PIM])
Controles de infraestrutura
- Negação distribuída de serviço (DDoS), firewall, sistema de prevenção de intrusões (IPS), VPN, web, e-mail, wireless, DLP, etc.

O resultado desta fase é uma classificação de maturidade para qualquer um dos controles para o status atual e status desejado. Após o desenvolvimento do programa e a implementação dos controles, começa a segunda fase da gestão da maturidade. Nesta fase, as classificações são atualizadas e a equipe de gestão tem visibilidade do progresso.

A Figura 8 mostra um exemplo de um painel de maturidade para arquitetura de segurança.

Conclusão

Independentemente da metodologia ou estrutura utilizada, a arquitetura de segurança corporativa em qualquer empresa deve ser definida com base no risco disponível para essa empresa. As estruturas empresariais SABSA, COBIT e TOGAF garantem o alinhamento da arquitetura definida com metas e objetivos de negócios.

O uso dessas estruturas pode resultar em uma arquitetura de segurança bem-sucedida que esteja alinhada com as necessidades dos negócios:

Os princípios e facilitadores do COBIT fornecem as melhores práticas e orientações sobre alinhamento de negócios, entrega máxima e benefícios.
O MODELO DE AVALIAÇÃO DE PROCESSOS COBIT (PAM) fornece uma visão completa dos processos e controles de requisitos para arquitetura de segurança de nível corporativo.
As camadas e a estrutura da SABSA criam e definem uma arquitetura de cima para baixo para cada requisito, controle e processo disponíveis no COBIT.
A estrutura togaf é útil para definir as metas, benefícios e visão da arquitetura e a criação e implementação de projetos para atingir essas metas.
O modelo CMMI é útil para fornecer um nível de visibilidade para a gestão e o conselho de arquitetura, e para relatar a maturidade da arquitetura ao longo do tempo.

A abordagem ágil simplificada para iniciar um programa de arquitetura de segurança corporativa garante que a arquitetura de segurança corporativa faça parte dos requisitos de negócios, atende especificamente às necessidades dos negócios e é automaticamente justificada.

Notas

ISACA, COBIT 5, EUA, 2012, <www.isaca.org/COBIT/Pages/COBIT-5-Framework-product-page.aspx>
Thomas, M.; “As principais publicações de COBIT: Um Olhar Rápido”, COBIT Focus,13 de abril de 2015, <www.isaca.org/Knowledge-Center/Research/Documents/COBIT-Focus-The-Core-COBIT-Publications-A-Quick-Glance_nlt_Eng_0415.pdf>
Op cit, ISACA
O Grupo Aberto, “Bem-vindo ao TOGAF 9.1, um Padrão de Grupo Aberto, http://pubs.opengroup.org/architecture/togaf9-doc/arch/
O Grupo Aberto, “TOGAF 9.1 Architecture Development Cycle”, http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap05.html
Instituto CMMI, “Níveis de Maturidade cmmi”, http://cmmiinstitute.com/capability-maturity-model-integration

Artigo Original