*>>I'll stand by my statement that opening up the firewall in the proposed fashion is a very stupid decision, because it doesn't solve the proposed problem - you might as well not have a firewall at all. *
So, let's look at the very specific alternative for the situation at hand, and compare the two security postures: - Machine in the DMZ which authenticates back into the more secure/trusted part of the network over 100 ports to a limited set of machines - Machine in the DMZ with all local authentication Let's just assume that there are 50 user accounts that need to authenticate. We won't even address WHAT this machine is serving up, or who it is serving it for. (These are both things the business will care about, but for now let's just work in abstraction) In your mind, which of the two scenarios is more secure? Or, said another way, if there was a breach of both machines, which would likely cause greater immediate problems for the organization, and why? *ASB *(My Bio via About.Me <http://about.me/Andrew.S.Baker/bio>) *Exploiting Technology for Business Advantage...* * * On Fri, Jan 7, 2011 at 1:11 AM, Kurt Buff <kurt.b...@gmail.com> wrote: > We disagree, and with your vast weight of experience, you carry the day. > > Or perhaps I'm just tired of battling. > > Whichever, I'm done. > > I'll stand by my statement that opening up the firewall in the > proposed fashion is a very stupid decision, because it doesn't solve > the proposed problem - you might as well not have a firewall at all. > > Either the machine is trusted, and can sit inside the soft chewy > center alongside the DC(s) and other machines, or it isn't trusted, > and you need to firewall it, and not allow it to reach inside the > network in the proposed fashion. > > Kurt > > On Thu, Jan 6, 2011 at 21:33, Ken Schaefer <k...@adopenstatic.com> wrote: > > > > > > -----Original Message----- > > From: Kurt Buff [mailto:kurt.b...@gmail.com] > > Sent: Friday, 7 January 2011 3:41 PM > > To: NT System Admin Issues > > Subject: Re: AD and firewall ports > > > > On Thu, Jan 6, 2011 at 18:11, Ken Schaefer <k...@adopenstatic.com> wrote: > >> Hi, > >> > >>> Then you should turn of all your computers, encase them in concrete, > >>> and launch them into outer space - and into the Sun. That is the best > >>> way of stopping anyone compromising one of your machines. > >> > >>Got to love the straw man argument. > > > > How is this a straw man? Putting your data into the sun is going to make > it more secure. > > Far less usable, but far harder to steal. > > Since considerations of usability and convenience are not on your list, > you better start launching your servers. > > > > That is the logical conclusion that can be drawn from your argument. > > > > > >>> Hint: go and read some books on security first. *All* security is risk > mitigation. > >>> For example: that's why we still have passwords that are only "x" > >>> characters long, rather than "x + 1" (where x is any number less than > infinity). > >> > >> And you exaggerate again. We have passwords that are 'x' characters long > (I tend to use 20+ character > >> passphrases myself) because the effort to crack them is, so far, > infeasible, due to the lack of rainbow > >> tables of the size necessary to do so, and the lack of time to brute > force them before I change them. > >> If firms (such as my own work, I'll admit) are so foolish as to ignore > this limit, then they will likely suffer for it, > >> and deserve to do so. > > > > But they are NOT uncrackable. > > They are not unguessable > > They are able to by bypassed by beating them out of someone physically > > Etc. > > Etc. > > The 20 character password is "good enough", but it is not as secure as > the 21 character password, which in turn is not as secure as the 22 > character password, and so on ad infinitum > > > > At some point you have to decide that the *risk* of password compromise > is *not worth* the cost (inconvenience) of having more complex passwords or > 2FA > > > > You *mitigate risk* (password compromise) by picking an acceptable level > of risk. That level of acceptable risk varies from place to place. The local > coffee shop might have lower security requirements than the local bank. > > > > > >>> Everything in security is about: > >>> a) analysing what risks you face, > >>> b) working out what the likelihood of it eventuating > >>> c) working out the cost of the likelihood eventuating > >>> d) working out the cost of making the risk go away > >>> e) working out whether it's cost effective to implement (d) given > >>> (a)(b)(c) > >> > >> It's a b) that the risk mitigation wizards fail. Spectacularly. IMHO, > "risk mitigation" is a mantra > >> that has gone way too far, in the relentless pursuit of cost and effort > savings. The above > >> recommendation to turn a firewall into a safe passage for intruders is a > prime example. > > > > What on earth are you talking about? Risk mitigation is saying "is > someone breaks into our DMZ, we can't have them break into our main network, > so there is no trust relationship" > > Alternatively, the entire business might have all their data in the DMZ > anyway (or in a hosted data centre), in which case, once someone "0wns" the > DMZ, then they own everything anyway, so what's point of cumbersome barriers > and sneakernet? > > > >>> That is why a national government has a far more secure, cumbersome > >>> network than your average business. Because the risks are different. > >> > >> Oh, yeah - that's worked out well, hasn't it? I believe you have that > problem > >> by the wrong end of the stick. National government networks are more > cumbersome, > >> and not more secure, in the main. That's because they're, wait for it, > run by bureaucrats. > >> They danced the risk mitigation dance, and we got wikileaks, infected > thumb drives, > >> virus infestations on supposedly secure networks, and all manner of > silliness. > > > > See, I work as an architect for one of those big vendors (two letters > long), for a national government, managing their base platform > infrastructure (you can go google SOEasy). I /know/ that the risks that > governments face are different to other customers I have worked for, which > is why security is different. > > > > Not every customer needs 5 years of log retention of every event of every > device. Not every customer needs multiple levels of encryption (at rest, at > the file level, end-to-end on the wire). Not every customer needs physically > separate networks. And not every customer needs to keep their DMZ machines > off the domain. > > > >>> That why we don't all blithely implement the same way of doing things. > >>> Because doing things *costs* money (whether that be products, > >>> convenience, productivity etc) > >> > >> And doing them intelligently costs less money than doing them stupidly. > > > > That's not the point. Implementing something as simple as file encryption > incurs *costs*, because you have to start to worry about recovery, about DoS > attacks and so on. > > > > Do *you* encrypt every single file you have on your network? Why not? > Surely it's more secure than not doing it? My guess is that it costs too > much for the benefit you will receive. > > > ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ --- To manage subscriptions click here: http://lyris.sunbelt-software.com/read/my_forums/ or send an email to listmana...@lyris.sunbeltsoftware.com with the body: unsubscribe ntsysadmin
