Re: [fw-wiz] Defense in Depth to the Desktop

• Previous message: TaylorSC_at_mfe.usmc.mil: "[fw-wiz] Cyberguard Firestar"
• In reply to: Chris Pugrud: "[fw-wiz] Defense in Depth to the Desktop"
• Next in thread: Paul D. Robertson: "Re: [fw-wiz] Defense in Depth to the Desktop"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]

To: "firewall-wizards@honor.icsalabs.com" <firewall-wizards@honor.icsalabs.com>
Date: Tue, 07 Dec 2004 10:45:28 -0000

Sounds a lot like Domain Based Security (not Windows 'domains',
obviously). I did knock a simple paper together once that described
similar concepts, albeit at a 'management' level rather than a 'wiggly
amps' level. It probably needs an overhaul, but can be read at
www.bournemouthbynight.co.uk.

Kev

>
> Defense in Depth to the Desktop
> the Strong Internal Network Defense model
>
> Most organizations have expended large amounts of money and resources in
> strengthening their perimeter defenses, primarily through firewalls and
> similar
> network hardware mechanisms. Additionally, most organizations rely only
> on
> operating system security controls for the internal networks, not
> applying
> strong internal security controls. The lack of strong internal security
> controls is highlighted when the internal network and systems suffer
> catastrophic failure when attackers, malware, and, most destructively,
> worm
> viruses make their way into the network inside the defensive perimeter.
> This
> is the classic "eggshell" weakness of network security, hard and crunchy
> on the
> outside, soft and chewy on the inside. The Strong Internal Network
> Defense
> (SIND) model attempts to address this key vulnerability through the
> application
> of hard internal defenses through network hardware.
>
> Overview
>
> Consider the following example of a simplified network. The network is
> divided
> into two subnets; one subnet contains all of the client systems, while
> the
> second subnet contains all of the servers. The client subnet and the
> server
> subnet are separated by a session based, stateful, packet filtering
> firewall.
> The firewall is unidirectional; it only permits traffic that is
> initiated from
> a client to a server. Servers are allowed to reply to clients, but they
> can
> not initiate communication, TCP or UDP, to a client.
>
> Surprisingly, this example does not break Microsoft or most application
> [*1]
> protocols. The result is counterintuitive, but analysis and testing
> support
> this assertion.
>
> In addition to the firewall, the client systems are fully isolated from
> each
> other by layer 2 controls (private vlans). The servers may be similarly
> isolated, but doing so is minimally effective and damaging to server to
> server
> communications.
>
> Consider the introduction of a zero day worm virus [*2] into such a
> network by
> an infected client. The client can attack all of the servers, and all
> of the
> servers may become infected. The infected client can not attack any of
> the
> other clients because of the layer 2 isolation. The infected servers
> can not
> attack any of the clients because of the firewall. The end result is
> that one
> client and the servers, a small subset of the organization, are
> infected. This
> is much less devastating, and much easier to clean up, than if the entire
> network was infected.
>
> [*1] MAPI, the protocol used by MS Exchange clients (outlook) and the
> server
> has a quirk, acknowledged by Microsoft, affecting new mail notification.
> Despite the presence of a perfectly capable TCP connection from client to
> server, the server sends a small “new mail notification” message to the
> client
> from a random high port, UDP, to a dynamic high port on the client.
> Microsoft
> has acknowledged the issue, as highlighted by using clients through a NAT
> gateway, but does not give an indication that they care to fix it.
>
> [*2] The infamous “zero day worm virus” is invoked as a worse case
> analysis
> because it invalidates anti-virus and patch defense mechanisms. Since
> worms
> are increasingly targeting necessary network ports, personal firewalls
> are also
> equally invalidated as a defense mechanism. Marcus can gleefully dance
> on
> their graves.
>
> Analysis
>
> The primary design of the model is to focus security resources on the
> servers.
> No organization can reasonably maintain strict control over client
> systems, but
> they do have absolute control over making sure that servers are currently
> patched and running the latest AV signatures. The need to keep client
> systems
> on the patch and AV treadmill is greatly diminished. Client systems can
> not
> directly affect the security of other clients systems, they can only
> attempt to
> harm the servers and themselves.
>
> Application protocols that are broken are peer to peer systems and any
> kind of
> desktop file sharing. This is strongly viewed as a good thing in most
> organizations. If I was an attacker going after juicy data the first
> place I
> would look is the poorly secured desktops of the CEO and CFO. Since many
> organization appear to be IDS blind on client segments, I’d probably fly
> under
> the radar as well.
>
> The model can be easily supplemented with port and protocol restrictions
> to
> further protect the servers from the clients.
>
> The model is very easily scalable, the example is for demonstration
> purposes.
> Research suggests the addition of: a tightly protected “master server”
> segment,
> for servers that query clients (server -> client protocols, security
> scanners,
> dhcp, backup servers?); a resources segment for things only used by the
> servers, like printers; the Internet (duh!); and something intuitive
> keeps
> wanting to separate out authorization servers (Domain Controllers) as
> well.
> Draw circles on the white board for each segment with arrows to model the
> firewall, any arrows that point at the clients have the potential to
> infect the
> entire organization, you’ve been warned.
>
> With good IP space management, the model should scale across a WAN.
>
> Questions? (aka, what have I missed?)
>
> Chris
>
>
> _______________________________________________
> firewall-wizards mailing list
> firewall-wizards@honor.icsalabs.com
> http://honor.icsalabs.com/mailman/listinfo/firewall-wizards
>
>

-- 
Kevin Sheldrake MEng MIEE CEng CISSP
Electric Cat (Cheltenham) Ltd
_______________________________________________
firewall-wizards mailing list
firewall-wizards@honor.icsalabs.com
http://honor.icsalabs.com/mailman/listinfo/firewall-wizards

• Previous message: TaylorSC_at_mfe.usmc.mil: "[fw-wiz] Cyberguard Firestar"
• In reply to: Chris Pugrud: "[fw-wiz] Defense in Depth to the Desktop"
• Next in thread: Paul D. Robertson: "Re: [fw-wiz] Defense in Depth to the Desktop"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]