It’s long past the day we need to convince you that cloud and DevOps is a thing. We all know it’s happening, but one of the biggest questions we get is “Where do I start?” In this episode we scratch the surface of how to start approaching the problem when you don’t get to join a hot unicorn startup and build everything from scratch with an infinite budget behind you. Share:
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:
In our wanderings we’ve noticed that when we pull our heads out of the bubble, not everyone necessarily understands what cloud is or where it’s going. Heck, many smart IT people are still framing it within the context of what they currently do. It’s only natural, especially when they get crappy advice from clueless consultants, but it certainly can lead you down some ugly paths. This week Mike, Adrian and Rich are also joined by Dave Lewis (who accidentally sat down next to Rich at a conference) to talk about how people see cloud, the gaps, and how to navigate the waters. Share:
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:
After a short review of the RSA Security Conference, Rich, Mike, and Adrian debate the value of using labels like “Rugged DevOps” or “SecDevOps”. Rich sees them as different, Mike wonders if we really need them, and Adrian has been tracking their reception on the developer side of the house. Okay, it’s pathetic as smackdowns go, but you wouldn’t have read this far if we didn’t give it an interesting title. Share:
Every year we focus a lot on the RSA Conference. Love it or hate it, it is the biggest event in our industry. As we do every year we break down some of the improvements and disappointments we expect to see. Plus, we spend a few minutes talking about some of the big changes coming here at Securosis. We cover a possibly-insulting keynote, the improvements in the sessions, and how we personally use the event to improve our knowledge. Share:
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:
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:
Rich, Mike, and Adrian highlight the big trends from the year and where our expectations were right and wrong. We teeter on the brink of predictions, but manage to pull ourselves back from falling into that chasm of idiocy. Mostly. We cover a fair bit of ground, but the main trends are the weirdnesses on the investment and M&A side of the security industry, breaches, the faster than expected adoption of cloud computing, and the changing regulatory environment. This is likely our last Firestarter for the year, and our posting volume will be lower as we all cram in those last few projects. We sincerely want to thank everyone watching and reading for your continued support. It lets us try out best to “do good work” while feeding our families. We are a very lucky band over here. Share:
Get hacked? Blame China. Miss a quarter? Blame China. Serve malware to everyone visiting your site? Don’t take responsibility, just blame your anti-ad-blocking vendor. Or China. Or both. Look, we really can’t keep track of these things, but in this episode Mike and Rich talk about the lack of accountability in our industry (and other industries). One warning… a particular analogy goes a little too far. Maybe we need the explicit tag on this one. Share:
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:
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:
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.
