Securosis

Research

Building Resilient Cloud Network Architectures

New technologies scare some people. And the cloud is scaring lots of people. They worry about how data resides within networks they don’t control. They worry that attackers could compromise a multi-tenant environment. They worry they don’t have the tools or techniques to provide equivalent security to what they already have in their traditional data centers. It turns out they don’t really need to worry. But for those ready, willing, and able to step forward into the future today, the cloud is waiting to break the traditional rules of how technology has been developed, deployed, scaled, and managed. Building Resilient Cloud Network Architectures builds on our Pragmatic Security Cloud and Hybrid Networks research, focusing on cloud-native network architectures that provide security and availability infeasible in a traditional data center. The key is that cloud computing provides architectural options which are either impossible or economically infeasible in traditional data centers, enabling greater protection and better availability. We would like to thank Resilient Systems, an IBM Company, for licensing the content in this paper. We built the paper using our Totally Transparent Research model, leveraging what we’ve learned building cloud applications over the past 4 years. Download: Building Resilient Cloud Network Architectures Share:

Share:
Read Post

Building a Vendor (IT) Risk Management Program

In this business environment, where more output is expected faster, while consuming fewer resources, organizations have little choice but to embrace outsourcing and other means of becoming more efficient while maintaining productivity. Interconnecting business technology systems accelerates inter-enterprise collaboration, but there are clear risks to providing access to external parties. The post-mortem on a few recent high-profile data breaches indicated the adversaries first entered the victim’s network not through their own systems, but instead through a trusted connection with a third-party vendor. Basically the attacker targeted and then owned a small service provider, and used that connection to gain a foothold within the real target’s environment. The path of least resistance into your environment may no longer be through your front door. It might be through a back door (or window) you left open for a trading partner. In our Building a Vendor (IT) Risk Management Program paper, we explain why you can no longer ignore the risk presented by third-party vendors and other business partners, including managing an expanded attack surface and new regulations demanding effective management of vendor risk. We then offer ideas for how to build a structured and systematic program to assess vendor (IT) risk and take action when necessary. We would like to thank BitSight Technologies for licensing the content in this paper. Our unique Totally Transparent Research model allows us to perform objective and useful research without requiring paywalls or other such nonsense, which make it hard for the people who need our research to get it. A day doesn’t go by where we aren’t thankful to all the companies who license our research. Download: Building a Vendor (IT) Risk Management Program (PDF) Share:

Share:
Read Post

SIEM Kung Fu

Despite having published a bunch of research over the years about SIEM, it’s still a very misunderstood and under utilized technology. Lots of organizations aggregate their logs (you can thank PCI-DSS for that), but not enough actually use their SIEM effectively. And it’s not like you can just look at some other shiny technology to replace the SIEM: Security monitoring needs to be a core, fundamental, aspect of every security program. SIEM — in various flavors, using different technologies and deployment architectures — is how you do security monitoring. So it’s not about getting rid of the technology — it’s a question of how to get the most out of existing investments, and ensure you can handle modern advanced threats. In the SIEM Kung Fu paper, we tell you what you need to know to get the most out of your SIEM, and solve the problems you face today by increasing your capabilities (the promised Kung Fu). We would like to thank Intel Security for licensing the content in this paper. Our unique Totally Transparent Research model allows us to do objective and useful research and still pay our bills, so we’re thankful to all of the companies that license our research. Download: SIEM Kung Fu (PDF) Share:

Share:
Read Post

Securing Hadoop: Recommendations for Hadoop Security

Securing_Hadoop_Final_V2.pdfBig data systems have become very popular because they offer a low-cost way to analyze enormous sets of rapidly changing data. But Hadoop, with its incredibly open and vibrant ecosystem, has enabled firms to completely tailor clusters to their business needs. This combination has made Hadoop the most popular big data framework in use today. And as adoption has ramped up, IT and security teams have found themselves tasked with getting a handle on data – and Hadoop cluster – security. We released first our first security recommendations in 2012, just before the release of YARN. Since then the Hadoop security landscape has changed radically. Today a comprehensive set of technologies is available. This research paper delves into the fundamental security controls for Hadoop including encryption, isolation, and access controls/identity management. We start by examining the types of problems most firms need to address, matching them against available security tools. From there we branch out into two major areas of concern: high-level architectural considerations and tactical operational options, exploring decision process you need to go through to determine which problems you need to address. We close with a strategic framework for deploying tactical controls into a cohesive security strategy, with key recommendations for keeping Hadoop infrastructure and data secure. As with all our research papers, we welcome feedback and community participation. If you have comments or you want to see additions, please email us at info at Securosis dot com, or post a comment on this blog. This way we can foster an open dialog with the community. Finally, we would like to thank the companies which have licensed this research and helped us make it available to you free: Hortonworks and Vormetric. Download the research here: Securing_Hadoop_Final_V2.pdf. Share:

Share:
Read Post

Building Security Into DevOps

We are excited about this research paper, because we are excited about what the DevOps approach has delivered to many organizations, both small and large, already. And even firms who have only recently started down the path toward a full DevOps process already enjoy the advantages of streamlined testing and build processing with continuous integration. Our focus for this research was on how to embed security and security testing into DevOps, leveraging automated workflows to implement security testing, and providing fast feedback to developers when something is amiss. We offer a basic overview of DevOps, followed by several perspectives on how security folks and developers can work together to engineer security into a DevOps pipeline. From the paper: Some folks who suggest moving to DevOps meet internal resistance, fresh off the failures to implement Agile processes. When development teams of the past decade tried to go ‘Agile’ they often ran smack into the other groups within their own firms who remained steadfastly un-Agile. This resulted in more of the same in inter-group friction and further compounded communication and organizational issues. This dysfunction can have a paralytic effect, dropping productivity to nil. Most people are so entrenched in traditional software development approaches that it’s hard to see development ever getting better. And when firms who have adopted DevOps talk about deploying code every day instead of every year, or being fully patched within hours, or detection and recovery from a bug within minutes, most developers scoff at these notion as pure utopian fantasy. That is, until they see DevOps in action – then their jaws drop. We know plenty of you are already tired of hearing the term ‘DevOps’, and think this is just the newest overhyped flavor of Agile. Heck, even one of our associate analysts has scoffed at the claim that DevOps will have a pronounced effect on development and operations. But you don’t need to look far to see incredible success stories. When it comes down to it, DevOps is merely a way to reduce friction and leverage the full potential of your infrastructure. You can – and we know some organizations have and will – screw it up. But part of the beauty of this approach is that you quickly learn from mistakes – you can back them out and continue move forward. And it’s not magic fairy dust – it requires a radical change in organization, months of hard work to automate basic daily chores, and years to mature the pipeline. The benefits are not felt overnight – you only make small improvements on any given day, but they snowball over time. Especially paired with cloud computing, which provides granular API-level control over infrastructure, DevOps enables dramatic improvement. Our thanks to Veracode for licensing this content so we can bring it to you free of charge! Here is the paper: Building Security Into DevOps (PDF). Share:

Share:
Read Post

Threat Detection Evolution

Most organizations have realized that threat prevention has limitations, so we have seen renewed focus on threat detection. But like most other security markets, the term threat detection has been distorted to cover almost everything. So we figure it’s time to clarify what threat detection is and how it is evolving to deal with advanced attacks, sophisticated adversaries, and limited resources. Not to worry – we haven’t become the latest security Chicken Little, warning everyone that the sky is falling. Mostly because it fell a long time ago, and we have been picking up the pieces ever since. It can be exhausting to chase alert after alert, never really knowing which are false positives and which indicate real active adversaries in your environment. Something has to change. We need to advance the practice of detection, to provide better and more actionable alerts. This requires thinking more broadly about detection, and starting to integrate the various different security monitoring systems in use today. Our Threat Detection Evolution paper starts by reviewing security data collection, including both internal and external data sources that can facilitate detection efforts. Next we discuss how to use that data ti reliably figure out what is an attack. We wrap up by going through th process, using a quick wins scenario to show the concepts in action. We would like to thank AlienVault for licensing the content in this paper. Our unique Totally Transparent Research model allows us to do objective and useful research and still make ends meet, so you should thank them too. Download: Threat Detection Evolution (PDF) Share:

Share:
Read Post

Pragmatic Security for Cloud and Hybrid Networks

One of the bigger issues when migrating to the cloud is translating and extending your existing security controls, especially our old friend, network security. While cloud networking may resemble what we are used to, under the covers it behaves, and is managed, very differently. Over the last few decades we have been refining our approach to network security. Find the boxes, find the wires connecting them, drop a few security boxes between them in the right spots, and move on. Sure, we continue to advance the state of the art in exactly what those security boxes do, and we constantly improve how we design networks and plug everything together, but overall change has been incremental. How we think about network security doesn’t change – just some of the particulars. Until you move to the cloud. While many of the fundamentals still apply, cloud computing releases us from the physical limitations of those boxes and wires by fully abstracting the network from the underlying resources. We move into entirely virtual networks, controlled by software and APIs, with very different rules. Things may look the same on the surface, but dig a little deeper and you quickly realize that network security for cloud computing requires a different mindset, different tools, and new fundamentals. Many of which change every time you switch cloud providers. This report walks you through these differences, and includes specific examples from major cloud providers to show you what it looks like in the real world. Our thanks to Algosec for licensing the research so we can offer it for free. Pragmatic Security for Cloud and Hybrid Networks (pdf) Share:

Share:
Read Post

EMV Migration and the Changing Payments Landscape

October 2015 is the deadline for merchants to adopt EMV-compliant credit card terminals, in exchange for a liability waiver for fraudulent card present transactions. Explaining the EMV shift and payment security is difficult – there is a great deal of confusion about what the shift means, what security it really delivers, and whether it actually offers real benefits for merchants. Part of the problem is that the card brands have chosen to focus all their marketing on a single oversimplified value statement: the liability shift for card present transactions through non-EMV-compliant terminals. But digging into the specifications and working through the rollout process reveals a much larger change underway, with much broader ramifications. Unfortunately the press has failed to realize these implications, so the conversation has focused on liability, and lost sight of what else is going on. We produced this research paper to explain the additional changes underlying the EMV shift, its full impact on merchant security and operations, and where the shift will take the payment ecosystem. The real story is both simpler and more interesting than its coverage to date. Download here Ultimately every paper we write at Securosis has the same core goal: to help security practitioners get their jobs done. It’s what we do. This paper is mostly for those at merchant sites struggling with the rollout and issues it creates. At the end of the paper we offer recommendations for practitioners of EMV and mobile payment; including whether they should adopt EMV terminals and practical considerations to protect themselves from new attack vectors if they do. As always, if you have questions or additional material to add, feel free to post a comment. EMV and the Changing Payment Landscape: download here. Share:

Share:
Read Post

Network-based Threat Detection

The more things change, the more they stay the same. We have been talking about Reacting Faster and Better for years and we will continue to do so, because trying to prevent every attack is and will remain futile. The best path forward is to continue advancing the ability to prevent attacks, while spending as much time on detecting attacks that successfully compromise your defenses. This detection-centric view of the world has been a central theme in our research; it highlights a variety of areas to focus on – including the network, endpoints, and applications. We know many organizations have already spent a bunch of money on detection – particularly intrusion detection, its big brother intrusion prevention, and SIEM. But these techniques haven’t worked effectively either, so now is time to approach the issue with fresh eyes. By taking a new forward look at detection, not from the standpoint of what we have already done and implemented (IDS and SIEM), but instead in terms of what we need to do to isolate and identify adversary activity, we will be able to look at the kinds of technologies needed right now to deal with modern attacks. Times have changed and attackers have advanced, so our detection techniques need to evolve as well. In our Network-based Threat Detection paper, we focus on what kinds of indicators make the most sense to look for on the network, how to prioritize what you find, and then steps to operationalize the process to make detection consistent and reliable. We would like to thank our licensees (in alphabetical order), Damballa, Niara, and Vectra Networks. Our unique licensing model enables us to perform impactful and objective research and still pay our bills, so please thank them too. Download: Network-based Threat Detection (PDF) Share:

Share:
Read Post

Applied Threat Intelligence

Threat Intelligence remains one of the hottest areas in security. With its promise to help organizations take advantage of information sharing, early results have been encouraging. We have researched Threat Intelligence deeply; focusing on where to get TI and the differences between gathering data from networks, endpoints, and general Internet sources. But we come back to the fact that having data is not enough – not now and not in the future. It is easy to buy data but hard to take full advantage of it. Knowing what attacks may be coming at you doesn’t help if your security operations functions cannot detect the patterns, block the attacks, or use the data to investigate possible compromise. Without those capabilities it’s all just more useless data, and you already have plenty of that. Our Applied Threat Intelligence paper focuses on how to actually use intelligence to solve three common use cases: preventative controls, security monitoring, and incident response. We start with a discussion of what TI is and isn’t, where to get it, and what you need to deal with specific adversaries. Then we dive into use cases. We would like to thank Intel Security for licensing the content in this paper. Our licensees enable us to provide our research at no cost and still pay our mortgages, so we should all thank them. Download: Applied Threat Intelligence (PDF) Share:

Share:
Read Post
dinosaur-sidebar

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.