It's that time again

It's been three years, so the Security+ ce is up for renewal again.
Just like last time, I got 40 of 50 credits from training activity and will fulfill the rest with relevant blog posts here. This turned out to be really simple and kind of fun too.

Credit Card Authentication

As news continues to trickle out about the Target breach (and allegedly 6 other merchants, including Neiman Marcus), I continue to wonder why the credit card companies have not taken steps to provide more security at the point of purchase. Perhaps their cost of dealing with compromised cards is less than the cost of rolling out a whole new mechanism that would likely involve new cards, new POS terminals, training everyone involved, etc? Personally, I am hoping that the magnitude of these most recent incidents will serve as leverage to make such changes.

Regardless of why it has not been done, I wanted to understand more about the current security mechanisms. When I make a credit card purchase in person, I swipe my card in the POS terminal and then possibly sign the transaction receipt (either on paper or digitally on the POS terminal screen, if it has one). That's it. Rarely am I asked to present a photo ID. And in the last few years, some merchants have stopped requiring the receipt signature if the purchase total is less than some amount. The amount seems to vary, but the limit is typically between $25 and $40. Also consider purchases made at automated kiosks including most gas pumps, where you do not have to sign at all.

So if someone could steal my card (or clone it using information stolen electronically), they would likely be able to make purchases with it. Especially if they know which stores typically do not ask for additional proof of identification and/or make small purchases and do not get greedy with it. The mechanisms of photo ID and receipt signature are pretty weak. The probability of the clerk knowing you personally is very small. And the clerk is unlikely to have been professionally trained at spotting fake IDs or handwriting analysis. So comparing the signature on the credit card with the receipt and/or ID is not going to get a lot of scrutiny. Also, the merchant will err on the side of making profit and permit most purchases by default. A merchants public image would be damaged if they became know for turning down valid transactions (i.e. false positives). And the merchant is not liable for the fraud. Neither are you. Federal law limits your liability to $50 and that is typically waived by the major credit card vendors.

Even if these mechanisms were not so weak, is the merchant required to implement them? The answer varies with card type and the policies have changed over time. An internet search turns up several articles exploring this same question, but they are all several years old with outdated or broken links to the credit card merchant sites. So I did a fresh search as of January 2014.

All of the big four vendors require the signature check for in-person purchases, but what about requesting photo ID?
Visa (page 431) says no.
Mastercard (page 3-2, #7) says yes.
American Express (page 22, section 4.4) says no.
I could not locate the Discover manual, only a fraud FAQ.
It looks like you may need to be a registered merchant to access their documents.
the FAQ suggests that refusal of showing photo ID is "suspicious", but does not mention any policy of asking to see it.

I don't have a Mastercard, but have used some of the others and can count on my two hands how many times in over twenty years that I've been asked to show my photo ID.

There is an interesting meme floating around that says you can "sign" your credit card with the statement "See ID". The idea is that the merchant would then be forced to ask for your photo ID. This has been debunked. Not using your actual signature means the card is technically invalid. This may actually work for you if the clerk agrees with the meme, but it has no legal validity.

What about the PIN or the CVV2 code on the back of the card? Yes, credit cards have a PIN. When you first got your card, there was a separate envelope mailed to you from a different, seemingly unrelated address that contained the PIN. So why are we not using that like we do for debit card transactions? The only place it is required is if you use your credit card at an ATM to get a cash advance (i.e. high-interest loan).

The CVV2 code on the back is not required for in-person purchases, but is used by a few merchants. At Best Buy, for example, they usually ask to see my card, flip it over and type the code into the cash register. So that makes it more like an online purchase where it is often (but not always) required. Of course, this does not matter if someone has acquired your physical card. Then they have that number too.

In my opinion, it is only a matter of time now before we see some new payment processing infrastructure rolled out en masse. It will likely be EMV (chip and PIN), i.e. smart cards that can do some cryptographic calculations all by themselves. Powered by the POS terminal, they would be given transaction session information and only emit encrypted packets back through the merchant's system to the payment processor. This is analogous to the Secure Shell protocol where public/private keys are used to securely exchange the session key and all traffic is encrypted the entire time. And in order for a thief to clone your card, they would need to compromise all the way into the card itself to extract your keys. If they steal your physical card, then they have to crack your PIN and these cards can be configured to lock themselves down after so many incorrect attempts. I have no doubt that someone can engineer a way around all that, but at what expense? Just like the merchants and credit card vendors, the thieves also have to balance the cost vs reward ratio. If it costs them more time and effort than they get out of it, then it is not worth the time to crack your card. These guys are just as business savvy as anyone else, they just choose to do things that are considered illegal.

This post maps to CompTIA SY0-301 exam objectives 2.1 and 5.2.

Content Filtering and Analysis

I work in a "high-security" facility and we have all manner of policies and rules to follow to be considered worthy of a simple Internet connection at our workstations. Our facility is just one building on a much larger campus and all the network traffic to the outside world goes through a single gateway. As part of their security apparatus, they have set up an HTTPS proxy at this gateway. The proxy allows them to break open every HTTPS connection with a deliberate man-in-the-middle (MITM) "attack" for the purpose of analyzing it to make sure it's "OK" by their definition. On top of this, they also subscribe to a content analysis/filter service that categorizes various sites and pigeon-holes them into one or more labels. Then certain labeled categories are denied as a whole.

Both of these mechanism introduce some rather severe usability issues. In several previous posts on this blog, I have brought up the subject of usability. In my experience, usability is about the last thing that security folks consider. It really ought to be part of the availability side of the security triangle. If something becomes too difficult or impossible to use, but it is a legitimate need, then it has become unavailable. Then users are tempted to seek workarounds or "other means" of getting to their resources. Security FAIL.

Let's look at some specific issues.

The MITM HTTPS proxy wreaks all kinds of havoc. It causes a noticeable increase in download speed for the extra time it takes to establish a second HTTPS connection with whomever you actually intended to reach. Remember this one system is doing this for every connection on the entire campus which is several tens of thousands of systems. I sometimes download software via  svn or git servers. Wireshark is a good example. This is a fairly lengthy operation, much larger than a typical single web page. It often breaks down in mid-download for no apparent reason. If I download it from outside the facility (e.g. at home) it works fine every time.

The content analysis/filter frequently prevents access to legitimate resources for the wrong reasons. The facility subscribes to a third-party filter service. They just get a regular filter definition update and install it. Job done as far as they're concerned. Unfortunately, the granularity of the filter is pretty big and lots of sites get lumped into a general category of "bad" with no further distinction made. A great example is a site being declared a "blogging site". That is way too broad. We are doing software engineering and solving a lot of technical problems about Linux, C++, etc. Many times, a web search will turn up someone talking about the exact, specific issue that we are having, but... the discussion is on a "blog" site (<gasp>). So you end up emailing the URL to yourself at home and looking it up from there later. Progress is delayed. Part of our application makes use of OpenGL doing all kinds of fancy graphics stuff. A lot of discussion about those types of issues is found on gaming development forums, but they're all blocked because they are lumped into the "gaming site" category. Shame on you, programmer, for looking at gaming sites instead of working!

I have also encountered sites that are blocked for seemingly no logical reason. A good example is http://libssh.org. When I got denied access to that one day, I decided to try challenging it and requesting an exception. I explained what it was, why I wanted access and how it was not in any way qualified to be in the "known spammers" category. After escalating it to the "tier 2" guy, I was told that yes, that site was OK, but unfortunately the IP of its hosting service was in a range of addresses that host known spammers. So the entire range of addresses was just blocked wholesale. And since they just subscribe to this third-party list and it had the range listed, they could not or would not make any change for it. So once again, I download it at home later.

So how could this situation be improved? If I were in charge of the whole thing, I would have a few folks appointed to be the local point of good judgement and discretion. They would be tasked with evaluating all requests for exceptions and making local tweaks to the content filter definition. I think a subscription-based service is fine as the starting point, but if you just accept that as-is, you will end up hurting the usability for your particular, local users. And that reduces availability which can hurt security more than it helps sometimes.

This post maps to CompTIA SY0-301 exam objectives 1.1 and 2.8.

Public key authentication with libssh

Continuing my previous post about libssh, the next question was how to handle authentication.
The library (version 0.6.0) allows for several methods, including passwords, public keys, keyboard interactive and GSSAPI. For my use case, I knew passwords were right out because once the shared key was passed around, it would be worthless with no way to control access. I didn't like the sound of keyboard interactive and don't know a thing about GSSAPI. I've been using public key authentication with ssh for many years, so that seemed like a good choice.

Once a session has been established and keys exchanged, you are ready to accept the authentication.
Set your public key authorization callback in the server callbacks struct.

   struct ssh_server_callbacks_struct cb = {   
      .auth_pubkey_function = auth_pubkey
   };

Tell it that you only want public key authentication. It will automatically deny all attempts to use passwords and other methods for you.

  ssh_set_auth_methods(session,SSH_AUTH_METHOD_PUBLICKEY);

Create the event loop that will take care of all the I/O for you and simply invoke your authentication callback at the appropriate time to let you decide what the answer will be.

    mainloop = ssh_event_new();
    ssh_event_add_session(mainloop, session);

    while (!(authenticated && chan != NULL)){
        if(error)
            break;
        r = ssh_event_dopoll(mainloop, -1);
    }

The public key authentication callback looks like this. You are given a pointer to the session, any username that was used, a pointer to the public key that was offered, the key's signature state and your own application user data (if any).

   int auth_pubkey( ssh_session session,
                               const char *user,
                               struct ssh_key_struct *pubkey,
                               char signature_state,
                               void *userdata );

So what do we do with all this? I had a brief moment of initial confusion about being handed a public key instead of a private key. Well duh, you don't ever send the private key anywhere or it would not remain private for long, would it? Referring to RFC 4252 - The Secure Shell (SSH) Authentication Protocol, section 7, we see what's going on. Back on the client side, the SSH client uses your private key to sign a copy of your public key. Then the public key and signature get sent to the server and show up in this callback. Actually, the library has already evaluated the validity of the signature and simply gives you the signature_state enumerated value. You need the whole public key, however, because you're likely going to compare that to one or more public keys already installed on the server side to see if this one is a match. Using OpenSSH, for example, you would have your public key installed on the server side in the $HOME/.ssh/authorized_keys2 file. The server sees you attempting a login as user 'fred' and compares the public key offered from the client side to all the keys in user fred's authorized_keys2 file. If the signature is valid and there is a match, you're in. If not, then you are rejected.

In my use case, there is no relevant username because we're not logging into a system. So I just ignore that value. It can even be omitted on the client side. I chose to simply have a directory within my application's data area that is the designated location for authorized public keys. This is equivalent to the authorized_keys2 file. There is little difference between keeping them all in one file or having separate files in one directory. So my auth_pubkey function logic looks like this (error-checking elided for clarity).

   if ( signature_state == SSH_PUBLICKEY_STATE_NONE )
      return SSH_AUTH_PARTIAL;

   if ( signature_state != SSH_PUBLICKEY_STATE_VALID )
      return SSH_AUTH_DENIED;

   // valid signature received
   // loop through the keys directory, for each key file 'f'
   ssh_key k;
   ssh_pki_import_pubkey_file( f, &k );
   int result = ssh_key_cmp( k, pubkey, SSH_KEY_CMP_PUBLIC );
   ssh_key_free(k);
   if ( result == 0 )
      authenticated = true; // to exit the event polling loop
      return SSH_AUTH_SUCCESS;

  // if no matches
  return SSH_AUTH_DENIED;

This works but leaves me with one open question. Why does it get called twice? Once with a signature state of NONE and then again with VALID after the client has given the private key passphrase. In fact, if you don't return PARTIAL in response to NONE, then the client side never prompts for the passphrase at all. With this logic, the client side (at least OpenSSH) shows an extra line of verbose output stating "Authenticated with partial success". That's harmless but I will continue to investigate and see if I can clean that up.

Note that there are two mechanisms at work here to denote that authentication is complete. You return SUCCESS/PARTIAL/DENIED for the sake of the library logic that is taking care of so many things for you. You also set the 'authenticated' boolean to true to break out of the application-managed event loop. Are these two controls redundant? Not at all. Suppose you wanted to be extra secure and use multiple authentication mechanisms. They all get processed off this one loop with all the respective method callbacks firing. Each one of them is telling the library if that particular method is successful or not. Then you still need something like the authenticated boolean to reflect your application's overall success state, i.e. once all the methods have succeeded.

It does not get much easier than this. Many thanks to the authors of libssh for encapsulating so much of the work.

This post maps to CompTIA SY0-301 exam objective 1.4.

Embedding SSH Service

Some network appliances (routers, firewalls, etc) support a remote command-line interface. This can be a good way to provide a user interface to a device that doesn't have video and isn't connected to any peripheral. It's just there on the network. Traditionally, this interface uses the TELNET protocol. The origin of this feature predates SSH and HTTP. Most newer items tend to use an HTTP-based interface where you just point your web browser to it. Some devices may have SSH instead or in addition to the TELNET option for better security.

I work with a proprietary application that runs like a system service and has no user interface. However, there are a number of performance-related parameters and status values that are useful to inspect and possibly modify at run-time to perform diagnostics or help create particular test conditions. In this applications environment, low-security interfaces are, shall we say, frowned upon. And we did not have the resources to implement a full-blown HTML interface using HTTPS or anything like that. So recalling the simple TELNET command-line interfaces that some devices use, I thought that would make a good option.

The first version made use of a very handy library called Libcli created by David Parrish. This library is easily included with your application and takes care of setting up the socket and handling the whole TELNET part. You register as many different commands as you want, each mapping to a callback function that you provide. The library takes care of parsing the user input and invoking the registered callback. From the callback you can do whatever you want and print output that goes back to the client side for display.

That was great until the security folks said, "hey, you can't run a TELNET service". They were not willing to draw a distinction between a TELNET service allowing a user login to the system and an application allowing access to some diagnostic information. Their network scanner just saw "something" respond positively to a TELNET request. Compliance check failed. End of story.

So we had to disable it in deployed configurations and can only use it in the test lab. So my next logical thought was using SSH instead of TELNET for the authentication and transport but still let Libcli handle all the command processing after that. I didn't want to have to reverse-engineer the OpenSSH code to pull out what I needed. Had anyone written a library that made implementing the SSH protocol simple for embedding in other applications? Of course they have. I'm not the first person to think of any of this.

I found two obvious candidates, libssh and libssh2. So which one should I try first? The libssh2 folks already did my homework for me with this comparison chart of their library vs libssh. This made the decision very quick because libssh2 does not have server-side functionality, where libssh does. Done.

libssh takes care of almost every necessary SSH function for you. It sets up the socket, listens for connections, handles authentication (using host keys you provide), lets you set up a pty and open a secure channel. After that, you have a secure "pipe" to read/write data, whatever that data might be. That part is your business.

So the next question was how to meld the two libraries together? I wanted to use libssh to do all the SSH part but still let Libcli handle all the command processing over the secure channel. In order to read/write the secure channel you use the ssh_channel_read() and ssh_channel_write() functions. Other than the channel parameter, you just give them a pointer to your buffer and length and its just like a plain read()/write() as far as you're concerned. Now in Libcli, once you set up all your commands, you normally just call the cli_loop() function. But in this use-case, we cannot do that because cli_loop() encapsulates too much stuff we don't want. It handles accepting socket connections, all the TELNET stuff and then executing the appropriate callback function. We just need to parse the command and invoke the callback. Most of that is encapsulated in cli_run_command().

So that just leaves our code with the duty of processing the raw user input from the secure channel and assembling a line (until 'enter') and passing it to cli_run_command(). But how will output from the callback functions get back to the client side? All output from Libcli callback functions is done by calling cli_print(). Since that's part of the library, it has direct access to the file descriptor of the socket and sends your output back to the client for you. But in our case, we have to call ssh_channel_write(). Fortunately, Libcli has foreseen this type of situation and provided cli_print_callback() which, if set, will be invoked from cli_print() instead of trying to write to the internal file descriptor (which is NULL because we didn't use cli_loop() to accept a connection). So the command callback invokes the print function which calls my callback with the output text. Perfect. My print callback just passes the buffer on to ssh_channel_write().

So that's it in a nutshell.  As my initial proof-of-concept demonstration, I simply modified one of the examples provided with libssh. Note that this uses the release candidate version 0.6.0 of libssh. The current stable release (0.5.5) does not have as many examples of SSH server code.

sshcli.c

A single, trivial command of "show stuff" is set up with Libcli and then the rest of the modification is in the do loop that reads from the channel. To build it, just compile with gcc and link with both Libcli and libssh.

gcc sshcli.c -o sshcli -lcli -lssh

To run it, you'll need to provide SSH host keys. I just copied the ones on my system. Also specify which port to listen on. The default port 22 is taken by your system's sshd service, of course. Your application will be listening on something else.

sshcli -d host_dsa_key -r host_rsa_key -p 2000 127.0.0.1

Then from another shell, just connect with ssh. The example program uses password authentication with username "user" and password "password".

ssh -p 2000 user@127.0.0.1

After authenticating, you'll get the welcome banner and the prompt. Note that I had to implement those too because they are normally taken care of by cli_loop(). Then start typing commands. Done.

This post maps to CompTIA SY0-301 exam objective 1.4.

Payment Card Security

The recent breach of payment card data from US Target stores piqued my curiosity about exactly how credit and debit card security works. Many of us use these cards nearly every day if not several times per day to pay for goods and services both in person and online. Yet how many people understand the security of these instruments that permit access to our financial resources?

There are two basic types of payment cards, credit and debit. Both of them serve as your identification and means of authentication for authorizing a transaction between you and a merchant. The cards all conform to the ISO/IEC 7813 standard. For identification, they have your name and account number both printed and encoded on the magnetic stripe. There are several mechanisms that provide authentication. Which one(s) gets used depends on which type of card it is and how you are using it. You can use the cards in person at a point-of-sale (POS) terminal or you can make an online/telephone/mail-order (i.e. "card not present") transaction.

If you are physically at the merchant's checkout register, the card is "what you have". If it is a debit card, then the PIN is "what you know" and you have two-factor authentication. If it is a credit card, the merchant should verify your identity against a government-issued photo ID (e.g. driver's license) and also compare the signature on your credit card to the one on your receipt or the digital signing pad. I think of this as a crude quasi-biometric that weakly qualifies as "what you are". (That's probably another post to rip that idea apart.) So in practice, credit cards are effectively one-factor authentication.

Interestingly, most credit cards have a PIN number too, but that's only used for ATM cash advances. I think most people use a debit card at the ATM, so it's kind of useless. You'd think they would have required that at POS terminals for two-factor authentication, yes? Credit cards have been around far longer than debit cards. I suspect the PIN came later and now it's too expensive to mandate an update to the entire infrastructure (e.g. IPv6 upgrade). Also, federal law limits your fraud liability to $50 and the big companies (Visa, etc) waive that to $0. I'm guessing with their massive resources, it's cheaper to take the chance and maintain good relations with the customers, i.e. a calculated risk.

If you are making a "card not present" purchase, then a merchant should require you to provide the CVV2 code (the 3 or 4 digit code on the back of the card). This code can be used in the transaction with the payment processor to verify that the card number given is legitimate. This replaces the use of the CVV1 code which is only encoded on the magnetic stripe which is not used in this case. Since all the data provided is on the card, this is one-factor authentication. Some merchants still do not require the CVV2 code. I guess they're just passing the buck to financial institution if the transaction turns out to be fraudulent.

No matter which type of card and transaction you're doing, the steps are fundamentally the same. You provide the card (or its data) to the merchant. They communicate this data along with the proposed amount of the transaction to their payment processor for authorization. Most of the card-issuing institutions do not deal with this directly, but farm it out to third parties who have the ability to authorize the transaction to occur between the merchant and your account. There are many institutions, processors and merchants that all have to work together seamlessly in order to provide you with a consistent purchasing mechanism. In regards to security, the Payment Card Industry (PCI) Security Standards Council formed in 2006 to provide security requirements and best practices for all these participants. They offer the Data Security Standard (version 3.0 as of Nov 2013) that provides a framework of security requirements, testing procedures and implementation guidance for all aspects of payment card processing.

We don't have any technical details from the Target breach (and we probably won't), but we can learn a few things from their public relations handling. They have a web page dedicated to the issue including an FAQ. According to the FAQ, they found some type of malware on their point-of-sale systems. I take that to mean the actual swipe terminals or the interface between them and the payment processor. There was some initial confusion about "CVV information" being acquired. This is a terminology nightmare. Read something like this Wikipedia entry and then tell me what they're talking about. I believe what was acquired was the CVV1 code which is on the magnetic stripe. The CVV2 code is not on the stripe, only physically printed on the back of the card. There is no way to capture that electronically (unless you want to talk about cameras planted under the POS terminal). The CVV1 code cannot be used for fraudulent online purchases, but it can be used to reconstruct a clone of your card for fraudulent in-person purchases.

There was also concern over captured PIN data from debit cards. Target later confirmed that the encrypted PIN data was also acquired. Your PIN gets encrypted right in the keypad terminal and has to be transmitted to the payment processor. Also PCI DSS requirement 3.2.3 says that PIN data (encrypted or not) should never be stored. In fact, there is an entire separate document all about PIN Security Requirements. However, it has to reside in some memory buffer long enough to get transmitted from the POS terminal to the processor. That's probably where it got captured. The data is encrypted with Triple-DES which was the precursor recommendation for "strong encryption" before AES was published. The Target FAQ says that the decryption key is only possessed by the payment processor and has never been on any Target system ever. This implies PKI and Target only has the payment processor's public key. So this is as well protected as anything encrypted with Triple-DES. Unless the NSA was behind this, I doubt the thieves can do much with that. Nor do they need to because you can opt to use a debit card but pay as a credit transaction which does not require PIN entry.

And now we're back to my earlier question about why credit cards do not require PIN use. How many more large-scale incidents like this will it take before we bite the bullet and introduce credit card PINs? Perhaps we use the European-style "chip and PIN" smart-cards? This enhances security because the PIN is only used as an input to the chip on the card to unlock access to your encryption keys that then protect the interaction between card and terminal. That's a lot smaller window of opportunity for PIN capture.

Definitely a story to keep following as it develops due to its large scale and high visibility. This is another great example of the tradeoff between security and usability. Do we keep things simple like they are and avoid a potentially high-cost upgrade of the infrastructure? That will result in more breaches, more bad public relations, etc. Or do we pay a relatively one-time cost and go for a more secure solution? Also consider that some due care should be expected on the part of the customer. We should learn to keep an eye on our accounts. Most institutions will offer to send you emails or text message alerts if anything suspicious happens. Since this is all about money, the answer comes down to money as well. Whichever path is deemed to have the lesser overall cost will win.

This post maps to CompTIA SY0-301 exam objectives 2.1, 2.5 and 5.2.

Certificate Revocation Checks

Another usability issue that I have to deal with on a daily basis is the clash between enforced security policies and unavailable security services. Where I work, we use smart-cards that contain identity and email certificates. We are required to use them to access email using Microsoft Outlook. They serve as our two-factor authentication for accessing the account (you must have the card and know the PIN). This is a full-blown Outlook installation, so we have a central server that stores everyone's public keys so we can encrypt messages to one another and/or digitally sign them. The public keys are used by others to verify our digitally signatures and/or decrypt messages.

The cards are issued by another centralized authority so if you look at your certificates, you can see the chain of signatures going up to the root certificate authority (CA). The root CA certificates and all the intermediate certificates are installed and updated on everyone's system as part of a common enterprise-managed infrastructure (Windows 7 Enterprise).

Certificates can be revoked for a number of reasons (expiration, terminated employees, etc).  This includes both individual certificates and any certificate up the chain including the root CA potentially. So any time you receive a signed email, the signature must be verified by making sure it traces back to a root CA and has not been revoked. So where do we keep track of the certificate revocation list (CRL)? That's on yet another centralized repository somewhere and we use a program called Axway Desktop Validator that queries this repository to see if any certificates in the chain being verified have been revoked, which would invalidate everything from the point of revocation on down.

Our managed system policy enforces a number of behaviors that cannot be changed by normal, non-administrative users. The use and configuration of Axway being one of these. It integrates with Outlook so you rarely, if ever, see any visible signs of its existence. However, we certainly feel its effects because it rarely works well. The Axway program has a plethora of configuration options, many of them pertaining to timeouts for how long to keep revocation data and what to do in various circumstances and error cases. We seem to hit these cases frequently.

Whether the program and the service are simply latent in response or completely down, the local effect is that Outlook hangs until the operation is complete or times out, which can be on the order of 30 seconds. This falls into what I call the "piss-off" zone. It's long enough to disrupt your mental workflow and initiate frustration, but too short for you to go do something else and come back later. And often, the emails that use digital signatures are "official" messages from various authorities (facilities, security, IT, administration) that you really should read, so there's no avoiding it.

This whole certificate business is all about protecting integrity and providing non-repudiation, but these policy vs implementation clashes result in reduced availability. In my experience, availability always gets the short end of the stick over every other security aspect. I suspect it is because most people think of availability as simply a system being online or not regardless of performance and the cumulative impact that can have. The downstream consequences of poor performance can get multiplied exponentially.

Our technical support just shrugs their shoulders and says they can't do anything about the performance. They've deployed it as required. The security folks just shrug their shoulders and say "it's policy, you have to use it", whether it actually works well or not. So it becomes a classic case of the two entities that could do something about it just pointing the finger at each other and doing nothing. Neither one cares because they have each met their specific requirement.
A true improvement in the overall security of an organization would have someone appointed with both the responsibility and authority to look at these combined effects and do something about it. Perhaps the "Chief Usability Officer (CUO)". I'd like that job... :)

This post maps to CompTIA SY0-301 exam objectives 6.3 and 6.4.