LITMIR.BIZ

Скачать книгу

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 of the use of digital certificates.

      In both cases, the process is similar. A certificate authority establishes itself in the marketplace, and others (content owners) come to it to obtain a credential, token, or certificate that they can provide to a content user as proof of the content owner's trustworthiness. Content users can then challenge the content by requesting a verification or authentication service from the certificate authority. Certificates issued by a certificate authority can, in some circumstances, in effect delegate authority to a subordinate.

      Zero Trust Architectures

      In late 2020 the information security profession began a major paradigm shift away from focusing on defense in depth and its association with trust but verify (or verify at initial access, then trust until end of session) as the dominant metaphor. Zero trust as a set of concepts focuses instead on protecting data assets first and foremost. NIST published its SP 800-207 Zero Trust Architecture (ZTA) as a reference and guide in August 2020; a number of vendors have begun providing implementation roadmaps that use this, and in May 2021, the US Defense Information Systems Agency published its zero trust reference architecture. All of these represent snapshots in time of a rapidly evolving set of concepts, ideas, strategies, and tactics.

      NIST SP 800-207 describes a ZTA as one that demonstrates the following design tenets:

       Data and computing services are treated as resources to be managed and protected.

       All communications are secured regardless of network (or physical) locations;

Скачать книгу