I started my professional career as a cybersecurity engineer/analyst and part of that job consisted on deploying, customizing and operating security technologies as well as analyzing security events to identify and contain real threats. I found that last part to be my favorite as it was really fun and also very challenging; as some of you might know, finding the relevant threats can feel just like trying to find a needle in a hay-sack.
Security operations was overwhelming 10 years ago and it still is, many companies or organizations fill themselves with security "solutions" rather than focusing on a security architecture which ultimately leads to small teams of engineers and analysts navigating a sea of consoles, logs and security events that they somehow need to make sense of, analyze and correlate in the hope of finding relevant threats, threats that could indicate a potential or actual security breach, events that are meaningful to the organization; the ones that could certainly cause a negative impact.
Makings sense of relevant security events for a specific threat of a specific vulnerability for a specific element of a specific network of a specific cloud of a particular organization is a fundamental requirement to successfully reduce two crucial security metrics: TTD (time-to-detect) and TTR (time-to-respond). Why are they crucial? The shorter the time we take to detect that something is wrong and the shorter the time we take to contain and remediate that incident, the lower the resultant impact. Think about it, we've all head of a high impact security breach, and when we learn that the attackers were inside the network or the server for months or even years, suddenly everything falls into place.
Network intrusion prevention systems (IPS) are one of the oldest security technologies but that doesn't make them obsolete; even with the increased adoption of the Cloud (whatever the flavor or consumption model), network traffic inspection to detect and block threats is still a major security capability required for a robust security architecture. That's why most IPS vendors now have a virtual option for public and private clouds; also, that is why the SASE model has brought the idea of delivering the IPS capability natively from the cloud.
FTD (Firewall Threat Defense) is the current name (and believe me it has changed a few times) of Cisco's Next Generation Firewall/IPS and has its origins in the legendary Sourcefire; a company acquired by Cisco in 2013. I consider FTD is not just a great piece of technology, but also a technology that has made easier the life of many security teams resulting in stronger network defense capabilities for multiple organizations around the world.
The time of the security engineer is valuable, it should be used wisely
Many organizations and security teams fail believing the IPS just needs to sit there and block stuff; they forget that security events need to be investigated as well, the reason for that is that a security event, even if it has blocked the traffic, could be only the tip of the iceberg, it could be an indication of a large scale staged attack or even an indication that there has already been a security breach.
I remember myself, during those days as a security engineer, looking at the screen and scrolling at the security events GUI or console of many different IPS solutions using a typical algorithm to find "impactful" events and prioritize my investigations. If you have ever been in the same situation I'm sure that you have also used this method, I call it the "do what you can method". The process is simple, you sort the latest security events based on the their severity and start working on them, first the ones with critical severity, then the high severity ones and so on.
The "do what you can method" doesn't scale at all, I used to feel lucky if I ever completed the investigation of only the critical events during my shift. Also, it is awfully frustrating because this method has an enormous flaw: using the event severity to sort the prioritization of your investigation won't guarantee that you are using your time on what's important. That is because the severity assigned to an IPS security event is hardcoded and it depends mainly on the nature of the attack, threat or vulnerability associated to the IPS signature that triggered the event, but it doesn't take into consideration the characteristics of that specific environment or network that the IPS is trying to protect.
Many times I found myself investigating what appeared to be a critical security event just to find out that the event had zero impact to my network. How could there be a critical event with no resulting impact? Well, imagine the IPS reports a security event related to the exploitation of a critical vulnerability on MS-SQL targeted to a host sitting on a subnet where you know the database servers are connected to and maybe you also know that MS-SQL is the main choice for DBMS, but you end up finding that the specific target of the security event is a server running CentOS and MySQL as DBMS; thus, the host is not vulnerable and the event has no impact at all for that host in your network.
Avoiding wasting time investigating security events with no impact to our network is crucial so that we can use our time investigating what could actually cause harm. That is particularly were FTD shines.
FTD has a built-in network discovery engine that automatically generates a network map with host profiles of the elements living in the network it is protecting. Host profiles include information about the associated LDAP users, protocols and services being used by the host, ports on which the host is listening, operating system type and version along with the applications running in it with their corresponding versions. That information gives FTD the ability to infer the vulnerabilities existing in every host of the network (powerful, right?). By default, network discovery is done passively just analyzing the traffic that goes through the FTD sensor; however, it can also be achieved actively using FTD's built-in Nmap engine or through the integration with a vulnerability scanner.
With this insight on the network it is protecting, FTD solves the prioritization problem beautifully by presenting all the security events not only with its intrinsic severity but it also assigns to every IPS event a dynamically constructed impact flag; this impact flag is the result of the correlation between the nature of the event and the knowledge FTD has from the vulnerabilities in your network. Hence, the impact flag shows you the actual impact of a security event in your network, that way, a security engineer can immediately focus on what's important.
Tailored security is the best security
A few months ago, I read a document written by a Cybersecurity Manager regarding the acquisition of a new IPS solution for his employer's datacenter; the document stated the characteristics of the required solution. I felt terrorized when I read something like: "The new IPS solution must not require any type of advanced configuration or customization to protect a network out of the box". I understand that most security teams are in fact overrun with responsibilities and they are looking for simple solutions; however, there is no way a one-size-fits-most IPS will bring strong defense capabilities to any organization. A zero touch provisioning strategy might work for some specific environments such as a coffee shop or to protect a guest internet-access-only network; but definitely not a datacenter or a corporate network.
Customization is very important for an IPS solution, specially the customization of the IPS policy, since that's the only way to reduce false positives, reduce false negatives (which we don't want at all) and make sure the IPS hardware resources are not being wasted.
Customizable is not necessarily the opposite of simple, FTD is the living proof. On one hand FTD gives you full customization of the IPS policy rules, their thresholds and variables; furthermore, through a policy element know as "variable set" you can specify characteristics of the network you are protecting so that the IPS rules (which by the way use Snort) make sense for your network. On the other hand, if you don't really know what you are doing modifying the IPS policies, FTD can do that for you automatically taking advantage, once again, from the network discovery and the host profiles.
FTD uses the network insight it has already built to generate whats called "Firepower recommendations", those are custom modifications for your IPS policy based on the vulnerabilities actually existing in your network, and that you can implement into your policy. Pretty much, FTD has the ability to customize itself depending on the network it is protecting. That is simplicity and efficiency that translates into security efficacy.
Automation saves lives and definitely buys you time
Some organizations have the resources to implement a security operations center that works 24/7, unfortunately thats not the reality for many more that can only afford security staff working nine to five, Monday to Friday leaving an open window of around 16 hours everyday. I mentioned before how important it is not only to trust the IPS to block malicious traffic but to investigate the security events so that you can contain and mitigate the actual attack or threat underlying. So, what happens if a security event related to a mayor compromise is triggered on a Saturday night when there is nobody to investigate it?. Most likely, investigation would have to wait until Monday morning, and that's if the event doesn't get lost in the sea of logs. That scenario automatically puts any organization in danger as it increases the time-to-respond and aggravates the potential impact of the breach.
FTD has a feature that solves this problem as well: the correlation rules. Configuration of correlation rules let you set actions that will be triggered automatically after a specific event is generated. The trigger can be pretty much any security event with specific characteristics of your choice, such as a malware event or an IPS event with an Impact 1 flag. The response action could be as simple as an email notification (to wake up the on-call security engineer) or something more elaborated such as executing a Nmap scan or injecting a blackhole route into a router so that the malicious traffic gets discarded.
Furthermore, FTD has a native integration with Cisco ISE, which is Cisco's identity based network access control for authentication, authorization and accountability, using a standard open protocol (developed by Cisco) called pxGrid (integration is the power of a security architecture). This integration allows you to unleash a feature called Rapid Threat Containment which basically means that FTD can automatically trigger an adaptive network control change on ISE so that the host generating that security event gets quarantined or expelled from the network as the result of a correlation rule. That opens the possibility to delay a security event investigation as the threat has been already contained without human interaction; hence, the time-to-respond tends to zero along with the potential impact.
See? Now you understand why it was true love at first sight.
Cheers
a security artist