Best Practices for Mapping IT Services with SDDM

Exclusions

We can make mapping of services easier if we first address some of the white noise inherent in most environments.  Active Directory authentication, replication and Group Policy application as well as other infrastructure services such as DHCP, DNS and others can generate nearly constant network activity that may seep into an automatically discovered service map.  Fortunately, we can set the solution to automatically filter out this noise in a couple of ways.

Global Exclusions

If the scope of your project does not include any infrastructure services, and you have no need of this data for any investigatory purposes, then these can be filtered out globally by going to Edge Devices in the web interface and clicking on Global Network Traffic Settings.

However, if you intend on using the Network Traffic page to investigate traffic on systems for the purposes of troubleshooting incidents or for security investigations, you may not want to globally exclude all of this traffic.  As an alternative, each Service Group has configurable Port and IP Exclusions, and therefore this white noise can be filtered at the Service Group level and enable the Network Filter page to show absolutely all traffic from any system.  The choice is yours.

Common Ports to Exclude

Excluding Monitoring and Management Tools

If you are running any monitoring and management tools, especially any that perform discovery, we recommend excluding their IP addresses in Global Network Traffic Settings.  This is especially true for Solarwinds, BMC Patrol, Nessus scanners, any SIM/SIEM products and the like. 

Defining Entry Points for Services

With exclusion out of the way, we are ready to start mapping services.  There are three ways to map a service in FireScope SDDM, depending on the type of service being modeled; Business Services or Infrastructure Services.  Business Services, such as CRM, Payroll, Claims Management are typically mapped by the service entry point such as the front-end web server(s) or authentication server. 

There are two main screens to setup these services, Network URLs and Network Destinations in the Configuration menu.  Please note that if the solution is solely using NetFlow/sFlow for traffic data, the Network URLs page will be empty as this form of traffic data does not include URLs.  Of the two, we recommend focusing on the Network Destinations list as this will include thick client applications as well as web applications and has better search capabilities.  In the background, the solution analyzes for scenarios where multiple, unique IP addresses are all calling the same IP and destination port.  This is what drives the Clients column on this page.  Simply select the entry points that we want to map and complete the mini-form at the top of the page to create a new service.

Infrastructure Services

In addition to Business Services, many organizations map out key infrastructure applications such as their Oracle database servers, Citrix, MS SQL and the like.  While these services may not be useful as candidates for Federation to Cherwell or ServiceNow CMDBs, they are useful for operations and security teams in that they highlight when new instances are stood up (authorized or not) or when new consumers (potential intrusion) are identified, as well as helping identify downstream requirements needed to support these services such as network segmentation.

Mapping these services is as easy as going to Network Traffic in the Configuration menu and filtering by traffic port.   The filter offers a preview of what this service will look like, to make this permanent complete the mini-form at the top to create a Service Group.

To aid in creating these types of services, the following is a partial – and growing – list of commonly used applications and their critical dependent ports.

 Once you have defined a service, bear in mind the initial map will not be produced until the Service Dependency Engine runs, which is performed on a scheduled basis (every 15 minutes, 1-hour, 4-hours).  You can kickstart this process by going to Edge Assignment Rules in the Configuration menu (Service Rule Settings, Administration menu in SPM) and clicking Save – no need to change any settings.

After this has been run, you will then need to open the Service Group in the Dependency Editor and approve the relationships.

Using Inclusions

If you are still seeing considerable noise from nodes that should not be contributing to a service, another approach to consider is using a port inclusion list in the Service Group itself.  If we know all of the ports used by dependencies of the service, such as the MS SQL backend, application server ports, etc., then we can use those in the Port Inclusion list for the service to provide additional filtering – any traffic that isn’t using a port from this list will be scrubbed from the service.  However, unless you are absolutely confident that you know every potential port used by a given service, we would not recommend using this.

Run VMware and Topology Discovery

You may notice that initially you will only see application dependencies.  VMware and Network dependencies will only be incorporated into a Service Group after the next run of those discovery scans.