126_artigo

Uma proposta para a implantação de um ambiente de desenvolvimento desoftware com segurança

ANDRÉ LUIZ TEIXEIRA DOS SANTOS 1

MILTON FAGUNDES VALPASSOS 2

MARÇAL DE LIMA HOKAMA3

Resumo. Este artigo tem como finalidade orientar na implantação de um ambiente dedesenvolvimento seguro, utilizando técnicas que visam minimizar falhas que possam servir comobrechas que facilitem acessos indevidos. Tais acessos podem causar alguns transtornos, tais como:obtenção de informações sigilosas, alteração de registros confidenciais e até mesmo a destruição deuma base de dados. Abordando as causas e conseqüências, assim como possíveis soluções, tendocomo base a ISO 15.408, que é originária do Common Criteria for Information Tecnology SecurityEvaluation. Com isso, resultando, quando utilizadas tais técnicas, em uma aplicação muito maisconfiável e segura.

Palavras chaves:. Segurança, Aplicação, Desenvolvimento, Invasão e Software1

Summary. This article aims to direct in the implantation of a secure software by using techniquesthat serve the purpose of minimizing faukts that can be used as openings, whose inapropriete accessescan be facilitated. Such accesses may cause prublems, such as secret: secret information access,confidential recording alteration and even the destruction of a database. It deals with some causes andconsequeces as well as some possible solutions based upon the ISO 15.408, whose origin comes fromthen Common Criteria for Information Tecnology Security Evaluation.Therefore, whenever suchtechiniques are used, they result in a much more reliable and secure softwere.

Key-Words:. Security , Aplication, Development, Invasion, Software

1EsAEx – Escola de Administração do Exército, Rua Território do Amapá, nº 455, Pituba, Salvador – BA, [email protected], [email protected], [email protected],br3

1. IntroduçãoMuito se fala na segurança de sistemas, masgeralmente o infoque é dado na segurançada rede, nos possíveis ataques de hackers,ou seja, uma visão totalmente externa,esquecendo que muitas vezes oferecemos asvulnerabilidades que tanto desejam ospossíveis invasores. Estas ocorremgeralmente durante o desenvolvimento desoftware.

As principais falhas tem como origem nanão observância das vulnerabilidadesexistentes no ambiente de desenvolvimento.

Este artigo tem como finalidade auxiliarna elaboração de uma política dedesenvolvimento segura, baseado na norma

ISO / IEC 15.408 (Common Criteria forInformation Technology Security Evalution).Será abordado também algumas falhas naprogramação, mostrando suas conseqüênciase possíveis soluções.

A norma ISO / IEC 15.408 (CommonCriteria for Information TechnologySecurity Evalution), na maioria das vezeschamado apenas de Cammom Criteria, emportuguês (Critério comum para avaliaçãode segurança de tecnologia da informação),tem como objetivo fornecer um conjunto decritérios fixos que permitem especificar asegurança de uma aplicação de forma nãoambígua a partir de características doambiente da aplicação, e definir formas degarantir a segurança da aplicação para o

cliente final (ALBUQUERQUE, RIBEIRO –2002).

O presente texto visa expor algumastécnicas relevantes no desenvolvimento deuma aplicação. Tais como o levantamentodo ambiente de desenvolvimento, a proteçãodos dados dos usuários e das funções desegurança e a garantia da segurança daaplicação.

2. Política para desenvolvimento desoftware

Em desenvolvimento de softwarenormalmente a segurança só é consideradanas fases finais dos projetos, quando éconsiderada, assim resultando numa série deadaptações nos sistemas. Incluindo odesenvolvimento de software na política desegurança, reduz consideravelmente oretrabalho.

As normas pertinentes aodesenvolvimento de sistemas contemplam asseguintes funções:

Processo de desenvolvimento Testes Documentação Controle de revisão e configuração Uso de terceiros Propriedade intelectual

No processo de desenvolvimento, asnormas devem garantir que a segurança seráconsiderada durante todo o projeto:especificação, programação e homologação.As políticas devem identificar de quem sãoas responsabilidades por promover odesenvolvimento seguro e por colocar osistema em produção. Os desenvolvedoresdevem conhecer todas as políticas desegurança, padrões, procedimentos e outrasconvenções de desenvolvimento, tais como:padrão de criação de nomes para os objetosde um sistema (banco de dados, arquivos,variáveis, etc.); senhas não podem sertransmitidas pela rede sem que sejamcriptografadas e nem armazenadas emarquivos textos e em dispositivos comacesso livre; e etc.

As seguintes regras devem serobservadas: obrigar que os sistemas sejamespecificados, e esta especificaçãocontemple os requisitos pertinentes àsegurança e privacidade dos dados; prever avalidação da entrada de dados nos GUI dasaplicações; prever a checagem dos dadosnos processos de transmissão; e o sistemanão poderá ter "portas dos fundos" enenhum outro mecanismo de interação quepermita a entrada ou saída não segura dedados.

Quanto aos testes, deve ser criada umapolítica que garanta a segurança de todos osdados utilizados, uma vez que estes dadosdevem ser extraídos do ambiente deprodução, para que os testes possam serrealistas. As rotinas de teste devem abordaro aspecto de segurança, de modo a avaliareventuais vulnerabilidades nos sistemas edevem ser feitas exaustivamente. Parafacilitar as rotinas de teste, sempre quepossível, deve haver reutilização de códigoentre projetos. Pois estes códigosreutilizados, por já fazerem parte de umoutro projeto, já sofreram uma boa etapa detestes.

A documentação não é de cunhoobrigatório para a segurança. Mas permitirá,no futuro, que outros programadores possamentender com mais facilidade como osmecanismos de segurança foramimplantados, facilitando assim acontinuidade e melhora da política desegurança.

Com o controle de configuração osadministradores podem saber se a segurançafoi violada através da instalação de algumprograma não autorizado. Já que estecontrole permite saber o que deveria estarinstalado nos equipamentos e na rede.

O controle de revisão e configuraçãopermitirá rastrear as mudanças nos sistemas.A política de segurança deve obrigar quetodas as solicitações de modificações nossistemas sejam formalizadas, respeitem umaalça de aprovação e não violem as regras desegurança. (MARTINS, 2003)

É comum que os sistemas tenham bugs,fazendo necessária a instalação de patchesque corrijam este problema. Contudo, ospatches podem criar vulnerabilidades nossistemas. Por isto, é de suma importânciaque a política de segurança exija que ospatches sejam avaliados, andes de entraremem produção, num ambiente dehomologação. Por vezes se faz necessária adesinstalação de um software ou patch,devido a um bug ou incompatibilidade comoutro sistema. As políticas que tratam docontrole de configuração devem requererque um sistema ou patch seja colocado emprodução somente se houver uma rotina paradesinstalação.

O uso de terceiros no desenvolvimentode sistemas é uma fonte potencial deproblemas com a segurança. Para efeito deminimizar ao máximo tais problemas, asregras e os procedimentos, que dizemrespeito à segurança, devem ser incluídos nocontrato com o terceiro, sendo este obrigadoa respeitar todas as políticas de segurançaassociadas ao desenvolvimento de software.

No caso de sistemas adquiridos deterceiros, devem ser incluídas nos contratosduas cláusulas de total importância:

1ª - O terceiro não pode vender ouredistribuir os programas nem adocumentação desenvolvidos paraempresa. Para haver exceções aesta regra, deve existir umaaprovação formal da diretoria.

2ª O terceiro deve manter osprogramas fontes e a documentaçãoem custódia e a empresa poderá teracesso aos mesmos, caso o terceirovenha a encerrar suas operações.

Independentemente de quem tenha feito odesenvolvimento, o resultado final épropriedade da empresa. O sistema contémos processos de negócio e outrasinformações sobre como a organizaçãoopera. Estes programas devem serconsiderados como um bem da empresa.Deve haver uma política de propriedadeintelectual, compatível com a lei, que

garanta a propriedade dos sistemasdesenvolvidos.

3. Avaliação do ambiente dedesenvolvimento e estratégias desegurançaNão é possível gerar uma aplicação seguraem um ambiente não seguro.

O primeiro passo para o desenvolvimentode uma aplicação segura, será olevantamento e avaliação do ambiente noqual esta aplicação será implantada.Verifica-se as ameaças, os pontos críticos,os ativos valiosos, legislações esalvaguardas já existentes no ambiente(ALBUQUERQUE, RIBEIRO – 2002).

Devemos implantar as defesasnecessárias e algumas requeridas pelalegislação ou pela política de segurança daempresa.

Não podemos esquecer dos sistemas deapoio (sistemas operacionais, banco dedados) que possuem várias características desegurança implementadas. Estes sistemaspodem se transformar em armadilhas, seusadas pura e simplesmente, é claro quedevem ser usadas, já que não devemosreinventar o inventado, mas é preciso saberquando e o que usar. Usá-las somenteporque estas existem, sem haver umanecessidade detectada, pode trazer algunsprejuízos para o desempenho eprincipalmente brechas de segurança naaplicação. O correto é levantar o querealmente precisamos, para então decidir-mos como atender as necessidades, sejaatravés dos sistemas de apoio ouimplementando um novo mecanismo desegurança.

Quatro aspectos devem ser consideradosdurante o levantamento:

Política de segurança (diretrizes,normas, legislações);

Ameaças (ativos, mecanismos deataque e agentes) ;

Objetivos de segurança(necessidades do usuárioformalizada); e

Premissas (considerações sobre ouso do sistema e de seu ambiente)

Devemos primeiro levantar a política desegurança e as ameaças, para entãofornecermos subsídio à definição dosobjetivos de segurança. Assim, após adefinição destes, levanta-se o que já éfornecido pelo ambiente, ou seja, ossistemas de apoio.

3.1. Levantamento da política desegurançaA maioria das empresas possui normasrelativas a segurança, privacidade,confidencialidade e diversos outros aspectosde segurança. Antes de tudo, estas são asnecessidades que precisam ser levantadas,uma vez que são requisitos do sistema quenão podemos alterar (ALBUQUERQUE,RIBEIRO – 2002).

O trabalho pode ser facilitado se aempresa cliente já tiver uma política desegurança definida (ALBUQUERQUE,RIBEIRO – 2002).

O retorno deste levantamento poderá seruma lista vazia, quando não existir umapolítica de segurança definida ou umalegislação aplicável, caso contrário retornaráuma lista com identificadores quereferenciam os aspectos de segurança, ositens que indicam os requisitos de segurançae a descrição desses itens. Esta lista serviráde base para a definição dos objetivos desegurança.

3.2. Levantamento das ameaçasEm virtude da evolução da tecnologia,torna-se impossível levantarmos todas aspossibilidades de ameaças. Por isso nãodevemos querer que uma aplicação tenhadefesa para todos os tipos de ameaças. Issopoderá torná-lo falho ou pesado demais.Uma aplicação deverá ter defesas para umgrande número de ameaças, pois esta estarácom certeza protegida contra muitas outrasque não tenham sido levantadas, pois amaioria das ameaças tendem a utilizar osmesmos princípios para realizarem seusataques.

As ameaças quase sempre possuem asmesmas características: um ativo com valor(tabelas com números de cartões decréditos), um mecanismo de ataque(apoderar-se da conta de um administrador),e um agente (um hacker). EntãoAMEAÇA=AGENTE X MECANISMO XATIVOS. Faltando um desses itens nãohaverá ameaças (ALBUQUERQUE, RIBEIRO –2002).

3.2. 1 Os agentesDe quem se defender? Esta é a perguntaque constantemente fazemos, e a respostageralmente é: dos “hackers”. Não é apenasdeles que devemos nos proteger, pois aspessoas que estão envolvidas com o sistema,também podem ser grandes ameaças.

Os agentes são classificados de acordocom algumas categorias:

Acesso ao sistemaQuanto maior o acesso, mais fácil seráde realizar o ataque. Veja algumascategorias de ataque. Tabela 1 (videanexo)

Conhecimento do sistemaQuanto maior o conhecimento que setiver sobre o sistema, mais fácil seráde realizar o ataque. Tabela 2 (videanexo).

Capacidade do agenteÉ claro que um hacker é um agenteextremamente perigoso. Porém umusuário comum também pode sermuito perigoso se tiver um amploacesso e conhecimento do sistema.Tabela 3 (vide anexo).

Motivação do agenteEsta característica não deve serconsiderada diretamente em suaespecificação de segurança, poispodem ser inúmeras. Porém poderãotornar-se uma informação importantefuturamente. Tabela 4 (vide anexo).

Classificação dos agentes

Na especificação de segurança dosistema, utilizamos essa informaçãopara traçar as estratégias a cadaameaça. Tabela 5 (vide anexo).

3.2. 2 Os MecanismosExistem diversos mecanismos conhecidospara explorar a vulnerabilidade de umsistema, e muitos irão surgir(ALBUQUERQUE, RIBEIRO – 2002).

Os mecanismos podem ser de alto nível(apoderar de conta de administrador) ou denível operacional ( usar uma aplicação “X”).Devemos nos ater as de alto nível, pois oestudo dos mecanismos de níveloperacional, se tornará pouco produtivo, emfunção da dinâmica do surgimento de novasaplicações.

Destacamos alguns mecanismos naTabela 6 (vide Anexo).

3.2. 3 Os AtivosSão todas as informações com algumaimportância em seu sistema, que se torneminteresse dos agentes.

Veja alguns ativos e sua relevância aosagentes na Tabela 7 (vide anexo).

Existem vários aspectos em um ativo, deinteresse de um atacante:

ConfidencialidadeSe um agente consegue ler umainformação já obteve ganho, pois sóo conhecimento do conteúdo destainformação representa uma perdapara o sistema.

IntegridadePara sucesso de um agente, eleprecisa alterar ou remover um dadodo sistema.

DisponibilidadeDo que adianta todos os recursospossíveis, se estes não tiveremdisponíveis quando necessário.

AutenticidadeÉ a garantia de que o usuário érealmente quem diz ser.

PrivacidadeQuando alguém consegue monitoraras ações de um usuário, quedeveriam ser privadas.

3.2. 4 Tabela de ameaçasÉ constituída a partir da ligação entre osativos e os agentes, constantes na tabela deativos, definidos quais mecanismos osagentes deveriam utilizar para atingirdeterminado ativo. Devemos levar em contaa capacidade do agente, seu conhecimentodo sistema, o acesso que ele possui, além desua motivação, para constatar se esterealmente tem como utilizar o mecanismopressuposto (Tabela 8 - Anexo).

3.3 Objetivos de segurançaLevantar as ameaças e necessidades legais,mas estas não oferecem todos os objetivosde segurança, sendo alguns de exclusividadedo cliente.

As listas de objetivos de segurançapreviamente acertadas com o cliente, são abase para toda a segurança a ser implantadano sistema.

3.4 Premissas de segurançaSão itens a serem considerados na segurançaexterna do sistema, utilizados para atenderdiretamente algum objetivo de segurança oualterar sua necessidade (ALBUQUERQUE,RIBEIRO – 2002).

A ISO 15.408, estabelece que aspremissas apenas devem ser usadas paraindicar as condições prévias do ambiente dosistema. Sendo posteriormente definido osatributos extra –sistema , para indicaraspectos de segurança já atendido peloambiente (ALBUQUERQUE, RIBEIRO – 2002).

Basicamente as premissas são de doistipos: as de uso do sistema e as do ambiente.Como exemplo das premissas de sistema,podemos definir que o sistema somente seráusado por um administrador treinado, assimeliminando os objetivos de segurança quetinha como ameaça o desconhecimento dosistema.

As premissas do ambiente, diz respeitoao ambiente esperado pelo sistema. Porexemplo “ os computadores nos quais irãorodar o sistema, não terão drive dedisquete”, assim eliminamos a possibilidadede se usar discos de inicialização, pois estedisco poderia burlar as funções de segurançado sistema operacional (ALBUQUERQUE,RIBEIRO – 2002).

Essas premissas devem ser aprovadaspelo cliente, pois afetarão diretamente aoperação do sistema (ALBUQUERQUE,RIBEIRO – 2002).

As premissas irão dar origem a duastabelas distintas, onde a primeira listarátodas as premissas com um identificador, asegunda confronta estas com os objetivos desegurança.

Estas listas devem definir claramente aspremissas que foram adotadas e comoafetam os objetivos de segurança Tabelas 9e 10 ( vide anexo).

4. Proteção dos dadosA função básica da proteção de dados e docontrole de acesso é de garantir aconfidencialidade e disponibilidade dasinformações armazenadas (ALBUQUERQUE,RIBEIRO – 2002).

Além do controle de acessos, outroscontroles são usados para garantir a proteçãodos dados, tais como: controle de fluxo deinformação, canais de comunicação,informação residual.

A função de controle de acesso, define oque determinado usuário pode acessar oualterar.

Devemos atentar para alguns problemaspráticos no controle de acesso. Como porexemplo garantir que nenhum dos inúmerosmeios de acesso a informação, viole ocontrole de acesso estabelecido.

Esta questão pode facilmente serresolvida, aproximando a proteção e ainformação. Ou seja o controle de acesso aessas informações fica a cargo do banco dedados.

4.1 Política de controle de acesso

É a primeira linha de defesa da aplicação.Sua função primordial é ditada pelanecessidade do usuário. Desta forma a fasede especificação do sistema é o melhormomento para definição da política deacesso, sendo realizada em conjunto com ousuário (ALBUQUERQUE, RIBEIRO – 2002).

Quase todos os sistemas necessita dealgum mecanismo de controle de acesso.

De acordo com a ISO 15.408, umatributo de segurança, só deve ser usadocom o objetivo de atender a determinadoobjetivo de segurança (ALBUQUERQUE,RIBEIRO – 2002).

Geralmente o controle de acesso se ligaaos objetivos de segurança nas seguintesformas:

Garantindo que os usuários não vejamou alterem determinadas informações;

Facilitar o uso pelo usuário final; Minimizar a necessidade demanutenção do sistema devido erro dousuário final.

Na maioria das vezes não é necessárioassociar um objetivo de segurança a algumaameaça, bastando considerar simplesmenteuma premissa do sistema, como porexemplo: “realizar o controle de acesso dainformação, conforme a política desegurança da empresa”.

4.2 Política de controle de fluxo deinformaçãoExistem situações onde uma aplicação tratauma determinada informação e a repassa aoutro sistema ou meio de armazenamento.Existindo a necessidade da definição docontrole de fluxo informacional.

Devemos também nos preocupar com osfluxos ilícitos de informação, mesmohavendo o controle de acesso e do fluxo deinformação, um usuário pode abrir umaconexão direta ao banco de dados através deum acesso oculto, contornando o controle deacesso e fluxo de informação, ou até mesmoroubar o HD.

Na tentativa de eliminarmos estes fluxosilícitos, nos deparamos com dois problemas:

Identificar todos os canais para acessoa informação;

Identificar as formas de impedir,controlar e monitorar tais acessos.

O primeiro pode ser resolvido através dolevantamento de todos os possíveis canaisde acesso a uma informação.

O segundo problema, podemos limitá-losatravés da autenticação de dados,conseguindo detectar alterações nestesdados. Outra alternativa é diminuir o ciclode vida da informação, com isso limitandoos fluxos ilícitos. Limitar os canais deentrada do sistema, removendo placa derede e dispositivos de disco flexível, massem dúvida alguma a melhor alternativapara evitar acessos ilícitos é através do usoda criptografia.

Geralmente o controle de fluxos ilícitosnão são preocupação da maioria dossistema, porém em arquiteturas em camadas,seu uso pode ser de crucial importância.

Este controle deverá ser usado aosseguintes objetivos de segurança.

O acesso do Banco de dados, porqualquer caminho diferente doservidor da aplicação.

Os clientes deverão apenas aceitar asmensagens vindas do servidoresinternos.

É bastante difícil controlar fluxos deinformação de um sistema. Por isso éinteressante o uso do controle de fluxos porsubconjunto. Não há a necessidade decontrolar tudo, pois alguns fluxos não sãotão importantes assim, sendo mais prudentecontrolar por completo os fluxosimportantes do que vários fluxos de formaincompleta.

4.3 Fluxo de Dados externoExistem informações que precisam transitarou serem armazenadas fora do escopo daaplicação.

Na importação dos dados externos énecessário definir os atributos de segurança,seja em sua importação ou criação no

sistema, pois geralmente estas informaçõesnão possuem atributos de segurança.

As informações quando definidas comcontroles por níveis, deverão possuir o níveligual ou menor de confidencialidade donível do usuário que gerou ou importou.

Quando o controle de acesso fordiscriminado, a informação herdará osdireitos de acesso de sua classe.

Todas as entradas devem obedecer apolítica de segurança, pois de nada vale se aentrada de dados principal seguir a risca estapolítica de segurança, se existir outras quenão siga esta política.

Na exportação de dados, apenas o usuárioque ver o dado pode exportá-lo, se este sairsem atributos de segurança, fica o usuárioresponsável pela segurança do dadoexportado, uma vez que o sistema não maistem controle sobre ele.

Podemos tanto exportar como importarum dado com seus atributos de segurança,um exemplo disso é o e-mail .

Quando consideramos uma transação dedados mantendo seus atributos de segurança,precisamos proteger a confidencialidade,integridade e autenticidade da informação.

A confidencialidade pode ser garantidapor criptografia, a integridade por um hashda informação e sua autenticidade, atravésde assinaturas eletrônicas (ALBUQUERQUE,RIBEIRO – 2002).

Sempre que houver uma política decontrole de acesso e de controle de fluxo, osatributos de importação e exportaçãodeverão estar sem atributos de segurança,uma vez que estes precisam nascer com odado, por isso devem serem removidos nomomento de sua exportação(ALBUQUERQUE, RIBEIRO – 2002).

Ao exportar um dado para umarmazenamento ou linha de comunicaçãofora de nosso controle, e importar de umoutro ponto, é preciso usar a autenticaçãodos dados, proteção de confidencialidade eintegridade, importação e exportação comatributos de segurança. Estas medidas visamprimeiramente garantir ao sistema, acapacidade de gerar cópias de segurança e

restaurá-la, mantendo sua confidencialidadee integridade (ALBUQUERQUE, RIBEIRO –2002). Permite também ao sistema ser capazde se comunicar com qualquer outro sistemacom segurança de suas informações.

Segundo a ISO 15.408, a importação,exportação, autenticidade e proteção deconfidencialidade e integridade, sãoatributos separados (ALBUQUERQUE,RIBEIRO – 2002), uma vez que podemosutilizar um ou outro atributo sem anecessidade de uso em conjunto com osoutros atributos.

É importante lembrar que usar apenascriptografia, não garante a confidencialidadeda informação, pois mesmo que esta tenhasido implementada com algoritmo forte, suachave pode ser quebrada se esta estiverguardada em local de fácil acesso. Essaconfidencialidade é conseguida com ainclusão da autenticação através deassinaturas eletrônicas.

4.4 Informação residualUm arquivo apagado pode em algumassituações ser recuperado. O mesmoacontecendo com blocos de memóriasliberados.

Uma informação depois de descartada,esta continua lá, seja em memória, disco,cache de rede. Se caracterizando eminformação residual, o problema está napossibilidade destas informações seremrecuperadas por invasores.

Podemos resolver estes problemasescrevendo zeros sobre o bloco ou arquivodescartado, ou ainda zerar a cache depois deeliminar a informação.

É problema identificar onde estáocorrendo informação residual, a melhoralternativa é tratar o fluxo de informaçõesconfidenciais no sistema. O simples tráfegoda informação até a máquina do usuáriopode gerar problemas de informaçãoresidual e vazamento por intercepção narede. Para evitar isso procura-se trazer dobanco de dados para a estação local somenteas informações solicitada e que tenhaacesso. Outra situação é o caso de um

sistema de transação eletrônica que deixainformações temporárias em arquivos, taiscomo número de cartão de crédito.

4.5 Manutenção de integridade de dadosinternosA integridade dos dados é um dos aspectosprincipais da segurança de um sistema(ALBUQUERQUE, RIBEIRO – 2002).

A perda de integridade pode ocorrer porduas causas:

Problema de hardware ou influênciamagnética;

Perda de atomicidade de transações.No primeiro caso pouco pode ser feito no

desenvolvimento de sistema, limitando-secomo medida a detecção e aviso doproblema.

Quanto a perda de atomicidade detransações, devemos implementar naaplicação rotina capaz de desfazer o que foirealizado para uma determinada transaçãono momento que uma operação gerar umerro. Com isso o sistema voltará a condiçãoanterior ao início da transação, mantendo aintegridade das informações.

Lembramos que hoje, nos sistemas maismodernos, estas ações ficam por conta dopróprio SGBD (Sistema Gerenciador deBanco de Dados).

5. AuditoriaE um conjunto de funções que gravam emantém uma trilha de ações realizadas nosistema, permitindo a análise e visualizaçãodestas ações, assim a possibilidade deidentificar o que ou quem causou algumproblema de segurança.

Simples de ser implementada, porém dedifícil de projetada em um sistema, emfunção da diversidade de parâmetros quedevem ser avaliados. Por exemplo quaisações devem ser registradas? Terei queregistrar tudo? E se registrar, terei problemade espaço? E muito mais.

Devemos relevar o motivo pelo qualqueremos auditoria, desconsiderando

objetivos externos à segurança do sistema.Os objetivos da auditoria podem ser:

Segunda linha de proteçãoExiste um responsável para umeventual problema, mesmo que osistema já tenha um evento para evitá-lo.

Melhoria do sistemaVisa medir a funcionalidade dosistema para eventuais melhorias.

Aumento do escopoVisa identificar ações, mesmo queválidas, possam causar prejuízos ouexponha ativos de formadesnecessárias.

PrevençãoTer conhecimento de tentativas deinvasão ou ameaças que tentemfraudar os mecanismos de proteção dosistema.

PolíticaAtendimento a política de segurança.

5.1 Geração dos dados de auditoriaRegistrar um grande número de eventos,torna a auditoria completa, porém torna osistema mais lento e com necessidade demaior armazenamento, além de tornar arevisão das trilhas impossível.

Devemos sempre levar em conta oobjetivo de nosso mecanismo de auditoria.A ISO 15.408,sugere vários eventos deauditoria de cada mecanismo de proteção ouatributos de segurança implementado nosistema (ALBUQUERQUE, RIBEIRO – 2002).Devemos, ainda atentarmos apenas paraaqueles que dizem respeito aos pontos maiscríticos do sistema.

É importante que façamos ligação com asameaças, para atender aos demais objetivosde auditoria. Para atingirmos os objetivosde aumento de escopo de proteção eprevenção de ataques, é necessárioconsiderarmos os seguintes critérios:

Principais mecanismos utilizadospelas ameaças ao sistema;

Ativos mais valiosos, Agentes mais capacitados; Itens definidos na política desegurança

Todo sistema que exige alto nível desegurança, principalmente no controle deacesso, precisa de auditoria. O desempenhodo sistema precisa ser acompanhado, paraque falhas sejam levantadas assim comidentificar os usuários maliciosos.

Por fim, é importante salientar que, umsistema de auditoria é caro em suaimplantação e diminui o desempenho dosistema (ALBUQUERQUE, RIBEIRO – 2002).

5.2 Análise automática da trilhaComo já vimos o objetivo da auditoria édetectar as invasões no sistema, por isso éimprescindível que a trilha de auditoria sejarevisada periodicamente.

A revisão manual da trilha de auditoria éuma tarefa tediosa e bastante vulnerável aerros, uma vez que a maioria dos eventossão irrelevantes.

A automação da auditoria é altamentedesejável, porém em função de sua altacomplexidade de implementação, somentedeverá ocorrer se for realmente necessária.Estes mecanismos podem ser acionadosquando:

Um evento de auditoria com afinalidade de proteção de escopo, forexecutado;

Um conjunto de evento, mesmo queinofensivos, indicar tentativa deviolação do sistema.

Evento de monitoração de quebra docontrole de acesso ocorrer.

Após a identificação de qualquerocorrência, o sistema se manifesta dediversas formas, como por exemplo:

Cria um registro em tabela desituações suspeitas;

Mensagens ao administrador; Shutdown no sistema.

5.3 Armazenamento da trilha deauditoriaO armazenamento de trilhas, tendem acausar alguns problemas, como:

A trilha não pode ser alterada porusuário comum(senão este poderiaapagar todos os registro que oincriminasse);

As trilhas precisam estar integras,mesmo em caso de ataque ou queda dosistema

Falta de espaço para armazenamentodas trilha.

Fica claro que deve ser preocupaçãoconstante do administrador de banco dedados, quanto a exaustão das trilhas.

Existem algumas alternativas como porexemplo, enviar automaticamente as trilhasmais antigas para mídia de armazenamentomaior e de menor custo, porém deve existira preocupação com a disponibilidade destasinformações.

Deve-se também definir por quantotempo estas informações devem estardisponíveis.

Não podemos esquecer que algunssistemas operacionais, já possuemmecanismos de armazenamento de trilhas,portando devemos evitar a criação demecanismos já existentes, e que realizam asua função com eficiência.

6. AutoproteçãoGeralmente os sistemas de segurança falhamna segurança de suas funções de segurança.Desta forma se estas funções estiverem forade ação os dados dos usuários estarãodesprotegidos.

As funções de segurança do sistemapodem ser atacadas em três pontos:

Dados e atributos de segurança; Implementação das funções desegurança;

Camada subjacente.

6.1 Dados e atributos de segurança

No momento que se perde o controle sobreos dados e atributos de segurança, asfunções de segurança perdem sua utilidade.

Os mecanismos para proteção de dadosde segurança, são complementares ao dosdados do usuário, ou seja, os mecanismos desegurança de dados dos usuários ( controlede acesso, controle do fluxo de informação,importação e exportação de dados, e outrosjá vistos neste artigo), também se aplicamaos de segurança, devendo sercomplementados pelos seguintesmecanismos:

Exportação de dados de segurançaDevemos prover mecanismos maisrigorosos para garantia da integridade,confidencialidade e disponibilidadedas informações de segurançaexportada (ALBUQUERQUE, RIBEIRO –2002).

Transferência interna de dadosDeve-se criar critérios rígidos queregem a transferência interna dedados.

Capacidade de recuperaçãoO sistema deve ser capaz de retornar aum estado seguro mesmo após umafalha ou ações externas

Sincronismo de estado da aplicaçãoEm aplicações distribuídas, éimportante gerar mecanismos degarantia de recebimento deinformação, mantendo todo o sistemaconsistente (ALBUQUERQUE, RIBEIRO– 2002).

Consistência de dados replicadosdentro da aplicaçãoOcorre quando alguns atributos desegurança são mantidos replicados nosclientes por motivo de desempenho oupara garantir a segurança quando osistema estiver off-line(ALBUQUERQUE, RIBEIRO – 2002).

Consistência de dados com funçõesexternas de segurançaNa maioria das vezes, os sistemas desegurança são compostos por códigosdo sistema e do sistema operacional,

sendo comum a troca de informaçãoentre o sistema desenvolvido e osistema operacional. Cabe lembrar queatributos de segurança fora do padrão,também pode se configurar como umatentativa de invasão pelo sistemaoperacional. Por isso é convenienteque o sistema deva tratar como erro,todo atributo externo que ele nãoconsiga interpretar (ALBUQUERQUE,RIBEIRO – 2002).

6.2 Proteção das funções de segurança daaplicaçãoÉ de vital importância a proteção daaplicação, uma vez que dependendo dosistema operacional usado e a forma deinstalação, pode haver alterações indevidasno código executável dos programas

Os sistemas seguros devem possuir ummecanismo de garantia de integridade dosistema, onde este faça verificações, seja nainicialização ou em intervalos periódicos,para garantir que nenhuma alteração tenhaocorrido. Isso pode ser feito através de umaverificação de CRC, ou utilizandoredundância de códigos (ALBUQUERQUE,RIBEIRO – 2002).

Deve existir também a preocupação coma parte física, já que o agente pode abrir ogabinete e trocar o HD, e reiniciar osistema, burlando todo mecanismo desegurança.

Muitas vulnerabilidades surgem porestouro de área de armazenamento, para issotemos como solução a separação dedomínios. Existem algumas arquiteturas quepermitem, a separação de áreas de dados dasáreas de código, assim resguardando asegunda.

A separação de domínio pode ser feitatambém na forma de armazenamentoexterno, com controles adicionais.

Outro aspecto de grande relevância, é averificação de integridade dos canais deacesso ao sistema.

6.3 Proteção contra falhas da camadasubjacente

É muito fácil fraudar um sistema, se a base aqual ele roda está comprometida.

Devemos minimizar ao máximo apossibilidade de se contornar o processonormal de inicialização, ou seja impedir oboot pelo drive A: ou substituição do HD,execução por terminais remoto entre outros.

7. PrivacidadeA privacidade passou a ser um requisitomuito importante após o surgimento daInternet.

Ela pode existir de diversas formas,conforme a necessidade da política desegurança ou da privacidade do sistema(ALBUQUERQUE, RIBEIRO – 2002):

InvisibilidadeO sistema garante a um usuário que osdemais tomem conhecimento de seuacesso.

Não-rastreadoO usuário não é identificado nosistema, nem seus passos monitorados,porém pode ser responsabilizado porseus atos, quando usado em conjuntocom o pseudônimo.

PseudônimoMuito utilizado quando há anecessidade de responsabilização dousuário e a privacidade ao mesmotempo (ALBUQUERQUE, RIBEIRO –2002). O usuário é identificado eautenticado pelo sistema, mas sendoreferenciado por um pseudônimo paracada ação realizada.

A ligação do usuário com seuspseudônimos, somente ocorrerá emsituações especiais.

AnonimatoNão existe identificação nenhuma dousuário.

Por fim a privacidade surge porinfluência da política preestabelecida, deuma solicitação do usuário ou até dalegislação, além de ameaças que exigemcerto grau de privacidade (ALBUQUERQUE,RIBEIRO – 2002), pois uma vez um usuário

tenha seus passos rastreados por outros, ficafácil obter informações sobre ele.

8. Gerenciamento da segurançaNa implementação de uma aplicação segura,torna necessária a existência de funções einterfaces que controlem seus atributos edados (ALBUQUERQUE, RIBEIRO – 2002).

O gerenciamento de segurança, visadefinir os usuários, dividindo em grupos oupapéis, cada um com seus direitos definidos.

O sistema deve ser capaz de identificarcada usuário em cada situação,relacionando-o a seu grupo, e definindo seeste terá ou não os direitos reservados a seugrupo.

O gerenciamento ainda deve ser capaz derevogar e expirar atributos de segurança,sendo uma questão de suma importância,como exemplo se o sistema encontra-se sobameaça através do uso indevido de umaconta, esta deve ser imediatamenterevogada, ou seja ter seus direitostotalmente bloqueados. A revogação dedireitos, pode ocorrer de várias formas: Napróxima vez que o usuário logar ou atravésde uma função de verificação, que teste osdireitos de tempos e tempos, assim permite arevogação durante este intervalo.

A expiração de direitos ocorre nummomento anteriormente estabelecido, temoscomo exemplo os certificados digitais, quesão concedidos, já com um prazo devalidade estabelecido. Sendo muito utilizadotambém em contas de funcionárioscontratados para serviços temporários, asquais são criadas com data de validadedefinida.

Enfim, é muito importante o controle devigência dos direito de usuários sobre osistema.

9. Testando a segurançaÉ a etapa final do desenvolvimento de umsistema. Em função de sua importância esteteste muitas das vezes se confunde comcontrole de qualidade.

O principal objetivo dos testes é garantirque a aplicação seja fiel a todos os seusrequisitos de segurança.

A ISO 15.408, conta com quatro famíliasde garantia de segurança:

Cobertura de testesComposta por uma família decomponentes, que levanta se o testesrealizados são suficientes para garantira funcionalidade prevista do sistema.

Profundidade dos testesEsta família de componentes atua nodetalhamento da funcionalidade desegurança, baseado no aumento daprofundidade das informaçõesutilizadas na análise. Tendo comoobjetivo impedir algum erro e detectarcódigos maliciosos inseridos durante odesenvolvimento.

Testes funcionaisSão executadas geralmente pelosdesenvolvedores, buscando garantirque as funções de segurança retornempropriedades necessárias quesatisfaçam aos requisitos funcionais(ALBUQUERQUE, RIBEIRO – 2002).

Testes independentesÉ a terceirização do teste, ou sejapessoas que não participaram dodesenvolvimento, que buscam falhascometidas pelos desenvolvedores, poisestes tendem a cometê-los, por seremconhecedores da estrutura defuncionamento da aplicação.

10. Avaliação de vulnerabilidadesTem como finalidade garantir a resistênciado sistema contra ameaças do ambiente

A avaliação toma como base a lista deameaças.

Em sua fase de teste, esta avaliação podeser feita pela equipe de desenvolvimento,porém o resultado terá maior garantia se estafor realizada por uma equipe independente.Seja quem for, é imprescindível que aequipe tenha um conhecimento compatível

com os padrões dos ataques testados(ALBUQUERQUE, RIBEIRO – 2002).

A avaliação deve ser realizada após aaplicação estar pronta para entrega.

Para sucesso da avaliação, deve-se levarem conta o levantamento de algunselementos:

Ambiente que a aplicação seráimplantada;

O nível de conhecimento dosprincipais agentes de ataque;

Toda documentação disponível,inclusive as premissas do ambientelevantado.

Nesta fase, a análise deve serextremamente detalhista, pois qualquerresultado que contraste, mesmo que umpouco do esperado, pode ser sinal de umavulnerabilidade.

É importante lembrar que devemos tercuidado com o fato desta análise ser umadas últimas tarefas a ser realizada antes daentrega, em função disto, ela pode receberpressões de prazo de entrega, assim tornainteressante que esta análise seja realizadapor terceiros, uma vez que estes serãomenos influenciado pelo fator tempo.

Os testes podem ser realizados utilizandode várias técnicas, como por exemplo:fornecendo um número maior de caracteresesperado pelo sistema, assim causando umestouro de campo de entrada. Podemosainda usar plics(‘) ou outros caracteresestranhos, que podem fazer com que osistema retornem mensagens de erro, ondeestas mostram ao atacante uma brecha a serexplorada. Muitas outras podem ser usadas,pois existem inúmeras a disposição e quecom certeza surgirão.

O importante e ressaltar que devemosverificar o maior número de possibilidadesde ataque, mesmo aquelas menos prováveis,pois assim estaremos dando a garantia desegurança pretendida pela aplicaçãodesenvolvida.

11. Segurança na programação Web

Enquanto as atenções estão voltadas para osproblemas de segurança de redes, outroproblema de grande gravidade é deixado delado: falhas de programação capazes deexpor um site na web.

Estas falhas possibilitam que qualqueramador consiga entrar em sites, para istobasta usar um browser e o notepad, nãoprecisando ser um grande hacker commuitos conhecimentos e técnicas.

Tudo se inicia na caixa de login e senha.É necessário que a aplicação pegue o login esenha digitados e pesquise-os no banco dedados. Existe uma regra básica para evitarfalhas de segurança: “jamais faça umapesquisa no banco de dados com algo que ousuário informou sem trocar primeiramenteos caracteres reservados”. O não seguimentodesta regra leva à algoritmos falhos, do tipo:“vai-se ao banco de dados pesquisando pelonome e senha, se houver registro de retornoo nome e senha é válido e o usuário estálogado”.

Digitando, na caixa de login, umapóstrofo e clicando no botão para seguir,podemos ter várias reações:

Uma mensagem de erro gerada pelopróprio site.

Essa é a melhor reação possível, quandobem utilizada e quando não fica inútil. Ofato da própria aplicação no site gerar amensagem de erro significa que, se é quehouve um erro ocorreu um tratamento e opretenso invasor ficará sem saber o queocorreu em conseqüência da entrada dele nacaixa de login.

Alguns sites têm o costume de darmensagens diferentes para cada tipo de erro,tal como: “usuário inválido”, “senhainválida” e “erro desconhecido”. Neste casoo procedimento de tratar o erro é inútil, poisa mensagem de erro personalizada estáinformando ao invasor que a tentativa delegerou algum resultado.

O ideal é dar uma mensagem padrão, porexemplo “login inválido” , para qualquererro que possa ocorrer durante o processo delogin. Desta forma o invasor, a princípio,

não saberá se as tentativas dele geraramalgum resultado ou não, dificultando a açãodo pretenso invasor. (TORRES, 2003)

Mensagem do servidor: Caracteresinválidos no login.

Apesar de funcionar e parecer a soluçãodo problema, está não é a melhor forma dese tratar os apóstrofos. Se a mensagem fordisparada a partir do servidor significa que oalgoritmo de login testou o login eidentificou que haviam caracteres inválidos,não indo ao banco de dados. Isto fará comque o invasor de imediato desista do seusite, mas saiba que seu site é malprogramado.

Mensagem do Cliente: Caracteresinválidos no login.

Em menos de cinco minutos o invasoredita o código fonte, elimina a validação einvade o site. Manter validação apenas nocliente é o mesmo que nada. Se a validaçãoestiver tanto no cliente como no servidor oinvasor vai perder tempo a toa. Mas parasorte deste, são poucos os desenvolvedoresque tem um verdadeiro conhecimento daarquitetura web para desenvolver destaforma.

11.1 Solucionando o problemaQuando lidamos com caracteres reservadosde uma linguagem devemos pesquisar deque forma eles poderiam ser representados.O SQL não é uma exceção.

O apóstrofo, caracter reservado no SQL,para ser representado precisa ser dobrado.Assim quando o banco de dados encontradois apóstrofos dentro de uma string,entende que o que se pretende é inserir ouconsultar apenas um e tudo funcionacorretamente. Em ASP podemos utilizar ainstrução replace para dobrar os apóstrofosdigitados pelo usuário.

Desta forma não fará diferença para ocódigo o que for digitado, o código fará abusca do que o invasor digitar como se fosseum nome de usuário e o resultado será

"usuário inválido". Por isso que quando oinvasor recebe esta mensagem ou continuarecebendo uma mensagem de erro padrão,ele desiste do site, pois percebe que o sitefez o tratamento dos apóstrofoscorretamente.

12. ConclusãoEste artigo procurou alertar da importânciada segurança no desenvolvimento de umsistema. Salientando técnicas de eficiênciacomprovada internacionalmente, quegarantem a obtenção dos resultadospretendidos no que diz respeito a segurança.

Esperamos que seu conteúdo seja degrande valia aos profissionais da área dedesenvolvimento e aos interessados peloassunto, que em conjunto com outras obrassobre o assunto, possam solidificar a práticadestas técnicas, que sem dúvida maximiza asegurança de uma aplicação.

Referência

ALBUQUERQUE, Ricardo; RIBEIRO,Bruno. Segurança no Desenvolvimento deSoftware. 1. Ed. Editora Campus, Rio deJaneiro, RJ, 2002

MARTINS, José Carlos Cordeiro. Gestãode Projetos de segurança da Informação.1. Ed. Editora BRASPORT Livros eMultimídia Ltda, Rio de Janeiro, RJ, 2003

TORRES, Dennes. Segurança Máxima deSoftware: Como desenvolver SoluçõesSeguras. 1. Ed. Editora BRASPORT Livrose Multimídia Ltda, Rio de Janeiro, RJ, 2003

Anexos

Tabela 1 - Acesso ao sistemaCategoria Descrição

Programador Acesso eventualmente total ao código do sistemaAdministrador Total acesso à operação e administração do sistemaUsuário do sistema Acesso a algumas funções do sistemaAcesso não-autorizado Pessoas, em princípio, sem acesso ao sistema

(ALBUQUERQUE, RIBEIRO – 2002)

Tabela 2 – Conhecimento do sistemaCategoria Descrição

Grande conhecimento Usuário poderosos, administradoresAlgum conhecimento Usuários ou ex-usuários do sistemaAcesso a manuais Embora sem conhecimento do sistema, tem acesso a

manuais (ALBUQUERQUE, RIBEIRO – 2002)

Tabela 3 – Capacidade do agenteCategoria Descrição

Especialista Grande experiência em ataques. Usa ferramentas sofisticadasConhecedor Alguma experiência em ataques. Ferramentas mais simplesCurioso Ferramentas básicas de ataquesleigo Nenhum conhecimento


Tabela 4 – Motivação do agenteCategoria Descrição

Financeira Interesse em retorno financeiroImagem Interesse em destacar suas habilidadesdano Vingança ou prejuízo a empresa que tenha trabalhado ou concorrenteAprendizado Estudo de ferramenta de ataque


Tabela 5 – Classificação dos agentesAgente Acesso Conhecimento Capacidade Motivação

Usuário do sistema 3 2 3 1,2,3 ou 4Administrador do Sistema 2 1 2 1,2,3 ou 4Programadores 1 1 2 1,2,3 ou 4Funcionário 3 2 2 1 ou 3Ex-funcionário 4 2 2 1 ou 3hacker 4 3 1 1 ou 2


Tabela 6 – Mecanismos de ataqueMecanismo Descrição

Abuso do poder Acesso legal sobre o sistema para realizar um ataqueBy-pass de controle deacesso

Utilização de funções externas visando burlar o controlede acesso.

Força bruta Quebra de senhas e criptografiaEstouro de buffer Destrutivo, porém de fácil correção pela equipe de

desenvolvimentoCaracteres inesperados Uso de caracteres com a finalidade de confundir o

sistema (ALBUQUERQUE, RIBEIRO – 2002)

Tabela 7 – Ativos com valorAtivo Agente Valor

Confidencialidade da tabela declientes

Ex-funcionários ouconcorrente

Dano à empresa

Integridade da tabela de contas apagar

Hacker, funcionários,usuários, administradorou programador

Valor financeiro


Tabela 8 – Lista de ameaças consideradasAmeaça Agente mecanismo AtivoObtenção de listade clientes

Hacker, Ex-funcionário ouconcorrente

Exploração devulnerabi-lidade co-nhecida, caracteresinesperados

Confidencialidadeda lista de clientes

Falha no sistemaimpede seufuncionamento

programador Abuso do poder Integridade edisponibi-lidade dabase de dados,


Tabela 9 - PremissasIdentificador Premissa

PA.AutentSO O Sistema Operacional deverá autenticar o usuário antes daexecução da aplicação.

PA.AdminSO Somente o Administrador do SO, poderá alterar senhas e criarnovos usuários

PU.TreinAdmin O Administrador deve consultar o RH antes de cadastrar novosusuários


Tabela 10 – Objetivos de segurança x premissasObjetivo desegurança

Premissa Explicação

O.Confidencialidade PU.CadastroUsuario;PAAutentSO;PU.TreinAdmin

A aplicação utilizará autenticaçãodo SO para garantir a autenticaçãodo usuário na aplicação.

O.ControleAdmin PU.AdminAuditoria Existe a figura do administrador deauditoria


126_artigo

Documents