This document is intended as a guide to mapping IT Services with FireScope SDDM. It is assumed that prior to any steps described in this document, one or more FireScope Edge VMs have been deployed and is successfully collecting flow or packet data, and that all relevant load balancers have had discovery performed on them. As with any best practice guide, this is an evolving document and will be updated continually as new knowledge is gained.
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.
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
|Port or Port Range||Traffic Type||Additional Notes|
|49152-65535||Windows Dynamic Session Ports||There may be extremely rare cases where an application is using one of these ports as its entry port, so this may need to be adjusted based on that need – that said it’s extremely rare.|
|67,68||DHCP||If you intend on mapping your DHCP servers as an infrastructure service, then you probably won’t want to exclude this one.|
|88||Kerberos||User and Computer Authentication (Active Directory)|
|135||RPC, EPM||AD Replication|
|137||NetBIOS||Name resolution and NetLogon|
|389||LDAP||Directory and Replication, Trusts|
|445||SMB, CIFS, SMB2, DFSN||Directory and Replication, Trusts|
|2447||Network Node Manager daemon|
|8042-8043||FireScope||FireScope Agent/Edge Traffic|
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.
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.
|Exchange Server||691, 2883, 1129, 2657, 3173, 4309, 2728, 2703, 995||Also uses ports 443,25,110 and others, but these tend to include too many downstream clients; the ports listed to the left are predominantly used in Server-Server communication|
|MS SQL Server||1433||1434 is used by SQL Server browser and tends to bring in more clients than servers.|
|MS SQL Database Mirroring||5022||Useful to understand and track which SQL Servers are mirrored.|
|Oracle Database||1630, 2100, 3025, 3026, 4696, 7777, 3339, 5580, 5560, 2483|
|MOVEiT||3471-3473, 3478-3479, 33062, 8443||This may also be defined by using an entry point server. If so, make sure that ports 25,80,443,20,21,990,1433,3306,636,8080 are part of the inclusion ports.|
|Citrix Core||2512, 1494, 7279, 694|
|VMware||902, 903||These ports are used for heartbeat between vCenter and hosts, so these are useful to just map the core infrastructure. Also, don’t forget to use VMware discovery.|
|Skype for Business Server Front End||444||Will show a lot of clients as this is a distributed application.|
|BMC Control-M||2369, 2370, 6005, 7005, 7006||Often changed during implementation|
|Symantec NetBackup||13720, 13721, 13724, 13782|
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.
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.
Give some considerations such as system requirements or "gotchas" for this setting or control or programming syntax.