The recent of End-of-Sale and End-of-Life Announcement for the Cisco Secure Access Control System has left no option but to migrate towards Cisco Identity Services Engine (ISE) product line. Cisco has successfully implemented the Cisco Secure Access Control System (ACS) product functionality into the Cisco Identity Services Engine (ISE) product line.
The Cisco Identity Services Engine (ISE) product line is capable of integrating any Security appliance which can support Tacacs & Radius and similar kind of security polices can be created. Cisco will also offer a migration tool which is capable of migrating the Cisco Secure Access Control System rules into
Cisco Identity Services Engine (ISE). The migration tool uses the Cisco Secure ACS Programmatic Interface (PI) and the Cisco ISE representational state transfer (REST) application programming interfaces (APIs). The Cisco Secure ACS PI and the Cisco ISE REST APIs allow the Cisco Secure ACS and Cisco ISE applications to run on supported hardware platforms or VMware servers. One cannot directly run the migration tool on a Cisco Secure ACS appliance. The Cisco Secure ACS PI reads and returns the configuration data in a normalized form. The Cisco ISE REST APIs perform validation and normalize the exported Cisco Secure ACS data to persist it in a form usable by Cisco ISE software.
Cisco is offering up to 63% off on Cisco ISE hardware and software license bundles for those who want to migrate from Cisco ACS to Cisco ISE. However the customer with both ACS and ISE installations are not eligible for the migration bundles.
The below table shows the major milestones for the latest announcement.
|End-of-Life Announcement Date||The date the document that announces the end of sale and end of life of a product is distributed to the general public.||November 30, 2016|
|End-of-Sale Date||The last date to order the product through Cisco point-of-sale mechanisms. The product is no longer for sale after this date.||August 30, 2017|
|Last Ship Date:
App. SW, HW
|The last-possible ship date that can be requested of Cisco and/or its contract manufacturers. Actual ship date is dependent on lead time.||November 28, 2017|
|End of SW Maintenance Releases Date:
App. SW, HW
|The last date that Cisco Engineering may release any final software maintenance releases or bug fixes. After this date, Cisco Engineering will no longer develop, repair, maintain, or test the product software.||August 30, 2018|
|End of Routine Failure Analysis Date:
|The last-possible date a routine failure analysis may be performed to determine the cause of hardware product failure or defect.||August 30, 2018|
|End of New Service Attachment Date:
App. SW, HW
|For equipment and software that is not covered by a service-and-support contract, this is the last date to order a new service-and-support contract or add the equipment and/or software to an existing service-and-support contract.||August 30, 2018|
|End of Service Contract Renewal Date:
|The last date to extend or renew a service contract for the product.||November 25, 2021|
|End of Service Contract Renewal Date:
|The last date to extend or renew a service contract for the product.||November 26, 2019|
|Last Date of Support: App. SW||The last date to receive applicable service and support for the product as entitled by active service contracts or by warranty terms and conditions. After this date, all support services for the product are unavailable, and the product becomes obsolete.||August 31, 2020|
|Last Date of Support:
|The last date to receive applicable service and support for the product as entitled by active service contracts or by warranty terms and conditions. After this date, all support services for the product are unavailable, and the product becomes obsolete.||August 31, 2022|
It’s a good approach from Cisco to push the flavor of Cisco Identity Services Engine (ISE) product towards their customer.
When Blue Coat Proxy SG is configured for internet in any of the mentioned deployment methods the client must need to establish connection with Blue Coat Proxy SG appliance. A client uses either an explicit method or a transparent method to establish a connection.
In this method, a client browser is explicitly configured to forward all the request towards proxy. Usually the browser is configured with an IP address and the port number of the proxy service. One can use Group policies to push the configuration to browsers or can also use Proxy Auto-Configuration (PAC) file to configure the browser to proxy setting from a web server. Explicit proxying is the quickest and simplest proxy solution. However, this method does fit well for large organizations.
In this method, the client browser does not need any special configuration, neither the browser is aware of how the traffic is being processed by the proxy. The proxy intercepts the traffic and process it. Basically the traffic is directed to proxy SG by using techniques like PBR, WCCP or default route. This method is much easier to deploy and administrate as there no configuration needed at the client end.
Some of the best practice of Blue Coat proxy SG are
Inline is recommend for:
- Small branch office with very limited scalable plan
- For POC and short-term deployments
Virtually inline or out-of-path is recommended for:
- Customers who are looking for scalability
- Customers who are looking for high availability (redundancy)
Explicit proxy is recommended for:
- Customers who wants to use extensive authentication
Transparent proxy is recommended for
- Customers who want inline physical deployment.
The Out-of-path deployment mode is commonly used when, one cannot bring down the network. Out-of-path deployment happens to be very difficult to manage as one cannot intercept and redirect the internet traffic at network level (like configuring WCCP, PBR or inline deployment). One needs to explicitly configure the web browser of each client to sent internet request to Proxy SG. Hence this mode of deployment is also known as explicit proxy deployment.
One can use either of the methods to configure the out-of-path / explicit mode to redirect the traffic to Proxy SG
- Client Brower is manually configured to connect to Proxy SG
- System administrator can distribute PAC (Proxy Automatic Configuration) files using group policy to explicitly point the end-user’s browsers to the Proxy SG.
Some of the advantages of Out-of Path deployment are
- No downtime is required to deploy out-of-path mode in any network
- Easy to deploy
Some of the disadvantages of Out-of-Path deployment are
- Requires client configuration to redirect the internet traffic towards Proxy SG
- Increase administrative overheads
In Virtually Inline deployment mode, the Proxy SG can be deployed in any network location, it relies on traffic redirection mechanisms like Web Cache Communication Protocol (WCCP) or Policy Based Routing (PBR) to redirect the interesting traffic, such as HTTP /HTTPS to the Proxy SG. WCCP is a Cisco proprietary protocol that allows certain Cisco routers, switches, Firewalls and Nexus switches to transparently redirect the traffic to a cache engine like Proxy SG. Blue Coat Proxy SG does supports both versions of WCCP 1 and 2.
The main advantages of Virtually Inline Deployment mode are
- No downtime is required to deploy Virtually inline mode in any network
- Very scalable and Robust
- Additional Proxy SG appliance can be added for capacity redundancy.
- The administration overhead is low, as clients need no configurations in their browsers.
Some of the disadvantages of Virtually Inline Deployment mode are
- Network configurations are needed to enable WCCP. This some times creates additional load on the Switch or Router especially when GRE is used.
- WCCP / PBR capable hardware is required for Virtually Inline Deployment.
Virtually Inline mode proves to very handy form operation prespective and its been observed this is one of the widely used deployment method for Blue Coat Proxy SG.
When it comes to deployment of Blue Coat Proxy SG, it offers some flexibility. One can deploy them in either of the below mentioned methods.
- Physically Inline (Transparent)
- Out-of-Path or Virtually Inline (Transparent)
Inline deployment is the simplest among the above mentioned deployments and it well suits for small branch offices. In this mode of deployment, the Proxy SG is placed directly placed between the core Switch and the edge router, logically the Proxy SG is placed in the path of all network traffic going to and from the Internet. In mode the Proxy SG relies on pass-through network card, which basically supports hardware bridging to provide fail-to-wire functionality. This mode of deployment doesn’t require any configuration changes either in core switch or router. Even the clients don’t need any kind of configuration. This mode of deployment is also known as bridge mode due to the hardware bridging network cards in use.
Inline deployment mode does have certain draw backs like
- Single point of failure.
- Network down time is must to deploy inline mode.
- Doesn’t offer scalability.
- Protocols proxied needs to be managed.
Inline deployment holds good for small organization as its is easy to deploy, can be used for evaluations or short-term deployments. However, one cannot rely on this mode for larger organizations for obvious drawback mentioned.
When it comes to deployment of Blue Coat Proxy SG, it can be deployed as a forward proxy or reverse proxy.
Basically forward proxy is used proxy LAN users / Internal user’s requests to the external networks. In this mode of deployment, the Blue Coat Proxy proxies in behalf of client. Basically the tcp session is built between Internal Users and Proxy SG, the proxy then breaks this tcp session and build a new tcp session with the External server. The internet network users are never exposed directly to external servers. In forward proxy mode, the Proxy is always placed on the same network as Internal users.
In the reverse proxy mode, the proxy does the opposite of forward proxy, in this mode the proxy is placed in the same zone as servers. When the external client initiates the connection towards the internal web server, the Proxy intercepts that connection and proxies the whole communication between the external client and the web server. As forward proxy mode , the proxy breaks the tcp session between the external client and the internal web server.
Proxy either in forward or reverse proxy mode always act as layer of protection, and can be used to implement security policies, caching, anti-virus scanning etc.
Blue Coat proxg SG can be physically deployed in following ways.
- Physically Inline (Transparent)
- Out-of-Path or Virtually Inline (Transparent)
In upcoming post, we will discuss these methods in brief.
When it comes to forward proxy or reverse proxy Blue Coat Proxy SG happens to be a Gartner Magic Quadrant leader in Secure Web Gateways category. They are especially known for their proxy capabilities for over a decade Blue Coat offers their Proxy SG appliances in various size and models. More details about their current models and capabilities can be discovered at their website.
Their strengths according to Gartner are
- ProxySG is the strongest proxy in the market in terms of breadth of protocols and the number of advanced features. It also supports multiple authentication and directory integration options.
- Blue Coat’s hybrid offering (cloud service and on-premises appliances) enables operations teams to manage most policies from a single console (although policies can be pushed only in one direction — from the cloud to on-premises appliances).
- Blue Coat provides strong support for SSL/TLS. All ProxySG models include SSL hardware assist, to offload processing from the main CPU. The stand-alone SSL Visibility Appliance can be used to decrypt SSL/TLS traffic and feed it to Blue Coat and non-Blue Coat security solutions (for example, data loss prevention [DLP], IPS and network sandboxes).
- Blue Coat’s partnership strategy has enabled it to fill gaps in its product line. Partnerships with six endpoint detection and response (EDR) vendors help ensure that its customers can complement Blue Coat’s network-based advance threat detection with an endpoint strategy. Partnerships with FireEye and Lastline enable customers to use their own sandboxes instead of Blue Coat’s sandbox. A partnership with Cylance adds signatureless file inspection to Blue Coat’s Content Analysis System.
- Blue Coat’s ownership and integration of CASB technology gives it an early mover advantage in this emerging market
The main intention of starting a series on blogs post about Blue Coat is to create an awareness about Blue Coat especially the technical capabilities of the appliance as its not easy to find more resources on Blue Coat Proxy SG. One need to rely on Blue Coat portal for more details and the information is not easily accessible especially for those who are not aware about the Blue Coat products.
The Cisco ASA Firewall with FirePOWER services can be deployed in Active/ Active failover, in this mode the ASAs must operate in multiple context mode. Cisco is relying on failover groups for active Active/Active failover mode. A failover group comprises of logical groups, of one or more security context. In Active/Active failover mode , both units of Cisco ASA Firewall with FirePOWER services can pass the network traffic, however the traffic load is split between members of the failover pair in such a way that each unit will be active for some set of security contexts.
The Cisco ASA Firewall with FirePOWER services can support up to three fail over groups in Active/Active failover mode.
- Group 0
- This is a hidden group which cannot be modified and it hold system context as its member. Group 0 have huge dependency on Group 1 as Group 0 remains active on the ASA unit where the group 1 is active .
- Group 1
- The admin context is always the part of this group and any newly created context are added to this group by default. By default the primary ASA Firewall with FirePOWER services unit always own the Group 1.
- Group 2
- Some of the newly created contexts can be added to be the part of group 2 so that they are active on the secondary unit of the ASA Firewall with FirePOWER services. By default Group 2 is also active on the primary ASA Firewall with FirePOWER services unit, one need to change ownership of Group 2 from the primary ASA Firewall with FirePOWER services unit to the Secondary ASA Firewall with FirePOWER services unit manually
In Active/ Active failover deployment with multi context mode
- Physical interfaces of the ASA Firewall with FirePOWER services cannot be shared between contexts belong to different failover groups.
- All the features of ASA Firewall with FirePOWER services are not supported
- When failover occurs, a single physical ASA unit must carry all the traffic load which was shared by two ASA units.
- When ASA FirePOWER module fails, it can be configured to do either of the following
- Fail Open
- In fail open state all the traffic will pass thought the ASA even when the ASA FirePOWER module fails
- Fail Close
- In this state all traffic passing though the ASA will stop.
- Fail Open
The Active/ Active failover deployment is quite useful following scenarios
- Multi-tenancy environment
- Multiple LAN subnets which needs a logical separation though different firewalls.
However looking at the limitations of Active/ Active failover deployment model one can consider clustering of Cisco ASA with FirePOWER modules as they provide much better HA solutions for load sharing scenarios.
The Cisco ASA Appliances offers failover in following states
- Stateless failover
- Stateful failover.
By default Cisco ASA Appliance performs stateless failover and in this mode of operation, the Active Unit does the following
- Synchronizes its configuration with the standby unit.
- Maintains all Stateful flow information
- Doesn’t synchronises Stateful flow with the Standby Unit
The Stateless failover is not a viable option, especially when failover occurs as it has to re-establish all the connections. This state simply cannot provide the availability of the services without any disruption. However some hardware platforms like Cisco ASA 5505 are only capable of working in Stateless failover mode.
When Stateful failover is enabled on the Cisco ASA Active unit it is capable synchronizing the following with Standby Unit
- Stateful table for TCP & UDP connection
- Routing table both static and dynamic learned routes
- ARP table
- Bridge-group MAC mapping table in the transparent mode.
- Application Inspection data for certain applications like
- Packet Data Protocol (PDP)
- General Packet Radio Service (GPRS)
- GPRS Tunnelling Protocol (GPT)
- Session Initiation Protocol (SIP) signalling tables.
- VPN Data structures like Security Associations (SA)
However Stateful failover is supported only for the Cisco ASA Software features, where as the Cisco ASA FirePOWER module need to track the connection state independently. When failover occurs ASA FirePOWER flows are transferred to the new Active unit. The ASA FirePOWER module in the new active unit is capable of inspecting the traffic only from that point as old inspection states are not transferred during the failover process.
The Cisco ASA Appliance with FirePOWER Services is capable of offering high availability using failover and clustering. When it comes to failover , the Cisco ASA supports following types
- Active/ Active
The Cisco ASA Appliance with FirePOWER Services when deployed in Active/Standby failover mode it offers device level redundancy. However only one unit of ASA appliance remains in active mode , where as the other ASA Appliance of the failover pair remain in standby mode.
The ASA Appliance in Active mode is responsible for the following
- Active unit accepts all the configuration commands from the user and replicate the same with Standby Unit.
- All transit traffic is processed.
- Applies security policies , build and tear down connections .
- Synchronises all the connection information like global pool addresses, translation table for NAT, TCP/UDP states, ARP table and many other details with the standby unit provided its configured in Stateful failover mode.
- Forwards all the syslog messages and Netflow Secure Event Logging (NSEL) to the destined event or log collector.
- Participates in building and maintaining dynamic routing adjacencies with peer routing device
The standby device is not capable of processing any traffic it receives , it simply drops all the transit traffic and only accepts the management connections. The Standby ASA Appliance becomes fully active automatically, provided that the active ASA appliance becomes less operational healthy than its peer.