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.
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.
