Skip to main content
Home  › ... Technotes
SuperUser Account
/ Categories: Security

The Future of the Technical Design Authority

Many large organisations have a Technical Design Authority to ensure that any IT project is compliant with organisational standards especially in regard to capacity, strategy and security. Well, many but not all large organisations have this role and, from my experience, very few small to medium sized organisations do as the actual skills to perform this role are expensive to acquire and maintain especially if the organisation is under pressure to reduce costs.

The Technical Design Authority role is an increasingly important one as every organisation these days will find itself immersed in a world full of ever more complex data protection legislation that constantly changes what your IT systems should be doing and, as the cynical amongst you will likely have figured out by now, business insurance cover against cybercrime losses will likely become very expensive if you don’t have a whole series of formal procedure and processes to ensure compliance with what will be something of a moving target.

So, what had actually diverted me from my morning coffee? A couple of things. The first was simple request to assess the security implications on a change request that would allow an application in an external organisation to authenticate internal users. Hardly an unreasonable request but the proposed solution – from the external organisation, I would add - was to present an internal domain controller on the public network so that the external application could query it via LDAP. This was a ludicrous solution yet the external organisation seemed completely unaware of this perhaps as their solution would involve the least effort on their part. The lesson you should learn from this is that you should formally define how services, such as user authentication, will be provided to any external organisation. That way, you can protect your organisation from the foolishness of others before that IT auditor has to remind you.

The second was a rather more complex and expensive one. A project to ensure service availability by mirroring everything between two data centres have gone over budget and over timescale and was currently in a permanent holding pattern. The root cause of this was poor design processes. The basic idea – mirror everything – was valid but no account had been taken of the logistical problems of doubling the size of the server estate (you need twice as many people to support it, for a start) or the ongoing costs (effective doubling of licensing costs, for example). Add in the fact that, even at the start, there was a clear lack of technical resource to implement such a plan anyway and the project was destined to spiral forever over the pit of doom. As it turned out, at the initiation of the project, the organisation in question just didn’t have the technical skills or evaluation procedures to properly verify that the intended project was actually viable. A lesson learnt, of course, but an expensive and embarrassing one.

So, the point of all this? If you are an organisation that cannot afford the overhead of the technical design authority role on a full time basis then protect yourself by defining policies and procedures that allow you to validate that any proposed infrastructure changes – and, of course, normal change requests – are compliant. This may require you to hire in person or persons on a short term basis to help you define all this but at least you won’t have the ongoing cost of such staff. In addition, you have ammunition to protect yourself should you find yourself subject to an audit.

I think there would also be a gap in the market for the better IT consultancies to offer the technical design authority role as a service. Some already do, even if it only as an adjunct to their more nefarious commercial intentions, but the scope would be would be there to package up this as a separate product. Again, this would be beneficial from an IT audit perspective (and I suspect that there will be a lot more money to be made in IT Audit in the coming years) and would give beleaguered IT slime people something that might actually sell.

Previous Article Penetration Test Remediation Approach
Next Article Office 365 Basic fault finding Part One
Print
2647 Rate this article:
No rating
Please login or register to post comments.