Research

A few months back I did a series of posts on how to leverage Amazon EC2, APIs, Chef, and Ruby to improve security over what you can do with traditional infrastructure. I decided to collect these posts together, clean them up, and release them as a standalone paper. Hopefully you find this interesting. I consider this the future of our industry. A Practical Example of Software Defined Security (PDF) Attachments SDS-Practical-Example.pdf [239KB] Share:

Continuous Monitoring has become an overused and overhyped term in security circles, driven by US Government mandate (now called Continuous Diagnostics and Mitigation). But that doesn’t change the fact that monitoring needs to be a cornerstone of your security program, within the context of a risk-based paradigm. So your pals at Securosis did their best to document how you should think about Continuous Security Monitoring and how to get there. Given that you can’t prevent all attacks, you need to ensure you detect attacks as quickly as possible. The concept of continuous monitoring has been gaining momentum, driven by both compliance mandates (notably PCI-DSS) and the US Federal Government’s guidance on Continuous Diagnostics and Mitigation, as a means to move beyond periodic assessment. This makes sense given the speed that attacks can proliferate within your environment. In this paper, Securosis will help you assemble a toolkit (including both technology and process) to implement our definition of Continuous Security Monitoring (CSM) to monitor your information assets to meet a variety of needs in your organization. We discuss what CSM is, how to do it, and the most applicable use cases we have seen in the real world. We end with a step-by-step list of things to do for each use case to make sure your heads don’t explode trying to move forward with a monitoring initiative. We are indebted to all our licensees for supporting our research and broadening our reach, including Qualys, Tenable Network Security, and Tripwire. We don’t expect you to rebalance security spending between protection and detection overnight, but by systematically moving forward with security monitoring and implementing additional use cases over time, you can balance the scales and give yourself a fighting chance to figure out you have been owned – before it’s too late. Download: Continuous Security Monitoring (PDF) Share:

API gateways are an emerging hot spot in IT services. They offer platforms for companies to selectively leverage IT systems for end user use. But well beyond just slapping a web server in front of an app, gateways both facilitate use of an application and protect it. Gateways enable third party developers, outside your organization, to support different use cases in different environments – such as new applications, mobile apps, and service mash-ups – while allowing you to control security, function, and access to data. They provide a glue layer between your systems and the outside world. This research paper describes API gateways in detail, shows how they are deployed, and provides the key information to select and implement a gateway. Here is an except: API gateways enable developers to build cloud, mobile, and social apps on enterprise data, layered over existing IT systems. That said, API gateways are not sexy. They do not generate headlines like cloud, mobile, and big data. But 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 believe, at prices that seem to good to be true. But APIs are a key part of what makes them so scalable, universal, and cheap. API mashups bring new ways to collaborate and mobile apps provide fundamentally new front ends. We are commoditizing our IT systems into open services! Of course open, API-driven, multi-tenant environments bring new risks 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. We would like to thank Intel for licensing this research. We wouldn’t be able to do the research we do, or offer it to you folks for this most excellent price, without clients licensing our content. If you have comments of questions about this research, please feel free to email us with questions. View Intel’s API Gateway resource center to download the report and view other API related tutorials. Or Download from Securosis: API Gateways, version 1.0. (PDF) Attachments API_Gateways_Enabling_Innovation_FINAL.pdf [1.0MB] Share:

Most folks think the move towards the extended enterprise is very cool. You know, get other organizations to do the stuff your organization isn’t great at. It’s a win/win, right? From a business standpoint, there are clear advantages to building a robust ecosystem that leverages the capabilities of all organizations. But from a security standpoint, the extended enterprise adds a tremendous amount of attack surface. In order to make the extended enterprise work, your business partners need access to your critical information. And that’s where security folks tend to break out in hives. It’s hard enough to protect your networks, servers, and applications while making sure your own employees don’t do anything stupid to leave you exposed. Imagine your risk – based not just on how you protect your information, but also on how well all your business partners protect their information and devices as well. Actually, you don’t need to imagine that – it’s reality. In Threat Intelligence for Ecosystem Risk Management we delve into the risks of the extended enterprise and then present a process to gather information about trading partners to make decisions regarding connectivity and access more fact-based. Many of you are not in positions to build your own capabilities to assess partner networks, but this paper offers perspective on how you would, so when considering external threat intelligence services you will be an educated buyer. Direct Download (PDF): Threat Intelligence for Ecosystem Risk Management We want to thank BitSight Technologies for licensing the content in this paper. The largesse of our licensees enables us to provide our research without cost to you. Share:

We are proud to announce the availability of our Cloud Identity and Access Management research paper. While you have likely been hearing a lot about cloud services and mobile identity, how it all works is not typically presented. Our goal for this research paper is simple: Present the trends in IAM in a clear fashion so that security and software development professionals understand the new services at their disposal. This paper shows how cloud computing is driving extensible architectures and standardization of identity protocols, and how identity and authorization is orchestrated across in-house IT and external cloud services. Changes to IAM architectures provide the means to solve multiple challenges; additionally, external service providers offer commoditized integration with the cloud and mobile devices — reducing development and management burdens. Here is an except from the paper: If you want to understand emerging Identity and Access Management (IAM) architectures, it’s best to start by forgetting what you know. The directory services we use today (most often LDAP and Active Directory) were designed in the client-server age, and their implementations generally presuppose a closed system. Third-party cloud services, and to a lesser extent mobile computing, have forced a fresh approach that embraces decentralization. We liken the change from in-house directory service to Cloud IAM as that of moving from an Earth centric view of the universe to a Sun centric view: it’s a complete change in perspective. We are talking about the fusion of multiple identity and access management capabilities — possibly across multiple cloud services — for computers and devices not fully under your control. We are developing the ability to authorize users across multiple services without distributing credentials to each and every service provider. We would like to thank Symplified for licensing this content. Without their interest in projects such as this, we would not be able to bring you cutting edge research, free of charge. Please email us if you have questions! Attachments Understanding_IAM_For_Cloud_Full.pdf [835KB] Share:

You have heard of denial of service attacks, but database denial of service? It may come as a surprise, but database denial of service attacks have become common over the past decade. Lately they are very popular among attackers, as network-based attacks become more difficult. We have begun to see a shift in Denial of Service (DoS) tactics by attackers, moving up the stack from networks to servers and from servers to the application layer. Over the last 18 months we have also witnessed a new wave of vulnerabilities and isolated attacks against databases, all related to denial of service. We don’t hear much about them because they are lost among the din of network DoS and even SQL injection (SQLi) attacks. Database DoS doesn’t make headlines compared to SQLi, because injection attacks often take control of the database and can be more damaging. But interruption of service is no longer ignorable. Ten years ago it was still common practice to take a database or application off the Internet while an attack was underway. But now web services and their databases are critical business infrastructure. Take down a database and a company loses money – possibly quite a lot. Here is an except from the paper: The abuse of database functions is, by our count of reported vulnerabilities related to DoS, the single most common type of DB-DoS attack. There have been hundreds, and it seems like no externally accessible function is safe. This class of attack is a bit like competitive judo: you shift your weight in one direction your opponent pushes you in the same direction to make you lose your balance and fall over. An attacker may use database features against you just like a judo expert uses your weight against you. For example, if you restrict failed logins, attackers may try bad passwords until they lock legitimate users out. If you implement services to automatically scale up to handle bursts of requests, attackers can generate bogus requests to scale the database up until it collapses under its own weight, or in metered cloud environments you hit a billing threshold and service is shut down. There is no single attack vector, but a whole range of ways to abuse database functions. We would like to thank DBNetworks for licensing the content in this paper. Obviously we wouldn’t be able to do the research we do, or offer it to you folks for this most excellent price, without clients licensing our content. If you have comments of questions about this research, please feel free to email us with questions! Database_DoS.pdf Share:

Our updated and revised 2014 Endpoint Security Buyer’s Guide updates our research on key endpoint management functions, including patch and confirmation management and device control. We have also added coverage of anti- … malware, mobility, and BYOD. All very timely and relevant topics. The bad news is that securing endpoints hasn’t gotten any easier. Employees still click things, and attackers have gotten better at evading perimeter defenses and obscuring attacks. Humans, alas, remain gullible and flawed. Regardless of any training you provide employees, they continue to click stuff, share information, and fall for simple social engineering attacks. So endpoints remain some of the weakest links in your security defenses. As much as the industry wants to discuss advanced attacks and talk about how sophisticated adversaries have become, the simple truth remains that many successful attacks result from simple operational failures. So yes, you do need to pay attention to advanced malware protection tactics, but if you forget about the fundamental operational aspects of managing endpoint hygiene, the end result will be the same. The goal of this guide remains to provide clear buying criteria for those of you looking at endpoint security solutions in the near future. Direct Download (PDF): The 2014 Endpoint Security Buyer’s Guide We would like to thank Lumension Security for licensing the content in this paper. Obviously we wouldn’t be able to do the research we do, or offer it to you without cost, without companies supporting our work. Share:

Much of the security industry spends significant time and effort focused on how hard it is to deal with today’s attacks. Adversaries continue to improve their tactics. Senior management doesn’t get it, until there is a breach… then your successor can educate them. And the compliance mandates hanging over your organization like albatross remain 3-4 years behind the attacks you see daily. The vendor community compounds the issues by positioning every product and/or service as a solution to the APT problem. Which means they don’t really understand advanced attackers at all. But complaining doesn’t solve problems, so we put together a CISO’s Guide to Advanced Attackers to help you structure a programmatic effort to deal with these adversaries. It makes no difference what a security product or service does – they are all positioned as the only viable answer to stop the APT. Of course this isn’t useful to security professionals who actually need to protect important things. And it’s definitely not helpful to Chief Information Security Officers (CISOs) who have to explain their organization’s security programs, set realistic objectives, and manage expectations to senior management and the Board of Directors. So as usual your friends at Securosis are here to help you focus on what’s important and enable you to wade through the hyperbole to understand what’s hype and what’s real. This paper provides a high-level view of these “advanced attackers” designed to help a CISO-level audience understand what they need to know, and maps out a clear 4-step process for dealing with advanced attackers and their innovative techniques. Direct Download (PDF): The CISO’s Guide to Advanced Attackers We would like to thank Dell Secureworks for licensing the content in this paper. Obviously we wouldn’t be able to do the research we do, or offer it to you without cost, without companies supporting our efforts. Share:

The benefits of Infrastructure as a Service (IaaS), public or private, are driving more and more organizations to cloud computing; but one of the biggest concerns – even for internal deployments – is data security. The cloud fundamentally changes how data is stored, and brings both security and compliance concerns. We see this creating a resurgence of interest in encryption, with some very practical approaches available: Infrastructure as a Service (IaaS) is often thought of as merely a more efficient (outsourced) version of traditional infrastructure. On the surface we still manage things that look like traditional virtualized networks, computers, and storage. We ‘boot’ computers (launch instances), assign IP addresses, and connect (virtual) hard drives. But while the presentation of IaaS resembles traditional infrastructure, the reality underneath is decidedly not business as usual. For both public and private clouds, the architecture of the physical infrastructure that comprises the cloud – as well as the connectivity and abstraction components used to provide it – dramatically alter how we need to manage security. The cloud is not inherently more or less secure than traditional infrastructure, but it is very different. Protecting data in the cloud is a top priority for most organizations as they adopt cloud computing. In some cases this is due to moving onto a public cloud, with the standard concerns any time you allow someone else to access or hold your data. But private clouds pose the same risks, even if they don’t trigger the same gut reaction as outsourcing. This paper will dig into ways to protect data stored in and used with Infrastructure as a Service. There are a few options, but we will show why the answer almost always comes down to encryption in the end – with a few twists. Direct Download (PDF): Defending Cloud Data with Infrastructure Encryption We would like to thank SafeNet and Thales e-Security for licensing the content in this paper. Obviously we wouldn’t be able to do the research we do, or offer it to you without cost, without companies supporting our research. Share:

Detecting malware feels like a losing battle. Between advanced attacks, innovative attackers, and well-funded state-sponsored and organized crime adversaries, organizations need every advantage they can get to stop the onslaught. We first identified and documented Network-Based Malware Detection (NBMD) devices as a promising technology back in early 2012, and they have made a difference in detecting malware at the perimeter. Of course nothing is perfect, but every little bit helps. But nothing stays static in the security world so NBMD technology has evolved with the attacks it needs to detect. So we updated our research to account for changes in scalability, accuracy, and deployment: The market for detecting advanced malware on the network has seen rapid change over the 18 months since we wrote the first paper. Compounding the changes in attack tactics and control effectiveness, the competition for network-based malware protection has dramatically intensified, and every network security vendor either has introduced a network-based malware detection capability or will soon. This creates a confusing situation for security practitioners who mostly need to keep malware out of their networks, and are uninterested in vendor sniping and trash talking. Accelerating change and increasing confusion usually indicate it is time to wade in again and revisit findings to ensure you understand the current decision criteria – in this case of detecting malware on your network. So this paper updates our original research to make sure you have the latest insight for your buying decisions. Direct Download (PDF): Network-based Malware Detection 2.0: Assessing Scale, Accuracy and Deployment We would like to thank Palo Alto Networks for licensing the content in this paper. Obviously we wouldn’t be able to do the research we do, or offer it to you without cost, without companies supporting our research. Share: