CISSP :: Security and Risk Management – Part 1
The first domain we will discuss in my series of CISSP articles will be Security and Risk Management. I will break this down across several posts, with the intention of keeping them “bite-sized” and easier to take on board. I will use the (ISC)2 defined sub-categories of each domain as headings during my posts.
Confidentiality, Integrity, and Availability Concepts
This is a good place to start, in this section I will give you an overview of what we mean when we say “Confidentiality”, “Integrity” and “Accessibility” and why they are important to us and our IT systems.
It seems obvious to say that only people who need access to certain systems, or parts of systems, should be given access – but I often see this basic concept being cast aside. This isn’t necessarily due to malicious intent, but often users are given permissions above and beyond what is necessary to ease the work load on system administrators, but also to remove barriers the user faces. One concept (that combats this) that is worth discussing is the “Concept of Least Privilege” – this concept goes further than just limiting permissions based on roles, but instead breaks it down to permissions required to fulfil a specific task – by this I mean, an IT administrator may need to be a Domain Admin in order to fulfil elements of his/her role, but not every task he/she carries out will require these permissions; it is therefore good practice for this person to also have an account that does not have Domain Admin rights, that they use on a day to day basis. When Domain Admin permissions are required, then and only then would they use an account that has those rights. This is important because the more you use an account, the more opportunity there is for that account to be exposed to unforeseen threats and compromised. There are plenty of examples I could list, but they are outside of the scope of this post – I do advise you explore this concept further and perhaps even enforce in your own environments.
However, confidentiality is more than just user rights and permissions – it can also mean the proper labelling of data. Classifying data based on it’s sensitivity can assist with restricting who has access, but also what level of protections are applied during the storing and sharing of that data. The reason protecting data is important is because it could be personal information that shouldn’t be in the public realm, but also business secrets that provide an edge over competitors – these are things that will be explored further on in this domain. There are plenty of solutions available that will assist with keeping data confidential, and they aren’t cheap!
Data is only as good as its integrity – users need to be able to trust that the data they are reading has not been tampered or comprised in any way. If there is data that must not be changed, there must be process and controls in place that prevent this data from being changed. This is true for the data no matter where it is, whether in storage or transit.
Another consideration when thinking about Integrity of data and systems is; who should have the ability to read, modify and delete this data? Proper protections should be in place to ensure that users that should not have this access, don’t. Further to this, when users do have access to read, modify and delete, change control process should be in place to track those changes, in addition to appropriate logging when those changes have happened at a system level.
Now we have talked about access to, labelling of, and integrity of data/services; we also need to talk about availability of them. When systems are not accessible, it can have a drastic impact on a business and its ability to function. We as system engineers/managers must ensure that not only are these services protected, but also that those who need to access them are able to, whenever necessary.
Further to Integrity when I mentioned change control, this is also important for availability – when a change is due to take place to a service, it is important that those changes are peer reviewed to prevent those changes having a detrimental affect on availability.
In addition to the above, we must also make sure that there is a disaster recovery plan in place in the event of an outage to a live system. It is important to make sure that the disaster recovery plan doesn’t then impact the security of your data and services, a poor example of “recovery” would be – some firewalls have the functionality that during a power failure to the appliance, they can “fail-open”. Although this may be good for availability (unless it’s a routed network) it is not at all good for the security of your network, which could leave the confidentiality and integrity of your data and services at risk. Recovery plans must maintain the security of your data/services, as well as availability.
As you can see, the aim of Confidentiality, Integrity & Availability is to know what you are protecting, controlling who has access, maintaining the accuracy of this and also ensure that it is available to those who need it and only those who need it.
Hopefully this will have served as an overview to this particular element to the Security and Risk Management domain. I will be following this post with Security and Governance Principles in the near future. I hope you have found this post useful and please let us know your thoughts – remember to take a read of our other posts as I’m sure you’ll find something useful.