Cisco is jumping into the Anti-virus and Data Leakage Prevention (DLP) client market with their recent release of Cisco Security Agent 6.0 (CSA). CSA has been around for quite a while now but was focused mainly on addressing the HIPS, PFW, and 0 day protection market. CSA 6.0 broadens that scope by adding AV, DLP, and some way overdue ease of use/deployment features to the product line. Cisco CSA is a security client that runs on windows, linux, and solaris systems, both servers and desktops, to protect them from malicious harassment. I’ve always considered CSA to be the most effective security product that Cisco has in its portfolio. However, CSA has never been able to capture that valuable desktop and server footprint like Mcafee, Symantec, etc. have. By moving CSA simultaneously into both the hot DLP market and the capital rich AV market Cisco hopes to change that. The devil is always in the details so let’s walk through some of what’s new.
First Anti-virus; Cisco has embedded the open source ClamAV product into CSA 6.0. Clam is a free AV client that has a big footprint but mostly on Linux systems, especially email gateways. The embedded ClamAV is managed and updated using the centralized CSA management center (CSAMC) so it doesn’t require a separate management station. ClamAV doesn’t really add any new protections to CSA’s behavioral malware detection but it does allow for the naming of that malware and allows for on-demand or periodic scans of the system. It also will detect and stop non-malicious, but otherwise annoying, adware type apps from installing; something that CSA alone would not do in the past.
By embedding AV functionality into CSA companies are now able to comply with regulations, like PCI, that require AV to be installed on hosts without forcing them to use another AV agent. This was not possible before CSA 6.0. Given that AV is a heavily commoditized product with little variance in protection from vendor to vendor this prospect could become attractive to companies.
Now on to DLP in CSA 6.0. CSA has traditionally had the ability to control what data can be written to external devices like USB, Bluetooth, CD-R, etc but CSA 6.0 takes it one step further. Now CSA can tag files on the system that contain sensitive information, like credit card number, SSNs, etc. and allow you to write data protection policies based on those tags. These policies can limit things like writing tagged files to external devices, printing, copying to clipboard, etc. CSA even allows you to control what applications can access this data, change your personal firewall rule sets dynamically when you open and close a sensitive doc, and limit your ability to connect to a non-secure wireless network. It can also force users that are offsite and possess sensitive data to always initiate a VPN back to head quarters when they try and use the network. This allows you to gain additional protection from your security appliances at HQ, for example IPS, mail and URL filters.
CSA 6.0’s DLP features extend to allowing you to monitor, report, and track sensitive data throughout your enterprise. You will be able to see, real-time, what hosts contain sensitive data, how that data has been accessed, shared, printed, or external saved/moved. DLP policies can be written such that if a user tries to perform a suspect action with sensitive data like say print it CSA can pop up a dialog box that displays the security policy around this action and allows the user to type in a justification for an override. CSA also allows you to pop up an Acceptable Usage Policy that users must accept to perform a given action on sensitive data.
The final noticeable improvement in CSA is the new management GUI. It has been enhanced with the sole purpose of making it easier to use. The default CSA security policies have been rewritten so they produce less false positives, a brand new reporting and monitoring section has been added, PCI templates have been added along with a bunch of new wizards like the tuning wizard. Cisco has added an interactive quick start tutorial to bring new admins up to speed quickly.
The CSAMC homepage has been replaced with a slick new dashboard with all sorts of new views.
A new default view called simple mode allows new admins to use wizards and point and click simplicity to configure their policies. Much of the configuration has been reduced to wizards and checkboxes instead of the previous versions complex rules configuration screens. The more complex screens are still available for advanced users by switching to advanced mode.
Cisco’s CSA 6.0 looks to be a big release for the company putting it squarely in the sites of incumbent powerhouses like Mcafee and Symantec. Do you think Cisco is up to the challenge?
For more information see www.cisco.com/go/csa
CSA 6.0 Configuration Guide
http://www.cisco.com/en/US/partner/docs/security/csa/csa60/user_guide/CSAMC_UserGuide.html
Whitepaper on CSA’s embedded AV features.
Datasheet on CSA’s DLP features.
To download a free 30 day evaluation go here
The opinions and information presented here are my personal views and not those of my employer.
Jamey Heary, CCIE No. 7680, is a security consulting systems engineer at Cisco. He leads its Western Security Asset team and is a field advisor for Cisco's global security virtual team. Jamey is the author of the recently published Cisco NAC Appliance: Enforcing Host Security with Clean Access. His areas of expertise include network and host security design and implementation, security regulatory compliance, and routing and switching. His other certifications include CISSP, CCSP, and Microsoft MCSE. He is also a Certified HIPAA Security Professional. Jamey has been working in the IT field for 14 years and in IT security for 9 years.
The opinions expressed in this Weblog are those of the writer and may not represent the opinions of Network World.
|
|
Having evaluated CSA 6.0 myself...
Well, it worked pretty well for me. There's an awful lot of behaviour-based stuff in there that really gets down to the nuts and bolts of the underlying OS. However, the DLP stuff turned out to be a real let down.
In principle it's a really good idea being able to tag data and modify behaviour accordingly, and there's some nice details. For example, if an application handling sensitive data accesses the clipboard, the clipboard is 'tainted' - and any other apps the clipboard subsequently touches are also flagged as handling sensitive data.
The problem arises with the tagging itself. It has preset patterns for credit card and US Social Security numbers, or you can enter a non-case-sensitive string. And that's it. No regexes, no other pattern matching.
Which makes it basically useless to me, as I'm in the UK and don't do anything with credit cards. There's no point tagging files containing the word "secret" if it also catches "secretive" , "a shared secret" or "secreted".
C'mon Cisco, you can do better than that surely!
pattern matching
In your example matching on secret, CSA will not match on anything but the whole word secret. It will not match secretive or shared-secret like you mentioned. If you use wildcards then it will for example if you do secret* then it will match secretive. You can also do things like cisco*confidential. this will allow up phrases like cisco CSA roadmap confidential to be matched on.
Here are the complete rules. I completely agree that CSA needs full boolean support however. HOpefully in a future release.
Scanning Data Tag Search Patterns
The Patterns field of the Data Classification - Scanning Tag pop-up is where you specify the pattern that your content tag represents.
There are two types of patterns can be specified in this field:
Text-matching Search Patterns
Built-In Scanning Patterns
Text-matching Search Patterns
Text-matching patterns can contain any strings of characters or numbers specified by the administrator.
Note: In general, long text-matching patterns usually will be more effective than short patterns. Searching for long text-matching patterns prevents CSA from assigning content tags to files that you did not expect or intend to match. For example, by searching for the pattern Company confidential. For internal use only CSA is more likely to find and tag files that are truly confidential than if your pattern was only the word confidential.
These are the syntax requirements for character-matching search patterns:
CSA’s string-searches support English, and languages other than English, whose character sets can be represented by 2-byte UNICODE text-encodings. (Currently, this excludes Asian and Semitic languages.) We also support accented Latin, Greek, and Cyrillic characters, as long as each letter and its accents are included within a single two-byte character.
Note: In order to match strings with accented characters, the string must be entered twice using both the “combined encoding” and the “pre-composed encoding” UNICODE formats.
Text-matching patterns are not case sensitive. For example, the pattern cisco will match Cisco and cisco.
A text-matching pattern can be no more than 256 characters long including wildcards. For example, the pattern: confidential* is 13 characters long.
The smallest text-matching pattern you can search for, not including wildcards, is two characters long.
A text-matching pattern, by default, can only match a whole word or phrase, and not part of a word. Therefore, a pattern such as confidential will not match the word nonconfidential in a file.
Wildcards, represented by a * , can be used to match prefixes and suffixes of a word as well as character strings in between other strings. Here are some other examples:
The pattern *confidential matches nonconfidential.
The pattern confidential* matches confidentiality.
The pattern *confidential* matches nonconfidentiality.
The pattern confidential does not match nonconfidential, confidentiality, or nonconfidentiality.
If multiple words are specified, and they are included on the same line in the Patterns field, they must appear in the same order in the target file to be considered a match. If words are entered on separate lines, the presence in the file of any of the lines in the Patterns field, in any order, is considered a match.
A wildcard can be used in the middle of a string with more than one word. In this case the wildcard breaks the pattern into three parts: the string before the wildcard, the wildcard, and the string after the wildcard.
CSA will match the pattern, Cisco*confidential, to a string that begins with Cisco, ends with confidential and has no more than 50 characters in between Cisco and confidential. For example Cisco*confidential will match Cisco Security Agent - Company Confidential because “ Security Agent - Company ” is only 26 characters long.
Numeric strings are matched like alphabetic strings. The whole string in the Patterns field must be matched exactly in the file to record a match; if there is more than one number on a line in the Patterns field, that entire string must be present in the target file to make a match; and wildcards may be used to match longer strings of numbers.
Though wildcards can be used to match strings of numbers, if you use wildcards, you may end up matching other alpha-numeric strings that you did not expect or intend to match with your string. Entering exact strings of numbers in the Patterns field will produce the most accurate results.
These are examples of using wildcards with numbers:
The pattern 9785551234 will only match 9785551234.
The pattern 5551234 will not match 9785551234.
The pattern *5551234 will match PART5551234.
The pattern *8555123* will match 1234978555123ABCD.
The pattern 978* will match 9785551234 as well as many other alpha-numeric string that you may not have intended on matching.
Post new comment