Please cite references.
I can find plenty of firewall required references but I'm
yet to find a NAT and/or RFC 1918 required.
Mark
Mark Andrews wrote:
Please cite references.
I can find plenty of firewall required references but I'm
yet to find a NAT and/or RFC 1918 required.
(Skip if you've participated in a SOX audit from the IT department POV)
The way it works is that the law doesn't call for specific measures. The law calls for audits. Audits are done by outside firms (like "large accounting firms") using their internally-developed checklists for compliance. Passing the checklist gets you an unqualified audit. Failing a few items gets you a qualified audit. Failing more means you don't have the necessary audit document to present.
The exact details of every line item are typically under non-disclosure when presented to the IT department for review, so for instance I can't post the ones from the last audit I participated in.
Firms are also free to develop their own internal control guidelines, as long as they can convince the outside auditor that the controls are at least as strong as the ones on the checklist.
Other regulations, like HIPPA, also require the same thing. For instance, the top Google hit for HIPPA and "private address space" links to a wustl.edu document regarding how their controls over HIPPA-protected information are implemented (including the use of private address space and the use of multiple layers of NAT).
It takes a *lot* longer to get policies changed and auditors to sign off on the revised policies than it does to make a change in a router. That means that the process of updating policies should have started *even sooner* than the process of upgrading and reconfiguring routers for IPv6. But since there's still open questions (like the recent discussion of IPv6 NAT on the BEHAVE list) that have no answers at all, I can imagine why some folks might be putting off revising their policies and asking for external review of those.
Matthew Kaufman
[...SOX auditor stuff...]
> When the compliance explicitly requires something they are required to check
> for it, they don't have the option of ignoring or waving requirements ...
> and off the top of my head I don't recall if it is SOX that calls for
> RFC1918 explicitly but I know there are some that do.Please cite references.
I can find plenty of firewall required references but I'm
yet to find a NAT and/or RFC 1918 required.
It isn't SOX, but sadly enough, PCI DSS Requirement 1.5 says:
Implement IP address masquerading to prevent internal addresses from
being translated and revealed on the Internet. Use technologies that
implement RFC 1918 address space, such as port address translation (PAT)
or network address translation (NAT)
I know that some auditors want to hold people to that standard.
I stopped working with the credit card people at that point...
>> > The SOX auditor ought to know better. Any auditor that
>> > requires NAT is incompenent.
>>
>> Sadly, there are many audit REQUIREMENTS explicitly naming NAT and
>> RFC1918 addressing ...
>
>SOX auditors are incompetent. I've been asked about anti-virus
>software on UNIX servers and then asked to prove that they runUNIX.........
Fair enough, but my point was that it isn't the auditors' faults in
_all_ cases.
When the compliance explicitly requires something they are required to
check for it, they don't have the option of ignoring or wavingrequirements ...
and off the top of my head I don't recall if it is SOX that calls for
RFC1918 explicitly but I know there are some that do.Please cite references.
I can find plenty of firewall required references but I'm
yet to find a NAT and/or RFC 1918 required.
Minor correction (I did say I wasn't sure it was SOX) ... It is PCI that
requires RFC1918 and translation.
For SOX, what is your assessment of (IPv6) internal controls and risk based
on? Has anyone (with the authority to do so) developed and released
guidance? Do we have a repository of "current best practices" to rely on
(yet)?
Interestingly, with SOX, I am curious if lack of IPv6 preparation will play
into the risk assessment as well :).
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. We are just starting to see finalized product profiles
and STIGs for IPv6 configuration - without that guidance Defense networks
really couldn't <wink> run IPv6 either.
(In other words (again, generally speaking) - if you run IPv6, your current
C&A (or perhaps your CTO (Certificate To Operate)) is invalid).
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.
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.
(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.
/John
John Curran
EVP, COO, CTO
ServerVault Corp
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
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.
Compliance frameworks are generally technology agonistic.
They tell you "have an information boundary for your system",
"manage your user identifiers", etc. Aside from the DoD IA
STIGs (and small handful of NIST areas such as encryption),
you don't find specifications that particular protocols or
technology is required. They don't require major updating
for IPv6 because there's very little IPv4 specific contents
in them already.
That's not to say that moving an application to IPv6 is trivial
from a compliance and security perspective, as you've still got a
pile of mandatory firewall, load-balancing, and IDS infrastructure
that needs to handle IPv6 correctly before you can get started.
In organizations that are planning ahead, this is common security
control infrastructure, and gets done once centrally rather than
each little component.
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.)
Look, systems change. Change your database software, and you
get to update the corresponding pieces of the C&A package. Add
IPv6, you have to update the network portions. This shouldn't
be a surprise to anyone, and it certainly doesn't mean "all of
their C&A work will need to be re-done".
/John