Sensor placement can be very tricky as there are loads of variables to consider. At minimum, you should take into account

• Classification level of monitored resource
• Network design
• System throughput
• Personnel time (for management and analysis)
• Resource availability

Throwing all of those into a blender and turning on high for a few minutes will give you some nice data to start with for determining your deployment. Deployment planning is a multiphase process, and while they are not intrinsically separated, it is beneficial to remember that they are different parts of the same plan.

##Data Collection and Planning##

More likely than not, what you're going to want to do is construct a list of all of the systems that you want to monitor, then rate them based on importance or risk. That should give you a prioritization of what systems you really need to be watching now. In a perfect world, we would have a sensor monitoring the link connected to each and every system. However, that would be scary expensive, difficult to maintain, and noisy. Instead, talk to your network team and take a good hard look at your network design. Figure out on the network map where your prioritized systems live and figure out where the choke points are. Look at what hardware you have available to turn into sensors. In an awesome environment, you could have one big box with a few 10Gbps interfaces and do all of your monitoring for an entire enterprise using a single sensor. However, more likely, you're going to have a few surplus systems that used to be used by department secretaries and will need to spread the load.

##Array Design and Deployment##

Now is the time to think long and hard about what risk acceptance threshold is. How close to the sensitive data do you feel like you need to have a sensor, and how far away do you feel comfortable placing it? In some cases you may really need to monitor the switch port that a server is directly connected to. In other cases placing a single sensor on a building or floor uplink, and ignoring any intra-switch traffic, is sufficient. In another case you may feel as if mirroring a specific port is not good enough, and instead mirror an entire VLAN.

##Workload and Other Considerations##

As you're building our your sensor deployment strategy keep in mind that it can get very complicated. As you decide where to place your sensors, make sure to account for all of the other issues that arise. For every sensor you deploy there will be management overhead for an employee to actually maintain the system (apply patches, hardware replacement, etc), application management overhead (updating signatures, tweaking rulesets, making sure snortd stays running), and analyst time (interpreting the alerts and taking action). Depending on your design, and how much time you're willing to front-load, these numbers can vary wildly. For example, using the right configuration management/automation tools, it's not that difficult to manage several dozen snort sensors using a fraction of an FTE.

For full disclosure this was originally posted as answer to this question. We're not sure it's worth merging them, but the answer definitely works here too.

Sensor placement can be very tricky as there are loads of variables to consider. At minimum, you should take into account

• Classification level of monitored resource
• Network design
• System throughput
• Personnel time (for management and analysis)
• Resource availability

Throwing all of those into a blender and turning on high for a few minutes will give you some nice data to start with for determining your deployment. Deployment planning is a multiphase process, and while they are not intrinsically separated, it is beneficial to remember that they are different parts of the same plan.

Data Collection and Planning

More likely than not, what you're going to want to do is construct a list of all of the systems that you want to monitor, then rate them based on importance or risk. That should give you a prioritization of what systems you really need to be watching now. In a perfect world, we would have a sensor monitoring the link connected to each and every system. However, that would be scary expensive, difficult to maintain, and noisy. Instead, talk to your network team and take a good hard look at your network design. Figure out on the network map where your prioritized systems live and figure out where the choke points are. Look at what hardware you have available to turn into sensors. In an awesome environment, you could have one big box with a few 10Gbps interfaces and do all of your monitoring for an entire enterprise using a single sensor. However, more likely, you're going to have a few surplus systems that used to be used by department secretaries and will need to spread the load.

Array Design and Deployment

Now is the time to think long and hard about what risk acceptance threshold is. How close to the sensitive data do you feel like you need to have a sensor, and how far away do you feel comfortable placing it? In some cases you may really need to monitor the switch port that a server is directly connected to. In other cases placing a single sensor on a building or floor uplink, and ignoring any intra-switch traffic, is sufficient. In another case you may feel as if mirroring a specific port is not good enough, and instead mirror an entire VLAN.

Workload and Other Considerations

As you're building our your sensor deployment strategy keep in mind that it can get very complicated. As you decide where to place your sensors, make sure to account for all of the other issues that arise. For every sensor you deploy there will be management overhead for an employee to actually maintain the system (apply patches, hardware replacement, etc), application management overhead (updating signatures, tweaking rulesets, making sure snortd stays running), and analyst time (interpreting the alerts and taking action). Depending on your design, and how much time you're willing to front-load, these numbers can vary wildly. For example, using the right configuration management/automation tools, it's not that difficult to manage several dozen snort sensors using a fraction of an FTE.

For full disclosure this was originally posted as answer to this question. We're not sure it's worth merging them, but the answer definitely works here too.

Sensor placement can be very tricky as there are loads of variables to consider. At minimum, you should take into account

• Classification level of monitored resource
• Network design
• System throughput
• Personnel time (for management and analysis)
• Resource availability

Throwing all of those into a blender and turning on high for a few minutes will give you some nice data to start with for determining your deployment. Deployment planning is a multiphase process, and while they are not intrinsically separated, it is beneficial to remember that they are different parts of the same plan.

##Data Collection and Planning##

More likely than not, what you're going to want to do is construct a list of all of the systems that you want to monitor, then rate them based on importance or risk. That should give you a prioritization of what systems you really need to be watching now. In a perfect world, we would have a sensor monitoring the link connected to each and every system. However, that would be scary expensive, difficult to maintain, and noisy. Instead, talk to your network team and take a good hard look at your network design. Figure out on the network map where your prioritized systems live and figure out where the choke points are. Look at what hardware you have available to turn into sensors. In an awesome environment, you could have one big box with a few 10Gbps interfaces and do all of your monitoring for an entire enterprise using a single sensor. However, more likely, you're going to have a few surplus systems that used to be used by department secretaries and will need to spread the load.

##Array Design and Deployment##

Now is the time to think long and hard about what risk acceptance threshold is. How close to the sensitive data do you feel like you need to have a sensor, and how far away do you feel comfortable placing it? In some cases you may really need to monitor the switch port that a server is directly connected to. In other cases placing a single sensor on a building or floor uplink, and ignoring any intra-switch traffic, is sufficient. In another case you may feel as if mirroring a specific port is not good enough, and instead mirror an entire VLAN.

##Workload and Other Considerations##

As you're building our your sensor deployment strategy keep in mind that it can get very complicated. As you decide where to place your sensors, make sure to account for all of the other issues that arise. For every sensor you deploy there will be management overhead for an employee to actually maintain the system (apply patches, hardware replacement, etc), application management overhead (updating signatures, tweaking rulesets, making sure snortd stays running), and analyst time (interpreting the alerts and taking action). Depending on your design, and how much time you're willing to front-load, these numbers can vary wildly. For example, using the right configuration management/automation tools, it's not that difficult to manage several dozen snort sensors using a fraction of an FTE.

For full disclosure this was originally posted as answer to this question. We're not sure it's worth merging them, but the answer definitely works here too.

Sensor placement can be very tricky as there are loads of variables to consider. At minimum, you should take into account

• Classification level of monitored resource
• Network design
• System throughput
• Personnel time (for management and analysis)
• Resource availability

Throwing all of those into a blender and turning on high for a few minutes will give you some nice data to start with for determining your deployment. Deployment planning is a multiphase process, and while they are not intrinsically separated, it is beneficial to remember that they are different parts of the same plan.

##Data Collection and Planning##

More likely than not, what you're going to want to do is construct a list of all of the systems that you want to monitor, then rate them based on importance or risk. That should give you a prioritization of what systems you really need to be watching now. In a perfect world, we would have a sensor monitoring the link connected to each and every system. However, that would be scary expensive, difficult to maintain, and noisy. Instead, talk to your network team and take a good hard look at your network design. Figure out on the network map where your prioritized systems live and figure out where the choke points are. Look at what hardware you have available to turn into sensors. In an awesome environment, you could have one big box with a few 10Gbps interfaces and do all of your monitoring for an entire enterprise using a single sensor. However, more likely, you're going to have a few surplus systems that used to be used by department secretaries and will need to spread the load.

##Array Design and Deployment##

Now is the time to think long and hard about what risk acceptance threshold is. How close to the sensitive data do you feel like you need to have a sensor, and how far away do you feel comfortable placing it? In some cases you may really need to monitor the switch port that a server is directly connected to. In other cases placing a single sensor on a building or floor uplink, and ignoring any intra-switch traffic, is sufficient. In another case you may feel as if mirroring a specific port is not good enough, and instead mirror an entire VLAN.

##Workload and Other Considerations##

As you're building our your sensor deployment strategy keep in mind that it can get very complicated. As you decide where to place your sensors, make sure to account for all of the other issues that arise. For every sensor you deploy there will be management overhead for an employee to actually maintain the system (apply patches, hardware replacement, etc), application management overhead (updating signatures, tweaking rulesets, making sure snortd stays running), and analyst time (interpreting the alerts and taking action). Depending on your design, and how much time you're willing to front-load, these numbers can vary wildly. For example, using the right configuration management/automation tools, it's not that difficult to manage several dozen snort sensors using a fraction of an FTE.

For full disclosure this was originally posted as answer to this question. We're not sure it's worth merging them, but the answer definitely works here too.