This slide maps the “old world” of technology silos to the new world of Cisco Adaptive Threat Defense solutions. This will be the last time you see the traditional silos in this preso. Key points: ASA is built on market proven technologies from the Cisco platforms listed above. This is a key differentiator. Most “multi-function” security devices are strong in one area and weak in the others, therefore causing customers to give up features in such a device. Cisco literally built this device from the best of its security technologies, all of which are road-tested and proven in customer environments. All these security/VPN technologies are built on a foundation of “Network Intelligence”…meaning ASA is network aware, thus won’t “break” network traffic and applications, such as VoIP or virtualized or VLAN’d networks. ASA converges all of these technologies to deliver the ATD and VPN services listed at the right. Very similar to the ATD message in previous slides, this slide just brings down to the actual product implementation level (i.e. ATD customers can buy).
This slide maps the “old world” of technology silos to the new world of Cisco Adaptive Threat Defense solutions. This will be the last time you see the traditional silos in this preso. Key points: ASA is built on market proven technologies from the Cisco platforms listed above. This is a key differentiator. Most “multi-function” security devices are strong in one area and weak in the others, therefore causing customers to give up features in such a device. Cisco literally built this device from the best of its security technologies, all of which are road-tested and proven in customer environments. All these security/VPN technologies are built on a foundation of “Network Intelligence”…meaning ASA is network aware, thus won’t “break” network traffic and applications, such as VoIP or virtualized or VLAN’d networks. ASA converges all of these technologies to deliver the ATD and VPN services listed at the right. Very similar to the ATD message in previous slides, this slide just brings down to the actual product implementation level (i.e. ATD customers can buy).
This slide maps the “old world” of technology silos to the new world of Cisco Adaptive Threat Defense solutions. This will be the last time you see the traditional silos in this preso. Key points: ASA is built on market proven technologies from the Cisco platforms listed above. This is a key differentiator. Most “multi-function” security devices are strong in one area and weak in the others, therefore causing customers to give up features in such a device. Cisco literally built this device from the best of its security technologies, all of which are road-tested and proven in customer environments. All these security/VPN technologies are built on a foundation of “Network Intelligence”…meaning ASA is network aware, thus won’t “break” network traffic and applications, such as VoIP or virtualized or VLAN’d networks. ASA converges all of these technologies to deliver the ATD and VPN services listed at the right. Very similar to the ATD message in previous slides, this slide just brings down to the actual product implementation level (i.e. ATD customers can buy).
This slide maps the “old world” of technology silos to the new world of Cisco Adaptive Threat Defense solutions. This will be the last time you see the traditional silos in this preso. Key points: ASA is built on market proven technologies from the Cisco platforms listed above. This is a key differentiator. Most “multi-function” security devices are strong in one area and weak in the others, therefore causing customers to give up features in such a device. Cisco literally built this device from the best of its security technologies, all of which are road-tested and proven in customer environments. All these security/VPN technologies are built on a foundation of “Network Intelligence”…meaning ASA is network aware, thus won’t “break” network traffic and applications, such as VoIP or virtualized or VLAN’d networks. ASA converges all of these technologies to deliver the ATD and VPN services listed at the right. Very similar to the ATD message in previous slides, this slide just brings down to the actual product implementation level (i.e. ATD customers can buy).
This slide maps the “old world” of technology silos to the new world of Cisco Adaptive Threat Defense solutions. This will be the last time you see the traditional silos in this preso. Key points: ASA is built on market proven technologies from the Cisco platforms listed above. This is a key differentiator. Most “multi-function” security devices are strong in one area and weak in the others, therefore causing customers to give up features in such a device. Cisco literally built this device from the best of its security technologies, all of which are road-tested and proven in customer environments. All these security/VPN technologies are built on a foundation of “Network Intelligence”…meaning ASA is network aware, thus won’t “break” network traffic and applications, such as VoIP or virtualized or VLAN’d networks. ASA converges all of these technologies to deliver the ATD and VPN services listed at the right. Very similar to the ATD message in previous slides, this slide just brings down to the actual product implementation level (i.e. ATD customers can buy).
This slide gives more detail on the ATD, VPN and network-awareness listed on the previous slide. The key message: ASA is the first multi-function security device in the market where multi-function doesn’t require feature or performance trade-offs. Application security: ASA delivers port-80 application inspection and control for peer-to-peer, IM, and other often unwanted application traffic; all the granular traffic analysis that comes from its embedded IPS technology; deep VoIP traffic inspection, protocol validation and other VoIP security features Anti-X: Stops all the things listed above. Also offers on-device security event correlation and risk rating event response “tuning” to increase the accuracy of classifying threats so that appropriate action may be taken. NCC: In this area, ASA delivers typical NCC features like layer 3 and 4 firewall/access control features and stateful traffic inspection to control network user and application access. VPN: ASA offers all the “Easy VPN” features for touchless remote access and remote device VPN configuration. ASA also offers basic SSL VPN services. ASA also provides S-S VPN services with QoS and routing support. All of the ATD features can be applied to the VPN services to ensure the VPN doesn’t become a conduit for worms, viruses, etc. This enables “threat-protected” VPN without any additional cost or operations complexity. Network awareness: ASA supports all the features listed here to make sure that ASA inserts gracefully into the network and doesn’t disrupt traffic or applications.
PIX OS 7.0 introduces powerful new web inspection services that provide two classes of protection. First, PIX OS 7.0 provides visibility and control of Instant Messaging, Peer-to-Peer, and other tunneling applications (such as GoToMyPC.com). Secondly, PIX OS 7.0 provides businesses robust control over what actions users can perform when accessing websites. A common example we share is: you can now create a policy that states that traffic coming from the Internet to a web server on a DMZ can only view web pages – not edit or delete them. Correspondingly, businesses could create a second policy that states that the staging web server can edit and/or delete content on the production web server. Additional capabilities include MIME type filtering, giving administrators further control over what type of web content is acceptable in their environment. The new HTTP inspection engine in PIX OS 7.0 provides the following major features: 1. Check whether a HTTP message is compliant to the RFC – this includes checking the Request Message to ensure it is one of the predefined methods: OPTIONS, GET, HEAD, POST, PUT, DELETE, TRACE, or CONNECT. If the request messages does not contain one of the above request methods a check is made to verify that it is an extension method. If both the checks fail then the user will be alerted. The default action will be a syslog message, but through configuration it can be modified to reset the TCP connection. 2. Configure which HTTP methods (OPTIONS, GET, HEAD, POST, PUT, DELETE, TRACE, or CONNECT) are permitted through the firewall. By default all the predefined methods in the RFC are permissible. This list can be narrowed using the CLI/ASDM. Upon receiving a message that contains a method that is listed as not permissible, the action specified by the user through the policy will be executed. 3. Specify which extension methods are allowed through the firewall. If the messages do not contain a predefined HTTP request method or an extension method it is considered to be non-compliant to the RFC. Once again the action whether the messages should be passed or logged is decided by the user during configuration. The default behavior is to allow all the hard coded extension methods. Examples of extension methods include: INDEX, MOVE, etc. For a complete list of extension methods supported please refer to Appendix A. 4. Select whether a subset of mime-types are to be permitted through the firewall. The user will be provided with a predefined list of mime-types ex. image/Jpeg, text/html, application/msword, audio/mpeg. The user can choose whether only the mime-types mentioned in this list are to be permitted through the firewall or all mime-types are acceptable. The default behavior is to allow all mime-types. 5. Configure the minimum and maximum size of an http message body. When a request or response HTTP message passes through the firewall, a check will be made to ensure that it meets the size constraints. If it does not the action configured for this policy by the user will be executed. 6. Verify that the content-type specified in the header is the same as that being passed in the body of the http message. If a discrepancy is noticed then the action that the user configured is executed. 7. Validate that the content-type passed in the response message is one of those listed in the request message’s accept-type field. Once again if a violation is detected the action specified in the policy is taken. 8. Specify whether all traffic not compliant to the HTTP standard should be permitted or logged. By default the behavior is to disallow all non-http traffic through the firewall. The user can change this default behavior during configuration. 9. The ability to filter http messages on keywords. When a message transmitting the keyword is detected the appropriate action for this rule will be taken. An example where this is useful is when looking for Yahoo Messenger running over HTTP. The keyword will be YMSG should be in the first 4 bytes of the HTTP data. 10. The ability to specify the maximum header length for HTTP request and response messages. 11. Ability to configure the maximum size of URI to be permitted through the firewall. 12. The ability to catch double encoding attacks (aka de-obfuscation) New CLI introduced for this inspection engine includes: inspect http map <http_map_name> http-map <map_name> Note: these are used as part of the new Modular Policy Framework introduced in PIX OS 7.0. Once a particular traffic stream (possibly on port 80, 8080, or any other user-specific port, etc) is selected, the http-map further refines the search to what traffic to target and what actions to take when offending traffic is found. In the http-map sub-mode, the following new commands will be added: strict-http content-length content-type-verification max-header-length max-uri-length port-misuse request-method transfer-encoding Usage of these sub-mode commands are as follows: strict-http action { allow | reset | drop } [log] content-length {min <bytes> max <bytes> | min <bytes | max <bytes>} action {allow | reset | drop} [log] content-type-verification [match-req-rsp] action {allow | reset | drop} [log] max-header-length {request <bytes> response <bytes>} action {allow | reset | drop} [log] max-uri-length <bytes> action {allow | reset | drop} [log] request-method rfc <rfc_method> action {allow | reset | drop} [log] (used for RFC 2616 conformance checking) request-method ext <ext_method> action {allow | reset | drop} [log] (used for extension methods) <rfc-method> connect | delete | get | head | options | post | put | trace | default <ext-method> index | move | mkdir | copy | edit | unedit | save | lock | unlock | revlabel | revlog | revadd | revnum | setattribute | getattribute | getproperties | startrev | stoprev | default port-misuse <appl_category> action {allow | reset | drop} [log] <appl_category> p2p | tunneling | im | default transfer-encoding type <coding_types> action {allow | reset | drop} [log] } <coding_types> default | chunked | compress | deflate | gzip | identity
ensure resilient network protection
Today, when a system connects to the network, it’s identity is typically checked via identity mechanisms such as one-time passwords. However, no check is made to see if that system is compliant with corporate security policy. Even if a network has been purged of known threats, the entry of non-compliant system once again makes that network vulnerable to attack. For example, an infected system could immediately begin to spread a worm throughout the corporate network. Alternatively, it might be down-rev with respect to operating system patch levels, thus creating a new vulnerability that opens the network to external attack. Even the most conscientious users can be at risk. Systems may be shut down or off the network when signature files schedule for update. Even scripts that enforce “push mechanisms” for patches or virus signatures can only do so AFTER the system has been connected to the network. Complications such as this is one of the primary reasons worms, viruses, and other threats continue to propagate after a fix has been released and applied. The more time that elapses before all systems are brought into compliance increases the risk. And that’s the problem… time itself. As John stated, people cannot react quickly enough to ensure that all of these safeguards are in place. An automated system is required.
New with version 5.0, cisco enhances this threat identification by recognizing and identifying new vectors of threats such as Spyware and Adware…by protecting the network through its control of the transmission of confidential data, as well policing the network traffic to filter out spyware communications. Also, Network Viruses….Cisco leverages its partnership with Trend Micro to integrate late-breaking malware, and improves virus coverage and response time. Another vector of threat identification is Application Abuse by providing deep inspection for web protection and control of “port 80 misuse”…as well, controls usage of Instant Message, Peer 2 Peer methods/commands, and other MIME types. And finally Cisco protects Voice Over IP traffic by ensuring protocol compliance for call setup, protects voice gateways from attacks, and prevents excess memory allocation of URL overflows.
PIX OS 7.0 introduces powerful new web inspection services that provide two classes of protection. First, PIX OS 7.0 provides visibility and control of Instant Messaging, Peer-to-Peer, and other tunneling applications (such as GoToMyPC.com). Secondly, PIX OS 7.0 provides businesses robust control over what actions users can perform when accessing websites. A common example we share is: you can now create a policy that states that traffic coming from the Internet to a web server on a DMZ can only view web pages – not edit or delete them. Correspondingly, businesses could create a second policy that states that the staging web server can edit and/or delete content on the production web server. Additional capabilities include MIME type filtering, giving administrators further control over what type of web content is acceptable in their environment. The new HTTP inspection engine in PIX OS 7.0 provides the following major features: 1. Check whether a HTTP message is compliant to the RFC – this includes checking the Request Message to ensure it is one of the predefined methods: OPTIONS, GET, HEAD, POST, PUT, DELETE, TRACE, or CONNECT. If the request messages does not contain one of the above request methods a check is made to verify that it is an extension method. If both the checks fail then the user will be alerted. The default action will be a syslog message, but through configuration it can be modified to reset the TCP connection. 2. Configure which HTTP methods (OPTIONS, GET, HEAD, POST, PUT, DELETE, TRACE, or CONNECT) are permitted through the firewall. By default all the predefined methods in the RFC are permissible. This list can be narrowed using the CLI/ASDM. Upon receiving a message that contains a method that is listed as not permissible, the action specified by the user through the policy will be executed. 3. Specify which extension methods are allowed through the firewall. If the messages do not contain a predefined HTTP request method or an extension method it is considered to be non-compliant to the RFC. Once again the action whether the messages should be passed or logged is decided by the user during configuration. The default behavior is to allow all the hard coded extension methods. Examples of extension methods include: INDEX, MOVE, etc. For a complete list of extension methods supported please refer to Appendix A. 4. Select whether a subset of mime-types are to be permitted through the firewall. The user will be provided with a predefined list of mime-types ex. image/Jpeg, text/html, application/msword, audio/mpeg. The user can choose whether only the mime-types mentioned in this list are to be permitted through the firewall or all mime-types are acceptable. The default behavior is to allow all mime-types. 5. Configure the minimum and maximum size of an http message body. When a request or response HTTP message passes through the firewall, a check will be made to ensure that it meets the size constraints. If it does not the action configured for this policy by the user will be executed. 6. Verify that the content-type specified in the header is the same as that being passed in the body of the http message. If a discrepancy is noticed then the action that the user configured is executed. 7. Validate that the content-type passed in the response message is one of those listed in the request message’s accept-type field. Once again if a violation is detected the action specified in the policy is taken. 8. Specify whether all traffic not compliant to the HTTP standard should be permitted or logged. By default the behavior is to disallow all non-http traffic through the firewall. The user can change this default behavior during configuration. 9. The ability to filter http messages on keywords. When a message transmitting the keyword is detected the appropriate action for this rule will be taken. An example where this is useful is when looking for Yahoo Messenger running over HTTP. The keyword will be YMSG should be in the first 4 bytes of the HTTP data. 10. The ability to specify the maximum header length for HTTP request and response messages. 11. Ability to configure the maximum size of URI to be permitted through the firewall. 12. The ability to catch double encoding attacks (aka de-obfuscation) New CLI introduced for this inspection engine includes: inspect http map <http_map_name> http-map <map_name> Note: these are used as part of the new Modular Policy Framework introduced in PIX OS 7.0. Once a particular traffic stream (possibly on port 80, 8080, or any other user-specific port, etc) is selected, the http-map further refines the search to what traffic to target and what actions to take when offending traffic is found. In the http-map sub-mode, the following new commands will be added: strict-http content-length content-type-verification max-header-length max-uri-length port-misuse request-method transfer-encoding Usage of these sub-mode commands are as follows: strict-http action { allow | reset | drop } [log] content-length {min <bytes> max <bytes> | min <bytes | max <bytes>} action {allow | reset | drop} [log] content-type-verification [match-req-rsp] action {allow | reset | drop} [log] max-header-length {request <bytes> response <bytes>} action {allow | reset | drop} [log] max-uri-length <bytes> action {allow | reset | drop} [log] request-method rfc <rfc_method> action {allow | reset | drop} [log] (used for RFC 2616 conformance checking) request-method ext <ext_method> action {allow | reset | drop} [log] (used for extension methods) <rfc-method> connect | delete | get | head | options | post | put | trace | default <ext-method> index | move | mkdir | copy | edit | unedit | save | lock | unlock | revlabel | revlog | revadd | revnum | setattribute | getattribute | getproperties | startrev | stoprev | default port-misuse <appl_category> action {allow | reset | drop} [log] <appl_category> p2p | tunneling | im | default transfer-encoding type <coding_types> action {allow | reset | drop} [log] } <coding_types> default | chunked | compress | deflate | gzip | identity
SYN Cookie: SYN Cookies is a way to mitigate TCP spoofed SYN attacks. Attacker sends SYN packets that lies about its src address. TCP resource exhaustion bc server needs to maintain due maintaining state of embryonic connection (per SYN packets). If src replies with a SYN ACK then it will not cause the server exhaustion. SYN Cookie serves as a proxy for the TCP connection to the server. Sensor acts as an endpoint for the server from the source side, as if the sensor where the final destination. So if there is a SYN attack, the server never sees the SYN packet. So support for SYN cookies allows the security device to not keep state of the connection until it has been proven valid. Main reason traceback. Atta sends syn. Server sends SYN ACK. Underlying OS of the attacker automatically sends a rst packet to the server. When the server sees the rst packet he drops the connection state. The attacker does not send an ACK instead of a RST since most OSs a memory militiation of keeping state of embryonic (half open connections). So the rst thwarts the flooding process. RST sent from attacker to server TCP Worm detection: For every TCP flow that has seen a SYN packet and no other packet for X seconds, send an event to the AD with type TCP-non-established and data that holds the 5-tuple (sourceIP, destIP, proto=TCP, source-port, dest-port). UDP worm detection: The event definition for UDP is short, uni- directional inactive connection: UDP connection that has less than a pre-defined number of packets, all packets going only on one directional and is idle for more than a time period. Non allocated addresses: user can define 3 lists: internal, external, and un-allocated. 2 non allocated address types: Global unallocated: IP blocks that AT&T owns that hasn’t been assigned Inside org, probably use use a systematic fashion to allocate 10.1, 10.2, but non allocated 10.10, so if someone is approaching 10.10 Behavioral: Therefore, for each destination port, we keep a histogram that express the distribution of the source IPs according to their scanning "behavior." More precisely, the histogram is a table, such that entry X in the table, contains the number of source IPs that had incomplete connections to more than X dest IPs.
SYN Cookie: SYN Cookies is a way to mitigate TCP spoofed SYN attacks. Attacker sends SYN packets that lies about its src address. TCP resource exhaustion bc server needs to maintain due maintaining state of embryonic connection (per SYN packets). If src replies with a SYN ACK then it will not cause the server exhaustion. SYN Cookie serves as a proxy for the TCP connection to the server. Sensor acts as an endpoint for the server from the source side, as if the sensor where the final destination. So if there is a SYN attack, the server never sees the SYN packet. So support for SYN cookies allows the security device to not keep state of the connection until it has been proven valid. Main reason traceback. Atta sends syn. Server sends SYN ACK. Underlying OS of the attacker automatically sends a rst packet to the server. When the server sees the rst packet he drops the connection state. The attacker does not send an ACK instead of a RST since most OSs a memory militiation of keeping state of embryonic (half open connections). So the rst thwarts the flooding process. RST sent from attacker to server TCP Worm detection: For every TCP flow that has seen a SYN packet and no other packet for X seconds, send an event to the AD with type TCP-non-established and data that holds the 5-tuple (sourceIP, destIP, proto=TCP, source-port, dest-port). UDP worm detection: The event definition for UDP is short, uni- directional inactive connection: UDP connection that has less than a pre-defined number of packets, all packets going only on one directional and is idle for more than a time period. Non allocated addresses: user can define 3 lists: internal, external, and un-allocated. 2 non allocated address types: Global unallocated: IP blocks that AT&T owns that hasn’t been assigned Inside org, probably use use a systematic fashion to allocate 10.1, 10.2, but non allocated 10.10, so if someone is approaching 10.10 Behavioral: Therefore, for each destination port, we keep a histogram that express the distribution of the source IPs according to their scanning "behavior." More precisely, the histogram is a table, such that entry X in the table, contains the number of source IPs that had incomplete connections to more than X dest IPs.
Risk Rating —Offers unprecedented reliability and complete confidence to enable your inline prevention deployment. Traditional intrusion prevention has relied on severity rating as its sole method of determining the potential damage associated with an event. In contrast to simplistic ratings used by traditional IPS solutions that only consider values like the event severity, RR uses 4 discrete terms whose aggregate delivers the RR rating. Some of these terms are user definable. The terms are: Event severity —Rating indicating potential damage per event Signature fidelity —Rating indicating accuracy of the signature. For example, how prone that specific sig. is to a false positive (in v 5.0 each sig. will be delivered with its unique fidelity rating). Asset value — The asset value term allows the user to define the assets value for various mission critical components on the network. So if there is a mission critical server that contains credit card info., for example, the asset value for this server can be escalated Attack relevancy —Value based on the susceptibility of the target to this attack type The aggregate of these values provides a single Risk Rating for the event. Most of these terms are configured by default and require minimal user involvement. The Risk Rating is then applied to each signature. It takes on a value between 0 and 100 and the higher the RR value, the greater the confidence that the event detected is an indication of malicious activity (vs a false positive). RR Thresholds may be applied to dictate the response action that are applied to certain behavior that is detected by the sensor. So for example, if the user sets 2 thresholds at , 30 and 80, he may also set associated actions that the sensor must dynamically execute once those thresholds are exceeded. So according to the preceding example, the user may choose to generate an alarm only when RR <30 and perhaps generate an alarm and perform an ACL modification on a router for alarms that have a RR between 30 and 80, and they may choose to drop the packet and not display the alarm when the RR value exceeds 80, since this indicates a high confidence level that the event generated is actually a true event.
Enhanced Portal Design eliminates mandatory pop-up toolbar Drag & Drop Webified File Access Support for new webified file transport (FTP) Head-end deployed applets for telnet, SSH, RDP, and VNC as well as overall framework to support new plug-ins Advanced port-forwarder for Windows (SmartTunnel) – least privileged operation providing access to TCP based applications without the need to manually configure individual ports IPv6 internal resource access over an IPv4 connection Text resources will be externalized, allowing for administratively defined translation/localization of all user visible content Ability to define RSS newsfeeds on portal page Access AnyConnect (Network access) client from Portal page Personal bookmark support Transformation enhancements including Flash support
I think this is enhanced authorization (vs. authentication) if we're referring to the functionality that allows us to map users better taking in to account LDAP and posture status
Details at http://stg-wiki.cisco.com/index.php/Cisco_AnyConnect What is the Cisco AnyConnect VPN Client? A. The Cisco AnyConnect VPN Client is the next generation of the Cisco SSL VPN Client. It provides many new options that were not previously available with the SSL VPN Client, including, but not limited to: Additional platform support for Microsoft Vista 32-bit (x86), Vista 64-bit (x64), Windows XP 64-bit (x64), Mac OS X, Linux Intel and Windows Mobile 5 handheld devices (Pocket PC Edition, release estimate ~CY4Q07). Optimized tunneling for latency-sensitive traffic using Datagram Transport Layer Security (DTLS) Ability to establish a standalone VPN connection without needing to use a Web browser Ability to establish a VPN connection through a clientless portal link (download and/or auto-launch AnyConnect) Microsoft Installer package for simplified pre-deployment
This slide provides information for the administrator on where to configure Proxy/PAC support.
DTLS is defined in RFC 4347 DTLS stands for Datagram Transport Layer Security. It is defined under RFC-4347 Created to deal with datagram based applications that are latency sensitive Implemented as part of the standard OpenSSL package Looks like SSL over UDP to a firewall
The AnyConnect 8.0 clientless interface is highly customizable and localizable. Administrators can add non-English language text, change the actual information shown, configure population of newsfeeds via (RSS) and even allow for users to have their own personal customization & bookmarks. The customization/bookmark information is stored off-device on a file server and accessed via the CIFS (or FTP) protocol. This allows the information to easily be shared between multiple devices. Additional sophisticated web content is supported in clientless mode with every release. In addition, Single Sign On (SSO) options have been increased in the ASA 8.0 release to now include support for the RSA Access Manager protocol via the SAML protocol. Previous support was available for CA Siteminder (Netegrity) and Basic/NTLM/Form based pass through. In addition, user information such as login username and password can now be sent off via a web link to ease the SSO process. WebFolders is a new feature that allows the administrator to make use of the native Windows Explorer application in order to manage webified file shares. This feature is compatible with the Internet Explorer browser on Windows platforms. Smart Tunnels is described in more detail later on in the presentation. The goal of Smart Tunnels is to provide access to as many TCP based applications as possible without the need for administrative rights on the remote system. This feature is compatible with most Winsock v2 compliant TCP applications, but does not presently provide compatibility for Outlook communicating with an Exchange server (MAPI). This is a Windows 2000 & XP (x86) feature only.
This is a screenshot of the new clientless user interface in ASA 8.0. A significant portion of the information shown is customizable and the interface has been redesigned to focus on the end user experience.
Screenshot shown on this slide is for webified file access. The Webfolder user experience will be similar to that of utilizing Windows explorer. New support is available for the FTP protocol in ASA 8.0. Current support includes CIFS and FTP.
Screenshot shown on this slide is for webified file access. The Webfolder user experience will be similar to that of utilizing Windows explorer. New support is available for the FTP protocol in ASA 8.0. Current support includes CIFS and FTP.
Left screen shot shows example of how the administrator will import a plugin. Right side of screen shows an example pull down list with options for the configured plugins.
Screenshot shown on this slide is for webified file access. The Webfolder user experience will be similar to that of utilizing Windows explorer. New support is available for the FTP protocol in ASA 8.0. Current support includes CIFS and FTP.
Screenshot shown on this slide is for webified file access. The Webfolder user experience will be similar to that of utilizing Windows explorer. New support is available for the FTP protocol in ASA 8.0. Current support includes CIFS and FTP.
Screenshot shown on this slide is for webified file access. The Webfolder user experience will be similar to that of utilizing Windows explorer. New support is available for the FTP protocol in ASA 8.0. Current support includes CIFS and FTP.
Screenshot shown on this slide is for webified file access. The Webfolder user experience will be similar to that of utilizing Windows explorer. New support is available for the FTP protocol in ASA 8.0. Current support includes CIFS and FTP.
Flow of a CSD protected connection Secure Session, also called Secure Desktop or Vault, encrypts the data and files associated with or downloaded during the remote session into a secure desktop partition, and presents a graphical representation of a desktop that includes an image of a lock to signify a safe environment for the remote user to work in. Upon session termination, it uses a U.S. Department of Defense (DoD) sanitation algorithm to remove the partition. Typically used during clientless SSL VPN sessions, Secure Session attempts to reduce the possibility that cookies, browser history, temporary files, and downloaded content remain after a remote user logs out, the session times out, or after an abrupt termination occurs. Secure Session runs over Microsoft Windows Vista, Windows XP, and Windows 2000. If a prelogin policy is configured to install Secure Session, but the operating system on the remote computer does not support Secure Session, Cache Cleaner attempts to install instead. Secure Session does not encrypt or clean system memory information, including that which may be left on the disk by the operating system in the Microsoft Windows virtual memory file, commonly referred to as the paging file. Secure Desktop Manager provides an option that seeks to disable printing from within a user session. If local printing is permitted, there may be instances when data can remain in the local system print spool.
Enhanced Portal Design eliminates mandatory pop-up toolbar Drag & Drop Webified File Access Support for new webified file transport (FTP) Head-end deployed applets for telnet, SSH, RDP, and VNC as well as overall framework to support new plug-ins Advanced port-forwarder for Windows (SmartTunnel) – least privileged operation providing access to TCP based applications without the need to manually configure individual ports IPv6 internal resource access over an IPv4 connection Text resources will be externalized, allowing for administratively defined translation/localization of all user visible content Ability to define RSS newsfeeds on portal page Access AnyConnect (Network access) client from Portal page Personal bookmark support Transformation enhancements including Flash support