FACTS and Sensorship: A New Kind of Entrepreneurial Partnership
If you have navigated to this story expecting a discussion about the folly of fake news and censorship, then we have done our job to pique your interest. However, this story is about an entirely different, bold new proposal to assist the Federal Emergency Management Agency (FEMA) in keeping citizens safe during times of disaster.
The proposal described in this story calls for a digital-driven extension to the Department of Homeland Security’s Flood Apex Program called FACTS — FEMA Associated Collective Transportation Sensors. According to FEMA, the Apex Program “applies new and emerging technologies to improve community resilience from flood disasters.” Currently, the Apex Program includes emerging technology initiatives for an automated inventory system for national structures, for hazard assessment and mitigation planning systems, for Internet of Things (IoT) based flood inundation sensors, for a smart alerts pilot program, and for Landsat technology to automate flood extent mapping.
According to an Apex infographic flash flooding claims 200 lives a year and other types of flooding claim 80 lives a year — 50% are vehicle related. Unfortunately, none of the current Apex initiatives incorporate extensive and growing sensor technologies which turn millions of vehicles into mapping/measuring devices and also happen to carry millions of people to safety in the event of an emergency.
Cars are becoming sensor beds of the future and one tech writer is convinced, “data collected from vehicles will change the world. With millions of vehicles on the roads every day, they will be collecting data everywhere and on potentially everything they come across.” FEMA must position itself now to collect situational awareness from a sensor enabled fleet of vehicles that will only become more interconnected with the rapid development of autonomous vehicles. The federal government needs vision and open governance to co-opt technology that is already being developed by the private sector.
The FACTS framework proposed here could be used to collect real time data from millions of vehicles to map changing road conditions, flood boundaries, wildfire spread, air quality, weather conditions, and the movement of people. This massive amount of sensor information can be processed with deep learning big data technologies that could in turn broadcast very specific evacuation information to individuals who are in an area of concern. Even if some at risk people are not connected to the Internet, decision makers in a command post could still use interconnected vehicle data to maintain a common operating picture.
Data is critical during a disaster, and data that is mapped provides significant advantages for decision makers. One recent study explored the identification of disaster affected areas using georeferenced tweets in a flood event. The authors say Twitter is considered a “social sensor” and up-to-the-minute information from the tweets can be used to create a comprehensive spatio-temporal footprint of a disaster event. Moreover, “measurements from sensors and reports from the affected population can complement the remote sensing perspective, improve situational awareness, contribute to a common operational picture, and help decision makers to assess the footprint of a disaster, which may extend well beyond the originally affected area.” This application of data is based on just one input — Twitter. We imagine that FACTS could provide more expansive data to provide a more enhanced common operating picture.
The full range of opportunities for autonomous vehicles and the impact of the underlying sensor technology are still unknown but growth in this field will happen quickly. In his book, Delivering on Digital: The Innovators and Technologies That Are Transforming Government, William Eggers reminds us how quickly technology is changing everything we do. He recalls that barely a decade ago, Netflix transitioned from a business model of mailing DVDs into digital delivery of all content. Eggers emphasizes, “transformation will only intensify as digital rapidly makes its way into the physical world.” Unfortunately, Eggers also reminds us that government is painfully slow at transforming bureaucratic habits into digital thinking.
The government’s digital mindset to pursue FACTS is not to rethink emergency management, but rather open the door to partnering with entrepreneurs who are already transforming the transportation industry. In exchange for government fast-tracking regulatory approvals for autonomous vehicle technologies, FEMA could gain shared access to a connected mesh of vehicle based sensor technologies.
FEMA must embrace technology to stay relevant in a digitized world, but more importantly FEMA must adopt new technology to save lives. Apex initiatives are certainly a step in the right direction, but Eggers remarks that government officials cannot merely adopt new technology (because they can never do it fast enough even in the unlikely event they have a proper budget), they must instead change their entire way of thinking. Specifically Eggers asserts, “As governments embark on their digital journeys, it’s important to recognize that ‘being digital’ is about far more than technology — it’s a changed mindset. Digital transformation requires seeing old problems and old processes through new eyes.”
The U.S. government is starting to recognize the inevitable and imminent rise of self driving cars, but congress and the states are stuck trying to adapt current regulations to a completely new problem (or opportunity) space. If FEMA can step in as a champion of change to bring the entrepreneurial world of vehicle based sensors (needed for autonomous driving) and the world of disaster related situational awareness together, the opportunity to transform emergency management into a shared digital experience becomes an exciting possibility.
Using Eggers’ Delivering on Digital as a framework, we want to start hacking away at bureaucracy and technology obstacles. A bold partnership between FEMA and autonomous transportation systems requires us to hack delivery systems; hack hiring and training; hack procurement; and hack the silos of government that could make a FEMA associated collective of transportation sensors possible. We also need to make sure this initiative doesn’t get hacked in the wrong way, making us more vulnerable to cyber-intrusions.
Delivery, Design, and Execution
“Rethinking and reimagining service delivery should always begin with the user rather than the existing program. This means focusing foremost on citizens’ actual needs and touch points, even if they don’t fit or reflect your current operating model.” Eggers in Delivering on Digital.
FACTS is not a widget that rolls off an assembly and comes in a box — it will be delivered as an experience. Each stakeholder through every channel will have a say, and get value in return, including the automakers, government officials, and most importantly, the customers. Our design is centered on how to solve response problems from coastal flooding and other disasters, not on how to make and deliver sensors.
The delivery strategy for FACTS is not traditional supply chain and marketing “plans,” it is an agile approach. For FACTS, agile is not a lofty set of ideals, nor a package of buzzwords. It is a straightforward approach whereby user feedback is made the center of the design, roll out, and continued operations. Automotive companies must adapt sensors to meet a novel set of basic needs that are designed with stakeholder and customer testing and input. The product will change to meet customer needs rather than the customer changing for the product. With FACTS, the customers are a variety of government entities that are collecting data to save lives.
The collected data from the sensors will be processed and returned to emergency managers and users. This information will expand or change based on their feedback. This process will be iterated and expanded as long as value is continued to be delivered. If and when that value stops, the project ends. It is that simple.
Agile Process (not Waterfall) — In Delivering on Digital, William Eggers provides an excellent overview of the agile delivery method, as well as case studies that speak to its importance for government projects. Eggers finds that use of the agile method was the primary explanatory factor in determining eventual success in the federal roll out of HealthCare.gov and the associated state health insurance exchanges. Amtrak, Texas Health and Human Services, and the U.S. Department of Veteran affairs also found success in leveraging the agile approach.
Before moving further into the FACTS delivery plan, it is worth saying what the plan is not. FACTS is not a “waterfall.” Waterfall design is a traditional approach to development whereby the “requirements,” representing all of the users’ needs, are gathered in one phase at the beginning. From there, the project team goes off and completes design, implementation, and delivery. Typically, the next time the user is involved is during “user acceptance testing,” a stage whose name is what it implies — does the product work or not, often ignoring measures of continued utility.
To be fair, waterfall development is appropriate for many types of projects. Mary Lotz provides a great comparison of when each method excels. For example, in projects where the solution is known or knowable in advance, waterfall will deliver a plan that allocates time and resources efficiently to meet that goal, delivering progress feedback at milestones along the way.
Increasingly, in technology development and especially when designing cutting-edge, digital-based projects like FACTS, waterfall would likely result in a framework that is out of touch with current users. Experimental technologies like FACTS require frequent feedback and modifications at the center of an agile development plan. Agile design and delivery of FACTS is the approach that will allow the final solution to account for technology shifts and advancements.
FACTS Delivery Plan
Stage 1 Design → Stage 2 Agile Delivery →Stage 3 Operations
Stage 1 — Design
FACTS design revolves around one question: How can the growing collection of digital information from sensors be harnessed to transform emergency response in coastal areas? In coastal areas wherever there are people, there are cars. In fact, US households average 1.9 vehicles per household, which outnumbers their average number of drivers. If the sensors from even a fraction of the vehicles could be harnessed to report on real time disaster conditions, situational awareness and response would be transformed.
FACTS is predicated on leveraging sensor data that automotive manufactures are going to collect, or are already collecting. Government need not enter the high-tech product development world, it only needs to engage it before it is too late. Self-driving cars already ensure that the sensor data needed for emergency response will be passively collected. If government acts now it can be a part of that future. If it waits until that future arrives, any bargaining power or value add will be reduced, or disappear entirely.
FACTS can begin to design mutually beneficial partnerships with automakers. This design flow from one of two basic arrangements.
Arrangement #1: When automakers and sensor developers have regulatory roadblocks, enrolling in FACTS program will fast track the approval process.
Arrangement #2: Automakers and sensor developers enrolled in FACTS will be eligible for a variety of sensor technology incentive programs designed to accelerate the use of sensor technology.
Once FACTS acquires sensor data the program will ensure value is immediately available to users including both automotive customers and emergency managers. This process begins in the design phase using sample data, prototypes, and user feedback before the data is even obtained. During design, FACTS will collect critical needs directly from pilot participants and any early adopters of the program.
Sample uses include the following:
→ For drivers, GPS navigation screens will be enhanced by FACTS through access to improved video imagery in affected areas, more specific SOS help request ability, and expedited emergency alert broadcast notifications.
→ For automakers, the increased features will act as an additional selling point, plus they will have access to the faster approvals and incentive programs to cut existing costs because FACTS participation will be cost neutral.
→ For emergency managers, FACTS will be a game changer offering a faster and more complete visualization of road conditions, flood boundaries, wildfire spread, air quality, weather conditions, and the movement of people.
To summarize, FACTS design in Stage 1 will:
Collect critical needs information directly from pilot participants →Develop prototypes to satisfy those needs → Put the prototypes into hands of the test group →Collect feedback → Modify and add to the prototype → Repeat the cycle.
Stage 2 — Delivery
The delivery of FACTS will be an experience that will seamlessly fit into each user’s day by adding new digital values with virtually no physical presence. We imagine that delivery can take several forms:
— The emergency management experience will be a web page where users can log in, view the GPS and video data collected from the sensors and send and receive messaging.
— The customer experience will be an application that runs on their car’s navigation screen making the sensor data and emergency messaging available (a website and mobile apps will also be available).
— The automotive experience will be another feature for their customers that leverages their existing technology with minimal effort.
Stage 3 — Operating the service
Central to the operations of FACTS will be a continuation of the agile process that started during design. Feedback links will be embedded in the website, mobile, apps and car apps. This feedback will be compiled and acted on in the versioning process. Additionally, metadata on feature use will be analyzed to capitalize on use and to fix or abandon underused features. When these data are not clear, or when big new experimental ideas are developed, A/B testing will be employed to facilitate decisions.
Customer care will be prioritized by FACTS, but will most likely be another area where partnership with the private sector is critical. Emergency managers, automakers, sensor developers, and drivers should all have access to a customer care center that is staffed with professionals that respond 24/7 to needs coming directly from users messages. This group would monitor social media as well to identify user likes and dislikes, as well as to intervene to help solve problems.
Expected Value from the Process
Program managers should expect — and prepare for — the following agile curves while managing FACTS. Note the differences between a waterfall approach and an agile approach to the stages of project development.
Visibility will be high throughout an agile process because of the constant feedback cycles — there is not any multi-month periods of developers disappearing to code and wondering what they will return. This also implies a more significant time commitment from program managers. Risk will decrease overtime. Initially, time and money will have to be budgeted without clear deliverables. Of course, over time the iterated product may shift initial expectation, but as the product travels through cycles it will become more concrete — and program managers will know that its current state reflects actual user needs. Finally, value will increase over time. That value will be realized sooner because each new cycle will bring an improved product that is faster at incorporating feedback.
Potential Challenges
An essential element of any proposal such as this will be the recognition of potential weaknesses and the identification of threats. A possible Achilles heel for this plan lies in its reliance on coding talent for execution, and a threat may come from constituencies which may not trust the government with the required real-time data from the citizenry. In this section we will address each of these issues in turn.
Human Capital and Talent — The approach described above will require ready access to a remarkable degree of agile project management, design thinking, coding talent, and overall digital capability. At present, FEMA may not have in its workforce those with the knowledge, skills and abilities — i.e. human capital — to produce field ready updates over a sustained period as would be required for an agile approach.
Should FEMA’s existing human capital come up short in the effort to apply an agile approach, one response could be to hire top talent with agile, digital attributes from the outside. However, as Rohit Bhapkar et al. from McKinsey explain: “Attracting people with these attributes can be difficult. You may have to overpay to create initial critical mass.” Unfortunately, throwing money at new hires can be extremely difficult and potentially disruptive for a federal agency such as FEMA, so a more realistic approach could be through training. In the UK, the Department for Work and Pensions (DWP ; a massive government agency) created a Digital Academy which prepared its existing workforce in “key elements such as user-centric design, agile development, and digital government services.” (Eggers in Delivering on Digital, Kindle Locations 924–925). However, this required a substantial investment in training for full-time employees (FTE) , and while DWP’s effort was successful, it involved a deeper effort than just the formal six-week course; graduates required significant mentoring and additional on the job training before they could truly add value. Furthermore, even if FEMA could successfully grow an organic capability, the agency could find itself hemorrhaging the talent once it’s developed. Experienced agile workers are in high demand, and as P. W. Singer and Alan Friedman remark in Cybersecurity and Cyberwar: What Everyone Needs to Know, “a particular problem for the government is that it often pays for the creation of talent that it then loses to the private sector.” (p. 237). In part, this is a function of compensation — seasoned digital workers can quickly double or even triple their salary in the private sector — but any government bureaucracy will be at a disadvantage culturally in retaining young talent versus high-tech firms in the private sector. As Singer and Friedman wryly observe: “Beyond a preference for cargo shorts and a T-shirt over khakis and a tie, the culture of a high-tech firm will always be more dynamic” (p. 237)
Given the challenges associated with developing human capital and retaining internal talent, we believe FEMA must be prepared to embrace techniques for tapping outside talent in order to foster an agile approach for FACTS. To this end, the concepts outlined by Eggers in Delivering on Digital or by Ismail, Malone, and van Geest in Exponential Organizations could serve FEMA well. In Eggers’ view, engaging with the external tech community is key in order to create public value. Such engagement means tapping borrowed, freelanced, and open-source talent because the most mature digital governmental organizations recognize that “there will always be more tech talent outside government than in.” (Delivering on Digital, Kindle Locations 961–962). Even outside of government, Ismail and his colleagues embrace this idea; for them, two of the five external characteristics that define exponential organizations involve the use of external talent. Specifically, the characteristics of “staff on demand” and “community and crowd” entail leveraging human capabilities beyond the enterprise’s full-time workforce.
According to Ismail and his colleagues: “As a result of both Staff on Demand and Community & Crowd, the core FTEs of an organization become smaller and its flexible workforce larger. As a result, organizations are not only much more agile, they are also better at learning and unlearning due to the diversity and volume of a flexible workforce. Ideas are also able to circulate much faster.” (Exponential Organizations, Kindle Locations 878–880)
Moreover, with regards to attracting a trait-based, virtual community willing and motivated to invest their abilities and time into a project, FACTS will have a distinct advantage. After all, the development of effective capabilities will provide coders and other participants in flood-prone areas with selfish as well as altruistic motivations.
Legal Environment and Privacy — Mark Zuckerberg may believe that privacy is no longer a social norm, but, as the backlash over Edward Snowden’s revelations reveal, many elements of the citizenry see government collection of data on them as an unacceptable invasion of privacy. So, we should anticipate some resistance to the idea that a federal agency will be accessing real-time location data on citizens through sensors in their cars. Because crunching this data is core to the FACTS initiative, the resistance from some quarters may be fierce and include effective legal action that would hinder or block the initiative altogether. Thus, legal challenges and privacy concerns constitute a threat to the FACTS initiative for which FEMA should prepare.
Legal outcomes are uncertain, and countering challenges in court could be both time consuming and resource draining. Thus, should resistance on privacy grounds materialize and take hold, FEMA may not want to dig in for a legal battle or attempt to persuade the public to “trust the feds.” Instead, FEMA should consider how it could shift the FACTS initiative outside the agency. That is, FEMA should be prepared to get out of the business of collecting and analyzing the data, abandon the role of producer for a FACTS product, and instead become the incubator, funding source, and/or market maker for private sector entrepreneurs who can fill the data collection space. As such, FEMA could take a role more akin to that of the Defense Advanced Research Projects Agency (DARPA) which creates funding streams, sets visions, and makes a market for innovators to produce independent of the direct or detailed agency involvement.
Consistent with Lean Startup methods outlined by Eric Reis, such a fundamental shift in strategy while remaining true to the overarching vision would be considered a “pivot.” Such a pivot would jibe well with the build-measure-learn cycle embodied by the agile approach described above (Ries, The Lean Startup, p. 9 & 23, Kindle edition). FEMA could make this happen through the use of contests and prizes. DARPA uses such techniques extensively to draw in outside problem solvers and encourage innovation. Moreover, this serves a dual purpose in that it may address both the privacy issue as well as the human capital challenges previously discussed. After all, this represents yet another way to leverage talent that lies outside the federal workforce.
Essentially, FEMA could become a seed investor or branding authority — “FEMA Certified” — of in-vehicle products that deliver egress routes to potential flood victims. Alternatively, FEMA could subsidize end user participation to improve data collection if consumers are able to opt out. Regardless of the specific manner this pivot might take, the goal of FACTS can be achieved whether the data stream, algorithms, and ultimate product comes from FEMA, a private company, or individual entrepreneur. In fact, this need not be just a pivot to consider in the face of legal challenges; FEMA could simultaneously build an in-house product while fostering competition from the private sector.
Procurement
“Government has always had unique requirements, and the Internet did not magically make them disappear. But for the promise of digital transformation to be realized, these needs must be met in a smarter, faster, and cheaper way.” Eggers in Delivering on Digital.
In order to procure the digital transformation that we desire to implement FACTS, the procurement system must also be transformed. It will not be enough for FEMA to issue a request for proposal (RFP) with the business model the organization might think it needs at the time of issuance.
As Eggers points out, government IT projects are very much like the execution of the Galactic Empire’s Death Star in Star Wars. It was a huge, complex project that was behind schedule and was easy to attack because of a technical “oversight” in the design. It could not have been properly managed. Sound familiar? In order to ensure that the development of this system is agile, procurement must also be nimble and flexible.
In order to ensure FACTS success, FEMA must commit to hacking its procurement system. So what is needed?
While not necessarily a procurement function, agreements must be made for data-sharing with the automakers. We already mentioned incentives would be available for automakers who participate in FACTS as well as the potential for fast tracking regulatory approvals. It remains to be seen if this would be enough to encourage data-sharing, however the value the consumer would obtain from this type of partnership could create further competition among the industry to be innovative and provide vital and potentially lifesaving services to its customers. No PR firm can compete with that value proposition.
How would FEMA analyze interconnected vehicle data once it’s obtained? In the delivery section of this article, we told you that there would be a web portal developed for FEMA staff that could provide real-time updates of conditions. This system would need to be procured, but rather than FEMA staff defining all of those business requirements up front, the agency should encourage vendors to create working prototypes to experiment with using test data — that way, RFP evaluators can see which vendor would actually meet the agency’s needs right off the bat. In addition, vendors could compete based on the initial design concept and be funded to do additional development if the RFP evaluators are interested in the direction they are going. FEMA may also wish to consider diversifying the number of vendors that can participate in this project. So rather than procuring one large IT project that could take a decade to complete, the agency could procure small batches of requirements among several vendors and that way the government is not reliant on the single vendor who created and designed the system.
The automakers would be on the hook for creating enhancements to its navigation systems for consumers, however this is something that the government could consider providing tax incentives to the industry to develop these changes.
Lastly, the customer care center that was mentioned would likely need to be staffed by a vendor. This could be procured by a “traditional” government RFP, but in order to save time and money the agency should consider leveraging other vendors who already have contracts with government to do this type of work.
Cutting through the Silos of Government
“In this world, creating an enterprise system is often less about trying to corral dozens of disparate agencies into using a single platform and more about creating systems of systems built around data exchanges and with a common understanding of how that shared data is defined.” Eggers in Delivering on Digital.
When it comes to regulation, there are often informational and operational silos that limit collaboration among local, state, and federal agencies. The private sector has been successful building intelligence sharing platforms for some agencies and the same concept could be implemented to break the silos of information related to FACTS. We can learn from programs like the Intelligence Community Desktop Environment (ICDTE).
The Department of Homeland Security would be a major influence for the success of FACTS the same way they have been a part of the ICDTE integration within the intelligence community. With DHS buy-in, FEMA could stress the importance of FACTS by promoting how critical it is to share information to improve situational awareness during disaster response.
Eggers describes how the US Government Accountability Office (GAO) found that IT projects in just three departments — Defense, Homeland Security, and Health and Human Services — had spent more than $321 million to duplicate the efforts of other projects within the same departments. There was no communication between agencies as a result of informational silos within government.
The “silos” of government agencies are wasteful and can also hinder effective strategies for the American people. Eggers provides an example of how the State of Indiana was able to use their data to identify issues with infant mortality rates with mothers on Medicaid because they practiced the idea of horizontal government. Eggers states,
“A horizontal model punches holes through agency silos, improving efficiency and reinforcing a culture of openness and sharing. Its digital tools are built on data sharing and uniform standards.”
Eggers argues that horizontal government looks great on paper. While it is often hard to implement this concept, it can happen. An example was seen in 2013 when the FCC hired a new CIO, David Bray. At that time, the FCC had 207 different IT systems for 1,750 civil servants. Every time a new effort was requested by Congress or the administration, they just created a new system. It wasn’t just the number of systems — nearly one for every nine employees — that caught the CIO’s attention. Many of the systems were terribly outdated. Bray found data centers lacking anything remotely resembling modern heating, ventilation, and cooling systems. Much of the software hadn’t been touched since the 1990s. And the worst part for an administrator looking to make big changes: Nearly 80% of his operating budget was allocated to keep all of it running.
In response, Bray put all 207 systems on the chopping block. Mary Ellen Seale, a member of his team, says multiple offices then worked together to decide, “Should we keep this, divest it, modernize it, move to a different version, or completely reengineer it?” They weren’t afraid to make cuts. In six months Bray and his team eliminated 113 with the goal of eliminating the process of the FCC managing its own IT. Today, the FCC IT team only writes code if there isn’t a product available to meet their needs. By 2015, Bray and the FCC were seeing the positive return on their efforts. Bray estimates that the FCC save approximately $ 500,000 on software and $3 million by not building their own infrastructure.
FACTS must recognize, right from the start, that a variety of governmental agencies will be involved. Rather than creating new systems in each area, the key to eliminating silos before they even begin is to focus on common access to existing data that is already created in a system of autonomous vehicles. More importantly, FEMA must avoid the impulse to create new IT systems but instead act as a facilitator to promote the private sector’s seamless integration of data that is accessible to program participants.
Confronting the Cybersecurity Challenge
“Without better cybersecurity and trust in government’s ability to secure data, digital transformation will fall short.” Eggers in Delivering on Digital.
When it comes to networked technology, it is “increasingly clear that perfect cybersecurity is impossible” (Eggers, Chapter 6). Threats are growing in volume, intensity, and sophistication. Strategies to combat these threats must continuously evolve.
For automated vehicle technology, cybersecurity threats at all stages must be identified and mitigated. Developers should prioritize risks and build controls to protect against current and emerging threats. For example, Petit and Shladover (2014) analyzed both autonomous and networked self-driving vehicles and considered the likelihood, feasibility, and impact of a cyberattack on a variety of attack surfaces. They determined that the highest cybersecurity threats to autonomous self-driving cars were to vehicle cameras (creating vehicle “blindness”) and to GPS spoofing/jamming (routing the car to the incorrect location). Networked or “cooperative” automated vehicles, could be injected with fake safety messages and the vehicle’s map database poisoned, both of which impact how the vehicle will react, potentially putting the driver, passengers, and other vehicles in harm’s way. They concluded:
Further, when looking to leverage existing sensor data from private sector data sets, especially data with potential privacy and security considerations, FEMA must make every effort to protect this sensitive data. Measures should be taken to adhere to the three capabilities of proper cybersecurity and the capabilities should be woven throughout the agile process:
Security — “Lock the Doors” — At the system level, the sensitivity of the data being distributed and maintained must be assessed and properly protected. Typically, this would include any data containing personally identifiable information (PII) or protected critical infrastructure information (PCII). At the end user level, every employee should be required to verify his or her identify through dual-factor authentication before accessing the sensor data. Further, all employees should be periodically reminded and trained on cyber hygiene and network administrators should continuously monitor for insider threats.
Vigilance — “Monitor and Detect Anomalies” — FEMA should leverage existing resources, including the National Cybersecurity & Communications Integration Center (NCCIC), the Multi-State Information-Sharing Center (MS-ISAC), and the United States Computer Emergency Readiness Team (US-CERT), to obtain actionable cyber threat intelligence and indicators of compromise (IOCs).
Resilience — “Return and Repair” — When an intrusion does occur, network administrators must detect and quarantine it as soon as possible. It should also continuously test the security of its network (penetration testing) and should consider leveraging the skills of the private sector developers to help test security (war gaming).
Eggers (chapter 6) offers five recommended steps that all organizations should take to protect Internet of Things (IoT) devices. At a minimum, these five steps should be implemented by FEMA and FACTS:
- Define uniform standards for interoperability
- Use purpose-built devices rather than pre-IoT solutions
- Designate responsibilities for participants in the ecosystem
- Establish baseline data
- Provide data governance
In conclusion, It is critical that the government understand the potential implications of any new technology:
The transition to autonomous vehicles, and the use of the sensor technology for emergency management, will bring with it new and emerging challenges. As discussed, even without government participation, self-driving cars will collect the necessary sensor data which can be leveraged for emergency response. Therefore, it is clear that FEMA would certainly be falling short if it did not leverage that data. However, history has shown that technology companies do not necessarily consider the security and privacy implications of emerging technology, and although we propose fast-tracking regulation for agencies that enroll in FACTS, this should not be done at the expense of cybersecurity.
Feedback
Thank you for taking the time to read our proposal to transform emergency management in the future. Clap your hands, tell a friend, or add some remarks if you think any part of this has a chance to help FEMA stay on the leading edge of the wildly disruptive world of automated vehicles and networked sensor technology.
