v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space

TJ trejrco at gmail.com
Tue Feb 10 21:30:26 UTC 2009


>> Current versions of the rest (HIPAA, GLBA, SOX, FIPS, etc.) simply
>> tend to omit IPv6 completely, and generally require everything not
>> explicitly called out to be disabled ... thus, no IPv6 on any network
>> that falls under any of these regulations.
>
>TJ - You attempted to say that for PCI, and then it was shown that there's
>clear language regarding compensating controls that could easily be
>considered applicable.  I haven't had the honor of running an IPv6-enabled
>system through a PCI compliance audit, but have little doubt that it will
>happen shortly and will require auditor education just like every other
>technology introduction.

First off - me neither; this is related to my realm, but not within it.

Secondly - we largely agree; although I think the level of "auditor
education" that will need to occur is more burdensome than might be expected
- partially due to lack of underlying guidance.  Again, I don't live and
breathe compliance, but the best I have seen is that some have started
developing these procedures/guidelines.  Started.

Additionally, I suspect (but do not know that) the compensating control
clause is meant to be a special case ... I'd love to hear more ...


>I run a data center which specializes in secure, compliant managed
services,
>and have been through hundreds of audits in support of our clients which
>include federal civilian, federal defense, health care, and financial
>services firms.  There are very few IT standards which have precise
protocol
>or address requirements embedded in them, and there is almost always an
>opportunity to provide compensating controls where necessary.  If you've
got
>an example from one of the above compliance frameworks to the contrary that
>would actually preclude IPv6 deployment, please cite it.

Sure, general language meant to be semi-technology-independent.

Perhaps not outright preclude deployment altogether, but certainly cause
(possibly rather expensive) delays or complications.
Note - I am merely pseudo-quoting from what auditors and policy people have
told me and my colleagues, through the course of several briefings.

Allow me to more directly quote one of my colleagues:
* Current C&A auditors are not checking for IPv6-based vulnerabilities. They
do not understand the process or have the tools to do IPv6 C&A.
* IPv6 is already deployed in a surprising number of IT systems, networks,
and software - we find it operating in audits of agencies and enterprises
that are "not deploying IPv6"
* Is your FISMA C&A complete/valid without considering IPv6?

Note that the last bullet is a somewhat rhetorical question - the answer is
obviously no, but you might be surprised to see the look on some peoples'
faces when you tell them that ...

Or let's take this -
http://72.34.43.90/IPV6/usipv6_reston_2004/thu/Kruger-Schifalacqua.pdf
... and while the goal is to show that/how it is possible to obtain your
ATO, I think it makes a strong case in the opposite direction.
How can you be assured that you live up to "Do no harm" when the definition
of harm, based on the (until very recently) absent standards upon which to
make this basis?  Or with a staff (local network or auditor) that is not
IPv6 savvy at day -1  (meaning prior to the expected deployment of IPv6).  
(And in fact, after just re-reading it - this presentation seems to make a
case for disabling DAD (albeit in a specific case) - something that violates
the protocol spec as well as the DoD APL requirements ... so who wins that
decision?)

To take it a step further (and perhaps be over-simplsitic): 
The guidance to "disable all unused protocols and services" applies.
So, if you aren't using IPv6 today it must be off.
If you want to turn it on, you must redo your C&A.
That costs money, therefore doesn't happen - atleast not "soon".
Therefore, no IPv6.

I would love to hear more from those who have done C&A (of any flavor) on an
IPv6 enabled network - specifically, was IPv6 actually considered/evaluated
and any problems it caused for the process.


>> (In other words (again, generally speaking) - if you run IPv6, your
>> current C&A (or perhaps your CTO (Certificate To Operate)) is
>> invalid).
>
>Sure... change your network, and you need to update your C&A package as
part
>of maintaining your ATO.  It's up to your DAA as to whether they want to
use
>IPv6 prior to equipment being certified under the DoD IPv6 Profile.

But that is my point - Do any of the compliance frameworks / requirements /
audit standards today address IPv6, or detail how it could be implemented in
such a fashion as to 'pass' an audit (including the "in-house" /
consultant-specific audit guidelines)?  If it can be done, but is solely a
"you and your (current) auditor figure it out, on a case by case basis,
every time" I would argue that that is not good enough for the general case.

And while I agree with you, "any change = redo" I would argue that not
everyone realizes that all of their C&A work will need to be re-done in
order to retain their CTOs/ATOs if they move forward with any sort of IPv6
deployment.  I have heard the gasps (I didn't see the faces, that was a
coworker of mine did and said it was amusing - in a sad way.)


Thanks ... 
/TJ





More information about the NANOG mailing list