Focus on IDS
Re: PCI DSS 11.1 - ".. deploying a wireless IDS/IPS..". Kismet+Snort? Apr 27 2009 03:38PM
Jeremy Bennett (jeremyfb mac com)
Emm,

A laptop with a wifi interface connected to the network with the intention
of extending the network into wireless is just as much of a threat as an
unauthorized AP. However, most laptops that are connected to the LAN are not
connected with the goal of extending the network. Most of them just happen
to have a wireless interface and a wired interface. In this case the
operating system does not automatically bridge the two interfaces.

That said, there are three possibilities that need to be addressed.

1. The device is acting as an AP. There's lots of software out there to do
this, Mac OS does it right out of the box if you know how to set it up.
However, this is the easiest case to detect because these appear identical
to rogue APs.
2. The device is acting as a node in an ad hoc network. This is what Windows
will often do unintentionally. Ad hoc networks are pretty easy to detect and
there is very seldom a good reason for having one on a corporate campus so
they should be tracked down and disabled just like rogue APs.
3. The device joins an existing wireless network and bridges it to the
wired. This is the most problematic case. If the wireless network is from a
rogue AP it can be detected. Likewise if it is an authorized network it can
be detected and is also less of a threat. However, if it is a recognized
neighboring network (say att-wifi or tmobile) then this is very difficult to
detect without a client agent of some sort running.

-J

On 4/24/09 10:05 PM, "Emm Maxim" <maxus (at) infosec (dot) ru [email concealed]> wrote:

>
>
> Hi Jeremy,
>
>
> Could you share your opinion about notebooks with wifi interfaces activated,
> that attached to CDE environment?
>
> As you know, by default windows host try search any known SSID and connect to
> them. So somebody could connect to that host by setting up rogue AP outside
> the CDE but with that SSID ...
>
>
> -----Original Message-----
> From: listbounce (at) securityfocus (dot) com [email concealed] [mailto:listbounce (at) securityfocus (dot) com [email concealed]] On
> Behalf Of Jeremy Bennett
> Sent: Friday, April 24, 2009 11:01 PM
> To: Gary Everekyan; Taras P. Ivashchenko; focus-ids (at) securityfocus (dot) com [email concealed]
> Subject: Re: PCI DSS 11.1 - ".. deploying a wireless IDS/IPS..". Kismet+Snort?
>
> Gary,
>
> I'm sorry if my statements seemed to self-contradict. I'm a member of the
> Wireless SIG reporting to the PCI DSS. We've had numerous discussions on
> this topic and have been working to provide better guidance on all of this.
>
> So, let me put this another way. You must assert that there are no rogue APs
> connected to your CDE. By definition a rogue device is unauthorized and out
> of your control. Therefore you can't use networking technologies like
> firewalls to prevent someone from physically connecting a rogue device to
> your network. The only way to be certain that there are no rogue devices
> connected to your CDE is to scan for them. Hence 11.1 applies whether you
> have a wireless network or not.
>
> Is that more clear?
>
> -J
>
>
> On 4/24/09 11:48 AM, "Gary Everekyan" <Gary.Everekyan (at) consumerinfo (dot) com [email concealed]>
> wrote:
>
>>
>> Hi Jeremy IMHO you just contradicted yourself. PCI DSS SCOPE is for
>> Cardholder Data Environment that deals with PAN Data. It is this type of
>> scope
>> creep that moves InfoSec professionals away from the business decisions. It
>> is
>> very costly to include all your network hence you do what is absolutely
>> necessary to be complainant. (including segmentation)
>>
>> Here is the excerpt from the PCI DSS 1.2 that talks about in scope and out of
>> scope. You can get the document at https://www.pcisecuritystandards.org/
>> https://www.pcisecuritystandards.org/security_standards/pci_dss_download
.html
>>
>> Scope of Assessment for Compliance with PCI DSS Requirements
>> ..........................
>> Network Segmentation
>> Network segmentation of, or isolating (segmenting), the cardholder data
>> environment from the remainder of the corporate network is not a PCI
>> DSS requirement. However, it is recommended as a method that may reduce:
>> ô??? The scope of the PCI DSS assessment
>> ô??? The cost of the PCI DSS assessment
>> ô??? The cost and difficulty of implementing and maintaining PCI DSS controls
>> ô??? The risk to an organization (reduced by consolidating cardholder data into
>> fewer, more controlled locations)
>> Without adequate network segmentation (sometimes called a "flat network") the
>> entire network is in scope of the PCI DSS assessment. .......................
>>
>>
>>
>> Regards,
>> Gary Everekyan
>> CISSP, CISM, CHS-III, ISSAP, ISSPCS, ITILp, CGEIT, MCSE, MCT
>> Gary_Everekyan (at) hotmail (dot) com [email concealed]
>>
>>
>> -----Original Message-----
>> From: Jeremy Bennett [mailto:jeremyfb (at) mac (dot) com [email concealed]]
>> Sent: Friday, April 24, 2009 11:04 AM
>> To: Gary Everekyan; Taras P. Ivashchenko; focus-ids (at) securityfocus (dot) com [email concealed]
>> Subject: Re: PCI DSS 11.1 - ".. deploying a wireless IDS/IPS..".
>> Kismet+Snort?
>>
>> Gary,
>>
>> That is not true. The requirement for scanning for (and dealing with)
>> unauthorized APs or wireless devices is applicable to any physical location
>> that has a part of the CDE (Cardholder Data Environment). Whether you have a
>> wireless network and whether that wireless network is in or out of scope for
>> PCI DSS you are still required to scan.
>>
>> There are a number of other wireless requirements if your WLAN *is* in scope
>> that you can avoid if you can move it out of scope but this is not one of
>> them.
>>
>> Taras,
>>
>> That requirement is focused on rogue detection and mitigation. If your WLAN
>> can be moved out of scope for PCI (using a stateful firewall) then you are
>> only required to scan for rogue devices.
>> You can either do walk-around scans using something like kismet or
>> NetStumbler or you can invest in a system with distributed sensors that can
>> scan for the rogue devices all the time. In theory you could build this with
>> low cost sensors running kismet and syslog and watch/filter the logs in a
>> central location. You'd need a way of filtering out the known neighbors and
>> internal devices and set up something to alert you, etc. I think you'll find
>> that it is a lot less "free" than you would hope.
>>
>> -J
>>
>>
>> On 4/23/09 2:20 PM, "Gary Everekyan" <Gary.Everekyan (at) consumerinfo (dot) com [email concealed]>
>> wrote:
>>
>>> You can bypass the requirement if the WIFI Does NOT in any way transmit or
>>> connect to PAN data. If the Wireless network does not transmit PAN data and
>>> is
>>> segmented from the wired network with VPN FW ACL etc. than your WIFI is out
>>> of
>>> scope.
>>>
>>>
>>> Regards,
>>> Gary Everekyan
>>> CISSP, CISM, CHS-III, ISSAP, ISSPCS, ITILp, CGEIT, MCSE, MCT
>>> Gary_everekyan (at) hotmail (dot) com [email concealed]
>>>
>>> -----Original Message-----
>>> From: listbounce (at) securityfocus (dot) com [email concealed] [mailto:listbounce (at) securityfocus (dot) com [email concealed]] On
>>> Behalf Of Taras P. Ivashchenko
>>> Sent: Thursday, April 23, 2009 12:51 PM
>>> To: focus-ids (at) securityfocus (dot) com [email concealed]
>>> Subject: PCI DSS 11.1 - ".. deploying a wireless IDS/IPS..". Kismet+Snort?
>>>
>>> Hello, list!
>>>
>>> There is requirement in PCI DSS v.1.2:
>>>
>>> "...11.1 Test for the presence of wireless access points by using a wireless
>>> analyzer at least quarterly or deploying a wireless IDS/IPS to identify all
>>> wireless devices in use..."
>>>
>>> I made some research for open source wireless IDSs and results are not good.
>>> I found some articles about using together Kismet and Snort but it looks
>>> like
>>> not best soliution.
>>> Air Snort project is dead.
>>> What wireless IDS/IPS (especially opensource/free) do you use?
>>>
>>>
>>> --
>>> ТаÑ?ас Ð?ваÑ?енко (Taras Ivashchenko), OSCP www.securityaudit.ru
>>> ----
>>> "Software is like sex: it's better when it's free." - Linus Torvalds
>>
>>
>
>
>
>

[ reply ]


 

Privacy Statement
Copyright 2010, SecurityFocus