Visit to Symantec Security Ops Center

Last week I was invited to visit the Symantec Security Operations Center (SOC) in Alexandria, VA. I had been there twice before, before they acquired Riptech and after. Jonah Paransky, Director of Product Management for MSS, answered many of my technical and business questions.

On this trip I learned that Symantec operates two 24x7x365 SOCs (in the USA and the UK), along with one in Europe, one in Japan, and other support centers. They do not collect and store security data at the SOC; instead, they have they data pouring into colocation facilities elsewhere.

Jonah said they see 3000-4000 "potential" incidents per day, of which about 100 are considered "hard kills." I couldn't tell if that meant actual compromise or not, but those 100 events per day prompt calls to customers.

We discussed the nature of their customer base. Symantec provides managed security services to many global 500 companies, some "with security staffs larger than Symantec's." I asked why such a company would bother with MSSP? Jonah responded with these points:

  1. It's expensive to hire a team of analysts to inspect and react to security events on a 24x7x265 basis. My own experience says that requires hiring 12 people if you want 2 people on shift.

  2. Analysts watching a single company -- even a very large one -- get bored fast. This is true. If your company cares enough to staff a security operation like this, they are probably not bleeding like a .edu. (Ever notice the best papers come from .edu's and not's?)

  3. Symantec's global perspective, combined with local data, gives customers a sense of what is happening on the Internet and their networks. In other words, customers hire Symantec to provide a data feed that those large security staffs can interpret and work. Customers see "everything" that Symantec's analysts see. This is a change from the environment five years ago.

Jonah noted that Symantec undergoes a Statement on Auditing Standards (SAS) No. 70 Type II audit every year. The process takes 2 months out of 12 (ouch). The end result, however, is a document that shows all of the processes Symantec follows, along with a measurement of Symantec's adherence to those processes. This is very valuable for customers, who previously would require Symantec to undergo on-demand audits prior to signing up for MSS. Now, Symantec hands them the SAS 70 Type II audit report and the customer is SOX-satisfied. Symantec also follows ISO 27001 standards.

Overall, I was impressed by what I saw. I was a little concerned by the emphasis on process over outcomes, however. While it's good to be audited for adherence to processes, it would be better to determine if those processes result in improved incident detection and response. I doubt the auditors attack Symantec clients to test the responsiveness of the analyst staff.

This thought came to mind during the visit, and also later when one of my customers called. They're planning to bring their monitoring services back in-house, as they fear their vendor is too malware-focused. This customer wants me to help them build an in-house network security monitoring, incident response, and forensics operation, to be completed by the end of next year. That should be a great project.

I'm considering the value of something like Symantec Early Warning Services for my customers who run their own MSS SOCs. An early warning service can provide indicators that might be absent in an operation focused on a single company.

Thank you to Jonah and the other folks from Symantec and their partners who answered my questions and let us tour their facility.


Anonymous said…

You think it would be better for auditors (who, in most cases, are accountants) to tell you how to do security, rather than to tell you whether you are doing what you tell customers you do? If so, I respectfully disagree.

The role of the infosec expert should be in devising the control objectives, the means by which they are attained, and how the degree to which they are/are not obtained is measured. The role of the auditor, in this case the accountant who prepares the SAS 70 level II letter, should be to state whether the controls used were operating effectively enough to achive the control objectives.

Possibly you are saying not that *the auditor* should focus on having sound control objectives, and measuring performance rather than process-adherence, but that *somebody* should. I wholeheartedly agree -- I just don't want auditors doing it. They generally lack the skills, and this opens conflict of interest areas that auditors are rightfully concerned about.

Customers need to be prepared not to just say "Yup. They got a SAS-70 level II letter, so they must be good". They need to be able to evaluate whether the control objectives are appropriate, and to ask hard questions about internal processes -- including measurement -- at the 3rd party service organization. This can occur, for example, in an RFP or RFI.

I didn't say anything like that. In fact, I was "concerned by the emphasis on process over outcomes." The rest of that paragraph shows I don't believe auditors know anything about security.
Anonymous said…
Hey Richard
is that nagios on the right hand side of the globe ?, bsd or linux ?

Since it's a stock photo, it can be whatever you think it is. :)
Anonymous said…
don't forget msn messenger in the middle :)

Popular posts from this blog

Five Reasons I Want China Running Its Own Software

Cybersecurity Domains Mind Map

A Brief History of the Internet in Northern Virginia