Re: [Discuss] Security

[Gregory Boyce]

On Wed, Nov 2, 2011 at 1:10 PM,   wrote:
> At my work, here are a few vending machines. One of these machines has a
> nice little antenna on it. Presumably, it communicates via cellular
> network to the vendor in order to report on usage and supplies. Yes, good
> idea. Cool.
>
> It occurs to me that this machine, most likely, did not have to go through
> any vetting. Not only that, I bet the grunts that stock these machines are
> hired more for strong backs and no criminal record.
>
> So, here we have a powered machine with external wireless connectivity on
> the premises with no actual over site. It is there 24x7, powered!
>
> Think of all the cool/evil things you could put in a vending machine with
> a wireless link. Imagine having direct access to a Linux box in almost any
> company you want. You could run any software you want. You could have
> wi-fi too. Could you break the company's wireless security? Could you
> monitor their wireless communications? Could you eaves drop on
> conversations near by?
>
> Everyone suspects the cleaning crew, and if you are interested in
> security, you do background checks. Almost no one cares about the vending
> machines.

There's nothing that device can do to your wilreless network that a
person with a directional antennae can't already do.  As long as you
don't plug it into your internal network, you're not worse off.

As for the eavesdropping, you wouldn't need an obvious antennae for
that.  There could be a camera or microphone in older vending
machines, televisions, coffee machines, fridges, ceiling tiles or even
a cabinet.  These could have less obvious antennas or hey, just have
the recordings picked up occasionally during maintenance.

There's an infinite number of things that "could" happen.  You need to
consider the likelihood and impact of those sorts of attacks.  In most
cases the likelihood is minimal.  Impact is probably minimal as well
unless its in the board room.
___
Discuss mailing list
Discuss@blu.org
http://lists.blu.org/mailman/listinfo/discuss

Re: [Discuss] Security

[Matt Shields]

On Wed, Nov 2, 2011 at 2:05 PM, Gregory Boyce  wrote:

> On Wed, Nov 2, 2011 at 1:10 PM,   wrote:
> > At my work, here are a few vending machines. One of these machines has a
> > nice little antenna on it. Presumably, it communicates via cellular
> > network to the vendor in order to report on usage and supplies. Yes, good
> > idea. Cool.
> >
> > It occurs to me that this machine, most likely, did not have to go
> through
> > any vetting. Not only that, I bet the grunts that stock these machines
> are
> > hired more for strong backs and no criminal record.
> >
> > So, here we have a powered machine with external wireless connectivity on
> > the premises with no actual over site. It is there 24x7, powered!
> >
> > Think of all the cool/evil things you could put in a vending machine with
> > a wireless link. Imagine having direct access to a Linux box in almost
> any
> > company you want. You could run any software you want. You could have
> > wi-fi too. Could you break the company's wireless security? Could you
> > monitor their wireless communications? Could you eaves drop on
> > conversations near by?
> >
> > Everyone suspects the cleaning crew, and if you are interested in
> > security, you do background checks. Almost no one cares about the vending
> > machines.
>
> There's nothing that device can do to your wilreless network that a
> person with a directional antennae can't already do.  As long as you
> don't plug it into your internal network, you're not worse off.
>
> As for the eavesdropping, you wouldn't need an obvious antennae for
> that.  There could be a camera or microphone in older vending
> machines, televisions, coffee machines, fridges, ceiling tiles or even
> a cabinet.  These could have less obvious antennas or hey, just have
> the recordings picked up occasionally during maintenance.
>
> There's an infinite number of things that "could" happen.  You need to
> consider the likelihood and impact of those sorts of attacks.  In most
> cases the likelihood is minimal.  Impact is probably minimal as well
> unless its in the board room.
> ___
> Discuss mailing list
> Discuss@blu.org
> http://lists.blu.org/mailman/listinfo/discuss
>

I think his point was more that these "smart" vending machines are becoming
more commonplace.  Even these days companies put ethernet jacks in the
kitchen, so what *if* someone who was malicious put something inside a
vending machine and plugged it into your network.  Or what if it had
camera/microphone, most people talk shop even in the kitchen.

Speaking of that, I remember a few years ago a company I was at talking
about checking ethernet jacks periodically to make sure no devices were
plugged in that shouldn't be.

Matthew Shields
Owner
BeanTown Host - Web Hosting, Domain Names, Dedicated Servers, Colocation,
Managed Services
www.beantownhost.com
www.sysadminvalley.com
www.jeeprally.com
Like us on Facebook 
Follow us on Twitter 
___
Discuss mailing list
Discuss@blu.org
http://lists.blu.org/mailman/listinfo/discuss

Re: [Discuss] Security

[John Abreau]

Every Ethernet device has a unique MAC address. If you document
every MAC address of all your company's legitimate systems and
devices, then any unknown MAC address will be a rogue device.
Tracking them down should then be fairly straightforward.



On Wed, Nov 2, 2011 at 2:19 PM, Matt Shields  wrote:
> On Wed, Nov 2, 2011 at 2:05 PM, Gregory Boyce  wrote:
>
>> On Wed, Nov 2, 2011 at 1:10 PM,   wrote:
>> > At my work, here are a few vending machines. One of these machines has a
>> > nice little antenna on it. Presumably, it communicates via cellular
>> > network to the vendor in order to report on usage and supplies. Yes, good
>> > idea. Cool.
>> >
>> > It occurs to me that this machine, most likely, did not have to go
>> through
>> > any vetting. Not only that, I bet the grunts that stock these machines
>> are
>> > hired more for strong backs and no criminal record.
>> >
>> > So, here we have a powered machine with external wireless connectivity on
>> > the premises with no actual over site. It is there 24x7, powered!
>> >
>> > Think of all the cool/evil things you could put in a vending machine with
>> > a wireless link. Imagine having direct access to a Linux box in almost
>> any
>> > company you want. You could run any software you want. You could have
>> > wi-fi too. Could you break the company's wireless security? Could you
>> > monitor their wireless communications? Could you eaves drop on
>> > conversations near by?
>> >
>> > Everyone suspects the cleaning crew, and if you are interested in
>> > security, you do background checks. Almost no one cares about the vending
>> > machines.
>>
>> There's nothing that device can do to your wilreless network that a
>> person with a directional antennae can't already do.  As long as you
>> don't plug it into your internal network, you're not worse off.
>>
>> As for the eavesdropping, you wouldn't need an obvious antennae for
>> that.  There could be a camera or microphone in older vending
>> machines, televisions, coffee machines, fridges, ceiling tiles or even
>> a cabinet.  These could have less obvious antennas or hey, just have
>> the recordings picked up occasionally during maintenance.
>>
>> There's an infinite number of things that "could" happen.  You need to
>> consider the likelihood and impact of those sorts of attacks.  In most
>> cases the likelihood is minimal.  Impact is probably minimal as well
>> unless its in the board room.
>> ___
>> Discuss mailing list
>> Discuss@blu.org
>> http://lists.blu.org/mailman/listinfo/discuss
>>
>
> I think his point was more that these "smart" vending machines are becoming
> more commonplace.  Even these days companies put ethernet jacks in the
> kitchen, so what *if* someone who was malicious put something inside a
> vending machine and plugged it into your network.  Or what if it had
> camera/microphone, most people talk shop even in the kitchen.
>
> Speaking of that, I remember a few years ago a company I was at talking
> about checking ethernet jacks periodically to make sure no devices were
> plugged in that shouldn't be.
>
> Matthew Shields
> Owner
> BeanTown Host - Web Hosting, Domain Names, Dedicated Servers, Colocation,
> Managed Services
> www.beantownhost.com
> www.sysadminvalley.com
> www.jeeprally.com
> Like us on Facebook 
> Follow us on Twitter 
> ___
> Discuss mailing list
> Discuss@blu.org
> http://lists.blu.org/mailman/listinfo/discuss
>



-- 
John Abreau / Executive Director, Boston Linux & Unix
Email j...@blu.org / WWW http://www.abreau.net / PGP-Key-ID 0xD5C7B5D9
PGP-Key-Fingerprint 72 FB 39 4F 3C 3B D6 5B E0 C8 5A 6E F1 2C BE 99
___
Discuss mailing list
Discuss@blu.org
http://lists.blu.org/mailman/listinfo/discuss

Re: [Discuss] Security

[markw]

> Every Ethernet device has a unique MAC address. If you document
> every MAC address of all your company's legitimate systems and
> devices, then any unknown MAC address will be a rogue device.
> Tracking them down should then be fairly straightforward.

Little known fact, you can change the mac address in a good number of
devices.
>
>
>
> On Wed, Nov 2, 2011 at 2:19 PM, Matt Shields  wrote:
>> On Wed, Nov 2, 2011 at 2:05 PM, Gregory Boyce 
>> wrote:
>>
>>> On Wed, Nov 2, 2011 at 1:10 PM,   wrote:
>>> > At my work, here are a few vending machines. One of these machines
>>> has a
>>> > nice little antenna on it. Presumably, it communicates via cellular
>>> > network to the vendor in order to report on usage and supplies. Yes,
>>> good
>>> > idea. Cool.
>>> >
>>> > It occurs to me that this machine, most likely, did not have to go
>>> through
>>> > any vetting. Not only that, I bet the grunts that stock these
>>> machines
>>> are
>>> > hired more for strong backs and no criminal record.
>>> >
>>> > So, here we have a powered machine with external wireless
>>> connectivity on
>>> > the premises with no actual over site. It is there 24x7, powered!
>>> >
>>> > Think of all the cool/evil things you could put in a vending machine
>>> with
>>> > a wireless link. Imagine having direct access to a Linux box in
>>> almost
>>> any
>>> > company you want. You could run any software you want. You could have
>>> > wi-fi too. Could you break the company's wireless security? Could you
>>> > monitor their wireless communications? Could you eaves drop on
>>> > conversations near by?
>>> >
>>> > Everyone suspects the cleaning crew, and if you are interested in
>>> > security, you do background checks. Almost no one cares about the
>>> vending
>>> > machines.
>>>
>>> There's nothing that device can do to your wilreless network that a
>>> person with a directional antennae can't already do.  As long as you
>>> don't plug it into your internal network, you're not worse off.
>>>
>>> As for the eavesdropping, you wouldn't need an obvious antennae for
>>> that.  There could be a camera or microphone in older vending
>>> machines, televisions, coffee machines, fridges, ceiling tiles or even
>>> a cabinet.  These could have less obvious antennas or hey, just have
>>> the recordings picked up occasionally during maintenance.
>>>
>>> There's an infinite number of things that "could" happen.  You need to
>>> consider the likelihood and impact of those sorts of attacks.  In most
>>> cases the likelihood is minimal.  Impact is probably minimal as well
>>> unless its in the board room.
>>> ___
>>> Discuss mailing list
>>> Discuss@blu.org
>>> http://lists.blu.org/mailman/listinfo/discuss
>>>
>>
>> I think his point was more that these "smart" vending machines are
>> becoming
>> more commonplace.  Even these days companies put ethernet jacks in the
>> kitchen, so what *if* someone who was malicious put something inside a
>> vending machine and plugged it into your network.  Or what if it had
>> camera/microphone, most people talk shop even in the kitchen.
>>
>> Speaking of that, I remember a few years ago a company I was at talking
>> about checking ethernet jacks periodically to make sure no devices were
>> plugged in that shouldn't be.
>>
>> Matthew Shields
>> Owner
>> BeanTown Host - Web Hosting, Domain Names, Dedicated Servers,
>> Colocation,
>> Managed Services
>> www.beantownhost.com
>> www.sysadminvalley.com
>> www.jeeprally.com
>> Like us on Facebook 
>> Follow us on Twitter 
>> ___
>> Discuss mailing list
>> Discuss@blu.org
>> http://lists.blu.org/mailman/listinfo/discuss
>>
>
>
>
> --
> John Abreau / Executive Director, Boston Linux & Unix
> Email j...@blu.org / WWW http://www.abreau.net / PGP-Key-ID 0xD5C7B5D9
> PGP-Key-Fingerprint 72 FB 39 4F 3C 3B D6 5B E0 C8 5A 6E F1 2C BE 99
> ___
> Discuss mailing list
> Discuss@blu.org
> http://lists.blu.org/mailman/listinfo/discuss
>


___
Discuss mailing list
Discuss@blu.org
http://lists.blu.org/mailman/listinfo/discuss

Re: [Discuss] Security

[markw]

> On Wed, Nov 2, 2011 at 1:10 PM,   wrote:
>> At my work, here are a few vending machines. One of these machines has a
>> nice little antenna on it. Presumably, it communicates via cellular
>> network to the vendor in order to report on usage and supplies. Yes,
>> good
>> idea. Cool.
>>
>> It occurs to me that this machine, most likely, did not have to go
>> through
>> any vetting. Not only that, I bet the grunts that stock these machines
>> are
>> hired more for strong backs and no criminal record.
>>
>> So, here we have a powered machine with external wireless connectivity
>> on
>> the premises with no actual over site. It is there 24x7, powered!
>>
>> Think of all the cool/evil things you could put in a vending machine
>> with
>> a wireless link. Imagine having direct access to a Linux box in almost
>> any
>> company you want. You could run any software you want. You could have
>> wi-fi too. Could you break the company's wireless security? Could you
>> monitor their wireless communications? Could you eaves drop on
>> conversations near by?
>>
>> Everyone suspects the cleaning crew, and if you are interested in
>> security, you do background checks. Almost no one cares about the
>> vending
>> machines.
>
> There's nothing that device can do to your wilreless network that a
> person with a directional antennae can't already do.  As long as you
> don't plug it into your internal network, you're not worse off.


This is, of curse, true, however, having a powered local presence is a lot
more flexible than having to be local with a directional antennae. In
fact, many buildings are not easily accessible.

>
> As for the eavesdropping, you wouldn't need an obvious antennae for
> that.  There could be a camera or microphone in older vending
> machines, televisions, coffee machines, fridges, ceiling tiles or even
> a cabinet.  These could have less obvious antennas or hey, just have
> the recordings picked up occasionally during maintenance.

Also true, but sort of not the point.
>
> There's an infinite number of things that "could" happen.  You need to
> consider the likelihood and impact of those sorts of attacks.  In most
> cases the likelihood is minimal.  Impact is probably minimal as well
> unless its in the board room.
>

That depends on what you want to learn.


___
Discuss mailing list
Discuss@blu.org
http://lists.blu.org/mailman/listinfo/discuss

Re: [Discuss] Security

[Jerry Feldman]

On 11/02/2011 01:10 PM, ma...@mohawksoft.com wrote:
> At my work, here are a few vending machines. One of these machines has a
> nice little antenna on it. Presumably, it communicates via cellular
> network to the vendor in order to report on usage and supplies. Yes, good
> idea. Cool.
>
> It occurs to me that this machine, most likely, did not have to go through
> any vetting. Not only that, I bet the grunts that stock these machines are
> hired more for strong backs and no criminal record.
>
> So, here we have a powered machine with external wireless connectivity on
> the premises with no actual over site. It is there 24x7, powered!
>
> Think of all the cool/evil things you could put in a vending machine with
> a wireless link. Imagine having direct access to a Linux box in almost any
> company you want. You could run any software you want. You could have
> wi-fi too. Could you break the company's wireless security? Could you
> monitor their wireless communications? Could you eaves drop on
> conversations near by?
>
> Everyone suspects the cleaning crew, and if you are interested in
> security, you do background checks. Almost no one cares about the vending
> machines.
The vending machine was placed in your office by Homeland Security
because it thinks you are a terrorist and is currently spying on you :-)

-- 
Jerry Feldman 
Boston Linux and Unix
PGP key id:3BC1EB90 
PGP Key fingerprint: 49E2 C52A FC5A A31F 8D66  C0AF 7CEA 30FC 3BC1 EB90

___
Discuss mailing list
Discuss@blu.org
http://lists.blu.org/mailman/listinfo/discuss

Re: [Discuss] Security

[Matt Shields]

On Wed, Nov 2, 2011 at 4:18 PM, Jerry Feldman  wrote:

> On 11/02/2011 01:10 PM, ma...@mohawksoft.com wrote:
> > At my work, here are a few vending machines. One of these machines has a
> > nice little antenna on it. Presumably, it communicates via cellular
> > network to the vendor in order to report on usage and supplies. Yes, good
> > idea. Cool.
> >
> > It occurs to me that this machine, most likely, did not have to go
> through
> > any vetting. Not only that, I bet the grunts that stock these machines
> are
> > hired more for strong backs and no criminal record.
> >
> > So, here we have a powered machine with external wireless connectivity on
> > the premises with no actual over site. It is there 24x7, powered!
> >
> > Think of all the cool/evil things you could put in a vending machine with
> > a wireless link. Imagine having direct access to a Linux box in almost
> any
> > company you want. You could run any software you want. You could have
> > wi-fi too. Could you break the company's wireless security? Could you
> > monitor their wireless communications? Could you eaves drop on
> > conversations near by?
> >
> > Everyone suspects the cleaning crew, and if you are interested in
> > security, you do background checks. Almost no one cares about the vending
> > machines.
> The vending machine was placed in your office by Homeland Security
> because it thinks you are a terrorist and is currently spying on you :-)
>
> --
> Jerry Feldman 
> Boston Linux and Unix
> PGP key id:3BC1EB90
> PGP Key fingerprint: 49E2 C52A FC5A A31F 8D66  C0AF 7CEA 30FC 3BC1 EB90
>
> ___
> Discuss mailing list
> Discuss@blu.org
> http://lists.blu.org/mailman/listinfo/discuss
>

Actually it was placed there by insurance companies so they can get out of
having to pay for your medical bills.

Matthew Shields
Owner
BeanTown Host - Web Hosting, Domain Names, Dedicated Servers, Colocation,
Managed Services
www.beantownhost.com
www.sysadminvalley.com
www.jeeprally.com
Like us on Facebook 
Follow us on Twitter 
___
Discuss mailing list
Discuss@blu.org
http://lists.blu.org/mailman/listinfo/discuss

Re: [Discuss] Security

[Gregory Boyce]

On Wed, Nov 2, 2011 at 2:19 PM, Matt Shields  wrote:

> I think his point was more that these "smart" vending machines are becoming
> more commonplace.  Even these days companies put ethernet jacks in the
> kitchen, so what *if* someone who was malicious put something inside a
> vending machine and plugged it into your network.  Or what if it had
> camera/microphone, most people talk shop even in the kitchen.
> Speaking of that, I remember a few years ago a company I was at talking
> about checking ethernet jacks periodically to make sure no devices were
> plugged in that shouldn't be.

If rogue devices on your network is a concern, then there are ways to
combat that problem.  Implement 802.1X for network authentication, or
NAC.  Look at anomaly based IDS devices to detect unusual behavior, or
signature based IDS to detect known threats.  Monitor your switches so
you know when new devices are plugged into the network.

"Rogue Vending machine" strikes me as a movie theater threat.  Rogue
devices can be a very real problem, but you're much more likely to be
hit by a users virus infected home laptop or potentially a malicious
device other than a vending machine.  Bring up a specific threat like
this one, and you'll find management talking about implementing some
sort of hardware review for on site equipment, rather than something
that would also find the more common threats.
___
Discuss mailing list
Discuss@blu.org
http://lists.blu.org/mailman/listinfo/discuss

Re: [Discuss] Security

[Richard Pieri]

On Nov 2, 2011, at 8:41 PM, Gregory Boyce wrote:
> 
> "Rogue Vending machine" strikes me as a movie theater threat.  Rogue
> devices can be a very real problem, but you're much more likely to be
> hit by a users virus infected home laptop or potentially a malicious
> device other than a vending machine.

Case in point: a few gigs back we got hit by Slammer on the inside of our 
firewalled network.  It wasn't ourselves.  It was a visiting vendor or some 
such who brought it in on his own laptop and it spread when he plugged it into 
our network.

Another case in point:
http://tech.mit.edu/V131/N30/swartz.html

--Rich P.

___
Discuss mailing list
Discuss@blu.org
http://lists.blu.org/mailman/listinfo/discuss

Re: [Discuss] Security

[dan]

> Case in point: a few gigs back we got hit by Slammer on the inside
> of our firewalled network.  It wasn't ourselves.  It was a visiting
> vendor or some such who brought it in on his own laptop and it
> spread when he plugged it into our network.

Not trying to open a rathole, but are any of ya'll dealing
with "consumerization"?  ("Bring-your-PC-to-work," etc.)

--dan

ref: GE CIO
http://www.slideshare.net/SOURCEConference/james-beeson-source-boston-2011

___
Discuss mailing list
Discuss@blu.org
http://lists.blu.org/mailman/listinfo/discuss

Re: [Discuss] Security

[Dan Ritter]

On Wed, Nov 02, 2011 at 09:33:18PM -0400, d...@geer.org wrote:
> 
> > Case in point: a few gigs back we got hit by Slammer on the inside
> > of our firewalled network.  It wasn't ourselves.  It was a visiting
> > vendor or some such who brought it in on his own laptop and it
> > spread when he plugged it into our network.
> 
> Not trying to open a rathole, but are any of ya'll dealing
> with "consumerization"?  ("Bring-your-PC-to-work," etc.)


Everyone wants to connect their iPad or phone... so we got a
cheap cable modem from Comcast, wired up a WiFi router, and 
let them play. 

No more privileges than a Starbucks. Highly recommended.


-dsr-

___
Discuss mailing list
Discuss@blu.org
http://lists.blu.org/mailman/listinfo/discuss

Re: [Discuss] Security

[Daniel Feenberg]

On Wed, 2 Nov 2011, Dan Ritter wrote:


On Wed, Nov 02, 2011 at 09:33:18PM -0400, d...@geer.org wrote:



Case in point: a few gigs back we got hit by Slammer on the inside
of our firewalled network.  It wasn't ourselves.  It was a visiting
vendor or some such who brought it in on his own laptop and it
spread when he plugged it into our network.


Not trying to open a rathole, but are any of ya'll dealing
with "consumerization"?  ("Bring-your-PC-to-work," etc.)



Everyone wants to connect their iPad or phone... so we got a
cheap cable modem from Comcast, wired up a WiFi router, and
let them play.


You don't really need a separate uplink - just connect the visiting 
hardware upstream of the firewall.


Daniel Feenberg
NBER



No more privileges than a Starbucks. Highly recommended.


-dsr-

___
Discuss mailing list
Discuss@blu.org
http://lists.blu.org/mailman/listinfo/discuss


___
Discuss mailing list
Discuss@blu.org
http://lists.blu.org/mailman/listinfo/discuss

Re: [Discuss] Security

[Dan Ritter]

On Thu, Nov 03, 2011 at 07:56:41AM -0400, Daniel Feenberg wrote:
> 
> 
> On Wed, 2 Nov 2011, Dan Ritter wrote:
> 
> >Everyone wants to connect their iPad or phone... so we got a
> >cheap cable modem from Comcast, wired up a WiFi router, and
> >let them play.
> 
> You don't really need a separate uplink - just connect the visiting
> hardware upstream of the firewall.

I can point to complete physical separation when the auditors
come. That's worth more than the Comcast bill.

-dsr-


-- 
http://tao.merseine.nu/~dsr/eula.html is hereby incorporated by reference.
You can't fight for freedom by taking away rights.
___
Discuss mailing list
Discuss@blu.org
http://lists.blu.org/mailman/listinfo/discuss

Re: [Discuss] Security

[Tom Metro]

Dan Ritter wrote:
> Everyone wants to connect their iPad or phone... so we got a
> cheap cable modem from Comcast, wired up a WiFi router, and 
> let them play. 

Good approach. Obviously it can also be implemented using appropriate
router/firewall/VLAN rules, rather than a physically separate WAN
connection.


> I can point to complete physical separation when the auditors
> come. That's worth more than the Comcast bill.

Sure, but aren't there dozens of other places in your infrastructure
where your security *is* dependent on firewall rules, and thus you still
need to assure the auditors of the integrity of those systems?


I bet when these "foreign" devices need access to the corporate network,
you're still using a VPN, which then makes the whole corporate LAN
accessible to the infected machine.

I get that it can be complicated to forward specific ports (via ssh or
otherwise), but never got why large corporations were always so willing
to completely open their internal networks to their employee's home
computers, and always preferred VPNs to port forwarding (which I find
far simpler to setup, than a VPN client).

 -Tom

-- 
Tom Metro
Venture Logic, Newton, MA, USA
"Enterprise solutions through open source."
Professional Profile: http://tmetro.venturelogic.com/
___
Discuss mailing list
Discuss@blu.org
http://lists.blu.org/mailman/listinfo/discuss

Re: [Discuss] Security

[Dan Ritter]

On Thu, Nov 03, 2011 at 05:43:13PM -0400, Tom Metro wrote:
> > I can point to complete physical separation when the auditors
> > come. That's worth more than the Comcast bill.
> 
> Sure, but aren't there dozens of other places in your infrastructure
> where your security *is* dependent on firewall rules, and thus you still
> need to assure the auditors of the integrity of those systems?

Yes... and we don't let random devices from outside connect to
them. If a visitor comes in with a computer, they get to use the
WiFi.

> I bet when these "foreign" devices need access to the corporate network,
> you're still using a VPN, which then makes the whole corporate LAN
> accessible to the infected machine.
> 
> I get that it can be complicated to forward specific ports (via ssh or
> otherwise), but never got why large corporations were always so willing
> to completely open their internal networks to their employee's home
> computers, and always preferred VPNs to port forwarding (which I find
> far simpler to setup, than a VPN client).

Actually, we don't have a VPN. We use SSH port forwarding, as you
describe.

Less sophisticated users know that they click on the icon we provide
which opens a shell window which asks for their passphrase. They
don't particularly know that they have a key which is guarded by that
passphrase, or that their browser is configured with an autoproxy that
recognizes our internal domain names (different from the outside one)
and routes those requests over the SSH forwarding tunnel.

Locking them out is a simple matter of disabling their accounts on the
small number of machines that serve as SSH gateways.

Glamorous and sexy? No. Works really well, with well-understood
failure modes? Yes.

-dsr-

___
Discuss mailing list
Discuss@blu.org
http://lists.blu.org/mailman/listinfo/discuss

Re: [Discuss] Security

[Jerry Feldman]

On 11/02/2011 08:54 PM, Richard Pieri wrote:
> On Nov 2, 2011, at 8:41 PM, Gregory Boyce wrote:
>> "Rogue Vending machine" strikes me as a movie theater threat.  Rogue
>> devices can be a very real problem, but you're much more likely to be
>> hit by a users virus infected home laptop or potentially a malicious
>> device other than a vending machine.
> Case in point: a few gigs back we got hit by Slammer on the inside of our 
> firewalled network.  It wasn't ourselves.  It was a visiting vendor or some 
> such who brought it in on his own laptop and it spread when he plugged it 
> into our network.
>
> Another case in point:
> http://tech.mit.edu/V131/N30/swartz.html
>
>
When we set up our internal conference room, I set up 1 ethernet port to
connect to the Regus Office network. I did this because we use the room
for training. In addition, our 2 wireless routers are set to WPA + MAC
address authentication. Regus also has WiFI and I give vendors and
clients the password for Regus. Of course that does not solve the
problem when you have a visiting employee from a Rogue nation like
Canada :-).

-- 
Jerry Feldman 
Boston Linux and Unix
PGP key id:3BC1EB90 
PGP Key fingerprint: 49E2 C52A FC5A A31F 8D66  C0AF 7CEA 30FC 3BC1 EB90

___
Discuss mailing list
Discuss@blu.org
http://lists.blu.org/mailman/listinfo/discuss

Re: [Discuss] Security

[Tom Metro]

Dan O'Donovan wrote:
> Hsuan-Yeh Chang wrote:
>> Is there a way to encrypt data stored with cloud services (such as
>> dropbox) that can be decrypted only by the data owner...
> 
> Sure it can, but one of the reasons that DropBox is great is because
> it saves incremental backups of your files (tracking changes and the
> like). If you start encrypting them you loose this...

Not only is the problem solvable, but there are existing open source
(rsyncrypto) and and commercial (Wuala) solutions.

The only real challenge a DropBox-like service faces when implementing
client-side encryption is one of convenience - such as how do you
provide the user with access to their files if all they have is a web
browser? Decryption would need to be done in Java or JavaScript, and the
user would have to have their key, or an adequately strong passphrase to
generate a key. It's the usability challenges that undoubtedly led to
DropBox taking the less secure approach.


Cloud storage is easy compared to securing cloud applications. With the
latter the affiliated application data needs to be unencrypted in order
for the application to interact with it.

There is, however, a researcher at IBM who is working on a type of
encryption that makes it possible to perform certain mathematical
operations on encrypted data, such that the transformation persists
after decryption. If this worked, you'd upload encrypted data to the
cloud, process it in the cloud while still encrypted, and finally
download and decrypt it. It sounds like something that will never be
possible in the general case (more than for a few specific mathematical
transformations).

About the best you can hope for is a cloud vendor that uses an
architecture where your login generates a key and your data gets
decrypted on the fly. When you log out, the key gets flushed from
memory, and your data resumes being inaccessible to anyone but you.


> Hsuan-Yeh Chang wrote:
>> If I send an e-mail (with attachment) from Gmail to Hotmail, would
>> both Google and Microsoft keep this e-mail on their respective servers
>> forever?

No, not if you delete it. (Though backups are a different story.)

Many people don't realize it, but it is possible to purge messages out
of a Gmail account. I have a few Gmail hosted accounts, and I
periodically purge all the messages out of them.

 -Tom

-- 
Tom Metro
Venture Logic, Newton, MA, USA
"Enterprise solutions through open source."
Professional Profile: http://tmetro.venturelogic.com/
___
Discuss mailing list
Discuss@blu.org
http://lists.blu.org/mailman/listinfo/discuss

Re: [Discuss] Security through obscurity

[Tom Metro]

[Please update subjects when a thread veers off to a distinctly
different topic.]

Derek Martin wrote:
> Rich Pieri wrote:
>> Security by obscurity is no security at all.
>  
> This is a popular mantra of paid security professionals, but it is a
> fallacy, and in fact is a tool that those very same people employ
> every day (e.g. recommendations to run ssh servers on non-standard
> ports, configure servers to respond with non-default banners, etc.).
> The benefits of such measures often amount to foiling script kiddies
> who may otherwise compromise your otherwise vulnerable system with
> zero effort, but that itself can be a big win, since this is the
> overwhelming majority of attack traffic that most sites see.

We're getting a bit wrapped up in dogma. This isn't a black-and-white
issue. If you take a broad enough definition of "obscurity" it could be
taken to mean your knowledge of a password - it's obscure, you know it,
and yet it's guessable, just like the oddball port your service is
running on.

It has already been mentioned that the reason why security through
obscurity is generally considered bad, is because it is often used as an
excuse for having lax real security. (For example, in the scenario
above, the owners of the service running on a non-standard port should
not be slow to install security updates to their service, thinking they
are safe merely because they are using a non-standard port. Although
statistically speaking, they are indeed safer than if they weren't using
a non-standard port, as the vast majority of attack attempts are
unsophisticated scripts. [Before you jump to dispute that, note I said
*statistically* speaking.])

There's really no reason why a system administrator should reject an
obscurity layer, if their security fundamentals are already good, as
long as in their judgment the obscurity doesn't impact their users. (For
example, picking a non-standard VPN port can have near zero impact, as
VPN setup is a one-time thing, and you're already supplying the user
with setup documentation covering numerous parameters. Or you're using a
custom pre-configured client.)

But the real value in obscurity measures is cutting down on noise, which
doesn't directly impact security, but can indirectly help it by making
real attacks far more visible, and avoid alarm fatigue. You're merely
filtering out the nuisance.

For example, if you can use a non-standard ssh port without impacting
your users, and you log and monitor attack attempts against it (as you
should), switching to a non-standard port will reduce those logged
attacks to virtually zero. That's useful.

 -Tom

-- 
Tom Metro
Venture Logic, Newton, MA, USA
"Enterprise solutions through open source."
Professional Profile: http://tmetro.venturelogic.com/
___
Discuss mailing list
Discuss@blu.org
http://lists.blu.org/mailman/listinfo/discuss

Re: [Discuss] Security through obscurity

[Rich Pieri]

--On Wednesday, March 27, 2013 6:42 PM -0400 Tom Metro 
 wrote:



We're getting a bit wrapped up in dogma. This isn't a black-and-white
issue. If you take a broad enough definition of "obscurity" it could be
taken to mean your knowledge of a password - it's obscure, you know it,
and yet it's guessable, just like the oddball port your service is
running on.


Passwords aren't obscured things. They're supposed to be secrets. A 
password that is not a secret but merely obscured is a password that has 
been compromised.




There's really no reason why a system administrator should reject an
obscurity layer, if their security fundamentals are already good, as
long as in their judgment the obscurity doesn't impact their users. (For


If the fundamentals are good then the obscurity layer adds no tangible 
security to the system while at the same time making the system more 
inconvenient for users. If the fundamentals aren't good then obscurity 
provides only a semblance of security while adding the same layer of 
inconvenience for users. Either way, obscurity is of no benefit to either 
security or to those who use the system.


Obscurity makes it harder to manage the system. I can't use standard tools 
to monitor my services if they're not running on standard ports and 
protocols. I can't automatically install system and security updates with 
cron-apt; I have to validate every non-standard change. This makes my job 
that much more difficult. It is prone to mistakes and unforeseen 
consequences, and as a direct result makes the whole system that much less 
secure and reliable.


I'd say that's more than enough reason to say "no" to obfuscation.



But the real value in obscurity measures is cutting down on noise, which
doesn't directly impact security, but can indirectly help it by making
real attacks far more visible, and avoid alarm fatigue. You're merely
filtering out the nuisance.


I want that "noise" because it isn't noise. It's useful information.

In terms of security, that "noise" can be used to tune passive and active 
defenses, much like how a corpus of spam can be used to train a spam 
filtering engine. If I don't have that "noise" then it's harder to tune my 
security rules. Genuine noise, the genuinely useless information, can be 
masked out of sight. It's there if I come to need it but it doesn't get in 
the way of immediate work.


In terms of finances, having a huge list of attack logs can be used to 
justify the expense of intrusion detection and prevention systems. If I 
don't have that "noise" then I can't show the fiscal office anything 
tangible to justify the expense of intrusion detection and prevention 
systems. As a matter of fact, yes, I have once been asked to provide such 
logs for such purposes.


Unintended consequences, indeed.

--
Rich P.
___
Discuss mailing list
Discuss@blu.org
http://lists.blu.org/mailman/listinfo/discuss

Re: [Discuss] Security through obscurity

[Tom Metro]

Rich Pieri wrote:
> Tom Metro wrote:
>> We're getting a bit wrapped up in dogma. This isn't a black-and-white
>> issue. If you take a broad enough definition of "obscurity" it could be
>> taken to mean your knowledge of a password - it's obscure, you know it,
>> and yet it's guessable, just like the oddball port your service is
>> running on.
> 
> Passwords aren't obscured things. They're supposed to be secrets. A
> password that is not a secret but merely obscured is a password that has
> been compromised.

This is exactly my point...it's a spectrum of complexity, without a
crisp delineation between what is obscurity and what is secret.

Choosing a port number from a space of 65535 possibilities is exactly
identical to choosing a password with 16-bits of strength, provided both
lack measures to prevent brute force attacks.

You could, if you so desired, have a port knocking client that
translated a pass phrase with 40+ bits of strength into a knock
sequence. Now is this a secrete or is it still just obscure?

Obscure, in most security contexts, is just a synonym for weak strength.
What you consider to be weak is subjective, and relative to the threat
scenarios.


> I want that "noise" because it isn't noise. It's useful information.

If you find it so, then good for you. Others consider it useless noise,
and it detracts from more valuable signals.


> ...that "noise" can be used to tune passive and
> active defenses, much like how a corpus of spam can be used to train a
> spam filtering engine. If I don't have that "noise" then it's harder to
> tune my security rules.

Sure, in some contexts, I agree completely.

 -Tom

-- 
Tom Metro
Venture Logic, Newton, MA, USA
"Enterprise solutions through open source."
Professional Profile: http://tmetro.venturelogic.com/
___
Discuss mailing list
Discuss@blu.org
http://lists.blu.org/mailman/listinfo/discuss

Re: [Discuss] Security through obscurity

[Derek Martin]

On Wed, Mar 27, 2013 at 08:19:12PM -0400, Rich Pieri wrote:
> --On Wednesday, March 27, 2013 6:42 PM -0400 Tom Metro
>  wrote:
> 
> >We're getting a bit wrapped up in dogma. This isn't a black-and-white
> >issue. If you take a broad enough definition of "obscurity" it could be
> >taken to mean your knowledge of a password - it's obscure, you know it,
> >and yet it's guessable, just like the oddball port your service is
> >running on.
> 
> Passwords aren't obscured things. They're supposed to be secrets. A
> password that is not a secret but merely obscured is a password that
> has been compromised.

You're being pointlessly pedantic... the words "secret" and "obscure"
are near-synonyms, and Tom already stipulated a broad definition of
"obscure".

> >There's really no reason why a system administrator should reject an
> >obscurity layer, if their security fundamentals are already good, as
> >long as in their judgment the obscurity doesn't impact their users. (For
> 
> If the fundamentals are good then the obscurity layer adds no
> tangible security to the system while at the same time making the
> system more inconvenient for users. 

Not true.  As I've already said, it slows down your attacker.  They
can't immediately attack you with a known vulnerability; they need to
first expend some effort to determine where you're vulnerable.
Depending on what you're running, and what they're targeting, this
could take a couple of minutes, or it could take a couple of days...

But it can do more than that.  Take the case of a zero-day exploit to
a public service your site MUST provide, let's say Apache.  Your
security is as good as it can reasonably be, but your system is
vulnerable and there's no possible way you can know; the information
isn't available to anyone but the attacker.  But he writes an exploit
and posts it on some hacker site, and it's immediately picked up by
some script kiddie and run against your site.

Historically, a number of such exploits actually check the response
from your server to see if it's vulnerable, and move on if it does not
recognize the server as being the target.  Here, a little security
through obscurity--shutting off ServerSignature and changing the
Server: response header via a feature of mod_security--could very well
save your site, where no other measure you're likely to be able to
implement would.

And the impact to users of changing your welcome banner?  Zero.

Will doing this always save you?  Absolutely not.  If the script
doesn't bother to check the response but just assumes you're
vulnerable and always executes the attack, you lose.  If a
knowledgeable attacker finds the exploit and targets you directly,
chances are you lose... but maybe not, depending on how serious he
is.

There's a significant statistical probability that making such a
change will save you from a number of attacks, and the cost of making
the change at implementation time is very nearly zero.  So why
WOULDN'T you do it?

> Obscurity makes it harder to manage the system. I can't use standard
> tools to monitor my services if they're not running on standard
> ports and protocols. 

Maybe, probably not.  A reasonable tool will let you specify where the
service is running.

> I can't automatically install system and security updates with
> cron-apt; 

In the example I gave, this is not prevented: cron-apt does not muck
with your server configuration.  If you modify your error document, it
doesn't muck with those either.  This is unlikely to ever be an issue
unless you need to modify code to do it.

> I have to validate every non-standard change. 

In practice, not likely... in many such cases it's a trivial config
change.

> This makes my job that much more difficult. It is prone to mistakes
> and unforeseen consequences, and as a direct result makes the whole
> system that much less secure and reliable.

In some cases perhaps, but in most security-concious apps which have
facilities for this sort of thing, absolutely not.

> >But the real value in obscurity measures is cutting down on noise, which
> >doesn't directly impact security, but can indirectly help it by making
> >real attacks far more visible, and avoid alarm fatigue. You're merely
> >filtering out the nuisance.
> 
> I want that "noise" because it isn't noise. It's useful information.

Sometimes.   Like with a host-based IDS, you want a little noise, so
you know the tools are doing their job.  For a web server, which
recieves hundreds of thousands connections, a significant percentage
of which are virtually guaranteed to be some sort of attack traffic,
it really is just noise.  If you can get rid of it, seems like a good
thing to me.

> If I don't have that "noise" then I can't show the fiscal
> office anything tangible to justify the expense of intrusion
> detection and prevention systems. As a matter of fact, yes, I have
> once been asked to provide such logs for such purposes.

If you need to, you can always shut them off...  But I would just 

Re: [Discuss] Security through obscurity

[Rich Pieri]

--On Wednesday, March 27, 2013 8:47 PM -0400 Tom Metro 
 wrote:



This is exactly my point...it's a spectrum of complexity, without a
crisp delineation between what is obscurity and what is secret.


Either a password is a secret (known to authorized personnel) or it isn't. 
That's not a "spectrum of complexity". It's a yes/no fact.



You could, if you so desired, have a port knocking client that
translated a pass phrase with 40+ bits of strength into a knock
sequence. Now is this a secrete or is it still just obscure?


In principle it's a secret. In practice 25 years ago it would have been 
considered a secret since exhaustive search of a 40-bit keyspace was 
considered to be prohibitively costly. In practice today an exhaustive 
search of a 40-bit keyspace takes about 3 seconds.



Obscure, in most security contexts, is just a synonym for weak strength.
What you consider to be weak is subjective, and relative to the threat
scenarios.


Obscure, in serious security contexts, is synonymous with NO strength 
regardless of threat scenarios.




If you find it so, then good for you. Others consider it useless noise,
and it detracts from more valuable signals.


Anyone who thinks that way hasn't figured out how to use the tools they 
have or hasn't switched to using tools that do what is needed.


--
Rich P.
___
Discuss mailing list
Discuss@blu.org
http://lists.blu.org/mailman/listinfo/discuss

Re: [Discuss] security through obscurity

[Derek Martin]

On Thu, Mar 28, 2013 at 10:49:57AM -0400, Rich Pieri wrote:
> That's what I find so amusing about security discussions like this.
> So many get caught up with the idea of keeping attackers out or
> slowing them down without really thinking about how to protect
> what's actually of value.

I fully acknowledge this point, and I never said anything to the
contrary.  This in no way indicates that obfuscation has no value.  

> The right way to secure a public-facing server is to start by
> assuming that it will be compromised. 

There's truth to this--from a risk management perspective.  Don't risk
exposing things that would be expensive if they were exposed, unless
it's essential to do so.

But it's also very defeatist.  I have on several occasions discovered
an intrusion in progress and shut the attacker down, never to be heard
from again.  Most attackers in practice are robots, and will simply fail
with the slightest interruption.

> An attacker -- be he a script kiddie or a pro turned black hat --
> will find a way in regardless of what you do. 

This is nonsense.  A script kiddie will go away after at most a
handful of meager attempts.  A well-informed, extremely determined
attacker who is explicitly targeting YOU will find a way in, IF he has
sufficient motivation to STAY determined in the face of your defenses.
The underwhelming minority of attacks fall into this category.  There
is an entire universe of grey in between.

But even in the cases that start to fall into the extreme category,
time is your friend.  If you can put enough barriers in place, and
have tools for detecting the intrusion *while it is happening*, you
may be able to shut down the attack.  You may be able to convince your
foe that you really are not worth the effort.  Or, if you yourself are
determined to prevent intrusion, you may be able to keep your foe
engaged long enough to involve the authorities and have him
incarcerated.  I've never personally been involved in a case of this,
but I've met people who have.

Making it hard for your attacker to find what he's looking for is
a very cheap and useful part of preventing him from getting it.  It is
very much a part of security in depth, in fact eliminating many
attacks before they even begin.  You just need to be prepared for when
it fails.

-- 
Derek D. Martinhttp://www.pizzashack.org/   GPG Key ID: 0xDFBEAD02
-=-=-=-=-
This message is posted from an invalid address.  Replying to it will result in
undeliverable mail due to spam prevention.  Sorry for the inconvenience.

___
Discuss mailing list
Discuss@blu.org
http://lists.blu.org/mailman/listinfo/discuss

Re: [Discuss] security through obscurity

[Richard Pieri]

On 3/28/2013 2:21 PM, Derek Martin wrote:
> This is nonsense.  A script kiddie will go away after at most a
> handful of meager attempts.  A well-informed, extremely determined

Wow. You utterly missed the point. When I say "assume an attacker will
get in" it's not a statement of fact. It's a statement of philosophy.
It's an assumption. I *HOPE* it's wrong. I *HOPE* that my perimeter
security is good enough to deter both the script kiddie and the pro. But
I still assume that it isn't because I know that I can't defend against
every conceivable attack and exploit.

I believe it was you who mentioned bank vaults. A public-facing server
isn't the vault. It isn't the contents of the vault. It's the door to
the bank lobby. I can't secure the front door anywhere near as well as I
can secure the vault. What I can do is rigorously control access between
the door and the vault. This is detection and containment. This is where
I detect the intruder, analyze the attack, and shut it down permanently.

If you think that hanging a curtain over the front door when the bank is
closed is any security at all then by all means do whatever makes you
feel better.

-- 
Rich P.
___
Discuss mailing list
Discuss@blu.org
http://lists.blu.org/mailman/listinfo/discuss

Re: [Discuss] security through obscurity

[Derek Martin]

On Thu, Mar 28, 2013 at 02:51:05PM -0400, Richard Pieri wrote:
> On 3/28/2013 2:21 PM, Derek Martin wrote:
> > This is nonsense.  A script kiddie will go away after at most a
> > handful of meager attempts.  A well-informed, extremely determined
> 
> Wow. You utterly missed the point. When I say "assume an attacker will
> get in" it's not a statement of fact. It's a statement of philosophy.

I utterly did not.  I addressed that directly, in the part you didn't
quote, about risk management.  What I'm attempting to point out is that 
it's a very narrow philosophy.  You should not assume that your
measure will work; but you should expect that they will work
*sometimes*, and understand the value of that.  There are measures you
can take which are cheap and which will ELIMINATE low-hanging fruit,
whereas the more "thorough" approach which ignores those may allow
them to mount their attack, and by some miracle penetrate your
otherwise excellent defenses.  Like my zero-day example.

> I believe it was you who mentioned bank vaults. 

It wasn't, but no matter.

> I can't secure the front door anywhere near as well as I can secure
> the vault. What I can do is rigorously control access between the
> door and the vault. 

Surely by now you understand that this point is not lost on me, nor 
have I ever said you should ignore such concerns in favor of security
PURELY by obscurity, or anything remotely similar.  My premise
throughout simply has been that security by obscurity has its place,
and can be an effective tool.   What I've taken issue with is your
absolute rejection of the idea that it can provide any value whatever.

> If you think that hanging a curtain over the front door when the bank is
> closed is any security at all 

I don't.  But if your bank is made of 6-foot thick stone and the door
is the only practical means of entry, then making the door hard to find
IS.  It greatly improves the chances that the cops will drive by and
notice some dudes behaving oddly around an obvious target, before they
manage to gain entry.  Sure you COULD blast a hole in the outer
wall... someone's going to notice that pretty quick, it tends to make
a racket.

Popes and Presidents alike have made use of that very technique for
centuries for a slightly different purpose (but still well within the
purview of security): to escape harm or threat from an attacker, using
an obscured door to an obscured passageway to another obscured door,
their attackers meanwhile unaware that their prey has long since
absconded undetected.

-- 
Derek D. Martinhttp://www.pizzashack.org/   GPG Key ID: 0xDFBEAD02
-=-=-=-=-
This message is posted from an invalid address.  Replying to it will result in
undeliverable mail due to spam prevention.  Sorry for the inconvenience.

___
Discuss mailing list
Discuss@blu.org
http://lists.blu.org/mailman/listinfo/discuss

Re: [Discuss] security through obscurity

[Richard Pieri]

On 3/28/2013 7:01 PM, Derek Martin wrote:
> I utterly did not.  I addressed that directly, in the part you didn't

No. You did miss it.

In my model I'm less concerned if an intruder exploits a zero-day
vulnerability in mod_ssl than you are. Said intruder is trapped in the
DMZ between web server and whatever is behind it. Yes, he's compromised
a web server but that's ALL that he's compromised. And once any
anomalous activity is detected I can shut him down, identify how he got
in, close that off, and swap in a clean and fixed server.

I'm not ignoring perimeter security. It's best if attackers don't get in
at all. But I'm not one for relying on the chance that some misdirection
will prevent intrusion. I'm not one for relying on the chance that
someone will spot the attempts before they succeed. Chance, by
definition, is not reliable.

As for the secret escape routes? Those aren't perimeter security. There
a last resort when everything else has failed and the alternative is
death or capture. And historically, they're not particularly reliable.

-- 
Rich P.
___
Discuss mailing list
Discuss@blu.org
http://lists.blu.org/mailman/listinfo/discuss

Re: [Discuss] security through obscurity

[Tom Metro]

One person wrote:
> Wow. You utterly missed the point.

And another wrote:
> I utterly did not.

Keep in mind when you participate in threads like this that your
audience is the BLU readership, and not the individual that happens to
be constantly posting counter arguments. Have confidence that you've
made your point clearly enough that the rest of us have gotten it, and
that we're smart enough to conclude which perspective makes more sense,
and let the thread drop.

 -Tom

-- 
Tom Metro
Venture Logic, Newton, MA, USA
"Enterprise solutions through open source."
Professional Profile: http://tmetro.venturelogic.com/
___
Discuss mailing list
Discuss@blu.org
http://lists.blu.org/mailman/listinfo/discuss

Re: [Discuss] Security Firm Recommendations Requested

[Jared Carlson]

VSR 

http://vsecurity.com

George Gal is the principal.  Very good guy, has a really good team.


On Nov 4, 2013, at 1:51 PM, Samuel Gechter  wrote:

> Looking for a recommendation for a computer security firm. Anyone have a
> firm that they have experience with and would recommend?
> 
> Thanks,
> Sam
> ___
> Discuss mailing list
> Discuss@blu.org
> http://lists.blu.org/mailman/listinfo/discuss

___
Discuss mailing list
Discuss@blu.org
http://lists.blu.org/mailman/listinfo/discuss

Re: [Discuss] Security Firm Recommendations Requested

[Samuel Gechter]

Jared - thank you very much.

Sam


On Mon, Nov 4, 2013 at 2:12 PM, Jared Carlson  wrote:

> VSR
>
> http://vsecurity.com
>
> George Gal is the principal.  Very good guy, has a really good team.
>
>
> On Nov 4, 2013, at 1:51 PM, Samuel Gechter  wrote:
>
> > Looking for a recommendation for a computer security firm. Anyone have a
> > firm that they have experience with and would recommend?
> >
> > Thanks,
> > Sam
> > ___
> > Discuss mailing list
> > Discuss@blu.org
> > http://lists.blu.org/mailman/listinfo/discuss
>
>
___
Discuss mailing list
Discuss@blu.org
http://lists.blu.org/mailman/listinfo/discuss

Re: [Discuss] Security Firm Recommendations Requested

[Derek Atkins]

Samuel Gechter  writes:

> Looking for a recommendation for a computer security firm. Anyone have a
> firm that they have experience with and would recommend?

A security firm to do what exactly?

> Thanks,
> Sam

-derek
-- 
   Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
   Member, MIT Student Information Processing Board  (SIPB)
   URL: http://web.mit.edu/warlord/PP-ASEL-IA N1NWH
   warl...@mit.eduPGP key available
___
Discuss mailing list
Discuss@blu.org
http://lists.blu.org/mailman/listinfo/discuss

Re: [Discuss] Security in the Internet of Things

[Jerry Feldman]

Thanks JABR

On 12/06/2014 04:07 PM, John Abreau wrote:
> The video of Jeff Schiller's BLU talk a couple weeks ago is up on youtube
> now.
>
>  http://youtu.be/Auuiwr9NKxA
>
>

-- 
Jerry Feldman 
Boston Linux and Unix
PGP key id:B7F14F2F
PGP Key fingerprint: D937 A424 4836 E052 2E1B  8DC6 24D7 000F B7F1 4F2F


___
Discuss mailing list
Discuss@blu.org
http://lists.blu.org/mailman/listinfo/discuss