One Article Review
| Source |  AlienVault Blog |
|---|---|
| Identifiant | 1642861 |
| Date de publication | 2020-04-08 12:00:00 (vue: 2020-04-08 14:08:36) |
| Titre | The Zero Trust Authorization Core |
| Texte |
This is part 2 of a 3 blog series
The Foundation of a Zero Trust Architecture (ZTA) talked about the guiding principles, or tenets of Zero Trust. One of the tenets mentions how all network flows are to be authenticated before being processed and access is determined by dynamic policy. A network that is intended to never trust, and to always verify all connections requires technology that can determine confidence and authorize connections and provide that future transactions remain valid. The heart of any ZTA is an authorization core involving equipment within the control plane of the network that determines this confidence and continually evaluates confidence for every request. Given that this authorization core is part of a control plane, it needs to be logically separated from the portion of the network used for application data traffic (the data plane).
Based on the designed ZTA and the overall approach, components of the authorization core may be combined into one solution or completely stand on its own through individual hardware and/or software-based solutions.
Communication Agent – the source of the access should provide enough information for confidence to be calculated. Enhanced identity attributes such as user and asset status, location, authentication method and trust scoring should be included in every communication so that it can be properly evaluated.
Enforcement Engine – also known as an Enforcement Point. This should be placed as close to the element of protection (the data) as possible. You might think of this as the data’s bodyguard. The Enforcement Engine will authorize the requested communication based on policy and continually monitor the traffic to stop it, if necessary, as requested by the Policy Engine. An Enforcement Engine may prevent a system holding the element of protection from being discoverable, for example.
Policy Engine – makes the ultimate decision to grant access to the asset and informs the Enforcement Engine. The policy rules will depend on the implemented technology but will typically involve the who, what, when, where, why and how for access involving network services, endpoint and data classes.
Trust/Risk Engine – analyzes the risk of a request or action. The Trust/Risk Engine informs the policy engine of deviations in an implemented trust algorithm, evaluates the communication agent’s data against data stores and can utilize static rules and machine learning to continually update agent scores as well as component scores within the agent. A trust algorithm that is implemented to compute a score-based confidence level based on criteria, values and weights set by the enterprise, along with a contextual view of an agent’s history and other data provides the best and most comprehensive approach to eliminating threats. A score and contextual-based trust algorithm will identify an attack that may stay within a user’s role, versus an algorithm that does not take historical and other user data into account. For example, a score and contextual-based trust algorithm may pick up on a user account or role that is accessing data outside normal business hours in an unusual way or from an unrecognizable location. An alternative algorithm that relies solely on a specific set of qualified attributes may evaluate faster but will not have the historical context to understand that that access request seems odd and advise the policy engine to require better authentication before proceeding.
Data Stores –As stated, a preferred approach is to implement a score and c |
| Envoyé | Oui |
| Condensat | –as about above access accessing account action advise against agent agent’s algorithm all along also alternative always analytics analyzes and/or another another’s any application approach appropriate architecture are arena assessment asset assets attack attributes authenticated authentication authorization authorize based before behavior being best better blog bodyguard business but calculated can carefully case changes classes classification classified client close cloud combined communication communications company completely component components composition comprehensive compute confidence connections contains context contextual continually control core correlated cost created criteria currently data data’s decision decisions depend depending design designed determine determined determines determining developed deviations devices diagram differ different discoverable discovered does during dynamic dynamically element elements eliminating endpoint enforcement engine engines enhanced enough enterprise environment equal equipment evaluate evaluated evaluates evaluating evaluation every example exist extreme fact faster fill flows foundation from function further future gaps gateway given grant group guide guiding handling hardware have heart help historical historically history holding holistic hours how identify identity implement implemented important include included increased individual inform information informs intended inventory investments involve involving its key known learning level links load location locked logically longevity machine make makers makes making maturity may meeting mentions method micro might migration model monitor most must necessary needs network never normal not odd offset one only open order organization’s other others outside overall own part particular pick place placed plan plane point policy portion portions possible practical preferred premise prevent principles private proceeding processed profile properly protection provide provided provides qualified reference related relies remain request requested requests require requires resource respect results risk roadmap role rules same scale score scores scoring seems segmentation separated series server services set should shown similar software solely solution solutions source specific stand standards stands stated static status stay stop store stored stores such sufficient supplemental supported switching system take talked technologies technology tenets than that therefore these think threats through traffic transactions trust trust/risk typically ultimate under understand unrecognizable unusual update use used user user’s users utilize valid values various vendor vendor’s verify versus view virtual voids vpc way ways weights well what when where who why will within without worked workloads yet zero zta zta’s |
| Tags | |
| Stories | |
| Notes | |
| Move | 
|
L'article ne semble pas avoir été repris aprés sa publication.
L'article ne semble pas avoir été repris sur un précédent.