The transitive trust as we talked about will determine whether you can extend that trust from A to B and say, "Okay, because A and B are both trusting each other. Let's allow the relationship that A and C have to effectively allow C and B to trust each other without creating a direct trust connection between them." This is the nature of the transitive trust. And so when we think about trust relationships, and we think about how we built an architect access control, we have to think about the nature of connectivity, think about the nature of trust, and we have to think about the nature of transitivity because if we're not fully thinking through the logic of what a transitive trust may imply, we may grant access to users in domains C. Remember, A and C are connected together. They're kind of like this, and there's a trust relationship between the two right here. If A and C are connected, and A and B are connected, but B and C do not connect together directly over here this way, but we give C the ability to walk through A and come over here to B because of transitive trusts, then B and C are talking to each other. We may not have wanted users and C to interact with resources over here in domain B. That may not have been our design. It may not have been our focal point in our thought process. But because of the nature of transitivity, that may have occurred. The SCCP needs to be aware of that, needs to understand that, needs to account for that and understand that you may need to go in and take steps to prevent that from happening if that's not one of the outcomes you were looking for. Or if you indeed did want B and C to talk to each other, interact and trust each other and to do so because of the transitive nature of trusts, you would need to ensure that the trust is set up in a way that will become transitive. So you would need to make sure you're aware of that, and you would take steps to design the trust relationships using the proper tools and the proper choice of trusts in order to do so. You will create a series of one-way trust that may or may not be transitive, in other words. And you would have to understand that and take advantage of that by default and by design. In a Windows Active Directory-based architecture, all hierarchical domains from parent to child automatically have two-way trust involved with them, and those domains trust all the other domains that are trusted by the parent, so there's automatic transitivity. We need to know that and be aware of that as part of our management of that design or that particular architecture. So we want to be thinking about these things as we talk about intranetwork architectures, as we talk about trust relationships. It's very important for us to think about the implications of the design decisions that others may make, they we're asked to manage and to work with, but also to understand the implications, not just of what somebody else may choose as a design element that they implement but decisions we make as managers, as practitioners, as people that have our hands on the systems every day. We may choose to change the nature of trust. And, in so doing, perhaps modify the architecture of the trust relationships without proper knowledge, without proper understanding, we may choose incorrectly. And if we choose poorly, we may or may not be accountable for the outcomes that we were looking for because we may have made a bad choice and may have different outcomes than we were expecting, and that can be a problem. So as we wrap up our conversations in this section and think about what we're doing with trust relationships and think about the nature of trust, it's very important for us to stop and pause and really ponder for just a moment, as we look at this in the setting of the real world, what the relationships and the interconnections between systems may be and to truly understand them, to truly make sure we know whether they are transitive or non-transitive, whether they are one-way, two-way, things of that nature before we just operate the system and decide that we will accept on the surface seeming realities, when in fact, the reality may be very different from a design perspective. So, the general thought process would be always trust what you see but verify what you see. We talk about trust but verify, meaning, look at the documentation. Look at the information that the system architect may have left as part of the documentation and the build guidance around how this should be implemented. Validate what's going on. Look at the outcome of the last set of audits. Make sure that all of this information is accurate. Make sure you're supposed to have transitive trust, and if you don't, ask the obvious question, why not? If you do, make sure that they're operating correctly. Can a user in domains C really interact with users and resources in domain B and vice versa. Can the two effectively cross-pollinate one another through A because A is held in common to both? And if that works great, you've validated the assumptions. You've documented that they still hold true, and you're able to operate the system effectively as a result. But if you checked out and find out that's not the case, that's equally important, for different reasons of course, but equally important because now you know that the assumptions in the documentation are wrong. And you have to step back and figure out why. It will keep coming back to this idea of why this root cause analysis that we often speak about in many of these areas throughout our discussions, if as a security practitioner, as a security professional, you can get to a root cause. You can understand why. You can figure out why the transitive nature of trust is or is not in place and working correctly. You'll solve a lot of the dilemmas, a lot of the concerns and problems that are underlying the risks that are in the system, the threats, the vulnerabilities that we see. And you'll be able to manage the systems, make them more secure and, ultimately, take better advantage of the tools that are being given to do so in the proper way. This becomes a very important focal point for us. It's a building block. A standard solution of thought process that is, we go out and we implement it. We manage and we are focused on all the elements of the system that we come back to time and again because if we get things like setting up trust relationships right, if we get things right, like looking at that and getting it on an ongoing basis from a accountability, from a usability, a reliability, a traceability, just all those different ability perspectives that we can think of. Audit ability, transaction ability, we can look at all those things. If we can validate that everything is built correctly, we're going to be able to operate the system with a level of confidence, a level of knowledge and a level of assurance that allows us to focus on the real concerns because we're not constantly worrying about whether the baseline things, the bedrock things that form the foundation are being done correctly. And this is important for us as we begin our conversations. Not just in Access Control, as we continue our conversations in this area, not just in identity management but more broadly in risk and system architecture and network and telecommunications capabilities and cryptography. And any of the areas, in any of the knowledge areas associated with the SCCP and even more broadly, just in operating systems generically in the real world, out beyond our theoretical and practical conversations here in the classroom environment becomes critical for the security professional and security practitioner to understand the reasons why things work the way they do. If you're able to do that, able to understand, able to based on that assumption, based on that understanding and based on that validated knowledge, make good choices, you're always going to make good choices for the most part. But in general, you may make them for the wrong reasons or without full knowledge, and that may turn out to be not so good, unless we know exactly what's going on. And because we want to make good choices, because we want to try to understand our systems and do the right thing, it's very, very important. I would say it's vital for all of us to understand the basics, to understand the concepts inherent in these architectures. And once we've done that, once we've mastered that knowledge and most importantly, we've taken and apply that knowledge, validated it going forward. So we understand that, yes indeed, we do have a two-way transitive trust between A and B and A and C, and as a result, C will trust B even though there's no direct connection. That's a very critical, very important piece of information for us to carry forward, as we begin to work with users in domains C in our example and create a single sign on environment for them to authenticate and be able to access resources in domain B. A user, for instance, should be able to print to a printer in domain B, in my example, if there are two-way transitive trusts involved between A, B and C. And, as a result of that, we should be able to set that up very easily, knowing that it will work. But having knowledge of the system, knowing that it's working the right way, is the key to success. So to wrap up our discussions in this area, just make sure you're comfortable. The general ideas of the inner network designs, the architectures we've discussed, as well as the different kind of trust relationships we have, one-way, two-way and transitive trusts, making sure we understand what an Internet and Intranet and extranet and DMZ are. And by mastering those definitions and those concepts, you'll be well on your way to understanding all the things you need to know to be successful.
