the NGOs. This demonstrates several types of trust relationships.
One-way trust relationships exist where organization A trusts its users and trusts the users of organization B, but while B trusts its own people as users, it does not fully trust the users in organization A and must limit their access to B's systems and information resources.
Two-way trust relationships exist when both organizations have the same level of trust in all of the users in the other's domain. This does not have to be as high a level of trust as what they repose in their own people but just a symmetric or matching degree of trust.
Transitive trust relationships happen when organization A trusts organization B, organization B trusts C, and then in effect organization A trusts C.
Note how transitive relationships establish a chain of trust, with the trust anchor being the one at the root or start of that set of relationships. In the previous example, C has in effect delegated its trust authority to B, and B then provides its assurance of trustworthiness to A. As you'll see in a moment, these third-party connections can provide two different approaches to authentication and trustworthiness, known as hierarchical or web trust relationships.
As the complexity of the relationships between organizations, their systems and platforms, and the domains of user subjects (and objects) associated with those platforms increase, trust relationships can start to matrix together sometimes in convoluted ways. This could quickly overwhelm efforts by each organization's systems administrators to manage locally. Federated approaches to identity and access management are not by themselves simple, but they can be easier to manage, especially when the social or organizational context and trust relationships are straightforward. Federated systems also allow for much quicker, cleaner disconnects, such as when the relief operation ends or when one agency's systems are found to be less secure than can be tolerated by others in the federation.
Solutions to situations like this might contain elements of the following:
Advanced firewall technologies
Gateways and proxies as interface control points
VLANs and restricted VLANs
Public access zones
Extranets for data center access
Extensive Authentication Protocol (EAP)
Using allowed list management to restrict execution of applications, with application visibility and control functions to monitor and enforce these policies
Multifactor authentication of subjects
Behavior and posture monitoring, such as enforcing device update status and using remediation or quarantine to enforce updates or limit access
Network segmentation to include zero trust architectures where required
Let's take a closer look at some of these trust architectures and frameworks.
Extranet
An extranet is a virtual extension to an organization's intranet (internal LAN) system, which allows outside organizations to have a greater degree of collaboration, information sharing, and use of information and systems of both organizations. For example, a parts wholesaler might use an extranet to share wholesale catalogs, or filtered portions thereof, with specific sets of key customers or suppliers. Extranets typically look to provide application-layer shared access and may do this as part of a service-oriented architecture (SOA) approach. Extranets may also see extensive use of electronic data interchange (EDI) protocols, which facilitate automated exchange of substantial volumes of information such as parts lists, inventories, or catalogs. Prior to the widespread adoption of VPN technologies, organizations needed significant investment in additional hardware, network systems, software, and personnel to design, deploy, maintain, and keep their extranets secure. In many industries, the use of industry-focused applications provided as a service (SaaS or PaaS cloud models, for example) can take on much of the implementation and support burden of a traditional extranet. As with any network access, careful attention to identity management and access control is a must!
Note that the prefix extra usually means “outside of,” or beyond a known boundary or perimeter. In some respects, having a demilitarized zone (DMZ) as part of your network provides this boundary point. If external users still must be defined in your access control systems and provide valid credentials to gain access, then that DMZ (or a portion thereof) is an extranet. If the general web-crawling public can access it, then it's a public-facing DMZ. In either case, an extranet or a DMZ is usually logical and physical segments of your organizational internet, usually isolated by routers from other segments (such as those inside the DMZ).
As an aside, compare these concepts with that of an intranet, which is an internet segment logically restricted to users who are members of the organization (that is, insiders).
Intranets, like extranets, are often part of VPN systems and can provide secure infrastructures for collaboration and information sharing for authorized users.
Third-Party Connections
Third-party trust relationships usually involve three parties (people or organizations): a content user, a content owner, and a certifying authority that can attest that the content in question being sent by the content owner to the content user is authentic. Note that the certificate authority has no real role in verifying that the content is what the content user needs to accomplish their purpose or objective—only that the content the user receives is exactly and completely what the content owner provided. Identity management uses this concept in somewhat different ways than access control, encryption, digital signature, and other information security systems usually do, as a quick look will reveal.
During identity proofing (the first step in establishing a new identity for a subject or user), your organization needs to obtain authoritative evidence that the applicant is whom and what they claim to be. Documentation that attests to a person's identity is often issued by a government or corporate entity, but in this day and age when almost anyone can make a convincing official-looking but fake document, you need ways to authenticate the documents that are presented. In almost all countries, national law establishes a hierarchy of authorities who can authenticate a document, either because they were the issuing authority or because they can otherwise confirm its legitimacy. In the United States, notary publics can notarize many types of documents; in other countries, similar functions may be done by notarios, by solicitors, or by the local or national government itself. These are examples of human-to-human certificate authorities who support two other parties in establishing trust. (On the international level, a process known as apostille is used by agencies of one nation's government to attest to the authenticity of documents they generate, which a person then provides to an agency of another nation's government. This usually requires layers of authentication in the source country, as well as layers of verification and confirmation in the receiving country.)
As you'll see in Chapter 5, “Cryptography,” most of our modern information security depends upon the use of digital certificates, which are a fundamental part of our public key infrastructure (PKI). These are issued by a certificate authority and assert that the person (human or organizational entity) named on the certificate matches the public key that the certificate contains. Chapter 5 will also address hierarchies of trust and webs of trust, in the context
