1. Home
  2. Training Library
  3. CISSP: Domain 1 - Security and Risk Management - Module 4

Integrate Security Risk Consideration into Acquisitions Strategy and Practice

The course is part of this learning path

Preparation for the (ISC)² CISSP Certification (Preview)
course-steps 16 certification 4 description 1
play-arrow
Integrate Security Risk Consideration into Acquisitions Strategy and Practice
Overview
DifficultyAdvanced
Duration33m
Students2
Ratings
5/5
star star star star star

Description

Course Description

This course concludes the final module of Domain 1 of the CISSP, covering security and risk management. It covers topics that include the identification of threats, diagramming potential attacks, performing reduction analysis, and also examines technologies and processes to remediate the threats

Learning Objectives

The objectives of this course are to provide you with and understanding of:

  • Threat modeling and how to apply these modes within your environment
  • How to integrate security risk considerations into acquisitions strategy and practice
  • How to establish and manage security education, training, and awareness within your organization

Intended Audience

This course is designed for those looking to take the most in-demand information security professional certification currently available, the CISSP.

Prerequisites

Any experience relating to information security would be advantageous, but not essential.  All topics discussed are thoroughly explained and presented in a way allowing the information to be absorbed by everyone, regardless of experience within the security field.

Feedback

If you have thoughts or suggestions for this course, please contact Cloud Academy at support@cloudacademy.com.

Transcript

Now we're going to go into section 11 and we're going to integrate security risk considerations, into our practices surrounding acquisition. So in this section, we're going to look at hardware, software and services acquisition, Regular Third-Party Assessments, setting Minimum Security Requirements and then how this all develops into the combination of Security Level Requirements, security Service Level Agreements and other documents so that we can measure how good of a job we've done here. 

So when it comes to the acquisition of hardware, software and services, one of the very first steps we must take, is we need to develop a common nomenclature and taxonomy for cyber security conditions and attributes that we must obtain through all of our acquisition activities, whether they're a product of some kind or a service of some kind. We need to institute baseline security requirements as a condition of contract, award and continuous. When we set these conditions we need to be sure that the party that we're going to award the contract to or that we are going to buy the product from understands that these are mandatory requirements in order to get our business. And this is us dealing effectively with our supply chain and increasingly important aspect of our overall security requirements and programs. We have to specify the training requirements, for both initial and ongoing activities as part of that contract award and continuous. And we need to extract from all of this an acquisition cyber risk management strategy to be employed throughout all of our acquisition activities. 

So as we progress into the acquisition process, another thing we need to consider is a requirement to purchase from verified authentic sources, are they authorized resellers or other trusted sources whenever feasible or that the candidates wanting to provide us the hardware or software products or services that we're seeking as suitable compensating process, when such trusted sources are not readily available. Through the vehicle of these contracts and these activities we need to increase the organizational accountability, for cyber risk management on the part of the organization to whom we're considering awarding this business. In cases of critical suppliers, we may decide to take a further step and include a system security audit as justified for the award. So rather than taking their word for it, we're actually going to see for ourselves. And this of course may be done by our own staff or by a third party we hire for this purpose. 

For all requirements and purchases that can adversely affect the organization security and in today's world that would be just about everything. We need to perform our due care and our due diligence always but for those situations of critical supplier consideration, we need to extend that further so that it is commensurate with the associated risks and values of the work or product involved. In these relationships we need to give very strong consideration to the periodic assessment of the activities and the vendor that supplies them. This could include things like onsite assessments, done on a periodic basis, it would involve document exchange and review and that in itself would involve walking through a process and the policy that governs it. 

Now in all of these cases, we can again employ our own staff or a third party. One of the things that we will put together during the course of this process will be a Service Level Agreement. Now the Service Level Agreement is what specifies the conditions, the performance, the deliverables that we can expect from the party to whom we award this piece of business. It defines the agreed upon levels of performance and the compensation or penalty that the provider and the customer are going to engage in. So that if the provider fails to perform, it could be anything from, a penalizing effect on the contract award or fee or even consideration of cancellation and award to another party. 

Comparing that to assurance, the Service Level Agreement is the contract for service that we then depend upon for the contractor to deliver to but the assurance that we may want can only come through our actively inspecting, reviewing and assessing their actual performance so that we know that what they're doing has every potential to deliver on exactly what the Service Level Agreement has specified that you both have signed. Within the Service Level Agreement we need to specify Minimum Security Requirements. To do this, we need to begin with an understanding of what the project will deliver so that we know exactly what we should expect to come out of it. And that means in virtually all respects, we should know precisely what to expect. 

As we build this, we need to set the requirements and metrics to establish the baselines that the provider will need and any accountability or responsibility that we as the customer receiving the benefit must respond to as well. We have to review the perspective mitigation and compensating actions that our contractor will propose to take or is taking. And then we have to have a way of course of evaluating all the possible and probable risks to determine potential outcomes with regard to the effectiveness of the mitigation and compensating actions. So in the course of negotiating any of these acquisition activities we're going to undertake, there's never a time that we should assume anytime we need something, we want something, we should never assume that we know what they're going to say we should always ask. 

We should always make plain what our expectations and what our tolerances are going to be to make sure that the discussions and negotiations are open and transparent. If we ourselves are the ones discussing what is to be delivered as these potential supplier of something, we should always involve the users from the start so that that potential population that we'll be using the product or service that we're going to be delivering can tell us what they expect, what they need and help us work towards delivering that in a better way. And this, of course is going to include cyber security attributes as well. We need to define and agree on the scope of the project to ensure that everyone knows what has to be delivered, by when and what the boundaries and constraints are going to be so there's a common understanding. 

As we look at the requirements being stated, whether they're ours being given to a potential supplier or these are the ones that we're being asked to meet. Both parties must review the requirements being stated and note that they are specific, that they are realistic and measurable and that we have metrics associated appropriately with each of these. Obviously, if there's ever any doubt about anything, being discussed, we need to discuss it and remove that doubt. Make sure that there is clarity and a common understanding between the parties. And when this is all completed, there should be a very clear, very concise and very thorough requirements document, including those requirements that may have variants as part of them, that we document all this and that if we are the customer we have them, if we are delivering something for a customer that we and they both agree to all the various pieces that are in this. Some rules or some guidelines, for successful requirements gathering. Because the better job we do at gathering the requirements, the better job we can do at understanding them, having full clarity and knowing exactly what we will need to do to deliver on them. Always repeat back what has been said to you so that your measure of understanding can be gauged by the persons or parties that have made the statement. 

When it comes to dealing with cyber security in the context of risk management, we should speak about results, we should speak about conditions, we should speak about concerns, rather than talking about technology before we get around to a full understanding of what the requirements are. Getting their requirements agreed upon as we've said, is extremely important so that the stakeholders will know exactly what to expect by when and all the other details that surround it. It could be that a prototype would be a useful thing to create to demonstrate not only capability but ensure that their understanding, their expectations, are indeed in alignment with what is going to be delivered. So to examine in detail, let's look at Service Level Requirements. Now as one of the guiding documents in the course of acquiring these products or services, the Service Level Requirements documents, will contain the requirements for this, from the client's viewpoint. 

For example, Service Level Standards need to be defined as precisely as possible and with the potential of a plus or minus X amount of variants. We need to define the service level measurement methods and minimums so that everybody understands what the sources of the measurements will be and that they can be agreed upon before actual work or service delivery begins. You can never be too clear about who is responsible for what, whether it's either party or a shared responsibility and what the specifics are of the sharing. If there are specific customer groups that have unique requirements that will be part of this, we need to set out exactly what makes them unique and go through the same process for them so that their expectations are known and that their requirements are understood so that our delivery will be properly aligned with their expectations. If there are differing priorities, if there are different conditions that specify what priority will be given to either a customer group or a particular delivery, those need to be called out so that criteria can be defined and then met. If there is anything special beyond, simply the normal services and exceptions handling policy, for example that needs to be called out as clearly as we can. If there is going to be the possibility of the need for a forensic examination of the material of the system, of an incident that should probably be defined at the earliest possible point, incident handling would be part of that particular element and the associated responsibilities and division of labor needs to be specified as to who will do what, what information will be required from which party to ensure that this is laid out as clearly as can be before the incidents actually occur. And then like all contracts, there needs to be clause in there to define what the dispute resolution process will be. 

From this and the other negotiations that have been conducted this far, we will put together the Service Level Agreement and when all the various pieces have been compiled, edited, agreed to it's committed to the document form, like any contract would be and then it's signed off by both the supplier and by the customer. It should be said that the clearer this can be, the more precise it can be. Even if there is some variants possible in any of the metrics, all of that needs to be called out with as much clarity as can be given to it and making sure that both parties are of the same mind, when it comes to these things. Makes for an easier transition into the relationship and ideally should make working together or dispute resolution easier as well. Then from all of this after the service or product has been supplied or as it is being supplied, a service level report, should be generated by the provider to show what they have done. And the customers should have their own ways and means of managing and measuring the relationship. And then based on a comparison between those two things, it should be able to determine whether or not it has received all that it believes it should based on its understanding of the SLA and when there is a discrepancy a method by which that discrepancy can be resolved bringing it to an alignment with the understanding and agreement of both parties so that the relationship can continue with no further dispute or to help them resolve any sort of exceptional events that may not have been called out as precisely as might now be possible, it is very difficult to call out every possible occurrence and there's usually an exception handling process to deal with.

About the Author

Students413
Courses16
Learning paths1

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.

Covered Topics