RSS feed for blog Linkin Skype Mail Me Twitter


Click for Full Blog Listing

Learning A Lesson About Security from other People

My self and the rest of LDC went to the MongoDb Coming To You day in London and amongst the many interesting sessions, there was one about MongoDb security, I’m not going to even post a link to the slides as the interesting part was not on them, it was an story about a company going under due to losing control of their AWS (Amazon Web service) access keys, their site was hacked, their servers terminated, their databases deleted and all their backups purged. Everything…. Dead

This gave me quite a shudder, I’m more than a little bit paranoid at the best of times, but it did remind me of off the old phrase to never “put all your eggs in one basket” and that applies as much to cloud platforms as to anything else, however its a tricky trap to escape from as the cloud service providers sell them selves as everything you could ever want and there is no need to have any other vendor, they make it sooo easy to just bolt on services using the same credentials, yes they do provide granularity and yes they provide 2 factor authentication, but they are always a single point of failure and there is no physical security measure if you suffer a major breach (you can’t pound down to the server room and yank the cables out the back of your router or servers) if the bad guys get your security keys then they ARE you.

So what to do?, cloud services are cheap and hideously powerful for their money, not using them robs you and your company of a major advantage in the Internet economy?

Well let’s relate this all back to personal experience and in particular LDCVia, after the conference we sat down and worked out some worst case scenario ( loss of the root account API keys, breach in a primary admins 2 factor authentication or a member of the LDC founders being possessed by a Brain Slug) and figured out how we would deal with them, not what we would do to prevent them, as we had already do everything we can to that end:

  1. 2 factor authentication on every account capable of doing anything at an infrastructure or admin level
  2. Not using primary accounts or their API keys for day to day activities.
  3. Multiple single function accounts and granulated security.
  4. Operating level accounts should not have access to database content
  5. Proper firewalls.
  6. etc. etc. etc.

But how much damage we would be looking at and what the hell we could do to mitigate and recover from it.

For how much damage?, cater to losing all of it, the whole lot lost or compromised :( how are we going to deal with that >:( .

  1. Backups should not be on the same security domain as the servers and databases. hell they should not even be on the same cloud service (you create backup accounts with read only access to only databases, with no OS access) and the servers should have no idea the external backup provider exists, don’t forget to limit the source IP address for these accounts or else you are just giving people a nasty back door to your data.
  2. App servers and database servers should should be segregated in the same way if possible, now this will often depend on network connection speed as db access though a firewall is really going to slow down your apps, but often cloud providers provide good links between different accounts on their network.
  3. Inquire with your cloud provider about a separate authentication method in the case of a breach, a phone number to call and a list of real people and credentials such as you use for phone banking that can shut down all access so you can pick up the pieces,
  4. Talk and I do mean actually TALK with your provider to find out what provisions they have for this scenario type. and while you are there find out their notification schedule are you being told about their network changes? also what back door accounts to they insist on adding to your systems, how are they protected? … in short be knowledgeable about your cloud platform.
  5. Can you take full images of your machines and store them else where (not just backups), they are a lot faster to recover from
  6. Work out your full DR restore strategy, how fast can you get all the servers and database built and back on line, what gets built in what order, what do you tell your clients during that time, what’s the public message you display? get it all written down distributed to the right people and for heavens sake down store it in one place.

I think I need a brown paper bag and a quiet place to calm down (shudder)

2014 A Year In Review

Looking back on this year, it has been the most varied in my working life.

Making the move from contracting to pure freelancing early in the year I worked on some interesting smaller-scale projects before getting the chance to work for the guys at and in particular Rene Winkelmeyer who turned out to be a truly awesome person to work with (well I knew he was awesome, but he turned out to be awesome’r). The midpoints work was really interesting and I recommend that you go and look at their new products.

The mid point work was the largest single chunk of work this year with the rest of the time filled with tons of individual projects for well over a dozen clients. none of which was either boring or unchallenging (lucky man that I am)

The skill set used this year has taxed my tiny tiny mind, from core java upgrades (1.3 to 1.8) through lots of infrastructure work with Node, Jboss, apache, and IBM connections past a wide variety of database stuff for DB2, MYSQL and MongoDB to lots of serious front end stuff with Vaadin and Domino… all in all…I say…bring it on!!

This year has had 2 challenges for me as a freelancer, the first and obvious one is to manage and maintain a steady flow of projects, its harder than it looks and I am lucky to know people like Matt White and Mike Smith to provide advice and tips, the second is Working primarily from home has been a new experience and not one I am used to. But it’s helped me focus and I’ve worked out some great tools and methods to help me:

  1. The use of enabling me to chat to the rest of LDC and The Turtles but not get bogged down with the general flood of the internet.
  2. The use of the that keeps me on course during the day and ensures I do a solid days work
  3. Office rental, I use a mixture of Regus Lounges and a desk I rent at to actually ensure I see some humans once in a while.

Through all of this has run LDC and our first product LDCVia, something I am really excited about as having helped build it I can see the massive potential for what it can do also building a product with spanking new technology has taught me tons of new stuff and given me a chance to activity work again with some of my favourite people: Matt White, Julian Woodward and that evil bugger Ben Poole

Finally we come to being an IBM champion, a groovy thing but basically a product of other peoples work and support, particularly Gabriella Davis, who prodded me up on stage for LotusIdol years ago, hired me to do IBM Connections development when it was just starting out and generally has provided me was a metric sh*t load of support through both this and previous years, she does not get half the credit she deserves.

By the way, I have spare capacity opening up from the second week in Feb 2015, so if you have Java/Scala work, Connections customisations, complex website stuff or even some good solid Domino stuff, give me a kick.

Thinking of an image that sums up 2014 for me would be one of my bl**dy cat who because I have been working from home this year is the creature I’ve seen most of. and as you can see he provides tons of support (the lazy swine)


IBM Connections Dev Update to V5

As per this blog by Gab Davis, customisations in connection V5 is not the same as V4.5

Now that is expected with just about any software upgrade though a list of upgrade requirements/changes for customisations just as there is for administration would have not gone amiss,

The nearest you will get is this blog by Paul Godby (which is very useful)

It gives a lot of excellent details, I personally found that the major changes between connections CSS v4.5 and v5 were ones of extra granularity caused by catering to the dynamic widths on the content (do not forget that your widgets will no longer be fixed width) and spruced up side menu in V5, so you should find that adding extra elements to your existing CSS rules will solve 90% of the problem the upgrade brings

In additional to the details provided by Paul, its worth noting that the open social widget standard seems to have been quietly dropped and iwidgets are back in favour (the basic open social widget wrapper for an XPage no longer works)

So where you might have had a basic open social widget XML of

<?xml version="1.0" encoding="UTF-8"?>
            title="Example title"
            author_email="" height="800" scrolling="true" width="450">
    <Require feature="dynamic-height"/>
    <Content href="<Computed Value>/content.xsp" type="url" view="canvas" />

you will most likely go back to the iwidget version of

<?xml version="1.0" encoding="UTF-8" ?>
<iw:iwidget name="WelcomeTabAdministrator" xmlns:iw="" iScope="htmlWidget"  supportedModes="view" mode="view">
<iw:content mode="view">
       <iframe src="<Computed Value>/content.xsp" scrolling="no" width="450px" height="800px" frameborder="0" scrolling="no"></iframe>

The good news is the SSO works just fine in the iwidget.

Click for Full Blog Listing
Latest Blogs