Security Analytics Team of Rivals: Introduction [New Series]

Security monitoring has been a foundational element of most every security program for over a decade. The initial driver for separate security monitoring infrastructure was the overwhelming amount of alerts flooding out of intrusion detection devices, which required some level of correlation to determine which mattered. Soon after, compliance mandates (primarily PCI-DSS) emerged as a forcing function, providing a clear requirement for log aggregation – which SIEM already did. As the primary security monitoring technology, SIEM became entrenched for alert reduction and compliance reporting. But everything changes, and the requirements for security monitoring have evolved. Attacks have become much more sophisticated, and detection now require a level of advanced analysis that is difficult to accomplish using older technologies. So a new category of technologies dubbed Security Analytics emerged to fill the need to address very specific use cases requiring advanced analysis – including user behavior analysis, tackling insider threats, and network-based malware detection. These products and services are all based on sophisticated analysis of aggregated security data, using “big data” technologies which did not exist when SIEMs initially appeared in the early 2000s. This age-old cycle should be familiar: existing technologies no longer fit the bill as requirements evolve, so new companies launch to fill the gap. But enterprises have seen this movie before, including new entrants’ inflated claims to address all the failings of last-generation technology, with little proof but high prices. To avoid the disappointment that always follows throwing the whole budget at an unproven technology, we recommend organizations ask a few questions: Can you meet this need with existing technology? Do these new offerings definitively solve the problem in a sustainable way? At what point does the new supplant the old? Of course the future of security monitoring (and everything else) is cloudy, so we do not have all the answers today. But you can understand how security analytics works, why it’s different (and possibly better), whether it can help you, where in your security program the technology can provide value, and how long. Then you will be able to answer questions. But you should be clear that security analytics is not a replacement for your SIEM – at least today. For some period of time you will need to support both technologies. The role of a security architect is basically to assemble a Team of Security Analytics Rivals to generate actionable alerts on specific threat vectors relevant to the business, investigate attacks in process and after the fact, and also to generate compliance reports to streamline audits. It gets better: many current security analytics offerings were built and optimized for a single use case. The Team of Rivals is doubly appropriate for organizations facing multiple threats from multiple actors, who understand the importance of detecting attacks sooner and responding better. As was said in Contact, “Why buy one, when you can buy two for twice the cost?” Three or four have to be even better than two, right? We are pleased that Intel Security has agreed to be the initial licensee of our Security Analytics Team of Rivals paper, the end result of this series. We strongly appreciate forward-looking companies in the security industry who invest in objective research to educate their constituents about where security is going, instead of just focusing on where it’s been. On Security Analytics As we start this series, we need to clarify our position on security analytics. It’s not a thing you can buy. Not for a long while, anyway. Security analytics is a way you can accomplish something important: detect attacks in your environment. But it’s not an independent product category. That doesn’t mean Analytics will necessarily become subsumed into an existing SIEM technology or other security monitoring product/service stack, although that’s one possibility. We can easily show why these emerging analytics platforms should become the next-generation SIEM. Our point is that the Team of Rivals is not a long-term solution. At some point organizations need to simplify the environment, and consolidate vendors and technologies. They will pick a security monitoring platform, but we are not taking bets which will win. Thus the need for a Team of Rivals. But having a combined and integrated solution someday won’t help you detect attackers in your environment right now. So let’s define what we mean by security analytics first, and then focus on how these technologies work together to meet today’s requirements, with an eye on the future. In order to call itself a security analytics offering, a product or service must provide: Data Aggregation: It’s impossible to produce analysis without data. Of course there is some question of whether the security analytics tool needs to gather its own data, or can just integrate with an existing security data repository, like your SIEM. Math: We joke a lot that math is the hottest thing in security lately, especially given how early SIEM correlation and IDS analysis were based on math, too. But the new math is different, based on advanced algorithms and data management to find patterns within data volumes which were unimaginable 15 years ago. The key difference is that you no longer need to know what you are looking for to find useful patterns. Modern algorithms can help you spot unknown unknowns. Looking for known profiled attacks is now clearly a failed strategy. Alerts: These are the main output of security analytics, and you will want them prioritized by importance to your business. Drill down: Once an alert fires, analysts will need to dig into the details, both for validation and to determine the most appropriate response. So the tools must be able to drill down and provide additional detail to assist in response. Learn: This is the tuning process, and any offering needs a strong feedback loop between responders and the folks running the tool. You must refine analytics to minimize false positives and wasted time. Evolve: Finally the tool must evolve, because adversaries are not static. This requires a threat intelligence research team at your security analytics

Read Post

Totally Transparent Research is the embodiment of how we work at Securosis. It’s our core operating philosophy, our research policy, and a specific process. We initially developed it to help maintain objectivity while producing licensed research, but its benefits extend to all aspects of our business.

Going beyond Open Source Research, and a far cry from the traditional syndicated research model, we think it’s the best way to produce independent, objective, quality research.

Here’s how it works:

  • Content is developed ‘live’ on the blog. Primary research is generally released in pieces, as a series of posts, so we can digest and integrate feedback, making the end results much stronger than traditional “ivory tower” research.
  • Comments are enabled for posts. All comments are kept except for spam, personal insults of a clearly inflammatory nature, and completely off-topic content that distracts from the discussion. We welcome comments critical of the work, even if somewhat insulting to the authors. Really.
  • Anyone can comment, and no registration is required. Vendors or consultants with a relevant product or offering must properly identify themselves. While their comments won’t be deleted, the writer/moderator will “call out”, identify, and possibly ridicule vendors who fail to do so.
  • Vendors considering licensing the content are welcome to provide feedback, but it must be posted in the comments - just like everyone else. There is no back channel influence on the research findings or posts.
    Analysts must reply to comments and defend the research position, or agree to modify the content.
  • At the end of the post series, the analyst compiles the posts into a paper, presentation, or other delivery vehicle. Public comments/input factors into the research, where appropriate.
  • If the research is distributed as a paper, significant commenters/contributors are acknowledged in the opening of the report. If they did not post their real names, handles used for comments are listed. Commenters do not retain any rights to the report, but their contributions will be recognized.
  • All primary research will be released under a Creative Commons license. The current license is Non-Commercial, Attribution. The analyst, at their discretion, may add a Derivative Works or Share Alike condition.
  • Securosis primary research does not discuss specific vendors or specific products/offerings, unless used to provide context, contrast or to make a point (which is very very rare).
    Although quotes from published primary research (and published primary research only) may be used in press releases, said quotes may never mention a specific vendor, even if the vendor is mentioned in the source report. Securosis must approve any quote to appear in any vendor marketing collateral.
  • Final primary research will be posted on the blog with open comments.
  • Research will be updated periodically to reflect market realities, based on the discretion of the primary analyst. Updated research will be dated and given a version number.
    For research that cannot be developed using this model, such as complex principles or models that are unsuited for a series of blog posts, the content will be chunked up and posted at or before release of the paper to solicit public feedback, and provide an open venue for comments and criticisms.
  • In rare cases Securosis may write papers outside of the primary research agenda, but only if the end result can be non-biased and valuable to the user community to supplement industry-wide efforts or advances. A “Radically Transparent Research” process will be followed in developing these papers, where absolutely all materials are public at all stages of development, including communications (email, call notes).
    Only the free primary research released on our site can be licensed. We will not accept licensing fees on research we charge users to access.
  • All licensed research will be clearly labeled with the licensees. No licensed research will be released without indicating the sources of licensing fees. Again, there will be no back channel influence. We’re open and transparent about our revenue sources.

In essence, we develop all of our research out in the open, and not only seek public comments, but keep those comments indefinitely as a record of the research creation process. If you believe we are biased or not doing our homework, you can call us out on it and it will be there in the record. Our philosophy involves cracking open the research process, and using our readers to eliminate bias and enhance the quality of the work.

On the back end, here’s how we handle this approach with licensees:

  • Licensees may propose paper topics. The topic may be accepted if it is consistent with the Securosis research agenda and goals, but only if it can be covered without bias and will be valuable to the end user community.
  • Analysts produce research according to their own research agendas, and may offer licensing under the same objectivity requirements.
  • The potential licensee will be provided an outline of our research positions and the potential research product so they can determine if it is likely to meet their objectives.
  • Once the licensee agrees, development of the primary research content begins, following the Totally Transparent Research process as outlined above. At this point, there is no money exchanged.
  • Upon completion of the paper, the licensee will receive a release candidate to determine whether the final result still meets their needs.
  • If the content does not meet their needs, the licensee is not required to pay, and the research will be released without licensing or with alternate licensees.
  • Licensees may host and reuse the content for the length of the license (typically one year). This includes placing the content behind a registration process, posting on white paper networks, or translation into other languages. The research will always be hosted at Securosis for free without registration.

Here is the language we currently place in our research project agreements:

Content will be created independently of LICENSEE with no obligations for payment. Once content is complete, LICENSEE will have a 3 day review period to determine if the content meets corporate objectives. If the content is unsuitable, LICENSEE will not be obligated for any payment and Securosis is free to distribute the whitepaper without branding or with alternate licensees, and will not complete any associated webcasts for the declining LICENSEE. Content licensing, webcasts and payment are contingent on the content being acceptable to LICENSEE. This maintains objectivity while limiting the risk to LICENSEE. Securosis maintains all rights to the content and to include Securosis branding in addition to any licensee branding.

Even this process itself is open to criticism. If you have questions or comments, you can email us or comment on the blog.