All too often I hear the complexities of managing a centrallly deployed intrusion detection and prevention system in various types of environments. Some might add that the cost of implementing, maintaining, updating, and training personnel is becoming a nefarious act of constant contact with one’s bank accounts. This doesn’t always need to be the case, and is why I like to highlight the options one has when attempted to build-up perimeter security at the drop of a hat. The options listed below are not endorsed specifically by Black Bear, nor are these the only options available. Keep in mind that your particular solution needs to be scalable, affordable, manageable, and overall tunable to the requirements of your network.
Let’s start this one off with a BANG shall we? A topic of conversation to be had over various types of food and drink could be the inclusion of Cloud security implementation. What one does in order to fully secure someone else’s data center, you ask? Well, in order to fully implement a solution that allows you to monitor, track, and potentially block unwanted traffic, you’ll need to provide a system that also works with hosted data center operations such as AWS
The EC2 Instance offers several products that you can implement within AWS administration. Again, there may be more out there, but these are the ones that have been vetted by our teams the most.
McAfee Virtual Network Security Platform (vNSP)
Trend Micro Deep Security
Alert Logic Threat Manager
Feel free to research these products individually or compliment with your own hosted version of the next recommendations.
The Bro Network Security Monitor - @Bro_IDS - has always been a personal favorite of mine. The language used is highly adaptable and being an open-source product, the development of the project from the community perspective is heavily established.
Bro is easily downloaded and running in minutes. Optional dependencies can be brought down separately such as a send mail server to enable the Bro/BroControl alerting to email feature or LibGeoIP for geolocation IP addresses.
The development code base is readily available on git - git clone —recursive git://git.bro.org/bro
The Bro Center of expertise, funded by the NSF, is available to provide extended support to all Bro users at an extremely low-cost.
Catch on their Bro conferences such as BroCon in Arlington, VA (2018) and the Bro Workshop in the EU (2018)
The Security Onion - @SecurityOnion - has long been another personal favorite of mine and widely used amongst IT Security professionals on the basis of power, efficiency, familiarity and minimal installation overhead. Although the SO is not exclusively an IDS/IPS tool directly, it utilizes other IDS tools (as previously mentioned, Bro, and others such as Snort, Suricata, and HIDS based tools such as OSSEC to collect all the information you need in making secure decisions about your networks and hosts. Built-in tools such as Squert provide allow you to query the data easily.
Althought the Security Onion is not exclusively an IDS/IPS program, it brings many of the popular referenced tools together in one suite. It is all encompassing and extremely powerful in bringing visibility to your network’s traffic.
Cisco’s Firepower and FireAMP - @cisco - One of the bigger box company solutions that has been up and coming in recent years are the Firepower systems provided by Cisco. The base ideals set forth by the FP systems are built on Snort detection engines for IDS/IPS and an integration with HIDS based software and IronPort systems through the AMP product. Literally, AMP is everywhere in the Cisco world! This model gives you end-to-end visibility into exactly what your network is doing, how often it is doing it, and where IT is coming from or moving to. Althought the Firepower product itself is not exclusive to IDS/IPS, as it includes modules for host identification, simple URL filtering, and VPN concentration, the overall layered approach to detecting unwanted traffic is still the gleaming purpose of the Cisco Firepower system.
Here are some highlighted items to take into consideration when using Firepower.
Policies are exclusive to HTTPS, HTTP, File, and TCP/UDP based traffic.
Keep in mind that in order for the Firepower to process data about the traffic within the network, it needs to be “implanted” on everyday endpoint or pass-through point, including the perimeter, the hosts, and cloud-connected services such as IronPort.
Source and destination security zones are key in determining the sensors for the traffic. Without clearly defining these zones, traffic will not be logged, analyzed, or blocked
Keeping up with the recommendations added to the Snort definitions can be daunting in the interface itself. Take advantage of scheduled updates to the Snort selections by utilizing a timed installation and reviewing the change reports prior to final tuning.
Overall, there are numerous solutions available, both free and at cost, too allow business the security and flexibility of modern day IDS/IPS systems. It’s important to understand the needs of your organization and the traansparency that you require over the landscape of any network prior to implementing an IDS/IPS system. Modern day systems provide less hassle in maintaining complex rule sets and responding to monitored incidents than before. That also means that tuning these systems is key in order to provide the most benefit without overloading the network, or your users. As such, here are some bullet points to consider when implementing IDS/IPS.
Cost must be efficient in all scenarios. You never want to have to answer to security budget defencies by cutting the IDS system out of the equation. These systems should be implemented as a necessity to current Internet usage trends, especially with the ever increasing mobile and mobile device workforce. Make sure to allocate more than enough funds annually and always come in under budget.
Tuning for performance, and efficiency. The IDS system and alert on all events and monitor large amounts of traffic. To ensure the usefulness of the system, only flagged events would require and alert while others can be simply discarded. It does beg the question, however, if there are no alerts, is the system really working as designed? If there are TOO many alerts, this could also be the case. Thresholds to alert should be evaluated based on their legitimacy; identifying false-positives wherever possible. If the IPS is also tuned to drop events that are related to alerts, you want to ensure that false-positives are addressed appropriately. Otherwise legitimate traffic may be blocked.
Throughout the article, I lump IDS/IPS systems in one liners. The truth is, they have their differences from an operational perspective. The IDS system is typically out-of-band. It does not need to be implanted in all areas of the network as inline and can be used out-of-band in order to limit the ill-effects of an IDS failure causing overall network communication issues. IPS systems are almost always inline with the existing network traffic and connectivity. They typically will have a fail-open or fail-closed requirement; if the IPS system is no longer able to block traffic, it should stop all network traffic or allow all network traffic, depending on your availability model.
I hope this article was informative and sparks interest in using some of the options listed above. Stay tuned next time for ideas on how to implement proper IDS or IPS strategy within your network, using one or more of the options from this article.