How to create UDS for IPS/IDS?

User Defined Signatures for IPS/IDS may relate to three basic scenarios of requirement.
# Emergency Situation:  There may be situations where an attack covering particular vulnerabilities may be a very high priority for your network but might not be provided as swiftly as your security policy might require. In this case, you might need to write and deploy strategic signatures based on your knowledge of your network’s vulnerabilities until an update from McAfee is available.
# Forensic Analysis: It may be useful to deploy specialized signatures to investigate suspicious activity on your network and possibly to track intrusions.
# Custom Signatures for Your Particular Environment: Writing custom signatures for your network environment may be necessary for a variety of reasons. The most common is policy enforcement. For example, your security policy may dictate that certain traffic or usage patterns are disallowed. In such cases, it may be useful to write and deploy signatures that can alert your IT or security staff

Steps to create User Defined Signatures
Step 1: Identify the reason for creating this UDS to make appropriate choices

•  Before creating a signature, you should carefully consider the requirement that you are trying to address. This means that you should have a clear understanding of the signature’s purpose, such as a specific business or policy requirement. 
• You should also have a clear rationale for using a signature,instead of another mechanism. In some cases, a User-Defined Signature may not be the appropriate solution. 
• For this reason, you should consider whether you can address your need with other technical means, such as router ACLs, firewall rules, or a network sniffer. 
• Finally, you should verify that the signature you intend to create does not duplicate functionality already provided in the vendors Intrusion Detection/Prevention System

Step 2: Technical information

• A signature is generally based on an advisory or some other description of a known vulnerability. You should have in hand whatever information you can find regarding what the signature will be used to detect. This can include traffic dumps of an attack in progress or the exploit code itself. You can use this information to determine the characteristics of the vulnerability. 
• This information should include specific criteria that comprise the signature, such as field values and patterns to match. Your research may lead to a long list of characteristics specific to the exploit traffic. Bear in mind, however that a signature based on all suspicious characteristics may be too specific. Although it would be precise, it may be inefficient or lead to detection problems. On the other hand, a signature based on only one of the characteristics may be too broad and generate false positives.

Step 3: Protocol in which this UDS will search the traffic (also known as the impact protocol).

• Identify the traffic first (For eg: TCP or UDP) and then look for the specific protocols which you need to monitor/block (For eg: HTTP). It might be possible that the vendor does not support that specific protocol. In that case a more generic platform oriented approach is advised.

Step 4: Specific hardware or software platforms affected by this traffic (also known as impact packages).

• Identify the OS first (For eg: Windows or Linux) and then enable the package which you need to be protected. But remember in case the vendor does not support the specific platform or package it is wise to select some close to your target.

Step 5: Identify the Severity of this event.

• Specifying a severity comes quite handy in the process workflow specifically with importance to the support staff's reactive measures.

Step 6: The direction in which the 'traffic to be watched for' occurs.

• Specify whether the alert needs to be generated for inbound or outbound or both traffic methodologies.

Step 7: Specific criteria that comprise the signature, such as field values and patterns to match.

• Introduce the signature on strings, hex, regular expressions, etc to action on matching with the traffic.

Step 8: A method, data, or tool to be used for testing the signature. Implementing a signature testing plan

• Use traffic generation tools or packet dumps to verify that your signature(s) match the traffic you intend it to detect.
• Verify that your signature is not duplicating functionality already provided by the Sensor by examining whether your test traffic raises additional alerts other than UDS.
• Deploy the signature to a non-production Sensor connected to either a test network that duplicates your production network traffic or a non-production Sensor connected to your production network in Span or Tap mode.

Signature Components:
# Select:
- Sensors
- Inbound/Outbound
- Range of IP/Host (optional)
- Protocol
- Ports
- Pattern/String/Numeric Comparison
- Mode (Alert/Block/Drop)
- Severity
# Logical Constructs:
The logical constructs provide methods for grouping and ordering the more granular pieces of the signature - numeric tests and pattern matches - in any order you require. The core constructs are:
•  AND- Tests are grouped within AND blocks. The tests must all succeed, but may occur in any order inside the context of a given flow. AND blocks cannot be contained within an OR condition.
•  OR- The first test to succeed fulfills the condition, and the next AND or OR block is engaged. OR constructs are contained withinAND blocks, though at times they may be the only contents.
•  ANDTHEN- ANDTHEN is the ordering construct. By placing ANDTHEN statements between AND blocks, you can create a structured order for your tests, if required.
# Detecting Windows:
The detection window is the portion of the traffic flow that a signature should examine for signature matches. The detection window may be one of:
- Packet- All of the signature tests (and thus all protocol fields) must occur in a single packet on the network.
- Request- All of the signature tests must occur in the request direction of the flow. (Useful if the protocol is bidirectional and might include the same data or commands in either direction.)
- Response- Identical to request, but used to examine only response-direction traffic.
- Flow- When the detection window is set to flow, all conditions can be fulfilled by traffic flowing in either direction. Tests are still subject to any ordering imposed by the structure of the signature or flow direction implied by the field being tested.
- Benign Trigger Probability- This is a measure of the confidence with which the signature writer believes the signature can identify a network event. A high benign trigger probability (BTP) implies that a signature may be prone to false positives. When creating a UDS, you should set the BTP to “Low” to ensure that your signatures are selected by the Default Policy.
- Severity- Severity is simply an indication of how severe the signature writer believes the network event detected by the signature to be. You should set the Severity to at least “Medium” to ensure that the signatures will be selected by the Default Policy.

Please note that this article can be very helpful for those who uses McAfee Network Security Platform *formerly Intrushield*. But it can act as a generic one as well as most of the steps are common in all IDPS with the components might vary in some.