Added 'Windows Service Activity' event.

[davemcatcisco]

Related Issue:

1020

Description of changes:

This schema change introduces a new Windows Service Activity event to the Windows extension in the System Activity category. The new event extends the System Activity event only minimally:

• Enumerants are added to the activity_id attribute, corresponding to the various actions that a process may perform on a service.
• The new win_service attribute is a Windows Service object.

The Windows Service object extends the pre-existing Service object in some important ways:

• The pre-existing name attribute is made required so as to reflect the mandatory nature of this attribute when describing behaviour pertaining to a Windows service.
• The new service_type_id attribute and its service_type sibling correspond to the dwServiceType field in the Win32 QUERY_SERVICE_CONFIG structure.
• The new service_start_type_id attribute and its service_start_type sibling correspond to the dwStartType field in the Win32 QUERY_SERVICE_CONFIG structure.
• The new cmd_line attribute corresponds to the lpBinaryPathName field in the Win32 QUERY_SERVICE_CONFIG structure.
• The new load_order_group attribute corresponds to the lpLoadOrderGroup field in the Win32 QUERY_SERVICE_CONFIG structure.
• The new service_dependencies attribute corresponds to the lpDependencies field in the Win32 QUERY_SERVICE_CONFIG structure.
• The new service_start_name attribute corresponds to the lpServiceStartName field in the Win32 QUERY_SERVICE_CONFIG structure.
• The new service_error_control attribute corresponds to the dwErrorControl field in the Win32 QUERY_SERVICE_CONFIG structure.
• The new service_category_id attribute and its service_category sibling do not directly correspond to any field in the Win32 QUERY_SERVICE_CONFIG structure but instead represent a more coarse-grained categorisation of the information in the service_type_id and service_type attributes. This is useful in contexts where the precise type of service is unknown and a security product knows only if the activity relates to a kernel mode driver or a user mode service.

Because behaviour relating to Windows services is a common trigger for detections, this PR also adds the win_service attribute to the Windows Evidence Artifacts object.

[davemcatcisco]

A dedicated Windows event might be the way to go.

However, "services" of some form are relevant on major operating systems. Have you considered creating a more generic "Service Activity" event that isn't specific to Windows?

If such an event isn't descriptive enough then the windows extension could be used to add additional information that doesn't fit well into a generic event.

Even if the current approach is what we go with, it is good to have the reasons why written down in the pull request.

I think the reasons for having a dedicated event were already discussed elsewhere and in the issue linked to above. But...

It certainly would be possible to identify ways in which the Windows service mechanism overlaps with, say, the Linux systemd mechanism, and it would therefore be possible to define a common base event class. But would doing that actually be useful? I often feel that the result of an effort to identify a common base results is something that is vaguely satisfying intellectually but not practically useful and ultimately more trouble than it is worth. The Windows service mechanism has a very tightly defined control interface, lifecycle, and configuration which owes more to its VAX/VMS roots than to Linux.

[davemcatcisco]

I've been thinking a lot about this PR since discussing it at the System/Mappings call yesterday. I'm going to look at the possibiltiy of using the existing service object. Please don't spend any time reviewing this for now until I've bottomed out on that.

[davemcatcisco]

I've been thinking a lot about this PR since discussing it at the System/Mappings call yesterday. I'm going to look at the possibiltiy of using the existing service object. Please don't spend any time reviewing this for now until I've bottomed out on that.

I've reworked the PR so as to define a new Windows Service object which extends the pre-existing Service object. This PR is now ready for review. Marking as such.

[davemcatcisco]

Attn. gatekeepers (@floydtree, @pagbabian-splunk, @mikeradka, @Aniak5, @zschmerber): This PR is now ready for review. Thanks.

[davemcatcisco]

Attn. @floydtree, @pagbabian-splunk, @mikeradka, @Aniak5, @zschmerber: I still need one more approval on this PR if one of you could do the needful.

[davemcatcisco]

Attn. gatekeepers (@floydtree, @pagbabian-splunk, @mikeradka, @Aniak5, @zschmerber): This PR is now approved and ready for merge. Thanks!