Segurança Virtual para o Segmento de Mercado de Energia Nuclear

Ao implementar sistemas com base em software, como instrumentação e controle digitais para o segmento de mercado nuclear, é vital incluir uma avaliação de segurança virtual como parte da arquitetura e do processo de desenvolvimento. Ao integrar e entregar sistemas com uso intenso de softwares para o segmento de mercado nuclear, as equipes de engenharia devem usar um ciclo de vida de desenvolvimento de software que seja seguro e guiado por requisitos, garantindo a conformidade com a segurança e o retorno ótimo sobre o investimento. Proteções de confiabilidade, prevenção de perda de dados e garantia de privacidade são argumentos fortes para instalar políticas de segurança virtual estritas.

Irv Badr, Rational Go-To-Market Manager, IBM

Photo of Irv BadrEngenheiro de sistemas e arquiteto de software em diversos segmentos de mercado, Irv é o IBM Rational Go-To-Market Manager para os segmentos de energia e telecomunicações. Ele é coautor e colíder do padrão Telco Modeling Language (TelcoML) e preside o futuro padrão Smart Energy do Object Management Group. Escreveu mais de cinquenta artigos sobre sistemas e arquitetura de software. O email de Irv é ibadr@us.ibm.com.



23/Out/2012

Introdução

Tradicionalmente, sistemas baseados em hardware eram isolados de violações de segurança. Mas, à medida que o acesso à rede se prolifera através das organizações nucleares, a relação entre benefícios e riscos subjacentes pode não ser tão óbvia. Acesso sem precedentes aos sistemas principais, a grande maioria dos quais são implementados em software, deve ser gerenciado através de um novo conjunto de controles de segurança e políticas.

Regulamentos como aqueles definidos pela North American Electric Reliability Corporation (NERC) são relevantes para o segmento de mercado nuclear. Os regulamentos de infraestrutura crítica da NERC são voltados para fornecedores de energia e operadores de geração e transmissão de energia, que são obrigados a seguir todas as suas provisões sobre segurança virtual.

Vulnerabilidades durante os processos de entrega de software podem surgir devido à falta de supervisão da avaliação e requisitos de segurança virtual, levando a integração precária do software e a uma vulnerabilidade geral do sistema. Conformidade regulatória, proteções de confiabilidade e prevenção de perda de dados oferecem um caso de negócios forte para ter políticas de segurança virtual rígidas. A U.S. Nuclear Regulatory Commission (NRC) oferece uma estrutura para ajudar a identificar os ativos digitais que precisam ser protegidos contra ciberataques. Os ativos digitais identificados são chamados de ativos digitais críticos (CDAs). O Título 10 do Código de Regulamentos Federais, 10CFR73.54, intitulado "Protection of Digital Computer and Communications Systems and Networks", requer, em parte, que usinas nucleares comerciais dos EUA tenham alta garantia de que sistemas e redes de computador e de comunicações tenham proteção adequada contra ciberataques. (Consulte Recursos.)

Arquitetura para segurança

Os operadores nucleares obtêm softwares de várias fontes, que podem coletivamente ser vulneráveis a ciberataques. Além disso, na tentativa de satisfazer os requisitos de segurança da NRC mencionados acima, as equipes de projeto, que estão geralmente inundadas com diversos requisitos operacionais e de controle, geralmente omitem ou especificações de segurança ou as interpretam mal.

Ainda além, aplicativos comerciais prontos, ou de software livre, são costumeiramente usados em sistemas complexos afiliados com grandes sistemas de TI e de rede. As organizações nucleares frequentemente usam provedores de serviço de software e fonercedores de software independentes para desenvolver e integrar o sistema final. Entre os vários benefícios da terceirização, o menor custo total, maior conjunto de especialistas disponíveis e menor tempo de maturação são os mais óbvios. No entanto, apesar do número de diversas equipes envolvidas na montagem de software, não são impostos regulamentos de segurança em fornecedores de software independente, software pronto ou componentes de software livre usados no sistema entregue.

É vital incluir uma avaliação da segurança virtual como parte da análise e arquitetura de sistemas antes do desenvolvimento, integração e entrega do sistema. Aplicativos voltados para uso em uma usina nuclear devem usar um ciclo de vida de desenvolvimento de software seguro, que ajuda a garantir aceitação mais rápida e retorno ótimo sobre o investimento.

De acordo com o Regulatory Guide 5.71 da NRC, os produtos devem estar isentos de vulnerabilidades conhecidas e testáveis e de código malicioso através da eliminação, entre outras coisas, do "uso de código não documentado ou de funções maliciosas que possam permitir o acesso ou o uso não autorizados do sistema, ou que permitam que o sistema tenha um comportamento além dos seus requisitos".


Gerenciando o requisito por segurança

Após as especificações do sistema serem capturadas, é vital intercalá-las com requisitos de segurança de fontes como o Regulatory Guide 5.71 da NRC. Como consequência, o documento de requisitos resultante não conterá apenas especificações do usuário, mas também conteúdo regulamentar relacionado à segurança. Portanto, organizar diferentes conjuntos de requisitos antes de dividi-los em módulos para implementação posterior cria um conjunto geral de requisitos do sistema, que incluem especificações de segurança.

Figura 1. Requisitos em forma modular, lado a lado com código fonte gerado por modelo.
Requisitos em forma modular, lado a lado com código fonte gerado por modelo.

Conforme ilustrado na Figura 1, a coluna esquerda contém vários módulos de requisitos, como parâmetros de infusão, canal de bomba e arquitetura de software, no qual cada módulo pode conter requisitos de segurança das fontes NRC ou NERC mencionadas acima. Em muitos casos, requisitos específicos são divididos como objetos, para que possam ser facilmente ser endereçadas com base no identificador de objeto. A Figura 1 mostra os módulos de requisitos e os objetos subjacentes, lado a lado, com módulos de implementação realizados em forma de modelo, código fonte ou módulos comerciais prontos. Cada objeto de requisito pode ser rastreado a um elemento de modelo Unified Modeling Language (UML), mas deve definitivamente ser rastreado ao código fonte final. Esse arranjo cria navegabilidade, o que é vital para a conformidade de segurança. É obtida navegabilidade entre elementos arquiteturais, especificações de segurança, elementos de design ou requisitos de segurança, além da sua implementação subjacente.


Rastreabilidade de requisitos e conformidade

Se a rastreabilidade for bidirecional (ou seja, se cada módulo de requisito e seus objetos de requisito subjacentes estiverem mapeados para um design ou artefato de implementação), esses links podem ser facilmente atravessados em ambas as direções.

Como mostra a Figura 2, os requisitos gerais do usuário são rastreados para o design, implementação ou ambos. Por exemplo, se um elemento de design UML for mapeado para um certo requisito, essa ligação pode ser atravessada em ambas as direções, criando rastreabilidade bidirecional. Da perspectiva do design, os requisitos na esquerda na Figura 2 podem ser rastreados para a frente para a implementação de design ou código fonte correspondente. Além disso, o design ou código fonte é ligado para trás, para os objetos de requisito.

Figura 2. A rastreabilidade de requisitos e a análise de impacto são obtidas de forma confiável, usando a automação de ferramentas.
A rastreabilidade de requisitos e a análise de impacto são obtidas de forma confiável, usando a automação de ferramentas.

Obviamente, a melhor forma de obter rastreabilidade bidirecional é pelo uso de uma ferramenta de gerenciamento de requisitos (RM), que é frequentemente integrada com ambiente de desenvolvimento de design e código fonte, criando assim uma solução de colaboração automatizada. Usar a integração de IBM Rational® DOORS com ferramentas de modelagem UML, Rational Rhapsody e Rational Software Architect criou um ambiente totalmente automatizado e acionado por RM para entrega de aplicativo e sistema. Essas ferramentas são parte da plataforma Rational Jazz, voltada para equipes distribuídas de entrega de produtos que trabalham em um ambiente colaborativo.

Outro grande benefício do uso do ambiente colaborativo torna-se óbvio durante a depuração e teste, quando implementações de design e código fonte são frequentemente alteradas. Essas mudanças podem violar inadvertidamente requisitos de segurança cumpridos anteriormente. O pior é que muitas violações podem permanecer indetectadas no sistema entregue no final. Para evitar essa ameaça, um recurso de análise de impacto (IA) prova-se valioso. IA pode identificar os requisitos afetados pelas mudanças em design e código fonte e identificar os requisitos afetados. Esse recurso torna-se um aspecto útil de um sistema de gerenciamento de mudanças. Por exemplo, as alterações podem ser validadas ou rejeitadas, dependendo de seu impacto nos requisitos subjacentes, sejam específicos ou não da segurança. Na Figura 2, as linhas pontilhadas ilustram IA como complemento da rastreabilidade de requisitos. Esse arranjo é bem imune a alterações feitas na entrega final, quando o sistema é integrado e testado.


Normas e rastreabilidade da segurança virtual

De acordo com o Regulatory Guide 5.71 da NRC, os sistemas são classificados com base no grau de gravidade. Os CDAs que são essenciais para a segurança e funções de segurança e que, se comprometidos, prejudicariam a segurança de todo o sistema, são alocados ao nível defensivo de segurança virtual 4, como mostra a Figura 3.

Figura 3. Visão geral da arquitetura defensiva para segurança virtual, a partir do Regulatory Guide 5.71 da NRC, com rastreabilidade correspondente.
Visão geral da arquitetura defensiva para segurança virtual, a partir do Regulatory Guide 5.71 da NRC, com rastreabilidade correspondente.

Os CDAs de Nível 4 são protegidos contra todos os níveis inferiores, como mostram as setas brancas em negrito na Figura 3. Segundo o Guia Regulamentar 5.71, o fluxo de dados é permitido apenas em uma via do Nível 4 para o Nível 3, e do Nível 3 para o Nível 2. Os dados apenas são transmitidos de um nível para outros através de "dispositivos" que impõem a política de segurança entre cada nível. A arquitetura defensiva geral tem a responsabilidade de "detectar, evitar, atrasar, mitigar e recuperar-se de ciberataques". Outra diretriz recomenda a eliminação de todos os aplicativos, serviços e protocolos que não são necessários para dar suporte à função de base de design dos CDAs contidos.

Para aplicar o esquema descrito na Figura 3, a rastreabilidade é usada de forma tática para automatizar o processo de conformidade. Ao compartimentalizar os requisitos que correspondem a cada nível de CDA, em módulos 0-4, o fluxo de dados entre os níveis é estudado através de links de rastreabilidade. Em outras palavras, CDAs em módulos de requisito de nível 4 que são reunidos com CDAs de nível 3 através de rastreabilidade devem mostrar fluxo de dados apenas em uma direção, ilustrado pelo atributo "direção de fluxo".

CDAs (especificamente seus requisitos subjacentes) que continuam sem rastreamento para outros requisitos exibem o primeiro sintoma de um objeto "órgão" e são candidatos para eliminação. Geralmente, muitos componentes de sistema desnecessários não apenas são capturados como requisitos, mas também são detalhados mais na arquitetura, design e, por fim, código fonte do sistema. Uma auditoria, ao identificar esses requisitos órfãos, não apenas identifica os requisitos, mas também os componentes rastreados de design e código fonte que podem gerar um risco de segurança no sistema implementado. Esse tipo de validação está de acordo com a recomendação 5.71, de remover componentes do sistema desnecessários que não contribuem para a função de base de design.


Validando requisitos de segurança virtual

De uma perspectiva de validação, relatórios de rastreabilidade tabulados pela ferramenta de RM trazem muitos benefícios ao processo final de análise. Embora as ferramentas de RM e de modelagem automatizem o processo de ligar requisitos à implementação subjacente, requisitos ausentes ou incompletos não são facilmente identificados apenas pela rastreabilidade.

Figura 4. Uma visualização tabular ou de matriz pode identificar rapidamente lacunas e criar links de rastreabilidade
Uma visualização tabular ou de matriz pode identificar rapidamente lacunas e criar links de rastreabilidade

Na Figura 4, os casos de uso em colunas mostram as fases de design e implementação do sistema final. Quando organizados em relação a um conjunto de requisitos de segurança virtual, representados na horizontal, algumas conclusões importantes surgem:

  1. Multiplicar requisitos de segurança ligados: nesse caso, o requisito SR-56 é mapeado para mais de caso de uso, "Capture Usage Data" e "Configure Route". Dessa forma, o requisito será aplicado e testado em relação a ambos os casos, e qualquer alteração na implementação de um deles afetará o requisito.
  2. Muitos requisitos de segurança (por exemplo, SR-37, SR-44, SR-46 e alguns outros) não são implementados em nenhum dos três casos de uso. Isso pode ser resultado perda de requisitos, o que significa que o sistema implementado final pode ter perdido esses requisitos de segurança. Caso seja verdade, isso pode fazer com que o sistema fique inconforme. O relatório pode suscitar um plano de ação para corrigir isso.

Após os casos de uso na Figura 4 serem corrigidos e os requisitos de segurança perdidos são implementados, estes últimos podem ser ligados aos casos de uso correspondentes. Para isso, basta clicar na célula de tabela apropriada, criando facilmente um link de rastreabilidade, mais um benefício da automação proporcionada por ferramentas de RM.


A segurança tem diversas dimensões

O local mais lógico para começar a implementar a segurança é no software em evolução marcado para entrega. Desenvolver um processo de negócios para incluir requisitos NERC e NRC em vários estágios principais da operação de uma usina nuclear é essencial para criar uma cultura conscientizada para a segurança. Também é benéfico ativar profissionais de segurança para ajudar a projetar e desenvolver um plano de ação de vulnerabilidade customizado, aplicável às normas de segurança observadas internacionalmente. Da perspectiva de segurança, é vital que uma empresa de energia incorpore medidas de segurança nos seguintes elementos:

  • Os vários componentes de modelo, código fonte e software executável que formam o sistema final
  • O processo colaborativo de desenvolvimento e integração praticado no local e pelas equipes estendidas
  • A estrutura corporativa através da revisão e reengenharia da arquitetura empresarial e do processo de negócios

Conclusão

A implementação da segurança envolve todos os estágios do processo de entrega de produto. Começando com a reunião de requisitos, os requisitos de segurança devem ser gerenciados junto com outros requisitos, a serem entregues eventualmente como produtos baseados em software. Para preservar a fidelidade entre o sistema entregue e os requisitos gerais, a rastreabilidade tornar-se um recurso importante para ajudar a eliminar a perda de requisitos e a cobertura inadequada. A perda causada por mudanças no código fonte ou design durante a integração e teste do sistema pode tornar-se uma importante fonte de falta de conformidade. Ferramentas de gerenciamento de requisitos (RM) oferecem capacidade de análise de impactos automatizada, para evitar a perda de requisitos e auxiliar na criação de um sistema seguro. Além de impingir a segurança virtual através de RM, um programa de segurança efetivo depende de um processo sólido de colaboração durante os esforços de desenvolvimento e entrega de produto. Por fim, processos de negócios e fluxos de trabalho, junto com a estrutura organizacional subjacente, têm um papel importante na realização da segurança virtual efetiva.

Recursos

Aprender

Obter produtos e tecnologias

Discutir

Comentários

developerWorks: Conecte-se

Los campos obligatorios están marcados con un asterisco (*).


Precisa de um ID IBM?
Esqueceu seu ID IBM?


Esqueceu sua senha?
Alterar sua senha

Ao clicar em Enviar, você concorda com os termos e condições do developerWorks.

 


A primeira vez que você entrar no developerWorks, um perfil é criado para você. Informações no seu perfil (seu nome, país / região, e nome da empresa) é apresentado ao público e vai acompanhar qualquer conteúdo que você postar, a menos que você opte por esconder o nome da empresa. Você pode atualizar sua conta IBM a qualquer momento.

Todas as informações enviadas são seguras.

Elija su nombre para mostrar



Ao se conectar ao developerWorks pela primeira vez, é criado um perfil para você e é necessário selecionar um nome de exibição. O nome de exibição acompanhará o conteúdo que você postar no developerWorks.

Escolha um nome de exibição de 3 - 31 caracteres. Seu nome de exibição deve ser exclusivo na comunidade do developerWorks e não deve ser o seu endereço de email por motivo de privacidade.

Los campos obligatorios están marcados con un asterisco (*).

(Escolha um nome de exibição de 3 - 31 caracteres.)

Ao clicar em Enviar, você concorda com os termos e condições do developerWorks.

 


Todas as informações enviadas são seguras.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=80
Zone=Segmentos de mercado, Rational
ArticleID=842081
ArticleTitle=Segurança Virtual para o Segmento de Mercado de Energia Nuclear
publish-date=10232012