Need information regarding DCS:SA IPS policy signature flags and how they work
This is about the Symantec Data Center Security : Server Advanced (DCS:SA) 6.0 IPS policy feature "signature flags" and in particular: Process Signature, Module Signature, Parent Process Signature, Parent Process Publisher.
here is an example event:
##################################################################
DETAILS
Description Process Assignment for CMD.EXE to deny_ps
Policy Name PREVENTION ENABLED -
DCSA-MGMT_PROD_WHITELISTING_2008
Rule Name :i.RA
Internal Rule Routing - Application child may not run
Process C:\WINDOWS\SYSTEM32\CMD.EXE
Parent Process C:\PROGRAM FILES\Symantec\SOFTWARE\BIN\symc\sisips.EXE
Module Path C:\PROGRAM FILES\Symantec\SOFTWARE\BIN\symc\sisips.DLL
Agent State Windows Service Process/Sub-Process
Sandbox deny_ps
Operation create
Process ID 22616
Thread ID 22392
Parent PID 10228
Arguments C:\WINDOWS\system32\cmd.exe /c C:\PROGRA~3\Symantec\SOFTWARE\BIN\symc\sisips.cmd rotate_evtlogs.pl
Process Signature Microsoft OS Component (00039437)
Module Signature Signed and Trusted
Parent Process Signature Signed and Trusted
Parent Process Publisher Company
##################################################################
The last 4 lines are what this article is about and will hopefully explain by the following question and answer piece:
1# Does a DCS:SA agent have a "list" of known process signatures & publishers?
There is no human readable list however the SymEFA (Symantec Extended File Attributes) component that is integrated in the DCS:SA agent uses "EFA Signatures" that contain the file hashes, publisher name and signature flags of processes.
2# How do file hashes, publisher name and signature flags of processes used by the SymEFA component get created/calculated/updated?
The EFA Signatures used by the SymEFA component are created by Symantec and distributed by means of LiveUpdate.
3# Does the DCS:SA agent get updated process signatures & publishers from LiveUpdate? Does the agent need access to the internet?
Internet access is not required on agent side. SymEFA definitions are sent down to the DCS:SA agent from the DSC:SA server, the DCS:SA server gets them from LiveUpdate. The DCS:SA Management server needs access to LiveUpdate (internal LU server or straight from the internet).
4# What happens to your DCS:SA IPS policy rule if the process binary is updated by a patch, does the signature need to be recalculated?
Unlike a hash value of a binary which would likely get updated if a process binary is updated by a patch, it is very unlikely that a process's signature would get updated by a patch. If it did though, it could potentially affect routing of the process to the intended sandbox/process set and also which resources (file, registry, pac) that process can access.
5# What happens to your IPS policy rule if the process binary is updated by a patch and the process signature no longer matches
As mentioned in response to question 4, IPS rule gets ignored if process signature does not match with the signature the user has defined in IPS policy. This could affect routing of the process to the intended sandbox/process set and to which resources (file, registry, pac) that process has access.
6# What is the significance of the number for example (00039437) or (00038407)?
These are the signature flag values. The signature flag values themselves do contain bit values that indicate whether the process was signed by Symantec, signed by Microsoft, or that it is a Microsoft OS Component.
7# How does getEFA.exe relate to all this?
GetEFA.exe is a standalone utility used to display the hash, publisher, and signature values of a file. It uses the same code (the SymEFA libraries) that the DCS:SA driver uses to retrieve hash, publisher, and sigflag values. This utility is not used in normal processing but can be helpful in debugging.
8# Anything else you can tell us about signature flags, process signatures & publishers?
The version 6.0 Windows policy is the only policy that supports signature flags, hash, and publisher. UNIX policies or SCSP 5.2.9 policies do not support this feature.
This is a set of categories for identifying digitally signed program files. The following flags are available as process attributes:
# Microsoft OS Component - The file is validly signed. The signing certificate indicates it belongs to Microsoft. The signing certificate indicates the file is part of the Windows operating system. The signing certificate chains to a trusted root certificate.
# Microsoft Signed - The file is validly signed. The signing certificate indicates it belongs to Microsoft. The signing certificate chains to a trusted root certificate.
# Symantec Signed - The file is validly signed. The signing certificate indicates it belongs to Symantec. The signing certificate chains to a trusted root certificate.
# Signed and Trusted - The file is validly signed. The signing certificate chains to a trusted root certificate.
# Unsigned . The file is not signed.
# Invalid Signature . The file is signed, but the signature is invalid.
In addition, two other categories are available in this attribute that are not related to whether the file is digitally signed:
# Service Process . The process is a descendant of the Service Control Manager.
# Interactive Process . The process is part of an interactive logon session.