Infrastructures are the foundations used to provide services: since services are subjected to confidentiality and availability requirements, infrastructures must be designed so to provide several confidentiality and availability tiers. This way a service can be placed on the part of the infrastructure that meets the availability and confidentiality requirements for its use case. This means that one of the very first things to do when designing infrastructures is defining the corporate's standard tiers.

Benefits

Defining corporate standards provide a lot of benefits:

    • avoid reinventing the wheel each time, and so also avoiding  the risk of having several similar wheels that actually differ a little bit one another.
    • it is easier to express requisites, since it can be avoided to provide a detailed description of a requisite that has already been standardized
    • there is a lower risk of misunderstandings, both when designing and implementing as well as when operating on systems and services, since these should be tagged with the tiers they belong to.
    • it eases communication from business to technician, providing some well understood words that make senses on both fields

Availability tiers

Availability level means how available a component is: for example there are business cases that require 24hx5 availability, others that require 24x7. Some business cases may require an availability of 99.999% - that means only 5 minutes down per year.

Defining availability tiers is no mandatory - you may already have 99.999% infrastructure that let you provide any kind of service, but from the business perspectives probably you are wasting moneys: by defining availability tiers you can limit the high costs of fully redundant components and instead use more cheaper components for the less business-critical services.

Examples of availability tiers can be:

  • B1 – collateral system that does not directly affect the business
  • B2 – business bound system not so critical to the business
  • B3 – business bound system critical to the business
  • B4 – business bound system mission critical to the business

CONFIDENTIALITY tiers

This is a very important concept you must get acquainted with: it is a best practice to define a few confidentiality tiers along with describing what they apply to.

Examples of confidentiality tiers can be:

  • S0 - publicly available
  • S1 - internal use
  • S2 - confidential
  • S3 - strictly confidential / business secrets

These confidentiality tiers must be used to tag both roles and the object (the asset) a role is granted access to; the access rule then is straightforward: a role can grant access to assets belonging to the same confidentiality tier of the role itself. Of course this requires to create multiple instances of the same role, one per confidentiality tier.

Do not assign confidentiality tiers directly to users! Besides being in contrast with the RBAC framework, his approach is not granular enough: a user may be entitled to access assets classified as confidentiality tier 3 for some purposes, and other assets classified as confidentiality tier 2 for other purposes. Confidentiality tier should be assigned only to assets and roles.

Footnotes

Designing infrastructures is more an art that a science. However there are best practices and guidelines that should be followed to avoid common pitfalls: defining availability and security tiers is certainly one of the very first thing to do, ... although I often see people underestimate this, maybe because they seem not so important at first. But as time passes by they will become more and more important. The identifier assigned to the tiers must be added only to the security objects that are used to grant an access level to configuration items: for example when designing  the corporate naming convention for the RBAC. But this will be the topic of another post.

I hate blogs with pop-ups, ads and all the (even worse) other stuff that distracts from the topics you're reading and violates your privacy. I want to offer my readers the best experience possible for free, ... but please be wary that for me it's not really free: on top of the raw costs of running the blog, I usually spend on average 50-60 hours writing each post. I offer all this for free because I think it's nice to help people, but if you think something in this blog has helped you professionally and you want to give concrete support, your contribution is very much appreciated: you can just use the above button.

Leave a Reply

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

You may use these HTML tags and attributes:

<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>