Em SegInfo não é diferente. Mas a pergunta que fica: será que vale à pena segui-las? Na minha humilde opinião, não. Tais  previsões normalmente são extremamente enviesadas na tentativa de (des)favorecer tecnologias/soluções/fabricantes.

Como sei que estou chovendo no molhado, percebi pelo menos um bom proveito a ser tirado destas listas: diversão. Vamos tentar nos divertir um pouco?

Nomes típicos de listas de previsões em SegInfo

Alguns nomes comumente usados por autores destas listas:

• Tendências de segurança para <insira o ano>: simples assim.
• Top <insira o número de itens da lista> previsões em <insira seu tema preferido sobre SegInfo> para <insira o ano>: o autor tem muitas previsões a fazer, mas preferiu colocar só algumas.
• Ameaças mais perigosas para <insira o ano>: cheiro de FUD no ar!
• Qual será a maior ameaça ano que vem? : o autor não tem tanta certeza, então prefere dar uma lista.
• Etc, etc…

Como dectar FUD em listas de previsões

Veja alguns indicativos de estratégia do “medo, incerteza e dúvida” nestas listas. E não se surpreenda se praticamente todas listas se basearem em variações de:

• “A plataforma X será alvo de um grande número de ataques”
• “Ausência de solução Y em dispositivos ABC fará com que estes sejam fortes vítimas neste novo ano”
• “Surto na quantidade de cyber incidentes provenientes dos grupos Z”

Previsões criativas, pra não dizer o contrário

A criatividade não é necessariamente um ponto forte entre os autores destas listas. O óbvio impera, como podemos ver:

• “Malware para plataformas móveis irá crescer”: com certeza, se algum sistema/dispositivo passa a ser mais adotado, essa é a tendência natural.
• “Sistemas de automação industrial voltarão a ser alvo”: para compor a lista, basta usar algo que já ocorreu no passado e/ou ainda ocorre e colocar novamente como previsão.
• “Sistemas e dispositivos de saúde serão alvos de ataques”: vamos pegar carona em outra norma, pois PCI e SOx deixaram de ser cool.
• “Pelo menos mais um grande incidente envolvendo vazamento de informações pessoais”: assim fica fácil…

Por fim…

…espero que todos tenham tido alguns segundos de diversão com um assunto tão comum nessa época do ano. E que me permitam fazer uma previsão para 2012: teremos mais artigos neste blog ano que vem!

Feliz 2012 a todos!

Vou começar de leve, com o primeiro de uma série de artigos que pretendo escrever sobre o assunto. Ou talvez nem tão de leve assim, pois o tema é delicado: Como criar um tão aclamado Centro de Operações de Segurança?

Afinal, o que é um SOC?

Ainda me lembro do tempo em que, prestando serviço a uma das operadoras mais bem preparadas tecnologicamente no país, fui incumbido da tarefa de operar e administrar uma ferramenta de SIEM em seu SOC. Naquela época (por volta de 2006), SOC no Brasil era vanguarda. Acho que nem mesmo a Wikipedia tinha definição para o termo. Felizmente hoje existe, então posso copiar a definição do termo e colar aqui:

Um Security Operations Center (SOC), em português Centro de Operações de Segurança, é um termo genérico que descreve parte ou a totalidade de uma plataforma cujo objetivo é prestar serviços de detecção e reação a incidentes de segurança.

Duas observações importantes nesta definição:

1. …uma plataforma… : plataforma é até diminutivo demais para algo como um SOC. Eu daria status de entidade, área ou unidade organizacional, mesmo que seja parte de um departamento tal como uma Gerência de Segurança da Informação ou um Centro de Resposta a Incidentes (CSIRT), ou até mesmo parte de uma empresa de MSS.
2. ...detecção e reação a incidentes de segurança: sim, um SOC tem que ser capaz de fazer detecção e reação, mas não só isso. E não somente de incidentes, que normalmente são “coisas ruims”. E não necessariamente uma reação completa, que pode ser parte das atribuições de outro grupo, como um CSIRT, uma outra empresa ou o próprio cliente (no sentido geral da palavra).

Redefinindo o termo, no meu entendimento:

SOC é uma área ou unidade organizacional que tem como objetivo prestar serviços de monitoração de segurança, detectando, analisando e respondendo a ocorrências que possam impactar o nível de segurança de uma organização.

Com essa definição eu reforço não apenas o observado acima, mas também:

• a importância do conceito de prestação de serviços, no sentido geral. Desse modo, clientes não são apenas aqueles que pagam todo mês, mas também outras unidades organizacionais interessadas, dentro da mesma organização.
• a importância da idéia de monitoração inerente ao SOC, assim como num NOC (Network OC) ou até mesmo numa central de vigilância patrimonial, que detecta, analisa e responde a alarmes, sem necessariamente reagir efetivamente a eles (o operador da central não vai até o local para prender alguém, mas pode chamar a polícia).
• a importância de se detectar (descobrir), analisar (entender) e responder (reagir de alguma forma a um estímulo).

O mais importante a se observar vem do objetivo principal de um SOC: a necessidade de trabalhar para a manutenção do nível de segurança de uma organização.

O que um SOC não é?

Definitivamente, um SOC não é:

• a mesma coisa que um MSSP (Managed Security Services Provider). Um SOC pode ser parte de um MSSP ou uma das unidades de um provedor de seviços gerenciados.
• uma área que atende chamados de usuários, aplica regras de firewall ou atualiza IDSs. Isso é parte dos possíveis serviços de um MSSP.
• a mesma coisa que um CSIRT. Pode ser parte de um CSIRT, mas prefiro dizer que são unidades separadas também (mais sobre isso outro dia…).

E definitivamente mesmo, SOC não é um software (nem mesmo um SIEM, por melhor que seja), um equipamento ou aquela sala bonita com um telão de 60 polegadas e um monte de gente assistindo. SOC é muito mais que isso…

A velha tríade: pessoas, processos e tecnologia

Pessoas, processos e tecnologia são e vão continuar sendo por todo tempo a base para qualquer projeto, área ou organização de alguma forma relacionada com TI, e ainda mais se o assunto for SegInfo. Para a criação de um SOC, essas três “disciplinas” precisam ser bem planejadas, nessa exata ordem.

Em alto nível, uma breve apresentação de algo a considerar para a criação de um SOC:

• Pessoas: os membros do SOC, em alto nível. Quem são os stakeholders? Qual departamento será hierarquicamente responsável pelo SOC? Quais outras áreas serão envolvidas? Quais são os papéis de cada um? Estão realmente preparados e comprometidos com o projeto? Quais são os clientes do SOC? Quem irá liderar? Quem irá executar?
• Processos: nada mais são que a cadeia de ações executadas com base em algum insumo e que resultam num produto. Para listar os processos, algumas questões preparatórias podem ser feitas: Qual será a missão do SOC? Quais são os objetivos? Quais serão os insumos recebidos e os produtos gerados para atingir estes objetivos? Tendo respondido a isso, partir para a etapa de definição de processos propriamente dita, iniciando em alto nível para identificar passos chave dos processos, fim-a-fim. Algumas questões que podem ajudar para o refinamento dos processos são: Quais informações básicas serão tratadas? Quais relacionamentos (interação entre áreas, solicitações, acordo geral de nível de serviço) serão necessários? Quais indicadores de qualidade deverão ser sempre acompanhados? Outro ponto importante: a atenção deve ser especial nas demandas com maior probabilidade de ocorrer.
• Tecnologia: tendo definido pessoas e processos, a tecnologia será apenas o componente empregado para que as pessoas executem os processos com a eficiência e eficácia esperada, definida anteriomente (indicadores de qualidade). A tecnologia é que depende dos processos, e não o contrário. Com base nos processos, realizar o levantamento das tecnologias (software, hardware, etc.) aplicáveis e necessários.

No próximo artigo…

Em breve, num próximo artigo, vou entrar em detalhes do planejamento necessário para criação do SOC. Até lá!

O tema também mudou, como vocês podem ver. Além de estar hospedado no WordPress.com (o bolso pediu…).

Daqui a pouco tem post novo no ar!

Uma razão para a persistência deste cenário é que não existem padrões efetivos para o desenvolvimento de software seguro, ou melhor, não existem processos bem definidos visando este objetivo. Na verdade, apesar dos problemas, boa parte das organizações nem mesmo discute esta necessidade.

Por outro lado, várias empresas relevantes no mercado já se posicionaram num sentido positivo. A Microsoft, por exemplo, aplica desde 2005 a metodologia SDL (Security Development Lifecycle), de autoria própria. Felizmente, muitos desenvolvedores e gerentes de desenvolvimento já entendem a necessidade da segurança de software, e as iniciativas em busca da aplicação de modelos, guias e padrões têm sido crescentes. Um exemplo claro é o crescimento da comunidade em torno do projeto OWASP (Open Web Application Security Project).

Paralelamente, ao longo dos anos, tem se tornado cada vez mais evidente que desenvolver software seguro depende do resultado conjunto de pessoas e processos, e não somente de tecnologia. Outras experiências também mostraram que, mesmo sendo únicas, as organizações podem tirar bom proveito de práticas bem sucedidas de outras organizações, ao invés de simplesmente se basear em metodologias teóricas.

Tendo tudo isso em mente, um grupo de especialistas em segurança de software das empresas Cigital (Gary McGraw, Sammy Migues) e Fortify (Brian Chess) publicou o BSIMM (Building Security In – Maturity Model), um modelo de maturidade focado em segurança de software. O modelo foi elaborado com base em iniciativas de segurança de 9 empresas diferentes, entre elas Adobe, EMC, Google e Microsoft. Utilizando um arcabouço de sua autoria denominado SSF (Software Security Framework), que aponta domínios e práticas comuns das iniciativas em segurança de software, o grupo conduziu pesquisas nas empresas participantes e utilizou os dados obtidos para construção do modelo.

O modelo lista 110 atividades divididas em 12 práticas dos 4 domínios do SSF. Cada prática pode receber até o nível 3 de maturidade. Totalmente livre (licença Creative Commons), o modelo pode ser obtido neste link (requer registro), ou acessado interativamente aqui.

Para entender e considerar o BSIMM positivo, deve-se levar em consideração pelo menos dois fatores:

• Apesar de utilizarem métodos diferentes, as empresas envolvidas na pesquisa empregam iniciativas de segurança que compartilham melhores práticas. O BSIMM condensou as atividades e boas idéias comumente aplicadas.
• Modelos de maturidade têm sido aplicados em diferentes áreas há muito tempo, com bom nível de disseminação. O BSIMM se apresenta num formato já consolidado e aceito internacionalmente.

O BSIMM não é um guia completo ou um “how-to”, mas pode ser um bom começo para aqueles que lidam com desenvolvimento e implantação de software, ou que de alguma forma dependem da confiabilidade dos aplicativos e programas que suportam o negócio de sua organização.

Apesar do artigo ser um pouco antigo, o assunto anda muito em voga. E, mesmo não apresentando muitas novidades de fato, resolvi fazer um “self promotion” e postá-lo aqui. Boa leitura!

A palavra convergência tem tomado o dia-a-dia das empresas de telecomunicações nos últimos anos. As operadoras de todo o mundo têm focado seus esforços e investimentos em torno da construção das chamadas “redes da próxima geração”, com o objetivo de oferecer, além dos já tradicionais serviços telefônicos e de banda larga, serviços de televisão, utilizando de forma única e compartilhada as técnicas e meios de transmissão de dados.

Esse novo enfoque dado à prestação de serviços de telecomunicação significa, basicamente, a possibilidade de se fornecer em conjunto os serviços que antes eram fornecidos totalmente separados. Porém, convergência tem sido usada pelas operadoras ao redor do globo com entonação quase mística, tais como “a liberdade para os clientes utilizarem qualquer serviço em qualquer circunstância”, ou como “uma questão de conveniência que enriquece a vida das pessoas, já que pode ser oferecida informação e entretenimento da forma que elas desejarem”, e até mesmo como “simplicidade para os clientes – o primeiro passo para o paraíso digital”.

Deixando o marketing de lado, convergência de fato se trata de um avanço da tecnologia que, no mínimo, ira auxiliar os operadores de telecomunicação. Convergência é o resultado da indústria de telecomunicação adotando a tecnologia da Internet, que provê uma forma mais barata e eficiente de mover dados pelas redes de computadores. Na Internet, toda informação é transportada por meio de pacotes de dados, seguindo o protocolo IP (Internet Protocol). Este mesmo sistema também pode ser usado para codificar chamadas de voz, mensagens de texto e foto, chamadas de vídeo e canais de televisão. E com a maturidade já alcançada pelas redes IP, as operadoras podem substituir toda a infra-estrutura heterogênea, utilizada na prestação dos diferentes serviços, por uma única rede totalmente baseada na comutação de pacotes IP, aliviando assim os custos com manutenção e operação das diferentes tecnologias e sistemas.

É importante citar que essa convergência afeta não só as redes cabeadas, mas também as redes sem fio. Com o advento da convergência, as operadoras podem utilizar redes de transmissão compartilhadas, tanto para telefonia fixa quanto para móvel. Isso tudo pelo fato de que redes convergentes são agnósticas aos meios de acesso – uma rede núcleo (ou “core”) pode ter diversas outras redes e dispositivos interconectados em suas pontas através de diferentes tecnologias. Telefones fixos tradicionais podem estar conectados por fios, telefones celulares conectados pelas ERBs, e televisores ou computadores conectados à banda larga via links telefônicos ou Wi-Fi.

Redes convergentes, totalmente IP, têm duas vantagens para as operadoras de telecomunicações. A primeira, já comentada aqui, envolve queda nos custos, graças à arquitetura mais simples e às economias na escala de produção dos padrões IP. Algumas operadoras chegam a estimar gastos 30% menores. A segunda vantagem é que, em teoria, novos serviços podem ser adicionados de forma muito mais rápida e fácil, sem a necessidade de se adicionar nova infra-estrutura de rede. Adicionar um novo serviço requer basicamente a adição de um novo software ao núcleo da rede, e talvez alguma nova tecnologia de acesso nas pontas.

Por causa da convergência baseada em redes IP, companhias que antes se encontravam em nichos separados – telefonia, provedores de banda larga, ou TV a cabo – de repente passaram a fazer parte do mesmo negócio. Operadoras de TV à cabo passaram a ocupar os mercados de telefonia e banda larga, e operadoras de telefonia passaram a ocupar o mercado de TV à cabo. Nesse novo “mundo convergido” das telecomunicações, qualquer empresa que possa oferecer dados via IP por meio de suas redes pode oferecer qualquer um destes serviços.

A estratégia dominante é oferecer juntos grande parte dos serviços disponíveis, senão todos. Daí vem a grande corrida das empresas em possuir pacotes “triple play” (telefone, banda larga e TV), ou até mesmo “quadruple play” (telefone fixo, telefone móvel, banda larga e TV). As operadoras alegam que vender três ou quatro serviços juntos num pacote torna a vida mais fácil e conveniente para os clientes, além de tornar possível a oferta de descontos e condições melhores. Como já se sabe, de fato os clientes preferem as possibilidades de desconto, numa única fatura.

Apesar da aparente boa vontade das operadoras de telecomunicações, principalmente as “incumbents”, a ofertas dos pacotes é uma questão de proteção de suas receitas, que ainda são formadas em sua maioria pelos serviços de telefonia fixa. O principal problema destas é a perda de clientes para outras empresas que oferecem serviços de VoIP, ou a perda de clientes que têm se livrado de seus terminais telefônicos fixos em favor dos móveis. Portanto, à medida que as operadoras de TV a cabo oferecem aos clientes os pacotes “triple play”, as operadoras de telecomunicações passaram a oferecer acessos sem fio, os quais não podem ser oferecidos por grande parte das concorrentes. É tudo uma questão de garantia de receita com o uso de suas possibilidades.

Outras melhorias trazidas pela convergência incluem a possibilidade de novos serviços, que anteriormente nem eram cogitados. Um deles é a de aparelhos híbridos (fixo-móvel), em que um mesmo telefone pode ser usado como fixo ou móvel dependendo de sua localização física e oferecendo tarifas de acordo. Outros serviços possíveis são o de TV com vídeo-conferência, TV integrada ao telefone, e até mesmo o acesso remoto (por telefone ou computador) a câmeras de vigilância de sua casa ou trabalho.

Conclui-se, portanto, que convergência promove às operadoras tanto os meios de se defender contra competidores nos seus serviços legados, protegendo sua receita, quanto a possibilidade de gerar novas receitas com novos serviços. Porém os maiores beneficiados são os consumidores, que poderão ter uma gama maior de serviços integrados à sua disposição, com preços mais acessíveis, graças à concorrência entre as empresas, agora com menor custo de operação. A convergência acaba também unindo dois mundos que antes andavam separados: a tecnologia da informação e as telecomunicações, somando forças para o avanço da sociedade e da vida moderna.

Alguns pontos importantes na análise das estatísticas (adaptados do anúncio do CERT.br na lista certbr-anuncios):

• O total de notificações recebidas em 2008 foi de 222.528, o que representa um aumento de 39% em relação a 2007.
• As notificações de tentativas de fraude, em 2008, totalizaram 140.067, correspondendo a um aumento de 209% em relação a 2007.
• O aumento das tentativas de fraudes está relacionado, principalmente, ao crescimento nas notificações de quebra de direitos autorais através da distribuição de material pirata em redes P2P. Em 2008 este tipo específico chegou a 108.242, correspondendo a um crescimento de 600% em relação a 2007;
• Em 2008 houve um aumento, em relação a 2007, de 124% no número de notificações de casos de páginas falsas de bancos (phishing tradicional). Este aumento intensificou-se no segundo semestre de 2008, quando as notificações cresceram 104% em relação ao primeiro semestre.
• O crescimento no número de páginas falsas de bancos concentrou-se, principalmente, em páginas de bancos brasileiros, com aumento de 266% no ano em relação a 2007.
• Em 2008 ocorreu um aumento, nas notificações de ataques a servidores Web, de 149% em relação ao ano anterior. Estes ataques exploram vulnerabilidades em aplicações Web e, em alguns casos, visam a hospedagem de cavalos de tróia utilizados em fraudes ou de páginas falsas de instituições financeiras.

Seguem abaixo meus comentários e uma coletânea de links sobre segurança em Mac OS X:

• A lista de features de segurança do Leopard (Mac OS X 10.5) é bem vasta, e como usuário da plataforma posso dizer que a Apple conseguiu mantê-lo seguro e “usável” ao mesmo tempo.
• O sistema a princípio é mais imune a malware do que o seu concorrente de Redmond, porém sabemos que isso não passa de (in)segurança por obscuridade. A Apple chegou a divulgar a necessidade de uso de anti-vírus no final do ano passado, mas voltou atrás após “perceber” que isso estava indo de encontro à sua estratégia de marketing. Sugiro a instalação de anti-vírus e correlatos, no mínimo como medida preventiva, e já pensando nas prováveis ameaças futuras.
• Recomendo acompanhar o SecureMac e The Mac Security Blog. Este último, apesar de ser de uma empresa que desenvolve software de segurança para Macs, traz artigos interessantes, tais como uma compilação completa de notícias de 2008 sobre o tema.
• Recomendo também a leitura dos excelentes guias de segurança escritos pela Apple.

Pretendo escrever mais sobre o tema. Portanto, até o próximo post!

[ 26/01/2009 15:40 - Atualização ]

Não tinha percebido antes, mas o especialista em segurança Pedro Bueno, handler do ISC, postou recentemente o artigo Identifying and Removing the iWork09 Trojan. Leitura recomendada para quem ainda acha que anti-vírus no Mac é bobagem.

Muito tempo depois do memorável artigo de Marcus J. Ranum, entitulado The Six Dumbest Ideas in Comupter Security, Lenny Zeltser publica mais uma grande contribuição: How to Suck at Information Security.

Sugiro a leitura completa deste último, e aproveito para fazer comentários sobre alguns dos tópicos que concordo plenamente (tradução livre):

• Assumir que os usuários irão ler a política de segurança por uma mera solicitação: o resultado é óbvio, pois poucos irão ler um documento que para eles fará pouca diferença (ou só trará chateações, de seu ponto de vista). Nada mais recomendável que iniciativas de awareness frequentes, com palestras, material multimídia, teatros, etc. Estas sim podem se mostrar bem mais efetivas.
• Criar políticas de segurança que não podem ser garantidas: fazendo uma analogia bem simples, a “Lei Seca” seria com certeza muito mais efetiva se tivéssemos mais bafômetros nas ruas.
• Praticar políticas de segurança que não foram devidamente aprovadas: em outras palavras, quem foi que disse que a partir de hoje o Skype está bloqueado?
• Executar testes de vulnerabilidade, mas não acompanhar os resultados: esta é uma prática muito comum, mas que faz muita falta ao se criar indicadores. Normalmente se investe muito em network assessments e pen-tests, porém estes sempre devem envolver o trabalho posterior de correção.
• Adquirir produtos caros quando uma simples correção poderia consertar 80% do problema: um exemplo clássico é o uso de um WAF (web application firewall) para proteção de aplicações web com vulnerabilidades que poderiam ser corrigidas com muito menos recurso (pretendo falar mais sobre WAFs num post futuro).
• Banir o uso de discos USB externos e continuar sem restringir acesso à Internet: sem dúvida uma das maiores dores de cabeça quando se fala em vazamento de informações, os acessos a webmail e outros sites são apenas um pouco menos práticos em termos de transporte de dados que os milhares de pen-drives que circulam nas empresas ultimamente.
• Agir com superioridade frente aos colegas da área de redes, administração de sistemas e desenvolvimento: segurança da informação, por ser um processo, pode envolver todas as áreas de uma empresa, em especial as equipes de suporte e desenvolvimento. Soberba só dificulta o trabalho.
• Usar a mesma senha em sistemas que diferem quanto a exposição ao risco ou criticidade de dados: talvez isto seja algo a se pensar antes de implantar SSO (single-sign-on).