The course is part of this learning path
This course covers CSSLP Domain 8:2 and how to source suppliers in a way that mitigates risk and maintains security.
- Understand how to source suppliers in a way that mitigates risk and maintains security
This course is intended for anyone looking to develop secure software as well as those studying for the CSSLP certification.
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.
Now, as I mentioned before, in supply chains there are frequently multiple contractors involved in the various hierarchies. The way that it appears to see it on paper would be that there's typically a prime, and subcontractors are branching off of that, supporting the prime's effort. The prime contractor would typically be the integrator of all the various pieces.
Even though the acquirer may not know about all the subcontractors or have any input to that process, they need to be fully informed about the extent and depth of the arrangements. Because again, if you are the acquirer this is your risk that you're attempting to manage and you need to understand how it's going to be arranged and how the work will be delegated so that you can manage the various schedules that you yourself are trying to meet, and make sure that they do the same. Your primary contact will be the prime, but it has to flow from them to the others. And so their discourse with you will make sure of that.
Elements disclosed must also in include, are there anything transferred to agents outside the country or to offshore? That can be a non-issue for some but it can be a very big issue for others. And you have to consider that in light of what regulatory or other prohibitions may be present in this process.
Now it goes without saying, but we're going to make sure that we say it, that security must be integrated at all levels, at all stages with the product. And that will include the contract, things that derive from it, and the process of moving things between the various supply chain members. We're going to have to investigate security, what's needed in the program, and very likely make some trade offs with regard to what that constitutes.
We can look at it from the standpoint of how we are going to cope with it. For example, we can think of the project as strategic improvements, or we can make it focus on the maintenance of current operations. So this is an early stage decision. And what it really means is we can stay with what we have and keep it running, or we can choose to advance strategically with a magnitude of ordered improvements. Now, what this really means is we're taking no risk of changing, but we're taking a great deal of risk by not changing. If we change, if we make the decision to change then of course risk comes with that as well because it's a risk to change. Just like it's a risk to stay the same.
What are the risk levels? Well, this is something relative and somewhat rather subjective. High is not always to be avoided but low is not always preferable. We need to balance the risks that we confront against the opportunities that are associated with this effort. One risk that we can deal with is, making sure that things are adequately resourced to cope with whatever the choice might be. We have to think about the interaction between the contract teams. Changing suppliers can have very complicating effects. It disrupts the supply chain and its integrity to do that, even if it becomes absolutely necessary.
Then of course, there's the element of opportunity costs, which is always what do you get by making this decision at the same time you get you give up. So we need to think about that as well. The contract itself has been written to have high integrity and to be of course acceptable in all the different places around the world where it may have to come into play. And so it has to be vetted for what it contains and the integrity of that finished contract has to be sustained. So we going to talk about these points.
Description of the manner and criteria used to judge contract performance. Payment to the contractors is the direct consequence of that. Description of the manner and criteria used to judge the product quality and integrity. We like what they've done. And as far as quality and integrity goes, is it as good as we want? There are many different ways to deliver it, but is it at the level that we want it to be delivered at specified in the contract? Definitions of any compliance requirements that must be met in the course, that has to play a role in virtually every software contract these days.
We have mediation and dispute resolution when we make decisions that contravene what we may have decided in the past, and they're always going to have to generate a corrective action. Then we get into the delegation and performance of those corrective actions. Now, as we often say, proper communication, and in this case due to the software involved, good configuration management of the contract, assures that all parties remain in sync regarding the work's progress. Ultimately, sound management, controlling communications, will result in reductions in supply chain risk and improvements in deliverables quality. Controls for third party of suppliers include things like audits and reviews.
Now, in this regard, the essential aim of this is to ensure that contract requirements are understood, clearly communicated, and that they are being met in the prime contractors scope of work, as well as being passed by the prime, filtering down through the supply chain, to the subcontractors transferring their products up to the prime. So it means we have to have vendor controls to ensure integrity of all the software artifacts as they move up and down through the supply chain entities.
These controls are going to ensure that the integrity of the product baseline is maintained throughout the process. And that will include both the baseline and the repositories, two different elements, related, but different. It also addresses any authorized changes to any of these elements. And these will then propagate through the supply chain to ensure that the process and baseline remain consistent The controls themselves refer to a set of standards and technical items attached to or produced from the contract, and maintained in a formal authorized baseline.
Ideally, we should be able to specify the controls to be used even if at a general level at contract out so. It should be understood from the very beginning of the let contract with the supplier that these are the control we're going to use. The code controls are going to be under configuration control as will the contract to ensure that the performance and results are consistent and that they're done against understood and accepted criteria with understood and accepted metrics. In other words, we know, we all know what they are and we all know how they will be measured and what those measurements represent.
Typically, we're going to have the controls applied in three different contexts. One will be the unit testing. Now, remember we have spoken about this subject many times throughout this course. Here, we're talking about in the context of how things move between one element of the supply chain and another. So we have the unit testing, making sure that the model has the integrity it is supposed to have before it moves to the next step, to the next contractor.
We have integration testing, which at some contractors, must be performed so that they know that what they got is what they were supposed to have gotten and that when they bring them together, they perform again as expected. And we have qualification testing. This validates that completion has in fact met all of the performance and technical criteria so that what we have said we have executed, we actually have, and it meets all the standards.
Now, unlike the managed services closed-end nature of a project, managed services arrangements require the open-ended approach and continuous set of performance criteria for monitoring to ensure contractual integrity. Now, normally of the contract document specifies a detailed set of deliverables, or in this case potentially services and discreet products, along with their various minimums and standards by which they will be measured. And this will include reporting. These elements frequently are translated into language in the service level agreement which then serves as a service baseline. Itemizing things like, what is to be performed or delivered and the metric by which it will be measured.
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.