Note if you are on AirDefense 10.x the below example is illustrated in "legacy GUI" (or 9.5 GUI).
- Security profiles control what alarms will or will not trigger for a given device or BSS depending on the mode of operation of the device.
For Example, if a device is using TKIP and the Security Profile is set to allow TKIP, no alarm will trigger. If the Security Profile does NOT allow TKIP, an alarm will trigger.
• Although Security profiles are set using the SSID as a "keyword", when the security profiles are set to a folder, they are additive.
• This is by design, as a device or BSS residing in that folder may have multiple SSIDs it can use.
• The same rules apply to all SSIDs in use in that folder (or more accurately, the physical location represented by that folder).
• Therefore it is important to set Security Profiles to the folders where the rules within the Security Profile apply, and not allow any Security profiles to be applied to that same folder.
• If all the Security Profiles are set at the base (appliance level) and just allowed to propagate down the tree by inheritance (which is neither best or recommended practice), then every device in every folder will be subject to the rules in ALL Security Profiles. This is rarely the desired operation.
• The preferred and recommended way is to create the Security Profiles (one for each SSID) and go into the folders where devices are to be controlled by the rule set within that profile and (still in Security Profile configuration) and apply an override on that folder, then assign ONLY the single Security Profile which applies to that folder (the determining "key" in Security profiles is the SSID value, so I'm really saying put the Profile which controls the factors for an SSID in the folder(s) where that SSID will be present in the environment).
This will prevent False Positive alarms caused by conflicting Security Profile rule sets.
• To continue the simple example above,
• if one profile is set of TKIP ONLY and another is set for AES ONLY and both are set to the same folder, then when a device correctly using TKIP at that location is seen by a sensor
• ADSP will raise a False Positive alarm because the device is NOT using AES.
• Considering that there are as many as a hundred different configurable controls in a Security Profile, the number of FP alarms due to incorrect Security Profile placement can become very large in a very short time.
• The actual override need not be set for each floor folder.
• Some logic must be applied when setting the override.
• If a particular Campus uses only one SSID and only one set of rules to control the alarms for that Campus, then the override should be set (assigned the correct Security Profile) at the campus level, and let the Buildings and Floors inherit from the Campus folder.
•If the establishment only uses a single SSID and a single Security Profile to control the ADSP alarms on that SSID, then inheritance is fine, but in most real-world situations, the Security profiles MUST be distributed among the folders and/or branches of the tree using Overrides.