This week Mike and Rich address the recent spate of operational fails leading to massive security breaches. This isn’t yet another blame the victim rant, but a frank discussion of why these issues are so persistent and so difficult to actually manage. We also discuss the rising role of automation and its potential to reduce these all-too-human errors. Share:
Innovation comes and goes in security. Back in 2007 network security had been stagnant for more than a few years. It was the same old same old. Firewall does this. IPS does that. Web proxy does a third thing. None of them did their jobs particularly well, all struggling to keep up with attacks encapsulated in common protocols. Then the next generation firewall emerged, and it turned out that regardless of what it was called, it was more than a firewall. It was the evolution of the network security gateway. The same thing happened a few years ago in endpoint security. Mostly because they didn’t have any other options. Organizations were paying boatloads of money to maintain endpoint protection, because PCI-DSS required it. It certainly wasn’t because the software worked well. Inertia took root, and organizations continued to blindly renew their endpoint protection, mostly because they didn’t have any other options. Enterprises seem to have finally concluded that existing Endpoint Protection Platforms (EPP) don’t really protect endpoints sufficiently. We feel that epiphany is better late than never. But we suspect the catalyst for this realization was that the new generation of tools simply does a better job. The Endpoint Advanced Protection (EAP) concept entails integration of many capabilities previously only offered separately, including endpoint hygiene to reduce attack surface, prevention of advanced attacks including memory attacks and malware-less approaches, and much more granular collection and analysis of endpoint telemetry (‘EDR’ technology). This paper discusses EAP and the evolution of the technologies are poised to help protect endpoints from consistently innovating adversaries. We’d like to thank Check Point Software Technologies for licensing the content. We are able to offer objective research built in a Totally Transparent manner because our clients see the benefit of educating the industry. You can download the paper (PDF). Share:
Can you really ‘manage’ threats? Is that even a worthwhile goal? And how do you even define a threat? We have seen better descriptions of how adversaries operate by abstracting multiple attacks/threats into a campaign, capturing a set of interrelated attacks with a common mission. A campaign is a better way to think about how you are being attacked than the piecemeal approach of treating every attack as an independent event and defaulting to the traditional threat management cycle: Prevent (good luck!), Detect, Investigate, and Remediate. Clearly this approach hasn’t worked out well. The industry continues to be largely locked into this negative feedback loop: you are attacked, you respond, you clean up the mess, and you start all over again. We need a different answer. We need to think about Threat Operations. We are talking about evolving how the industry deals with threats. It’s not just about managing threats any more. We need to build operational process to more effectively handle hostile campaigns. That requires leveraging security data through better analytics, magnifying the impact of the people we have by structuring and streamlining processes, and automating threat remediation wherever possible. We’d like to thank Threat Quotient for licensing this content. We are grateful that security companies like ThreatQ and many others appreciate the need to educate their customers and prospects with objective material built in a Totally Transparent manner. This enables us to do impactful research and protects our integrity. You can download the paper (PDF). Share:
We are proud to announce the launch of our newest research paper, on multi-cloud key management, covering how to tackle data security and compliance issues in diverse cloud computing environments. Infrastructure as a Service entails handing over ownership and operational control of IT infrastructure to a third party. But responsibility for data security cannot go along with it. Your provider ensures compute, storage, and networking components are secure from external attackers and other tenants, but you must protect your data and application access to it. Some of you trust your cloud providers, while others do not. Or you might trust one cloud service but not others. Regardless, to maintain control of your data you must engineer cloud security controls to ensure compliance with internal security requirements, as well as regulatory and contractual obligations. That means you need to control the elements of the cloud that related to data access and security, to avoid any possibility of your cloud vendor(s) viewing it. Encryption is the fundamental security technology in modern computing, so it should be no surprise that encryption technologies are everywhere in cloud computing. The vast majority of cloud service providers enable network (transport) encryption by default and offer encryption for data at rest to protect files and archives from unwanted inspection by authorized infrastructure personnel. But the principal concern is who has access to encryption keys, and whether clouds vendor can decrypt your data without you knowing about it. So many firms insist on brining their own keys into the cloud, not allowing their cloud vendors access to their keys. And, of course, many organizations ask how they can provide consistent protection, regardless of which cloud services they select? So this research is focused on these use cases. We hope you find this research useful. And we would like to thank Thales eSecurity for licensing this paper for use with their customer outreach and education programs. Like us, they receive an increasing number of customer inquiries regarding cloud key management. Support like this enables us to bring you objective material built in a Totally Transparent manner. This allows us to perform impactful research and protect our integrity. You can download the paper. Share:
Migrating Hana and other SAP applications to a cloud environments is a complicated process, even with the tools and services SAP provides. For many organizations security was primary barrier to adoption. But SAP and other cloud service vendors have closed many security gaps, so now we can trust that the environment and applications are at least as secure as an on-premise installation – provided you leverage appropriate security models for the cloud. But that’s where we often see a breakdown: enterprises are not taking sufficient advantage of cloud security. Additionally, because there is no single model for SAP cloud security, transitioning other business applications to the cloud often results in greater cost, less scalability, and decreased security. From the paper: “Proper implementation is tricky – if you simply ‘lift and shift’ your old model into the cloud, we know from experience that it will be less secure and cost more to operate. To realize the advantages of the cloud you need to leverage its new features and capabilities – which demands a degree of reengineering for architecture, security program, and process,” said Adrian Lane, Analyst and CTO, Securosis. “We have been receiving an increasing number of questions on SAP cloud security, so this research paper is intended to tackle major security issues for SAP cloud deployments. When we originally scoped this research project we were going to focus on the top five questions people had, and quickly realized that grossly under-served the audience needs for a more comprehensive security plan,” continued Lane. “Securing SAP Clouds” covers the division of responsibility between an organization and the cloud vendor, which tools and approaches are viable, changes to the security model and advice for putting together a cloud security program for SAP. We are very happy to announce that Onapsis is licensing this research to help educate customers and Hana users. We thank them for their support, and for their ongoing security research! Download a copy of the paper here Share:
Given the challenges in detecting attackers, clearly existing approaches to threat detection aren’t working well enough. As such, innovative companies are bringing new products to market to address the perceived issues with existing technologies. These security analytics offerings basically use better math to detect attackers, leveraging techniques that didn’t exist when existing tools hit the market 10 years ago. The industry’s marketing machinery is making these new analytics tools akin to the Holy Grail, but per usual the hype far outstrips the reality. Security analytics is not a replacement for SIEM — at least today. For some time you will need both technologies. The role of a security architect is basically to assemble a set of technologies to generate actionable alerts on specific threat vectors relevant to the business, investigate attacks in process and after the fact, and generate compliance reports to streamline audits. These technologies compete to a degree, so we like the analogy of a Team of Rivals working together to meet requirements. This paper focuses on how to align your security monitoring technologies with new security analytics alternatives to better identify attacks, which we can all agree is sorely needed. We’d like to thank McAfee for licensing the content. We are grateful security companies like McAfee and many others appreciate the need to educate their customers and prospects with objective material built in a Totally Transparent manner. This allows us to do impactful research, and protect our integrity. You can download the paper (PDF) Attachments Securosis_SATeamofRivals_FINAL.pdf [648KB] Share:
Our paper, Assembling a Container Security Program, covers a broad range of topics around how to securely build, manage, and deploy containers. During our research we learned that issues often arise early in the software development or container assembly portion of the build process, so we cover much more than merely runtime security – the focus of most container security research. We also discovered that operations teams struggle with getting control over containers, so we also cover a number of questions regarding monitoring, auditing, and management. To give you a flavor for the content, we cover the following: IT and Security teams lack visibility into containers and have trouble validating them – both before placing them into production, and when running in production. Their peers on the development team are often disinterested in security, and cannot be bothered to provide reports and metrics. This is essentially the same problem we have for application security in general: the people responsible for the code are not incentivized to make security their problem, and the people who need to know what’s going on lack visibility. Containers are scaring the hell out of security pros because of their lack of transparency. The burden of securing containers falls across Development, Operations, and Security teams – but these groups are not always certain how to tackle the issues. This research is intended to aid security practitioners, developers, and IT operations teams in selecting container security tools and approaches. We will not go into great detail on how to secure apps in general here – we are limiting ourselves to build, container management, deployment, platform, and runtime security issues that arise with the use of containers. We will focus on Docker as the dominant container model, but the vast majority of our security recommendations also apply to Cloud Foundry, Rocket, Google Pods, and the like. If you worry about container security this is a good primer on all aspects of how code is built, bundled, containerized, and deployed. We would like to thank Aqua Security for licensing this research and participating in some of our initial discussions. As always, we welcome comments and suggestions. If you have questions, please feel free to email us, info at securosis.com. Download a copy of the paper here Share:
We talk frequently about the importance of having the right people and processes to make security effective. This is definitely true for Web Application Firewalls (WAF), a fairly mature technology which has been fighting perception issues for years. This quote from the paper nets it out: Our research shows that WAF failures result far more often from operational failure than from fundamental product flaws. Make no mistake — WAF is not a silver bullet — but a correctly deployed WAF makes it much harder to successfully attack an application, and for attackers to avoid detection. The effectiveness of WAF is directly related to the quality of people and processes maintaining them. The most serious problems with WAF are with management and operational processes, rather than the technology. Our Maximizing WAF Value paper discusses the continuing need for Web Application Firewall technologies, and address the ongoing struggles to run WAF. We also focus on decreasing time to value for WAF, with updated recommendations for standing up a WAF for the first time, what it takes to get a basic set of policies up and running, and new capabilities and challenges facing customers. We would like to thank Akamai for licensing the content in this paper. As always, we performed the research using our Totally Transparent Research methodology. You can download the paper (PDF). Share:
Nobody really argues any more about whether to perform security monitoring. Compliance mandates answered that question, and the fact is that without granular security monitoring and analytics you don’t have much chance to detect attacks. But there is an open question about the best way to monitor your environment, especially given the headwinds facing your security team. Given the challenges of finding and retaining staff, the increasingly distributed nature of data and systems that need to be monitored, and the rapid march of technology, it’s worth considering whether a managed security monitoring service makes sense for your organization. Under the right circumstances a managed service presents an interesting alternative to racking and stacking another set of SIEM appliances. This paper covers the drivers for managed security monitoring, the use cases where a service provider can offer the most value, and some guidance on how to actually select a service provider. It’s a comprehensive look at what it takes to select a security monitoring service. We’d like to thank IBM Security, who licensed this content and enables us to provide it to you for, well, nothing. The paper was built using our Totally Transparent Research methodology, to make sure we are writing what needs to be written rather than what someone else wants us to say. You can download the paper (PDF). 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.
