Operations Security (OpSec) is concerned with the same basic elements as all the other CISSP domains and those are confidentiality, integrity and availability.
So let’s approach OpSec from that CIA perspective: How do we keep the data and systems confidential, maintain integrity and ensure they are available? There needs to be controls for both the data and the people who have access to the data. And, those controls need to be monitored for effectiveness as well as to determine if any incidents have occurred.
When looking at staff, we need to ensure that background investigations are being performed for anyone with access to sensitive data, we need to enforce the taking of vacations; we need to plan for and execute job rotation; and we need to remember to grant access based on the principle of least privilege. Only give the person access to the data they need to do their job and do it using RBAC (role based access control). RBAC makes it a lot easier to add and/or remove access since you only have to remove the rule to effect the change. Job rotation and enforced vacation taking are both controls used to prevent/deter fraud. Ensuring that each person also has a separate sign-on helps to enforce accountability. And while we’re monitoring the people and their access, you need to know the definition for “CLIPPING LEVELS” and how it might be used. For example, we might set the audit software to only report failed login attempts if there have been more than five for a single user within a one hour time period. Which, by the way, could be an indication that a password attack was underway.
Before we talk about the data, let’s look at the hardware/software side of OpSec briefly. There needs to be system controls in place to help the operations staff when it is time to reboot, patch, upgrade, run backups or run daily jobs. There needs to be controls… No, make that CHANGE CONTROLS in place regarding hardware maintenance, even down to the point of reconfiguring the hardening of a particular server. Nothing, and I repeat nothing, should be done to a piece of hardware without an approved change control, signed by the appropriate management representative. And, the change should be vetted in a test environment and NEVER directly into production.
Two other rules for hardware:,
- Vendors should be required to come on site to make changes or upgrades and only if they have an approved change request, notice I stated they should come on site — that eliminates all the remote access issues for vendor maintenance.
- Those vendors should be escorted by someone in OpSec, familiar with what’s being done. We don’t want the vendors making random hardware re-configurations just because they happened to be on site.
Another key concept here is that the escort should be knowledgeable, otherwise the vendor can feed them a line of meaningless chatter and proceed to change whatever they want. Here’s a good scenario question for you. The vendor comes on site and says, “You have a bad drive in your RAID array. I’ve replaced it with a brand new one and all the data has been restored. I’ll take the old one back with me so that you don’t get charged the shipping fee.” Should you allow this? The answer should be NO. To protect the confidentiality of data which may or may not be stored on that drive, you need to put it through your own sanitization procedures and not rely on the vendor. I realize it’s a stretch, but that is a good example of Data Leakage.
And speaking of maintenance in OpSec, you’ll need to understand Mean Time Between Failures (MTBF) and Mean Time to Repair (MTTR) as part of the disaster recovery process for OpSec.
Data — like people — also need the principle of least privilege, in that only people who need to see it should be allowed. It needs to be backed up and stored offsite to help OpSec achieve the RTOs and RPOs defined by the user in their Business Impact Analysis. Just as an aside, what is a “safe distance” when it comes to defining where data will be stored offsite? My definition is that the event which caused the disaster will not affect the offsite storage location, if it does then it’s too close.
Like most other areas, OpSec also needs to have its own continuity of operations plan. How will they continue to do business if the IT infrastructure is inoperable? Let’s say just one array of disk drives are down and the vendor has a four-hour response window, the question is, what do you do during those four hours while you’re waiting for the vendor to fix the hard drive? What is your incident response plan? Speaking of which, and as the last item, every OpSec group needs to have a very thorough incident response plan. Who do you contact if there is an incident? What if it’s 3:00AM on a holiday morning? What if it’s on the late night shift and the other operator has gone to dinner and you’re the only one in the computer room? All of these need to be spelled out in an incident response plan.
And… that IR plan along with the COOP and DRP need to be tested — frequently.
I hope you have enjoyed the articles on the CISSP domains and I look forward to seeing you in class.
Incoming search terms:
- cissp operations security
- operations security cissp
- cissp operations security domain
- security operations in cissp
- doe opsec training/seminars 2013
- cissp operational security
- operational security cissp
- meaning of operations security cissp
- operation security cissc
- articles on operations security for cissp