Joint Practitioner/Developer Webinar Program Integrated Public Alert and Warning System (IPAWS) Open Platform for Emergency Networks (OPEN) Operational Collaborating Operating Group (COG) Access Procedures Wednesday June 1, 2011 12:00 Noon Eastern Avagene Moore: Ladies and Gentlemen: We welcome each of you to the June 1, 2011 Joint Practitioners and Developers Webinar! I am Avagene Moore and will serve as your Moderator today. We are recording today’s Webinar and trust you will benefit from the presentation we have planned for you. Please note we will let you know when today’s recording and slides are posted. We will also provide a link to the COG MOA Questionnaire when it is available. [Slide 1] And now to our speaker – we are pleased to have Mark Lucero with us today. Before joining FEMA in September 2009 as FEMA IPAWS Engineering Chief, Mark served as the lead engineer for the Defense Information Systems Agency's Technology Analysis Center, where he was responsible for evaluating emerging technology and advising the Chief Technology Officer on the Agency's technology investment decisions. Mark holds two engineering degrees and brings 8 years of engineering experience in the public and private sector. As explained through our mail lists, we are here primarily to discuss IPAWS-OPEN Operational COG Access Procedures. Mark will also provide an update of IPAWS OPEN as well as the FEMA IPAWS equipment conformance assessment before getting into detail on the COG MOA process. Mark, thank you for being here – I turn the floor to you. Mark Lucero: Thank you. I have some updates on the program to share with you and I’d like to go over the new MOA process for getting your COG with the new system. [Slide 2] This is the status update. As many of you are aware, we will decommission the DMIS tools and DM-OPEN 1.0 at the end of this month. We have sent out email reminders to let people know. We are fielding emails on the DMIS emails address that we monitor. We have been testing with several vendors. Some vendors have products they are connecting to IPAWS and testing out. These are origination systems. There are also alert dissemination systems testing with us. There are a good number of systems testing with us and you can visit this URL to get a list of who has an MOA for testing: (http://www.fema.gov/pdf/emergency/ipaws/open_developers.pdf) [Slide 3] This is a status update on supporting the CWID (Coalition Warrior Interoperability Demonstration). CWID is an annual DOD exercise that brings in different technology and they have real war fighters using these systems in a structure demonstration. The intent is to assess these new technologies and provide investment decisions to senior leadership in armed forces as well as any others who are participating, like FEMA. In CWID this year, there are several systems that are going to be using IPAWS for information exchange and the silhouette about this one is that we’re showing information exchange between civilian and military systems. There is a listing of the people who are participating here using IPAWS of products of IPAWS. The demonstration occurs June 6-17. There is an opportunity for people to visit and get a walk- through and get briefings on all the technologies. The information is at the bottom of the slide. As an update to this update, we are working on an issue with the participants posting alerts. They can retrieve alerts and message lists, but the posting is problematic. We have some of our senior engineers working on this. We should have some good news by the end of the day. [Slide 4] Here’s an update on the Conformity Assessment Program. ICAP is a program that takes in vendor products and assesses their conformity to the Common Alerting Protocol (CAP) and the IPAWS profile. So far, four products have passes testing and they are on the responder’s knowledge base. You can visit that site and see the supplier’s declaration of conformity. An SDoC says that the vendor has sent the product through testing—it passed—and test results can be provided if necessary. The four that have passed are EAS devices. [Slide 5] This is a walk-through with screen shots. If you visit http://www.rkb.us , click on “other content”. Under “certifications and declarations”, you’ll see on the bottom left a list of all the certifications that they have on the RKB. You’ll want to click on IPAWS SDoCs. [Slide 6] This will bring up a listing. Right now we have four EAS devices selected there. [Slide 7] On this slide, we’ve selected Trilithic EASy CAP software. That portion circled at the bottom, you can click to view the SDoC. That will give you all the information you need to be certain that this product is conforming to the profile. [Slide 8] The future of the Conformity Assessment Program—FEMA has funded the program for two years. The period ends at the end of August. We do not have plans to continue the program past August. The program is to provide to us a transition plan that can be passed on to any other lab that wants to continue this testing. Vendors can look at the NIMS STEP website—they do testing to include CAP. The FCC issued a notice of proposed rule-making in which they are seeking comments on how to extend certification for EAS devices. [Slide 9] This slide shows what the capabilities are for IPAWS 2.0. The initial operating ability will give you the ability to exchange EDXL-CAP messages and EDXL-DE wrappers. You use CAP for sending alerts to exchanging messages with another COG. You use EDXL-DE to wrap various XML content. The NOAA non-weather emergency messages—the previous system had a connection to NWS for sending alerts over NOAA radio. We are continuing that with this system. We are working on setting up the physical connection between IPAWS-OPEN and the HazCollect server. That connection should be completed shortly. If you send us an alert destined for NOAA, you need approval through NOAA to get the message through. IPAWS looks at, authenticates, and validates you message, there is an authentication happening at NOAA, too. If you want to send messages through NOAA, you will need to get onto their approved COG list. If you have a COG that you were previous using to send NOAA alerts, when you get a new COG you’ll have to go through that process again. We will be implementing EAS and CMAS/PLAN connections later this year—early September to meet the FCC deadline of September 30. Cellular alerts will be online later this year. [Slide 10 - 12] These slides outline the process for getting a COG with the new system. The first thing we have to do is post a questionnaire on the IPAWS website, which should be done by the end of the day today or by the end of this week. You will want to review the information. There are eligibility requirements—you must be an organization in the United States. Typically, you would be an emergency management agency. This is for getting a COG to get access to IPAWS-OPEN. This doesn’t mean you’ll be able to send alerts. There is another process for that. You need to have origination software. There is a list of vendors testing with OPEN and you can look at that list to find out whether or not they have tested with OPEN and have a MOA with us. Fill out the questionnaire. You’ll give a detailed description of the system you’ll be connecting to OPEN. Once you’ve sent that to us, we’ll review that. If you are not eligible, we will let you know. If you are eligible, we’ll make sure all you information is there. We will ensure that you are who you say you are. After that, FEMA will prepare the MOA. We will send it back to you for you signature. FEMA will provide you with a COG ID and a digital certificate that is necessary for signing your messages and connecting to OPEN. You will be given a copy of the MOA and your vendor will install your signature on your software. You should be good to go. [Slide 13] This is highlights of the MOA. There is a part about rules of behavior. You will be required to sign a “rules of behavior” which says you will not misuse the system and be responsible for any alerts you send. [Slide 14] This slide shows some of the things you’ll be signing up to based on security principles and practices that FEMA requires of users—strong passwords changed every 90 days, security awareness training—it is standard stuff if you have computers in your EOC. [Slide 15] I can answer questions you have. Avagene Moore: Thank you, Mark. It is time for you, the audience, to ask any questions you may have – we want to hear from you. We also have Gary Ham and Tom Ferrentino in the audience to help with questions today. Audience Question: Will a single certificate cover all devices operated by an agency? Mark Lucero: Yes. The signature is tied to your agency, not the device. Audience Question: Can you go into greater detail on what is the "wrapped" content of the DE? Can you provide an example of what type of content this is? Gary Ham: One of the capabilities that IPAWS-OPEN provides is an interface that allows the exchange between COGS of data that is wrapped in a standard structure known as a distribution element. This is not a publication like an alert. The distribution element provides meta data that lets people know what the message is about, where it comes from, and if they want to get the message. The content inside the wrapper is essentially chosen by the system or user who wishes to build it. There are standards for resource messaging, hospital availability and an emerging standard for transportation of emergency people for medical purposes. Also within the DE you could an Information Exchange Package (IEP) within an exchange using EDXL. The capability is in IPAWS-OPEN. It has to be developed by systems that use IPAWS- OPEN to unwrap the data on the other end and process it. Some of them include the folks that are doing some of the CWID work. There is work going on now with folks using it for a number of different ways, it is pretty much define the data structure and exchange it by wrapping it in a standard piece of information so it goes from COG to COG in accordance with the rules of IPAWS-OPEN. This is not something that would be published. This would be private exchange between private organizations of IPAWS-OPEN. There are other things you can wrap in a DE. It doesn’t have to me XML. A non-XML content item can be wrapped, such as a jpeg picture. There is a lot of capability within EDXL-DE wrapping structure, but there is not a lot of hard definition in order to try to validate the internal content within IPAWS-OPEN. We validate that the DE correct and the user has a validate signature. We do not validate the content. Audience Question: How long does the COG approval request process take? Minutes? Hours? Days? Weeks? Mark Lucero: Probably all of the above. This is a new process so we will have a better idea after we have gone through a few of these. Gary Ham: To get into the test environment for the vendors, the average is about five days. The amount of work is about two hours. It’s all the wait time in between as things go through the process. For basic COG access, it would be very similar. For NOAA designation, it may take longer. I would figure on a week as the standard, but it could be shorter or longer. Audience Question: If an Incident Management System is connected to IPAWS via an adapter (for EDXL and CAP verification), will all users of the IMS have to conform to the FEMA security requirements, or only account holders that have the permission to "Send to IPAWS"? Mark Lucero: It will only be account holders. Anyone who has access to send anything to IPAWS would be subject to the rules of behavior. If you have a system being used for multiple things, and only one or two people have the ability to send alerts, then those would be the ones to sign up for the rules of behavior and the security requirements around that. Audience Question: Can you go into more detail on how a message will make it to the HAZCollect system. Will it require another certificate from NOAA? Mark Lucero: Generally, when we send the message to NOAA for retransmission, they are looking at the COG it comes from. If the COG isn’t on their list of approved COGs, they kick it back to us. If you are on the list, it goes through. Gary Ham: The simple fact is that it is not going to require an additional signature. It is an additional permission that the particular COG you are using has. That permission is granted by the National Weather Service. The NWS identified particular COGS that are authorized to issue alerts via NOAA’s weather radio system. Your vendor can implement a function called “is COG authorized” that can do a test with your COG ID to test if you have been authorized or not. They can also check to which areas you are allowed to post a non-weather emergency message. A message going to NOAA requires a particular structure and certain information. Your vendor’s software should be built in such a way that provides the correct information for NOAA. It is all CAP, but it also has some restrictions. There is no extra signature required, but that COG must be certified by NOAA. If you already have that, chances are NOAA would make your COG approved very quickly. Amy Sebring: The point to note is that you will need the new COG ID number before you apply to the NWS for HazCollect access if you are not a previously approved COG. There is a required online training course. It is about three hours of continuous self-study. The URL is on the slide for the HazCollect Website which will need to be updated. Audience Question: With these tight security constraints, how could we enact cross-border communication? Mark Lucero: That has been a concern for awhile. It is on my list to do. There is a cross border demonstration that will happen at the end of the month with Vancouver. We are looking to leverage a version of IPAWS-OPEN that is not on FEMA’s network so we don’t have the security restraints. If we can pull that off, it will show that we can technically we can do it without issues. The biggest issue is policy. There are several examples of cross border communication with the U.S. government. I am looking to collect as much information on those as possible to go to security and see if they can grant an exception to some of the rules they have put in place. Based on the way IPAWS works, this information exchange is not a direct connection. It is like an email or web server. The system has controls in place that can prevent unwanted access. I’m hopeful we will be able to allow Canadian connection, but as it stands right now policy wise, we can’t allow it. I will provide an update when I get it done. Audience Question: Just to clarify - FEMA will have one central COG or will they have regional COGs? And will the FEMA COGs be the only "sources" of alerts we need to pass onto our customers? Mark Lucero: FEMA doesn’t have COGS. We don’t create alerts. FEMA is in the middle brokering messages. We take messages from the emergency manager and passing it to public infrastructure. We are providing assurances that the messages have been authenticated. The people with COGS are going to be state, local, and territorial emergency management agencies—one per state, one per county—something of that nature. Gary Ham: Note that there are two types of alerts that go through IPAWS-OPEN: COG to COG for private alerts, and public IPAWS profile-conforming alerts meant for public dissemination. Those alerts are going to be provided on feeds. These feeds include NOAA radio, EAS for broadcasters, and public feeds accessible by the general public, if the alerts are approved. Other alerts can be sent from COG to COG and they just have to be validated to CAP. Audience Question: Several of the agencies within the NY/NJ/CT/PA metro area are very interested in using IPAWS-OPEN as a platform to exchange non-alert interagency messages such as EDXL-RM or EDXL-SitRep (eventually). It seems that IPAWS-OPEN 2.0 can currently support this, so long as these messages are wrapped in EDXL-DE. Since this functionality is not specifically required in the Executive Order that mandates IPAWS, what is FEMA’s position on users of IPAWS using the platform in this manner? Will the exchange of messages such as EDXL-RM or EDXL-SitRep (wrapped in EDXL-DE) continue to be a function of IPAWS that is permitted and supported by FEMA in the future? Mark Lucero: I think the answer to all those questions is yes. IPAWS-OPEN supports the EDXL family of standards. CAP is the main one we are concerned with. It is not part of the executive order to support EDXL and EDXL-RM and SitRep, but this information exchange is critical to incident management in creating situational awareness. Those are key pieces of information people need when they craft their alerts. The system supports those standards. Can you use it? Yes. Do we perceive that IPAWS- OPEN will continue to support those standards? Yes. Gary Ham: As we go forward, there is a reason to keep the DE in play. If we get to the point where we require encryption on any type of content for exchange, the DE provides the means for encrypting content. As far as distribution is concerned one of the things we are going to be experimenting with is different means of distribution for public alerts. DE may provide an improved method of distribution. There are a number of aspects where DE comes into play that may have value as we go forward. Audience Question: After the public RSS feed is established, are there any plans for a public XMPP feed for push notifications? Mark Lucero: The federal government has been stand-offish towards XMPP. We will stand up an RSS feed for EAS. As far as a push notification, there are a few third-party secondary distribution vendors that we have signed MOAs with that are looking into that. Stay tuned. I can’t make promises for those vendors, but some are looking into it. Gary Ham: I think of that as a recruiting action on Mark’s part. Those of you who have the ability and wish to do so, as long as you do not break the content structure of the messages we send and provide publicly, I think would be encouraged to provide better user interfaces to the access to the messages. Mark Lucero: We are standing up an RSS feed for EAS, for broadcasters. They will be pulling us pretty frequently, and there are a lot of broadcasters. If we’re paying for hosting per hit, we are going to be paying a lot of money. The chances that we are going to extend an RSS feed to every person in the United States for each of their technologies to pull FEMA at regular intervals are very slim. Push technology scales much better for applications like that—I would encourage third-party or redistribution vendors to provide that service. FEMA is limited in what they can do by their budget. Audience Question: I understand the plan is to wait until after CWID is over (June 17th) to implement the new COGs in the production environment. Is that correct? Mark Lucero: Yes, that will give us enough time to put this process in place, and not so far away that we can’t start processing a few COGs before DMIS is decommissioned. Gary Ham: We need to process operational COGs with the objective of providing certificates and COG IDs as soon after June 17 as possible. We are ready to start now with authorization processes. Mark Lucero: Let’s work these in parallel. Get your MOA questionnaire signed and sent to us and we can process them while we’re waiting. Audience Question: A real basic question. If we currently have a COG what steps do we need to accomplish now to move from DMIS to IPAWS? Mark Lucero: Two things—whatever system you are using will have to work with IPAWS-OPEN 2.0. That will involve either shopping for a new system or speaking with your vendor to see if they can write the interface to open 2.0. You’ll need to follow the process to get a COG that is listed here. It is a different system so you will need a new COG. Avagene Moore: Mark, speaking on behalf of our audience today, thank you for your time and effort in today’s presentation and update. Very good job! Gary and Amy, thanks for your input as well today. Tom, we appreciate your presence as well. To you the audience – We sincerely appreciate your participation, interest and questions. Please note the contact information on the screen. Please let us know if we can help you in any way. It is our goal to keep you updated on IPAWS and IPAWS OPEN as the program moves forward. We encourage you to join us each time we meet – your presence and continued interest are important to us. Please watch for Mail List notices of future Webinars. You are always welcome! Thank you all. The Joint Practitioners and Developers Webinar is adjourned.