VMware vShield EndPoint Security: Agentless VM Security Solution

Strengthen security for virtual machines and their hosts while improving performance by orders of magnitude for endpoint protection, with VMware vShield Endpoint, part of the VMware vShield family. Offload antivirus and anti-malware processing to dedicated security-hardened virtual machines delivered by VMware partners. Leverage existing investments and manage antivirus and anti-malware policies for virtualized environments with the same management interfaces as physical environments.

VMware vShield Endpoint comprises a hardened, security virtual machine that hosts the third-party anti-virus software. Each virtual machine requiring AV protection only requires a small-footprint, driver software, deployed as a loadable kernel module per vSphere host.

How Does VMware vShield Endpoint Work ?

vShield Endpoint protects virtual machines and their hosts against viruses, malware and other threats. vShield Endpoint plugs directly into vSphere and consists of three components:

1. Hardened security virtual machine (delivered by VMware partners)

2. Driver for virtual machines to offload file events

3. VMware Endpoint Security (EPSEC) loadable kernel module (LKM) to link the first two components at the hypervisor layer

Partner Integrations :

Integration of VMware vShield Endpoint with security virtual machine solutions from VMware partners is facilitated through VMware EPSEC, which provides a library and API for introspection into file activity at the hypervisor layer. vShield Endpoint monitors virtual machine file events and notifies the antivirus engine, via VMware EPSEC, which scans and returns a disposition. It also supports scheduled full and partial file scans initiated by the antivirus engine in the security virtual machine.

ref



Understanding VMware vShield Endpoint And Agentless Malware Protection -


Trend Micro integration with VMware endpoint security - http://www.vmwareforum2011.com/library/documents/finland_1100_trendmicro_session.pdf

Windows Services Enhancements in Vista and above - Automatic Delayed Start & NotifyServiceStatusChange() API

Auto-start services to be started only after Windows has finished its own startup process. Specifically, a delayed auto-start service is activated roughly two minutes after regular auto-start services. The Service Control Manager (SCM) also creates the main service thread with a lower priority, ensuring that any logged on user isn't notably impacted by delayed auto-start services. The priority is set back to normal after the service updates its state indicating that it is running. You can force a delayed auto-start service to start sooner by using the StartService function if it turns out that it hasn't started by the time your application needs to make use of it.

Example: Windows Security Center Service(wscsvc) starts a Automatic delayed start Service.

Sample Code:
bool ChangeDelayedAutoStart( SC_HANDLE service, bool delayed)
{

ASSERT(0 != service);

SERVICE_DELAYED_AUTO_START_INFO info = { delayed };

return 0 != ::ChangeServiceConfig2(

service,

SERVICE_CONFIG_DELAYED_AUTO_START_INFO,

&info);

}


Service State Change Notifications

Earlier than Windows Vista, the only way for a client to determine whether a service had changed its status or been created or deleted was to use the service query API—such as the QueryServiceStatusEx function—and poll the status of the service. This was not the best approach because these polling loops reduced system performance. In addition, polling loops have historically been a significant source of bugs.

Windows Vista introduces a new function, NotifyServiceStatusChange, which allows the SCM to notify a client when a specified service is created, is deleted, or changes its status.

How to Have a Client Notified When a Service's State Changes:

To register for state change notifications, a client calls NotifyServiceStatusChange to specify the service and change that they want to be notified of. They also provide the SCM with a pointer to a callback function. When the specified change takes place, the SCM calls the callback function to notify the caller.

The following list contains several notes on the use of NotifyServiceStatusChange. For more information, see the function's reference page, which is listed in "Resources" at the end of this paper.

· NotifyServiceStatusChange can be used by local or remote clients.

· The callback function is called only once. If the client wants a subsequent notification for this change, the client must call NotifyServiceStatusChange again and reregister the callback function.

· The callback function is normally called after a transition to the specified state has occurred. There is an exception to this rule for the first time that the caller invokes NotifyServiceStatusChange. In that case, if the service is already in the specified state, SCM calls the callback function.

· Clients can cancel the notification by calling CloseServiceHandle to close the service handle.

· Clients should not exit the thread that they used to call NotifyServiceStatusChange unless the callback function has been called or they have canceled the notification. Otherwise, they will create a memory leak.

· If one or more services hold open handles to a service, the service is not deleted until the next time the system is booted. If this is the case, no delete notification is sent.

Note: A caller must have the SERVICE_QUERY_STATUS access right to call NotifyServiceStatusChange. By default, only administrators, power users, and server operators on a domain controller can get this right remotely. Services and interactive users can get this right locally.


ref:

Windows Services Advanced concepts - http://msdn.microsoft.com/en-us/magazine/cc164252.aspx

Windows Services in Windows Vista(Service State Change Notifications) - http://www.scritube.com/limba/engleza/software/Services-in-Windows-Vista1731861210.php

VC++ sample code(using NotifyServiceStatusChange) - http://www.experts-exchange.com/Programming/Languages/CPP/Q_23586927.html