This course within the CISM Domains learning path looks at risk management and the resources that can be used in order to avoid and tackle risk in an organization. We'll start by looking at risk identification and risk analysis, which is the quantification and comparison of risks. Then we look at a variety of risk management frameworks in use by companies today.
Then we look at the constraints that can hamper your efforts to manage risk, focusing on working with third parties and the technical and human aspects to take into consideration when doing so.
- Understand how an organization can identify and analyze risk
- Learn the constraints to risk management
This course is intended for anyone preparing for the Certified Information Security Management exam or anyone who is simply interested in improving their knowledge of information security governance.
Before taking this course, we recommend taking the CISM Foundations learning path first.
Now we move into section 39, continuing our discussion of domain two, Information Risk Management, and we talk about various constraints that hurt. So let's look at third-party services. Now, as a security manager within the enterprise we need to look at various things that come with using third-party services. This is a contract-driven kind of service, and so we manage through the things that we have built into the contract to ensure that the deliverables, be they services or products, are being delivered on time and are accurate and they're satisfying the requirements. This will include proper controls and processes to facilitate the outsourcing in the first place.
We will have to do project management to ensure that risk is being dealt with properly, and that will mean crafting the various requirements within the contracts themselves. We have to require that risk assessment is being performed for the outsourced process and for the products that are being delivered by that outsource.
As with all contracting processes we will need to perform our due diligence and carry it out prior to the contract signing and then throughout the contract's performance, to ensure that all requirements are being met in a timely manner. There may be the need for doing daily risk management of outsourced processes to ensure that these things are being met.
Periodically we will need to do a new risk assessment when any sort of material changes occur in the contracted relationship, and then ensuring that throughout proper processes are followed, and that when it comes time to end the relationship that proper disposal and disconnection types of processes are properly followed and also in a timely manner.
So we have our risk assessment and the controls and definitions on the organizations. And then when the disconnection is being done we have to be sure that both sides, the part that is being disconnected and our end of the connection, are terminated properly and all disposal practices, including return of information, return of various assets that might have been acquired during the relationship, are returned or disposed of properly.
Now, when we do outsourcing, the number of risk areas grows to three, and this includes our business as always, the process itself, and the third-party with whom we are contracting for the service or product to be delivered. Now, the contracts, of course, obviously have to address any sort of regulatory requirement. And there typically is going to be some form of that in almost any contract. Clearly they must be properly defined and included.
Now, the functions that are beyond the organization's core expertise, we need to be sure we understand what that is, even if generally, so that we know that what we're doing is proper and what we're receiving by way of service or product properly satisfies that. What we do is manage and what we continue to do is what we typically consider core, what we do best.
Exit strategy must also be considered in any contracting operation that we're going to perform. What we look at is how the process will continue if we are going to change from a third-party to another third-party or internalize the process that up until now has been contracted to an outsource.
One of the things we have to recognize at the very beginning of these processes there is a legal accountability that we cannot outsource. We will always be responsible since we are the part who is seeking the services of our outsource. We will always be ultimately accountable for what happens in the relationship and any regulatory failures that may occur during it. The providers may not share details of their protection mechanisms because that may expose them to various forms of failures or exploitation.
In our service level agreements and other requirements we need to be sure that we set clear boundaries, clear expectations, and how those will be met. For example, we may require specific skills or specific audits from time to time like a SOC two or 27001 certification of our outsource and be provided evidence of such.
Now, in a regulated industry, there may be reporting requirements for security events. Certainly in areas of critical infrastructure this is true. That means that our contract language must reflect these requirements because these requirements may in fact be levied on our shoulders, and they have to be fulfilled by information provided by our third-party services. But accountability rests with us.
We have to be sure that we are contracting with financially viable providers. This can be demonstrated by a SOC one along with the security assurance that we get from the SOC two. This means that we may also have to require that business continuity measures and even disaster recovery plans are present, to ensure that we have accounted for what happens when we lose critical providers during this relationship.
We have to be sure that we also address various kinds of indemnity. We have the right to software code in the event of a default. These are software escrow types of clauses that go into contracts. We have requirements that provide remains timely with compliance, such as in healthcare with HIPAA or in other regulated industries as with PCI types of requirements.
We can specify right to audit so that we can examine for ourselves objective evidence to show that they are in fact compliant or not and then take appropriate action. We should put in that we have the right to assess the skills of their employees to ensure that all things being brought to bear to fulfill the contract requirements are in fact being properly addressed. And if there's any advance notice that a provider's resources are about to be changed that we specify the various conditions and timeframes associated with that advance notice.
Now, in any contracting relationship, both parties have various responsibilities, but one party will typically have legal accountability for what goes on. Part of any contracted relationship will involve evaluation of compliance relative to other organizations in the same industry. In other words, a peer comparison.
The management must determine that non-compliance and whatever constitutes that is unacceptable, and that if there is non-compliance that it is fully understood and explained, justified and accounted for. There may be fines in the event that there is a finding of non-compliance.
We also may find that enforcement may be nonexistent from the agency, but we ourselves still remain accountable to ensure that all is being done that is reasonable to ensure that the compliance is being accomplished. We will have to support legal standards that are related to privacy in particular, the collection or handling of audit records for records retention purposes and performance of daily tasks.
We have to be sure that various kinds of retention, for example, with email or other kinds of communications media are being handled, that a relationship is established through the contract to handle incident investigation and resolution. And then we have to specify the requirement for cooperation with legal authorities.
We may have to make specifications for how human resources and legal will need to be discussed with before any sort of action along these lines is taken, to make sure that human relations and any legal questions are dealt with and properly answered. Throughout this, there may have to be consideration given to physical and environmental factors. Now, in keeping with our practice of defense in-depth, physical and environmental factors, of course, must come into play.
Now, physical security is mainly concerned with the development and management of controls to protect physical assets, workplaces, and personnel. There is significant intersection between information security and physical security.
Information security relies on physical security controls for the protection of information processing and communications equipment. And while some of this equipment resides in data centers, some also resides in workplaces where organizations personnel are present. These common controls make workplace safety a very close relative to information security.
The levels of security that are established are oftentimes set on the same basis as the information security factors. Criticality of systems, the sensitivity of the information being processed, the significance or criticality of the applications under consideration, the cost of replacement of the hardware, and the availability of any backup equipment.
Now, physical control of access should depend on sensitivity and information, and it should be based on the same sort of access controlled such as least privilege or minimum necessary. Now, the location within a facility is also quite important. For example, you're not going to put servers in a room that might be prone to flooding. You have to always consider temperature and humidity settings to ensure that the environment controls around the system are being maintained properly. And any physical media, such as magnetic tapes, diskettes or other sorts, are being stored properly also with environmental control.
We should, of course, make certain that physical locking devices are available for those systems that are better protected by such physical measures as these. Any devices that are used for storage should have encryption to process and mitigate the risk of theft or breaches by having data in human readable form rather than employing the encryption to protect against it.
Implementing a clean desk policy is a good idea and it should be done in a reasonable way to reflect the moveability and theft potential for information in some sort of movable or hard copy form. If we have the opportunity knowing that risk avoidance is one of our options, we should avoid selecting natural disaster-prone regions for facilities, or if this is not an option, what it would take to compensate for them and provide for better physical security in such areas. A something less than hard skill type of concern would be cultural and regional variances if we work for a multi-national type of firm. We have to be aware of the various laws and cultural differences from one region to another and what impact they may have on our operations or recovery efforts.
An inappropriate act in one culture may be acceptable elsewhere. It may be unacceptable everywhere, but again, we need to be aware of differences as we cross boundaries or move from one region to another. Different companies will have different laws based on where they are, and they vary based on the type of information concerned, such as personally identifiable protected health information, proprietary or trade secret.
So we are going to need to work with our legal advice and our human resources advice to ensure that we identify these potential issues as early in the cycle as possible and come up with viable solutions. As always, we must consider the logistics. And logistics issues will affect things like meetings, appointments, development, recurring procedures, managing workloads across various workforce members in different regions of the world, and the communications methods that are going to be employed.
Now, online systems can help with logistics but like everything else, these are not a cure-all. So we're going to need to conduct some logistics training on how it will be done for both virtual and physical movement of information, conduct of meetings and so forth.
So here we stop at the end of the next section. We will pause here shortly, and then we will take up our next chapter, which is section 40, Information Risk Management, the Action Plan.
Mr. Leo has been in Information System for 38 years, and an Information Security professional for over 36 years. He has worked internationally as a Systems Analyst/Engineer, and as a Security and Privacy Consultant. His past employers include IBM, St. Luke’s Episcopal Hospital, Computer Sciences Corporation, and Rockwell International. A NASA contractor for 22 years, from 1998 to 2002 he was Director of Security Engineering and Chief Security Architect for Mission Control at the Johnson Space Center. From 2002 to 2006 Mr. Leo was the Director of Information Systems, and Chief Information Security Officer for the Managed Care Division of the University of Texas Medical Branch in Galveston, Texas.
Upon attaining his CISSP license in 1997, Mr. Leo joined ISC2 (a professional role) as Chairman of the Curriculum Development Committee, and served in this role until 2004. During this time, he formulated and directed the effort that produced what became and remains the standard curriculum used to train CISSP candidates worldwide. He has maintained his professional standards as a professional educator and has since trained and certified nearly 8500 CISSP candidates since 1998, and nearly 2500 in HIPAA compliance certification since 2004. Mr. leo is an ISC2 Certified Instructor.