Video Screencast Help
Symantec to Separate Into Two Focused, Industry-Leading Technology Companies. Learn more.
Cyber Security Services

Early Incident Detection using a Layer 8 Sensor Array

Created: 04 Aug 2014 • 4 comments
Matt Sherman's picture
+2 2 Votes
Login to vote


I have a calendar alert goes off at 9:30 AM to “Reach out to Layer 8”, which is a little project I devised for myself. When the reminder fires, I open a file called “Friends.txt” that contains several people’s names, departments and phone numbers. I select a name from list and give them a call. This is usually a quick chat. I try to keep the conversation below 15 minutes, and we generally discuss overlap in our roles or projects that we have in common or new projects that the other might not have visibility in to. I end the call by saying something to the effect of “If you see anything weird, let me know”.  This is how I know the status of my Layer 8 sensor array.

I am willing to say that you have these types of contacts in most of the departments in your organization and that you have worked security events with these contacts in the past. I would also say 15 min’s of chat time is nothing when compared to getting hours, if not days of lead-time on a security event.

Lead-time is crucial to success and an actual human, who just happens to be fully versed in the standard functioning of whatever program/system/process they are assigned to, is the exact person you want to give you a heads up. We all have a series of consoles and reports that are run on regular intervals. This will give us information about what has happened, things from the past. It will also give information or alerts on things or events that are known. What about the unknown, the events which are not pre-defined. How would you go about finding out about these events?

You start by looking at “normal”.

The Network Operation team knows what the standard load is on our network segments. They know what the standard ports and protocols used by the majority of the applications are. They know where Core servers “live.” The SQL DBA’s know where the SQL servers are as well. They also know what the transaction logs should look like and they know what instances are housed on each server and what Web servers they connect to. The Web folks know what systems are running what versions of IIS and what versions of Tomcat and Apache. You can see where this is going… They are perfectly versed in what normal looks like and they are perfectly placed to notice when something falls outside of normal.

“But shouldn’t these teams be reporting this information to you as part of your Incident Response Plan?” you ask. The answer is “Yes”. Yes they would, but how much time would be lost before that was the case? How much time would be spent troubleshooting the issue before an alarm is raised? Due-diligence by any team could include cycling services, re-applying patches or service packs. Replacing hardware is not unheard of. All of this takes time. A Layer 8 sensor call could only take a few minutes and your access to security/threat related intelligence is a resource that the other team may not have You can, and most likely already do, even function as a Layer 8 sensor for them as well, letting them know about vulnerabilities or exploits; the type of information that you are versed in.

So, what is the status of your Layer 8 sensor array? I highly recommend putting one in place.

Blog Entry Filed Under:

Comments 4 CommentsJump to latest comment

Robert Shaker's picture

Matt, this is great. I can attest to my success as a customer CISO when I used a layer 8 sensor array :-D

How do you recommend someone go about build a layer 8 sensor array? Do you have any recommendations on building these relationships and what other question you might have for them to think of during an incident they experience?

Bob is a Senior Leader on the Symantec Managed Incident Response Service team. He can be found online at LinkedIn or Twitter

Login to vote
Matt Sherman's picture

The easiest sources would be the people that you have worked with previously. They already know who you are and some of the activates you perform. From there, offer to buy them a cup of coffee. Sitting down for a cup of coffee allows you both to catch up and also gives you a chance to discover if they have contacts in other groups that you might lack. A natural introduction point. The best way to maintain a sensor array is to participate in it. Information cannot just move in one direction.

The questions I would like to have my sensors asking themselves is "I wonder if Matt knows about this yet" and "What details can I gather and preserve to help". These are the same questions I ask of myself when reports of threats or vulnerabilities come across my desk. "Who would this have an impact on and how much useful detail can I provide for them". Again, part of having this array is being a member of it.

Login to vote
Vikram Kumar-SAV to SEP's picture

Totally agree on this article but its easier said than done on ground. more often due to cross-funtional politics and Security team is often seen as a team poking its nose everywhere which is not much welcomed by the IT teams.

So  its very important to get this approach enforced from Top to Down where a mechanism is in place where teams have to interact and share even the minor incidents from IT to Infosec teams and even the InfocSec team has to be very clear why he needs the information and how these issues can impact the overall security or IRP.

It so common to hear huge risks introduced to the company by small changes, sometimes by just adding a script written by a team member to automate things.Tweaking done to improve the performance of an server/application. These are not incidents but these changes are most of the times approved without proper Risk and Impact analysis hence so stakeholders who approve changes should have a mechanism to either report these changes to security team and even within the stakeholders to understand how various changes within DB, Network, Server Administrators, application support and others would impact each other.

Vikram Kumar

Symantec Consultant

The most helpful part of entire Symantec connect is the Search use it.

Login to vote
Matt Sherman's picture

I agree that having "Top to Down" support of a project such as this is critical. These are the types of considerations that should be included in discussions when Turning an Incident Response Plan into a Program as discussed by Clint M. Sand. Having that type of upper level sponsership greatly reduces the need for consant explination as to why you may be asking questions of other groups. An added benefit of say, buying a person on another team a cup of coffee, is that you are building a rapport with that person and therefore that team. Whether as aprt of a formal program or not, when the next incident occurs you will better situated with knowledge of that team and their processes and they will be acquainted with you and your needs.

Login to vote