Long time updating!

Hey all,

So my blog has been neglected for a few months now (5! – wow, sorry). I do have a good excuse though. Well a couple actually.

Excuse #1!

So during the summer, I organised a coding camp for teenagers. It’s called Kainos CodeCamp and it was all about teaching young people what a career in IT is like, and also to bridge the gap between ICT (Spreadsheets, Word, PowerPoint, depression) and real software development. I even ended up talking about it on BBC news 🙂

Go check out the site for yourself, or watch the highlight video here


Excuse #2!

The second excuse is that a project I’ve been working on for 2+ years went into UAT. I can’t go into too much detail (obviously), but suffice to say that it’s a Claims and Policy management system built upon Dynamics CRM 2011 with MVC4, Web API, Knockout JS, Twitter Bootstrap and other cool things. It even has Fuzzy matching in the for fraud detection. I’ve been exceptionally busy with that, as the team had 22 people on it at one point.

So what next?

Exciting times are ahead. I’ll be involved in some Government work using new a new tech stack. I’m also switching to using a Mac, which will be pretty cool for me.

TechEd Madrid – Day 3

I’m going off the standard track for this post, as the whole session update thing on TechEd is a bit monotonous and besides, you can view the cool ones yourselves on Channel 9. What I want to do instead is share my thoughts on something that has been floating about in my head from all the sessions I’ve attended, namely ‘Security’.

Non-Functional Requirements
One of my roles as a Solution Architect is to look at the Non-Functional Requirements of a particular system I’mscalability designing. What’s a Non-Functional Requirement (NFR)? Well, it’s the bits of the system that don’t directly do something – as those would be Functional Requirements (for example, think of  a login page or password reminder page as a piece of functionality that needs to be implemented).

A Non-Functional Requirement complements the Functional Requirement and basically applies boundaries to what the system should and what it shouldn’t do. NFR’s cover areas such as system availability, resiliency, performance, capacity, scalability, accessibility, for example.

I like to ask potential candidates which of these they think is most important to a system they’ve designed, or are going to design, as it helps me see if they have considered how a system will evolve or if it is robust enough to cope with user demands. Usually (but not always) Non-Functional Requirements are treated pretty much equal to each other. If the system isn’t available, the customer could lose money, and we could be in breach of SLA’s. If the system isn’t performing, the customer could lose money, the users would get angry and business could be lost if orders aren’t placed in time. If it doesn’t scale….you get the picture.

However, I don’t hold this ‘equality’ view anymore. I believe security is by far the most important Non-Functional Requirement a system can have. Why? Well, if an attacker can compromise your customers system, they have the means to disrupt daily work, anger users, delay orders, damage reputation etc as per any of the other NFR’s mentioned above, and this alone is bad enough. What’s worse though is that they also have the ability to steal the intellectual property that your customer has spent years and huge sums of money developing. This is much, much worse.

Plans, schematics, bids, quotes, source code, employee records, credit card information, medical information, voting records, tenders, contracts, customer databases, sales contacts, pharmaceutical formulas, criminal convictions – could all be gone in an instant. Once its out there, you’ve no chance of getting it back.

A single breach could effectively be a killing blow to the customer and your reputation as a service provider. The scary thing is that it’s getting easier to do; even scarier is that in some cases it’s state funded. Typically these attacks are focused at successful small to medium enterprises as well, as they haven’t the infrastructure or policies in place to implement proper security procedures and they are taking on a lot of new staff who aren’t yet familiar with how things should be done. Sound familiar?


I watched demo’s today whereby Lateral movement and Privilege escalation were demonstrated. What does this mean? Well, essentially it means using a low level account to move along a network from machine to machine and get access to another machine with the same account (Lateral Movement). You can then pull from memory any password hashes that are left by say, a recently logged in Domain Admin and using these, escalate your credentials (Privilege Escalation)

What’s a password hash? Well basically it’s a one-way transformation of your password into a token or series of characters. If you use the same password each time, you end up with exactly the same hash. It’s a one way transformation in that you can’t reverse the hash to get the password. If you change the password, even by one letter, you get a totally different hash. 

Why use them? Well, a lot of operating systems use this approach for authentication rather than sending passwords about the network, as it’s very quick to hash the password and send that – which is sensible. However, it’s totally open to attack using tools such as Windows Credential Editor (WCE).

I watched today as the presenters demonstrated using WCE and USB infiltration devices like Rubber Ducky to compromise a system, simply by inserting it into a USB port. Within 3-7 seconds (slowed down for the demo), it had installed an number of back door passwords, executed a dump from memory (using WCE) of the hashed credentials on the machine and uploaded them to a website. Three to seven seconds.

The tools are becoming more advanced, and as systems become more complicated we have more surface areas to attack. The weakest area of all these attack vectors however these however is us. You and me.

You see, we are after all only human. So many sites, so many passwords. It’s easy to use the same one for all of them right? What about us as developers? You run Visual Studio as Administrator on your dev machine yeah? Turn off User Account Control? What about contractors? How much access do they have to your system? Can users install their own software? Bring in their own USB devices? 

What can be done?

It’s an absolutely massive challenge that cover so many areas, but some key points are:

This is a really good article on the anatomy of an attack. Definitely worth a read.