Por que o controle de qualidade de software e a necessidade de segurança de TI precisam trabalhar juntos?

Esse artigo descreve uma nova abordagem de segurança com as equipes de desenvolvimento de software e garantia de qualidade de software trabalhando juntas para serem exponencialmente mais efetivas. Ele explica como processos de garantia de qualidade podem ajudar a TI a ser mais segura e como a segurança em TI pode ajudar na segurança mais eficiente de ambiente de teste. Os leitores também aprenderão como incorporar melhor o teste de segurança no ciclo de vida de desenvolvimento de software.

Jeff Laskowski, Senior IT Specialist, IBM

photo of Jeff LaskowskiJeff Laskowski, Especialista Sênior em TI no Software Group da IBM. Ele traz consigo mais de uma década de experiência em TI com grande foco em entrega de software e segurança. Jeff se juntou à equipe da IBM em julho de 2006, como engenheiro principal da unidade de negócios Great Lakes Rational Quality Assurance.



19/Out/2011

A unificação da garantia de qualidade de software (QA) e segurança de TI resulta em uma relação simbiótica, mas apenas algumas poucas organizações começaram a entender os benefícios dessas duas equipes separadas trabalhando juntas. A aliança da garantia de qualidade e da segurança de TI é natural, pois a segurança de TI é uma forma de garantia de qualidade em seu nível básico. Uma exposição de segurança em qualquer forma é um problema de garantia de qualidade.

Tanto a segurança de TI quanto a garantia de qualidade estão preocupadas em remover riscos. As equipes de segurança de TI trabalham para remover riscos de segurança e as equipes de garantia de qualidade trabalham para remover riscos de qualidade. Portanto, esse alinhamento deveria ter ocorrido há anos. Esse artigo explica os pontos naturais de integração comportamental entre os dois departamentos, e como a integração entre as famílias de produtos de software IBM® Rational®, Information Management, WebSphere® e Tivoli® Security podem ajudar.

Controle de acesso

Segurança de TI e garantia de qualidade trabalhando juntas são exponencialmente mais eficientes. O resultado será um departamento de GQ mais orientado à segurança e um departamento de segurança em TI mais orientado à qualidade, o que deverá ajudar a remover mais riscos e fornecer melhor continuidade.

A primeira área de interesse entre garantia de qualidade e segurança de TI está relacionada ao controle de acesso. O controle de acesso está continuamente mudando e evoluindo com base em padrões organizacionais internos, mudanças externas regulamentares de conformidade ou por motivos de política de segurança de TI. Normalmente, o controle de acesso é deixado para a equipe de desenvolvimento de software. Ele é tratado como qualquer requisito e deve competir com outros requisitos para ser executado em um aplicativo. Essa prática causa dificuldades para as equipes de segurança de TI e auditoria no rastreamento e alteração de políticas de controle de acesso com a mesma rapidez com que os requisitos regulamentares de conformidade, como SOX, HIPAA, PCI e outros mudam.

Quando as políticas de controle de acesso são escritas dentro do aplicativo, essas políticas precisam competir pelos mesmos recursos que as melhorias e os aprimoramentos do aplicativo. Os donos de aplicativos provavelmente desejarão gastar dinheiro em melhorias e aprimoramentos do aplicativo, em vez de atualizar as políticas de controle de acesso. No final, isso cria a necessidade de exteriorizar as políticas de controle de acesso do aplicativo. Além disso, a natureza mutável da conformidade complica ainda mais a necessidade de controles de acesso externos. As organizações entendem que a exteriorização do controle de acesso não pode ocorrer sem consequências.

Como, então, exteriorizamos o controle de acesso do aplicativo? A segurança de TI precisa se envolver no ciclo de vida de desenvolvimento do software (SDLC).

As políticas precisam ser aprovadas da mesma forma que qualquer outro requisito. A política de segurança precisa ser listada no documento de requisitos, idealmente usando o IBM® Rational® DOORS®, Rational® RequisitePro® ou Rational® Requirements Composer.Isso é importante porque, à medida que as políticas de segurança mudam, o controle de acesso também mudará. Entender e rastrear essas mudanças é uma prática recomendada. A equipe de garantia de qualidade trabalha com os donos do aplicativo o tempo inteiro e pode ser capaz de fornecer esse nível de suporte para políticas de controle de acesso.

O padrão emergente hoje em controle de acesso é Extensible Access Control Markup Language, ou XACML, que é um padrão reutilizável com base em XML usado para controle de acesso. O XACML diz respeito a dar às pessoas certas as informações certas no momento certo. Muitas empresas adotam XACML sem considerar o processo necessário para ser bem-sucedido em sua implementação. Ao criar seu processo XACML em seu SDLC, você cria coesão com a equipe de desenvolvimento de software. Essa abordagem é excelente para organizações que já têm segurança de gerenciamento de política de aplicativo integrada no aplicativo.

Organizações que consideram uma abordagem de XACML para o gerenciamento de política de segurança são frequentemente inibidas pela noção de que remover todas as políticas de segurança existentes dos aplicativos legados e recriá-los com XACML seria impraticável. Essa abordagem dá às organizações a capacidade de manter suas políticas de segurança existentes no lugar, ao mesmo tempo em que criam novas políticas de segurança em XACML. Ao trabalhar com a equipe de garantia de segurança, você está, de fato, integrando seu processo XACML no SDLC, o que significa que alterações podem ser feitas ao aplicativo e à arquitetura de XACML, se necessário. Isso remove a necessidade de remover todas as políticas de segurança de um aplicativo legado e permite adotar uma abordagem mais flexível. É possível decidir alterar uma política legada ou usar uma política XACML nova reutilizável.

Se você estiver considerando o uso do IBM® Tivoli® Security Policy Manager como uma política de criação de política de XACML, software como o IBM® Rational® ClearCase® e o IBM® Rational Team Concert™ pode ser usado como controle de fonte para os ativos de controle de acesso. Os ativos do Tivoli Security Policy Manager são baseados em XML e podem ser facilmente armazenados em qualquer uma das ferramentas. Testes automatizados podem ser criados usando o IBM® Rational® Functional Tester e o IBM® Rational® Performance Tester. A seguir, é possível testar automaticamente o comportamento dos scripts XACML no release de novas versões de produtos. Além disso, ferramentas como DOORS, RequisitePro e Rational Requirements Composer permitem a rastreabilidade a partir dos requisitos para os ativos do Tivoli Security Policy Manager. A Figura 1 representa requisitos XACML não funcionais de armazenamento do Rational Requisite Composer para um sistema.

O IBM® WebSphere® ILOG tem funcionalidades que permitem que os sistemas de gerenciamento de regras de negócio alimentem o mecanismo do Rational Requirements Composer e os produtos do Tivoli Security Policy Manager para permitir um nível mais alto de abstração e maior rastreabilidade em toda a corporação. Usando os produtos em conjunto não só permite que uma organização exteriorize seu controle de acesso, mas que o faça de uma forma repetível, sustentável e natural, que permite crescimento e mudança.

Figura 1. Visualização do Rational Requirements Composer de requisitos não funcionais
Visualização do Rational Requirements Composer de requisitos não funcionais

Visualização maior da Figura 1.


Segurança do aplicativo

Hoje, as organizações tendem a desenvolver aplicativos sem qualquer pensamento sobre segurança até que o aplicativo esteja totalmente desenvolvido. Esse é o cenário típico de "vamos jogar isso para a equipe de segurança de TI". O problema com esse cenário é que quaisquer problemas de segurança identificados imediatamente antes da implementação causarão grandes dores de cabeça à equipe de desenvolvimento ou à equipe de segurança de TI. O produto será implementado com brechas de segurança ou o aplicativo será atrasado, pois precisa de mais ciclos pelo SDLC para remediar o risco de segurança.

As equipes de GQ descobriram, há muito tempo, que profissionais de garantia de qualidade devem ser envolvidos em estágios iniciais do ciclo de vida de desenvolvimento de software por vários motivos. O primeiro motivo é que encontrar problemas de qualidade imediatamente antes de uma implementação causa grandes dores de cabeça. Mas a GQ também descobriu que encontrar problemas durante a fase de coleta de requisitos é muito mais fácil e barato de corrigir durante a fase de requisitos do que depois que os desenvolvedores começaram a escrever. Estar envolvido prematuramente no SDLC também é útil para que as equipes de garantia de qualidade possam começar a criar casos de teste e scripts de teste antes das compilações de software.

A segurança precisa estar fazendo a mesma coisa, trabalhando lado a lado com a equipe de GQ, analistas de sistemas e desenvolvedores para ajudar os analistas de sistema a reunir requisitos e criar o projeto de segurança no projeto de software. Os analistas de segurança de TI também precisam projetar os tipos de testes que devem ser executados em cada estágio. Os profissionais de segurança de TI, em conjunto com a equipe de garantia de qualidade, precisam escrever casos e planos de teste para cada teste que a equipe de segurança de TI deseja.

Nos últimos cinquenta anos, os hackers começaram a atacar aplicativos da Web porque as equipes de garantia de qualidade e de segurança de TI não trabalharam juntas, deixando grandes brechas nos aplicativos. Essa ação da comunidade de hackers forçou outro ponto de colaboração entre GQ e segurança de TI. A ideia aqui é começar o teste de segurança prematuramente no ciclo de vida de desenvolvimento do software. As equipes de GQ e de segurança definirão requisitos não funcionais que os desenvolvedores precisarão seguir. Esses requisitos não funcionais são a base para criar equipes de desenvolvimento com a mente em segurança e a equipe de QA precisa trabalhar lado a lado com a equipe de segurança de TI no princípio. A equipe de segurança de TI, em conjunto com a equipe de garantia de qualidade, poderia ajudar a criar um centro de excelência para definir as práticas padrão de codificação de segurança e teste de segurança, bem como definir os níveis de educação do programador e de treinamento em segurança.

A verdade simples é que encontrar brechas de segurança prematuramente custa menos a uma organização para remediar, o que faz sentido comercialmente. Por outro lado, aguardar que um aplicativo seja implementado ou esteja perto da implementação antes de encontrar brechas de segurança é uma prática ruim. Equipes de garantia de qualidade tiveram dificuldades com a criação de testes de segurança porque eles eram diferentes de testes funcionais e de desempenho. Em testes funcionais e de desempenho, os resultados esperados são documentados antes que o teste inicie e a equipe de qualidade observa se os resultados esperados coincidem com os resultados obtidos. Em testes de segurança, a equipe de garantia de qualidade está preocupada somente com resultados inesperados e em testar o desconhecido. Equipes de segurança de TI podem ajudar a equipe de GQ a criar esses testes. A família de software de segurança IBM® Rational® AppScan® pode ser extremamente útil ao ajudar uma equipe de GQ a iniciar o teste de vulnerabilidade do aplicativo. O Rational AppScan pode ser executado com relação a aplicativos para encontrar brechas de segurança no nível do aplicativo ou da infraestrutura.


Conexão única corporativa

Muitas organizações hoje começaram a percorrer o caminho de conexão única corporativa, pois oferece economia de custos, em termos de redução do tempo necessário para acessar dados, e maior segurança, em termos de gerenciamento de senhas. Um dos desafios da conexão única corporativa é a geração de perfis dos clientes para trabalhar com os vários aplicativos dentro da organização. Devido à natureza dinâmica das telas de login, o cliente ESSO de conexão única corporativa poderia ter dificuldades ao reconhecer as telas e os campos usados pelo IBM® Tivoli® Access Manager for Enterprise Single Sign-On (TA MESSO).

As equipes de segurança poderiam se voltar à equipe de automação de garantia de qualidade para obter ajuda com os perfis mais difíceis. O processo de criação de um perfil avançado é similar, de muitas formas, ao processo de criar um script de teste automatizado. As equipes de garantia de qualidade que trabalham com scripts automatizados têm um entendimento maior de como os sistemas de janelas funcionam, portanto, podem fornecer insight sobre como as janelas se comportam. Além disso, como os testadores de software automatizado passam várias horas por semana entendendo o comportamento das telas de aplicativos, o testador pode oferecer uma abordagem pragmática para depurar uma tela de login complicada.

Além disso, ferramentas como o IBM® Rational® Functional Tester e o IBM® Rational® podem ser usadas para a resolução de problemas, de forma a descobrir porque uma tela está apresentando comportamento incorreto. Verificações de ponto de validação nas ferramentas de teste funcional podem ser extremamente úteis para entender quais propriedades estão mudando em um dado campo. A Figura 2 é uma captura de tela do Rational Functional Tester exibindo propriedades vitais da janela de login por meio de uma verificação de validação de propriedade e destacando uma propriedade que está mudando. As informações exibidas na Figura 2 seriam difíceis de entender por parte de uma equipe de segurança, mas são fáceis de serem identificadas por uma ferramenta como o Rational Functional Tester. Testadores de software automatizados têm muitos truques, como WinSpy e outras ferramentas, que podem ser extremamente úteis para depurar janelas em mudança. As organizações podem aproveitar os mesmos recursos para teste automatizado e conexão única corporativa.

Figura 2. Exemplo de validação de propriedade do Rational Functional Tester
Exemplo de validação de propriedade do Rational Functional Tester

Visualização maior da Figura 2.


Gerenciamento de dados de teste

Outro desafio em testes é a segurança de dados em ambientes que não sejam de produção. Muitas organizações hoje preenchem os ambientes intermediários de desenvolvimento e teste com cópias dos dados de produção. O problema com essa prática é que carregar os ambientes de teste e desenvolvimento com dados de produção expõe as áreas de teste e desenvolvimento a informações pessoais identificáveis (PII), como números de seguridade social e datas de nascimento. Quando PII são carregadas em um ambiente que não seja de produção, os sistemas devem obedecer a todos os regulamentos de SOX, HIPAA, PCI e assim por diante, e estão sujeitos às mesmas exposições de auditoria e multas. Essa prática fez com que muitas organizações falhassem em auditorias de segurança e resultou em muitas multas.

Outro ponto de interseção para a segurança de TI é ajudar as equipes de garantia de qualidade a criar processos repetíveis para preencher dados purificados em ambientes que não sejam de produção na empresa. A equipe de segurança de TI precisa ajudar a criar scripts que limparão as PII antes que elas entrem em ambientes de teste e desenvolvimento. A equipe de segurança de TI pode ajudar a equipe de desenvolvimento a criar um processo repetido para preencher dados e garantir que dados purificados sejam usados.

Os softwares IBM Rational, Information Management e Tivoli podem ajudar a levar isso um pouco adiante ao fornecer suporte em nível de ferramenta para criar esse ambiente. O IBM ® Optim™ Integrated Data Management pode ser incorporado ao produto Rational Quality Manager para permitir que dados recém-purificados preencham o sistema antes do início de um teste. Esse processo também ajuda a equipe de garantia de qualidade ao criar uma plataforma de teste estável para garantir um estado do aplicativo que permitirá que as equipes de garantia de qualidade criem scripts de teste automatizado mais facilmente. O Tivoli® Security Information e o Event Manager também podem ser usados para monitorar o processo de purificação para ajudar a garantir que os sistemas estejam sendo carregados com dados adequadamente purificados e enviar avisos se forem detectados erros no processo.


Resumo

As equipes de segurança de TI e de garantia de qualidade precisam trabalhar juntas em segurança de aplicativos, gerenciamento de acesso, conexão única corporativa e gerenciamento de dados de teste. As duas unidades de negócios, ao trabalharem juntas, são exponencialmente mais eficientes. O resultado será um departamento de GQ mais orientado à segurança e um departamento de segurança em TI mais orientado à qualidade, o que deverá ajudar a remover mais riscos e fornecer melhor continuidade.

Recursos

Aprender

Obter produtos e tecnologias

  • Faça download de uma versão gratuita do software Rational.
  • Avalie outros produtos de software da IBM da forma que melhor lhe convier: faça o download da versão de avaliação, experimente-o on-line, use-o em um ambiente de nuvem ou passe algumas horas no SOA Sandbox aprendendo a implementar Arquitetura Orientada a Serviços de forma eficiente.

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=Rational, Tivoli, WebSphere
ArticleID=765899
ArticleTitle=Por que o controle de qualidade de software e a necessidade de segurança de TI precisam trabalhar juntos?
publish-date=10192011