1. Gary McGraw on software security assurance: Build it in, build it right
2. Accountability – Not Code Quality- Makes iOS Safer Than Android
3. Emergency Operations Centers & Security Incident Management: A Correlation
4. Apple takes innovative approach to Flashback malware removal

Artigo do mês em marcelosouza.com:

• Técnicas de troubleshooting

Dei vários RTs esse mês no meu Twitter (vejam @marcelo_sz). Os que merecem destaque:

Ótima iniciativa!!! || RT @lzanardo: “Mr. Log Marley (aka:@lzanardo) will be presenting his Anti-Babel Tower Log project at#ystscon“

I like Building Security In (& Building Visibility In) as much as the Soft Sec guys, but net sec and sec ops will still be needed *forever*. Richard Bejtlich‏ @taosecurity

Reparem: não importa a qualidade de um sistema/ferramenta/equipamento/ambiente, a quantidade de esforço/recurso empregado ou o conhecimento da equipe responsável. Sempre algum problema vai acontecer. Nessas horas é de extrema importância manter a calma e seguir uma metodologia minimamente organizada de troubleshooting.  Vejamos alguns passos e técnicas que recomendo a todos:

1. Conheça os sintomas: saiba o que esta sendo definido como problema conhecendo os sintomas. Colete evidências (logs, screenshots, etc.), principalmente quando quem apontou o problema não entende muito sobre o que está acontecendo.
2. Tente reproduzir o problema: sempre que possível e as consequências não forem catastróficas reproduza o problema com base nos sintomas conhecidos. Principalmente se não tiverem sido coletadas evidências no passo anterior. O importante aqui é ter certeza que o problema de fato existe e qual sua extensão.
3. Formule e teste suas hipóteses: conforme o tipo do problema (rede, aplicação, etc.) você terá um conjunto de hipóteses a formular e testar. O objetivo é ficar com um número pequeno de hipóteses que possam apontar a causa do problema, tendo os testes como principal arma para confirmação/eliminação de hipóteses. Para evitar um “rotating machine gun troubleshooting”, onde se atira para todos os lados (tudo se torna causa), existem algumas técnicas. Duas delas são:
   • Verificar mudanças recentes: considere como hipótese principal qualquer mudança recente que possa ser minimamente relacionada ao problema. Exemplos clássicos em SegInfo: regras de firewall novas, atualização de IPS, revisão de acessos.
   • Seguir as camadas de rede: especialmente quando um problema é relacionado a rede, siga as camadas do modelo TCP/IP ou OSI, de física até aplicação, respeitando sua ordem. Não verifique uma camada superior antes de ter verificado TODAS as camadas inferiores e eliminado hipóteses de falhas respectivas. Exemplo: verificar cabeamento (camada física), verificar tabelas ARP (camada de enlace), verificar roteamento (camadade de rede), verificar portas TCP/UDP (camada de transporte), verificar a aplicação. Perceba que a camada de aplicação é a última a ser verificada.
4. Encontre a causa e faça correções: caso suas hipóteses e testes estiverem corretos são grandes as chances de você já saber a causa e também o que precisa ser corrigido. Siga o seu plano de mudanças, conforme necessário, e mãos à obra.
5. Repita se necessário: se chegar nesse ponto você está lidando com uma $%!t^* daquelas! Reinicie desde o primeiro passo, revise tudo e veja se não faltou algum detalhe.

Espero que estas recomendações sejam úteis no seu próximo troubleshooting. E boa sorte!

1. Hacking IT systems to become a criminal offence
2. The Risks of Remote Desktop to Access over Internet
3. AccessData FTK 4.0: initial impressions
4. Is Cloud Secure? WTFC!

Artigos do mês em marcelosouza.com:

• “Por que os talentos deixam as empresas” aplicado a profissionais de SegInfo

Recentemente li um artigo da Forbes, intitulado “Why Top Talent Leaves: Top 10 Reasons Boiled Down to 1″. O artigo resume de forma direta o principal motivo dos talentos abandonarem empresas. Traduzindo livremente, da forma mais fiel possível: “Os melhores talentos saem de uma organização quando são mal gerenciados e a organização é confusa e não inspiradora”.

Meu objetivo nesse artigo de hoje é trazer isso para o mundo dos departamentos e empresas de SegInfo. Para adaptar melhor ao contexto, vamos mudar a conclusão acima para: “Bons profissionais de SegInfo vão embora quando há má gestão, confusão e consequentemente falta de motivação”. Assim, vou tentar responder à seguinte pergunta: quais seriam os indícios de má-gestão e confusão?

Na minha opinião, considero os fatores abaixo como os principais indícios de má gestão e confusão em SegInfo, que invariavelmente levam à desmotivação de profissionais que eventualmente passam por estas situações:

• CSOs ao invés de Security Leaders: a liderança nata cada vez mais escassa abre margem ao surgimento de “ocupantes de cargos com siglas”. O que se espera de um verdadeiro gestor de SegInfo é a liderança de sua equipe, mostrando claramente quais são os objetivos da área, porque e como todos devem atuar para atingí-los. Sim, o verdadeiro líder convence sua equipe da importância de objetivos plausíveis por ele definidos e defendidos, sem precisar se basear unicamente em metas “top-down”.
• “Casa de ferreiro, espeto de pau”: esse indício pode ser mais comum em empresas de consultoria de SegInfo. Vendem uma parafernalha tecnológica de ponta, mas nem mesmo o mais simples anti-vírus esta instalado nas estações. Claro que nem preciso dizer o risco disso (não que anti-vírus seja a solução para todos os males, nós bem sabemos…). E profissional de SegInfo se irrita demais com esse tipo de situação! Pior ainda é quando não estão disponíveis as ferramentas necessárias para o trabalho, aquelas que apoiam os processos (quando estes existem).
• “Síndrome da barata-tonta”: em SegInfo é mais conhecida como “Oh meu Deus, fomos invadidos, e agora!”. A confusão impera por não existirem processos e procedimentos definidos formalmente, nem muito menos divulgação e treinamentos sobre os mesmos.
• “Complexo de bombeiro”: muito comum em áreas mal estruturadas ou com pouca mão-de-obra qualificada (talentos!). Nestas, o dia-a-dia da equipe de SegInfo é apagar incêndios. Nunca há tempo ou incentivo para planos de adequação, prevenção ou preparação.
• Relatórios “para-inglês-ver”: auto explicativo. Já se depararam com isso?

Essa lista certamente é não exaustiva. Vocês que trabalham na área devem estar imaginando várias outras situações e indícios de má gestão e confusão. Algum comentário?

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.