It’s important to know, I didn’t have any existing documentation to work with. There was a wiki which had the developers’ notes in it, but that’s it. Nothing by way of formal hand-it-to-an-outside-entity documentation.

Okay, that’s not too abnormal; tech writing is expensive, and many companies don’t bother with it until an auditor is breathing down their neck. Hardly ideal, but to be expected, and I did have time. So, I set to it.

Since there wasn’t any existing documentation to re-do, I based my organization around the expectations set by the certification. And, a good week before the deadline, I turned in the completed documentation, all 100-something pages of it.

And that’s when disaster struck. The auditors decided they wanted the documentation in a completely different format – they weren’t going to read our documentation, no. They wanted us to fill out a questionnaire. The questionnaire was very comprehensive, encompassing exactly as much material as my documentation covered. And I had less than a week to complete it. I told my boss “No problem.” And I gave him the completed questionnaire in 3 days.

How? How could I turn an entire manual into a completed questionnaire in 3 days? If you’re thinking “An awful lot of copy and paste” you’re on the right track, but you haven’t fired up the engine yet.

Before I started the project, I had sought and gained permission to try something different. I decided to try Topic-Based Authoring. With topic-based authoring, rather than create complete documents I create small topic “nuggets” (I prefer to think of them as Lego bricks, but the technical term is modules) which consist of one or two standalone paragraphs on a single topic. I acquired some inexpensive software that integrated between Word and SharePoint, and after loading my nuggets into SharePoint I could assemble them in any form I desired, leaving me basically to write the introduction and conclusion to a given document and select what information should be included. Since I had determined what nuggets I would write based on the certification requirements, I knew I already had all the information they needed. So all I had to do was insert them into the questionnaire, check to make sure the formatting was correct and that each question was fully answered – or if not, edit the nugget in the database NOT in the document itself – and sing the praises of topic-based authoring.

Needless to say, I love topic-based authoring. It’s not just about being able to restructure documents quickly. It’s also about being able to rapidly change information. While I was working on the documentation, development was still ongoing. I was able to change single nuggets of information to reflect changes in the system, rather than going in and changing each document. And because I wasn’t sitting and staring at a given document for days or weeks, it reduced burnout. As an added bonus, I was even able to get some of the subject matter experts (SMEs, e.g. developers and system administrators) to write up about specific components, saving time and effort.

Topic-based authoring can be hard to implement. It’s not for everyone: the software can be expensive, the cost of changing documentation methods can be immense, and reusability may be very low. But whatever your documentation method is, you should think about being able to do what I did. Your documentation should always offer the following:

It should be accurate. I can’t say how many times I’ve found outdated documentation that simply doesn’t reflect current systems or processes. As an auditor, that tells me the documentation isn’t maintained, and that means I can’t trust any of it. That means my work will take longer, and ultimately that will cost you money.

It should be flexible. You never know when you’ll need to change formats, add data, or meet some other unexpected demand. A company’s ability to meet new demands is one of its most important skills.

It should be fast. “I’ll get back to you in a month” hasn’t been an acceptable answer since the 80s. No matter what it is, you’re going to have to generate new documentation at a pace that would have been considered simply impossible, regardless of resources, before modern computing.

It should be consistent. All of your documentation should reflect the same information. Anything less will reduce confidence and engender confusion. And that’s never a good thing, no matter who reads it.

Good documentation practices are life and death to any company. It’s always tempting to wait until you need documentation before hiring a tech writer. Let me resolve that quandary: you need good documentation Right Now. Because if you wait until you realize you need it, it could well be too late.

To enable the administration of your various virtual machines, storage, clusters, datacenters, and the like, you can now use the vSphere 5 Web Client. Before it can be used, it must be authorized; the best instructions I found for this are here. Follow the steps in the “Authorizing the vSphere Web Client (Server)” section. This is a one-time configuration necessary to enable the vSphere Web Client.

Once authenticated, you will see something that looks very similar to the Windows-based vSphere Client running in your browser.

This will satisfy most of your management needs, but it leaves out an all-important capability; the ability to remotely view the console of the systems. There’s a Console button, but it won’t work on a Mac. Once you’ve installed a machine, you can typically enable some sort of remote desktop capability in the operating system, but what do you do before then? If you’re running Windows, you use the vSphere client and open a console, but on a Mac, you’re out of luck. Right? Wrong.

There is an under-documented feature of vSphere that allows the capability of opening up VNC connections from the host directly to the console of the virtual machine. To perform this, we first have to enable incoming connections to your vSphere server, as vSphere 5 has an integrated firewall. This is the one step you will actually need to use the Windows vSphere Client; everything else can be done using the Web Client. This step needs to be executed once for each vSphere or ESXi host running virtual machines you want to access using VNC.

In the Windows vSphere client, choose the host you wish to enable VNC connections on. Choose the Configuration tab and on the left choose Security Profile. On the right, next to Firewall click Properties… As VMWare does not include VNC as a protocol, it is not listed as an available option. However the ports allowed by the gdbserver protocol will suit our purposes. Check the box next to gdbserver. (It is also wise to highlight the gdbserver line and click the Firewall… button and lock down where you will allow these VNC connections to take place from; in ours I restricted this to our intranet.) Click OK and you’ve now enabled the incoming ports to be used for VNC.

Finally, enabling VNC access to the console machines is a matter of setting advanced configuration parameters on each virtual machine, which can only be done when the virtual machine is off. To open up the advanced configuration:

• In the Windows vSphere client, choose the machine, click Edit Settings…, click the Options tab, choose Advanced->General on the left, and click Configuration Parameters… on the right.
• In the Web client, choose the machine, click Edit Settings… under the VM Hardware section, click VM Options, click Advanced, and click Edit Configuration….

In both cases, you now want to add three rows by clicking the Add Row button.

Once you’ve added these rows and click OK, you can now use a VNC client to connect to the console of the machine. Power up the machine, and then using Finder on the Mac, choose Go->Connect to Server (or hit Command-K), and type the following:

vnc://<ip or name of esxi host>:<port chosen in configuration settings>/

and click Connect. You will be prompted for your password, and depending on your client/version of OSX you may receive a warning about how keystroke encryption is not enabled. Accept the warning, and you will see the console of the virtual machine! (And note, since Macs don’t already use the three-finger salute, you can safely just press Ctrl-Alt-Del in that VNC-window to log into Windows systems!)

Once you’ve installed the operating system of choice, and enabled that OS’ remote desktop capability, you may want to disable this VNC access. Just shut down the VM, go back into the advanced options and change the RemoteDisplay.vnc.enabled setting to false.

Hopefully at some point soon, VMWare will enable a true web-based console application (which doesn’t require host-specific plugins to be installed) to go with their nice new web client. Until then, this is a reasonable workaround for accessing virtual machines using a Mac.

I have a 250 GB SSD drive – not exactly the biggest drive – and I have 11GB of that left. I wasn’t able to upgrade my machine to the new FileVault – until I moved the majority of my data to another computer and practically wiped my drive. I’m sure I’m not the only one in this situation – and generally, backups are not encrypted – Time Machine under Snow Leopard wasn’t, and most other backup options for home use are not either. So you have sensitive data backed up off an encrypted drive, just to “upgrade” to a different disk encryption technology. If I hadn’t upgraded, it wouldn’t have been a problem. If I was content to just leave $HOME encrypted, it wouldn’t have been a problem. But I wanted “bleeding edge”. Luckily, I have an iMac at work to off-load all of the files to – encrypted with Lion’s FileVault from the start.

One example of script-less cross-site scripting affected some high-profile MySpace users in 2007. Attackers were able to inject HTML into celebrity MySpace pages, but the service filtered out typical <script> payloads. Seemingly innocent <a> links were allowed, though, and adding a bit of CSS allowed one to create an invisible link that covered the entire page. In this case, clicking anywhere on an infected profile led to a malware download.

This attack could be one of the first prominent cases of clickjacking, though the term is usually applied to attacks that hijack clicks with malicious inline frames (iframes). Allowing <iframe> elements in user-controlled HTML opens up a range of issues more broadly known as UI redressing. For instance, an iframe that covers the entire page could render a fake login form that appears to be legitimate given the site’s address, leading to a powerful phishing attack. Frames and forms can also be used to bypass CSRF protections.

Of course, you can sometimes launch simple CSRF attacks using only images. By setting the “src” attribute of an <img> element to another page, the browser will still execute a GET request to that page when it tries to load the image. Without proper CSRF protections, such an attack may be possible without XSS to begin with. But images can also be a source of information leakage or tracking, since GET requests to a malicious server will also likely include a “Referer” header.

While most XSS payloads do capitalize on the power of JavaScript, keep in mind that a browser can load scripts from many places besides within script tags. Event attributes for other elements and certain CSS properties are just two examples of places a script could slip in. And don’t forget about the risks of browser plug-ins – Flash 0-day issues or malicious PDF files can also be sources of trouble.

Finally, an issue this week served to remind that XSS is no longer just a concern within the context of a web browser. As HTML and JavaScript become a greater part of developing apps built outside the browser, XSS may pop up on other platforms. On Monday, a security researcher with the handle superevr disclosed an XSS vulnerability in Skype for iOS. By inserting HTML into the “Full Name” of a user, one could send messages that when viewed would launch code capable of stealing the phone’s address book. And this wasn’t the first time XSS has been a problem for Skype – a vulnerability in desktop versions was found a few months ago, and XSS with shared content could lead to problems back in 2008.

Alternate labels, such as “HTML injection” or “web content injection,” have been proposed to describe cross-site scripting, but the established term is likely here to say. Still, remember that protecting against XSS does not simply mean blocking script tags, and keep in mind the power of XSS when integrating web technologies with other platforms.

While most people understand the technical side of PKI, I’ve found that the “soft”, or what I call the “political” side, is not as well understood.

Anyone can set up the technical infrastructure to become a CA – but what makes the Root CAs found in your browser special? And as a corollary, how do you get into that select list? Each company officially has their own method of determining what CAs are in their list of Trusted Roots. Mozilla clearly outlines their requirements on their wiki, and Microsoft has a program for inclusion. In general, there are a few technical requirements, and “the audit” – usually a WebTrust audit. I’ve audited CAs (not a WebTrust audit), and what you look for is compliance with the stated policies. However, the stated policies might not be the best option for a Root CA. WebTrust just requires that

“Subscriber information was properly authenticated (for the registration activities performed by ABC-CA).
The integrity of keys and certificates it manages is established and protected throughout their life cycles.” (http://www.webtrust.org/item27804.pdf)

So, what is “protected”, what’s “properly authenticated?” That’s left up to the CA to decide. As long as the CP and CPS cover what the CA is doing, how they’re doing it, and the auditor thinks it’s “protected” or “properly authenticated”, it’ll pass the audit. Generally, once the audit is passed, it’s almost trivial to get into the operating systems and browsers – just a paperwork exercise.

In the case of Diginotar, we can assume they’ve had a recent audit (not necessarily WebTrust) because they’re in Windows and Firefox (NSS), and the auditor felt that they were “secure” enough. Something went wrong though in the subscriber identity proofing process (if it even happened). The CA is just a tool, it can enforce some policies, but not all – it has no clue that the people requesting the certificate for *.google.com are not really Google – the RA function checks that then instructs the CA to issue the certificate(s). If the RA function was bypassed (intrusion into the CA), then the CA will do as it’s told and issue the certificates.

Ideally, CAs have an off-line root CA – no network connection, generally turned off, and only able to be turned on by the folks who have control of the CA. This is the Root CA that is in the operating systems and browsers. Then, that Root can revoke its sub-CA certificates, and life moves on (except for folks who now have to get a new certificate), and most people won’t even know. When an on-line root is compromised, it’s a bigger deal for everyone involved to revoke that CA – patches are issued, instructions go out on how to delete it or distrust it, etc.

Most people blindly trust the Root CAs in their browser/operating system – have you looked at the list in your OS/browser of choice? Do you know anything about these CAs or are you trusting the folks at Mozilla, Apple, and Microsoft to tell you if they’re to be trusted?

However, even an imperfect solution can be useful. This week I came across this list of 35 general mitigation strategies suggested by the Australian DSD (they’re sorta like the NSA). Many of these paint with a wide brush (patch all the things!), but some are directed at specific applications of technology and software. The approach is very proactive in targeting the most widely used components of modern attack vectors. On their website, DSD makes the claim that implementing the top 4 suggested strategies would have prevented 85% of the incidents they responded to in 2010. A bold claim (assisted by wide scopes):

1. Update and patch Adobe products, Microsoft products, and Java.
2. Update and patch your OS
3. Be stingy with administrator/superuser access
4. Whitelist your programs

I’m sure that taking these steps can eliminate much of the low hanging fruit, and doing all 35 would probably eliminate even more. But even if all 35 are not ideal for every scenario, it’s still all-around decent computer security advice. These strategies can be a great reference source when fleshing out a custom security policy for mitigating attacks. The rest of the list can be found here (pdf).

Crockford on JavaScript: The Early Years

LDAPS comes from LDAPv2 (retired in 2003) where the SSL negotiation takes place before any commands are sent from the client to the server. With a TLS connection, the connection is negotiated (non-encrypted) before any commands are sent – but the first command is StartTLS, which tells the server to renegotiate the connection, but this time, use TLS for encryption and authentication.

Despite these protocols being technically different, the general usage of the term LDAPS implies at least one of the methods.

Enabling S/MIME

There’s a setting I missed in the previous post was pointed out by a commenter. After getting iOS 5 on the device and putting your certificates on there, you need to edit your email settings. Click Settings->Mail, Contacts, Calendars->Your email account->Account->Advanced. Scroll down to the S/MIME section and turn on S/MIME. (Note that this wasn’t required in order to read S/MIME encrypted email.) Enabling S/MIME causes two new options to appear, Sign and Encrypt. Selecting these will cause your iOS device to try and sign and/or encrypt each outgoing message. Make sure you enable the Encrypt option at this point to make your iOS device attempt to encrypt outgoing messages when possible.

Immediately below the S/MIME section is a section called Certificates, which contains the certificates for which your device has private keys. You can select one of these certificates (clicking it puts a checkmark next to it) and this is the certificate that will be used to sign all outgoing messages (if you’ve turned on signing). Note: you can select certificates that are not valid for the digitalSignature key usage value. I submitted a bug report (ID 9601006) to Apple about this today.

Sending Encrypted Email With Exchange

If you are connecting to a Microsoft Exchange Outlook Web Access server, and you have an enterprise public key infrastructure that publishes encryption certificates to users’ global address list (GAL) entries, you are in luck. Sending encrypted email could not be easier.

Simply enable the account and ensure Contact syncing is being performed for the account for email and enable S/MIME (thanks, Allan). When you choose a contact, the iOS device will automatically attempt to download the recipient’s certificate from the GAL. If it considers it valid, you will see a lock icon displayed next to the “To” address like this:

If it can’t find a valid certificate for your recipient, you’ll see something more like this:

Sending Encrypted Email Without Exchange

If you are not connecting to Exchange, there will need to be a bit more manual process to get certificates on to your device. If you’ve used S/MIME at all, you’re likely familiar with the “send me a signed email so I can send you an encrypted email” dance. iOS 5 is no exception. In order to send encrypted emails to recipients you will need their certificates, and as far as I can tell the only way to make that happen (aside from using Exchange) is through an exchange of signed emails.

Once your desired recipient has sent you a signed email, if the iOS device trusts the certificate used to sign it, you will see their name in the From field appear like this:

If your device doesn’t trust them, it will look more like this:

Click the sender’s name. If they are untrusted, you will see a reason why, and have a “Trust” button available to you to choose to trust this certificate from now on. In either case, you will see a “View Certificate” button. Click it.

Click the “Install” button to install this certificate to your iOS device. Now when you reply to the sender’s email (or send them emails in the future), you will see a lock by their name indicating you will be encrypting the email to that individual.

Hopeful Future Improvements

I’d like to see some improvements. I’m filing bug reports with Apple on each of these items, and I hope others will too.

First thing would be an improvement to the signing certificate selection, enabling you to (a) not choose encryption certificates for signing, and (b) make it clear what that selection is for anyway. The certificate selection option is enabled even when you choose Encrypt, which makes the setting user interface very confusing. (On a related note, on my device I could not see a Key Usage value for any certificate by looking at its details. I have also filed this as a bug.)

The second thing would be a capability to import certificates into the device which does not require Exchange or the signed email dance. I created a configuration profile containing public certificates for every user at my company. Unfortunately, iOS Mail did not have the capability to use these certificates for sending encrypted email. In fact, iOS could not even send me an encrypted email until I first sent the device a signed email and imported it, even though my encryption certificate was on the device being used to read encrypted emails. Hopefully Apple will improve this in a future release.

Lastly, there should be a way to look in the contacts of the device to determine whether or not you have a (valid) encryption certificate for a user. If I am going to leave on a trip but I know I want to interact with a few people using encryption, I won’t know until I try to send them an email. The Address Book feature on my Mac already has this, it displays a little checkmark next to email addresses I can encrypt to.

Again, please let me know if you have any additional suggestions or feedback by entering a comment below!

During the 2011 Apple Worldwide Developer Conference keynote address, Scott Forstall indicated that iOS 5 would have support for S/MIME encrypted email. (Skip to 63:10 in the presentation.) This morning I successfully upgraded to the iOS 5 Beta and started being able to read my S/MIME encrypted email. Here is how I did it.

What you need:

-       Xcode 4.2 and iOS SDK 5 beta (requires iOS Developer Program account)

-       iOS 5 beta for your iOS device’s platform (requires iOS Developer Program account)

-       iTunes 10.5 beta (requires iOS Developer Program account)

-       iPhone Configuration Utility 3.3

-       Your S/MIME encryption and signature certificates exported in PKCS12 (.p12) format

(Note there is some discussion about not needing to pay for a developer program account to install iOS 5. I went the legitimate route.)

Click to read the whole walk-through of how I did it.

Installing iOS 5 Beta

To install the iOS 5 Beta, make sure you have a backup; this will wipe your device. I used Apple’s guide. First, install Xcode 4.2. Launch Xcode and plug in your iOS device. You should see a window similar to the following:

Click “Use for Development”. If it doesn’t automatically bring you to the device organizer, click Window->Organizer. Your device should appear there in a Summary view. Under “Software Version”, click Other Version… and then choose the .ipsw file relevant to your device. Once you see the 5.0 (9A5220p) choice under Software Version, click “Restore”. This will erase the contents of your iOS device including all pictures, music, videos, and apps. Make sure you have a backup. Allow the restore to complete. Once it is complete, Xcode will again display the “New Device Detected” dialog, and you should click “Use for Development”. To complete the installation, launch iTunes 10.5 beta and set up the device.

Once you’ve set up the device, and either synced your Mail settings or manually configured them, go ahead and try and open up an encrypted email message. Here’s one that Joey sent me:

As you might guess, going to Settings > General > Profiles doesn’t do you much good. On my system, the only profile installed was the Provisioning Profile put there via my Developer account. So, we need to create one.

Create and Install Configuration Profile

Note: If you don’t wish to deal with a configuration profile, you can also email yourself the .p12 file containing your certificate. Thanks to Oleg for the tip.

If you don’t already have it installed, install the iPhone Configuration Utility and launch it. Make sure your iOS device is plugged in.

On the left side of the iPhone Configuration Utility, click on “Configuration Profiles”. Then click the “New” button at the top.

In the general section, it would be good to give your configuration profile a name. You will definitely need to provide a unique identifier for your configuration profile, so they are not confused across devices. While you can set a number of other required configurations on the device using this tool, the important one for S/MIME is the “Credentials” configuration. On the left scroll down to “Credentials” and click it.

Click “Configure” on the right-hand side to add your encryption certificate to the device. You will be prompted with a file selection dialog where you can choose your PKCS12 file containing your encryption certificate and private key.

Once your certificate appears in the window, you can scroll down and enter the password used to protect the PKCS12 file, or not. If you enter it, you will not be prompted to enter it when inputting the certificate on the device, but there will be a copy of your password stored with the profile. I chose not to enter my password at this time.

You should repeat this process for your signing certificate as well; click the + button toward the upper right to add a second certificate. In my experience, I could not read signed and encrypted emails unless I put both my signing and encryption certificates into the profile.

To install the configuration profile on your device, click your device on the left-hand side of the window, and go to the “Configuration Profiles” tab.

You should see the profile you just created. Click “Install” and your iOS device will beep or click at you. Look at the screen and you will see:

Click the “Install” button on your iOS device. You will get a warning that it will change settings on your device, click “Install Now”. You will then be prompted to enter the password used to protect your PKCS12 file if you didn’t save it as part of the configuration profile. Enter it, click “Return” and then “Done”.

Now when I re-launch Mail I can read Joey’s message:

Hooray! I’m reading encrypted email on an iOS device!

Hopeful Future Improvements

First, there is no indication on this encrypted email that it had been encrypted. Note: See follow-up post for how to fully enable and see these UI changes, thanks to Allan for pointing this out. So, I don’t know if the sender thought it was sensitive. I think this will be changed in a future release. In the below still image I took from the keynote address, you can see a lock and the word “Secure” in the title bar of the message. Obviously it’s important that Apple provides this visual cue.

Second is of course sending encrypted and signed email. Note: Again, see follow-up post for how to fully enable S/MIME. Despite my best efforts (installing my CA as a root on the device, installing certificates for my co-workers, installing certificates for other email addresses of mine) I could not get the little lock icon to appear next to anyone’s name in the “To” field of any emails, nor could I get it to send encrypted emails.

I look forward to a future beta from Apple which has these features enabled. Stay tuned here, because once I figure them out I’ll document them.

Let me know if it worked for you, and please provide any other comments below!