Re: Forest/Domain in the "DMZ" to accomodate web, front-end servers

From: MCSEGURU (mcseguruhere_at_aol.com)
Date: 09/22/05 

Date: Thu, 22 Sep 2005 11:47:27 -0400

Agreed that there are many different philosophies and approaches to the same
goal. I also agree to a point that there are trusted, and un-trusted
separation. I do not agree that there has been "focus" on considering
internal users as risks. Surely for at least a half a decade we've been
cautious of what our "end-users" could access, but how about the application
teams? How about managing their change control to their custom
applications? How about enforcing they use secure code? That is definately
a very new focus in the industry my friend.

Still, I maintain that things are only trusted until otherwise identified,
and as implementation designers and engineers the idea of a trusted anything
assumes we know all that is possible. So depending on the system design as
a whole, things we most commonly define as trusted, really should not be
considered trusted at all. So for the sake of thoroughness, why not
consider all untrusted, and manage all things allowed specifically through
defined passive systems that are managed separately.

Now as for ISA 2004 being a seamless application layer inpspection security
device: While I am quite fond of the product, I won't begin to agree that
it's "out of the box" feature set provides the "layman" with the
managability at the application layer than many of it's competitors. And as
a systems engineer, I usually don't have time to drill down to the
programming of such filters that in my opinion are much better left to the
programmers and regression testing teams at the software provider. I mean,
I could take a linux box and make it an application layer inspection device
out of it too, but I have 500 servers, and 3000 desktops to worry about. I
lack the time to be effective and efficient in building and testing features
with my own custom made solutions, when I could easily go the direction of a
full featured package, and leave the updates and effectiveness testing to
their manpower resources.

If you are only offering HTTP/HTTPS, FTP, SMTP, ISA probably serves your
purposes well at all layers. But if considering using it as a protection
and logging device for "trusted" servers being segmented from LAN clients
where the array of protocols is much larger, the scope in which you will be
defining your "Layer 7" *** I shiver at the techno talk **** filters greatly
increases. Many managers will have alot of homework to do, in terms of verb
usage, malformed strings, etc... So I say, for the layman implementation
engineer, who will likely fail to dig this deep, what's the point of
managing all the doorways, if you're not going to enforce the dress code?
The real goal is to prevent the unknown by allowing only the known, not just
log it. Since ISA 200X's competitors pre-package these filter features
beyond web-traffic, I think there is a higher probability application layer
enforcement will actually get used.

I mean we've all been around. How many really savvy Security Engineers do
you find out there that are actually responsible for implementation? More
likely than not it's the old Consultant and has-been hack.

Again, everyone has an opinion, and understandibly justly so. I mean to
insult to anyone, just my perspective on the industry.

"Steve Clark [MSFT]" <bogus@microsoft.com> wrote in message
news:eDxoijhvFHA.252@TK2MSFTNGP09.phx.gbl...
> Um, I don't know where you came up with the idea that ISA Server doesn't
> perform application layer inspection and filtering, but you are dead wrong
> as it's been doing that since ISA 2000 debuted a number of years ago now.
>
> As to your point about the "internal" threat, this has always been the
> case. In addition to that, the network "edge" is essentially dead as a
> concept and the DMZ is deader than Julius Caesar as a security mechanism.
> Secure the transports, and the conversations to/from hosts. Provide
> isolation of trusted hosts from untrusted hosts. Who cares if untrusted
> hosts compromise other untrusted hosts? Who cares about what "normal"
> looks like on the Internet (or on my large corporate WAN for that matter)?
> I care about the hosts, and the data that resides on them. That is what
> attackers are after: the network is simply and end to a means.
>
> Authenticate users *and* machines. Clearly articulate and document
> policies in companies and provide for enforcement mechanisms for
> non-compliance. Provide enough detail in logging to be useful
> forensically. Have admins work as users unless they are performing
> administrative functions. Don't give admin privileges to non-admins.
>
> Many many more mantras can be placed here.
>
> My point is the network edge is not the place to have all your security.
> Rather, provide defense in depth and let ISA do what it is designed to do,
> and leverage the remaining layer 1-4 hardware to augment that.
>
>
>
>
> "MCSEGURU" <mcseguruhere@aol.com> wrote in message
> news:%23vhi$lXvFHA.3000@TK2MSFTNGP12.phx.gbl...
>>I disagree... While the implementation may be poorly thoughout, and more
>>of a bandaid to satisfy compliance with some directive, I assume network
>>segmentation may be only one goal of the implementation. Logging and
>>intrusion detection may be the driving force for his restrictive
>>architecture, which is becoming more and more sought after by IT auditors.
>>
>> The benefit of a passive firewall device logging all activity, is it's
>> alot harder to spoof at the passive interface, because we don't realize
>> it's there, additionally, should a server be compramised, it's local
>> logging could be totally lost.
>>
>> After all in todays' computer threats, our internal employees present a
>> much higher risk than the internet hacker. Reason being, is we fail to
>> enforce all the security we could on our internal servers we leave many
>> vulnerabilities subject to accidental, or inentional misuse. This
>> includes patches, policies, and account management.
>>
>> Architecture and Infrastructure Security teams can't easily force and
>> manage these patches, configuration lockdowns, and other common
>> oversights our applications teams, business units, and systems teams are
>> implementing, , so the direction to segment all internal PC's from the
>> server segments, and provide restricted port access based on
>> implementation design scopes, allows security manager the control to
>> manage, document and control exposed vulnerabilities much better.
>>
>> It's what I would do. Now would I use ISA 2004, probably not. There are
>> Firewall technologies that manage the actual header conversations, and
>> payload data in addition to the standard port/protocol access, which
>> allows the security managers to really control what's going on with
>> systems to the application layer we all wish we could monitor and log at.
>>
>> My 2 cents.
>
>

Relevant Pages

  • Re: Security Auditing
    ... > My team is responsible for monitoring security event logs on all ISA ... servers. ...
    (microsoft.public.isa)
  • Re: ISA and Exchange 2007
    ... "ISA is just another level of security" - I don't think I've ever heard it ... HTTP-level validation (blocks HTTP-based attacks so your Exch servers ... Jim Harrison (ISA SE) ... The reason I say this is that if you setup OWA correctly and use ...
    (microsoft.public.isa)
  • Re: Hitting specific port on internal IP from outside our network
    ... There is no layer of security there,...only a layer of needless complexity. ... I can understand that as a benefit, but you can do something similar with ISA by ... Microsoft ISA Server Partners: Partner Hardware Solutions ...
    (microsoft.public.isa)
  • Suggestions on Proxy type setup
    ... and accessible from the internet. ... We would like to add another layer of security to those servers. ...
    (comp.os.linux.misc)
  • RE: Front End/Back End communication
    ... MVP -- ISA Firewalls ... There is no such thing as security perfection. ... single front-end/back-end Exchange Server will find this setup to be ...
    (Focus-Microsoft)