PH_Rule_Change_4
Disabled
Detects that the configuration of a network device (router or firewall) has changed. This is achieved via logging in and keeping track of the last config. The IP address of the user likely to have executed the change, is obtained from a preceding syslog that indicates a prior login. This rule requires the network devices to forward syslog to the monitoring system.
6
Change
Defense Evasion
Defense Evasion consists of techniques that adversaries use to avoid detection throughout their compromise. Techniques used for defense evasion include uninstalling/disabling security software or obfuscating/encrypting data and scripts. Adversaries also leverage and abuse trusted processes to hide and masquerade their malware. Other tactics’ techniques are cross-listed here when those techniques include the added benefit of subverting defenses.
https://attack.mitre.org/tactics/TA0005T1562.004
Impair Defenses: Disable or Modify System Firewall
Adversaries may disable or modify system firewalls in order to bypass controls limiting network usage. Changes could be disabling the entire mechanism as well as adding, deleting, or modifying particular rules. This can be done numerous ways depending on the operating system, including via command-line, editing Windows Registry keys, and Windows Control Panel. Modifying or disabling a system firewall may enable adversary C2 communications, lateral movement, and/or data exfiltration that would otherwise not be allowed.
https://attack.mitre.org/techniques/T1562/004Network
Cisco IOS, Cisco ASA, Foundry Ironware Config Change Monitoring via Syslog
Correlation
Make sure it is an authorized change
If the following pattern or patterns match an ingested event within the given time window in seconds, trigger an incident.
1800 secondsIf the following defined pattern/s occur within a 1800 second time window.
loginOrChangeEvent FOLLOWED_BY deltaThis defines how two or more distinct events are related in a time-series based action. e.g. An event occurs followed by another event if the source IP, user, and messageId are the same
loginOrChangeEvent.reptDevIpAddr = delta.hostIpAddrThis is the named definition of the event query, this is important if multiple subpatterns are defined to distinguish them.
This is the query logic that matches incoming events
eventType = "IOS-SYS-CONFIG_I" OR eventType = "ASA-605005" OR eventType = "Foundry-Ironware-Running-Config-Change"This defines how matching events are aggregated, only events with the same matching attribute values are grouped into one unique incident ID
reptDevIpAddr ,srcIpAddrThis is most typically a numerical constraint that defines when the rule should trigger an incident
COUNT (*) >= 1Operator Rank: 0 Operator Type: FOLLOWED_BYThis operator defines the logic condition relating to the prior event subpattern clause and the following event subpattern clause
This is the named definition of the event query, this is important if multiple subpatterns are defined to distinguish them.
This is the query logic that matches incoming events
eventType = "PH_DEV_MON_CHANGE_RUN_CONFIG"This defines how matching events are aggregated, only events with the same matching attribute values are grouped into one unique incident ID
hostIpAddr ,hostName ,addedItem ,deletedItemThis is most typically a numerical constraint that defines when the rule should trigger an incident
COUNT (*) >= 1This section defines which fields in matching raw events should be mapped to the incident attributes in the resulting incident.
The available raw event attributes to map are limited to the group by attributes and the aggregate event constraint fields for each subpattern
srcIpAddr = loginOrChangeEvent.srcIpAddr,
hostIpAddr = delta.hostIpAddr,
hostName = delta.hostName,
addedItem = delta.addedItem,
deletedItem = delta.deletedItem