In this post I go on a winding road of exploration around some of the challenges I find with organisations when it comes to the realities of secure technology management, some of the barriers I see and the stark truth that technology security challenges are not a two-minute fix. Be warned this is an exploration of thought so it’s a bit random in it’s path but hopefully it shares some of my insights and thoughts from over the years.

The anti “We have always done it this way” way

This is a phrase as a consultant I hear all the time, I have worked with hundreds of organisations and probably thousands of people over the last 20 years of my career and some things seem to hold true regardless of how ‘smart’ our devices are, how fast we deploy or how ‘agile’ people think they operate some things generally seems to hold true:

• Quality requires hard work
• Quality requires more upfront effort
• Quality is a marathon not a sprint
• Quality results in improved customer satisfaction, improved staff experiences and greater long-term returns

I see technology and cyber security maturity really as an indication of quality. Attention to details, spending quality time researching, engineering, and understanding a system generally results in a much greater level of operational performance, availability, reliability, and reduced risk.

In the days of faster, better, cheaper this is probably at odds with some people’s mentalities. Consumerism has hidden complexity under a false veneer.

A change in flow

When people are not used to working with good practises and security ‘must haves’ (yes documentation is required it’s not a nice to have if you want to securely operate a service) it must be quite alien to them to suddenly have someone tell them they need to have documentation. I also think this is similar for someone who is not well versed in a range of technical management subjects. If someone has not got experience of these domains, processes, activities and practises it must be all rather overwhelming when confronted with frameworks and standards.

This is not a two-minute job

If you think this is super-fast, please show me how because I have been playing this game for a long time. Someone is probably going to tell you that they can something faster, cheaper etc. But think about applying that to your business and see it works for you if your customers asked you to provide your products and services at 25% of what you quote. It probably will not be a long conversation. Why do I bring this up when it comes to security culture? Well that aside let us look at some of the realities around planning for quality and security in service design and operations.

Practical Realities

fundamentally there is often a direct link between quality, effort, cost, and time. There is also the reality of seeing how people’s approaches to technology deployment and management are often directly at odds with building quality and security into the service/solution.

The art and science of estimation

If anyone has worked with me that is reading this will probably have heard me talk about the linkages between mature IT and security capabilities and the link to resources, leadership commitment, skills, effort, and planning. I mention estimation because so many people seem to respond to estimates (be they for multi-million-pound programmes or a few weeks penetration testing) with comments like these:

• Surely it cannot take that long!?
• Can we have a quicker version?
• Can we do the bare minimum?
• We don’t need documenation!
• We’ll project manage it.

It’s been this way since I first started cosulting and I doubt this is going to change much. But it’s important to understand this challenge as in my experiance consultants are engaged to help with change in spaces that the requestor does not have the experiance or skills. It can however make this quite challenging.

Why is this important for building a culture and pracitse of security? Well it’s about being honest and realistic when it comes to the fact when you are adding to a system it takes time. Be that a human or a computer system!

Why is it like this?

Honestly, I am not a psychologist, so I have no bloody idea on the technicalities, but I have a few ideas:

• No one likes to be made to feel stupid.
• No one likes to get ripped off.
• People like to feel like they are in control.
• People like money for the services they sell but often do not value that concept when it is applied to others.

Now I am writing this from the perspective of a consultant but before I roamed the consulting oceans and during long term programmes I still integrate with organisations and programmes/projects, so I still see the inside world. I see this internally, with customers and with industry friends who get to experience the same ‘joy’ I do when it comes to programme and project work (or departmental budgets etc.). I am talking about this because money, resources and time etc. are a huge factor (and often a constraint) that must be understood. Everyone who has worked in the B2B marketspace will know that project management and documentation are first to go (but also security is alongside that).

A Real World Example

Let us take an example of deploying a server. If your usual modus operandi is to click next finish and hope you have the details for what you need then your deployment pattern is probably like this:

• Have a quick chat with someone about their requirements and then just go ahead.
• Create new VM
• Install Operating System
• Run Windows Updates (maybe)
• Install application
• Configure Application
• Release to Production

Now let us look at how this would be done with a higher quality and assurance bar:

• Document the requirement
• Design and document the solution
  • Sandpit
  • Testing
  • Production
• Validate the design and have it approved
• Raise a change request
• Review at CAB and schedule release
• Create the new VM in the relevant phase
• Install the Operating System
• Patch and Harden the System
• Install the application
• Configure the application
• OAT
• UAT
• Security Testing
• Documentation
• Repeat until you are in production
• Early Life Support
• Handover to operations
• Project closure

Now there is a dramatic difference in here and in reality, I have just written down a very abridged note like version of a design lifecycle.

Now I will probably see a cry of people calling about AGILE/agile… so ok here we go.

In an Agile development methodology, you still need to think about security, you still need to create documentation and you still need to test all the things, you will just be doing that in backlogs, stories, sprints etc. You can see already that designing security into your development process and leveraging automation are going to really help out here. But what you might notice is that agile doesn’t say just forget about security (and whilst it values working code over documentation it never say’s you shouldn’t have any documentation either!)

Security in concrete? What is this magic?

Security and Quality often go hand in hand. Security is however not a static state, what is reasonably secure today can be critically vulnerable tomorrow (though that’s usually when quality/security has been traded for cost/speed/profit etc.)

So, the idea of using frameworks and standards alongside direct linkages to quality is to give business products and services a scaffolding of support and quality around its core purpose.

So where does this leave us?

• Recognise the realities.
• Recognise that doing things in a secure manner changes the profile of the activity (hate to break the bad news to people but it usually takes longer, sometimes significantly so).
• Security must be balanced.
• Security should be viewed as a quality investment and should support business not only through risk management but also quality improvement and therefore should support a return on investment (ROI).
• When you speak to specialists in this subject remember there is an entire industry in this space, so if you think you know better that is fine but be honest and realistic.
• Building security into things requires people to operate differently, change is hard, but that is ok. Hard work usually pays off!
• Security is not easy; I wish it were. Trust me I would not be bored, technology management as a whole is a bit of a dumpster fire! (security aside)

This post started as a view on culture, yet I realise a lot of what I am talking about probably feels more like a financial, procurement and deployment methodology conversation, and well that is because it is. The spirit of an organisation starts with leaderhip and planning.  Without the right leadership approach and planning your culture is likely going to reflect the initial approach, chaning this is no turn key solution.

However you approach building security into your organisation, it’s often a change in status quo or change in behaviour. Small steps are the start to making big improvements, and all improvements are wins!