Is It Time For Zero-Trust Corporate Networks? (csoonline.com)
An anonymous reader quotes CSO:
"The strategy around Zero Trust boils down to don't trust anyone. We're talking about, 'Let's cut off all access until the network knows who you are. Don't allow access to IP addresses, machines, etc. until you know who that user is and whether they're authorized,'" says Charlie Gero, CTO of Enterprise and Advanced Projects Group at Akamai Technologies in Cambridge, Mass... The Zero Trust model of information security basically kicks to the curb the old castle-and-moat mentality that had organizations focused on defending their perimeters while assuming everything already inside didn't pose a threat and therefore was cleared for access. Security and technology experts say the castle-and-moat approach isn't working. They point to the fact that some of the most egregious data breaches happened because hackers, once they gained access inside corporate firewalls, were able move through internal systems without much resistance...
Experts say that today's enterprise IT departments require a new way of thinking because, for the most part, the castle itself no longer exists in isolation as it once did. Companies don't have corporate data centers serving a contained network of systems but instead today typically have some applications on-premises and some in the cloud with users -- employees, partners, customers -- accessing applications from a range of devices from multiple locations and even potentially from around the globe... The Zero Trust approach relies on various existing technologies and governance processes to accomplish its mission of securing the enterprise IT environment. It calls for enterprises to leverage micro-segmentation and granular perimeter enforcement based on users, their locations and other data to determine whether to trust a user, machine or application seeking access to a particular part of the enterprise... Zero Trust draws on technologies such as multifactor authentication, Identity and Access Management (IAM), orchestration, analytics, encryption, scoring and file system permissions. Zero Trust also calls for governance policies such as giving users the least amount of access they need to accomplish a specific task.
"Most organizational IT experts have been trained, unfortunately, to implicitly trust their environments," says the chief product officer at an IAM/PIM solutions supplier.
"Everybody has been [taught] to think that the firewall is keeping the bad guys out. People need to adjust their mindset and understand that the bad actors are already in their environment."
Experts say that today's enterprise IT departments require a new way of thinking because, for the most part, the castle itself no longer exists in isolation as it once did. Companies don't have corporate data centers serving a contained network of systems but instead today typically have some applications on-premises and some in the cloud with users -- employees, partners, customers -- accessing applications from a range of devices from multiple locations and even potentially from around the globe... The Zero Trust approach relies on various existing technologies and governance processes to accomplish its mission of securing the enterprise IT environment. It calls for enterprises to leverage micro-segmentation and granular perimeter enforcement based on users, their locations and other data to determine whether to trust a user, machine or application seeking access to a particular part of the enterprise... Zero Trust draws on technologies such as multifactor authentication, Identity and Access Management (IAM), orchestration, analytics, encryption, scoring and file system permissions. Zero Trust also calls for governance policies such as giving users the least amount of access they need to accomplish a specific task.
"Most organizational IT experts have been trained, unfortunately, to implicitly trust their environments," says the chief product officer at an IAM/PIM solutions supplier.
"Everybody has been [taught] to think that the firewall is keeping the bad guys out. People need to adjust their mindset and understand that the bad actors are already in their environment."
Until the network gets in the way of an executive doing something executive-y or costs too much. Then it's right back to status quo.
How the hell are you going to do business like that? Do you have any idea how many companies don't have IT staff who understand TCP/IP networking but somehow are in charge of it? How much do you think it would cost when your network constantly has to be reconfigured to allow connectivity by IP and/or expiring certs rather than passwords?
Unless highly skilled IT workers get a hell of a lot cheaper then this is pie in the sky. The cost of a breach is still less than the cost of wages needed to keep a scheme like this working _and_ have a functional network.
Hi! I make Firefox Plug-ins. Check 'em out @ https://addons.mozilla.org/en-US/firefox/addon/youtube-mp3-podcaster/
The truth is that almost any organization that isn't heavily regulated against doing so is putting at least _some_ data outside the corporate firewall in public clouds. Even if the official IT department doesn't realize it, it's definitely happening. It's rare these days to see companies with a defined perimeter that nothing leaks out of. Anyone who's doing Office 365 is doing Azure AD and logging in from remote. The days of securing a fixed boundary and trusting everything that makes it in are numbered.
Almost every corporate environment I've been in assumes that once something is behind the firewall, either VPNed in or connecting directly, it's trusted. That's a very bad assumption, and I think that's where "zero trust" networks come in. Even if it's degrees, like "I'm not going to implicitly trust every device that plugs into an internal switchport," it's better than nothing. Doing it right is hard though...and there are a lot of companies that just don't want to re-architect their networks to accomodate a posture of limited trust.
Don't allow access to IP addresses, machines, etc. until you know who that user is and whether they're authorized,'" says Charlie Gero, ...
How about: "Treat your internal wiring like it's the wild-and-wooly Internet. Have both the the boxes and the applications/services - encrypt everything and authenticate each other before exchanging information."? (Apps authenticate both the other app and the box it runs on because a corrupted box can get into the app.)
Then you don't have to trust all the other boxes or the wiring between them.
It also means that it's not such a big deal if somebody manages to hang an extra box on your net or inserts it in a cable. The most it can do is use your bandwidth to talk to the outside rather than use its own radio, listen to its surroundings with its own sensors, or DoS what ever is going through the cable into which it's inserted. That means you can let your employees bring in their own equipment without compromising your firewall (or compromise your operation more than a tape recorder, camera, or box with sensors would do without the netk access).
Bantam Dominique roosters crow a four-note song. Once you've heard it as "Happy BIRTHday" you can't NOT hear it that way
What we need to do is build networks using the same philosophy that was used when creating the Rust programming language. Rust is the safest and most secure programming language around. It has been designed to use move semantics instead of garbage collection, to have guaranteed memory safety, to have threads without data races, and no segfaults. Although Rust is a programming language we can apply the same design process and philosophies when creating other systems like computer networks and IT infrastructure. This way we could build hyper-secure networks without losing functionality. Just like Rust revolutionized programming, applying Rust's design philosophy to networking would be revolutionary in its own right.
and no mention of Blockchain. waaaaa???!!
It isn't new, and has been around in one form or another for a long damned time. The problem is that a lot of networks have been set up with a lowest common denominator principle. "Oh we have that old XP box that communicates with that weird old Xerox plotter, so I guess we better leave SMBv1 enabled" or "Jeez, setting up a VPN for those machines in the annex connected by WiFi is such a pain in the ass, let's just turn off SID advertising and give it a real long password and plug the access point into the private intranet."
I've seen these sorts of "compromises" and many more over the years, and it very often is because either the IT department is filled with idiots, or they're perfectly sensible people who have been ordered by management to keep supporting awful legacy devices, and support them in a way that does cause the management team any difficulty ("What, I have to log in to some portal so I can get access because you've segregated it off the LAN!!! I just want to click on the icon that I've always clicked on!")
And that's where zero trust networking really runs into problems. It's not all that hard to set up systems that have that much rigor. It's having to get the users, and in particular your superiors, to accept the necessity and not push for "accommodations" that end up undermining security.
The world's burning. Moped Jesus spotted on I50. Details at 11.
However, security must also acknowledge reality. The reality is that so long as you empower your employees to do, well, much of anything, they will become potential vectors of an attack. Lock them down to be harmless, they will often also be unable to be productive.
It is worth noting that many of these attacks that happen still do happen because someone dangled part of the information outside the defenses. An improperly set up cloud storage or service has become a frequent source of compromise. These attacks would be rarer in the 'castle and moat' because they happened inside a more protected network. Sure, they shouldn't have been configured that way even internally, but reality is *someone* is going to do something like this, and better for it to be mitigated than in the open.
So the lesson is sure, be as vigiliant as you already *should* have been, but also that going out of the moat is part of the problem, not that the moat is losing efficacy compared to before.
XML is like violence. If it doesn't solve the problem, use more.
So my work set up OTP authentication to get in remotely.
First time around, hadware tokens. Problem: people kept losing them.
Eventually, migrate to OTP for phone use. Problem, people would forget their phones.
Ultimate solution, a website to generate the token that's publicly accessible, that just accepts the same single username/password that they were trying to get away from in the first place.
Anyone in the industry knows *exactly* what'll happen when you inconvenience people with onerous security, they bypass it. Have no viable way to exchange large files? Those files *will* end up publicly shared on google drive. Refuse to set up an internet facing service for some department in a timely fashion? Someone in that department will buy an AWS instance and just do it themself, even if they use a few dollars of their personal money.
Security is about more than locking down access to stuff, it's about facilitating work to be done securely, but within reason. Sometimes that means doing something that isn't perhaps *as* locked down as you would like, but it is better than the alternative.
XML is like violence. If it doesn't solve the problem, use more.
For security to actually *work*, this is the key thing that must change.
Security in this industry has been about security teams covering their asses, it's not *their* fault if all their efforts to make things secure are bypassed by people trying to get their job done. Security *needs* to be more about understanding the human consequences of the approach being taken.
XML is like violence. If it doesn't solve the problem, use more.
It's not new to IT, it's "new" to corporate management and C-level, who always complain when any security inconveniences them or their secretaries.