Os sistemas de informação representam o principal frame por onde transitam as informações de uma instituição. Afinal o objetivo destes sistemas é justamente concentrar o maior fluxo possível de informações permitindo agilidade nos processos de negócio. Entretanto nem sempre as empresas adotam as medidas de segurança necessárias durante o desenvolvimento de sistemas, para a proteção adequada destas informações.
Controles pontuais são perfeitamente válidos, porém não garantem, por si só, a segurança das informações. Um ambiente seguro devem empregar produtos de segurança sem esquecer de inserir a segurança em seus processos. Muitas empresas vêem empregando controles individuais, desconsiderando a necessidade de definição e principalmente de formalização de seus processos.
A área de desenvolvimento das empresas é um exemplo claro de processo que nem sempre recebe as atenções necessárias no que diz respeito à segurança da informação. Garantir a segurança da rede corporativa não significa ter sistemas de informação seguros. A informalidade ainda predomina nas relações entre desenvolvimento e suporte operacional.
O primeiro passo para inserir a segurança da informação na área de desenvolvimento de sistemas é definir formalmente este processo. Uma abordagem adequada é considerar como início do processo as solicitações dos usuários e como final a liberação das novas versões para produção.
Entre estes dois pontos deve existir uma avaliação do Analista de Segurança. Este analista pode ser um dos próprios Analistas de Sistemas, porem capacitados a determinar quais são os controles de segurança necessários para determinada especificação de sistema. Por exemplo, um usuário solicita inserir novos campos em um formulário. O Analista de Segurança deve avaliar esta solicitação e inserir, na especificação, a necessidade de validação de entrada, caso integridade externa seja fundamental para o negócio em questão.
A equipe de desenvolvimento somente deve receber especificações para novos sistemas ou modificações nos sistemas existentes após avaliação dos requisitos de segurança. É indispensável a formalização destes requisitos, juntamente com os requisitos do negócio apontados pelo usuário. O desenvolvimento das soluções deve respeitar integralmente as definições de segurança impostas pelo Analista de Segurança e documentadas junto aos requisitos do sistema.
Após o desenvolvimento da solução, o Analista de Segurança deve realizar uma verificação se os controles realmente são válidos e garantem, no caso do nosso exemplo, a inserção exclusiva de dados representativos. Após passar pela aprovação de segurança é necessário realizar testes formais com os usuários. Estes testes devem ser realizados em ambientes próprios, totalmente isolados do ambiente de produção.
A confirmação dos usuários de que o sistema incorpora as funções solicitadas deve ser visto como requisito mínimo para a distribuição da nova versão no ambiente de produção. Os procedimentos de distribuição também precisam estar definidos formalmente, pois representam uma fase crítica do processo. Quando possível, convém que sejam realizados testes verificando se as novas versões não possuem funções ocultas, ou os famosos covert channels, que já foram responsáveis por diversos incidentes de segurança.
Cada fase do processo deve ser formalizada e devidamente autorizada. Para isso, é importante manter uma lista de níveis de autorização, ou seja, quem pode autorizar cada fase do processo. Deve-se exigir também que os desenvolvedores documentem cada novo sistema ou modificação realizada, destacando as funções de segurança incorporadas.
Entretanto, a segurança da informação não é obtida apenas através da formalização do processo. Algumas medidas devem ser adotadas para garantir, sobretudo que cada informação é divulgada a quem se faz necessário – conceito conhecido como need to know.
Em primeiro lugar e requisito para todo o processo de desenvolvimento, os ambientes de produção e desenvolvimento deveem ser segregados. Além de fisicamente separados, em salas ou locais diferentes, devem estar logicamente separados, de preferência em redes próprias, separadas por firewalls da rede de produção. Máquinas da produção não devem realizar suporte ou qualquer outra atividade, devem ser vistas como ferramentas de desenvolvimento apenas.
Um segundo passo importante é não fornecer dados reais para testes. Muitas empresas copiam sua base de dados de alguns meses anteriores e disponibilizam aos desenvolvedores como teste. Claro que a base de testes deve representar como a máxima fidelidade a realidade do negócio. Porém pode-se obter isso através de procedimentos de descaracterização da base de dados. É importante substituir dados de clientes por dados aleatórios, números de contas por números aleatórios, ou seja, e qualquer outra informação que possa ser refletida na realidade deve ser descaracterizada.
Controles de criptografia devem ser sempre considerados e avaliados. Nem sempre são necessário, principalmente frente ao overhead que podem causar nos servidores de produção. Porém existem soluções interessantes, como autenticação de mensagens e serviços de não repúdio que não acrescentam volume às taxas de processamento.
O controle de acesso ao código fonte deve ser rigidamente definido. É importante que o responsável pelo desenvolvimento atribua a cada desenvolvedor acesso aos fontes e projetos que este está diretamente ligado. Produtos de controle de versão são interessantes neste sentido, entretanto uma organização através de servidores de arquivos com acessos definidos também resolve a questão.
Por último, é importante que o ambiente de teste seja dedicado. Uma estação de trabalho e um pequeno servidor rodando a aplicação com acesso a base de testes são o suficiente para que os usuários possam identificar e testar as novas características desenvolvidas. Esse ambiente não deve ser conectado ao ambiente de produção. Pode estar isolado ou conectado ao ambiente de desenvolvimento.
Estes são alguns mecanismos que quando adotados concorrem para o aumento da segurança nas aplicações de negócio. Não se deve esquecer que o controle e auditoria do processo devem ser realizados pelo Security Officer, ou pessoa que assume este papel na empresa. Vale ressaltar que estas medidas de segurança não só protegem as informações da empresa, mas também organizam o processo de desenvolvimento. Nada mais correto, pois um ambiente seguro é forte candidato a ser um ambiente organizado.
Controles pontuais são perfeitamente válidos, porém não garantem, por si só, a segurança das informações. Um ambiente seguro devem empregar produtos de segurança sem esquecer de inserir a segurança em seus processos. Muitas empresas vêem empregando controles individuais, desconsiderando a necessidade de definição e principalmente de formalização de seus processos.
A área de desenvolvimento das empresas é um exemplo claro de processo que nem sempre recebe as atenções necessárias no que diz respeito à segurança da informação. Garantir a segurança da rede corporativa não significa ter sistemas de informação seguros. A informalidade ainda predomina nas relações entre desenvolvimento e suporte operacional.
O primeiro passo para inserir a segurança da informação na área de desenvolvimento de sistemas é definir formalmente este processo. Uma abordagem adequada é considerar como início do processo as solicitações dos usuários e como final a liberação das novas versões para produção.
Entre estes dois pontos deve existir uma avaliação do Analista de Segurança. Este analista pode ser um dos próprios Analistas de Sistemas, porem capacitados a determinar quais são os controles de segurança necessários para determinada especificação de sistema. Por exemplo, um usuário solicita inserir novos campos em um formulário. O Analista de Segurança deve avaliar esta solicitação e inserir, na especificação, a necessidade de validação de entrada, caso integridade externa seja fundamental para o negócio em questão.
A equipe de desenvolvimento somente deve receber especificações para novos sistemas ou modificações nos sistemas existentes após avaliação dos requisitos de segurança. É indispensável a formalização destes requisitos, juntamente com os requisitos do negócio apontados pelo usuário. O desenvolvimento das soluções deve respeitar integralmente as definições de segurança impostas pelo Analista de Segurança e documentadas junto aos requisitos do sistema.
Após o desenvolvimento da solução, o Analista de Segurança deve realizar uma verificação se os controles realmente são válidos e garantem, no caso do nosso exemplo, a inserção exclusiva de dados representativos. Após passar pela aprovação de segurança é necessário realizar testes formais com os usuários. Estes testes devem ser realizados em ambientes próprios, totalmente isolados do ambiente de produção.
A confirmação dos usuários de que o sistema incorpora as funções solicitadas deve ser visto como requisito mínimo para a distribuição da nova versão no ambiente de produção. Os procedimentos de distribuição também precisam estar definidos formalmente, pois representam uma fase crítica do processo. Quando possível, convém que sejam realizados testes verificando se as novas versões não possuem funções ocultas, ou os famosos covert channels, que já foram responsáveis por diversos incidentes de segurança.
Cada fase do processo deve ser formalizada e devidamente autorizada. Para isso, é importante manter uma lista de níveis de autorização, ou seja, quem pode autorizar cada fase do processo. Deve-se exigir também que os desenvolvedores documentem cada novo sistema ou modificação realizada, destacando as funções de segurança incorporadas.
Entretanto, a segurança da informação não é obtida apenas através da formalização do processo. Algumas medidas devem ser adotadas para garantir, sobretudo que cada informação é divulgada a quem se faz necessário – conceito conhecido como need to know.
Em primeiro lugar e requisito para todo o processo de desenvolvimento, os ambientes de produção e desenvolvimento deveem ser segregados. Além de fisicamente separados, em salas ou locais diferentes, devem estar logicamente separados, de preferência em redes próprias, separadas por firewalls da rede de produção. Máquinas da produção não devem realizar suporte ou qualquer outra atividade, devem ser vistas como ferramentas de desenvolvimento apenas.
Um segundo passo importante é não fornecer dados reais para testes. Muitas empresas copiam sua base de dados de alguns meses anteriores e disponibilizam aos desenvolvedores como teste. Claro que a base de testes deve representar como a máxima fidelidade a realidade do negócio. Porém pode-se obter isso através de procedimentos de descaracterização da base de dados. É importante substituir dados de clientes por dados aleatórios, números de contas por números aleatórios, ou seja, e qualquer outra informação que possa ser refletida na realidade deve ser descaracterizada.
Controles de criptografia devem ser sempre considerados e avaliados. Nem sempre são necessário, principalmente frente ao overhead que podem causar nos servidores de produção. Porém existem soluções interessantes, como autenticação de mensagens e serviços de não repúdio que não acrescentam volume às taxas de processamento.
O controle de acesso ao código fonte deve ser rigidamente definido. É importante que o responsável pelo desenvolvimento atribua a cada desenvolvedor acesso aos fontes e projetos que este está diretamente ligado. Produtos de controle de versão são interessantes neste sentido, entretanto uma organização através de servidores de arquivos com acessos definidos também resolve a questão.
Por último, é importante que o ambiente de teste seja dedicado. Uma estação de trabalho e um pequeno servidor rodando a aplicação com acesso a base de testes são o suficiente para que os usuários possam identificar e testar as novas características desenvolvidas. Esse ambiente não deve ser conectado ao ambiente de produção. Pode estar isolado ou conectado ao ambiente de desenvolvimento.
Estes são alguns mecanismos que quando adotados concorrem para o aumento da segurança nas aplicações de negócio. Não se deve esquecer que o controle e auditoria do processo devem ser realizados pelo Security Officer, ou pessoa que assume este papel na empresa. Vale ressaltar que estas medidas de segurança não só protegem as informações da empresa, mas também organizam o processo de desenvolvimento. Nada mais correto, pois um ambiente seguro é forte candidato a ser um ambiente organizado.
No comments:
Post a Comment