• United States




What lessons can we learn from Notre Dame to better prepare for cyberattacks?

Apr 16, 20199 mins
Data and Information SecuritySecuritySecurity Infrastructure

The Notre Dame cathedral – one of mankind’s greatest achievements – is not only a monument to Catholicism, but also to the French people who built and maintained this landmark over centuries…and will now rebuild this icon again. As infosec professionals, we can learn many lessons from this event and use them to build better architectures for our customers.

Like many of you, I was glued to news sites and social media as the fire that engulfed the famous French cathedral Notre Dame took down the spire and roof, and severely damaged most of it. It will need to be rebuilt, which President Emmanuel Macron has committed to do.

Construction began on this cathedral in 1160, and was largely complete by 1260. It has been upgraded multiple times since then and has silently stood witness to many crucial events of human history, including the Renaissance, French Revolution, Paris Commune and World War II. The spire that collapsed was from the 19th century, as are its iconic gargoyles.

Notre Dame is a symbol of continual evolution, long-term planning and the continued growth of the nation of France and its people. It has seen the change from monarchy to democracy, and the changes in the Catholic Church that has used it as a place of worship for over seven centuries. Even though the Eiffel Tower dwarfs it in size, it was still the most visited site in France by a large margin. What happened today will be remembered centuries into the future, when the generations that succeed us visit and worship there, like the events of the French Revolution or World War II.

We can learn many lessons from today and apply them to the companies we work in. Most companies, like Notre Dame, are a combination of different elements from different times making a whole. Sometimes, like Notre Dame, they fit together very well. Many other times, they don’t. There are obvious lessons to learn here.

Contain to learn and prevent collateral damage

On February 23, 1991, the City of Philadelphia was changed forever. One Meridian Plaza, one of the giant office towers that abutted City Hall, was set alight because contractors left linseed oil rags in a pile, which combusted and caught fire. Three firefighters died fighting this fire. Eight floors of the building were destroyed. The building, because it sat directly above a major rail and subway transport interchange, could not have more invasive firefighting techniques, such as a plane dropping water on it, because of the risk of building collapse and collateral damage to not only other buildings, but major transportation hubs that took tens of thousands of workers in and out of Philadelphia’s central business district, Center City and City Hall.

This fire is noteworthy because of the carefulness used to fight the fire due to its proximity to the Suburban Station and Broad Street Line transport hubs. Because of it, significant evidence was preserved that allowed investigators to do a full root cause analysis, which showed that the failure of fire safety systems and building design both contributed to this catastrophic event. The findings from this fire not only provided instructions on how to improve building safety, they also provided a case study on how to safely deconstruct a building in a very risky area. The demolition took place over several years, one story at a time, and ended in 1999. Fire science was greatly advanced because of One Meridian Plaza. Those three Philadelphia Fire Department firefighters did not die in vain.

Notre Dame had the same issue. While I understand the urgency of some people to put out the fire the quickest way possible, sometimes you have to understand that you have to be careful and judicious in how you do so so that you do not destroy evidence of what happened and learn from the event, and take out other historical landmarks in the process.

Such as it is with ransomware and malware attacks. Many organizations who are attacked by them just format and reinstall PCs. They don’t study what happened, how it happened, or document their findings. They just want to continue on with their business.

When an attack happens, you have to contain it, and you have to understand how it got in in the first place. Destroying evidence or rebuilding everything without analyzing how the attack works will provide one thing, which is certainty that the attack will happen again using a similar vector. Even though it may be initially unappealing, you have to study the infected computing equipment in detail and understand the attack vectors. What you will find during your analysis is that there will be elements of the business IT architecture and processes that were established years ago, maybe even from a business unit that was acquired from another company, that have been incorporated into yours and present significant risk.

Respect the history

Oftentimes one of the comments that comes up when these issues arise is how the previous people who established these systems and have long since left the company made bad decisions. We need to stop when this happens. We’re all guilty of this. We don’t understand the context in which these decisions were made, and we most likely never will. When we come upon these risks, we need to respect the people who made them, and work with the business to craft solutions that meet their needs while preserving their critical processes.

When fire investigators, engineers and scientists pore over the damaged Notre Dame when developing their restoration plans, they will see how masons from the 19th century may have done work that did not complement work from the 12th or 18th century. In this case, the people who have made these decisions are long since gone. They need to document what their predecessors did, what they know, and discuss how they will preserve the legacy of all historical changes made while preserving this landmark.

Likewise, we need to keep this in mind when we develop our plans. We need to document what we know our predecessors in the business developed, how we will work with the customer to bring them to a better state, and how to best preserve the past while moving forward to that state.

Understand the past

The people who developed Notre Dame did not have AutoCAD. They developed an architectural achievement without computers at the end of the Dark Ages in Europe. They did this without an effective supply chain, engines, modern tools, and without laborers that understood math and science the way a trade school teaches it today. They had to build the entire value chain to build this cathedral. When you look at the construction of Notre Dame in this context, you understand what a monumental human achievement this was and is given the constraints that the architects had to work under.

Technology moves very fast. When we look at the underpinnings of the technical architecture behind any significantly large business, we see processes and technologies that may seem primitive and ancient to us but were significant technical achievements in the era they were developed. Many of the minicomputer and mainframe programs used today written in COBOL or RPG, or the SCADA or PLC systems written in obscure BASIC dialects or Ladder Logic, or the SCADA front ends written in Visual Basic pushed the envelope of what could be accomplished. Even Microsoft Access, which many people consider an abomination, was critical to the development of modern enterprise systems because it gave businesspeople the ability to quickly develop applications to meet their needs.

We need to look at this technology and understand to the best of their abilities why they did what they did before we go rip everything out and put something shiny, new, and possibly costing 8 figures in its place. We owe it to ourselves to understand the constraints and use them to ask further questions as to why they occurred and get a better operating picture. What we will find at the end is a better way that respects the business and what people did to keep it viable. We can’t drop the hammer, destroy the past, and expect it to end well for the business. The graveyards of failed businesses are littered with companies who thought they could do this and failed.

Rebuild for the future

When Notre Dame is rebuilt, it will more than likely will be done so to 21st century building standards, some of which will be invented during and as a direct result of the reconstruction process and be respectful of the work of centuries past. Work that is done here most likely will be used as guidance to restore other historical buildings across the world to modern standards. Fire science and engineering will be advanced greatly through France’s restoration process of a national landmark.

When an attack happens on our networks, we need to look at it as an opportunity to advance it to modern standards, and to leverage what we know to do so. We need to be respectful of our customers, as every business unit has history, and in many cases, it predates the company, sometimes by centuries. We need to understand why these events occurred, identify the risk factors, plan to mitigate them, and present solution architectures respectful of the past value chain constraints and our customers.

Notre Dame was and is a landmark built over centuries. Like France, it has changed significantly since the 12th century when it was conceived. Its genesis caused an entire value chain to be developed around what it took to build it. The fire was significant and destroyed large parts of a landmark that symbolized both the resilience and evolution of the people of France. However, it will be rebuilt, and done so while respecting France’s past and future.

Cyberattacks on our organizations need to follow the same pattern as Notre Dame’s restoration. We need to be respectful of how businesses and solutions were developed, understand why attacks happened, build ways to address them and develop resilience, and not take a heavy hammer to contain risk or develop new solutions that don’t meet our customers’ needs.


Mitchell Parker, CISSP, is the Executive Director, Information Security and Compliance, at Indiana University Health in Indianapolis. Mitch is currently working on redeveloping the Information Security program at IU Health, and regularly works with multiple non-technology stakeholders to improve it. He also speaks regularly at multiple conferences and workshops, including HIMSS, IEEE TechIgnite, and Internet of Medical Things.

Mitch has a Bachelor's degree in Computer Science from Bloomsburg University, a MS in Information Technology Leadership from LaSalle University, and his MBA from Temple University.

The opinions expressed in this blog are those of Mitchell Parker and do not necessarily represent those of IDG Communications, Inc., its parent, subsidiary or affiliated companies.