RSA needs to resolve the basic components of the ESA correlation :
Synonymous language between ESA / reporting -- the language syntax between the ESA and the reporting is not the same. Should be consistent among the SIEM product.
ESA Syntax garbage -- There are ALOT of language gotchas that aren't really documented, and users have to enable auditing on esa rules, and hunt down logs on the esa appliance to help try and troubleshoot whether the syntax is proper or not. Example, is escaping characters, leveraging underscores versus dots (see above for language synonymous), and case sensitivity. Users should be able to copy/paste queries from searches/reports into esa rule builder and correlate as needed (see below for ESA / Query synonymous syntax).
ESA Rule Building Interface -- Users shouldn't have to touch esper language at all. This is a clear indicator that ESA was released before production release. Any / every type of rule should be easily built into the ESA rule building interface. Alot of RSA documentation shows that whenever users would like to create an advanced rule, they should ....copy/paste....another rule for syntax. This is NOT a good explanation/usage of the product, as it shows that the syntax is not easily achievable.
ESA / Query synonymous syntax -- Would be nice is RSA implemented an ability for users to enter the same syntax that they are able to leverage with existing queries, and paste this into rule syntax. This would be a great ability for users to a greater ability to identify whether the rule will fire properly. Instead of users having to learn another language (esper), they could leverage existing/KNOWN queries that are able to find results, and have RSA built an interpretation of this syntax into the backend esper that they chose to leverage for correlation.
Builtin logging to SA -- RSA Needs to implement a built in ability for ESA to feeds information to SA by default. This is SIEM 101, users shouldn't have to build extra functionality to leverage a basic component of a SIEM. Users should be able to search/report/chart on Correlation information by default. I know there is the incident management module, and tie-ins to archer, but these are additional overhead, managment & setup to get these going.
ESA Rule Replay -- RSA needs to implement an ability to test potential esa rules against live / archived data as the only way to test rules now is to inject log samples...of which some arent able to inject (windows logs, database logs,etc...) So every time we are able to test some ESA rules are to recreate the activity on the end ...every...time we want to test.
ESA Rule Expiration -- RSA should have an expiration date applied to certain rules if users chose this. Most rules are needed to be looked at and/or modified/disabled after a certain period of time. This would alleviate some management overhead of trying to manually document when the rule was created, and by who. Should allow notification of expiration before X time when the rule is to expire
ESA Rule documentation -- RSA Should implement fields such as when the rule was created AND by whom. Extra fields would be helpful such as description, log sources / device types applicable (alerting on), requestor, and output action. These fields would make it easier to implement ability to report on ESA intel (see below).
Reporting on ESA Intel -- RSA need to implement ability to create reporting on correlation rule information. There are several times when auditors come in and ask what are we monitoring. There is no built in ability to report on the correlation rules that are put into production. Need basic reporting on items such as : how many rules are in production (enabled), what log sources are needed for X,Y,Z rules to fire, what rules are leveraging email notifications, who are getting email notifications, and the ability to get a count of how many rules are monitoring each different type of log (device.type).
ESA List Ability -- Need an ability to reference lists within the ESA for consistency/usage of assets/items within a rule. For instance tuning in/out specific hostnames/urls within an RSA rule. These lists should be consistent with the reporting engine lists, so that users should only have one point of reference of maintaining/managing lists.