These FAQs come directly from the most common mission partner inquiries recieved, and from the live Enterprise Connection Division subject matter expert hosted Question and Answer sessions that are available regularly as part of the Mission Partner Training Program. If you would like to attend a live session please visit the training page for more information.
This page contains frequently asked questions on Ports, Protocols, and Services Management (PPSM). Have a question? Submit it here.
Question: Is it a requirement to register in the PPSM Registry?
Answer: Yes, it has been a requirement to register protocols in the Internet protocol suite, and associated ports (also known as “protocols, data services, and associated ports” or “ports, protocols, and services” or “PPS”); since the 2004 release of the first DoDI 8551. The new DoD 8551.01 has been released on May 28, 2014. Click Here to see the document.
Question: How do I comply with PPSM?
Answer: Your use of ports, protocols, and data services (PPS) must: Be documented in your Certification & Accreditation package (DCPP-1) and registered for Risk Management Framework (RMF).
Please be certain that you have completely filled out your certification and accreditation (C&A) package if using the Defense Information Assurance Certification and Accreditation Process (DIACAP) or your Security Assessment Report (SAR) Assessment and Authorization (A&A) information if using the new DoD Risk Management Framework (RMF) process in accordance with DoDI 8501.01 dated 12 March 2014. Under DIACAP the IA Security Control for PPSM is DCPP-1. If the implementation of the PPS is not compliant with the Category Assurance List (CAL) and Vulnerability Assessment (VA) report, it must be marked non-compliant on your DIACAP scorecard. We find that Components are marking PPSM compliant in the DIACAP package, but when we check the Registry, CAL, or VA report we realize that they are not compliant. Ensure there is a POA&M if you are not compliant with PPSM.
For the RMF process the primary PPSM security control is CM-7 LEAST FUNCTIONALITY (3) REGISTRATION COMPLIANCE: The organization ensures compliance with [Assignment: organization-defined registration requirements for functions, ports, protocols, and services].
Supplemental Guidance: Organizations use the registration process to manage, track, and provide oversight for information systems and implemented functions, ports, protocols, and services. Related NIST SP-800-53Rev4 CM-7 related controls include: AC-6, CM-2, RA-5, SA-5, SC-7.
Be registered in the PPSM Registry.
Undergo a Vulnerability Assessment (VA) or Component Local Services Assessment (CLSA).
If your data service(s) does not appear in the latest CAL, then it must undergo a VA Assessment if it is traversing the DISN (i.e. any boundary 1-8 or 15). For PPS restricted inside the enclave (i.e. exclusive to boundaries 9-14 or 16) the Components will generate a Component Local Services Assessment (CLSA) form.
Be assigned an assurance category, and be listed on the Category Assurance List (CAL).
NOTE: The CLSAs will also be uploaded to the Registry and listed on the CAL.
Be configured in accordance with current PPSM policies, procedures, and standards.
Per DODI 8551.01 section 3 Policy, It is DOD policy that:
a. All PPS used throughout planned, newly developed, acquired, and existing DODIN (whether used internal or external to the enclave), which include DoD Information Technology (IT), must be:
(4) Declared, including their underlying PPS.
Question: I am using a data service that is on the CAL, but my implementation is not in compliance with the CAL. How can I become compliant?
Answer: PPSM recommends migration off the non-compliant implementation (e.g. banned service or non-standard usage (NSU)) and comply with the PPSM standard as written and published by DoD PPSM. If the AO/Component cannot meet the standard set by the DoD PPSM CCB, then the AO/Component is required to follow the Exception Management Process to address non-compliance with PPSM standard.
Question: I am using a data service that is being blocked because it is not on the CAL. What do I do?
Answer: To address agility, PPSM has a ‘Temporary’ process to address data services that are Pending [Assessments] and/or have ‘limited duration’ (e.g. Tactical/Exercise). The ‘Temporary’ data services will be displayed on the Category Assurance List (CAL) ‘Temporary’ section following confirmation that the PPS are registered and all required documentation (e.g. FA Template, Scorecard, Network Diagram, and DIACAP Executive package) have been received and validated by the PPSM Secretariat. The ‘Temporary’ data service will not get a formal Category Assurance Level (Color Designation: Green, Yellow or Red) until the Vulnerability Assessment (VA) process has been completed
Question: I registered my PPS, but I still don’t see it on the Category Assurance List (CAL). What do I need to do to get it on the CAL?
Answer: If the PPS is a Local Service that operates solely within the Site’s Enclave boundary and does not leave the enclave (i.e. only traverses boundaries 9-14 or 16), then you must submit a completed CLSA template for the Local Service PPS to be placed on the CLSA section of the CAL.
If your PPS traverses DISN boundaries (i.e. boundary 1-8 or 15), then you must submit a completed Further Action (FA) template and the requirement documentation outlined in the template. Following verification of the required information received, an Analyst ticket will be assigned to conduct a Vulnerability Assessment (VA). The VA must be reviewed by the TAG and voted by the CCB prior to being placed on the CAL.
Question: What is CM-7 and how does this relate to PPSM?
Answer: CM-7 is the (LEAST FUNCTIONALITY) PPSM Security Control in NIST SP 800-53. “The organization configures the information system to provide only essential capabilities and specifically prohibits or restricts the use of the following functions, ports, protocols, and/or services: [Assignment: organization-defined prohibited or restricted functions, ports, protocols, and/or services].” CM-7 references DoD Instruction 8551.01.
NIST SP 800-53 Rev4: Click Here
Question: How does registration impact C&A and how does this relate to PPSM?
Answer: The following PPSM Registry field changes will update the Certification and Accreditation (C&A) Impact Date:
•Adding/editing/removing ports, protocols and services
•Adding/editing/removing boundaries (except for internal use)
Question: What is the difference between Non-Standard Usages (NSUs) and Component Local Services Assessments (CLSAs)?
Answer: A Component generates a CLSA for Local Services that are not listed in the CAL standard section. A Local Service is a Data Service that operates solely within the Site’s Enclave boundary (i.e. boundaries 9-14) or traverse a PPSM approved tunnel where both enclaves are controlled by the same Authorizing Official AO (i.e. Boundary 16). A CLSA may not be submitted for a data service for which an approved standard exists (i.e. listed in the Category Assurance List (CAL) standard section and covered by an existing VA report). An Exception Request is required for non-compliance with an approved standard (i.e. NSU).
An NSU is an organization’s non-compliant implementation of an approved data service listed in the CAL standard section (i.e. Non-Standard Port Usage (NSPU) or Non-Standard Boundary Usage (NSBU)). For example, the use of a port not listed in a standard VA (NSPU) or crossing a restricted boundary (NSBU).
Question: Where is the PPSM Registry located, and how do I get an account to access it?
Answer: At present, the PPSM Registry is only located on the high-side (i.e. SIPRNet). Currently all registrations have to come in through the high-side until we deploy the low-side Registry [ETA Q3 2014]. PPSM is currently working to roll out a low-side (i.e. NIPRNet) instantiation for users who simply have an unclassified system, application, or device that they need to register.
To gain PPSM Registry Access, first you must have a SIPRNet account; second, you need to have an active PPSM Registry account. If you do not have a Registry account, submit a request for access through your Component PPSM representative. NOTE: PPSM will automatically accept any DD2875 already approved for a SNAP/SGS account.
Effective 16 December 2013, the PPSM PMO shifted the management of ‘User’ ‘ accounts to the Components. Requests for new accounts received by the PPSM PMO Secretariat are forwarded to the Component PPSM CCB/TAG Representatives for action. For audit purposes, the Components are expected to maintain a DD Form 2875 for each User account created. Additionally, Component CCB/TAG Reps will only be allowed to grant users permissions up to the level of permissions they currently possess. NOTE: Components are advised not to grant CCB/TAG permissions (PPSM CCB/TAG Rep) to just anyone, since doing so will give them the rights to make unintended Org deletions. NOTE: PPSM will automatically accept any DD2875 already approved for a SNAP/SGS account.
DoD Component [PPSM CCB/TAG] Contact list:
Question: Why are you building a low-side PPSM Registry?
Answer: PPSM is aware that not everyone has the high-side terminal at his or her desk for registering. PPSM does not want registrants to have to drive or walk just to register low-side systems. Registrants should to be able to keep their registrations up to date easily, and even from tele-work if possible. Unclassified registrations account for approximately 80% of what is in the PPSM Registry. The percentage of PPS registration compliance will likely remain low until we can get the low-side instantiation out there. PPSM hopes to accomplish the low-side NIPRNet instantiation by Q3 FY15.
Question: I have many registrations I need to add. I have heard this can be done using a ‘Bulk Upload Spreadsheet (BUS)’. Can I get more information on this capability?
Answer: The BUS capability is only available to PPSM CCB/TAG members. It is a spreadsheet used to automatically import new DoD IS and PPS information into the PPSM Registry. Please contact your CCB/TAG member for more information wrt the BUS capability. NOTE: The BUS does not support uploading data services or IP protocol names that are not listed in the Registry drop-down.
Question: Is each site going to have to register the DoD Enterprise PPS, like HBSS, Site Protector, etc. or is there going to be one person that does that for the DoD Enterprise?
Answer: Yes, each site will have to register their own instantiation. When you installed your enterprise system (e.g. HBSS), you had to update your site accreditation package; thus you will need to register to ensure your PPS registration matches your accreditation package.
Question: Where do I find PPS that are already registered as Enterprise PPS?
Answer: We do not have a differentiating process for Enterprise PPS and do not separate or distinguish Enterprise PPS in the CAL.
Question: Do all NIPR and SIPR packages need to be registered on the high-side?
Answer: PPSM does not deal with circuit packages. However, in accordance with the DoD 8551.1 dtd May 28, 2014, all PPS used throughout planned, newly developed, acquired, and existing DODIN (whether used internal or external to the enclave), which include DoD Information Technology (IT), must be declared in the PPSM Registry.
Question: We have a SIPRNet connection, and we are replacing the VPN components. Do we need to do some modification of our registration?
Answer: Yes. Just as you need to update your package through the CAO SGS/SNAP, you also need to make sure that your information is update to date in the PPSM Registry.
Question: Do both internal and/or external PPS have to be registered?
Answer: The DoD 8551.1 dtd May 28, 2014 registration requirement applies to all PPS used throughout planned, newly developed, acquired, and existing DODIN (whether used internal or external to the enclave), which include DoD Information Technology (IT).
Question: We have an application where we have changed either the data service or the TCP/UDP port numbers. Do we need to perform re-registration or modification of our existing registration?
Answer: Yes, you must update your registration as soon as changes occur in your implementation to ensure your PPS registration remains current throughout the life of your DoD IS. You will want to confirm your PPS information is on the Category Assurance List (CAL) and not subject to access-control blocking policies. The bottom line: your registration should match what is on the network at all times. Failure to update your registration will negatively impact interoperability; in essence, compromising the value of your uninterrupted access to government resources and critical applications.
Question: It seems like not as many people are participating in the PPSM program as heavily as we are. Although we know other programs are using the same PPS we register, we do not see the PPS information in the CAL. What percentage of DoD do you think are using the PPSM Registry?
Answer: Unfortunately, we believe the registration percentage is currently small; however, PPSM is working many efforts to make registration easier [through federation and automation] and more accessible [via a new low-side Registry instantiation].
Question: Where are we going with the Cybercom White List (WL) and PPSM. Once PPS is registered in the PPSM Registry, why isn’t the Cybercom WL registration automatically creating at ARNLD? Why can’t the WL registration be created from the PPS registration?
Answer: PPSM would like to have both registration processes combined and a ‘one stop shop’. In compliance with Cybercom TASKORD 12-370 but there is currently no federated connection between the two databases.
Question: Why are some data service names on the Registry drop down list, but not on the CAL?
Answer: The data services names that appear on the Registry dropdown list but are not listed on the CAL are either ‘variation names’ of the data service names or data services that are in ‘pending’ status (i.e. currently being assessed by the PPSM VA team). Upon request, PPSM will provide you a list of the variation names with the mapping to the VA standard name.
Question: IP addresses are always being updated. Can we register the server names or FQDN in lieu of the IP address number?
Answer: Currently the Registry does have a separate field for populating the FQDN or Domain information.
Question: What IP address information should be populated in the ‘DoD IS IP Address’ and the ‘Perimeter Gateway IP address’ fields in the Registry DoD IS screen?
Answer: The DoD IS IP Address and the Perimeter Gateway IP address fields will be populated based on the DoD IS information that should already be in your ATO package. The DoD IS IP Address field should contain the DoD IS network segment information. The Perimeter Gateway IP address should contain the IP address(es) of the enclave gateway router where the DoD IS is located.
Both fields accept multiple formats such as: a single IP address (e.g. x.x.x.x); a notation (e.g. x.x.x.x[/n); or a range (e.g. x.x.x.x –x.x.x.x)
These fields are irrelevant to the assurance category of your PPS(s). Currently the fields are optional, but in the very near future they will become mandatory. It is important that you populate these fields now. The information should already be in your ATO package.
Question: Wrt the ‘Application’ field in the PPSM Registry, what exactly is an Application and how should the field be completed?
Answer: An Application is a software program that performs a specific function. The ‘Application’ field in the Registry is a mandatory. You should enter the name of the Application (i.e. application name) that uses the data service. The application name may be vendor propriety (e.g. Adobe-Connect, Cisco-Anyconnect) or open-source (e.g. MySQL Server, OpenSSH). If the data service or protocol runs directly from the Operating System (OS) (e.g. NetBios, ICMP), then enter the OS name (e.g. Windows Server 2012, Red Hat Enterprise). If this is a process-driven service (e.g. RPC) that calls a specific program, then enter the program name.
Question: What constitutes a valid registration?
Answer: Registrations with [NOT LISTED] will be considered an ‘incomplete registration’ requiring Further Action; and as such considered an invalid registration. Completing the registration process is as follows:
1. Organization creates a registration within the PPSM Registry
2. PPSM Analyst is assigned a ticket to work the registration
3. PPSM Analyst determines whether or not the Service(s) registered already exists; and are listed on the Category Assurance List (CAL)
4. PPSM Analyst works with the customer to either create a ‘new’ Vulnerability Assessment (VA) report or correct the registration to an existing previously approved standard that is already listed on CAL
a. If a VA report is created, the Analyst will submit the VA report to the CCB/TAG for processing and approval
i. Once the VA has been approved by the PPSM CCB, the report will be published on the respective PPSM websites and the Analyst will update the customer
ii. The further action will be cleared by the time the Analyst contacts the customer
b. If the registration is updated correctly, the registration will be cleared off the Further Action report
Following these steps, the registrations with [NOT LISTED] in the Service name will be cleared through the normal VA process.
Question: I received a Confirmation of Registration email, but some of the PPS registrations have discrepancies. What do I do and how long do I have to resolve these discrepancies?
Answer: Depending on the discrepancy, different actions are required. Contact your PPSM CCB/TAG representative to initiate the required action for the discrepancy. The Component must submit required information to PPSM WITHIN 60-DAYS to prevent automatic deletion from the PPSM Registry.
Question: What are the high-level steps of the Vulnerability Assessment Process?
Answer: In summary, the steps of the Vulnerability Assessment process are:
1. The Technical POC provides the required information/documentation to the PPSM VA Team, if not already done.
2. The vulnerability assessment is conducted by the VA Team to determine the recommended Category Assurance Level for each protocol/data service and a draft VA report is prepared.
3. The draft VA report is presented to the PPSM Technical Advisory Group (TAG) for review and forwarded to the Configuration Control Board (CCB) for approval.
4. Approval is granted by the PPSM CCB.
5. The protocol(s)/data service(s) is added to the CAL and the approved VA report and updated CAL are published for use by the DoD community.
Question: How do you assess PPS and evaluate risk?
Answer: PPSM has its own assessment criteria and process that is constantly updated as DoD policies change and technology advances. PPSM is working on publishing the assessment process for the community following. Until the process is published, information wrt PPSM processes can be found at one of our various websites.
Question: What are Vulnerability Assessments (VAs) and the Category Assurance List (CAL)?
Answer: A VA report documents the vulnerability assessment;operational risk assessment and security implementation strategies of PPS based on its capability, functionality, and exploitability; and are the authoritative PPSM artifacts used to help reduce the risk to the DODIN and JIE while meeting operational requirement.
The CAL is a summary reference used for implementing and promoting the standardization and management of PPS used on DODIN.
Question: What is the meaning of the Functional Capabilities on the Vulnerability Assessments (VAs) reports?
Answer: Functional Capabilities are the inherent functions of the data service, even if the capability is not enabled. As the number of functional capabilities increase, the number of potential vulnerabilities increase and a plan has to be implemented to reduce the risk.
Question: What is the process for the internal data services (i.e. Local Services) that do not leave the Enclave accreditation boundary? Do Local Services have to be registered and assessed?
Answer: The 8551.1 dated 2004 did not have any Local registration requirements. However, the new 8551.01 released on May 28, 2014 does require you to register your Local Service PPS.
PPSM has an agile process called ‘Components Local Services Assessment (CLSA)’ for listing Component Local Services in a separate section on the CAL when all CLSA requirements are met.
Question: How will the Joint Information Enterprise (JIE) architecture affect the PPS boundaries and assessment criteria?
Answer: PPSM is currently working with JIE engineers to ensure the PPSM process and boundaries seamlessly map to the JIE Single Security Architecture (SSA). Thus far, PPSM anticipates minimal change to the PPSM process.
Question: How can I find the approved PPS and boundaries for a particular device or vendor application? (e.g. How can I find the approved PPS Tandberg Video Terminal Controllers (VTC)) that connect to the DISA Bridge on SIPRNet?)
Answer: The Category Assurance List (CAL) displays Internet Protocols (IPs), data services, and associated ports (i.e. PPS). The reason the CAL is not tailored to be device specific is because redundant PPS information would be displayed. You must first review vendor documentation for the particular device to see what PPS are used, and then review the PPS information in the CAL and VA report.
Question: What is the Whitelist checkbox on the VA report?
Answer: The ‘White List’ FC checkbox will automatically check on a standardized data service VA based on the following rule:
• Unclassified Network Assessment
• PPSM Boundary 1 (External to DoD Gateway) is Acceptable (i.e. YELLOW)
• Functional Capability (FC) is identified at minimum as one of the:
• 4 Pillar FC categories on VA: ((E) Email Services, (W) Web Service, (N) Name Service, (F) File Transfer) OR
• Data Service(s) identified on USCYBERCOM TASKORD 12-0370 and TASKORD 14-0097.
Question: What is the difference between ‘Website (e.g. Webserver)’, ‘Web services’, and ‘Web Applications’; and is the PPSM assessment process different between them?
Answer:
• WEBSITE: Is a Repository that simply presents content (web pages) to a user via a browser using HTTP or HTTPS GET and POST requests.
• WEB SERVICES: Is a Software system designed to support machine-to-machine interaction often used for data transfer. It has an interface described in a machine-process able format (specifically WSDL). Other systems interact with the Web service in a manner prescribed by its description using SOAP-messages, typically conveyed using HTTP with an XML serialization.
• WEB APPLICATION: Is an interactive web interface to configure, manage, and/or monitor the application and/or device.
The PPSM assessment process is different between these 3 categories. The HTTP and HTTPS Vulnerability Assessment (VA) Reports cover the use of Websites; and does not address Web Services and Web Applications. Because Web Services and Web Applications are designed to provide specific function and/or capability and the use of HTTP/HTTPS as transport is only secondary, for situational awareness these must be registered as the particular web service/web application implemented for assessment based on their specific functional capability and built-in security features.
• PPSM Registrations of Data Services using HTTP/HTTPS for WEBSITEs will require an HTTP or HTTPS NSPU Exception when using a non-standard port.
• PPSM Registrations of Data Services using HTTP/HTTPS for WEB SERVICES and/or WEB APPLICATIONs (where the data service is not listed on the standard CAL) will either require a CLSA (if Local) or submit FA template for a customized VA (if traverses DISN boundaries).
Question: What is FIPS 140-2?
Answer: Federal Information Processing Standard (FIPS) 140-2 is a National Institute Standards and Technology (NIST) standard used to accredit cryptographic modules. The NVLAP accredited Cryptographic and Security Testing (CST) Laboratories perform conformance testing of cryptographic modules.
Cryptographic modules are tested against requirements found in FIPS PUB 140-2, Security Requirements for Cryptographic Modules: Click Here
The following is a list of all vendors with a validated FIPS 140-1 and FIPS 140-2 cryptographic module:
NIST SP 800-53 Revision 4 Security Control (SC) 13 states:
(1) CRYPTOGRAPHIC PROTECTION | FIPS-VALIDATED CRYPTOGRAPHY
The information system implements, at a minimum, FIPS-validated cryptography to protect
(3) CRYPTOGRAPHIC PROTECTION | INDIVIDUALS WITHOUT FORMAL ACCESS APPROVALS
The information system implements, at a minimum, FIPS-validated cryptography to protect
information when such information must be separated from individuals who have the necessary
clearances yet lack the necessary formal access approvals.
(4) CRYPTOGRAPHIC PROTECTION | DIGITAL SIGNATURES
The information system implements [Selection: FIPS-validated; NSA-approved] cryptography to
Question: Where can I find more information on the PPSM 16 network boundaries?
Answer: PPSM maintains definitions of the PPSM 16 Boundaries at the following site below. Contact your PPSM CCB/TAG representative if you cannot access the below document.
Question: I have a question about the network boundary diagram found in the VA reports: as an RDT&E tenant enclave on the DREN, how do I determine what path my PPS take when communicating to other RDT&E enclaves on the DREN? If I am on one DREN site, and I need to connect to another geographically separate DREN site, do I traverse the DoD-level DMZ service and then back to DREN?
Answer: The DREN is treated as one Enclave, so the connections between DREN Enclaves are considered Boundary 16. Boundary 16 represents tunneled network traffic between geographically distributed enclaves controlled by the same AO, where the tunnel is approved by PPSM:
A: to be encrypted and requires confidentiality and integrity protection (i.e. NIST FIPS 140-2 or NSA-approved cryptography).
B: to be unencrypted and contains encrypted data that requires confidentiality and integrity protection.
C: to be unencrypted and contains data that does not require confidentiality and integrity protection.
Question: We have a Medical Treatment Facility (MTF) tunnel [MTF-to-MTF] that traverses the DoD Internet Access Points (IAPs). Is the PPSM tunnel policy the same whether the PPS is internal to the DISN or traversing the IAP?
Answer: Yes, the PPS policy is the same for tunnels everywhere, including the DISN.
Question: Will the civilian agencies coming on board be required to follow your PPSM guidance.
Answer: Yes, when civilian agencies are required to follow the DIACAP RMF process, they are also required to follow PPSM policy.
Question: What about tunneled VPN/GRE traffic for multiple internal sites?
Answer: Boundary 16 represents tunneled network traffic between geographically distributed enclaves controlled by the same AO, where the tunnel is approved by PPSM:
A: to be encrypted and requires confidentiality and integrity protection (i.e. NIST FIPS 140-2 or NSA-approved cryptography).
B: to be unencrypted and contains encrypted data that requires confidentiality and integrity protection.
C: to be unencrypted and contains data that does not require confidentiality and integrity protection.
Boundary 15 represents tunneled network traffic between two or more enclaves controlled by multiple AOs that have set up a mutual agreement to exchange information, where the tunnel is approved by PPSM:
A: to be encrypted and requires confidentiality and integrity protection (i.e. NIST FIPS 140-2 or NSA-approved cryptography).
B: to be unencrypted and contains encrypted data that requires confidentiality and integrity protection.
C: to be unencrypted and contains data that does not require confidentiality and integrity protection.
Question: What is the PPSM Read Board?
Answer: The PPSM Read Board (distributed monthly) is a method to inform the community of recent and upcoming PPSM PMO activity including, but is not limited to: important PPSM PM comments, information on new policies and procedures implemented; list of upcoming events; new developments coming ahead; and finally a list of last month’s CCB voting results; administrative updates; NSU and CLSA publications.
The PPSM Read Board is posted on all PPSM websites and also emailed to a distribution list. Please contact PPSM if you would like to be added to the monthly PPSM Read Board email distribution.
Question: Where can I get additional PPSM information, reference materials, templates, and training?
Answer: PPSM has several websites where contact information, process guides, and vulnerability assessments (VAs) are maintained. Some of the directories are only accessible to CCB/TAG members, so you may need to contact your PPSM representative for more information.
NOTE: Directory includes: Functional Capability Defintions, Network Boundary Definitions, Implementation Strategy Business Rules, etc.
Question: How can I contact PPSM?
Answer: It is best to contact your PPSM Component CCB/TAG representative. If you reviewed the DoD Component Contact List and are still unsure who your representative is, then you may contact your equivalent Authorizing Official (AO) or Chief Information Officer (CIO) department.
If necessary, you can contact the PPSM PMO at:
Question: Our organization is not on the PPSM CCB/TAG DoD Component Contact List. How can our organization become a CCB/TAG member?
Answer: Please have your equivalent Authorizing Official (AO) or Chief Information Officer (CIO) contact dod.ppsm@mail.mil to request membership. In addition, your organization must be under DoD, or a DoD mission partner; already have access to the SIPRNet; and must either submit a DD2875 or have a SNAP/SGS account in order to become a CCB/TAG member and access the Registry. DoD Component Contact List
Question: Why does the Air Force require the AF-DoD PPS Worksheet?
Answer: The AF requires the AF-DoD PPS Worksheet to support certification and accreditation decisions (authorization decisions) by documenting the PPS used by the system, boundaries crossed, and compliance with DoD PPS guidance represented by the DoD PPS CAL and associated DoD PPS VA reports. Also, the AF-DoD PPS Worksheet allows domain-only registrations when IP addresses are unknown (type accreditations); whereas the PPSM Declaration Artifact is strictly IP addressing.
Question: What is DODIN?
Answer: Department of Defense information networks, or DODIN, formerly called the Global Information Grid, is a globally interconnected end-to-end set of information capabilities for collecting, processing, storing, disseminating and managing information on demand to warfighters, policymakers and support personnel
Question: Is there current or future requirements to register JWICS PPS information?
Answer: JWICS is excluded from DoDI 8551.01 requirements because it is considered part of an intelligence system.
Question: I have read through all your documentation and watched the CBTs, but still have questions. How can I get my questions answered?
Answer: PPSM would like to ensure we address all your PPSM related questions, comments, or concerns. Please send an email to Dod.ppsm@mail.mil listing all your PPSM relate questions and your available future dates/time for us to schedule a PPSM meeting with you.