CISSP 2015 Update: Security Operations
The CISSP 2015 Update brings new viewpoints on the key domains covered in this certification. The CISSP is already one of the broadest of all certs in that the amount of information it covers in different fields is staggering. However, breaking it down into its component domains or fields can help to chop at it bit by bit. With the new updates, each domain is a bit more streamlined – a bit easier to manage in the overall picture – and becomes easier to understand.
We will be diving into each domain over the course of the coming weeks, to see what you need to know if you have just started studying for the CISSP. Right off the bat we can say that, with very few exceptions, the old domains are gone. That’s not to say the information isn’t there anymore, its just that the perspectives on that information have shifted. The CISSP certification has always been a managerial-level certification – understanding is required for a lot of topics across a wide range of requirements. The new update zeroes in on that concept, making it easier to look at things from particular scenarios with a bird’s eye view.
With that in mind, let’s take a look at our sixth domain: Security Operations (Foundational Concepts, Investigations, Incident Management, Disaster Recovery)
Chain of Custody
Evidence gathering is a vital step of any investigation, and especially so when pressing or defending against charges. In order to make sure that evidence is usable in a court of law, it must follow the chain of custody – a specific series of documented events that show that the evidence gathered, whether electronic or physical, has not been tampered with, and is suitable for use. If any step is not followed precisely, or if the documentation is incomplete, it will be deemed untrustworthy and dismissed.
Understanding Requirements for Investigation Types
When dealing with physical crimes, gathering evidence after the fact is relatively straightforward – you look for evidence left by the suspect during and after the event to prove guilt or innocence. This means making sure that the location where the event took place is left untouched for the authorities to perform forensics on it. This doesn’t mean however that you do not gather information and create defenses ahead of time: security cameras, ID checkpoints, physical and digital locks all count when trying to prove that your organization performed its due diligence to protect against the event in question.
Electronic crimes on the other hand require A LOT of setup beforehand to be able to prove that the event occurred, how it happened, and where it came from. This means having traffic regularly sniffed and logged, setting benchmarks to be able to see if there was anything unusual going on on the network, and storing data in a secure location that cannot be easily damaged or destroyed.
Documenting everything may seem like a hassle and a waste of space that could be used in other, more immediate projects. However, every organization runs into situations where documentation can end up helping them sort out massive issues: when an employee leaves the company and there is no time for a knowledge transfer, when there is an investigation open on the organization, when there is a new employee looking for an easy way to learn the environment, or when a higher up wants an explanation about where a particular project is and how much further it has to go.
In other cases however, the documentation can help to create something more than the sum of its parts, case in point: Big Data. Documenting what each user does when presented with a specific situation may not seem like much by itself, but ramp that up several thousand times and patterns begin to emerge. Whether used by an organization looking to manage profits, or by one trying to prevent attacks, the same basic process remains: document everything.
Tapes, hard disks, optical media, holographic storage – they all fill a vital role: keep data safe. In order to make sure that backups are kept secure, they must be able to be at hand quickly but only to authorized users. Whether this means storing it in a vault, or offsite, or even with a partner organization, the media needs to remain safe. On top of this, it is also required to be certain that only AUTHORIZED media is used to hold company data that is leaving the facility. The same media types that can be used to save the organization when something bad happens can also be used to cause a problem in the first place.
There is an old saying that you learn more by failing than you do by succeeding. Incident response is certainly an aspect that benefits from that line or reasoning, since there is a very specific path that needs to be followed when an incident has occurred
1- Detect the Incident
2- Initial Response to the Incident
3- Mitigation Required for the Incident
4- Report the Incident
5- Post-Incident Recovery
6- Remediation Regarding the Incident
7- Lessons Learned from the Incident
On top of this basic structure, it is important for admins to know when particular situations require slightly different tactics. For example, some attacks require that the system be retired and rebuilt or swapped out as quickly as possible, while others require getting a sample of the attacking software as well as a memory dump of the system.
Patch and Vulnerability Management
Not every environment can afford to fix every vulnerability or apply every patch as soon as it arrives. Patches can have unintended consequences, or break functions that the organization depends on on a daily basis. Therefore, testing out patches before applying them and being aware of vulnerabilities as soon as they are discovered are more important than applying potential fixes as soon as they are released. Once a patch is tested and approved however, it is necessary to be able to not only push the patch out to all users immediately, but to know which systems have not yet taken the fix.
Change is constant, but knowing why a change took place is vital. If a major update is applied without scheduling downtime and it then causes a massive loss in services, that could potentially mean someone’s job. Therefore, even though it may take a lot of extra time and paperwork, going through the motions on managing changes and having them not only approved, but having all possible parties notified of them happening beforehand can save a lot of hassle down the road.
But if a situation does occur where an update DOES mess up a vital system, it is important to be able to bring it back up quickly, regardless if it is a single system or an entire building. Having a disaster recovery in plan and tested out is absolutely required of organizations beyond a certain size and complexity. In certain situations, it may very well be faster to rebuild operations from scratch, but that can only be known for sure by performing an investigation and then exercises based on the disaster recovery plan.
[download]Click Here to Download the Full CISSP Update eBook![/download]