A Lauda Gerencia de Segurança

Gerência da segurança

Grupo:

Gerência de segurança X Segurança

O grande enclave estabelecido nos conflitos entre gerência de segurança e segurança tem uma implicação direta na maneira como se instituem os investimentos.

É claro e notório o apego dos profissionais de segurança as melhores ferramentas - por definição, as mais caras e por infelicidade, nem sempre as mais funcionais - cuja implementação e a própria utilização estão a encargo do gerente da empresa.

Gerência de segurança é algo diferente da própria segurança em si: enquanto profissionais da área de segurança não pensam nela de forma geral, calculando custos, distribuição de orçamento, cronogramas, etc, os gerentes de segurança têm todo o peso que acompanha o processo da implementação de segurança na empresa.

A natureza clara da gerência de segurança em nada se distancia da natureza de gerência de projetos: deve ser exclusivamente elaborada considerando custo, necessidade e eficácia. Dados princípios em mãos, percebe-se a natural diferença entre os interesses das partes de segurança e sua gerência.

Respeitando a existência disto, basta definir o conjunto de condições dentro da topologia e as necessidades de seu ambiente para formar um projeto, sendo estas:

1- Risco

2- Ameaça

3- Prejuízo

Risco -> Probabilidade da ocorrência de um evento indesejável, multiplicada pelo prejuízo que esta ocorrência possa vir a causar; [1]

Ameaça -> Existência da chance de um prejuízo se manifestar sendo causado pela exploração do risco.

Prejuízo -> Déficit monetário causado à organização.

Segurança de rede

Quando foi criado o conceito de comunicação entre computadores, não era objetivada a segurança. Dá-se, por exemplo, o interesse maior na própria liberação de recursos com fim de pesquisa. A grande primeira pane de servidores de internet não foi conseqüência da exploração de um erro desconhecido e sim exclusivamente o mau uso intencional de uma funcionalidade. Esta pane foi o worm do Robert Morris Jr., que parou a internet no ano de 1981. A intenção do worm criado era medir o tamanho da internet utilizando-se em primeira ordem de funcionalidades de uma aplicação (sendmail), e em segunda instância a exploração de aplicações a partir de buffer overflow ou execução de comandos de uma suposta "fonte confiável".

Para entender melhor o conceito de segurança em rede, deve-se primeiro separar em grupos. Em primeiro, protocolos, em segundo, funcionalidades nativas do sistema operacional e por último, serviços providos por aplicações.

O desenvolvimento dos protocolos de rede, foi baseado pura e exclusivamente em alta funcionalidade para comunicação e descoberta de erros relacionados a rede em questão. Nada a respeito de segurança foi pensado durante o desenvolvimento dos protocolos, que quando se tornaram populares, as pessoas passaram a utilizar de forma maliciosa. Exemplos clássicos são: arp spoofing - man in the middle, switch -, tcp - dos utilizando tcp reset, sniffering - e OS Fingerprint.

1- vulnerabilidades clássicas:

arp spoofing

- man in the middle

- switch flood

TCP

- dos utilizando tcp reset

- sniffering*

OS Fingerprint



Segurança de SO

Sistemas operacionais por sua natureza herdaram várias funções não naturais, e um exemplo por negação seria: qualquer coisa que não faça escalonamento de processos e memória, tais quais servidores de mensagem, servidor de compartilhamento de arquivos, etc.

Considerando as suas diferenças de natureza, podemos assimilar facilmente os pontos primordiais de foco dos usuários mal-intencionados: funcionalidades iniciais dadas pelas ferramentas, que nesse ponto possuem acesso irrestrito à máquina, em segunda instância por questões mais elaboradas que trabalhavam falhas de gerenciamento do próprio sistema operacional, como por exemplo, buffer overflow, mais tardiamente trabalhado por ferramentas de segurança como o Pax, que faz tratamento do espaço de memória.

A migração de versão de uma determinada aplicação correspondia a um hiato temporal que deixava certas lacunas de segurança. Graças à dificuldade e insegurança a respeito do funcionamento das aplicações, depois de atualizadas, fabricantes de sistemas operacionais perceberam que algo deveria ser feito.

Com a facilidade de exploração das vulnerabilidades dos sistemas operacionais, os fabricantes tentaram resolver o problema implementando uma funcionalidade no SO que, através de um patch de atualização, corrige determinadas falhas de segurança. O que gerou outro problema: utilizando-se do patch de segurança, é possível gerar um exploit automaticamente em pouco tempo para se explorar a falha de segurança (que poderia ser conhecida apenas pelo fabricante).



Segurança da aplicação

Já que subverter o sistema operacional era uma tarefa relativamente fácil, não existia um interesse em subverter a aplicação a fim de ganhar o acesso ao sistema. Com o advento dos patches, a mentalidade malfeitora mudou para subverter a aplicação.

Posto que fabricantes de SO conscientizam e priorizam desenvolvedores seguros, qualquer pessoa pode se tornar um programador que não pensa em desenvolvimento seguro. Segurança é vista não como algo íntriseco ao desenvolvimento de adicional, custoso um software, e sim como um, que a falta não acarreta no não-funcionamento do software. A partir das aplicações escritas por esses