|
|
|
Forum Newbie
Group: Forum Members
Last Login: 8/25/2009 2:18:07 PM
Posts: 3,
Visits: 22
|
|
DoDI 8510.1 only covers the disallowance of Category I vulnerabilities under ATO . It does not say anything about the condition of known Category I vulnerabilities in order to receiving an IATT.
Are Category I vulnerabilities an absolute impediment to an IATT even if it is planned to resolve these weaknesses by the time the test period concludes and the DIACAP package is submitted for an ATO?
|
|
|
|
|
Forum Member
Group: Forum Members
Last Login: 8/26/2010 2:48:27 PM
Posts: 41,
Visits: 514
|
|
| I think it depends on what the Cat I is, in other words what and how much risk it imposes on the network in general, etc. Then it will depend on how well you persuade your DAA that you have a good enough countermeasure or mitigation in place to protect the rest of his network from whatever fiasco might happen with what you're testing. Some DAA's are more risk tolerant than others. I'd advise a really good plan to mitigate and/or counter the risk before you present the facts to your DAA to ask for an IATT. Your Cat I might be a gaping security hole that would allow anyone to see and access the system or application, even assume root privileges. That's not acceptable on any responsible DAA's network; BUT, maybe you have created a secret squirrel VPN that isolates it from the world, maybe there's no "real" data in it, maybe no one can even see that it's there let alone hack it because of that countermeasure, and you plan to only turn it on between the hours of X and X, after which it is completely turned off and removed from connectivity with the network. You'd never ask to put that kind of risk in a production environment, but you MIGHT have a need to check other functionality while you're developing the production version. See what I mean? Bottom line: always tell your DAA the whole truth, but when you bring him a problem, bring him the solution to help him say yes. I hope this is helpful.
|
|
|
|
|
Forum Newbie
Group: Forum Members
Last Login: 11/9/2009 12:13:43 PM
Posts: 1,
Visits: 1
|
|
All of these types of issues depend on "interpretation" of your CA. There should be no CAT I issues for IATO/ATO. Also be careful when documenting CAT I issues. If the vulnerability is an actual techincal finding leaving "root" open, it may need to be put on a classified POA&M.
Darren V. Strickland
Information Assurance Engineer
|
|
|
|
|
Forum Newbie
Group: Forum Members
Last Login: 6/17/2010 9:51:25 AM
Posts: 7,
Visits: 12
|
|
There should be no CAT I risks ... not issues, vulnerabilities, findings or whatever term we use for raw data.
So, a CAT I flaw/vulnerability may not present a CAT I risk -- due to compensating controls, etc.
In the AF, no CAT I risks are allowed for IATO, ATO, etc.
An IATT is an authority to test ... for AF, thats without live data or emanations.
We often get an IATT, so we can perform an IA test -- to find the vulnerabilities.
-- joe
AF 653 ELSG
Airborne Network Systems & Tactical Data Links
|
|
|
|