Tuesday, February 23, 2016

Getting your Head around the IBM Connections ID

We had a very useful meeting with IBM last week and a lot came out of it. A lot of things from that meeting will probably hit this blog in one form or another.  One rather interesting topic for us was "users". 

Our organisation uses a "Membership structure", meaning that while the organisation itself only has a small number of "core users", we have an enormous number of "extended users" (members) who don't work directly for us but connect on a number of issues and participate in a number of groups on a very regular basis. 

It sounds like an unusual organisational structure but once you get your head around the model, you'll find that it's not only fairly common but that it's becoming more common for companies to work this way.

...and it's a great fit for IBM Connections**

**Note that when I talk about IBM Connections, I'm talking about their Connections.Cloud product, why would I talk about anything else?


Verse Users and Contacts 
One of the first things we noticed when we moved some of our test users up to verse was the absence of many of our contacts.

In IBM Notes/Domino we use two address books, one for actual employees and the other for members of other organisations. It's kind of like a central CRM (Customer Relationship Management) system.  Moving up to Verse only took our staff members lists.

The problem with that is simply that we can't lookup their details easily "on the road" because they're no longer in our cloud-based "traveler". Also, we can't email them by name from verse, and we can't easily schedule meetings. It's a big problem for us. 

There's apparently a way to fix this, it's something to do with the extended directory catalog but we're still working on it so I don't have any magic solutions there.

We've also discovered that in a half-migrated hybrid setup, non-verse (Notes) users can't see new entries in the personal calendars for Verse users. We're not sure if that's a problem with our specific setup or a general problem. 

Back to users... what was interesting from IBM was the idea that verse and connections aren't using the same "address book". For those of us coming from a Notes/Domino background, this is rather unusual.


IBM Connections Users
Unlike Verse, there are no simple "contacts" in connections, everyone is a "user" in some form. They're either full users or "guests" of full users. 

What's interesting though is that connections users are more or less unique (by email address). That's to say that an email address can only be used once in connections. A connections user logs in with their email address and a password.

The account is set up when they first use connections regardless of whether it is a guest account or a paid corporate account. If a person starts  as a guest of one company and their own company later adopts connections, the password remains the same, the account is simply "upgraded" thus preserving all of their existing "connections".

It's clever and clearly IBM is banking on the features of connections "selling" the service to their "guests"; which it largely does.

There's still one problematic area. The world of Connections US and Connections Asia-Pacific seem to be disconnected. The login is shared, so you can't add a US person to the Japanese data centre because the email address has already been used but equally, you can't engage people from different data centres in the same communities.

In a global economy, this is a big problem but IBM is working on it, so hopefully it will get some priority.

The other problems from my point of view are that connections is very flat, it lacks hierarchy (nested groups). A very useful Notes feature. It also seems to lack a bit of granularity (something provided by two more great Notes/Domino features; [Roles] and Readers/Authors fields). Add something like that and there's no compelling reason to stay on Domino any more.

In the meantime, thanks to the open API in connections, there's a new breed of "Domino" app moving in to bridge those gaps between Notes and Connections.

Friday, February 19, 2016

Why Error 53 and the Apple Fight against the FBI is actually Good News for Consumers

There has been a lot of pressure on Apple lately with the US government pushing for access to their systems and lots of public pressure as people react to the “Error 53” scandal.

To many people’s surprise, Apple has dug their heels in on these issues and as the pressure mounts, is showing no signs of relenting. Normally I would be up on my soapbox denouncing this seemingly anti-competitive behaviour but this time I think that Apple is right to make a stand.

In the past, some of the things Apple did seemed to be mean spirited. For example; changing from the 30 pin plugs to lightning cable, and then blocking third party cables unless they were “Apple approved” (ie: paying royalties and super-expensive).



I know that they had their reasons for those changes, particularly safety, usability, size and speed but for people with stereo equipment that has 30 pin plugs, it still hurts - and no, adapters aren't a good solution.

Apple was mostly wrong then but despite the fact that the “bricking” of phones under error 53 is far worse, it's the right move.

So What is Error 53?
If you're unaware of Error 53, it's a status that gets checked and set when you update to iOS 9.

So, If you’ve had your iPhone 6 repaired by a non-Apple shop, it may have been working well for a while but when you do the iOS 9 update, it dies. In fact, it dies unrecoverably and permanently. 

Understandably people are upset about this but after contacting Apple, they have been told that this is a "feature" and that the behaviour is intentional. Naturally, the consumer groups are now getting involved in several countries.

You can read about it here;


As I mentioned earlier, I'm okay with this. The only thing that I have a problem with is that Apple didn't provide any warning about this.


What is the FBI vs Apple Thing About?
On the surface, the Apple vs FBI thing is all about the FBI wanting access to the iPhone of Syed Rizwan Farook, the gunman who was responsible for the 2015 San Bernardino terrorist attack. Below the surface however, this is an attempt by the FBI to set a precedent for Apple (and all tech companies) to build backdoors into their systems.

You can read about it all here;


On the surface, these seem to be two entirely separate events but both concern Apple and both concern security and privacy. It's a very big deal.


Why is it good that Apple is fighting for Security?
Moving away from Apple for a moment....

A lot of changes have occurred in the payments landscape in recent years. For example, we got automated checkouts at our shops. It was pretty cool. We were able to buy food and beep it through the registers ourselves.  Then, overnight (or so it seemed), these devices started offering cash out.

Suddenly, these automated checkouts stopped being simple "shopping systems" and turned into fully fledged ATMs. 

In most countries around the world, the ATM network is pretty strictly monitored. After all, you can't just have any old technician rocking up to fix them.  They have much higher security requirements. ATM's can be very dangerous devices. We all know what can happen if a criminal gets a chance to do maintenance on an ATM.... card skimming.


So, back to Apple....  unfortunately the iPhone doesn't actually dispense cash.... but with recent changes, it has become a payment method. Suddenly we're expecting the banks, the merchants and the consumers to trust Apple with their payment data.

In order for Apple to be trusted as a payments platform, they need to be able to prove that their hardware and software cannot be compromised.


Making a public stand against the FBI will certainly help Apple along the way to consumer and vendor "trust". Regular software security patches will consolidate this position.

As to hardware; Apple has a problem that most ATM and EFTPOS device manufacturers don't have. Apple's devices don't belong to a store, they're not wall mounted and they're not wired into desks. Apple's devices are personal, they're constantly moving and changing ownership.

The best way to assure the world that their hardware is protected, is to "brick it" whenever suspicious activity is detected - and that's exactly what Apple has done with Error 53.   If you mess with the devices biometrics (make a change to the fingerprint scanner), the phone will become inoperable... permanently.

... and it's for our own good.

Wednesday, February 17, 2016

A Walkthrough the Google Apps for Work Setup Process

About this Post
I'm a  big fan of Google Apps for work. Of the three major solutions I use on a regular basis (IBM Connections, Microsoft Office 365 and Google Apps),  it's easily the simplest to set up. In fact, I'd recommend it as the number 1 solution for small to medium sized companies.  I haven't tried it in a large company setting but I suspect it might be a pretty good fit there too.

A Little about Timing
In the recent past, getting established on the IBM ecosystem (IBM Connections), took about a week, while getting onto Microsoft's systems took more than two weeks (and it still causes a lot of daily pain). By contrast, you can get yourself established, without needing any help, on the google ecosystem in less than an hour -- yes, it's that easy.

Here's How

1. Go to the Google Apps for Work Site (https://apps.google.com/ - or in Australia, https://apps.google.com.au/) and click Start Here.



3. You'll be prompted to create your first user -- I always make this the  Admin user.
- Provide a Name: eg: CompanyXYZ Support
- Provide your current Email Address: support@myoldcompany.com

4. In the Section marked About Your Business  provide
    - A Business Name: CompanyXYZ Limited
    - The Number of Employees: (2-9 is a good start, since one will be your admin user)
   - Choose a country: eg: Australia
   - Phone: +61 2 9999 9999
   - Click Next



5. In the Business Domain address section,
    - Choose Use a Domain Name that I have already Purchased
      (if you already have one - these instructions assume that you do).
    - You'll need to type your company domain name and click next.

    - Note that you can choose to buy a New Domain 
    - The prices apparently start from AUD $9 per year including Automatic Setup. (very reasonable).




6. Setting up your Admin User
    - The next section gets you to set up the first user in your domain (usually the admin user).
    - Give them an email like admin@companyxyz.com
    - Give them a good Password
    - Enter the Captcha
    - Agree to the Terms
    - Click Accept and Sign Up

7. The next screen asks how you would like to set up your account.
    - Since I want to do this without support, I ignore the Google Advisor option
    - Choose Set up on your own. (and click NEXT)



8. The next screen allows you to add people to your account.
    - If you want to add a person, click Start
    - Provide a First Name,
    - Provide a Last Name
    - Provide a User Name,
    - Click Add. (Repeat as Required but remember you can set the users up later).

9. When you're ready to move on, click the box marked
    - I added all user email addresses currently using @companyxyz.com
    - Click Next

10. Next, Google wants you to notify your team.
      - Personally I don't like notifying people this early into a new domain,
      - I just used my own email address and sent myself a mail here.

11. The Next Steps are used to verify your domain
      - Since we don't have a website YET, we're going to verify via CNAME.
      - Click on - Choose a Different Method
      - Choose Add a CNAME or TXT Record
      - Follow the prompts.

      - On your domain provider's web portal, (instructions may differ depending on vendors)
      - Go into Manage Domains and choose your domain.
      - Choose Edit AAA CNAME Records
      - Go to TXT Records 
      - Set Hostname to @
      - Set TXT VALUE to  what Google gives you.
      - Click Add. (this takes seconds).
      - Google walks you through these steps, just tick them as you do them and you won't get lost. 


12. After the TXT Record verification, you'll need to set up your mail domains.
      - This is in your domain provider's interface again, probably near the TXT bit.
      - Look for a way to edit the MX records.
      - There are about 5 to add.
      - Add the Record and the priority (one at a time)
      - Each record should take seconds to add.

NOTE: Some domain providers such as Melbourne IT will give an error if you just paste the google records in. Their error is:  "Zone Integrity Error: A Relative MX Record should point to an existing A or AAAA Record".  All this really means is that you need to have a period (.) at the end of the record. 
ie:  Instead of: ALT1.ASPMX.L.GOOGLE.COM 
     it should be:  ALT1.ASPMX.L.GOOGLE.COM.

13 .Back at Google, Click Verify Domain and Setup Email
      - At the "Your Domain is Verified" message, click Next
      - At this point, technically, you're done. 



14. All of this is on the free trial (so there's no payment)
      - Google will recommend that you set up a payment option.
      - Click Continue
      - You'll be taken to the Admin Console where you can set up the billing 
      - You don't have to do that yet and can click cancel if you want. 
      - If you do continue, Agree to the terms, click Continue.
      - Fill in the Billing details and click Continue
      - You'll be told that you're now subscribed. click Continue



15. At some point you'll be logged out and will need to re-sign back in with your password and agree to the terms.

16. Next we need to Set up one of our Users
      - On the Admin Console, click Users.
      - Choose your non-admin user
      - Click on the three dots and choose change password
      - You might want to deselect the "force password change" box too.




17. Testing
      - Open a different browser, eg: Opera
      - Go to https://mail.google.com/
      - Login as your other user.
      - Send an email to it from another application on your desktop.
      - If all is working smoothly, the email will appear (and you'll be able to respond).


That's it....  You now have a fully functional Google Environment to explore. 

Tuesday, February 16, 2016

Does Cloud Storage Offer Protection from Malware such as Cryptolocker?

Recently we had a run in with the CryptoLocker malware, you can read about it here. The malware did a fair amount of damage across our file server but it was easily rectified by rolling back to shadow copies and traditional backups of files.

Of course, in writing the inevitable incident report, I began pondering the future and posed the question,

Given that traditional storage is giving way to cloud storage, does cloud storage in its broadest sense reduce or even eliminate the possibility of CryptoLocker, or similar malware in the future? - and -  in any case, what are our recovery options from the major vendors?

More or Less Vulnerable?
First, looking at the question of vulnerability, it very much depends on your access methods. All of the cloud services have web browser access to files, apart from general vulnerabilities in the browser itself, this is a pretty safe access method. If your password isn't compromised, it's unlikely that any of today's malware will be able to do widespread damage along that vector. Not unless you end up with a malicious browser add-on, and even then, damage is likely to be limited. The browser interfaces don't make it easy to automate mass encryption of files -- it's far more likely that your password will be compromised and provided to the attackers.

The most likely forms of attack along the web vector are in the form of password capture, particularly via spoofing. In other words someone either changes the DNS on your computer to point you to a different web site or they run a keylogger to capture your password. 

Then there's access via specialised apps on specialised hardware, such as Google Drive, the IBM Connections or Microsoft OneDrive, and their associated Apps, such as the IBM Connections Editor, Google docs, sheets or slides and Microsoft Office 365. This is probably the safest kind of access at the moment. All of the security settings and general access is controlled within the app.

These apps are arguably safer on phones and tablets, where they’re in a more “closed world”. The exception of course being the Windows tablet, which by definition probably has many of the same vulnerabilities as a Windows computer.

Connecting File Systems
Where this all comes unstuck however is when you directly connect a cloud service to your file system and enable synchronisation features.  For example using Microsoft OneDrive connector downloaded on your PC, or the IBM Connections Desktop Plugin or the downloadable version of Google Drive will make your file systems seamless to you … and unfortunately, to any malicious applications.

I think this needs to be on everyone's list of corporate, and probably home, “no no’s”.



Backups and Restoration
The great thing about cloud computing solutions seems to be that they back up constantly and that different versions can be restored easily.


  • Google DriveGoogle drive more or less saves after every change.  There’s a message at the top of the screen which says “saving” or “all changes saved in drive”.  If you click on that message, you can view older versions of your file in varying degrees of detail and you can restore any of those versions.  Of the three cloud solutions I looked at, Google Docs was clearly the most advanced when it came to saving and restoring. Head and shoulders above the rest.
  • Office 365I found the office 365 backups to be less comprehensive, In particular, using the Word application itself results in far fewer saves. Word online however does save as you make changes but it also doesn't handle the formatting of the offline versions very well. Restoring is via a simple right-click menu but I found the menu to be somewhat dysfunctional. Hopefully Microsoft will get this fixed soon.
  • IBM Connections
    Connections saves whenever you upload a replacement file or whenever you choose to save a document or page in progress. You can restore from any of these points, and they are clearly presented. What connections seems to lack, at least in some contexts, is a proper editor. There’s an editor on mobile devices but it is often completely missing on the browser --  though sometimes it's available.  Getting to restores is very easy, getting into edit mode is not. 


In Conclusion
Getting around single file encryption with minimal data loss in all three systems seems to be a relatively simple matter and clearly cloud storage provides a safer computing option than standard file share computing environments -- provided that you’re not using any file system connectors.  

The one thing that does seem to be missing in cloud systems is a wholesale recovery option for when an entire drive or folder is encrypted. Instead, users of these systems are expected to restore files individually. At least it is easy enough that it doesn't require any IT involvement. 

Sunday, February 07, 2016

A Run-in with Cryptolocker

A Little History
Over the years, we've had a fairly good run when it comes to viruses and malware. Much of that I can put down to the fact that we've always used IBM Notes as our mail system and it's less susceptible to hijacking. Of course, notes only slows down the distribution (and reduces the likelihood of specific mail calls being used).  It's not an effective anti-virus solution.

Years ago, I used to run my anti-spam services on the mail server. There were two problems with this approach;


  1. The mail had already reached our systems before the first scan occurred - even if it was just spam, you're now using your bandwidth and your storage.
  2. You're running secondary processes on (or between) your mail server. It needs updates, maintenance etc. 


Anti-Spam was the first service we moved offsite.

For the past few years, we've been using the Symantec.Cloud anti-spam service. This was a very good service when it was a recent acquisition (MessageLabs).  Back in those days, the spam used to pass through the filters of many of the major anti-spam vendors. These days, I think that it only runs through the Symatnec solution; making it far less valuable. We're finding that more and more spam is slipping through.

Our desktop scanners are Kaspersky. We've spent years on Symantec/Norton (slowed all of our PCs down) and McAfee (never actually caught anything) and Kaspersky has been pretty good overall but it didn't catch this one.


So How did it Start?
In this case, the email that made it into our systems was a variant of the Australia Post cryptolocker email that hit Australia from August last year onwards. This particular email looks very similar to real emails that Australia Post sends out. Our users had been warned about this particular problem three or four months ago but the fact is that if you keep throwing links at an organisation, eventually you're going to get lucky.

Detection
The first sign of trouble was when some of our users called the helpdesk saying that their files were encrypted. I was just standing up to go off to lunch but luckily I decided to investigate. This is why you need a responsive helpdesk - The reaction (and recognition of the problem) was time-critical. I immediately ascertained that the files were not .zip they were simply normal files renamed with .encrypted -- and there was a whole folder full of them.

I'd been following trends and reading bulletins from AusCERT, so although I didn't know the exact effects of cryptolocker, I immediately suspected it was the problem.

I quickly googled signs of it and discovered that the ransom message was the clue.  I looked for one on the person's computer but couldn't find one. I couldn't see one on the network either. I was just about to start disconnecting all devices from the network (all our PCs go to the servers via a single, easily isolated switch) when a user reported an unusual message.  We'd found the PC with the issue ... and it was a different PC to the one which reported the problem.  We immediately disconnected it from the network and started a local scan on it.

If possible, have a single point somewhere on your network that allows you to easily isolate systems in case there is a problem (this could be an attack, malware or even just a network traffic incident).



Confirming the Problem
I was pretty sure that Cryptolocker was malware, not a virus (meaning that it could wreck files but it couldn't infect) but I needed to be sure. I called one of our suppliers who had knowledge of cryptolocker and he advised me to look for the ransom notes in all the folders. There was a html and a txt version called "HELP_TO_DECRYPT_YOUR_FILES.txt" -- though some variants of cryptolocker use different names. They hadn't been there prior to the message but now they were everywhere. If you want to read them, open the text file.... there was too much HTML in the the other file, and it's too risky.

Looking at the properties of these ransom notes, we were able to confirm that all of them were created by the same user. There was only one problematic PC and it was now disconnected.


Cleaning Up
I already knew that the cryptolocker malware uses irreversible encryption, so the choices were either "pay up" or restore.

If you're interested, paying up was about $400 AUD with a timer set to go off in a few hours that would increase the price to $1,400.  They wanted their money in bitcoin.

I know people and companies who have paid up and they have had their files decrypted, so at least these people seem to have some honour.  Of course, if you have a decent backup, then it's safer not to draw attention to yourself.

In our case, we have drive shadowing turned on for our main drives which results in them being copied every two hours. It also makes restoration fairly simple.

The process of recovery was still long, but mainly because I wanted to be careful.


Tips and Problems in Restoration
I'm always telling people never to restore things to the same folders.  There's lots of good reasons for this which I won't go into right now.  We didn't have enough space to restore all of our data at once, so we did it in chunks.  Then we copied each chunk over the top of the good data (without overwriting). This meant that if a file was missing (because it had been renamed to .encrypted), it got restored but if a file was new/unaffected, it wasn't overwritten with an older version.

Part way though the restore process, we discovered that the malware had been triggered about three hours prior and that some files being restored had already been affected. Once we'd finished restoring the 10am files, we repeated the process with a 7am copy (which was definitely prior to the email).  That way we made sure that all of the right files were restored.

Getting rid of the Rubbish
The last things we did were;

Del *.encrypted /s 

On each affected drive letter. This removed the encrypted files.  We also did a

Del HELP_TO_DECRYPT_YOUR_FILES.* /s 

It certainly helps to know DOS.


As to the infected PC..., 

  • A complete scan using a current version of Kaspersky took nearly 24 hours and discovered nothing. 
  • The PC has now been wiped.