Influência da Normas de Segurança da Informação na produção de software

Para entender os aspectos das questões de segurança inerentes na produção de software é preciso compreender a evolução histórica desses dois

elementos. Se tomarmos a família de normas da ISO 2700012 podemos

considerar uma evolução significativa com as dimensões da norma de acordo com o sistema de gerenciamento da segurança da informação tais como o gerenciamento de riscos da segurança da informação (ISO 27005), comunicações intra e interinstitucionais (ISO 27010), Guia para proteção pessoal na nuvem (ISO 27018), continuidade do negócio (ISO 27031) e cibersegurança (ISO 27032).

Considera-se a norma ISO/IEC 27001 como ponto de partida para a operação de um sistema de gerenciamento da segurança da informação, pois estabelece o elemento principal para o mesmo, seus requisitos. Muitos tem atribuído inclusive à influência única da TI na norma. Isso não é bem verdade, mas podemos considerar que ela auxilia sobremaneira o planejamento de requisitos adequado para a construção e sustentação de sistemas informatizados que garantirão o Sistema de Gerenciamento de Segurança da Informação.

Dentre seu corpo de conhecimento, o anexo A da norma ISO 27001 nos alerta para uma série de controles de segurança para serem utilizadas no sentido de aprimorar o sistema de segurança. Dentre esses elementos destacam-se:

A.8 Gestão de ativos – controles relacionados ao inventário de ativos e uso aceitável, e também para a classificação de informação e manuseio de mídias

A.9 Controle de acesso – controles para a política de controle de acesso, gestão de acesso de usuários, controle de acesso a sistemas e aplicações, e responsabilidades dos usuários

12

147 A.10 Criptografia – controles relacionados a gestão de chaves criptográficas

A.12 Segurança nas operações – vários controles relacionados a gestão da produção de TI: gestão de mudança, gestão de capacidade, software malicioso, cópia de segurança, registro de eventos, monitoramento, instalação, vulnerabilidades, etc.

A.13 Segurança nas comunicações – controles relacionados a segurança em rede, segregação, serviços de rede, transferência de informação, mensageria, etc.

A.14 Aquisição, desenvolvimento e manutenção de sistemas – controles definindo requisitos de segurança e segurança em processos de desenvolvimento e suporte

A.16 Gestão de incidentes de segurança da informação – controles para reportar eventos e fraquezas, definindo responsabilidades, procedimentos de resposta e coleta de evidências

Outra contribuição significativa dos padrões e regulamentações de segurança na produção de software teve início em 1991 com a publicação da norma ISO/IEC 9126. Posteriormente, esse modelo evoluiu para os aspectos do modelo de qualidade, externos, internos e de uso dos sistemas de informação computacionais por meio das normas ISO/IEC 9126-1, ISO/IEC 9126-2, ISO/IEC 9126-3 e ISO/IEC 9126-4.

A evolução das normas ISO/IEC 9126 se deu em 2005 com a família ISO/IEC 25000:2005 e revisada em 2014. Considerando os aspectos do modelo SQuaRE (Software product Quality Requirements and Evaluation) os aspectos internos, externos e de uso estão sendo revisados pelas ISO/IEC 25023 e ISO/IEC 25022, respectivamente. Isso demonstra claramente a preocupação com os elementos de segurança na produção de softwares como ativo de segurança fundamental para a operação das Instituições e Organizações.

Entretanto, observa-se que a produção de software remonta a um passado mais antigo e que as formas de se produzir foram evoluindo constantemente muito em função das novas necessidades de negócio e dos aspectos tecnológicos. Não obstante esses dois fatores, há que se levar em consideração o aspecto humano e o modelo mental evolutivo da sociedade. Nesse sentido, (BOHEM, 2006) estabelece uma relação na evolução da produção de software, por meio da Engenharia de Software nos séculos XX e XXI.

148

Para entender como esses dois processos evoluíram ao longo dos anos. Barry Boehm (BOHEM, 2006) faz uma revisão da evolução da Engenharia de Software nos séculos XX e XXI. Seu trabalho estabelece a visão de tese, antítese e síntese baseada em Hegel para explicar o fenômeno na evolução da Engenharia de Software. Nesse sentido, podemos entender a evolução da Engenharia de Software desde 1950 até o final dos anos 2000.

Na década de 1950 a tese predominante era de que a Engenharia de Software deveria ser encarada como a Engenharia de Hardware, isto porque o Hardware ocupava nesta época o papel principal na Ciência da Computação. Com base nesse pensamento, projetar software era um processo extremamente rígido e nada tolerante à falhas, o que é admissível no projeto de hardware, pois é inviável resolver um problema de projeto após a produção de um equipamento físico.

Nesse sentido, o primeiro processo de produção de software foi concebido para a criação do maior desafio computacional da época, o SAGE (Semi-Automated Ground Environment) um mecanismo de defesa para os EUA e Canadá. Basicamente um processo em cascata (modelo waterfall).

Após anos de desenvolvimento e a percepção clara que software não é igual a hardware, a antítese vigente em 1960 era enxergar o software como uma entidade maleável. As empresas começaram a adotar a técnica “codifica e conserta” (code and fix), pois a unidade de trabalho não necessitava de consertos para cada elemento produzido, bastava recompilar o produto original.

Entretanto, nem todas as empresas e produtores de software sucumbiriam a esse modelo. Algumas missões críticas, como por exemplo os projetos da NASA para Mercury, Gemini e Apollo foram lideradas pela IBM em um modelo de trabalho ainda com foco intenso no processo rígido de produção. Nesses sistemas o elevado nível de confiabilidade exigido impulsionou a indústria para a criação de modelos de produção de software.

A Engenharia de Software começava a se delinear impulsionada pelas conferências de 1968 e 1969 organizadas pelo Comitê de Ciência da

Organização do Tratado do Atlântico Norte (OTAN ou NATO¹³). Se

observarmos a missão da OTAN, podemos perceber claramente as questões de segurança da informação pautadas nos dois pilares base da Organização que são o político e o militar.

Na década de 70 houve uma síntese e uma antítese formando a ideia de que o formalismo e o processo clássico eram necessários. Surge a programação estruturada, a linguagem Pascal e muitos estudos como a psicologia da programação de computadores de (WEINBERG, 1971).

13

149 Já no final dos anos 70, as empresas estavam gastando mais em software do que em hardware. A pressa em codificar e fazer o atalho para a produção, menosprezando os requisitos e o projeto de software fizeram os custos com testes e manutenção disparar.

Os anos 80 foram marcados pela síntese de que a produtividade e a escalabilidade deveriam ser o foco na produção de software. Surgiram os métodos orientados a objeto, os modelos de maturidade e qualidade (como o

CMM14), as fabricas de software além das ferramentas CAD e linguagens 4GL.

Já nos anos 90 uma discussão global se estabeleceu: como resolver o Bug do milênio? Muitos sistemas então construídos não estavam preparados para lidar com as datas após 1999, pois simplesmente foram programados com dois dígitos para representar o ano. Sendo assim, as operações com data entenderiam “00” como 1900 e não como 2000. Imagine um cálculo de juros para quitação de dívidas.

Ao longo dos anos 90 havia necessidade de se correr contra o relógio na produção de software e uma abordagem ganhava força: o desenvolvimento concorrente ou iterativo. Outras eventos importantes da época foram a criação do Linux em 1991, o que desencadeou a força do movimento Open Source criado em 1985 com Richard Stallman pela Free Software Foundation e pelo W3C (World Wide Web Consortium) de Berners Lee em 1994. Os usuários passaram também a se preocupar mais com a usabilidade dos softwares do que apenas com as funcionalidades.

Os anos no início do novo milênio foram marcados pelo conceito de agilidade e valor agregado na produção de software. Com o advento da popularização da Internet, o fenômeno da globalização e o surgimento de grandes empresas como Google o mercado estava cada vez mais presente na produção de software. Em 2000, os membros da NASDAQ votaram para sua reestruturação e spin off resultando em uma companhia voltada para o lucro. Já em 2001 a NASDAQ foi o primeiro mercado de ações a atingir os padrões da ISO 9001.

Os métodos ágeis como ASD (Adaptive Software Development), Crystal, DSD (Dynamic Systems Development), XP (Extreme Programming) e SCRUM ganhavam a atenção de desenvolvedores no mundo. Em 11 de setembro de 2001, com o atentado às torres gêmeas o mundo deu ainda mais atenção ao tema Segurança.

A criticidade e dependabilidade ficaram notórias. Pessoas, sistemas e Organizações estavam totalmente dependentes de software para executar suas rotinas. Foi criado um grupo pela ACM (Association of Computing

14

150

Machinery) denominado SPUR (Security/Privacy, Usability, and Reliability). As questões ligadas a segurança tomavam participação de forma explícita.

Fazendo um paralelo entre as normas e modelos referentes à segurança da informação e a evolução da produção de software de acordo com o quadro 10.1 percebe-se uma lacuna entre esses dois temas. Apesar do tema Segurança da Informação remontar a antiguidade com métodos criptográficos para comunicação (a exemplo da Cifra de César no séc. I a.C) observa-se que as normas e modelos para Sistemas Computacionais evoluíram somente 3 décadas após os modelos de produção de software.

Quadro 10.1 Fatores de Qualidade e Segurança da Informação e Produção de Software

Década Qualidade e Segurança da Informação Produção de Software

2000

ISO/IEC 27001:2005 Valor agregado para o negócio Agilidade Segurança, Privacidade, Usabilidade e Confiabilidade ISO/IEC 9126-2:2003 ISO/IEC 9126-3:2003 ISO/IEC 9126-1 a 9126-4 ISO/IEC 17799 1990

Padrão Britânico (BSI) BS 7799 1995 Concorrência versus Processo Sequencial

Código de Prática para Gerenciamento de Segurança - 1992 ISO/IEC 9126 1980 Modelo SW-CMM Produtividade e Escalabilidade 1970 Formalismo 1960 Software artesanalmente

1950 Software como Hardware

Fonte: elaborado pelo autor

Reflexões

Pode-se entender portanto que os aspectos de segurança da informação , apesar de remontar a um passado distante no que se refere à criptografia, mecanismos de defesa militar, privacidade não estão diretamente associados com as práticas de engenharia de software. A evolução da engenharia de software também se deu por aspectos mercadológicos competitivos o que precisou de mecanismos ágeis de desenvolvimento rápido e fácil. Tal cenário impõe restrições de investimentos em segurança na área do desenvolvimento de aplicações.

151 14.3 O Perfil do Recurso Humano na Produção de Software e o

Tratamento das Questões de Segurança.

A produção de software não se dá exclusivamente por pessoas com capacitação formal em ciência da computação, sistemas de informação, processamento de dados, engenharia da computação e cursos afins. É comum presenciar pessoas com outras formações ou mesmo jovens sem ainda terem concluído o ensino superior nessa atividade.

Parte desse comportamento pode ser explicado pela atividade ser desenvolvida como um hobby ou mesmo pelas facilidades tecnológicas para criação de sites, blogs, aplicativos e até mesmo sistemas mais robustos por meio de geradores de código.

Entretanto, seja profissional formalmente capacitado ou não, o perfil do desenvolvedor remete às competências ligadas à criatividade, inovação, agilidade. Enfim, características que exploram novas formas de pensamento, novas fronteiras tecnológicas, novo desafios. Esse tipo de perfil criador tende a ignorar ou mesmo dar menos atenção aos riscos inerentes à segurança da informação.

Portanto, aliado ao perfil do desenvolvedor e uma certa facilidade na criação de aplicações as questões de segurança ficam de certa forma comprometidas no processo de criação de software. Existem várias brechas para ataques, invasões e roubos de informação.

Parte desse fenômeno pode ser explicado pelo comportamento dos usuários em relação à segurança da informação. Após a revelação do caso de invasões à privacidade de pessoas, incluindo autoridades globais, por Edward Snowden, os usuários em um primeiro momento tiveram comportamento indicando interesse nesse assunto. Entretanto, em pesquisa recente esse interesse caiu abaixo dos níveis originais (PREIBUSCH, 2015).

Há também, para os profissionais da área, a questão da formação curricular. Um exame aprofundado nos currículos sugeridos pela ACM para a Ciência da Computação nos mostra que em 2001 o curriculum oficial mencionava a segurança e criptografia apenas no corpo de conhecimento de sistemas operacionais e sistemas centrados em redes como conteúdo optativo (ACM, 2001).

Posteriormente em 2008, a ACM já traz no seu curriculum a questão de segurança de maneira mais enfática. Pela primeira vez, explica-se no documento que de modo mais significativo é importante a preocupação em escrever software seguro. (ACM, 2008).

152

Em 2013 a ACM promoveu uma pesquisa para formação da sua base curricular pautada nos relatórios de 2001 e 2008 onde participaram 1500 departamentos de ciência da computação. Dois tópicos foram aclamados como de extrema importância para contemplar o novo currículo como áreas de conhecimento: Computação Paralela e Distribuída e Segurança (ACM, 2013).

Até então, esses tópicos figuravam em outras áreas do conhecimento como redes de computadores e sistemas operacionais. Foi criada então uma área do conhecimento denominada IAS (Information Assurance and Secuity).

Percebe-se portanto que também na formação dos profissionais o tema segurança da informação vem crescendo em importância, mas ainda é algo recente. Obviamente, mudanças curriculares levam tempo a serem absorvidas pelas Instituições de ensino, professores e alunos pela própria natureza da duração destes cursos. Logo, não é difícil de perceber que o reflexo prático deste conhecimento demore um pouco a chegar nos produtos de software de maneira mais ampla.

Reflexões

O tema segurança da informação sob a perspectiva da formação do conhecimento em Ciência da Computação, área fundamental para a criação de sistemas computacionais tangencia o conhecimento básico. Como pôde ser observado, nas grades de formação o assunto só teve a importância à partir desta década.

Os usuários não possuem a preocupação com o tema da maneira como deveriam e portanto, a formação dos requisitos de usuário e por consequência dos requisitos de software minimizam a importância do tema na construção dos softwares. Fato que pode explicar a quantidade de vulnerabilidades das aplicações legadas.