BreachExchange mailing list archives
What You Need to Know About Zero Trust Security
From: Destry Winant <destry () riskbasedsecurity com>
Date: Thu, 30 May 2019 09:21:27 -0500
https://www.darkreading.com/vulnerabilities---threats/what-you-need-to-know-about-zero-trust-security/d/d-id/1334751 If your network has a perimeter, it will someday be breached. That's both the lesson the "real world" works so hard to teach and the premise behind a key security model: zero trust. "Don't trust, and verify" might be a nutshell description of the zero trust model — "don't trust" because no user or endpoint within the network is considered intrinsically secure, and "verify" because each user and endpoint accessing any resources of the network must authenticate and be verified at every point, not just at the perimeter or large network segment boundaries. This often-repeated authentication throughout the network and application infrastructure relies on the concept of "microsegmentation," in which boundaries are defined around individual applications and logical network segments. This kind of frequent check point can go a long way toward putting an end to lateral infection in malware outbreaks, and it doesn't have to be as cumbersome to users as it sounds — as long as technology is used to deal with some of the logins and authentications along the way. While the concept behind the zero trust model is simple, implementation can be anything but. Before a company decides to invest in the technology and processes, it should understand what is involved in the model and its application. Dark Reading has identified seven issues to resolve before launching into a zero trust environment. Decide Who Drives Zero trust and its enabling technology, microsegmentation, require changes to both security and networking infrastructure. Given that, one of the first questions to be answered is which group will own the project. Depending on precisely how your application environment is configured before beginning the project, changes may be required to switches, routers, firewalls, authentication servers, and the application servers themselves. In many organizations, responsibility for changing those infrastructure components could fall well outside the responsibility of the security group, in which case the options boil down to expanding the security team's brief for this purpose or having security write the requirements that will be put into action by the network and application maintenance teams. The multiple responsibilities and components of zero trust make it an instigating factor for a move to DevSecOps for some organizations. Treating every part of the infrastructure as software to be constantly authenticated against, monitored, and improved makes sense for zero trust security, and it may ease some of the issues around which group is going to drive the change process. Build Least-Privilege Policies How much does access privilege cost? Does your company see it as a cheap line of code in an access table? Is it better to give users the privilege they might need rather than risk having them run into an access denial issue when their responsibilities expand? If so, your users have a serious attitude adjustment to come when you move to zero trust. Least-privilege security is based on a very simple concept: The network (and application) infrastructure is most secure when users have only the access privileges required to do their jobs. This kind of privilege management has many benefits, with one being the limited harm employees can do when they wander out of the tools required for their jobs. Another huge benefit is the limited harm hackers can do if they steal the credentials of users. It is much more difficult for low-level employees with low-level privileges to provide the stepping stone for a network takeover if their access to far-flung network segments and applications is limited. Least privilege requires a change in philosophy for many organizations, and it can feel awkward if the reason behind the shift isn't explained fully and carefully. Coupled with zero security, though, least privilege can be a powerful tool for limiting attackers' ability to expand their attacks and create damage inside the network. Get Small This is the crux of zero trust security. When you logically and physically segment your network and application infrastructure into very small pieces, with authentication required for each transit from one segment to another, then you have placed some very hard limits on how far an intruder's access can easily go. Those small segments should be thought of in both logical space and time. If a user (especially a highly privileged user, such as an administrator) occasionally needs access to a particular system or function, then he or she should be granted access for the time needed to work on the issue, not always. If you assume your network has been breached, then the logical response is to make sure the breach can do as little damage as possible. Keep any single attack confined to a single logical segment, and you limit the damage to that segment. And that does a number of very good things for your overall security. Secure Everything, Everywhere If you assume that the network has been breached and attackers are running around inside the perimeter, then the last thing you want to do is leave a segment or component unprotected. This is not just for the security of the protected piece of network, but to keep the unprotected components from becoming a launching pad for attacks on other segments of the infrastructure. Now, security experts may start to ramp up arguments about prioritizing assets for protection and the inadvisability of protecting everything equally. That's true, but remember that the ideal is layered security, so it's critical to understand the layer that's being discussed here. That layer is the access layer — who, or what, has been authenticated as legitimate so they can properly access a particular asset. At that layer should never be an unprotected network segment or application component. Secure everything, everywhere, and you will minimize the access-based risk to your IT infrastructure. Be Nosy — Very Nosy Microsegmentation should make it easier to stay on top of whatever is happening on your network, but to know who's doing what you have to first be looking. And if you want to be secure, you should be taking a very close look at many different facets of network behavior. With segmentation showing the way, it can be more straightforward to instrument a zero trust network than one with traditional authorization models. And to bring the prioritization question back to the fore, the question becomes not one of where to monitor, but which factors to monitor in each segment. Once you identify strategic network segments or application infrastructure components, you can establish deep inspection of network flows and behaviors with less concern about swamping data storage or human analysts because you will be taking data from a limited network segment. In general, though, you want to be quite aggressive in monitoring segments so that security architects can follow attacker and employee behaviors, as well as help evolve security rules and processes to keep pace. Add Factors If authentication to each network segment is key to total network security, then the process of authentication becomes critical. And until we reach the science-fiction future, user authentication means strengthening the factors you use and adding others to make user identification more certain. Surveys of passwords in use inevitably produce depressing results, with strings like "12345" and "qwerty" consistently topping the list of most-used passwords. So task one is establishing strong password policies for everyone in the organization and then enforcing those policies. Next, add factors. The current list of factors is something you have, something you know, and something you are. This multifactor authentication is becoming more common, but it has started from a total market penetration near zero, so many companies are still willing to try anything more robust than the classic user name/password pair for authentication. Keep It Modern There is no security model that is "set it and forget it." Zero trust security is not an exception to this rule — and may be one of the least forgettable security models out there. That's because keeping up with threats and knowing how they might try to thwart authentication schemes is critical when authentication plays such a significant role in the overall scheme. Beyond the authentication issue, security professionals much keep up with threats and the mechanisms they use for lateral movement and bypassing network segmentation. No one in security can assume that the methods and technology that work today will always be effective, so security practitioners will need to keep up with industry trends and spend time analyzing incidents captured in monitoring to see where breaches of segmentation have been tried — and where they might have been successful. There's no question that zero trust security can be the basis for successful information and asset protection. But just because a method is effective doesn't mean it can be launched without careful thought and planning. Ask questions, plan ahead — and remember to trust no one. _______________________________________________ BreachExchange mailing list sponsored by Risk Based Security BreachExchange () lists riskbasedsecurity com If you wish to Edit your membership or Unsubscribe you can do so at the following link: https://lists.riskbasedsecurity.com/listinfo/breachexchange
Current thread:
- What You Need to Know About Zero Trust Security Destry Winant (Jun 03)