[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Looking for Netflow analysis package
- Subject: Looking for Netflow analysis package
- From: mysidia at gmail.com (Jimmy Hess)
- Date: Sat, 18 May 2013 15:58:53 -0500
- In-reply-to: <[email protected]>
- References: <[email protected]>
On 5/17/13, Scott Weeks <surfer at mauigateway.com> wrote:
> owned resources". So don't. Set up an SSH tunnel over port 80 to
> your home server and access your non-paragraph-sized-signature email
> account from home. There's a million ways to do things and still
> follow corporate rules...
The disclaimer requirements seem dumb, but not entirely unreasonable
-- we should just tolerate them. As for spam... no good there.
I would caution against taking the advise of setting up a SSH tunnel
to "follow corporate rules". In some cases, that might be subverting
the intended affects of corporate rules.
The outgoing SSH session (or any encrypted session or tunnel) to an
unapproved non-company resource could still be a policy violation in
some organizations; where they don't already have a firewall that
identifies SSH protocol traffic regardless of TCP port, it is
essentially firewall circumvention.
The same goes for other encrypted or obscured remote access protocols
such as VPNs, IP traffic tunnels, VNC over port 80.
The defeat of e-mail/other network activity usage monitoring, may
impact archiving of mail or compliance with banking, (or other)
Since the SSH session is encrypted, the company's super-expensive
Data Leak Protection software suite may be unable to analyze the
outgoing traffic flow over the network.
It _might_ be a harmless SSH session to post to a mailing list; OR
it might instead be a covert channel for exfiltrating corporate data.
The channel is encrypted... how can you prove the difference?
How can the organization prove that its employees aren't siphoning
customer data out of the database, to satisfy compliance with privacy
In orgs with different priorities, or that haven't addressed certain
risks, it might be OK.
But there will be organizations where it definitely is not OK, so we
should just tolerate the spurious disclaimers.