The risks and rewards of evergreen IT

Evergreen IT will become the default model for new technologies, predicts RSA CIO David Germain, but securing evergreen systems requires an holistic approach

Evergreen IT is a strategy that deliberately seeks to avoid systemic shocks caused the need for sudden budgetary outlays, systems becoming unviable, partnerships failing or any other significant unforeseen change. Instead of five yearly overhauls, it implies a steady stream of small changes to ensure that the IT stack never becomes inviable. Evergreen IT is not a new idea but it's one that has come of age, prompted by the need to manage increasingly complex and interrelated systems and to deliver continuous improvements, and enabled by cloud and automation technologies.

A vital feature of evergreen systems is that interdependencies the between different components and layers of the stack are managed intelligently to avoid the situation where failure in one area produces damaging and unpredictable knock-on effects elsewhere.

Following our recent Deskflix: Cyber Security II event, we spoke to David Germain, Group CIO at RSA Group, about managing evergreen systems from a security point of view. The interview is edited for brevity.

Computing: The idea of evergreen systems seems to be back in fashion. What is your take?

David Germain: Organisations are having to find a balance between their ability to cope with the pace of change and keeping systems on the latest version. An evergreen model will become the default model for new technologies as vendors start to address the challenge of cost and supportability of IT at source, resulting from a legacy of old hardware and software. This balance is required not just from a resource perspective but also with respect to dependencies between systems. If one system changes faster than other dependent systems, it could lead to ever more complex upgrade scenarios.

What are the key indicators that a traditional system may be becoming ‘legacy'?

Two key indicators to be aware of are vendors who stop supporting their own product, and a shrinking, ageing pool of talent available to support and maintain the system. The older hardware becomes, the more problematic it is to keep operating or to implement new change - vulnerabilities are no longer patched, knowledge of the system lies with a minority of experts who are leaving the workforce, parts are discontinued, new technologies cannot integrate.

Is managing security easier or more challenging with evergreen systems?

On the plus side, 'evergreening' means systems can be continuously updated avoiding the cliff-edge of out-of-support platforms where security updates suddenly stop. It can also bring new security capabilities into existing systems in an incremental and integrated way which security functions can leverage, reducing the need for additional vendors and solutions on top and being able to leverage the ‘latest and greatest' to keep-up with ‘evergreen threats'.

However, evergreen also means the continual release of new product features and hence the possible introduction of new vulnerabilities if these features aren't expected, understood and communicated. This requires security teams to adjust their operating models, introduce more agility in their decision-making processes and partner with internal product owners to ensure security in a trusted partner during the continual release process.

In large, complex systems, patches arrive thick and fast, but as we know they don't always work as intended and can have unwanted side effects. How long should you wait before applying a patch?

An organisation's approach should consider their in-house engineering capability - or that of their IT support vendor. A solid engineering capability whether in-house or outsourced will allow for people, tools and processes to test and deploy patches in a timely manner, especially when leveraging the benefit of the scale you get from a large IT support organisation. The depth of this capability allows an organisation to be confident in robust testing prior to deployment, as well as the ability to continue to rapidly deploy critical day-1 patches with minimal risk of adverse impact.

Typically, technology companies are where one finds such depth in their engineering teams. Other companies see their fundamental purpose as business services (e.g. selling insurance) and not being a technology powerhouse. In such organisations, the speed of patching will have to be balanced between a team's ability to cope with change, and more importantly, any customer impact a failed patch may have.

Should we be aiming for optimum speed of updates rather than always faster? Is faster always better?

The optimum speed is one in which balances the costs, benefits, and importantly, the risks, according to the risk appetite of the organisation. This balance doesn't necessarily equal fast delivery of change.

But with competitive edge often associated with speed, this is often what the business requests and requires of technology. However, if unnecessary, unmanageable risk is introduced to the process, mistakes can be made, incorrect assumptions applied, complexity misunderstood, all of which can do irreparable damage.

Each organisation will have to determine their own optimal balance between their propensity to make change at speed, versus their effectiveness of managing and implementing change at speed.

If you had to give one recommendation for safely rolling out changes more quickly, what would that be?

People are often a major factor in the occurrence of error when implementing change, rather than the technology itself. Whilst a vast majority of this can be mitigated and managed through effective communication, tooling and processes, ensuring that you have the right people on the park, both internally and externally to your organisation, and gaining business buy-in, is of the utmost importance.

To gain buy-in from the business requires trust, born out of effective stakeholder management. That begins with correctly identifying who your key stakeholders are, coupled with a partnering approach between IT and their business stakeholders, fostering a collaborative culture that focuses on understanding the business strategy and objectives, to jointly drive the delivery of effective change.