Chapter 10. Introduction to and Deployment of Cisco Next-Generation IPS

The chapter covers the following topics:

NGIPS basics

Deployment design considerations

The NGIPS deployment lifecycle

Attackers have constantly improved their methodologies of exploiting gaps in security by concealing their malicious activities and potential intrusions in spite of the security controls used in an infrastructure. Detection challenges are introduced by complicit users, misaligned policies, sophisticated attackers, naïve users, complex geopolitical relations, dynamic threats, and more. Next-generation intrusion prevention systems (NGIPS) has become a very important component of security architectures, providing protection against traditional and sophisticated types of attacks.

This chapter introduces NGIPS and compares it with legacy intrusion prevention systems (IPS). It presents a number of design concepts, principles, and challenges for NGIPS deployment. The chapter also explores some basic deployment scenarios and explains the basic design considerations security architects need to address when deploying NGIPS. The chapter concludes with coverage of the NGIPS deployment lifecycle followed in most NGIPS deployments.

Legacy IPS depend mostly on matching signature-based patterns to identify and potentially prevent malicious activity. These are some of their basic characteristics of legacy IPS:

They are sometimes deployed behind a firewall when providing IPS functionality (inline). Often, an IPS is also placed in the network without a firewall in front of it.

They often look for attempts to exploit a vulnerability and not for the existence of a vulnerability.

Legacy IPS often generate large amounts of event data that are difficult to correlate.

They focus on individual indicators/events without focusing on contextual information to take action.

Legacy IPS require manual tuning for better efficacy.

Thus, legacy IPS suffer from certain shortcomings, including the following:

They often need to be operated in conjunction with other products or tools (firewalls, analytics, and correlation tools).

They are sometimes not very effective and may be ignored.

Their operation costs and the operating resources they need are high.

They can leave infrastructures imperfectly covered against attackers.

NGIPS supplement legacy IPS functionality with more capabilities, such as the following:

Application awareness and control: NGIPS provide visibility into Layer 7 applications and can protect against Layer 7 threats.

Content awareness of the information traversing the infrastructure: For example, knowledge about files transferred between two hosts can be used to identify viruses transferred and the trajectory of a virus infection in a system.

Contextual awareness: This helps better understand alerts and automatically deduce comprehensive information about the events taking place, which makes the NGIPS less complex and means it requires less tuning.

Host and user awareness: The infrastructure offers more conclusive information about the events taking place.

Automated tuning and recommendations: This allows an administrator to follow recommendations and tune signatures specifically to his environment.

Impact and vulnerability assessment of the events taking place: The impact of a security event identified by the system can be evaluated based on the information available for the environment. For example, a Windows system that is identified to secure a vulnerability cannot be severely impacted by an attempt to exploit the vulnerability against it.

Thus, it is clear that in the threat landscape of both today and in the future, NGIPS functionality has an important role in protecting and providing coverage against known attacks and new types of exploits.

Modern security tools need to integrate directly into the network fabric in order to maximize performance and efficiency. Responses need to be comprehensive and simple. Protection must be continuous. Network controls should not be implemented disparately and individually. To abide by these modern security requirements, Cisco follows a new security model that looks at the actions needed before, during, and after attacks that apply to mobile devices, virtual machines, endpoints, or more (see Figure 10-1). The Cisco Firepower NGIPS functionality operates mostly in the during phase of the attack continuum, but all phases are covered by the integrated capabilities of the Cisco Firepower product portfolio.

The following are some of the key differentiators of the Cisco NGIPS portfolio from other vendors:

Trusted security engine and security intelligence provided by Cisco

Security automation and behavioral and retrospective analysis

Network and context awareness and visibility

The Cisco Firepower NGIPS engine is based on well-defined open source Snort. Snort, originally created by SourceFire, is an open source IPS tool that is widely used in the industry. The Cisco Snort IPS rules in Snort are developed by the Cisco TALOS team and are open for inspection. They are built based on collective security intelligence by Cisco TALOS and a variety of other sources. The rule set offers broad product and threat coverage. In addition, third-party rules can be integrated and customized in the Cisco NGIPS.

The Cisco NGIPS products include the following:

Cisco ASA5500-X with FirePOWER Services: Multiple ASA5500-X products for different performance requirement can run FirePOWER Services to leverage Cisco NGIPS capabilities in software (5506-X, 5512-X) or hardware modules (ASA5585-X).

Cisco Firepower next-generation firewall (NGFW) appliances (4100, 9300 series): Threat-centric security appliances are available for service providers that run Firepower Threat Defense (FTD). FTD includes Application Visibility and Control (AVC), optional Firepower NGIPS, Cisco Advanced Malware Protection (AMP), and URL filtering.

Cisco Firepower appliances (7000, 8000 series): Standalone NGIPS appliances are available for different performance requirements.

vNGIPS: Firepower Virtual NGIPS is available for virtual environments.

The following are some of the most important capabilities of Cisco NGIPS:

Threat containment and remediation: Cisco Firepower NGIPS provides protection against known and new threats. Its features include file analysis, packet- and flow-based inspection, and vulnerability assessment.

Application visibility: Cisco Firepower NGIPS offers deep inspection and control of application-specific information for better efficacy.

Identity management: NGIPS policies can be enforced by using contextual user information.

Security automation: Cisco Firepower NGIPS includes automated event impact assessment and policy tuning.

Logging and traceability management: This can be used in retrospective analysis.

High availability and stacking: Cisco Firepower NGIPS provides redundancy and performance by leveraging multiple devices.

Network behavioral analysis: Key behavioral indicators and threat scores help analysts prioritize and recover from attacks.

Access control and segmentation: Access policies can be applied to separate traffic profiles in the network.

Real-time contextual awareness: NGIPS discovers and provides information about applications, users, devices, operating systems, vulnerabilities, services, processes, files, and threat data related to IT environments.

To leverage its capabilities, NGIPS needs a robust and comprehensive management platform. For NGIPS management, Cisco offers the following:

Cisco Firepower Management Center (FMC) (appliance or virtual) for multiple devices

Cisco ASDM (which, at this writing, can be used only in some ASA with FirePOWER Services models)

As shown in Figure 10-2, there are two connectivity flows between the FMC and the NGIPS that offer device policy configuration from FMC to the NGIPS and information collection from the NGIPS to FMC for further intelligent analysis and reporting.

The following are some of the features provided in the Cisco FMC:

Policy management

Display of event and contextual information, using various formations

Health and performance monitoring

Notifications and alerts filtering

Correlation, vulnerabilities, indications of compromise, and remediation features for real-time threat response

Custom reporting

High availability

By combining top-notch platforms, research, and management, Cisco offers a complete NGIPS tool set that allows a security architect to build secure and simple-to-operate architectures.

The caveat with inline NGIPS (Figure 10-3) is that in the event of a software failure or a loss of power, all traffic is dropped. The fail-open capability can be used for such situations to allow traffic to hardware bypass the device and avoid traffic loss. Fail-open should not be used when the security policy doesn’t allow for traffic to go unaccounted for or uninspected.

Inline mode offers two more modes of operation: routed and switched. In routed mode (see Figure 10-4), the device operates at Layer 3, as a router would. In switched mode (see Figure 10-5), the NGIPS is in transparent mode and doesn’t show in the path as a Layer 3 hop. It uses two interfaces in a VLAN pair and bridges them together.

Monitoring (passive) mode is the mode where the NGIPS does usually not prevent attacks. The device uses one interface to silently inspect traffic and identify malicious activity without interrupting traffic flow (see Figure 10-6). It is usually connected to a switch’s span port, a mirrored port, or a network tap interface. Even though in monitoring mode the device doesn’t block traffic, there is an option to reset malicious connections, but that should not be considered as a mitigation mechanism as it can’t guarantee attack prevention.

All Cisco NGIPS products (ASA FirePOWER Services modules, Firepower Threat Defense, NGIPS appliances, and vNGIPS) can operate in the modes described. Specifically for the ASA FirePOWER Services module, the modes and how they can be configured are presented in Chapter 2, “Introduction to and Design of Cisco ASA with FirePOWER Services.”

In perimeter deployments, the device monitors attacks from the outside. It is usually deployed behind a perimeter access control device such as a firewall that is responsible for enforcing access policies so that the NGIPS does not spend resources inspecting traffic that should not be traversing the network.

A demilitarized zone (DMZ) is a partly trusted area where web and other servers reside. There is a certain risk for DMZ devices like servers, and thus an NGIPS is often deployed to protect them.

An NGIPS deployed at the core of a network detects insider threats and attacks. It also often identifies malware propagation, worms, and outbound malicious activity. Cisco NGIPS network discovery is more accurate when deployed closer to the core as internal network traffic is evaluated and provides more accurate discovery results.

Extranets provide connectivity from an enterprise to its partners’, suppliers’, and customers’ networks. Such networks could carry concerns and threats that are not welcome to the enterprise. NGIPS can provide protection against those threats and secure sensitive information.

NGIPS can also be deployed in critical network segments—that is, parts of the network that contain highly valuable assets, also called “crown jewels.” These assets could include valuable servers that contain sensitive data and private information and e-commerce systems that are highly regulated. NGIPS may also be used in the following locations:

Branch office links

Out-of-band management networks

Cloud services (usually virtual NGIPS)

It is vital to perform a threat analysis against the security model to determine how the NGIPS would perform against it. For the Cisco threat model, the NGIPS should provide protection before and during an attack, and it should offer the analysis functionality during and after. Retrospective historical analysis is also important for a protection system to offer a holistic approach to protection after an attack. A good understanding of the candidate system will help in evaluating the system against the security model and also against current and modern threats. You should perform threat analysis before evaluating the system against the security model as threats could significantly vary depending on the architecture.

The following are some of the features and capabilities security architects have to think about:

Mode: You need to determine whether to use inline or passive mode and whether to use a physical or virtual sensor when designing an NGIPS solution.

Real-time contextual awareness: The capability of looking through multiple contexts—such as applications, users, devices, operating systems, vulnerabilities, services, behaviors, and files—is important for modern systems.

Open standards: It is important to be able to trust the rules and the efficacy of the system rules. Using open standards helps by allowing integration with third-party rules.

Manageability, visibility, and orchestration: Ease of use reduces the cost of owner-ship and provides better efficacy in today’s diverse environments. Capabilities such as automated impact assessment, IPS policy tuning, behavior analysis, anomaly detection and correlation, and user identification certainly increase the ability of operators to perform their jobs faster and more efficiently.

Advanced features: Functions such as application control, URL filtering, and malware protection increase the security an NGIPS offers.

Security and regulatory compliance: An NGIPS solution should be able to enable the enforcement of practices described in security standards (such as CISSP and the ISO 27000 series) in order to provide regulatory compliance (for example, with PCI, HIPAA, SOX, and FISMA).

Reporting: The reporting requirements of an organization should be cross-referenced with the reporting capabilities of the system. Custom reporting is often required by modern NGIPS to allow quick analysis and response to security incidents.

NGIPS devices traditionally are challenged when processing asymmetric flows because they cannot monitor the flow bidirectionally. In asymmetric flows, the forward and return paths are not the same. For example, packets flowing to a server do not follow the same hops as the returning packets. Asymmetric flows are often expected and designed in properly designed networks. They offer redundancy and take advantage of optimized switching fabrics and scalable uplinks. NGIPS devices cannot take action on packets they can’t see, and they do not tolerate too many missed packets. The primary issue with asymmetric traffic and IPS is performance because unidirectional traffic needs to be buffered longer in order to wait for retransmissions and degraded detection because of missing packets in one direction. Figure 10-8 shows how the Link Aggregation Control Protocol (LACP) hashing algorithm of the port channel can end up creating asymmetric flows seen by two different NGIPS devices.

Network architects need to ensure that asymmetric packets flow in a deterministic manner and are properly handled. Specifically for Cisco ASA with FirePOWER Services, ASA Cluster Context Pairing allows for the packets of the same connection to be forwarded to the same firewall and thus be inspected by the same NGIPS device, ensuring better security.

For low latency, passive mode deployments would be more ideal, but they are not always possible due to security requirements. For example, what happens to a low-latency stock trading application in an overwhelmed NGIPS? The Cisco NGIPS offers a rule latency threshold option that can be configured to suspend the rules when processing time exceeds the configured limit. In addition, the Cisco NGIPS appliance has a feature called Automatic Application Bypass (AAB) that limits the time allowed to process packets through an interface.

Cisco offers high-performance NGIPS functionality that can serve today’s applications. Performance and high-traffic processing are vital. For cases in which more processing power is required, Cisco ASA can allow multiple ASAs with FirePOWER Services to form a cluster (ASA Clustering Context Pairing) and serve much more aggregate bandwidth than a standalone device. Cisco Firepower NGIPS appliances themselves can be stacked together, and this more robust stack of systems then acts as one. In order to set up stacking, the primary device needs to be connected to all secondary devices using two stacking cables and a stacking module (see Figure 10-9).

Downtime is important for networks. Some critical infrastructures have zero downtime requirements. The recovery time from a failure is important. In addition, the mean time between failure (MTBF) is often a good indicator of the average time a device stays up. Multiple high-availability features ensure that a whole network will not go down when a failure occurs.

Some features include hardware and link redundancy. For link redundancy, port channel support is widely used. For hardware redundancy, Cisco ASA Clustering combines multiple ASA devices (with FirePOWER Services) to provide high throughput and ensure that hardware failure can be properly handled by the other devices. Cisco ASA Clustering also ensures that the same flows are handled by the same device, thus eliminating asymmetric routing. Figure 10-10 shows how flows are transported over the cluster control link and processed by the same device. What’s more, just for device pairs, the ASA offers the failover feature (active/standby or active/active failover pair) that automatically fails over to the healthy device in the event of a failure. The FirePOWER Services module state is not synced in this scenario.

Cisco Firepower NGIPS appliances also offer Firepower clustering (high availability), which differs from the ASA clustering mentioned previously. Firepower clustering establishes resiliency between two appliances or two stacks. Clustered devices synchronize state via a dedicated HA link. Both devices in a cluster must be the same model and have identical interfaces, software, and licenses. In the event of a failure, automatic failover takes place. Firepower clustering is a lot like having multiple standalone appliances, except duplicate events are suppressed.

If you have deployed a standalone device that has a zero downtime requirement, what happens if the device fails at some point? The fail-open feature offered in the Cisco NGIPS device allows you to bypass processing in the event of a failure and thus avoid downtime.

Thus, there are multiple options that can provide redundancy, performance, and extensibility. It is up to the security architect to consider the current and future network requirements and design for a highly scalable and failure-resilient NGIPS deployment.

Losing connectivity to a management platform should not render the NGIPS it manages unusable. Losing visibility of the events and configuration is acceptable, but the detection and blocking of malicious traffic should continue, and all collected events should be transmitted when the manager is recovered.

The Cisco FMC can operate in high-availability mode. Policies, user accounts, and more are shared between two Firepower devices. Events are automatically sent to both members of the redundant pair. If the FMC on one of them fails, the other one will take over. In redundant mode, two FMCs share the following information:

User account attributes and user roles

Authentication configuration

Custom dashboards and workflows

Intrusion detection, file control, access control, discovery, and correlation policies

Device attributes

Scale is also important to the management platforms. Depending on the number of NGIPS devices, you can choose different management platforms. For the FMC, for example, a FS4000 can support up to 300 sensors with a maximum of 300 million events with 20,000 flows per second.

The ASDM is a standalone device management tool and thus does not include any redundancy scenario. Practically, ASDM is launched from the client application and connects to the ASA with FirePOWER Services or the NGIPS module for management.

Although pricing is important, you should keep in mind that in today’s complex infrastructures, standalone devices at high prices are not always the best way to go. Today’s business is focused on generating results, and the infrastructure should align with that goal. Thus, implementing architectural approaches that deliver business outcomes is usually more important than purchasing purely cost-effective devices for the network without having a holistic architectural strategy.

Specifically for Cisco Firepower NGIPS, the following licenses are available:

Protection: This type of license allows managed devices to perform intrusion detection and prevention and enables file control, as well as intelligence filtering, clustering, and stacking.

Control: This type of license requires a Protection license and enables user and application control. It also allows devices to perform switching and routing.

URL Filtering: This type of license enables cloud-based category and reputation URL filtering. It requires a Protection license and a Control license.

Malware: This type of license enables network-based advanced malware protection.

FireSIGHT is an additional license that comes with FMC. It allows host, application, and user discovery. If NGIPS management is performed with ASDM, a separate license is not required.

Step 1. Policy definition

Step 2. Product selection and planning

Step 3. Implementation and operation

Step 4. Evaluation and control

The policy definition phase dictates the product selection and deployment plan that are chosen to satisfy it. After the selection step, the system gets deployed in the network. The operation and continuous evaluation ensure that the system is performing its tasks efficiently and successfully. At times, adjustments need to be made either because of changes in the policy or based on findings. The following sections describe all the steps in the deployment lifecycle.

The policy definition phase includes threat analysis, as mentioned in Chapter 9, “AMP Threat Grid: Malware Analysis and Threat Intelligence.” Before deciding on mitigations, the assets need to be identified, and the threats posed to them need to be defined. Then the threats are assigned risk (using risk analysis models). At this point, the security model is used to determine how the high-risk threats will be addressed (prevented or mitigated if they occur). After all potential mitigations are in place, there might still be risk (residual risk) that the security policy needs to address or accept. There will potentially be threats with mitigation costs higher than the cost of the risk occurring. In such a case, the risk may be accepted with no action taken. Of course, there are multiple tangible and intangible cost factors that can go into a security threat, and such risks should be evaluated carefully.

Compliance standards also influence the policy definition extensively. HIPAA, PCI, ISO, and other standards involve different rules that a security policy needs to satisfy in order for the organization to be compliant. Compliance audits focus on finding holes in the policy that could potentially render an organization not compliant.

After evaluating threats, risk, the security model, and compliance requirements, a security team finalizes the security policy that is used as the baseline for choosing the product and planning its deployment, as described next.

Because the product selection dictates the success of the NGIPS installation, the requirements definition that serves as input to the decision process needs to be as detailed as possible. Some determining factors are device type, deployment size, cost, other security devices, scaling requirements, and responsibilities:

Security architects start by identifying the use cases of the deployment. For example, an NGIPS deployed to prevent malware in a school is different than an NGIPS for preventing data exfiltration in a bank.

The location of the NGIPS also plays a role in the requirements document as each location assumes different performance and security requirements. Potential locations could be Internet edge, data center, branch, and core. It is obvious that the performance and availability requirements in a data center are not the same as those in a branch office. For example, an NGIPS in a data center looking at only internal traffic will not identify as many threats as when sitting at the Internet edge, looking at the wild Internet traffic.

The team needs to choose deployment options such as inline, passive, routed, switched, standalone appliance, or ASA with FirePOWER Services, Firepower Threat Defense, or virtual NGIPS, based on the use case and deployment locations.

Connectivity is the next subject of interest. How many sensing interfaces are needed? Are they going to be passive taps or inline interface pairs? Copper or fiber? What are the speed, link aggregation, and wireless setup? The answers to all these questions need to be documented for comparison against the NGIPS vendor options available.

Performance and scale are important considerations. How much traffic needs to be processed by the NGIPS? How much latency is acceptable? What is the peak number of connections, and what is the maximum connection rate? These questions need to be answered when scaling a deployment. Cisco ASA clustering and Firepower NGIPS stacking can be used to increase the aggregate NGIPS throughput.

Vendor data sheets should cover device performance for engineers to use. Traditionally, the firewall industry has almost always published maximum throughput numbers in data sheets. Engineers should ensure that performance numbers are sufficient in the deployment environment. The IPS industry has generally been more conservative about throughput estimates on data sheets, partly because the performance range varies based on features used and traffic patterns. In general, using extra features increases processing load and decreases performance. For example, a Cisco Firepower NGIPS running malware inspection and application control could in some cases run below its nominal performance numbers. You should exercise caution when investigating published performance data sheets and ensure that they match the deployment use case in question.

Availability also needs to be in the requirements list. Is bypass (fail-open) or non-bypass going to be used? Is clustering going to be available for redundancy? Is the traffic profile many short-lived flows or long-lived ones? These availability questions to need be answered. For Cisco NGIPS specifically, clustering can provide high availability between two NGIPS devices.

The management platform is another consideration. Is the management platform going to manage multiple devices? How is it going to be accessible, and by whom? Is the management software going to be virtual or an actual appliance? These are some of the decisions you need to make. For Cisco, the FMC can be deployed in a virtual machine and as an appliance and supports redundancy, so there is no unmanageable NGIPS situation if one FMC fails.

The feature requirements needed to enforce the policy must also be identified. Is malware part of the problem to address? URL filtering, user discovery, vulnerabilities, application awareness, and control are some features that Cisco NGIPS supports and that contribute to enforcing the overall security policy.

A security team should revisit the design considerations when answering all of the preceding questions in order to cover all the potential holes and ensure a smooth implementation phase.

After you answer all these questions, you need to check the long list of information against vendor products, product support, and licensing costs in order to make a decision. In making a vendor decision, you should also consider the future. Focusing purely on current requirements might lead to poor choices for years to come. What is more, integrating NGIPS into the whole network architecture in order to bring the business outcomes desired is how product selection should be viewed. Just focusing on a cost-effective piece of equipment with features that will solve security problems today is not the way to go.

After the vendor selection, a planning document is produced from the requirements document that will dictate how the deployment will take place, what features will be used, and in what timeframes. The plan needs to be as detailed as possible in order for the deployment to go smoothly and for the NGIPS operation to be efficient and successful.

The implementation phase involves the following hardware and software installations:

Installation of the management platform: This installation happens first because the management platform needs to be ready to discover the device to manage and start configuring it. This step involves going through the initial configuration, giving the device an IP address and a gateway in order to be reachable.

Specifically for Cisco Firepower NGIPS, the FMC needs to be installed in the network and configured. Either in hardware (appliance) or software (virtual machine), the FMC needs to be accessible from the network. If ASDM is the management software of choice, it can be launched and installed only after the following installation is done.

Installation of the Firepower appliance, the Firepower Threat Defense, the virtual appliance, or the Cisco ASA with FirePOWER Services: This installation involves going through the initial configuration, giving the device an IP address and a gateway in order to be reachable. If the device is Cisco ASA with FirePOWER Services, then ASDM can be launched and installed by establishing an HTTPS session into the firewall’s management IP address.

The initial device configuration and operation includes the following steps:

Step 1. Addition of the NGIPS appliance/module to the management platform: This step includes establishing connectivity between the management platform and the device in order to begin managing it.

Step 2. Application of licenses and basic configuration: After establishing connectivity, the management platform connects to the device to provision licenses that allow it to operate. Then a basic configuration is placed on the device, making sure that the policy is not very aggressive if the NGIPS is installed inline. At this stage, the NGIPS device might also be used in passive mode to prevent inadvertent packet loss.

Step 3. Tuning: Initially, many of the policies need to be tuned to the needs of the network. Sometimes, especially in inline deployment, a minimal set of features is deployed to avoid inadvertent outages due to misconfigurations. Later, the configuration can be adjusted to gradually take advantage of the whole set of NGIPS features. After the initial learning phase (specifically for Cisco), Firepower NGIPS devices offer a number of recommendations to make sure the policies align with the network condition.

Step 4. Operation: The final step is device operation. After finishing the tuning of the device and after ensuring a smooth transition, the NGIPS that was proactively put in passive mode can be converted to inline mode. Operation is a continuous process that requires proper planning and organization. Operating the NGIPS and using it to act appropriately or generate useful reports requires a certain amount of planning and organization. Operations teams need to be assigned and take their place in the day-to-day NGIPS operation and support.

Specifically for Cisco Firepower NGIPS, all features that apply to the after phase in the security model fall under evaluation and control. Some of these features include:

Snort rule tuning: Snort signature tuning happens initially after NGIPS implementation.

Signature updates: SourceFire Rule Updates (SRU) take place continuously in the NGIPS. The updates ensure that there is coverage for the most recent threats and exploits.

Firepower recommendations: The FMC uses host profile information to make recommendations about the rules that should apply to your environment. It can associate the host, OS, and applications with the rules that apply to them. It also revisits the rules that are already applied in the system. The Firepower recommendations should be used continuously to improve the security of the system.

Vulnerability scans: These scans should be leveraged in Cisco NGIPS occasionally in order to identify vulnerable devices and patch them. Periodically finding vulnerable hosts helps prioritize and keep the system up-to-date.

When the system identifies an incident, investigation needs to take place to mitigate it and find the root cause. Analytics and NGIPS reports can be used to investigate the incident. After the root cause is identified and addressed, lessons learned should be collected in order to update the security policy. If misconfiguration or issues were responsible, then the NGIPS policy also needs to be updated.

Obviously, NGIPS deployment is not finished as soon as the equipment is installed. It is an iterative process that involves ensuring that the security policy and the NGIPS are up-to-date and proved the best protections possible.

Specifically for Cisco, NGIPS is available in the ASA with FirePOWER Services, with Firepower Threat Defense, and also as a standalone virtual or physical appliance. There are multiple deployment options to fit different customer needs, depending on the deployment use case and location. When designing the deployment of NGIPS, network architects need to consider various factors, including system capabilities, traffic flow, and scale and availability. The deployment process is not a one-and-done step. It is an iterative process of defining the security policy, choosing products, and planning, operating, and evaluating the efficacy of the system.