I interviewed Kurt Roemer for this topic.  Kurt is Chief Security Strategist for Citrix Systems and a member of the CTO Office. He's a seasoned information security veteran with more than 20 years experience in networking, applications, and the evolving Web services infrastructure markets. He has designed, implemented, and assessed solutions and policies for Fortune 1000, mid-size, and government organizations worldwide.  Roemer is a CISSP and has spoken at a wide variety of leading industry shows and conferences across the globe including BITS, CSI, RSA, Networld+Interop, Japan's inaugural Web Application Security Forum, Society for Information Management, ITEC, SecureAsia and numerous regional ISSA and InfraGard conferences.  He has also appeared as a security expert on CNN, Fox Business News, and the Fox News Channel and is well known for his popular "Web Hacking Live" sessions. Prior to joining Citrix, Kurt held roles as CTO/CSO at NetContinuum and headed up information technology practices at Micron Electronics, NetFRAME and Hewitt.

Q: Kurt, isn't Cloud Computing competitive with Citrix?
A:  In some ways, yes, but in many ways interest in Cloud Computing actually creates opportunities for Citrix.  Our NetScaler and XenServer products are good examples of this.  Both   NetScaler and XenServer are powering major cloud providers today.  We also have partners, such as 3Tera, who are hosting applications, using XenApp and XenDesktop, on the Cloud.

Q: It seems to me that Cloud Computing requires that you really trust the provider - after all you are turning over your valuable data to them - is this a consideration?
A: Yes.  The old security mantra was that physical security trumps all. With the Cloud you lose control over physical security.  The actual servers could be anywhere the provider decides to put them, factoring in availability and least cost.  This is significantly different than a SaaS model, especially as you factor in access to data, backups, encryption keys and other security concerns.
When you sign an agreement with a provider you agree to pay for a certain amount of storage and resources like applications and are committed service levels.  You lose control over the assets in some respects and therefore the security model must be refactored.

Q: The security concerns with this must make security professionals uncomfortable.  Tell me more about what Citrix has to offer to improve this situation.
A: The fundamentals are encryption of data and access control to data.  Citrix has recently introduced the Citrix Cloud Center, which is composed of several Citrix offerings.  Access Gateway and NetScaler address encryption, and Access Gateway provides authentication services.  In addition to the security features, the Citrix Cloud Center provides geo-location with NetScaler (where the user can be connected to different hardware in different regions in the world, but yet have all the same applications and capabilities), local data caching with WANScaler and orchestration with Workflow Studio.  Citrix is also working with key ecosystem partners to enable end-to-end security in the cloud model.

Q: What is the future of security in Cloud Computing?
A:  The ultimate solution is data level security.  After all, sensitive data is the domain of the enterprise, not the Cloud Computing provider.   Security will need to move to the data level so that enterprises can be sure their data is protected, wherever it goes.  For example, with data level security, the enterprise can specify that this data is not allowed to go outside of the US.  It can also force encryption of certain types of data, and permit only specified users to access the data.  It can provide compliance with PCI.  We are working with several partners in the data security area.

I interviewed Glenn MacDonald  for this topic.  Glenn is a Senior Software Engineer at Citrix. He has been with Citrix since 2003 and has worked on every release of Password Manger.  He has a Masters degree in Computing Science from Simon Fraser University and over fifteen years of software development experience.  The interview did not actually take place on the yacht, below.

Q: When did CPM begin to provide provisioning?
A:  The CPM Provisioning feature was introduced during the Nassau release in 2005. The intent of this feature was to empower CPM administrators with the ability to provide users' secondary credentials directly to CPM, rather than forcing users to do so.  Being unable to do this had been an administrator pain point during CPM roll outs and when new applications were added to deployments.
In  a sense, provisioning in CPM provides additional security, in removing the responsibility from users for providing secondary credentials,  as users tend to do things like write down their passwords before entering them.

Provisioning in CPM increases the security by avoiding the initial distribution of credentials details directly to the user. Typically this is done by a less secure method such as a memo, voice mail or email.Another focus of the feature was to provide a means to integrate with existing identity management and provisioning systems (e.g. Courion Account Courier).

Q: Does CPM provisioning set up user accounts in applications?
A: No, it just informs CPM of the users' the credentials.

Q: How does it work?
A: The new web service (the Provisioning service) responsible for receiving the provisioning commands was added to the CPM Service.  These commands are added to a per-user queue located in the user specific container of the central store. Eventually the Plugin executes the queued commands to complete the provisioning action.

Q: Is it really that simple?

A: Of course not! There are lots of details to do this securely, but that's the basic flow.

 Q: Can you elaborate on those security details?
A:  Recall that the CPM Plugin protects a user's credentials using user specific keys. (i.e. Only the Plugin running in a user session can obtain the keys). This implies that it is impossible for the Provisioning service to directly execute the commands and alter the user's central store data. (i.e. the service can't add a credential because it doesn't have the key to protect the secrets).  This is why the commands are queued until a Plugin running as the user requests them. The service is completely responsible for the life cycle and encryption of the queued commands.

The Plugin does not directly access the queued commands - it obtains them from the Provisioning service over an SSL connection. Once the Plugin has successfully executed the commands, it informs the service that the queue can be deleted.
 
Q: Is the provisioning feature standards-based, since there are many provisioning products out there to integrate with?
A:  As a matter of fact, it is.  To ease third party integrations, we opted to use the SPML V2.0 open standard. The Service Provisioning Markup Language (SPML) is an XML-based framework, developed by OASIS, for exchanging user, resource and service provisioning information. Additionally, many identity management systems already support SPML 2.0.  A connector is required for identity management integration.

Q: Why do I need a custom connector if my identity management system already supports SPML 2.0?
A: To understand why a custom connector is needed, you need to consider the conceptual differences between provisioning for CPM and provisioning in general.

Consider a typical provisioning scenario from the perspective of an administrator of an identity management system. A new employee has joined the company and needs to be provisioned with a domain account and specific accounts for SAP, Outlook, etc. The administrator will request that an SAP account get created. To do this, the identity management system will send a message to the Provisioning Service Provider (PSP) for SAP.

"Hey SAP PSP, create a new account with user name=baracko and password=prez"
The Provisioning Service Provider will create the account and return a reference ID for the account.

Next, the administrator would want to provision CPM with the newly created SAP credential. The message that the CPM Provisioning Service needs to receive must say:
"Hey CPM Provisioning Service, for the domain user bobama, add a credential for SAP having the user name=baracko and password=prez"
First, notice that provisioning from the CPM perspective is simply providing the user with his CPM secondary credentials. There is NO creation of the accounts accessed with those credentials. Those accounts must be created by an outside means completely separate from CPM. Essentially, CPM provisioning is the act of populating the user's credential store - i.e., the administrator is populating a small data store and not actually provisioning accounts or resources.

Q:  I sort of see what you mean. The CPM provisioning command added the SAP credential for the specified domain user, it didn't actually create the SAP account. How does CPM know what "SAP" refers to in the command?
A: Good, you've noticed the second subtlety. Ultimately, the goal is to have CPM submit this credential when it detects to the SAP logon page. To achieve this, the credential needs to be associated with a specific application definition.

A unique GUID is assigned to every application definition when it is created in the CPM Administrative Console. This GUID is included in the command to provide the link between the credential and the application that the credential is for. So, the message actually needs to be:
"Hey CPM Provisioning Service, for the domain user bobama, add a credential for GUID-of-SAP-application-definition having the user name=baracko and password=prez"
The connector needs to provide the mapping between the application definition GUIDs and the credentials.

Q: How does the custom connector learn the application definition GUIDs?
A:  To determine the list of applications definitions available to a user, the connector needs to send a lookupApplicationRequest. The response to this will contain a list of the applications defined in the User Configuration associated with that user. The description of each application definition will contain the GUID and the fields in the a credential (e.g. user id, password and database name). Note that the lookupApplicationRequest command is a CPM specific, custom extension to SPML v2.0.
 
Q: Are you saying a custom connector is needed because it has to provide the binding between the CPM application definitions and the specific credentials?
A: Exactly!
The connector needs to know:

-  the mapping between the application definition GUIDs and the credentials.

- how to use the lookupApplicationRequest custom command to obtain the application definition GUIDs

- how to construct the CPM specific SPML extensions to use in the data elements of the commands.

Avoiding being Phished
I interviewed Brandon Olekas for this topic.  Brandon is a Lead Security Engineer at Citrix. He has been working in XenApp security for about four years, has been involved with many security features and improvements in the XenApp product, and helped co-author  Citrix Access Security for IT Administrators. He has a Computer Science degree from Georgia Institute of Technology and is an Associate of (ISC)².
Here is Brandon:

Q: What is Phishing?
A: It is a form of Social engineering - attempting to fool people into revealing information that is subsequently used against them.
Phishing doesn't require a lot of capital, so it is no wonder it is so prevalent.  Research firm Gartner Group estimates that phishers will cost US businesses and consumers a whopping $2.8B this year.  The average take: $1244 per victim.

Phishing primarily targets stealing personal information through the use of e-mail and websites. Phishing emails usually appear to come from well-known financial institutions (which they are not) and their goal is to acquire login information, credit card numbers, social security numbers, or account numbers.

Phishing e-mails attempt to entice the user into clicking a link which will direct them to a malicious website. The thing is, legitimate businesses will never request this information via e-mail.

Bottom line is, if you receive an e-mail asking you to login to your bank, do not click the link. Open a browser and go directly to the official bank site.

Q: Don't malicious Phishing sites also attempt to do damage to the victim's computer?
A: Actually, most virus scans catch virus-infected attachments now.  Phishers are looking to steal personal information.  One other case that comes to mind is the Nigerian scam, which is considered phishing because they attempt to fool victims into sending money.  The victims were enticed to send actual money to the Phisher after being convinced some amount of their own money was required to free up the large winnings.  Even though this sounds ludicrous, many victims fell prey to this scam.  Even now, people still fall for the Nigerian type scams

Q: How else can people notice the dangers and avoid "being Phished"?
A: According to phishtank.com, the most important things to look for in a phishing e-mail are:
1.       Generic greeting. Phishing emails are usually sent in large batches. To save time, Internet criminals use generic names like "First Generic Bank Customer" so they don't have to type all recipients' names out and send emails one-by-one. If you don't see your name, be suspicious.
2.       Forged link. Even if a link has a name you recognize somewhere in it, it doesn't mean it links to the real organization. Roll your mouse over the link and see if it matches what appears in the email. If there is a discrepancy, don't click on the link. Also, websites where it is safe to enter personal information begin with "https" — the "s" stands for secure. If you don't see "https" do not proceed.
3.       Requests personal information. The point of sending phishing email is to trick you into providing your personal information. If you receive an email requesting your personal information, it is probably a phishing attempt.
4.       Sense of urgency. Internet criminals want you to provide your personal information now. They do this by making you think something has happened that requires you to act fast. The faster they get your information, the faster they can move on to another victim.

In addition, in the URL, pay attention to be sure you are reading correctly.  For example, http://Realbank.hacker.com does not mean it is from Realbank.  To the contrary, it is from hacker.com. 
Also look out for numbers preceded by a % sign, which are encoded characters.  They can trick you.  For example, %47 is just a capital G, but it means the same thing to your web browser, i.e., http://%47oogle.com = = http://www.Google.com.

A good educational resource is at this site: http://cups.cs.cmu.edu/antiphishing_phil/   Anti-Phishing Phil - it's a fun online game that teaches how to recognize phishing websites.

Q: What is "Spear Phishing"? 
A: Just like regular Phishing, the objective is to entice the victim into divulging key information.  Spear Phishing is slightly different in that it is directed to a target person or group, and it is often extremely personalized.  For example, a Spear Phishing exploit may include having all the managers in a company receive a note that looks like it's from the CEO, asking them to click on a malicious web site that could look very credible.  Any person on a network is able to spoof a particular user.  Even a user outside the network could easily get a free email account with the CEO's name clearly evident.

Q: What are "Phishing Kits"?
A: These are sold on hacker forums on the internet.   They provide easy ways for nontechnical people to easily set up a Phishing operation.  Well, often the laugh is even on them: many of these kits create fraudulent web sites that actually send emails back to the Phishing Kit author, giving him the desired Phishing information, instead of or in addition to the Phisher.  Since the nontechnical Kit buyer can't read the code, they can't see that they are actually the dupe.

One of the most prolific phishing groups and kit authors is called Rock Phish.  No one can say for sure where Rock Phish is based, or whether the group operates out of a single country.  "They are sort of the Keyser Soze of Phishing," says Zulfikar Ramzan, senior principal researcher with Symantec's Security Response group, referring to the secretive criminal kingpin in the 1995 film, The Usual Suspects.  Security experts estimate that Rock Phish is responsible for between a third and a half of all phishing messages sent out on a given day.  Information was taken from, and full article can be found at http://www.pcworld.com/article/128175/who_or_what_is_rock_phish_and_why_should_you_care.html

Q: Where can people go for more general information on phishing?
A: There are some Good statistics here:
http://apwg.org/reports/APWG_GlobalPhishingSurvey1H2008.pdf

Other good resources:
[www.phishtank.com]  - Collects and verifies phishing sites. If you suspect a site is fraudulent, you can check it here.
[www.apwg.org]- The Anti-Phishing Working Group. The global pan-industrial and law enforcement association focused on eliminating the fraud and identity theft that results from phishing, pharming, and e-mail spoofing of all types

I interviewed Chris Mayers for this topic.  Chris has been with Citrix since 1998, and in his role as principal security architect at Citrix, Chris has both internal and external responsibilities for promoting security, developing security strategies and advocating the secure enterprise.  Based in Cambourne, Cambridge, Chris's job takes him all over Europe and to the USA, where he can be found advising CIOs and CSOs, presenting White Papers at industry conferences and working to develop Citrix technology to ensure it continues to protect the 'perimeterless' enterprise.

Here is Chris:

Q: Chris, first can you explain what we mean by "Strong Authentication"?
A: Strong Authentication is multiple factor authentication.  The classic definition is something you know (such as a password), coupled with something you have (such as a token or smartcard) or something you are (biometric data.)  For remote access using Web Interface, Citrix recommends that customers always use strong authentication rather than just passwords.

Q: That makes sense.  Why wouldn't everyone use strong authentication for remote access?
A: Everyone should use strong authentication, but there are choices, so it's a question of balance.  Security requirements are balanced against cost and user acceptance.   The number of users who actually need remote access, and the applications they are using must be evaluated.  There may be less expensive ways to secure remote access to simple applications such as email - using Smart Access or XenApp capabilities.

Q: What kind of cost would a customer be looking at for implementing strong authentication?
A: The good news is that the purchase price of second factor devices has come down in recent years.  A security token, for example, costs only a few dollars now.  Unfortunately there are additional costs, such as fulfillment to the user, and administrative and help desk costs; these need watching.

Q: What about user acceptance, why is that an issue for customers?
A: Well, users are required to either carry an item with them for access (something they have) or use biometrics (something they are.)  End users must be involved in this process - authentication is not something administrators can do for them.  So, users may view this as inconvenient. 
One interesting way around this is dual-purpose: combine strong authentication on an item the user can use for other tasks.  There are several solutions based on mobile phones, USB tokens (which can be used generically as well), and smartcards (which can be used for digital signature and encryption as well as authentication).

Q: Counting on users is always risky  How do you recommend IT deal with this?
A: The trick is to manage risks and have a calculated backup plan.  For example, if tokens or smartcards are used for strong authentication, and the user loses, damages or forgets the item, you might enable the help desk to temporarily allow a password to access the account remotely.  That way, even if a user intentionally "forgets" the item, there is no excuse to avoid work!

Q: What about biometrics - that way the user doesn't have to remember a device?
A: Biometrics are great for unlocking things, like laptops and doors.  The big danger for the remote access use case is that the biometric data can go over the network.   The issues with this are nasty - stolen biometric data can be much more damaging than stolen credentials (biometrics don't change like passwords do.) 

Q: Does Citrix provide strong authentication solutions?

A: No, but Citrix has numerous partners - check out Citrix Ready.

I interviewed Ola Nordstrom for this topic - way interesting!  Ola is a Senior Security Engineer at Citrix. He has been securing XenApp for the last five years. He's been involved with a number of product features and has driven numerous security improvements. He has a Master of Science in Computer Science degree from Georgia Institute of Technology and is a Certified Information Systems Security Professional (CISSP).

Here is Ola:
  

Q: Ola, what is an "Attack Surface" as it relates to software?

A: Attack Surface is a measure of how potentially vulnerable a piece of software is.  It enumerates the entry points and associated code a malicious user could employ to exploit the software. 

Q: What are examples of entry points?

A: Examples would be open sockets, RPC entry points, and even the number of web applications hosted inside a web server. 

Q: Why would the number of web apps running be an issue?

A: The more programs that are running, the more program code is exposed to malicious users finding vulnerabilities. Also, larger programs will tend to provide more opportunities for exploitation.  For example, a web application with 1000 lines of code is generally less likely than a web application with 10000 lines of code to have vulnerability.  

Q: Are there any "best practices" that can help customers reduce attack surface of the software they use.

A: Disabling unneeded features is a good step.  In fact, software vendors like Citrix are tending to disable more features by default to improve security.  Customers can also disable services and features not used - the smaller the number of features, the less attack surface is effectively available. The principle of least privilege also applies to all deployments. 

Q: What other steps is Citrix taking as a software vendor to decrease attack surface of our products?

A: We are disabling more features by default, of course.  We are also reducing the privilege of each component to the lowest possible - this is valuable in restricting capabilities of a component, even if it IS compromised.  In the web server example any vulnerabilities found will execute as the identity of the web server - so the less privileges the web server has the better off the system is. We are also focusing our security scrutiny and testing on components with large attack surface.  If a component is running with high privilege and is processing complex data (lots of code), that component has a high attack surface will receive more security review.  

Q: Can attack surface be measured?

A: Yes, there is a Relative Attack Surface Quotient metric that allows for comparisons. 

Q: Do you have any reference for more information?
A: Sure.  Measuring Relative Attack Surfaces and The Attack Surface Problem     

This is an interview with Andrew Innes.  Andrew is the Platform Architect for user interaction components of XenApp and XenDesktop, notably Web Interface and the desktop integration clients.  His job entails finding creative ways to improve the usability and security of these products, and helping strike the right balance between them.

Here is Andrew:

 Q: Andrew, what are the security issues Citrix Admins should be aware of with Web Interface?
A: Hi Kate.  There are two main categories of issues admins need to think about: security of the web server itself and security of the whole XenApp or XenDesktop delivery system.  For the web server itself, there are all the standard hardening rules to follow, especially if it is facing the Internet - I won't try to summarize these here.  The aim is to prevent intrusions into the web server itself or the network behind it.

It's worth mentioning though that Web Interface has undergone probably hundreds of evaluations in customer environments as well as regular security audits within Citrix as part of our secure development process.  It has been engineered with all the known web application threats in mind, and we track 'webappsec' developments closely to build in defenses against new styles of attack as they emerge. 

Hardening the web server itself is the #1 recommended best practice for everyone.  Some customers will still want to employ extra measures, such as a web app firewall or other monitoring systems to spot potential attacks.  NetScaler can easily be configured to provide web app firewall, SSL and detailed logs.

For the Citrix specific aspects of security, the admin should start by understanding the business reason for publishing resources (apps, desktops, documents etc) via the web, and the appropriate policies on access rights and restrictions.  These feed into the design requirements for the delivery system, including the configuration of Web Interface.  The aim here is primarily to ensure authorized users are allowed access in the intended way while unauthorized users are denied access, and that policies are not circumvented.
Web Interface has a brokering role in the delivery system, making it an effective place to enforce certain policies, for instance ensuring strong authentication happens before access is granted.  It can be augmented with Citrix Access Gateway to scan end point devices to make fine-grained access decisions; in this case Web Interface plays a supporting role in upholding those policy mechanisms.  It also implements a number of sensitive features, like password change and password reset, which can be enabled when the usability gains outweigh the security considerations.

Q: What are the prescribed security precautions Citrix Admins should use with WI?
A:  There are a few standard precautions we recommend all customers follow:
   -      Require SSL on the Web Interface server; this protects user credentials in transit and helps prevent spoofing attacks (like those that could result from the recent DNS vulnerabilities). 
   -    Use SSL or IPSec for requests to the XML service on XenApp or XenDesktop; again this protects credentials.
   -      Follow best practices for web server administration; this protects against accidental or malicious reconfiguration.
   -      Disabling the HTTP port, or having it redirect to the HTTPS port can be helpful.  Then to prevent potential phishing attacks (MITM against the HTTP connection that redirects to a replicated WI site) the Internet Option setting "Websites in less privileged web content zone can navigate into this zone" should be disabled.

Where possible, we encourage customers to consider using the Kerberos or smart card support in XenApp which avoids the need to send passwords at all.

Q: Do you have any Knowledge Base articles to reference that might be of help?
A:  There is a collection of technotes for Web Interface which cover useful points, but my favorite reference is the Troubleshooter's Guide for Web Interface.

 I don't know about you, but I've always been frustrated when reading articles about DNS Server Attacks and they never explain exactly how they work.  It's obvious that such a thing would be a point of extreme interest to an attacker, but how do they do it??? 

 I interviewed Ben Tucker, XenApp Developer on the Guardian Security Team, to finally understand this thing.  Ben worked previously in the Gaming Industry creating and securing slot machines, communications protocols, and distributed systems.
 
Here is a picture of Ben:       

 
 Q: What is DNS?

 A: DNS is a computer protocol that translates human-understandable web names, such as google.com, into IP addresses.  It's basically a telephone book that answers requests from a client to get them to the web site they want.   A DNS server answers requests and forms them into IP addresses so connections can be made.  A DNS server might talk with other servers until an authoritative answer is received.

 Q: What are the basic vulnerabilities of this technology?

 A: The client computer does not authenticate that the server providing IP addresses is really the right DNS server.  Therefore, the client has no verification that they are talking to the right DNS server, or a malicious entity, such as evil.com.

 This vulnerability has been around for twenty five years.  To complicate this further, DNS is a layered protocol.  A client in one layer might be the server from another layer.  So, this vulnerability pervades computers that lack trusted and authenticated communications.
 
Q: What has been done to fix this long-known vulnerability?

 A: When DNS was designed the security landscape was far more subdued than it is now.  Different ways to exploit the lack of authentication have been found over time.  Likewise, a series of mitigations have been implemented.  Until the last decade, transaction IDs were ascending and predictable.  Six years ago, a related implementation error led to an attack on the DNS protocol using the mathematics of the Birthday Paradox.  Overall, DNS has been a fertile ground for exploitation.
 
Q: So the problem was solved?

 A: No.  The recent DNS debacle involves forcing large numbers of fake DNS replies to a caching resolver while simultaneously controlling a client computer's requests.  Having a client repeatedly look for a DNS server gives the attacker more of a chance to improperly present evil.com as an authoritative DNS server.  Once the attacker beats the proper server with a response, then bankofamerica.com may look and feel correct to the user, but that user would be giving logon credentials to another entity entirely.

 Q: Why has this been in the news lately?

 A: Dan Kaminsky, a well-known security researcher, recently uncovered this problem and came up with a mitigation.

 First he uncovered a platform agnostic exploit that poisons a DNS cache within seconds.  Then, before releasing this exploit to the public, he worked with major vendors including Citrix to provide patches mitigating the problem.  Kaminsky's mitigation randomizes the protocol's source port as well as the transaction ID.  Now, the random transaction ID's are associated with random source ports, creating a more difficult problem for attackers in these race attacks.

 Q: How can Citrix help with this problem?

 A: We have two KB articles that may be helpful.  Please see:
 Vulnerability in Access Gateway Standard and Advanced Edition Appliance firmware could result in DNS Cache Poisoning (CTX118183)Vulnerability in NetScaler and Access Gateway Enterprise Edition could result in DNS Cache Poisoning (CTX117991)

 Q: Does HTTPS help at all?

 A: Yes.  HTTPS ensures that traffic is encrypted end-to-end.  With HTTPS, browsers can more easily notify users if the site being contacted doesn't match the intended site, if the certificate has expired, or if the certificate doesn't have a clear chain of trust to a known Certificate Authority.

 Another suggestion for customers is to consider using an Intrusion Detection System (IDS) from a security vendor or reputable security source.  This should be setup to guard corporate DNS server's from attacks.
   

I conferred with some of the security experts at Citrix on the topic of people and security.  Their advice came in several key areas:  

Physical access to IT assets: Gaining physical access to machines greatly increases the damage and theft of data a malicious user can do.   For this reason, admins should restrict physical access to sensitive resources - for example, restricting access to the XenApp farm to Citrix administrators with authorized access cards. 

Citrix products offer a great advantage in making it unnecessary to have applications and data locally stored, so physical access is less of an issue.  Some of our most security sensitive customers publish the application that can manipulate sensitive data but disable client drive mapping and the clipboard virtual channel and print screen functionality so that no data can leave the data center. 

Unattended and unlocked user workstations are also a liability and a policy that requires users to lock workstations when they leave the work area is strongly suggested.  System configuration to lock workstations after a few minutes of inactivity and password-protected screen savers are also good measures. 

Separation of Duties: Security policy should be such that no one person or role holds all control.  This means assigning roles in a manner in which it takes more than one person to accomplish certain tasks.  For example, if the task is releasing a binary to a customer, a software developer should not QA their own code.  Similarly, an administrator's activities should be monitored by a separate auditing role. 

Citrix brings value here as well, with a separate role for Citrix Administrators who share control of the overall system with Local and Network Administrators.  The Citrix Administrators manage only the Citrix environment, so there is additional separation of duties.

  Least Privilege:  The old "need to know" basis!  Well in this case, "need to have permission to do."  People's roles in an organization and access rights should be broken down to grant users only the privileges that they need for their particular jobs.  This applies to admins as well - for example, the database admin should not have management rights on the mail server or security console or the network. 

Citrix allows you to publish applications using different roles to further restrict access to certain data and privileges.   
The whole point of least privilege is that if an attacker is able to compromise an account, they can only do a small subset of tasks on the network/database/machine. 

Password Policies:

There are several ways people can weaken corporate security with their management of passwords.  The problem with passwords is users would like them to be easy to remember.  As a result, they may attempt to simplify things by using the following bad practices:

-         Write down their passwords

-         Set all of their application passwords to the same thing

-         Use really easy-to-guess passwords, like their dog's name

-         Use the same password every other time they change it (just alternating)

-         Using trivial and short passwords, like 123

-         Never changing their passwords 

These user antics are not good for corporate security!  Security Policy should specify:

-         Password length

-         Password complexity (require special characters, mix of letters and numbers, etc.)

-         Password history enforcement (force a new password and don't allow repeats for a certain number of passwords.)

-         Disallowing the use of dictionary words in the password

-         Prohibit the use of obvious words, like Citrix, in a password

-         Password expiry, forcing password changes 

Enforcement of this policy is a different matter.  Citrix Password Manager can help administrators enforce these policies in a corporate setting.  Plus, with CPM you can configure such that users do not even know their own passwords, very effectively preventing sharing.  As a side benefit, if the user leaves, de-provisioning and assuring the user can no longer access any assets is much easier, since the user didn't know their passwords in the first place. 

Robert O'Keefe has created a demo of how to use the Citrix Password Manager Localization SDK, which can be used to localize the CPM plugin to languages beyond those natively supported.

video:src=http://www.youtube.com/watch?v=sYxBOsIGzc8

I read several articles about research on the behavior of IT professionals recently.  The research was sponsored by security vendor Cyber-Ark.  Amazing stuff!  A third of all IT professionals surveyed could still access the company's network after they left the job.  A third admit to snooping and peeking at  information like people's personal emails, salary info and other juicy tidbits.  Most shocking: 50% of all IT professionals still keep passwords on Post-It notes.  These are administrative passwords!!  The really omnipotent accounts!!

The press release from Cyber-Ark has more details.  The survey was of 200 IT professionals at April 2008's Infosecurity Exhibition Europe, and it was entitled "Trust, Security and Passwords". 

Interestingly, these folks admitted these things in an anonymous survey, but aside from that they might never be detected in their snooping - admin passwords generally give privileged and anonymous access to systems.

One point: there's a difference between snooping and corporate-policy-based monitoring of company IT assets.  The survey was pointing out the fact that IT administrators can inappropriately access information and they count on not being caught.

I spent some time recently chatting with Ross Duncan, VP of Channels at Gemalto, due to my role as product manager for Citrix Password Manager.While Citrix remains "strong authentication agnostic", Ross raised some great points: - Passwords are bad - I don't think anyone will argue this point!  There have been many solutions to enforce management of passwords to mitigate the inherent weakness.  Then those "solutions" that make passwords more complex can cause user convenience problems - plus bad behavior such as passwords written down, using the same password for many applications, and so on.  Then the help desk calls are both extensive and expensive.  - eSSO means putting all the keys to the kingdom in one place.  This allows IT to use hyper-secure passwords (20+ characters, special characters, etc.) that change rapidly.  However, the end user now has only ONE password to know - therefore there is a case to augment it with a strong authentication device like Gemalto smart cards. - Coupling of eSSO and smart cards brings the ultimate in convenience with maximum security - the user inserts their card, enters their PIN, and they can securely access the system.  This is much easier then entering user name/password - easier and more secure. - Vendors like Gemalto are integrated with Citrix Password Manager, smooth roaming/Hot Desktop, XenApp and CAG, which is convenient for customers.
We also discussed the merits of converging logical and physical security.  This always looks great on powerpoints, but it has been a real slow starter in real life.  It's been discussed for 8 years that I personally know about, but the actual implementations are lagging.  It always struck me this way: the physical security personnel and the IT security personnel are usually in different areas within and organization, and there are numerous political barriers to having the two groups work together and contribute budgets to make a badge/technology/management decision together.  I know Gemalto has partnerships to do this, but it seems to me to face obstacles.  Would like to hear comments!
 

I attended the Courion Converge show, with the theme "Demystifying Provisioning and Access Compliance,"  in Chicago last week.  Courion, if you don't know it, is one of our partners and a reseller.   Courion provides a Courior suite of products, including AccountCourier, which CPM is tightly integrated with for user provisioning.  Converge is their yearly customer event.  Citrix was a Platinum sponsor.

 Courion AccountCourier is seamlessly integrated with Citrix Password Manager for eSSO.  See a flash demo here.

 Observations from Converge:

- The main industry vertical customers attending were financial and health care.   User provisioning is a key issue and it is very expensive to do manually 

- RoleCourier is gaining traction as customers are using it to avoid complexity, excessive roles, and political situations that arise when doing role-based provisioning

- ComplianceCourier is getting a lot of interest for its capability to enable business managers to periodically review and verify employee access rights

- There was a great customer presentation from Goodyear Tire and Rubber Corporation, where they discussed a previous failed attempt at implementing IAM, followed by their project with Courion, which is rolling out very smoothly.  One interesting note: a focus on educating and motivating users to appreciate the new system really pays off.

Autonomic security, AKA, self-healing, self-defending, situation aware security, or feedback-based security management, has long been a dream in distributed IT computing.  It could be the reason that this dream was not realized is that it is too hard to do in distributed computing.

 Enter virtualized computing, with centralization and much greater control over the [wily careless security-ignorant only-cares-about productivity] user.  Now does that change the complexion of the problem?

 The enemy is the usual: malware, such as worms, viruses and trojans, plus future attacks we don't even know about now.   Malware designers unfortunately have the upper hand, with ever stealthier approaches to evil.  Most security countermeasures are simply responses to known threats.  Thus the bad guys are controlling the game.

With virtualized computing, IT asserts more control.   Might it not be possible to realize autonomic security more effectively?  One of the problems distributed computing has is relentless complexity and lack of control.  With distributed computing, the end user is in the driver's seat!  Maybe if all end users were very diligent about security this would be fine.  This is sadly not the case.

 Autonomic security affords the luxury of not relying on a human to notice things are stealthily going amok.  It is possible to monitor what is going on in the network, applications, OS's, processors, and so on.  With a virtualized environment, does this not become easier?

To be clear, it is possible autonomic computing actually creates additonal security challenges, dong things automatically like changing system configurations, interconnections and so on, creating interesting entrees for malware designers.

I'd very much enjoy a dialog on the following thought: in a centrally controlled virtualized environment, is security innovation possible?  Given that we can get better information about what is going on, for example anomolous behavior such as a processor being hit abnormally, or other anomolies such as buffer overflows or abnormal accesses or sensitive data being touched in any way, could we not modify the enterprise security policy on the fly?  Could we have software to look at the collective of information now at our fingertips and change security policy appropriately? 

 The model I have in mind is human behavior.  If you are walking down the street and it's daytime, and it's a cheerful sunny day, and nothing suspicious is going on, we behave in a way to maximize productivity and pleasure.  In contrast, if you're walking down the street and it's dark and late, and there are strange- looking people about, and they are looking at you with too much interest, your security posture changes and security becomes more important than productivity and pleasure (until you get out of the situation.)

So could we not use that model and have an adaptive security policy that intelligently changes, based on the information available.  Not attacks per se, as there is software that does that already.  What if we could look at the health of the network and applications and decide that situation is not normal and a more restrictive security policy is now required?  Productivty and pleasure take a back seat when it's "code red".

I'd like to hear from folks with thoughts in this area!

Several striking aspects:

• All presentations about security in a virtualized environment were mobbed.  People were pretty angry when turned away at the doors of the presentation rooms, but fire marshall regulations prevented people from standing at the back.  It appears this is the "next interesting thing" in security, and there is great curiosity.  On the reality side, there were very few products / technology for sale to address the potential issues.  I believe there are a great many startup companies currently in stealth mode in this area.
  
• The days of radical and revolutionary change in security from the late '90's and early '00's are way over.   The big vendors seem to be just pulling together "fix it all" suites as best they can through acquisitions.
  
• Michael Chertoff's presentation was a tad scary: he mentioned that government agency computers are all interconnected, and that security is not consistent across all agencies (some have 24/7 monitoring for security and some don't).  This is bad for the obvious reason - just like in the movies, the bad guys can find an innocuous-looking, under-protected entrance and get to the agencies of interest.  The other scary part was that Mr. Chertoff seemed to think 24/7 monitoring was the main thing.  I'd tend to focus on preventative measures, vulnerability assessment, intrusion detection, user training, Identity and Access Management, strong authentication and other areas as well, but they were not mentioned.
  
• Bruce Shneier's presentation on security rationalization was provocative.  He focused on the separation between reality, feelings and models by "experts" when it comes to assessing security risks.  One example was the Tylenol scare, and it was successfully addressed from a commercial standpoint by adding hermetic seals to bottles.  It made people feel better.  The reality is that a syringe could inject poison pretty easily, but people feel better.  He also introduced the notion of "security theatrics", where the media and security vendors exaggerate risks and cause people to feel bad when the reality just doesn't match.  Interesting concept.

RSA Conference is growing: attendance was estimated at 17,000

This is a little-known fact that may be very interesting for customers who want SSO, but realize Password Manager does not natively support your language.  We have an SDK available for partners to do their own translations of the CPM UI.  It is available for free, and has already been requested by partners in Russia, Czech Republic, Sweden, Italy, Greece and Poland.

This SDK can be used with standalone CPM and XenApp Platinum (Single Sign-on powered by Password Manager.)  Both offerings are the same code base.

Our terms are intentionally simple: the local Citrix rep approves the partner to me, partner signs a EULA, I give the partner access to the SDK via FTP, and the partner owns the resultant work effort (of course CPM licenses are still required for the customers purchasing translated versions from the partner.)

The caveats are that the business partner is responsible for keeping up with changes as new releases are provided from Citrix, and the local Citrix account team vouches for the integrity of the partner.  We need to be sure the UI delivered is of quality, hence the local team involvement.

If you're interested, please have your Citrix rep contact kate.brew@citrix.com

 Would also appreciate comments on this approach - yea or nay!

Most people don't realize the value of the answers to their personal security questions (Citrix Password Manager calls this Question Based Authentication.)  As it turns out, those answers are more valuable than passwords.  If someone learns enough answers to your personal security questions, they very often can reset your password and have access to your accounts.  Yes, that includes your online bank account and it's a very real problem.  In fact, I have a friend so paranoid about this that he swears his favorite color is "three."

 Some of the issues around personal security questions are kind of interesting.  For example, I've dealt with customers where personal privacy of employees is a big consideration in selecting the questions.  Let's call that one "sensitivity".  Another issue is what I'll call "changeability" - your favorite movie may change from month to month.  Then another issue is what I'll call "detectability" - my place of birth is public record, if somebody happens to know where I was born and what my maiden name was.  Both of those are completely unguessable in my case so I am probably safe on that problem. 

 Then there is always my favorite, "guessability" - there are only so many colors, even if you count teal and puce.

We can't forget the punctuation marks either.  Tricky to remember whether I indicated a teacher's name as Mrs. Winters, Ms. Winters, Mrs Winters or Ms Winters when I signed up for a web account.  Have to be careful on that one.

 We are finding that the more flexibility you can allow the better on these personal security questions for CPM.  Let companies write their own personal security questions that are more obscure than place of birth.  Let people choose between a number of security questions that they find unique and easy to remember.

In fact, I'd love some comments on pet peeves and helpfuls suggestions on personal security questions!

I've been talking to a customer in the midst of a large rollout of Citrix Password Manager and heard some interesting items.  This is a very positive Citrix customer, but they don't want users aware of CPM. 

 Now, being software developers, we just assumed everyone would want to be aware of our cool SSO application.  But this customer, and apparently others, want their SSO solution to be transparent to users.

Why?  They have high turnover and their end users are unsophisticated from an IT perspective.  Their users have limited patience and get frustrated if they feel like they are getting slowed down.  So, even though CPM is saving them time and increasing security, the IT folks want CPM to be "invisible" so that users don't get the wrong perception (i.e., while CPM is launching they get irritated.)

We've already made some changes to the product to address this, but this customer experience convinces me we need to do more.

Another tidbit: training their new workers to use SSO is more easier than training established employees who already have bad habits like writing down their passwords, guessing a good bit, and getting locked out a good bit. 

Without Single Sign-On, users are left to their own devices (such as yellow stickies) to retain the many different passwords they need.

Trouble was that security vendors were so eager to provide this functionality (starting about 10-12 years ago), and the hype was so great, and the technology was so immature, that early SSO projects often had tragic results.  Early implementers in some cases dumped millions in services dollars to coax the immature SSO product into actually working for a subset of their applications.

 Well, the technology is mature now, and SSO really works!

With the Citrix SSO product, Citrix Password Manager (CPM), we have a very successful install base of customers, with many implementations with more than 50,000 users.   Very conveniently, CPM is included as the SSO XenApp Platinum component, bringing more value to users as well as value to IT administrators in increasing actual security by eliminating bad user behavior.

At Summit in January I ran into an interesting Citrix partner - Xceedium.  It's a security company with an appliance product, called GateKeeper, that is complementary to XenApp.  It enforces security policy by providing compartmentalization and containment.

Say you are outsourcing development.  The GateKeeper provides capability they call "LeapFrog Prevention" to isolate and contain users to authorized applications and network devices.  So your outsourced developers can't do DNS look up, NFS mount, ICMP to LeapFrog to unauthorized areas and information.  It also provides tracking and reporting for compliance reasons. 

In a XenApp environment, their agent monitors each user process and prevents unauthorized apps from trying to leapfrog to another device.  They also provide tracking for all CLI and prevent unauthorized CLI, so it adds to the security features of XenApp at the application layer with control over the command line/infrastructure layer.

The GateKeeper is complementary to the SmartAuditor session recording feature of XenApp, adding keystroke logging and session recording for CLI.

For customers who have audit and compliance requirements, Xceedium is an extremely interesting addition to XenApp.  They're already verified Citrix Ready too.  As a bonus, Gatekeeper is Common Criteria certified to EAL3.

[www.xceedium.com]

I just got a really nice note from a Citrix rep in Australia abut the "Cookbook" available for Citrix Password Manager.  He suggested we have similar tools for all Citrix products for our partners to use.

The CPM Cookbook, AKA Citrix Password Manager Project Guide, has been on MyCitrix for a while, but I am noticing people usually can't find it.  It contains information on sizing services revenue, developing scope of product deployment, justifying ROI, writing the Statement of Work, creating the project plan and documents and templates for training and other useful tasks.

It is located here on MyCitrix, under reference desk for CPM, under Whitepapers Exclusively for MyCitrix Users: https://www.citrix.com/English/myCitrix/refDeskResults.asp?Category=product&ResourceId=7181

If you have any problem getting it, I'd be happy to send you a zipped copy.  Please contact me at kate.brew@citrix.com