[Fed-Talk] IA Controls (and the Army)
[Fed-Talk] IA Controls (and the Army)
- Subject: [Fed-Talk] IA Controls (and the Army)
- From: "Emmons, James M Mr CIV USA USAMC" <email@hidden>
- Date: Mon, 28 Apr 2008 10:11:22 -0700
Greetings,
I am changing the thread topic to the above; it is more meaningful.
I'm using anti-virus as my primary example; however, I slip and cover all IA
controls for the Army as well as the _many_ other IA-related mandates. (I'm
pretty sure the other services have similar requirements. Other federal
agencies come under different agency rules - no DIACAP but NIAP.) And how
does this apply to Macs? It applies to *all*AIS in the Army as defined in
AR 25-2 and DODD 8500.1.
Writing (most definitely ex officio!) as a certifier (aka
"validator") and former Security Engineer, I can say that if a system does
not have an anti-virus* solution that meets the actual IA control below,
installed, if there is a solution, but it is impractical, or even if there
isn't an A/V solution at all, we are _required_ to make note of it - the IA
control was not met. Of course, when we do so, we also take into account
any mitigating factors as well as the effect of meeting/not meeting the IA
control. From our write-up, the paperwork (DIACAP Scorecard) goes to the
Agent for the Certification Authority (ACA), who reviews all the findings
(my boss applies a "so what" factor as well - he tends to be rather pointed
about it.... Ouch!). His review with his recommendation is forwarded to
the Office of Information Assurance and Compliance (OIA&C) (an office of the
CIO/G-6) to one of the CA Representatives (CAR), who reviews the entire
DIACAP package**. This package includes the Plan of Action and Milestones
(POAM) that basically tells the world how the program/system owners are
addressing all the findings. The CAR makes a recommendation to the
Designated Approving Authority (DAA) (a General Officer or SES who is in the
chain of command/ownership of the system and appointed by the CIO/G-6). At
this point, the DAA reviews the package and the recommendation, and makes
her/his determination about whether s/he will accept the various risks
presented to the LandWarNet, the GIG, and the Army by this system.
*Actually, this applies to _all_ of the IA controls in DODI 8500.2
as well as the regulatory requirements mandated by AR 25-2, AR 380-5, AR
380-67, etc. If there is a "Not Applicable", we have to state why that
specific IA control or regulatory mandate does not apply to this system in
sufficient detail to satisfy the CAR. And even if the system has a waiver,
we have to make note of the failing - the discussion will include a
statement to the effect that the current DAA has accepted the risk for this
IA control - even with a waiver, the system failed the control.
** The DIACAP package reminds me of that DiTech lending ad a few
years ago - the "bad" bank gave the prospective borrowers a huge stack of
paperwork to complete before considering their loan. When the customers
made a comment about how the ads said the bank had cut their paperwork, the
short chubby smarmy lending officer pulled one sheet off the top. That is
(IMNSHO) about the difference between the DITSCAP and the DIACAP - but the
DIACAP is <horns>ta daa!</horns> NEW!
The actual DODI 8500.2 IA control regarding anti-virus protection
is:
ECVP-1 Virus Protection
All servers, workstations and mobile computing
devices implement virus protection that includes
a capability for automatic updates.
Look at what this assumes: An operational network to which the
target machine is connected and over which the target machines is authorized
to download. Actual A/V software for the system (think of what A/V exists
for Crays, for example.) And the funding for same - if not one of the big
three the ACERT supports. (Where does the iPhone come into play here? How
about the Newton?) Trust in the entire A/V infrastructure - and no, you
can't say you won't use A/V because you don't trust it. Sorry. <vbg>
To push a system/program through just the C&A effort can take as
much as 270 days, though I have seen it done in one month - both were
exceptional systems. And to be honest, we (certifiers, security engineers,
etc.) are trying to make your computing experience more secure - that is,
officially, our sole intent and guide. The Program Managers and system
owners are the ones who are supposed to make it nice for you. But, because
we exist and we are almost always seen as the bad guys, we get blamed for
not allowing you to do something. (In actuality, _we_ merely advise; we
don't approve or deny anyone anything. Of course, we do try to advise you
[PMs/designers/owners] of the consequences of being complete idiots, though
we do try to be nice about it. And the DOIMs love us: we are the easy
target for them to blame for everything they don't want to do: "IA won't
let us do <whatever>."
And the ACAs are reimbursable - you have to pay us to work with and
on your system, as well as evaluating it. But we are also "honest brokers"
- we don't let the fact you are paying us affect our findings. It would not
be fair to you or the Army to do otherwise. Hoo-ah!
Stay safe,
Jim
James Emmons
Computer Scientist CISSP GSEC AAC
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Fed-talk mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden