|
|
|
Forum Newbie
Group: Forum Members
Last Login: 12/4/2007 6:44:03 PM
Posts: 6,
Visits: 24
|
|
| Networks and instrumentation used for data acquisition during Developmental Testing are a unique breed. Often the DoD and Service specific regulations for Information Assurance do not address the specific needs of this community. I'd hope this topic can discuss areas of interest to this unique community ... which I see including the Major Range and Test Facility Base (MRTFB) installations, Installations connected by the DREN, and HPC networks. Data Acquisition systems could be connected to the test item either by hard-wire or wirelessly. How do we secure these systems? Do we apply the same rules/procedures as those used for the NIPRNET? Do we connect to the NIPRNET? Any and all information in this area would be greatly appreciated. Thanks for your time.
|
|
|
|
|
Forum Member
Group: Forum Members
Last Login: 2 days ago @ 11:36:03 AM
Posts: 41,
Visits: 515
|
|
| Pardon my two cents worth: I should hope you would never "test" on a live network such as NIPRNet, etc; however, your IA folks may have constraints different from other communities, and I'm aware there are ways to isolate an environment if there is no alternative. I'm kind of shooting in the dark, and forgive me if I am offering advice that isn't wanted, but I would highly recommend/comment that information in a test environment such as yours is not live or classified (I would hope) so that you have relatively free reign to "play" with it once you prove that it is "benign" in the sense that it cannot/will not affect any live data, system, or network and is not accessible outside your test environment (in other words, nobody will mistake it for the real Magilla). In my experience, so long as you can prove it does not touch a "live" network, system, or data, normal rules of engagement don't apply to you. If/when you have something worthy of fielding on a production system (on a "live" network), THEN you have to contend with all the constrictions, IA and otherwise. I do think it's EXTREMELY advantageous to think the way you are thinking - it will make it far less painful when you have a "real world" product ready to field; but I can't imagine that anyone (DAA on down) expects a test environment to meet the same criteria as a live system/application. Throw cyber tomatoes at me if you like. :-) NewBieOrNotNewBie
|
|
|
|
|
Forum Newbie
Group: Forum Members
Last Login: 12/4/2007 6:44:03 PM
Posts: 6,
Visits: 24
|
|
Fear not, no cyber tomatoes coming from this direction. In case you didn't notice, this is the FIRST response/comment to my original post since August '06.Newbie2 (2/26/2007)
Pardon my two cents worth: I should hope you would never "test" on a live network such as NIPRNet, etc; however, your IA folks may have constraints different from other communities, and I'm aware there are ways to isolate an environment if there is no alternative. I'm kind of shooting in the dark, and forgive me if I am offering advice that isn't wanted, but I would highly recommend/comment that information in a test environment such as yours is not live or classified (I would hope) so that you have relatively free reign to "play" with it once you prove that it is "benign" in the sense that it cannot/will not affect any live data, system, or network and is not accessible outside your test environment (in other words, nobody will mistake it for the real Magilla). In my experience, so long as you can prove it does not touch a "live" network, system, or data, normal rules of engagement don't apply to you. If/when you have something worthy of fielding on a production system (on a "live" network), THEN you have to contend with all the constrictions, IA and otherwise. I do think it's EXTREMELY advantageous to think the way you are thinking - it will make it far less painful when you have a "real world" product ready to field; but I can't imagine that anyone (DAA on down) expects a test environment to meet the same criteria as a live system/application. Throw cyber tomatoes at me if you like. :-) NewBieOrNotNewBie Let me propose another perspective for you ... Our "Mission" is to conduct tests ... therefore, the network we use to conduct our tests, to collect the data, etc. really IS our "production" network! If that network is connected to the rest of the world via the DREN, ... (which, according to Army's NETCOM documents is a "non-Army" network) ... then why would the Army NIPRnet rules apply to those computers on the DREN? As you said ... cyber tomatoes are welcome ... I'm glad to get some discussion going about the Developmental Test community. DIACAP4DT&E
|
|
|
|
|
Forum Newbie
Group: Forum Members
Last Login: 2/2/2010 7:03:25 PM
Posts: 2,
Visits: 79
|
|
| I too work in the T&E Community, and understand your objective. I believe what we need is the ability to add (define new) IA controls, tests, validations, ... for Army and Command regulatory and instructional requirements. The DIACAP Toolset is a great help for tracking DIACAP progress and generating reports to the IA team. But, without the ability to define new IA controls, I can't completely capture C&A for things like MSL and SIPRNet (Authority To Connect testing). Another (quality) feature would be to have the DIACAP Toolset get its IA controls from the DIACAP Knowledge Service. WOW, and then, I-Assure could maybe get the tool published on the Knowledge Service - with enhancements it could become eMASS-Lite?
DIACAPER
|
|
|
|
|
Supreme Being
Group: Administrators
Last Login: 8/24/2010 8:37:01 PM
Posts: 292,
Visits: 690
|
|
| Appreciate the input. Starting in version 3.0.0, we added the ability for new IA Controls (supplemental) and Validation procedures to be added to the ScoreCard. After a project is created, open the ScoreCard and in the navigation bar, there is a "supplemental IA control icon", click it and a form will pop up to enter all the information. Only problem is that it is specific to the project you have open, so any control added would not be available in other projects. However, if you need to have the supplemental IA Controls across multiple projects, you can add them to one project, then Clone the project. From an IA Control perspective, our toolset baseline comes from the 8500.2 controls, as does the Knowledge Service, so we are synched up there. We have offered the tool to both DISA and the DIACAP KS, but never received a response
|
|
|
|
|
Junior Member
Group: Forum Members
Last Login: 2/5/2008 10:09:22 AM
Posts: 10,
Visits: 7
|
|
| Actually what DOD needs to do is add another description for the Test and Development Systems; you could label your T&E as a Stand Alone system. DODI 8510.1 page 23, 6.8. Stand-Alone IS Accreditation. Stand-alone ISs are treated as special types of enclaves that are not interconnected to any other network. Stand-alone systems do not transmit, receive, route, or interchange information outside of the system’s accreditation boundary. IA requirements for a stand-alone system are determined by its MAC and classification or sensitivity and need-to-know just as for other DoD ISs. Stand-alone systems must always be clearly identified as such on the IT Security POA&M, the SIP, and the DIACAP Scorecard. Because of the unique architecture of a stand-alone system, certain IA controls do not pose a risk to the system as a result of their non-implementation and thus are considered NA. NA IA controls are labeled as NA on the DIACAP Scorecard and addressed on the IT Security POA&M simply as a means to document and explain why the IA control is NA in the comments column. Refer to the KS for a discussion of IA controls that may be considered NA for stand-alone systems. Additionally, stand-alone systems that are deployed to multiple locations may be type accredited.
|
|
|
|