RE: Full Disk Encryption, Digital Signatures and enterprise Data Analysis and Transactional Auditing (eDATA)

["Bob Beringer" <bob () eor us>]

Geoff,

Agreed, which is great for a point to point VPN'ish solution with extra processing power at the NIC level that IPSec 
lacks in and of itself.  

I took my response a bit further, in that with a 3Com'ish solution, a group of systems can still be infected and that 
once infected can generate spoofed traffic that could be used to affect other systems (in normal cases).

Beyond that, would you ever only allow for a server or a series of clients to only connect with each other? And to not 
have access to other systems that didn't have a special NIC in them? To gain the full benefit that you are talking 
about, you almost wind up with a type of hermetically sealed network, and such things don't seem to provide the full 
benefit that other interconnected networks provide. 

Here is another thought, when 3Com'ish systems are to operate in an environment with external connections, it is 
possible that they will become infected, once infected the crypto cert that you mentioned below would then correctly 
authenticate the systems amongst themselves, but would not prevent the spread of the traffic that is less than 
legitimate.  The basic thought being, what is the actual benefit of assured communications that can themselves be 
compromised?

One of the things that would be cool, is a concept that some friends of mine have, that extends from the former 
Authenticated Execution Methodologies and that would extend the NIC Cert, to a Processor Cert, that would then allow 
only applications and solutions that have appropriate cert's and then you could enforce the chain of custody for all 
communications and gain benefit from the offloaded crypto processing.

Until such a thing happens that works on enforcing the legitimacy of comms that are put onto the network stack from 
inside of each host, then we have to look at ways of discriminating against the traffic and developing methods to 
isolate known good traffic from traffic that is not known to be generated by legitimate processes.

I hope this makes sense and I am glad that you have mentioned some good technologies that can definitely benefit folks 
on list...

v/r
Bob

-----Original Message-----
From: gjgowey () tmo blackberry net [mailto:gjgowey () tmo blackberry net] 
Sent: Thursday, September 27, 2007 8:30 PM
To: Bob Beringer
Cc: 'Lafosse, Ricardo'; security-basics () securityfocus com; 'Bob Beringer'; 'Rob Thompson'
Subject: Re: Full Disk Encryption, Digital Signatures and enterprise Data Analysis and Transactional Auditing (eDATA)

By spoofing I meant trying to bypass restrictions that would usually rely on evaluating the MAC address.  A crypto cert 
embedded in the card would easilly provide absolute assurance that the system is indeed supposed to be on the network.  
I wasn't refering to it providing additional protection against external traffic, but that's also true that the crypto 
would only be in affect among themselves providing privacy for all traffic over the wire between those systems.  
However, 3Com also has some sort of central policy management software that, according to the literature, looks like it 
can do a lot in an infrastructure that uses these cards.  

Geoff

Sent from my BlackBerry wireless handheld.

-----Original Message-----
From: "Bob Beringer" <bob.beringer () usa net>

Date: Thu, 27 Sep 2007 19:15:07 
To:<gjgowey () tmo blackberry net>
Cc:"'Lafosse, Ricardo'" <rlafosse () sfwmd gov>,<security-basics () securityfocus com>,"'Bob Beringer'" <bob () eor 
us>,"'Rob Thompson'" <my.security.lists () gmail com>
Subject: Full Disk Encryption, Digital Signatures and enterprise Data Analysis and Transactional Auditing (eDATA)


Geoff,

Thanks for the email, responses inline:

I hate to sound like an adobe sales person (I'm not, but I do like their acrobat line of products), but they have a 
product that serves as a document policy system.  Check out adobe document center.

> > You're right, Adobe makes a great solution for digitally signing documents and for augmenting e-Discovery efforts.  
> > Once we realized a solution was needed in an effort to augment the last FDE effort, we made several attempts to get 
> > Adobe to support a Pilot, but they seemed too busy to help out.  Hopefully, now that I have a bit more time we will 
> > be able to track down the right people and put the solution through an appropriate bake-off with other products, as 
> > we have done in the past with other solution sets...  Presently we know that the solution is much like a hot rod, 
> > but we haven't gotten a chance to put it up on a lift and fully inspect the solution or kick the tires...

Also, I don't like using MAC's for anything including as a computer :-) 

> > Turns out that most of the Executive level clients that I have, "do like them and do use them in support of business 
> > efforts" and that makes them more important to secure and manage than most of the other systems in the enterprise, 
> > (at least for the enterprises that I work with).

or a method of what IP/vlan/access a system can have because pretty much most all NIC's allow you to change their MAC.  

> > Agreed, this is a huge, huge problem!  End Point Awareness, eTelemetry, enterprise Data Analysis and Transactional 
> > Auditing (eDATA), IP Based Transactional Accounting and Layer-8 correlation efforts are all moving towards an 
> > appropriate solution to this problem.

> > One of the projects that I have undertaken is to build a company with a heart, and to start out by "Reuniting all of 
> > the lost and orphaned packets of the world with their Parents (PIDs)".  To that end, we have been working on 
> > enhanced mechanisms for following packet generation from the very soul of the process and all the way through its 
> > logical course of action on the remote system or application.  Packet Based Chain of Custody is the next big 
> > forefront in Internet-Networking Security at all levels around the world.

Now the 3Com cards on the other hand use crypto keys stored right in the card.  I'd like to see that spoofed.

> > I don't want to speak out of turn, but I think that the 3com cards will prevent data and streams from being spoofed 
> > amongst themselves, but not necessarily true for the Layer two indicators when the NIC's send traffic to systems 
> > outside of the gateway, proxy, or even to other systems within the same broadcast domain (to other systems) that 
> > don't have the compatible 3Com cards. 

Hope this makes sense and helps...

v/r
Bob
+12404756858

-----Original Message-----
From: "Rob Thompson" <my.security.lists () gmail com>

Date: Thu, 27 Sep 2007 14:58:32 
To:"Bob Beringer" <bob.beringer () usa net>
Cc:"Lafosse, Ricardo" <rlafosse () sfwmd gov>,security-basics () securityfocus com, "Bob Beringer" <bob () eor us>
Subject: Re: Full Disk Laptop Encryption


On 9/27/07, Bob Beringer <bob.beringer () usa net> wrote:
> MAC agents, I do not know what you are referring to with this.
>
> > > Meant to be "MAC FDE" == FDE for PowerBook, MacBook Pro's, ect...

That's hilarious.  That is NOT at all anything that I had considered.
I was thinking more along the lines of MAC address, networking,
somehow something is being verified that the laptop is encrypted or it
was not allowed on the network or something of the sort...  ;p

> Data-in-Motion - are you talking about data after it has physically
> left your hard drive.  Ie.  e-mail, thumbdrives, network traffic,
> etc...
>
> > > Exactly!  Now encryption can be managed centrally or remotely and can ensure cryptographically based chain of 
> > > custody, from the sectors on the drive, through the Network and then on to the destination system or even to the 
> > > field level in databases that might live on the destination systems as well.  Everything is encrypted at the 
> > > object level, so you can literally have a single word document that allows for three different viewers to see 
> > > different levels of redacted documents or the like (there are many other cool things that their solution does, but 
> > > this is one technique...)

That is pretty nifty.  That type of functionality I didn't even think
was possible.  I will be checking into this for sure.

<snip>
> More setup time and effort is a small price to pay when you have a
> more efficient and properly configured solution deployed.  It is well
> worth the time, IMO.
>
> > > Agreed, but sometimes you want to know that the solution is going to take a bit of effort to properly plan and 
> > > deploy, so that you don't assume it will be less effort and wind up over budget or red in the face due to 
> > > over-committing to the folks around you.  (So it was my way of putting a small disclaimer and friendly heads up, 
> > > so that you know that along with more power comes more responsibility ;-))

I hear you there.  I have found through my excessive blunders in the
computing world that have turned me into the find Computer Nerd that I
am today (If you could only "hear" my sarcasm...  ;p) that it's best
to plan on the worst.  That way, if things actually go as desired and
not as they "do", then you can take that extra time and run out for a
beer or two.

> I will have to check into this TECSEC.  My curiosity is piqued.  Thank
> you for the tip.
>
> > > Ask to talk to Jay Wack and tell him that Bob Beringer sent you, he is a busy man but he is the right guy to talk 
> > > to...
>
> > I hope that this information helps :-)

It sounds like it will.  Funny, I didn't get involved in this thread,
looking for a new vendor.  But I'll have to check into the TECSEC.
It'll be a while, as I'm swamped right now, but I will post my results
some time in the future.  From the sounds of it, it sounds like we may
have an alternative to our current solution.

<snip>
--
Rob