Managed SIEM/MSSP dos and don'ts

These are some pointers that would benefit you if you are thinking of going to an MSSP (Managed Security Service Provider) for a SIEM service (Security Information Event Management). The sooner you consider those points the better for your organisations security posture.

• Define a security policy. If you don't have one or think that you don't need one, and still insist on having a SIEM MSSP, you probably want it for the nice flashing lights and graphs in which case you need to invest heavily on a year-long X-mas tree. It will cost less and thousands of professionals around the world will thank you for it. When you are done with the security policy share it with your MSSP. The rules they will use to protect your network will depend on it.
• Don't ask "what other similar companies are doing?" if you do, it means that you haven't thought of point one seriously enough. For the romantics among us, companies are like snowflakes so... back to point 1. Each environment differs and should be given the right amount of attention to detail to optimize as best as possible. Security out-of-the-box DOES NOT WORK. 
• Define your scope correctly even if it "kills" you. Positioning of sensors can be crucial your your project (architecture wise). Asset management is key here, you can't secure things you don't know you have! 
• After you defined the scope... don't change it (or at least accept that changing it can have dramatic impact on your project delivery date). People that say that can hit a moving target are most likely lying to you.
• You need to make sure you are logging the right stuff. When you don't have auditd enabled on your Linux boxes it wont matter if you are sending the syslog over to your SIEM... the rule wont fire because the TRIGGER is missing. Testing your rules is not bad, testing all of them is though, pick some in random... yet covering all technologies you want to on-board.
• Select rules that are related to your technologies. Everything causes resource creep these days so if you don't have Oracle or MSSQL, don't select the Database specific rules.
• Feed the right technologies to your MSSP. If you can afford to feed everything to your MSSP, do so, but if you have to pick between two sources select the one that will contain the most valuable data. Oracle database feed or Proxy feed? Proxy feed of course! NIDS and Proxy feeds are two of the most valuable resources an Incident Handler can have (Payloads included!).
• Is there a third party involved in your network? You need to add that delay not just on your on-boarding phase, but on your tuning and most importantly on every incident's triage phase as well. Those relationships need to be carefully defined and managed. 
• Be prepared, when on-boarding a particular technology take note on who controls it, who manages it and what steps are needed to implement changes to it, when tuning comes into play you want to be ready to react. You can minimize the tuning process by being ready to make decisions and acting on them asap.
• Configure access appropriately. If you expect people to manage your firewall or extract data from your NIDS, don't just make them an account on the box, make sure they have VPN access to the box as well! 
• Don't try to hide form your SIEM, network diagrams, device configuration (inline/span-tap) are a goldmine of information for analysts and handlers. Just make sure you don't give them War and Peace to read... be informative and to the point. Remember, you are trying to integrate with these people! 
• Different MSSPs do different things for different companies. In your case what are they hired to do? Monitoring/detection/triage/incident response the big ones can do all but whats in your contract? If there a gap find it and eliminate it.
• Make sure the incident contact procedure is clearly defined and tested. You need to cover different levels of alerts since you don't want an email or a phone call every time Bob miss-types his password (sorry to call you out like that Bob). Your process also needs to contain alternatives, yes when using an email you will wisely use a mailing alias you control and all team members will be notified... but what about phone calls? Availability of the people on that process needs to be taken into account so the "red" phone needs to rotate but also secondary and even tertiary numbers should be made available. 
• How is your SLA standing? is it feasible or is it achieved by the usual ticketing system tricks? Most of all have realistic expectations if you want action within 15 mins you need to be quick enough to authorize it (would you be willing to let your MSSP have his finger on the trigger?) but also be willing to pay top dollar for it. Since you are paying top dollar for it have a process review process to make sure everything is as it should be as well.
• Do not attempt to shorten the tuning period. Analysts need time to collect data and assess what is noise and what is useful, what should be tuned out and what should be left as is. Keep in mind that tuning should be an ongoing process and not something that is done over a 6-8 week period and then left as is. IDS Signatures, Firewall rules, and environments in general change over periods of time so you should keep on top of it on a permanent basis.
• Do not ask the Analysts to start tuning your data before the on-boarding is completed. Tuning is a time consuming, borderline tedious process that is vital to your service and it can change from one day to another if you keep changing your network. Asking an analyst to start tuning while you are on-boarding is asking them to do the same work multiple times. 
• Aim to on-board your technologies according to category. If you finish on-boarding all your windows or IDS sensors, the Analyst can focus on tuning individual technologies and probably save you some time.
• You should know what reports you will be getting, what they contain and how they will be populated. Confirm the reports work and that they provide you with enough information to be actionable (Bob failed to login but from which IP address/MAC?) . If you are able to schedule your own reports make sure you do so at the rate you are able to consume them. No reason to be ruining daily reports if you can't afford to look at them every day!
• Lastly do not fall into the EPS trap (Events Per Second), just because most MSSPs will be charging you accordingly (as they should since more EPS = more resources feeding in) it does not mean that you should be minimizing the event sources you are feeding in to your MSSP. What you ultimately care about is what comes out from the SIEM. Actionable alerts and meaningful reports. You should strive to configure and maintain devices that feed in the SIEM only what is valuable to the analysts.

That's all for now :)