“Supported” Principle Added

Added a “Supported” Technology Principle. It also applies to security as a principle. It’s aim is to require solutions to have support from vendors available to the University. This is to ensure that if security vulnerability or problems arise there is fast access to fixes and help.

Having support for a 3rd party product is key to providing a reliable and available service.  It is rare that the University has the skills or knowledge to fix a product directly.  Although often an internet search will reveal a fix or a mitigation, it’s only the vendor or authors who can really fix it.   

So support is akin to AA/RAC membership, you really don’t want to pay for it or use it, but there is one day when your rear diff dies on a family holiday – you’re so pleased you were a member!

Obviously there are many models for support depending on the vendor.  Key for core infrastructure is time to fix.  It’s no good having to wait for the open source author to find the time to get around to fixing something, a critical problem needs a fast fix.  At the other end of the scale, a bleeding edge research project could sacrifice fix speed or even security for functionality in some specialist software.

The key implications for infrastructure are:

  • Open Source software needs to have proper support.  This limits the choice of open source software for which such mechanisms exist.  Typically, these are “Enterprise” versions of open source software such as RedHat Linux, Nagios Enterprise, etc.  There’s other advantages with the Enterprise SKUs in that they are typically supported by other Enterprise software – e.g. Hardware monitoring agents, asset management, VMware tools.
  • There is a proper process for rolling out fixes in a timely manner.  The process should be able to try out a fix in a test environment before deployment.  This gives confidence in being about to apply these fixes to the live production environment even during important times in the University calendar such as clearing, enrollment.
  • Running solutions which are no longer supported is not an option, or it if it a necessity (no replacement available, required to keep to access legacy data, etc.), then suitable mitigations are in place – e.g. isolation.
This entry was posted in Enterprise Architecture and tagged . Bookmark the permalink.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.