Re: [fw-wiz] IP/HTTP from the internet to internal network
From: Dave Piscitello (dave@corecom.com)
Date: 12/04/02
- Next message: Eric L Budke: "RE: [fw-wiz] OWA and Risk Assesment"
- Previous message: Eric Vyncke: "Re: [fw-wiz] Firewalls and 802.1q trunking"
- Maybe in reply to: Shimon Silberschlag: "[fw-wiz] IP/HTTP from the internet to internal network"
- Next in thread: Luca Berra: "Re: [fw-wiz] Outlook Web Access - Paranoid?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
From: Dave Piscitello <dave@corecom.com> To: Paul D Robertson <proberts@patriot.net>, Shimon Silberschlag <shimons@bll.co.il> Date: Wed Dec 4 12:39:30 2002
Things I'd consider in addition to Paul's Letterman List:
- application stream inspection/filtering
- if web front end to accommodate input to application server,
an audit of web applications to ferret out CGIs with poor
or no forms input checking, XSS vulnerabilities, and other web
common vulnerabilities
- an "M" series (well, Paul asked for a raise, I need a new car...)
At 08:20 AM 12/2/2002 -0500, Paul D Robertson wrote:
>On Mon, 2 Dec 2002, Shimon Silberschlag wrote:
>
> > When forced by business requirements to _consider_ allowing traffic
> > from the internet, through some application server, to a server on the
> > internal network that holds info for the application, what would be
> > your reaction/design/tools to secure this traffic?
>
>0. Control of the remote machine's configuration and integrity.
>1. Extrememly strong authentication.
>2. A good encrypted transport.
>3. Firewalls between those systems and the rest of the network.
>4. An extra FTE to monitor things.
>5. A raise.
>6. A review of the business's insurance.
>7. A written document absolving me of responsibility for the eventual
>failure.
>8. A direct process into "no longer authorized to access this system" be
>it employee/former-employee data or customer data.
>9. Integrity checking all through the chain.
>A. Data (rather than host) integrity assigned to someone who can
>responsibly handle the task given a compromised endpoint.
>B. A working disaster recovery plan that covers compromise of each
>important piece in the chain.
>C. Complete veto authority over the next seven requests that mirror this,
>but require other important bits of infrastructure to be exposed.
>D. Control of people scope-creeping other "neat" Internet-based
>applications which will eventually make their way onto the machine.
>E. Better logging on everything, with better log servers.
>F. A six month time extension to test the theory that it can be done
>"well enough" *before* the decision to actually do it is made.
>10. The option to pull the site off the 'Net immediately should the
>threat level against any component of the architecture be high enough to
>warrant it. In writing.
>
>Paul
>-----------------------------------------------------------------------------
>Paul D. Robertson "My statements in this message are personal opinions
>proberts@patriot.net which may have no basis whatsoever in fact."
>probertson@trusecure.com Director of Risk Assessment TruSecure Corporation
>
>_______________________________________________
>firewall-wizards mailing list
>firewall-wizards@honor.icsalabs.com
>http://honor.icsalabs.com/mailman/listinfo/firewall-wizards
David M. Piscitello
Core Competence, Inc. &
3 Myrtle Bank Lane
Hilton Head, SC 29926
dave@corecom.com
843.689.5595
www.corecom.com
- Next message: Eric L Budke: "RE: [fw-wiz] OWA and Risk Assesment"
- Previous message: Eric Vyncke: "Re: [fw-wiz] Firewalls and 802.1q trunking"
- Maybe in reply to: Shimon Silberschlag: "[fw-wiz] IP/HTTP from the internet to internal network"
- Next in thread: Luca Berra: "Re: [fw-wiz] Outlook Web Access - Paranoid?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|
|
