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

Platform Selection

As with most other technology categories (at least in security), the management console (or ‘platform’, as we like to call it) connects the sensors, agents, appliances, and any other security controls. Let’s list the platform capabilities you need.

• Dashboard: The dashboard provides the primary exposure to the technology, so you will want to have user-selectable elements and defaults for technical and non-technical users. You will want to be able to only show certain elements, policies, and/or alerts to authorized users or groups, with the entitlements typically stored in the enterprise directory. Nowadays with the state of widget-based interface design, you can 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 the 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 the ability to integrate with an enterprise asset management system/CMDB to get a heads-up whenever a new device is provisioned. This is essential for monitoring and enforcing policies. You can learn about new devices proactively via integration or reactively via discovery. But either way you need to know what’s out there.
• Alert Management: A security team is only as good as its last incident response, so alert management is key. This allows administrators to monitor and manage policy violations which could represent a breach. Time is of the essence during any response, so the ability to provide deeper detail via drill down and send information into an incident response process is critical. The interface should be concise, customizable, and easy to read at a glance – response time is critical. When an administrator drills down into an alert the display should cleanly and concisely summarize the reason for the alert, the policy violated, the user(s) involved, and any other information helpful for assessing the criticality and severity of the situation. This is important so we will dig deeper later.
• Policy Creation and Management: Alerts are driven by the policies you implement in the system, so policy creation and management is also critical. We will delve further into this later.
• System Administration: You can expect the standard system status and administration capabilities within the platform, including user and group administration. Keep in mind that for a larger more distributed environment you will want some kind of role-based access control (RBAC) and hierarchical management to manage access and entitlements for a variety of administrators with varied responsibilities within your environment.
• Reporting: As we mentioned when discussing the specific controls, compliance tends to funding and drive these investments, so substantiating their efficacy is necessary. Look for a mixture of customizable pre-built reports and tools to facilitate ad hoc reporting – both at the specific control level and across the entire platform.

In light of the importance of managing your policy base and dealing with the resulting alerts – which could represent attacks and/or breaches – let’s go deeper into each of those functions.

Policy Creation and Management

Once you know what endpoint devices are out there, assessing their policy compliance (and remediating as necessary) is where the platform provides value. The resource cost to validate and assess each alert makes filtering relevant alerts becomes critical for successful endpoint security management. So policy creation and management can be 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 almost always requires technical skill.

For policy creation the system should provide some baselines to get you started. For patching you might start with a list of common devices and then configure the assessment and patching cycles accordingly. This works for the other controls as well. Every environment has its own unique characteristics but the platform vendor should provide out-of-the-box policies to make customization easier and faster. All policies should be usable as templates for new policies. We are big fans of wizards to walk administrators through this initial setup process, but more sophisticated users need an “Advanced” tab or equivalent to set up more granular policies for more sophisticated requirements. Not all policies are created equal, so the platform should be able to grade the sensitivity of each alert and support 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. Remember that every policy needs some level of tuning, and a good tool will enable you to create a policy in test mode to see how it would react in production, without firing all sorts of alerts or requiring remediation.

Alert Management

Security folks earn their keep when bad things happen. So you will want all your tools to accelerate and facilitate the triage, investigation, root cause analysis, and process in which you respond to alerts. On a day to day basis admins will spend most of their time working through the various alerts generated by the platform. So alert management/workflow is the most heavily used part of the endpoint security management platform.

When assessing the alert management capabilities of any product or service, first evaluate them in terms of supporting your existing processes. Obviously you will need to adapt some process to get the most out of your tools, but you should not need to blow up your existing processes to take advantage of the platform.

In terms of what to look for, the first stop is the alert queue: a summary of all alerts, hopefully with the ability to assign each 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). 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 – you should be able to treat the interface like an email inbox. Each administrator should be able to customize everything to suit his or her own 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 summary of other recent violations by that user or device, and other violations with that data (which might indicate a larger event), is particularly useful. The tool should allow administrators 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), where the vendor manages the infrastructure, which you access via a browser across the Internet. There is a great deal of hype and religion permeating this discussion. At the end of the day, whether you select an endpoint security management service (cloud) or a product involves two considerations:

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 and Change: The other big message you hear from cloud advocates is that cloud platforms handle software updates more quickly and transparently than onsite gear. 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, changing and remediating, and install agents as needed. As long as you can meet your requirements, where the management console runs isn’t really a significant issue.

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 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 will need to define a short list and ultimately choose something. One of the inevitable decision points involves big versus small vendors. 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. But smaller vendors can get pretty aggressive on pricing as well.

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

Given the importance of intelligence to understanding patches, configurations, and file integrity, it is important to consider the size and breadth of the vendor’s research team and customer base. Keeping policies current and issuing effective updates (for configuration or file hashes, for example) requires access to a huge dataset and a serious analysis capability to figure out what needs to be done. You will 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 will 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. Depending on 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 could be very expensive to send your own folks to deploy the system.

Purchasing Cycle

In terms of the purchasing cycle, we see no need to reinvent the wheel. Some organizations are formal and issue RFI/RFP (requests 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 and services, you are likely to go through the same basic process:

1. Define Requirements: Don’t minimize the need to do some internal fact finding and requirement 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 may be a formal or informal process or not so formal. Ultimately you’ll need to find a handful of vendors who can meet your requirements. Talk to them and dig deeper into their products and services to figure out which vendor can really solve your problems.
3. Test products: You will want to set up a testbed and let the tools do their thing. Depending on which controls you are looking to implement, you can run all sorts of tests during a proof of concept. Figuring out the device overhead of any agentry is key, as well as the user experience of setting policies, managing alerts, and remediating issues.
4. Try support: Make sure you put a number of calls into 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 for now suffice it to say leverage is good. 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.

We could go much deeper into purchasing – it’s a discipline like any other aspect of a security professional’s job. But the high level process outlined above should serve you well.

And with that we wrap 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, to put a nice little bow on this series.