Research

Some of our first customer conversations about big data and SIEM centered on how to integrate the two platforms. Several customers wanted to know how they could pull data from different existing log management and analytics systems into a big data platform. Most were told by their vendors that big data was; and they wanted to know what that integration would look like and how it would affect operations. Likely you won’t be doing the integration, but you will need to live with the design choices of your vendor. The benefit depends on their implementation choices. There are three basic models for integration of big data with SIEM: Log Management Container Some vendors have chosen to integrate big data while keeping their basic architecture: semi-relational or flat file system which supports SIEM functions, and fronts a big data cluster which handles log management tasks. We say ‘semi-relational’ because it is typically a relational platform such as Oracle or SQL Server, but stripped of many relational constructs to improve data insertion rates. SIEM’s event processing and near real-time alerts remains unchanged: event streams are processed as they arrive, and a specific subset of events and profile information stored within a relational – or proprietary flat file – database. Data stored within the big data cluster may be correlated, but normalization and enrichment is only performed at the SIEM layer. Raw events are streamed to the big data cluster for long-term storage, possibly compressed. SIEM functions may be supported by queries to reference specific data points within the big data archive but support is limited. In essence big data is used to scale event storage and accommodate events – regardless of type or format. Peer-to-Peer Like the example above, in this scenario real-time analysis is performed on the incoming event stream, and basic analysis performed in a semi-relational or flat file database. The difference here is functional rather than architectural. The two databases are truly peers – each provides half the analysis capability. The big data cluster periodically re-calculates behavioral profiles and risk scores, and shares these with SIEM’s real-time analysis component. It also processes complex activity chains and multiple events tied to specific locations, users or applications may that indicate malicious behavior. The big data cluster does a lot of heavy lifting to mine events, and shares these updated profiles with SIEM to hone policy enforcement. The big data cluster allows provides a direct view for Security Operations Centers (SOC) to run ad hoc queries on a complete set of events to look for outliers and anomalous activity. Full Integration The next option is to leverage only big data for event analysis and long term log storage. Today most of these SIEM platforms use proprietary file systems – not relational databases or big data. These proprietary systems were born of the same need to scale to accommodate more data with less insertion overhead than big data. These proprietary repositories were designed to provide clustered data management, distributing queries across multiple machines. But they are not big data – they don’t have the essential characteristics we defined earlier, and often don’t have the the 3Vs either. You will notice that both peer-to-peer and log management oriented versions use two databases; one relational and one big data. There is really no good reason to maintain a relational database alongside a big data cluster – other than the time it takes to migrate and test the migration. That aside, it is a simple engineering effort to swap out a relational platform with a big data cluster. Big data clusters can be assembled to perform ultra fast queries, or efficient large scale analysis, or leverage both types of queries on a single data set. Many relational features are irrelevant to security analytics, so they are either stripped out for performance or remain present, reducing performance. Again, there is no reason relational databases must be part of SIEM – the only impediment is the need to re-engineer the platform to swap the new cluster in. This does not exist today but expect it in the months to come. Continuing this line of thought, it is very interesting to think of ways to further optimize a SIEM system. You can run more than one big data cluster, each focused on a specific type of operation. So one cluster would run fully indexed SQL queries for fast retrieval while another might run MapReduce queries to find statistical outliers. In terms of implementation, you might choose Cassandra for its index capabilities and native compression, and Hadoop for MapReduce and large-scale storage. The graphic to the right shows this possibility. It is also possible to have one data cluster with multiple query engines running against the same data set. The choice is up to your SIEM vendor, but the low cost of data storage and processing capacity mean the performance boost even from redundant data stores is still likely to outweigh the costs of added processing. The fit for security analytics is largely conjecture, but we have seen both models scale well for various other data analyses. Standalone Those of you keeping score at home have noticed I am throwing in a fourth option: the standalone or non-integration model. Some of our readers are not actually interested in SIEM at all – they just want to collect security events and run their own reports and analysis without SIEM. It is perfectly feasible to build a standalone big data cluster for security and event analytics. Choose a platform optimized for your queries (fast, or efficient, or both if it is worth building multiple optimized clusters), the types of data to mine, and developer comfort. But understand that you will need to build a lot yourself. A wide variety of excellent tools and logging utilities are available as open source or shareware, but you will responsibility for design, organization, and writing your own analytics. Starting from scratch is not necessarily bad but all development (tools, queries, reports, etc.) will fall to your team. Should you choose to integrate with SIEM or log management, you will

So why are we looking at big data, and what problems can we expect it to solve that we couldn’t before? Most SIEM platforms struggle to keep up with emerging needs for two reasons. The first is that threat data does not come neatly packaged from traditional sources, such as syslog and netflow events. There are many different types of data, data feeds, documents, and communications protocols that contain diverse clues to a data breaches or ongoing attacks. We see clear demand to analyze a broader data set in order hopes of detecting advanced attacks. The second issue is that many types of analysis, correlation, and enrichment are computationally demanding. Much like traditional multi-dimensional data analysis platforms, crunching the data takes horsepower. More data is being generated; add more types of data we want, and multiply that by additional analysess – and you get a giant gap between what you need to do and what you can presently do. Our last post considered what big data is and how NoSQL database architectures inherently address several of the SIEM pain points. In fact, the 3Vs (Volume, Velocity, & Variety) of big data coincide closely with three of the main problems faced by SIEM systems today: scalability, performance, and effectiveness. This is why big data is such an important advancement for SIEM. Volume and velocity problems are addressed by clustering systems to divide load across many commodity servers, and variability through the inherent flexibility of big data / NoSQL. But of course there is more to it. Analysis: Looking at More Two of the most serious problems with current SIEM solutions are that they struggle with the amount of data to be managed, and they cannot deal with the “data velocity” of near-real-time events. Additionally, they need to accept and parse new and diverse data types to support new types of analysis. There are many different types of event data, any of which might contain clues to security threats. Common data types include: Human-readable data: There is a great deal of data which humans can process easily, but which is much more difficult for machines – including blog comments and Twitter feeds. Tweets, discussion fora, Facebook posts, and other types of social media are all valuable for threat intelligence. Some attacks are coordinated in fora, which means companies want to monitor these fora for warnings of possible or imminent attacks, and perhaps even details of the attacks. Some botnet command and control (C&C) communications occur through social media, so there is potential to detect infected machines through this traffic. Telemetry feeds: Cell phone geolocation, lists of sites serving malware, mobile device IDs, HR feeds of employee status, and dozens of other real-time data feeds denote changes in status, behavior, and risk profiles. Some of these feeds are analyzed as the stream of events is captured, while others are collected and analyzed for new behaviors. There are many different use cases but security practitioners, observing how effectively retail organizations are able to predict customer buying behavior, are seeking the same insight into threats. Financial data: We were surprised to learn how many customers use financial data purchased from third parties to help detect fraud. The use cases we heard centered around SIEM for external attacks against web services, but they were also analyzing financial and buying history to predict misuse and account compromise. Contextual data: This is anything that makes other data more meaningful. Contextual data might indicate automated processes rather than human behavior – a too-fast series of web requests, for example, might indicate a bot rather than a human customer. Contextual data also includes risk scores generated by arbitrary analysis of metadata, and detection of odd or inappropriate series of actions. Some is simply collected from a raw event source while other data is derived through analysis. As we improve our understanding of where to look for attack and breach cluse, we will leverage new sources of data and examine them in new ways. SIEM generates some contextual data today, but collection of a broader variety of data enables better analysis and enrichment. Identity and Personas: Today many SIEMs link with directory services to identify users. The goal is to link a human user to their account name. With cloud services, mobile devices, distributed identity stores, identity certificates, and two-factor identity schemes, it has become much harder to link human beings to account activity. As authentication and authorization facilities become more complex, SIEM must connect to and analyze more and different identity stores and logs. Network Data: Some of you are saying “What? I thought all SIEMs looked at network flow data!” Actually, some do but others don’t. Some collect and alert on specific known threats, but only a tiny portion of that passes down the wire. Cheap storage makes it feasible to store more network events and perform behavioral computation on general network trends, service usage, and other pre-computed aggregate views of network traffic. In the future we may be able to include all data. Each of these examples demonstrates what will be possible in the short term. In the long term we may record any and all useful or interesting data. If we can link in data sets that provide a different views or help us make better decisions, we will. We already collect many of these data types, but we have been missing the infrastructure to analyze them meaningfully. Analysis: Doing It Better One limitation of many SIEM platforms is their dependence on relational databases. Even if you strip away relational constructs that limit insertion performance, they still rely on a SQL language with traditional language processors. The fundamental relational database architecture was designed and optimized for relational queries. Flexibility is severely limited by SQL – statements always include FROM and WHERE clauses, and we have a limited number of comparison operators for searching. At a high level we may have Java support, but the actual queries still devolve down to SQL statements. SQL may be a trusty

So why are we talking about this? Because APIs are becoming the de facto service interface – not only for cloud and mobile, but for just about every type of service. The need for security around these APIs is growing, which is why we have seen a rush of acquisitions to fill security product gaps. In what felt like a couple weeks Axway acquired Vordel, CA acquired Layer7, and Intel acquired Mashery. The acquirers all stated these steps were to accommodate security requirements stemming from steady adoption of APIs and associated web services. Our goal for this paper is to help you understand the challenges of securing APIs and to evaluate technology alternatives so you can make informed decisions about current trends in the market. We will start our discussion by mentioning what’s at stake, which should show why certain features are necessary. API gateways have a grand and audacious goal: enablement. Getting developers the tools, data, and functionality they need to realize the mobile, social, cloud and other use cases the enterprise wants to deliver. There is a tremendous amount of innovation in these spaces today, and the business goal is get to market ASAP. At the same time, security is not a nice-to-have – it’s a hard requirement. After all, the value of mobile, social, and cloud applications is in mixing enterprise functionality inside and outside the enterprise. And riding along is an interesting mix of user personas: customers, employees, and corporate identities, all mingling together in the same pool. API gateways must implement real security policies and protocols to protect enterprise services, brands, and identity. This research paper will examine current requirements and technical trends in API security. API gateways are not sexy. They do not generate headlines like cloud, mobile, and big data. But the APIs are the convergence point for all these trends, and the crux of IT innovation today. We all know cloud services scale almost too well to be real, at a price that seems to good to be true. But the APIs are part of what makes them so scalable and cheap. Of course open, API-driven, multi-tenant environments bring new risks along with their new potentials. As Netflix security architect Jason Chan says, securing your app on Amazon Cloud is like rock climbing – Amazon gives you a rope and belays you, but you are on the rock face. You are the one at risk. How do you manage that risk? API gateways play a central role in limiting the cloud’s attack surface and centralizing policy enforcement. Mobile apps pose similar risks in an entirely different technical environment. There is endless amount hype about iOS and Android security. But where are the breaches? On the server side. Why? Because attackers are pragmatic, and that’s where the data is. Mobile apps have vulnerabilities that attackers can go after one by one, but a breach of the server-side APIs exposes the whole enterprise enchilada. Say it with me in your best Taco Bell Chihuahua accent: The whole enchilada! Like cloud applications, API gateways need to reduce the enterprise’s risk by limiting attack surface. And mobile apps use web services differently than other enterprise applications, communications are mostly asynchronous, and the identity tokens are different too – expect to see less SAML or proprietary SSO, and more OAuth and OpenID Connect. API gateways address the challenges raised by these new protocols and interactions. APIs are an enabling technology, linking new and old applications together into a unified service model. But while cloud, mobile, and other innovations drive radical changes in the data center, one thing remains the same: the speed at which business wants to deploy new services. Fast. Faster! Yesterday, if possible. This makes developer enablement supremely important, and is why we need to weave security into the fabric of development – if it is not integrated at a fundamental level, security gets be removed as an impediment to shipping. The royal road is to things that make it easy for developers to understand how to build and deploy an app, grok the interfaces and data, and quickly provision developers and their app users to login – this is how IT shops are organizing teams, projects, and tech stacks. The DMZ has gone the way of the dodo. API gateways are about enabling developers to build cloud, mobile, and social apps on enterprise data, layered over existing IT systems. Third-party cloud services, mobile devices, and work-from-anywhere employees have destroyed (or at least completely circumvented) the corporate IT ‘perimeter’ – the ‘edge’ of the network has so many holes it no longer forms a meaningful boundary. And this trend, fueled by the need to connect in-house and third-party services, is driving the new model. API gateways curate APIs, provision access to users and developers, and facilitate key management. For security this is the place to focus – to centralize policy enforcement, implement enterprise protocols and standards, and manage the attack surface. This paper will explore the following API gateway concepts in detail. The content will be developed and posted to the Securosis blog for vetting by the developer and security community. As always, we welcome your feedback – both positive and negative. Our preliminary outline is: Access Provisioning: We will discuss developer access provisioning, streamlining access to tools and server support, user and administrator provisioning, policy provisioning and management, and audit trails to figure out who did what. Developer Tools: We will discuss how to maintain and manage exposed services, a way to catalogue services, client integration, build processes, and deployment support. Key Management: This post will discuss creating keys, setting up a key management service, key and certificate verification, and finally the key management lifecycle (creation, revocation, rotation/updating). Implementation: Here we get into the meat of this series. We will discuss exposing APIs and parameters, URL whitelisting, proper parameter parsing, and some deployment options that effect security. Buyers Guide: We will wrap this series with a brief buyers guide to help you understand the differences between implementations, as well as key considerations when establishing your evaluation priorities. We will also cover

Brian Krebs posted a detailed investigative piece on the 2011 breach of Fidelity National Information Services (FIS) and subsequent ATM thefts. I warn you that it’s long but worth the read. At least if your prescription for anti-depressants is current. Each paragraph seems to include some jaw-dropping fact about FAIL. A couple choice quotes from the article: The company came under heavy scrutiny from banking industry regulators in the first quarter of 2011, when hackers who had broken into its networks used that access to orchestrate a carefully-timed, multi-million dollar ATM heist. In that attack, the hackers raised or eliminated the daily withdrawal limits for 22 debit cards they’d obtained from FIS’s prepaid card network. The fraudsters then cloned the cards and distributed them to co-conspirators who used them to pull $13 million in cash from FIS via ATMs in several major cities across Europe, Russia and Ukraine. $13 mil is a lot of money from an ATM network through only 22 debit cards… … The FDIC found that even though FIS has hired a number of incident response firms and has spent more than $100 million responding to the 2011 breach, the company failed to enact some very basic security mechanisms. For example, the FDIC noted that FIS routinely uses blank or default passwords on numerous production systems and network devices, even though these were some of the same weaknesses that “contributed to the speed and ease with which attackers transgressed and exposed FIS systems during the 2011 network intrusion. … “Enterprise vulnerability scans in November 2012, noted over 10,000 instances of default passwords in use within the FIS environment. So our favorite new acronym du jour is MRA. Matters Requiring Attention. FIS has eight. Eight is a lot or at least that is what the FDIC said. It looks like the top line description of one these MRAs is “roll out a centrally managed scanning methodology to address secure coding vulnerabilities across FIS developed applications”. Hopefully the next MRA reads: “Fix the millions of lines of buggy code and all your crappy development processes. Oh, and some developer training would help”. Problem identification is one thing – fixing them is something else. With so many years in security between us we seldom read about a breach that shocks us, but if these facts are true this is such a case. If there is a proverbial first step in security, it is don’t leave passwords at the default. Hijacking accounts through default passwords is the easiest attack to perform, very difficult to detect, and costs virtually nothing to prevent. It is common for large firms to miss one or two default application passwords, but 10k is a systemic problem. It should be clear that if you don’t have control over your computer systems you don’t have control over your business. And if you don’t get basic security right, your servers serve whomever. The other head-scratching facet of Kreb’s post’s claim that FIS spent one hundred million dollars on breach response. If that’s true, and they still failed to get basic security in place, what exactly were they doing? One could guess they spent this money on consultants to tell them how they screwed up and lawyers to minimize further legal exposure. But if you don’t fix the root problem there is a strong likelihood the attackers will repeat their crime – which seems to be what happened with an unnamed United Arab Emirates bank earlier this year. Personally I would carve out a few thousand dollars for vulnerability scanners, password managers and HR staff to hire all new IT staff who have been trained to use passwords! In an ideal world, we would ask further questions, like who gets notified when thresholds change for something as simple as ATM withdrawal limits? Some understanding of account history would make sense to find patterns of abuse. Fraud detection is not a new business process, but it is hard to trust anything that comes out of a system pre-pwned with default passwords. Share:

Today we pick up our Security Analytics with Big Data series where we left off. But first it’s worth reiterating that this series was originally intended to describe how big data made security analytics better. But when we started to interview customers it became clear that they are just as concerned with how big data can make their existing infrastructure better. They want to know how big data can augment SIEM and the impact of this transition on their organization. It has taken some time to complete our interviews with end users and vendors to determine current needs and capabilities. And the market is moving fast – vendors are pushing to incorporate big data into their platforms and leverage the new capabilities. I think we have a good handle on the state of the market, but as always we welcome comments and input. So far we have outlined the reasons big data is being looked at as a transformative technology for SIEM, as well as common use cases, with the latter post showing how customer desires differ from what we have come to expect. My original outline addressed a central question: “How is big data analysis different from traditional SIEM?”, but it has since become clear that we need to fully describe what big data is first. This post demystifies big data by explaining what it is and what it isn’t. The point of this post is to help potential buyers like you compare what big data is with what your SIEM vendor is selling. Are they really using big data or is it the same thing they have been selling all along? You need to understand what big data is before you can tell whether a vendor’s BD offering is valuable or snake oil. Some vendors are (deliberately) sloppy, and their big data offerings may not actually be big data at all. They might offer a relational data store with a “Big Data” label stuck on, or a proprietary flat file data storage format without any of the features that make big data platforms powerful. Let’s start with Wikipedia’s Big Data page. Wikipedia’s definition (as of this writing) captures the principal challenges big data is intended to address: increased Volume (quantity of data), Velocity (rate of data accumulation), and Variety (different types of data) – also called the 3Vs. But Wikipedia fails to actually define big data. The term “big data” has been so overused, with so many incompatible definitions, that it has become meaningless. Essential Characteristics The current poster child for big data is Apache Hadoop, an open source platform based on Google BigTable. A Hadoop installation is built as a clustered set of commodity hardware, with each node providing storage and processing capabilities. Hadoop provides tools for data storage, data organization, query management, cluster management, and client management. It is helpful to think about the Hadoop framework as a ‘stack’ like the LAMP stack. These Hadoop components are normally grouped together but you can replace each component, or add new ones, as desired. Some clusters add optional data access services such as Sqoop and Hive. Lustre, GFS, and GPFS, can be swapped in as the storage layer. Or you can extend HDFS functionality with tools like Scribe. You can select or design a big data architecture specifically to support columnar, graph, document, XML, or multidimensional data. This modular approach enables customization and extension to satisfy specific customer needs. But that is still not a definition. And Hadoop is not the only player. Users might choose Cassandra, Couch, MongoDB, or RIAK instead – or investigate 120 or more alternatives. Each platform is different – focusing on its own particular computational problem area, replicating data across the cluster in its own way, with its own storage and query models, etc. One common thread is that every big data system is based on a ‘NoSQL’ (non-relational) database; they also embrace many non-relational technologies to improve scalability and performance. Unlike relational databases, which we define by their use of relational keys, table storage, and various other common traits, there is no such commonality among NoSQL platforms. Each layer of a big data environment may be radically different, so there is much less common functionality than we see between RDBMS. But we have seen this problem before – the term “Cloud Computing” used to be similarly meaningless, but we have come to grips with the many different cloud service and consumption models. We lacked a good definition until NIST defined cloud computing based on a series of essential characteristics. So we took a similar approach, defining big data as a framework of utilities and characteristics common to all NoSQL platforms. Very large data sets (Volume) Extremely fast insertion (Velocity) Multiple data types (Variety) Clustered deployments Provides complex data analysis capabilities (MapReduce or equivalent) Distributed and redundant data storage Distributed parallel processing Modular design Inexpensive Hardware agnostic Easy to use (relatively) Available (commercial or open source) Extensible – designers can augment or alter functions There are more essential characteristics to big data than just the 3Vs. Additional essential capabilities include data management, cost reduction, more extensive analytics than SQL, and customization (including a modular approach to orchestration, access, task management, and query processing). This broader collection of characteristics captures the big data value proposition, and offers a better understanding of what big data is and how it behaves. What does it look like? This is a typical big data cluster architecture; multiple nodes cooperate to manage data and process queries. A central node manages the cluster and client connections, and clients communicate directly with the name node and individual data nodes as necessary for query operations. This simplified shows the critical components, but a big data cluster could easily comprise 500 nodes hosting 30 applications. More nodes enable faster data insertion, and parallel query processing improves responsiveness substantially. 500 nodes should be overkill to support your SIEM installation, but big data can solve much larger problems than security analytics. Why Are Companies Adopting Big Data? Thinking of big data simply as a system that holds “a lot of data”, or even limiting its definition

It is starting to feel like summer. Both because the weather is getting warmer and because most of the Securosis team has been taking family time this week. I will keep the summary short – we have not been doing much writing and research this week. We talk a lot about security and compliance for cloud services. It has become a theme here that, while enterprises are comfortable with SaaS (such as Salesforce), they are less comfortable with PaaS (Dropbox & Evernote, etc.), and often refuse to touch IaaS (largely Amazon AWS) … for security and compliance reasons. Wider enterprise adoption has been stuck in the mud – largely because of compliance. Enterprises simply can’t get the controls and transparency they need to meet regulations, and they worry that service provider employees might steal their $#!%. The recent Bloomberg terminal spying scandal is a soft-core version of their nightmare scenario. As I was browsing through my feeds this week, it became clear that Amazon understands the compliance and security hurdles it needs to address, and that they are methodically removing them, one by one. The news of an HSM service a few weeks ago was very odd at first glance – it seems like the opposite of a cloud service: non-elastic, non-commodity, and not self-service. But it makes perfect sense for potential customers whose sticking point is a compliance requirement for HSM for key storage and/or generation. A couple weeks ago Amazon announced SOC compliance, adding transparency to their security and operational practices. They followed up with a post discussing Redshift’s new transparent encryption for compute nodes, so stolen disks and snapshots would be unreadable. Last week they announced FedRAMP certification, opening the door for many government organization to leverage Amazon cloud services – probably mostly community cloud. And taking a page from the Oracle playbook, Amazon now offers training and certification to help traditional IT folks close their cloud skills gap. Amazon is doing a superlative job of listening to (potential) customer impediments and working through them. By obtaining these certifications Amazon has made it much easier for customers to investigate what they are doing, and then negotiate a the complicated path to contract with Amazon while satisfying corporate requirements for security controls, logging, and reporting. Training raises IT’s comfort level with cloud services, and in many cases will shift detractors (IT personnel) into advocates. But I still have reservations about security. It’s great that Amazon is addressing critical problems for AWS customers and building these critical security and compliance technologies in-house. But this makes it very difficult for customers to select non-Amazon tools for key management, encryption, logging. Amazon is on their home turf, offering real useful services optimized for their offering, with good bundled pricing. But these solutions are not necessarily designed to make you ‘secure’. They may not even address your most pressing threats because they are focused on common federal and enterprise compliance concerns. These security capabilities are clearly targeted at compliance hurdles that have been slowing AWS adoption. Bundled security capabilities are not always the best ones to choose, and compliance capabilities have an unfortunate tendency to be just good enough to tick the box. That said, the AWS product managers are clearly on top of their game! On to the Summary: Webcasts, Podcasts, Outside Writing, and Conferences Adrian presenting next week on Tokenization vs. Encryption. Adrian’s Security Implications of Big Data. Favorite Securosis Posts Evernote Business Edition Doubles up on Authentication. Quick Wins with Website Protection Services: Deployment and Ongoing Management. Favorite Outside Posts Mike Rothman: Mandiant’s APT1: Revisited. Is the industry better off because Mandiant published the APT1 report? Nick Selby thinks so, and here are his reasons. I agree. Adrian Lane: Walmart Asked CA Shoppers For Zip Codes. Now It’s Ordered To Send Them Apology Giftcards. It’s a sleazy practice – cashiers act like the law requires shoppers to provide the zip codes, and are trained to stall if they don’t get it. The zip codes enable precise data analytics to identify shoppers. It’s good to see some merchant actually got penalized for this scam. Research Reports and Presentations Email-based Threat Intelligence: To Catch a Phish. Network-based Threat Intelligence: Searching for the Smoking Gun. Understanding and Selecting a Key Management Solution. Building an Early Warning System. Implementing and Managing Patch and Configuration Management. Defending Against Denial of Service (DoS) Attacks. Securing Big Data: Security Recommendations for Hadoop and NoSQL Environments. Tokenization vs. Encryption: Options for Compliance. Pragmatic Key Management for Data Encryption. The Endpoint Security Management Buyer’s Guide. Top News and Posts Paypal Site vulnerable to XSS. Via Threatpost. Two words: Dedicated. Browser. Sky hacked by the Syrian Electronic Army. Postgres Database security patch. Couple weeks old – we missed it – but a remote takeover issue. Anonymous Hacktivist Jeremy Hammond Pleads Guilty to Stratfor Attack. U.S. Government Seizes LibertyReserve.com. Why We Lie. Elcomsoft says Apple’s 2FA has holes. Blog Comment of the Week This week’s best comment goes to LonerVamp, in response to last week’s Friday Summary. As long as Google isn’t looking at biometrics, or other ways to uniquely identify me as a product of their advertising revenues, I’m interested in what they come up with. But just like their Google+ Real Names fiasco, I distrust anything they want to do to further identify me and make me valuable for further targeted advertising. Plus the grey market of sharing backend information with other (paying) parties. For instance, there are regulations to protect user privacy, but often the expectation of privacy is relaxed when it “appears” the a third party already knows you. For instance, if I have a set of data that includes mobile phone numbers (aka accounts) plus full real name of the owners, there can be some shady inferred trust that I am already intimate with you, and thus selling/sharing additional phone/device data with me is ok, as long as its done behind closed doors and neither of us talk about it. Tactics like that are how

This month Google announced a new five year plan for identity management, and update from 2008’s five year plan. Their look backward is as interesting as the revised roadmap. Google recognized their 2-factor auth was more like one-time 2-factor, and that the model has been largely abused in practice. They also concluded that risk-based authentication has worked. A risk-based approach means more sensitive or unusual operations, such as credential changes and connections from unusual locations, ratchet up security by activating additional authentication hurdles. This has been a recent trend, and Google’s success will convince other organizations to get on board. The new (2013-2018) identity plan is for a stricter 2-factor authentication scheme, a continuing push for OpenID, locking ‘bearer’ tokens to specific devices (to reduce the damage an attacker can cause with stolen tokens), and a form of Android app monitoring that alerts users to risky behavior. These are all very good things! Google did not explicitly state that passwords and password recovery schemes are broken, but it looks like they will promote biometrics such as face and fingerprint scanning to unlock devices and authenticate users. The shift away from passwords is a good thing, but what will replace them is still being hotly debated. From the roadmap Google is looking to facial and fingerprint scans first. This latter is a big deal from a outfit like Google because consumers have shown they largely don’t care about security. Despite more than a decade of hijacked accounts, data breaches, and identity theft, people still haven’t shifted from saying they care about security to actually adopting security. Even something as simple and effective as personal password managers is too much for most people to bother with. A handful of small companies offer biometric apps for mobile devices – targeting consumers and hoping Joe User will actually want to buy multi-factor authentication for his mobile device. So far that pitch has been about as successful as offering brussels sprouts to a toddler. But companies do care about mobile security. Demand for things like biometrics, NFC, risk-based access controls, and 2-factor authentication is all driven by enterprises. But if enterprises (including Google) drive advanced (non-password) authentication to maturity – meaning a point where it’s easier and more secure than our current broken password security – users will eventually use it too. Google has the scale and pervasiveness to push the needle on security. Initiatives such as their bug bounty program have succeeded, leading the way for other firms. If Google demonstrates similar successes with better identity systems, they are well positioned to drive both awareness and comfort with cloud-based identity solutions – in a way Courion, Okta, Ping Identity, Symplified, and other outfits cannot. There are many good technologies for identity and access management, but someone needs to make the user experience much easier before we can see widespread adoption. On to the Summary: Webcasts, Podcasts, Outside Writing, and Conferences Adrian’s DR post: Why Database Monitoring?. Favorite Securosis Posts David Mortman: (Scape)goats travel under the bus. Mike Rothman: Websense Goes Private. It’s been a while since we have had two deals in a week in security, and these were both driven by private equity money. Happy days are here again! Rich’s analysis of the first deal was good. Adrian Lane: Solera puts on a Blue Coat. Other Securosis Posts Making Browsers Hard Targets. Network-based Malware Detection 2.0: Evolving NBMD. Incite 5/22/2013: Picking Your Friends. Wendy Nather abandons the CISSP – good riddance. Spying on the Spies. Websense Going Private. Awareness training extends to the top. This botnet is no Pushdo-ver. A Friday Summary from Boulder: May 17, 2013. Quick Wins with Website Protection Services: Protecting the Website. Quick Wins with Website Protection Services: Are Websites Still the Path of Least Resistance? Favorite Outside Posts Dave Lewis: Woman Brags About Hitting Cyclist, Discovers Police Also Use Twitter. Wow… just, wow. David Mortman: Business is a Sport, You Need A Team. Mike Rothman: Mrs. Y’s Rules for Security Bloggers. Some folks out there think it’s easy to be a security blogger. It’s hard, actually. But with these 6 rules you too can be on your way to a career of pontification, coffee addiction, and a pretty okay lifestyle. But they are only for the brave. Adrian Lane: A Guide to Hardening Your Firefox Browser in OS X. Good post on securing Firefox from Stach and Liu. Research Reports and Presentations Email-based Threat Intelligence: To Catch a Phish. Network-based Threat Intelligence: Searching for the Smoking Gun. Understanding and Selecting a Key Management Solution. Building an Early Warning System. Implementing and Managing Patch and Configuration Management. Defending Against Denial of Service (DoS) Attacks. Securing Big Data: Security Recommendations for Hadoop and NoSQL Environments. Tokenization vs. Encryption: Options for Compliance. Pragmatic Key Management for Data Encryption. The Endpoint Security Management Buyer’s Guide. Top News and Posts Krebs, KrebsOnSecurity, As Malware Memes. Say what you will, but malware authors have a sense of humor. NC Fuel Distributor Hit by $800,000 Cyberheist. The Government Wants A Backdoor Into Your Online Communications. For everything they don’t already have a backdoor for. Hacks labelled hackers for finding security hole. Twitter: Getting started with login verification. Chinese hackers who breached Google gained access to sensitive data, U.S. officials say. Yahoo Japan Suspects 22 Million IDs Stolen. It’s like 2005 all over again. Skype’s ominous link checking: facts and speculation. Bromium: A virtualization technology to kill all malware, forever. Interesting technology. Indian companies at center of global cyber heist. Update on last week’s $45M theft. Blog Comment of the Week This week’s best comment goes to Simon Moffatt, in response to Wendy Nather abandons the CISSP – good riddance. CISSP is like any professional qualification. When entering a new industry with zero or limited experience, you need some method to prove competence. Organisations need to de-risk the recruitment process as much as possible when recruiting individuals they don’t know. It’s a decent qualification, just not enough on its own. Experience, like in any role is

The Washington Post says US Officials claimed Chinese hackers breached Google to determine who the US wanted Google to spy on. In essence the 2010 Aurora attack was a counter-counter-espionage effort to determine who the US government was monitoring. From the Post’s post: Chinese hackers who breached Google’s servers several years ago gained access to a sensitive database with years’ worth of information about U.S. surveillance targets, according to current and former government officials. The breach appears to have been aimed at unearthing the identities of Chinese intelligence operatives in the United States who may have been under surveillance by American law enforcement agencies. … and … Last month, a senior Microsoft official suggested that Chinese hackers had targeted the company’s servers about the same time Google’s system was compromised. The official said Microsoft concluded that whoever was behind the breach was seeking to identify accounts that had been tagged for surveillance by U.S. national security and law enforcement agencies. Wow. Like it or not, the US government ensnared US companies to spy on their customers and users. If the Chinese motivation is as claimed, Google was targeted because it was known to be collecting data on suspected spies. It will be interesting to see whether this announcement generates some pushback, either by companies refusing to cooperate, or – as many companies have done – by removing infrastructure that tracks specific users. Paining a target on your back and placing yourself in a situation where your servers could be seized is a risk most firms can’t afford. Share:

I have never been a fan of large gatherings of people. You would never find me at a giant convention center listening to some evangelist, motivational speaker, politician, or business ‘guru’ tell me how to improve my life. I don’t stalk celebrities; participate in “million man marches”, tea party gatherings, promise-keepers, or any something-a-palooza to support a cause. I don’t have a cult-like appreciation of ‘successful’ people. It has nothing to do with a political or religious bent and I don’t fear crowds – it is a personality trait. To me group-think is a danger signal. I’m a skeptic. A contrarian. If everyone’s doing it, it must be wrong. But it’s not like I never attend large events: AC/DC concerts are a go, and I’ll wait in long lines to get an iPhone. But it’s just as likely to bite you as be rewarding – you know, like the last Star Trek movie, the one with the terrible plot you’ve seen six times, because the cast and cinematography are oddly appealing. Anyway, when lots of people think something’s great I usually walk the other way. So what the heck was I doing at the Berkshire Hathaway Shareholders meeting last weekend? In Omaha, Nebraska, of all places? Forty thousand finance geeks standing in near-freezing rain, waiting for the doors to open at the CenturyLink center to hear Warren Buffett and Charlie Munger talk about stock performance? Are you kidding me? But there I was, with Gunnar Peterson, listening to the “Oracle of Omaha” talk about Berkshire Hathaway and investment philosophy. And it was a bit like a cult – a pilgrimage to listen to two of the greatest investors in history. But despite all my reservations I had a great time. You wouldn’t expect it from the topic but the meeting was entertaining. They were funny, insightful, and incredibly rational. They are politically incorrect and unapologetic about it. They are totally transparent, and as likely to remind you of their failures as successes. And they are more than happy to critique one another for their flaws (I’m certain I have seen these traits at another company before). As much as I have read about Munger and Buffett in the last 18 months – I think I read most of their funny quips before the meeting – there is something about hearing all of it in one place that weaves their concepts into a single cohesive tapestry of thought. You see the core set of values repeated consistently as they answer questions, no matter what the subject. If you are interested in a recap of the event, the Motley Fool blog did an excellent job of capturing the questions and some of the humor. I only started to follow Charlie and Warren about 18 months ago, because Gunnar’s use of sage Charlie Munger quotes got me curious. Now I am hooked, but not because I want investment ideas – instead I am fascinated by an incredibly simple investment philosophy, that involves an incredibly complex set of rational models, that forms the foundation of their decision process. Both men are contrarians – they choose to invest in a method that for decades people thought was a fluke. Berkshire has been called a 6-sigma outlier. They have been derided for not investing in tech companies during the tech boom – a profound critique when you consider Apple, Google, and Microsoft are some of the fastest-growing and 3 out of of 5 of the largest companies in the world. They have been mocked in the press as being “out of touch” when the market was going crazy during the whole mortgage/CDO fiasco. But they have stayed the course, despite fickle and fashionable trends, on their way to become the most successful investors in history. Berkshire is now one of the top 5 companies in the world, but ultimately their approach to decisions is what fascinates me. Had I heard about them during college, and comprehended their message as I do today, I would probably have gone into finance instead of computer science. Oh, before I forget, the majority of the Securosis team will be at Secure360 next week. Mort and I will be presenting on big data security. Ping us if you’re in Minneapolis/St. Paul and want to get together! On to the Summary: Webcasts, Podcasts, Outside Writing, and Conferences Adrian’s Security Implications of Big Data. Favorite Securosis Posts Rich: My “Peak Experience” article in The Magazine. I am really excited about this one, so even though it is technically an ‘Outside’ item I picked it as my favorite post. It’s the story of a mountain rescue I was on over a decade ago, for a really exciting publication, which I am honored to write for. David Mortman: The CISO’s Guide to Advanced Attackers: Evolving the Security Program. Mike Rothman: Some (re)assembly required. Need to show some love for our contributor Gal, who posted his first solo piece on the blog. He makes a great point about never forgetting the data security lifecycle. Adrian Lane: Finger-pointing is step 1 of the plan. Other Securosis Posts Database Breach Results in $45M Theft. Security Earnings Season in Full Swing. McAfee Gets Some NGFW Stones. Incite 5/8/2013: One step at a time. 2FA isn’t a big enough gun. Now China is stealing our porn. The CISO’s Guide to Advanced Attackers: Breaking the Kill Chain. Friday Summary: May 3, 2013. IaaS Encryption: How to Choose. IaaS Encryption: Object Storage. Favorite Outside Posts Rich: White House close to backing FBI’s wiretap backdoor proposal, says NYT. This is a short piece, but insanely important. Backdoors for wiretapping are horrible for security, with a long history of misuse and compromise. David Mortman: Google unveils 5-year roadmap for strong authentication. Mike Rothman: FUDwatch: Armenia. Marcus Ranum determines (with tongue firmly in cheek) that the biggest threat in the known world is… Armenia. Which just goes to show that you can make data say pretty much whatever you want it to. So interpret the breach reports and other data sources carefully, and figure out what you want them to say. Adrian Lane: The State of Web

Today’s big news is the hack against banking systems to pre-authenticate thousands of ATM and pre-paid debit cards. The attackers essentially modified debit card databases in several Middle Eastern banks, then leveraged their virtual cards into cash. From AP Newswire: Hackers got into bank databases, eliminated withdrawal limits on pre-paid debit cards and created access codes. Others loaded that data onto any plastic card with a magnetic stripe – an old hotel key card or an expired credit card worked fine as long as they carried the account data and correct access codes. A network of operatives then fanned out to rapidly withdraw money in multiple cities, authorities said. The cells would take a cut of the money, then launder it through expensive purchases or ship it wholesale to the global ringleaders. Lynch didn’t say where they were located. The targets were reserves held by the banks to fund pre-paid credit cards, not individual account holders, Lynch said … calling it a ”virtual criminal flash mob,”. The plundered ATMs were in Japan, Russia, Romania, Egypt, Colombia, Britain, Sri Lanka, Canada and several other countries, and law enforcement agencies from more than a dozen nations were involved in the investigation, U.S. prosecutors said It’s not clear how many of the thieves have been caught, or what percentage of the cash has been retrieved. Apparently this was the second attack, with the first successfully pulling $5 million from ATMs. Police only caught up with some of the attackers on the second attack, after they had managed to steal another $40M. How the thefts were detected is not clear, but it appears that it was part of a murder investigation of one of the suspects, and not fraud detection software within the banking system. The banks are eager to point to the use of mag stripe cards as the key issue here, but if your database is owned an attacker can direct funds to any account Share: