CyberSecurity

Category: Assurance/Netcentric

  • DIACAP Essentials + IA Control Validation Training (part 4): DIACAP/AFCAP Day 4 & 5

    UPDAT: 2014 - Risk Management Framework for DOD IT released.

    Days 4 & 5 bring the DIACAP/AFCAP Essentials Class to a close. The
    biggest things I learned were: CNSSI 4009 is the the official glossary of DOD IA, there is a big difference between theory, policy and practice, Agents of the Certifying Authority (ACA) are official validators and there is a difference between acquisition Mission criticality and IA MAC levels.

    Stuff I learned from people in the class:

    -AFCA is changing its name (to what?)

    DOD is going to put the new IA controls in NCSSI 12-53 (currently in draft)

    -a lot of what I need in there is in NIST 800-53

    Marines use something called Exacta

    Site called securitycritics.org

    33-202 is now completely irrelevant and obsolete (not even mentioned ONCE in the class)

    800-30

    Feds call Certification &Accreditation (C&A) “Security authorization”

    NIST SP 800-37

    Day 4:

    Validator Activities & Issue Accreditation Decision

    Prepare POA&M

    Validate Results/Scorecard

    Scorecard

    Make certification determination

    CA/DAA Package review

    Day 5:

    Validation procedures were discussed. On day five, we looked at how the validators look at a system.

    I thought is was interesting. It should help me get through the EITDR/DIACAP process easier.

    Maintain Situational Awareness

    Maintain IA Posture

    Conduct Review

    R-Accreditation

    Retire system

  • DIACAP Essentials + IA Control Validation Training (part 4): DIACAP/AFCAP Day3

    UPDAT: 2014 - Risk Management Framework for DOD IT released.

    Day 3 heats up a little. We start talking about what it take to actually get validated. The DIACAP Implementers Guide & the DIACAP Validators guide is opened up and reviewed. I think we all learned a little something during this discussion because there have been some challenges with this. Unfortunately, we don’t to far into the validator stuff.

    Day 3:

    DIACAP Structure

    Terminology Review

    Assemble DIACAP Team

    Registered System/System Information Profile

    Assign IA Controls

    Initiate DIACAP Implementation Plan

  • DIACAP Essentials + IA Control Validation Training (part 3): DIACAP/AFCAP Day2

    UPDAT: 2014 - Risk Management Framework for DOD IT released.

    Day 1 & 2 have been all about the very basics of DIACAP. Were introduced to the terminologies, key players of the C&A process and basically given the big picture. Like I said, GREAT for beginners, but just lots of theory and refresher if you’ve been doing C&A since DITSCAP.

    Day 1 &2:

    Getting the Big Picture

    DIACAP/AFCAP Policy & Terminology

    Roles and Responsibilities for the C&A process

    Accreditation & Approval to Connect

    Homework: review terminology

    In between longer breaks, during lunch and just before class we sneak in episode of the The IT Crowd. Its the first time I’ve watched it so its a real treat for me. Hilarious show.

  • DIACAP Essentials + IA Control Validation Training (part 2): DIACAP/AFCAP Day1

    DIACAP/AFCAP Day 1.
    This is the second installment of the DIACAP Essentials journal.

    In the first day of class we’ve taken a high level look at the big picture of the Department of Defense Information Assurance Certification & Accreditation Process (DIACAP) and Air Force Certification & Accreditation Program (AFCAP). It is a very valuable tool for a beginner.

    Since I’ve gone through the entire process (with a legacy system) more than once through all the growing pains of Air Force C&A from DITSCAP to DIACAP, I found that I knew about 90% of everything taught. I don’t mind having a refresher, though and quite frankly, I need the CPE’s for my CISSP :).

    There were a couple of golden nuggets that I’ve been able to get out of some of the old timers. I learned some interesting things about how the Navy, Marines and Army do things.
    Navy (as weird as their dumb ass rank system.. yep, I said it.. its dumb) have like three systems: DITPR-DON, DA-DUMB and some other BS, Marines have something called Exacta and the Army has APMS (Army Profile Management System). Also learned cool off topic stuff like history of eMass.

    I must admit I’m looking forward to day two.
    pros of day 1: Good solid start on basics GREAT for beginners. SecureInfo gets mad props for have a great instructor John M.(don’t know if he wants his full name published.. but he’s highly, highly knowledgeable and very positive).

    cons of day 1: Right off the bat I am noticing a huge hole in the training… a lack of in depth teaching of EITDR, which is how the Air Force implements, manages and maintains the entire DIACAP/AFCAP process. I don’t really see how you can teach one without the other these days. I guess contractually, SecureInfo can not touch it since some other company has the contract. But unfortunately, the folks that are new to this are going to suffer. Because if they goto this class without knowing the EITDR they will know why but now how, and if they go to the EITDR class without knowing the DIACAP they will know how but not Why.

  • DIACAP Activity #1 Initiate and Plan Certification & Accreditation

    Initiating the Department of Defense Information Assurance Certification & Accreditation Process (DIACAP) starts with a lot of “setting up shop”. Registering with a DoD component, forming the IA Team and assigning IA controls (also known as IA requirements and security controls) can be a lot of work, but the more of these tasks you complete, the easier the rest of the process will be.

    Register the System with DoD IA Component

    Each branch of the military has an IA component. Each of the US Armed Services have a division under their respective chief information officer’s responsible for all computers, communications and networks in a given military branch. These communications divisions will house the Information Assurance component responsible for the DIACAP tasks.

    Table 1. DoD IA Components

    DoD Branch Branch Communication & Information Service Branch IA Component
    US Air Force Air Force Communication Agency (AFCA)http://public.afca.af.mil/ AFCA/EVAssessment and Validatorshttp://public.afca.af.mil/library/
    US Army *Army NETCOM 9th Signal Corps http://www.netcom.army.mil/ Army NETCOM Information Assurance Office
    Department of the Navy DON CIODON Information Management and Information Technology (IM/IT)http://www.doncio.navy.mil DON SIAOhttp://www.doncio.navy.mil/Main.aspx

    *more on Army NETCOM

    More on Registering with your IA Component
    DIACAP Team

    Once you’ve made contact with your system’s IA Component you may be asked to identify the players in your DIACAP Team. The DIACAP Team roles will consist of a Designated Approval Authority (DAA), Program Manager (PM), Certifying Authority (CA), User Rep, Information Assurance Manager and others. You will also need to identify other important players such as the Lead Engineer.

    More on DIACAP Team Roles.

    Get an Enterprise Mission Assurance Support Service (eMASS) account

    The Enterprise Mission Assurance Support Service (eMASS) is a generic name for specific automated databases that are used to manage the DIACAP. Each branch has a different automated database (Fig 1). The USAF has the EITDR, The Navy has the DITPR-DON, and the Army has the APMS. Each of these databases satisfies DoD IT portfolio management, certification and IT reporting directives addressed in DoD Directive 8115.01, signed October 10, 2005.

    Fig 1, DoD IT Portfolio Management System

    eMASS IT Portfolio Management System

    More on the eMASS systems.

    Assign IA Controls

    Information Assurance Controls are also known as Information Assurance requirements and security controls. IA Controls are assigned according to a system’s Mission Assurance Category (MAC) and Confidentiality Levels (Fig 2.) defined in DoDI 8500.2. The DIACAP Knowledge Service has Excel spread sheets breaking down each of the IA Controls.

    Fig. 2, Mission Assurance Category & Confidentiality Levels

    Mission Assurance Category (MAC) Confidentiality Levels

    Some of the IA Controls require system security engineering interpretation because no system is alike. Some IA Controls will not apply while other will apply only under certain circumstances and that is where knowledgeable system & system security engineer comes in.

    Ref:

    https://akss.dau.mil/dag/GuideBook/IG_c7.5.7.2.asp

    DoDI 8500.2, Enclosure 4

    Initiate DIACAP Implementation Plan

    With the proper MAC/CL level applied, the system security specialist/engineer and/or technician should have a good idea what IA Controls apply to a given system. The next step is to begin the DIACAP Implementation Plan.

    The DIACAP Knowledge Service has a thorough break down of each of the IA Controls and how to accomplish and validate them. Once complete, your system’s DIACAP Implementation Plan should identify each of the applicable IA Controls, whether the system is compliant or not and when it will be compliant with those particular IA Controls.

    Initiation of the DIACAP Plan means you are consulting developers and or Program Managers on the IA Controls that will affect the system. Both new systems, and existing legacy systems will require some sort of documentation whether a simple spreadsheet, or Word document detailing who, what, when and where of each IA Control feature applied to the system. The DIACAP Knowledge Service has a sample DIACAP Implementation Plan spread sheet that thoroughly details all the above requirements. It can be downloaded and tailored easily to your specific systems needs.

    Once registered, the eMASS (EITDR, DITPR-DON, and APFM) system will require that you upload your completed DIACAP Implementation Plan (which is a bit of a paradox because the EITDR can actually create a DIACAP package once certain data is uploaded, validated and approved. EITDR will also require that the IA Controls be addressed and validated individually and subsequently Reviewed, Validated and Approved by system stakeholders.

    Deliverables for Activity #1:DIACAP System Identification Profile (SIP)

    DIACAP Implementation Plan

    USAF SISSU Stakeholder’s List (Air Force)

    References:

    DoD Regulation 5200.1-R , “DoD Information Security Program,” January 1997

    DoDD 8115.01, “Information Technology Portfolio Management”, dated October 10, 2005

    DoDD 8500.01E, “Information Assurance (IA),” dated April 23, 2007

    DoD 8510.1-M, “DoD Information Technology Security Certification and Accreditation Process (DITSCAP) Application Document”, dated July 31, 2000

    DoDI 8551.1, “Ports, Protocols, and Services Management (PPSM) Release 6.9,” dated September, 2007

    DoDD 8570.1, “Information Assurance Training, Certification, and Workforce Management,” dated August 15, 2004

    DoDI 8570.1-M “Information Assurance Workforce Improvement Program,” dated December 19, 2005

    Deputy Secretary of Defense Memorandum, “Information Technology Portfolio Management,” March 22, 2004

    Federal Information Security Management Act (FISMA) (2002)

    Information Assurance Support Environment (IASE)

  • NR-KPP stands for Net Ready Key Performance Parameters

    NR-KPP stands for Net Ready Key Performance Parameters.
    Net Ready is the ability to have immediate access to mission or business essential information. Like the term Netcentric, Net Readiness is the full exploitation of the Internet and/or Intranet whether the organization's primary mission is business, volunteerism or warfare.

    So Net Ready Key Performance Parameters refers to evaluating the “net readiness” of a given information system or organization.

    Formal Definition:
    NR-KPP was developed to assess net-ready attributes required for both the technical exchange of information and the end-to-end operational effectiveness of that exchange. The NR-KPP replaces the Interoperability KPP, and incorporates net-centric concepts for achieving Information Technology (IT) and National Security System (NSS) interoperability and supportability.

    What are the elements within the Net Ready Key Performance Parameters?

    Net Centric Operations and Warfare Reference Model (NCOW RM) Compliance Statement

    Information Assurance (IA) Accreditation Compliance Statement

    Your guide on creating the NR-KPP will be the CJCSI 6212, Interoperability and Supportability on National Security Systems:

    Net-Ready Key Performance Parameter. All Information Support Plans (ISP) for systems that exchange information with other systems will contain a Net-Ready KPP. For all ISPs with an associated approved JCIDS CDD or CPD capabilities document, the ISP can refer to the associated CDD/CPD. ISPs for CRDs, ORDs, non-ACAT and fielded systems will include the NR-KPP in the ISP.

    The NR-KPP will consist of the following:
    a. AV-1, OV-2, OV-4, OV-5, OV-6C
    b. SV-4, SV-5, SV-6
    c. TV-1 generated from DISR online
    d. Applicable CRD crosswalk (See Table D-3)
    e. Initial LISI Profile (Interface Requirements Profile) See Enclosure K
    f. NR-KPP statement. (Table I-1)
    g. IA Statement of Compliance
    h. Key Interface Profile (KIP) Declaration (list of the KIPS that apply to
    the system)

    Key Interface Profiles (KIPs) Compliance Statement

    Reference:
    CJCSI 6212, Interoperability and Supportability on National Security Systems
    ß http://www.teao.saic.com/cbrtraining/docs/CJCSI_6212_01.pdf

    Net Ready -> http://del.icio.us/tag/%22net%2Bready%22
    More on NR-KPP à http://del.icio.us/tag/%22nr%2Bkpp%22

    http://del.icio.us/rss/tag/netcentric

  • ISP Architectural Views

    One the most important part of an Information Support Plan
    (previously known as a C4ISP) is the Architectural Views.
    The DoD Architectural Framework Document describes each veiw
    in painful, painful detail.  Since the C4ISP has been
    changed into the ISP, the DoD Architectural Framework is a
    bit out dated.  For example it doesn't mention "ISP" and
    also includes some old views that have been phased out such
    as OV-3 and SV-1.  The following gives my view on some of
    the views.

    In my limited experience creating views is very interative
    process. Meaning you create a little then your tweak and
    change them as you go.

    AV-1 Overview and Summary Information is a breeze if you
    have all the appropriate information readily available.

    Operation Views (OV)
    These are fun for me because I feel like I understand
    them.  OV-1, High-level Operational Concept Graphic is
    one that I've had the pleasure of not having to do. 
    Merely starting it was a bit of a challenge.  It is
    intended to look pretty. I've seen it done affectively
    with MS Word and PowerPoint.

    OV-2 is Operation Node Connectivity.  As a network guy,
    this is my favorite.  I use Visio for this one with
    simple shapes representing the nodes or you can get
    fancy and use computer Icons OV-4, Organizational
    Relationship Chart is another fun easy diagram that can
    be created with Visio or Word using simple shapes. 
    Ov-5 is the Activity Model.  Since it is so closely
    tied to SV-4, fuctional description and SV-5,
    Operational Activity to System Function Traceability
    Matrix, it is very, very interative and not one of my
    favorites. I complete these three one after another. 
    Both SV-4 and OV-5 must be completed before you do SV-5
    since all the info in SV-5 comes from those two.
    OV-6c, Operational Events-Trade Description requires a
    very good understanding of what happens to the data
    upon entering the system.  But once you have that
    nailed down it is fairly straight forward.  The logical
    data model, OV-7, can get a bit convoluted, I imagine. 
    In it you are supposed give a visual representation of
    the various domains.

    System Views (SV)
    The SV's can get a little gray as some of the views can
    touch on things that involve your system but you have
    perhaps only heard of.  For example, if your system "A"
    connects with System "B" you may have to show that
    connection even though you don't know much of anything
    about System "B". I haven't seen SV-1 on the Teao Saic
    site so I assume it has been phased out. But it deals
    with Interfaces.  SV-2, System Communication Description
    is very much like the example of system "A" in relation
    to "B".  SV-2 shows how your system communicates/connects
    with other systems.  Its almost like a birds eye veiw of
    OV-2. SV-4, System Functionality Description, like I said
    in the OV section closely related to OV-5 and SV-5.  So
    if one changes, they may all have to change.
    SV-5 is a large table that shows the direct relationship
    between Operational Activity to System Function.  It is a
    pain in the ass for reason stated above. SV-6 can be a
    very complex table.  It is the System Data Exchange
    Matrix.. you'll note that anything with the word "matrix"
    in it sucks.  That is because one change on a seperate
    veiw can affect change in other views and almost always
    includes the matrices.

    Technical View (TV)
    TV-1, Technical Standards merely lists all the capabilities
    of the system and references each of the technical standards
    used.

    That is my oppinion of the ISP views.  I hope you find them as relatively painless
    as I did and if not this site will help you out --->
    http://www.teao.saic.com/cbrtraining/archpro01.asp

  • Net Ready Key Performance Parameters (NR-KPP)

    The Net Ready Key Performance Parameters (NR-KPP) is
    comprised of the following elements: compliance with the Net-Centric
    Operations and Warfare (NCOW) Reference Model (RM), applicable Global
    Information Grid (GIG) Key Interface Profiles (KIP),
    DOD information assurance requirements, and supporting integrated
    architecture products required to assess information exchange and use
    for a given capability.

    Net Centric Operations Warfare Reference Model (NCOW RM) (a) The NCOW
    RM serves as a common, enterprise-level, reference model for the DOD’s
    Enterprise Architecture The NCOW RM will ultimately provide a common
    architectural construct for NCOW with a common language and taxonomy.
    The final version of the RM will include:

    1. All Views (AV): AV-1 and AV-2
    2. Operational Views (OV): OV-1, OV-2, OV-3, and OV-5
    3. System Views (SV): SV-1, SV-2, SV-3, SV-4, and SV-5
    4. Target Technical View

    AV-1 Overview and Summary
    Information Scope, purpose, intended users, environment depicted, analytical findings

    OV-2 Operational Node
    Connectivity Description Operational Nodes, operational activities performed at each node,
    connectivity and information exchange need lines between nodes

    OV-4 Organizational Relationships Chart
    Organizational, role, or other relationships among organizations

    OV-5 Operational Activity Model
    Operational activities, relationships among activities, inputs and outputs.

    OV-6c Operational Event-Trace Description
    One of three products used to describe operational activity sequence and
    timing – traces actions in a scenario or sequence of events and specifiestiming of events.

    SV-4 Systems Functionality Description
    Functions performed by systems and the information flow among system
    functions, including information assurance functions

    SV-5 Operational Activity to Systems Function Traceability Matrix
    Mapping of systems back to operational capabilities or of system functions
    back to operational activities.

    SV-6 Systems Data Exchange Matrix
    Provides details of systems data being exchanged between systems.

    TV-1 Technical Standards Profile Extraction of standards that apply to the given architecture,
    Including information assurance functions.

    Bookmarks
    that are constantly updated by people around the world use delicious
    feed for netcentric (will need an aggregator to view feed):

    http://del.icio.us/rss/tag/netcentric
    More on Netcentrics, Ditscap, DIACAP and Information Assurance at infoassure.blogspot.com