Is It Time For Zero-Trust Corporate Networks? (csoonline.com) 150
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."
How is that supposed to work? (Score:5, Interesting)
Defense in depth is a very valuable concept, but "zero trust" seems like it is taking things too far. Do you not trust a printer to print your document unless you, as the end user (or executive officer) have verified its firmware is authorized by the manufacturer and has not been subverted? What if it prints your document but injects errors or sends a copy to a foreign espionage organization? How does a server decide whether to trust a request from a computer where a known user is logged in, rather than rejecting it as a web browser that got subverted by malware or a new-fangled kind of attack ad?
Re: (Score:2)
My point with that example was that I strongly doubt anyone is using the "zero trust" idea when they decide whether to send their document to a particular printer.
Re: (Score:2)
Hell, I already have nearly zero trust when deciding to send my documents to printers in the office, particularly if:
If you can guarantee my document will print every time, even with a few injected errors, I call that "reliable printer administration". Besides, who cares if there are errors? Nobody reads stuff on paper anymore, anyway.
Re: How is that supposed to work? (Score:1)
It is trivial.to guarantee a document will print in a large corporate environment.
1) select a physically inaccessible printer (wrong floor, locked door, etc)
2) print your resume or any other sensitive material.
Re: (Score:2)
That's a security through obscurity solution and doesn't really solve the problem. Other people will always have keys to those locations. Besides, people print and then get interrupted or distracted, say they'll pick up the printout later and forget leaving documents around. It's better to send the print job to a secure print server then I can walk up to any printer, scan my ID badge to access the job and then confirm to print (and delete it from the server).
Besides, what is being discussed here is trust in
Re: (Score:2)
If only we could teach your printer to not trust you we'd be set.
Re: (Score:3)
At least you can put printers on a separate network segment or preferably one printer segment per department if you have a large organization so they only can get the documents you print and don't see any other traffic or access any servers. Most of the attacks through printers are just using them as a springboard to access other services in the net.
Also make sure that the printers don't have any public internet access and do any firmware updates manually and you should have contained the printer issue reas
Re: (Score:1)
Security: Not often convenient.
Re:How is that supposed to work? (Score:5, Insightful)
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.
Re:How is that supposed to work? (Score:5, Interesting)
If, on the other hand, people move around between workstations, or need to be able to run arbitrary software (for example stuff sent by a client or vendor, or stuff they wrote themselves, or the software they run is a programmable environment like MATLAB that you can do nasty stuff with if you put your mind to it), then you can't have that without incurring a real penalty on productivity and encouraging your employees to work around the security infrastructure. You pretty much guarantee the latter if any portion of your workforce does R&D work that requires moving equipment between network jacks or needing to be able to send arbitrary packets from one gizmo to another or from a gizmo in the lab to their workstation. Or if several people on the same team need to be able to unlock the screen on the same machine and get at the same instance of the user session.
There is no silver bullet. Tiered access is good, sales clerks don't need to be able to get at the HR database or the preparatory documents for a patent filing, but there is no silver bullet.
Re:How is that supposed to work? (Score:5, Funny)
I think the zero-trust approach is all wrong.
The real answer is to deploy all that "machine learning" and "AI" bullshit to anticipate, and prevent, problems.
Re: (Score:2)
The real answer is to deploy all that "machine learning" and "AI" bullshit to anticipate, and prevent, problems.
Nope. The answer is "blockchains". The whole point of blockchains is dealing with trust, by distributing "trust" among many entities. Although none of them are fully trustworthy, they also don't fully trust each other, so the blockchain system as a whole has integrity.
Re: (Score:3)
Oops. [slashdot.org]
Deanonymizing Tor: Your Bitcoin Transactions May Come Back To Haunt You
Re: (Score:2)
Oh shit, 'blockchain' is the new 'sharding' or 'webscale.'
Mongo DB is Web Scale [youtu.be]
Re: (Score:2)
Security: 1-assume anyone could be a risk. If anyone is above suspision then that person will be targeted. 2-Need to know: limiting the scope of access to what is required, as opposed to you have a security clearance so you can see everything. Limit the damage when (not if) people fail. 3-Machine learning and AI are "mostly" reliable. When your personal security is at risk you want "Always" reliable.
Re: (Score:2)
It's a lot easier than that.
In the old days, admin jockeys had to manually allow/disallow all kinds of access for all kinds of entities all over the network.
I was there.
Time to deploy ML and AI the vendors are pushing.
Re: (Score:3)
How does a server decide whether to trust a request from a computer where a known user is logged in, rather than rejecting it as a web browser that got subverted by malware or a new-fangled kind of attack ad?
The same way you have been able to do it for a while. PGP signing. Go to a 'key signing party' and rub elbows with people you actually trust. Next time you get a letter from them verify the information is signed from them.
If the printer can inject errors we have bigger issues.
What shocks me in all of these e-mail leak scandals is how un verified it is. I remember being able to telnet to open port 25s and send e-mail to anyone as anyone. PGP encryption and signing should be standard by anyone at that level.
Re: (Score:3)
How does PGP protect against your computer getting infected by malware that impersonates you?
The "zero trust" approach mostly guards against the same attacks that locking down ports to known/expected MAC addresses does, although hopefully using more robust methods of identification. It can also guards against subversion of idle computers, but requires secure and clearly managed delegation mechanisms. Getting the delegation wrong can open up impersonation attacks that are probably worse than idle machines
Re: (Score:2)
What shocks me in all of these e-mail leak scandals is how un verified it is. I remember being able to telnet to open port 25s and send e-mail to anyone as anyone. PGP encryption and signing should be standard by anyone at that level.
There were DKIM [wikipedia.org] signatures on the Hillary Clinton emails
http://blog.erratasec.com/2016... [erratasec.com]
This Politifact post muddles over whether the Wikileaks leaked emails have been doctored, specifically the one about Tim Kaine being picked a year ago. The post is wrong -- we can verify this email and most of the rest.
In order to bloc spam, emails nowadays contain a form of digital signatures that verify their authenticity. This is automatic, it happens on most modern email systems, without users being aware of it.
This means we can indeed validate most of the Wikileaks leaked DNC/Clinton/Podesta emails. There are many ways to do this, but the easiest is to install the popular Thunderbird email app along with the DKIM Verifier addon. Then go to the Wikileaks site and download the raw source of the email https://wikileaks.org/podesta-... [wikileaks.org].
As you see in the screenshot below, the DKIM signature verifies as true.
If somebody doctored the email, such as changing the date, then the signature would not verify. I try this in the email below, changing the date from 2015 to 2016. This causes the signature to fail.
Re: (Score:2)
https://en.wikipedia.org/wiki/... [wikipedia.org]
DKIM's non-repudiation feature prevents senders (such as spammers) from credibly denying having sent an email. It has proven useful to news media sources such as WikiLeaks, which has been able to leverage DKIM body signatures to prove that leaked emails were genuine and not tampered with, definitively repudiating claims by Hillary Clinton's 2016 US Presidential Election running mate Tim Kaine, and DNC Chair Donna Brazile.
Trusting other cities (Score:2)
Go to a 'key signing party' and rub elbows with people you actually trust.
People in the same city, yes. But in the face of increasing "safety" and "security" restrictions on international travel, domestic air travel, and even getting a driver's license for the first time, how well does this scale beyond a city?
way past time... (Score:1)
Backwards example. Printers don't access databases (Score:5, Interesting)
The summary sucks, so I understand why it was unclear.
A printer is a great example. This is about networking. The idea is to get away from the "security happens at the firewall" model, the idea if anything that has an internal IP address should automatically get access to every internal resource. In the firewall model, the printer can connect to your databases, and can send data out to the internet. Does that make sense to allow that?
The Zero Trust model is about WHO, a logged in user, rather an IP addresses. In other words, *logging in* to the network gets you access to the stuff you have access to. It's the idea that just because you have an internal IP address doesn't mean you should have access to every internal resource. The printer is inside the network, but it doesn't get access to the databases, or HR system, or anything else. Also the printer doesn't have access to the internet. Inside the network or not, access is allowed based on who is logged in, not just anyone with a local IP.
Regarding a logged-in user with a malware infested PC, the network itself can't prevent ALL damage from that, but the Zero Trust model limits the damage because the malware can only access the things that specific user accesses for their job. The marketing manager can't even ping the database, so if his PC is infected only marketing material is at risk, not the database, code repos, etc.
Re: (Score:1)
In the firewall model, the printer can connect to your databases, and can send data out to the internet. Does that make sense to allow that?
I take it you've never worked with SAP.............
Re: (Score:2)
So how is that different than the "defense in depth" idea that had been around for decades?
Re: (Score:2)
It's got a cool new name.
Includes defense in depth, plus more (Score:2)
That's a great question.
Defense in depth is one part of Zero Trust. ZT has defense in depth built from the inside out, though. We start by securing the critical resource with the assumption that the attacker has control of a local computer. We then try to keep attackers out of our networks and an auxiliary measure. This is related to the principle of least privilege.*
Most crucially, perhaps, Zero Trust is about getting rid of the idea of "trusted networks" and focusing on WHO wants access to WHICH specific
Re: (Score:2)
So "Zero Trust" means to finally do the things that "defense in depth" has been telling you to do for decades, except to explain it poorly? If "the attacker has control of a local computer", what stops the attacker from impersonating whoever logs into that computer? Without 2FA, what keeps the attacker from capturing the legitimate user's password and logging in later?
Re: (Score:3)
First, I don't think most large corporate environments these days are castle & moat systems. If it is, it usually means that the company doesn't have more than one production facility, never did an M&A, no joint ventures, has no testing or R&D labs, hasn't been around for long, etc. Fragmentation naturally happens and it takes a lot of investment to keep things standardized.
So the largest security hole in these systems has always been the methane production units. Most corporations have all t
Re: (Score:1)
Re: (Score:2)
Well, at the very least you've reduced your attack surface. It really is getting to the point where you need IPSec even on internal traffic out of fear that someone will just walk in and plug into the nearest RJ45 and start sniffing out your traffic or trying to penetrate you from within. It's going to create some overhead, and will inevitably be a lot more complicated to administer, but that's where we're at now. The Internet has proven itself to be a big bad wild place, and you can't even trust your own u
Re: (Score:2, Interesting)
IPSec doesn't add anything if the peer is the thing to be compromised. That's pretty much the challenge. If things *do* get into your precious internal network, it's malware running on legitimately authenticated systems.
Physical attacks against ethernet ports are nothing compared to how often remote exploits occur.
Re: (Score:1)
I think that segmenting the network into smaller segments is at least a step up so that HR is on one segment, developers on another, HW CAD on a third etc. It's not a full client isolation perspective, but any mishaps would be contained. And anyone that runs WiFi should run a VPN to access "their" segment.
On WiFi you could leave non-essential stuff open, like internet access and intranet web server data in read only mode. All the stuff that would be harmless (except maybe a bit embarrassing) if it went out
Re: (Score:2)
In this case, the only thing that unauthenticated devices would be allowed to talk to would be the authentication servers. Anything else would require being authenticated in order to connect to. All traffic would be tunneled from point to point and only devices with a need to talk with each other would be allowed to do so.
That smells like "jump servers". Blech!!! As a DBA who must log into dozens of servers, they're the bane of my existence...
More like AD, no database passwords needed (Score:4, Interesting)
The summary sucks, so I can see how you might get that idea. It's very much NOT talking about jump boxes, though.
It's more about until you log in to your computer (via Active Directory / LDAP), you can't access sensitive internal resources. Once you're logged in, the DBA gets access to the database, while the UI developer doesn't. It's the idea that just because you have an internal IP address doesn't mean you should have access to every internal resource.
Re: (Score:2)
Oh. Well... shit. "Only being allowed access to resources that you have need" is as old as the fucking hills.
Mainframes were doing it in the 1970s and Multics has the idea in the 1960s.
Mainframes were more secure than Windows in many (Score:2)
What's old is new again. UNIX had a lot of security in the 1980s that Windows is just adding now. Partly that's the Disk Operating System legacy of Windows - Microsoft started out differentiating their product by making an OS for a PERSONAL computer, the opposite of the time-SHARING mainframe systems, and it was designed to run completely from the local disk as opposed to the network operating systems of the day. It was a smart move that made them billions. Then the internet happened and turned everythi
Re: (Score:1)
Generally referred to as NAC [wikipedia.org].
Re: (Score:2)
Re digital signatures: I never said that you should verify the firmware by trusting a digital signature. I specifically left the verification mechanism unspecified because of the difficulties you mention. I chose a printer as an example because even if a network's administrators attempt a "zero trust" model, other users probably will not adopt the same model: they will (in most cases) blindly trust that the thing their computer says is a printer does the right thing, or trust that the email bearing the co
Re: (Score:2)
Surely you see the problem with the idea of "don't trust a PC until a user logs in" if the concern is that the user visits "bad websites" while they are logged in. (And don't call me Shirley!)
Re: (Score:1)
Nope. If they're visiting websites while logged in whole on-premises, then hopefully your other compensating controls (DNS filter, firewall, AV) can help deal with that. Not trusting the device initially is more to prevent things like:
a) Unauthorized devices in general attaching to your network (home device, infiltration devices, etc)
b) Machines that have left the premises (e.g. a laptop that may have been infected in the field outside the firewall etc)
c) Overall better identification and management of syst
Take risk (www.myessaywriter.net) (Score:2)
Re: (Score:2)
That is an interesting take. Can you give an example of a risk that a zero-trust network would obviate that would cause the loss of some reward?
Re: (Score:2)
Re: (Score:3)
There are no lack of tools out there to help with this. Hire people that understand a certificate authority and can set up end to end encryption. It's a bit more complicated, but anyone coming out of any networking certification program who can't set up a CA and administer an IPsec network should be shown the door. And really, the hard part is just in the set up. Once you have the processes and systems in place, it's just a little bit of extra work every time you have to add new hardware. And then you can h
Re: (Score:3)
Re: (Score:2)
Dude, he's a spammer.
Re: (Score:2)
They all are.
Re: (Score:2)
It's not the first time. It's almost impossible to tell the difference between a spam account and your average AC.
Re: (Score:2)
This isn't risk in the context of "If I buy a million dollars in corn futures, and there's flooding that wipes out 1/3 of this year's harvest, why I'll make shit tons of money", this is risk in the form "if I leave my doors and windows open and put out a big sign saying ROB ME". The former may be a sensible gamble, but even if it isn't sensible, at least one can identify some potential up side to it. Having your hardware p0wned, your data stolen and your network rendered useless has no upside.
Re:Take risk (www.blow.me) (Score:2)
Please die in a fire. Fire optional.
Sure (Score:2)
I never trusted corporate networks anyway in the past, so why now?
Re:Why is this new to IT experts? (Score:4, Insightful)
Re: (Score:2)
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.
Exactly. These new and deeper in depth approaches are kind of silly when the suits insist on no impediment for themselves.
The problem of course, is that the person who can demand you remove any inconvenience can also fire you.
This is all well and good (Score:5, Insightful)
Re: (Score:2)
This -- especially "costs too much" -- is so effing true.
Re: (Score:1)
I've seen entire egress security postures removed just so a C level dbag with a chip on his shoulder can hold a skype for business meeting for 2 hours and be sure he isn't disrupted.
C stands for cocksuckers in my book
Re: (Score:2)
Any business using Skype ("For Business" or not) for intra-company comms is already asking for it.
Re: (Score:2)
Not even an executive being inconvenienced is needed, in my experience. Just enough noisy whiners complaining that they can't do their job is often enough. Once the rabble gets loud enough to be heard outside the executive bathroom, it gets fixed.
No-trust in practice is going to mean that about 100% of employees are going to not be able to do their job, or do it as they're used to doing it. I can't see retrofitting this onto any mid-sized business or larger. I think it would only work if you built it from t
Back To The Basics (Score:5, Informative)
The question "Is It Time For Zero-Trust Corporate Networks?" has been faced for decades, so how is Zero Trust any different? It seems to be based on two well known concepts: authentication (are you who you say you are?) and authorization (now that I know who you are, are allowed to do what you are trying to do?). The authentication and authorization model has been used to varying degrees for decades in Federated Naming systems, LDAP, Active Directory, NIS+. etc. etc. So, the question should be "How is Zero Trust new?" when we already understand the basics?
Re: (Score:3)
Further, one of the chief reasons that we haven't commonly used the authentication/authorization model on a widespread basis is that almost all previous attempts at scaling the solutions to very large organizations has met with physical hardware limitations that not even NIS+ on an Ultra Enterprise 10000 or batteries of Windows AD servers could tackle. If we now go back to the authentication/authorization model and write the code to operate integrally in the cloud we may have the means to actually scale it
Re:Back To The Basics (Score:5, Insightful)
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.
Re: Back To The Basics (Score:2)
No, God no (Score:3, Insightful)
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.
Re: (Score:2)
According to LinkedIn HR posts I read IT is not hard as technical skills can be learned. Managerial and leadership is not as unlike us these guys work very hard and provide a value to companies unlike IT appearrently.
Seeing Indians who barely speak English doing any of the jobs we used to do show them anyone can learn it as the company isn't falling apart yet.
Re: (Score:2)
And as someone astutely pointed out above: legacy devices.
Not only do you have the cost of skilled IT workers, you have the cost of having everything largely upgraded at all times, with no exceptions. No old fax/printer/copier sitting in some office somewhere, no old label printer, no headless box that hasn't been updated in 10 years that's running something critical, no cheap chinese security cameras with no firmware updates ever, no two decade old security card system, no xp machine running the envelope s
Re: (Score:3)
and I just be a fake fire men to get into the vents and also first be a fake fire inspector to install key loggers.
https://it.slashdot.org/story/... [slashdot.org]
The cloud is making this a requirement (Score:4, Insightful)
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.
How about not trusting your network, either? (Score:5, Insightful)
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).
Re: (Score:2)
In other words, treat the net like electrical wiring and just deal with what's plugged into it.
Re: (Score:2)
Came here to say the same. I wouldn’t stand up a server on the internet that didn’t require authentication and authorization so why would I do so on an enterprise network? Even then trust must be limited since malware happens.
It's so obvious in hindsight! (Score:1)
Trustless (Score:2, Insightful)
and no mention of Blockchain. waaaaa???!!
It has always been the time.. (Score:4, Insightful)
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.
Zero Trust Operating Systems (Score:2)
It's time for Zero Trust Operating Systems. Gone are the days when one could assume that a program would work as designed, and tolerate the odd bug. Until the software that defines our computing experience grows up and stops trusting everything put into it, we're going to be deep in shit.
This is pretty much nonsense (Score:3)
The only reason I can see for this (old, bad) idea to be pushed again is that some people need to create the next hype to keep their own business-model alive.
On the actual subject, if you really want every system to be individually administrated and fully secured, then go ahead and run this model. For a small network, with, say, less than ten computers this may even work. But even there it can be excessively expensive. In actual reality, any network where people think about a perimeter does need that perimeter. It needs to be implemented right, of course. For example, the only network access must be via that trusted network (enforced VPN if you are not on-site) and software must come from that trusted network as well. Also, any user active anywhere must be identified reliably (password _plus_ chipcard, e.g.) and the trusted network must, of course, be divided into zones with effective firewalling between them. Data import must go via secured channels, no just plugging in an USB stick. So not only do you need that perimeter urgently, it is by far not enough. It is just one element.
Now, this is very expensive to run and maintain. I know that. But unless you have no secrets and no IT-based business processes to protect, this is your only chance to avoid a hugely expensive disaster in the long run.
Re: (Score:2)
Having a perimeter to protect the machines within suggests that they need protecting. Either they do and resources should be focused on fixing them, or they don’t and no perimiter is needed - like servers on the open internet.
Re: (Score:3)
On the actual subject, if you really want every system to be individually administrated and fully secured, then go ahead and run this model. For a small network, with, say, less than ten computers this may even work.
FWIW, Google does this with a very large and complex network (100K+ employees). Google has taken the next step beyond this, actually, and recognized that once you have ensured you don't extend any trust to your internal networks, there's no reason to treat external networks as less secure. (See https://www.beyondcorp.com/ [beyondcorp.com]).
The solution to the problem you mention is standardization. Specifically, standardize all of your internal applications on web interfaces. Once everything is a web site, then you can st
Re: (Score:2)
Google can do it because they are atypical. It is no indicator that, say, a bank or a hospital can do the same.
Re: (Score:2)
Google can do it because they are atypical. It is no indicator that, say, a bank or a hospital can do the same.
Google can do it from scratch because they are atypical. I agree that a bank or hospital absolutely could not build all of the necessary infrastructure to do it, but that's no longer necessary. Google's BeyondCorp program is one of several "vendors" (I believe Google's stuff is all open source) that provide the necessary proxy software and related bits, and it will get easier over time.
Re: (Score:2)
A lot of this is getting rolled into software defined networking and used to create specific fine-grained rules and management of east/west network traffic inside a network.
I think the concept is reasonable to some degree and not entirely different from older ideas that treat the network more like concentric circles, with security increasing as you enter the circle and less and less traffic accepted from rings more than 1 ring above.
The problem with the present iteration of these concepts is that the vendor
BOYD consequence (Score:3)
Or even further (Score:1)
Cool idea but... (Score:3)
Once you get into a user's system you can do Active Directory attacks and legitimately escalate all the way to Domain Admin using tools such as BloodHound. There's also Kerberoasting and of course hash cracking once you've escalated on a system and run Mimikatz on it. Often you can just pass the hash and not even bother cracking them. All of this using legitimate credentials and "allowed" accesses within the scope of the users.
Sure this will keep a guy from plugging into an open ethernet jack and running all over the place, useful as part of defense in depth, but it's not a magic bullet.
Re: (Score:2)
At my organization we have deployed NAC to block unauthorized devices, Vmware NSX, for micro segmentation, web and email content filters, DLP detection, email encryption and MS ATA.
No one has a Domain admin account and Administrators must grant themselves access to systems they need to work on every day and those permissions are reset when they leave for the day.
Our goal is to make sure any attacks are so noisy because of the restrictions so they will be detected.
It takes a smack upside the head. (Score:3)
I can't remember how many times I heard people sit in staff meetings and argue against employing simple security practices when developing application using this excuse. You know what changed their minds? The time when some admin powered up a WinNT box sitting in an unused cubicle--inside the firewall--not realizing that it had been infected with Code Red and it DoSed several critical servers during month-end processing. Now their application design would likely have not had anything to do with protecting against Code Red, when they saw first-hand what can happen when the attacker is on the (supposedly) "clean" side of the firewall they finally figured it out.
It's time (Score:1)
https://cloud.google.com/beyondcorp/ [google.com]
But it's hard to bolt onto an existing infrastructure without restricting it.
Comment removed (Score:4, Interesting)
Yes this has been a thing for nearly 20 years (Score:2)
NAC is to Zero Trust as HyperCard is to hypertext (Score:2)
Once upon a time, if you described the concepts of hypertext to someone, they'd say "oh you mean HyperCard". After that, Hypertext Markup Language was created (HTML) and hypertext has gone way beyond HyperCard.
Today when most people read about Zero Trust they think "network access control", because NAC is a tool we currently use to implement some key Zero Trust concepts. However, just as hypertext wasn't limited to just HyperCard, Zero Trust is bigger than Network Access Control.
NAC is one of the earliest
YES (Score:2)
Betteredge be damned.
Zero Trust already exists (Score:1)
Zero Trust already exists out among the peers on many corporate networks. Unless you trust the motherfuckers who run the IT in your organization, in which case you are making a grave mistake, you make efforts to secure your group's workspace against the IT goons.
Reminds me.. (Score:5, Insightful)
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.
Re: (Score:3)
Yes, this is the whole "shadow IT" thing. Official IT falls short, people wanting to get work done will start supporting each other in creative ways. *Those* well-meaning efforts end up causing the network to be more at risk than if the IT department were more "risky" and actually helped work get done.
Re: (Score:3)
Charlie Gero: ~"Everyone should catch up with the times and start u
Re: (Score:2)
Would you rather be attacked in an open field surrounded by a moat, or in an urban setting which forces the attacker to dig you out building by building?