From: Securosis Highlights – Endpoint Security Management Buyer’s Guide – Platform Buying Considerations

Posted on 2012/08/20

a quick re-post from Securosis Highlights

Endpoint Security Management Buyer’s Guide – Platform Buying Considerations by (author unknown)

As we wrap up the Endpoint Security Management Buyer’s Guide, we’ve already looked at the business impact of managing endpoint security, the endpoint security management lifecycle, and then dug into the periodic controls (patch and configuration management), and the ongoing controls (device control and file integrity monitoring). We’ve alluded to the platform throughout the posts, but what exactly does that mean? What do you need the platform to do?

Platform Selection

Similar to most technology categories (at least in security), the management console (or platform as we like to call it) provides the glue that holds together the sensors, agents, appliances, or anywhere else that security controls are implemented. Let’s list the capabilities you need from the platform.

  • Dashboard: The dashboard provides the first exposure to the technology, and as such you’ll want to have user-selectable elements and defaults for technical and non-technical users. You’ll want to be able to only show certain elements, policies and/or alerts to authorized users or groups, with those entitlements typically kept in the enterprise directory. Nowadays with the state of widget-based interface design, you’d expect a highly customizable environment, letting each user configure what they need, and how they want to see it.

  • Discovery: You can’t protect an endpoint (or any other device, for that matter) if you don’t know it exists. So once you get past the dashboard, the first key feature of the platform is discovery. The enemy of a security professional is surprise, so make sure you know about new devices as quickly as possible, including mobile devices.

  • Asset Repository Integration: Closely related to discovery is being able to integrate with an enterprise asset management system/CMDB to get a heads-up when a new device is provisioned. Again, understanding when new devices appear in your environment is critical to monitoring and enforcing policies. You can learn about the new devices proactively (via integration) or reactively (via discovery). Either way, you need to know what’s out there.

  • Alert Management: Given the reality that a security team is only as good as the last incident response, the alert management capability is pretty important. This allows administrators to monitor and manage policy violations, which could possibly represent a breach. Time is of the essence during any response, so being able to provide deeper detail (via drill down) and send information to an incident response process is critical. The interface should be concise, customizable, and easy to read at a glance, given the time criticality of response. When an administrator digs into an alert during a drill down, the display should cleanly and concisely summarize the reason for the alert, the policy violated, the user involved, and any other information helping to assess the criticality and the severity of the situation.This is pretty important, so we’ll dig deeper later in the post.

  • Policy Creation and Management: Alerts are driven by the policies you implement in the system, which makes policy creation and management another critical aspect of the platform. Thus, we’ll delve into this more specifically later in the post.

  • System Administration: You’d expect to have the standard system status and administration capabilities within the platform, including user and group administration. Also keep in mind that for a larger, more distributed environment, you’ll want some kind of roles-based access control (RBAC) and hierarchical management capabilities to manage access and entitlements for a variety of administrators with a variety of responsibilities within your environment.

  • **Reporting: As we mentioned discussing each of the specific controls, compliance tends to have a significant role in funding and driving these investments, which means substantiating the efficacy of the controls is critical. So you want to look for a mix of customizable pre-built reports and tools to facilitate ad hoc reporting, both at the specific control level, as well as across the entire platform.

Given the importance of managing your policy base and then dealing with the subsequent alerts (which could represent attacks and/or breaches), let’s go a bit deeper into each of those functions.

Policy Creation and Management

Once you know what endpoint devices are out there, assessing the devices against a policy (and remediating as necessary) is where the platform provides value. Given the resources required to validate and assess every alert, ensuring relevant alerts becomes a critical success factor for endpoint security management. So it’s not hyperbole to state that policy creation and management is (potentially) the most difficult part of managing endpoint security. The policy creation interface should be accessible to both technical and non-technical users, although creation of heavily customized policies will nearly always require technical skills.

For policy creation, the system should provide some baselines to get you started. For patching, perhaps you start with a list of common devices and then configure the assessment and patching cycles accordingly. The same concept applies to the other controls as well. Although every environment will have some unique characteristics, the platform vendor should provide out of the box policies to make customization easier and faster. All of the policies should be usable as templates for new policies. We’re big fans of wizards to walk administrators through this initial setup process, but also understand more sophisticated users will need a proverbial advanced tab to more granularly set up policies to meet their requirements. Keep in mind not all policies are created equal, so the platform should allow each alert to be graded by sensitivity, and to set severity thresholds.

Most administrators tend to prefer interfaces that use clear, graphical layouts for policies — preferably with an easy-to-read grid showing the relevant information for each policy. The more complex a policy, the easier it is to create internal discrepancies or accidentally define an incorrect remediation. Also remember every policy will need some level of tuning, and a good tool will allow you to create a policy in test mode showing how it would react in production, without firing all sorts of alerts or requiring remediation.

Alert Management

Remember, security folks earn their keep when bad things happen. Thus, you’ll want all of your tools to accelerate and facilitate the triage, investigation, root cause analysis, and process in which you respond to alerts. To be clear, on a day to day basis, admins will spend most of their time working through the various alerts thrown off by the platform. Thus alert management/workflow will be the most heavily used part of the endpoint security management platform.

When assessing the alert management capabilities of any product/service, first look at it from the standpoint of supporting your existing processes. Obviously at times you’ll need to adapt your process to get the most from the tools, but ultimately you shouldn’t expect to blow up your existing process just to use the platform. As with most aspects of life, expect to meet somewhere in the middle.

In terms of what to look for, the first stop is the alert queue, which is a summary of all alerts and hopefully the ability to assign to a specific analyst for triage. Alert status should be clearly indicated with color-coded sensitivity (based on the policy violated) and severity (based on the volume of the transgression, or some other factor defined in the policy). The alerts should be sortable or filterable on any field. Policy violated, user, alert status (open, closed, assigned, unassigned, investigation) and responsible party should also be indicated and easily changed for instant disposition.

By default, closed alerts shouldn’t clutter the interface — basically you want to treat the interface like an email Inbox. Each administrator should be able to customize anything to better suit his or her work style. Alerts with either multiple policy violations, or multiple violations of a single policy, should only appear once in the incident queue to simplify things.

When digging into an alert, the platform should list all the relevant details, including who, what, where, when, and how the policy was violated. A valuable feature is a summary of other recent violations by that user or device, and other violations with that data (which could indicate a larger event). The tool should allow the administrator to make comments, assign additional resources, notify management, and upload any supporting documentation.

To Cloud or Not to Cloud

Now let’s address the cloud buzzword. In this context ‘cloud’ means SaaS (software as a service), and the vendor manages the infrastructure, which you access via a browser interface across the Internet. There is a lot of opportunity for hype and religion to permeate this discussion. At the end of the day, whether you select an endpoint security management service (cloud) or product involves two things:

  1. Scale: You will hear a lot from cloud providers about infinite scale and the limitations of customer premise offerings. It is true that scalability is the vendor’s problem in a cloud/SaaS scenario. That offers some advantages, but any solution can scale with a suitable deployment architecture. The more flexible the system the better; your platform should support the way you categorize assets and provide the services that are important to you — not force you to overhaul your environment and processes to use the vendor’s tools.
  2. Technology Updates/Change: The other big message you’ll hear from cloud bigots is that cloud platforms handle software updates more quickly and transparently than gear that runs onsite. Again, there is truth here, but every endpoint security management vendor has been sending new rules and tests to its devices for years, so it’s not like they haven’t figured out software distribution and updating.

These two objections to customer premise solutions are really much ado about nothing. The ‘decision’ isn’t really a decision at all — what is and isn’t ‘cloud’ nowadays is largely a matter of semantics. Let’s get back to your requirements. You need to be able to assess your environment, making changes/remediations, and install agents (as needed). As long as you can meet your requirements, where the management console runs isn’t really a significant issue.

Remember, regardless of where the console resides, there will be an on-site component of the system, which might be a dedicated appliance, a virtual machine, a dissolvable agent or some combination. Don’t get caught up in hype. Focus on what problems you need to solve and the best way to solve them.

Vendor Selection Considerations

Inevitably after doing your research to figure out which platform can meet your requirements, you’ll need to define a short list and ultimately choose something. One of the inevitable decision points involves the big versus small vendor choice. And given the pace of mergers and acquisitions in the security space, even small vendors may not remain independent and small forever. Ultimately the advantage of working with a larger vendor is all about leverage. Either pricing leverage, can be achieved by buying multiple products/services from the vendor. Though keep in mind that smaller vendors can get pretty aggressive on pricing as well.

You also can achieve platform leverage using multiple products managed via a single platform. The larger endpoint security management vendors also have more active defense products (like anti-malware or network security) that you may use, and having an integrated console can make your life easier.

Given the importance of intelligence to understanding patches, configurations, and file integrity, it makes sense to consider the size and breadth of the research team and the customer base of the vendor. This is mostly because keeping policies current, issuing effective updates (for configuration or file hashes, for example) requires access to a huge dataset and a large analysis capability to figure out what needs to be done. You’ll probably hear a lot about Big Data, but that’s just the buzzword du jour. It’s more about the vendor making the investment to keep their platform current given the dynamic nature of the security business.

You’ll want to ensure the vendor has the ability to support your environment, wherever that is. Local support is best when dealing with endpoints, though with the state of collaboration and remote management/troubleshooting tools, it’s increasingly possible for a centralized group to support a global customer base. Given the sophistication of your local IT teams, you may want to ensure you can get deployment assistance from the vendor as well, especially in remote locations, where it would be very expensive to send your own folks to deploy the system.

Purchasing Cycle

In terms of the purchasing cycle, we don’t see a lot of need to reinvent the wheel. Some organizations are pretty formal and issue RFI/RFP (request for information/proposals) to gather information. Others work with resellers or rely on personal contacts to learn about alternatives and negotiate the deals. However you buy products/services, you’ll likely go through this kind of process:

  1. Define Requirements: Don’t minimize the need to do a level of internal fact finding and requirements gathering before engaging with any vendors. Know what you’re buying and why. Understand what’s working in your environment and what’s not. Then you’ll know what you need the endpoint security management platform to do.
  2. Establish short list: This can be a formal process or not so formal. Ultimately you’ll need to figure out a handful of vendors that can meet your requirements. Talk to them and dig deeper into their products/services to really figure out which vendor can solve your problems.
  3. Test products: You’ll want to set up a test bed and let the tools do their things. Depending on which controls you are looking to implement, you can run all sorts of tests during a proof of concept. Figuring out the overhead on devices of any agentry is key, as well as the user experience of setting policies, managing alerts, and remediating the issues.
  4. Try support: Make sure you put in a number of calls to the vendor’s support group. Both during typical business hours and off-hours to understand how they’ll support you when it counts.
  5. Negotiate: We could write a book about vendor negotiation, but suffice it to say leverage is good. So try to negotiate with at least two vendors to get them competing for your business. And don’t believe the vendors when they say end of quarter discounts don’t happen. Unless the sales rep is way ahead of their quota, they’ll deal at the end of the quarter.

Obviously, we could go a lot deeper into the aspects of the purchasing cycle, as it’s a discipline like any other aspect of a security professional’s job. But the high level process outlined above will serve you well.

And with that, we’ll put a wrap on the Endpoint Security Management Buyer’s Guide. But wait, just one more thing…

Tomorrow, we’ll post the top 10 questions to ask your endpoint security management vendor, which will put a nice little bow on this series.

– Mike Rothman
(0) Comments

Posted in: reading