Endpoint Defense Essential Practices

The area of security has the most increased focus recently is protecting the endpoint. Once you stop snickering, it makes some sense. For years (or decades, depending on how cynical you want to be) endpoint security was the beneficiary of the compliance driver. Whether the technologies actually protected anything was beside the point. Assessors would show up, and you needed to have AV. Then advanced attackers happened and the industry started innovating, starting with network security, leaving the endpoint largely unprotected. But that’s no longer a defensible strategy. Endpoints are more likely untethered than not, so these devices are no longer within the corporate perimeter. You could route all traffic through your corporate network, but that defeats the purpose of the cloud and the Internet. We have seen a renaissance of sorts with lots of interesting technologies designed to protect endpoints. We covered many of these developments in our Advanced Endpoint and Server Protection paper. But the fact remains: many organizations are not even prepared to deal with unsophisticated attackers. You know, that dude in the basement banging on your stuff with Metasploit. Those organizations don’t really need advanced security – their needs are more fundamental. They need to understand what really needs to get done – not the hot topic at industry conferences. They cannot do everything to fully protect endpoints, so they need to start with the essentials. So this post is all about these Essential Practices of Endpoint Defense. Thanks to our friends at Viewfinity, we will turn this post into a short paper. Securing Endpoints Is Hard Why is this still a discussion? Endpoints have been around for decades, and organizations have spent tens of billions of {name your favorite currency} to protect these devices. But every minute more devices are compromised, breaches result, and your Board of Directors wants an explanation of why this keeps happening. Two issues underlie the difficulties of endpoint protection. First, let’s be candid. It’s a software issue – software has defects, which attackers exploit. Second, employees routinely fall for simplistic social engineering attacks, resulting in a software install or clicked link – the beginning of a successful attack. And you are a target, regardless of the size of your organization. You have something someone else wants to steal, and they will try. Complicating the situation, adversaries continue to automate their reconnaissance and attack efforts. You are not protected by resource constraints – the entire Internet can be scanned for common vulnerabilities daily. The status quo doesn’t work for our side. We need to take a step back, and look at protecting endpoints with fresh eyes. This provides an opportunity to determine what’s really essential. Defending Endpoints As we have alluded, there are two aspects to defending endpoints: hygiene and threat management. They are co-dependent – you cannot just address either on and expect your endpoints to be protected.   Endpoint Hygiene: The operational aspects of reducing device attack surface are an integral aspect of endpoint security strategy. You need to ensure you have sufficient capabilities to manage patches and enforce security configuration policies. Additionally, you should ensure employees have the least privilege necessary on each device to prevent privilege escalation, and lock down device ports. Endpoint Threat Management: Advanced attackers are only as advanced as they need to be: they take the path of least resistance. But the converse is also true. When these adversaries need advanced techniques, they use them. Traditional malware defenses such as antivirus don’t stand much chance against a zero-day attack. An effective threat management process incorporates people, processes, and technology. Now let’s dig into both aspects of endpoint defense to identify these essential practices. Endpoint Hygiene Consistent and effective hygiene practices are elusive, both personally (look at your dentist’s fancy car) and within security. It is not a lack of desire – everyone wants to ensure their devices are difficult to compromise. It has been a challenge of operational excellence. To be clear, effective hygiene practices don’t completely protect endpoints, but they certainly make them much harder targets. The essential practices we lump into the hygiene bucket include: Patch Management Configuration Management Device Control Least Privilege Patch Management Patch managers install fixes from software vendors to address vulnerabilities. The most well-known patching process is Microsoft’s monthly Patch Tuesday, when the company issues a variety of software fixes to address defects in its products – many of which could result in system exploitation. Other vendors have adopted similar approaches, with a periodic patch cycle and out-of-cycle patches for more serious issues. Once a patch is issued your organization needs to assess it, figure out which devices need to be patched, and install it within the window specified by policy – typically a few days. A patch management product scans devices, installs patches, and reports on the success or failure of the process. Our Patch Management Quant research provides a detailed view of the patching process, so refer to it for more information. Configuration Management Configuration management enables an organization to define an authorized set of configurations for devices. These configurations can control pretty much everything that happens on the device, including: applications installed, device settings, running services, and on-device security controls. Another aspect of configuration management is the ability to assess configurations and identify changes, which is valuable because unauthorized configuration changes may indicate malware execution or an exploitable operational error. Additionally, configuration management can help ease the provisioning burden of setting up and reimaging devices after infection. Device Control End users love the flexibility USB ports provide for ‘productivity’. Unfortunately USB doesn’t just enable employees to share music with buddies – it also lets them download your entire customer database onto their phones. It all became much easier once the industry standardized on USB a decade ago. The ability to easily share data has facilitated employee collaboration, while also greatly increasing the risks of data leakage and malware proliferation. Device control technology enables you to enforce policy – both who can use USB ports and how – and capture whatever is copied to and from USB devices. As an active control, monitoring

Read Post

New! Cracking the Confusion: Encryption & Tokenization for Data Centers, Servers, & Applications

Woo Hoo! It’s New Paper Friday! Over the past month or so you have seen Adrian and myself put together our latest work on encryption. This one is a top-level overview designed to help people decide which approach should work best for datacenter projects (including servers, storage, applications, cloud infrastructure, and databases). Now we have pieced it together into a full paper. We’d like to thank Vormetric for licensing this content. As always we wrote it using our Totally Transparent Research process, and the content is independent and objective. Download the full paper. Here’s an excerpt from the opening: Today we see encryption growing at an accelerating rate in data centers, for a confluence of reasons. A trite way to summarize them is “compliance, cloud, and covert affairs”. Organizations need to keep auditors off their backs; keep control over data in the cloud; and stop the flood of data breaches, state-sponsored espionage, and government snooping (even by their own governments). Thanks to increasing demand we have a growing range of options, as vendors and even free and Open Source tools address this opportunity. We have never had more choice, but with choice comes complexity – and outside your friendly local sales representative, guidance can be hard to come by. For example, given a single application collecting an account number from each customer, you could encrypt it in any of several different places: the application, the database, or storage – or use tokenization instead. The data is encrypted (or substituted), but each place you might encrypt raises different concerns. What threats are you protecting against? What is the performance overhead? How are keys managed? Does it all meet compliance requirements? This paper cuts through the confusion to help you pick the best encryption options for your projects. In case you couldn’t guess from the title, our focus is on encrypting in the data center: applications, servers, databases, and storage. Heck, we will even cover cloud computing (IaaS: Infrastructure as a Service), although we covered it in depth in another paper. We will also cover tokenization and discuss its relationship with encryption. We would like to thank Vormetric for licensing this paper, which enables us to release it for free. As always, the content is completely independent and was created in a series of blog posts (and posted on GitHub) for public comment. Share:

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.