When Ørsted set out to automate its network operations, speed wasn’t the primary goal. The energy company first needed to get its network data under control and establish processes that would consistently meet its security and compliance requirements.
João Soares, lead IT security consultant at Ørsted in Copenhagen, joined the company nearly five years ago to focus full time on network automation after working in network engineering and network security. When he joined the Danish energy company, there was little network automation in place, and one of his first tasks was assessing the company’s network and security environment. His initial assessment raised the question: Where was Ørsted’s network data?
He found that Ørsted network information was distributed across multiple platforms, including systems without APIs, systems with APIs that weren’t well-suited for automation, and even Excel spreadsheets. Engineers needed to move regularly between systems, copying information and updating spreadsheets as part of their processes.
“Many people think that automation is just about time to market, how fast you can deploy things, how fast you can configure,” Soares says. “The only way you can 100% ensure that it’s always compliant, regardless of who does the task, who’s involved, is if the process is automated and the automation forces you to be compliant.”
Building a foundation for network automation
Ørsted evaluated commercial and open-source alternatives before selecting Nautobot, the open-source network automation platform developed by Network to Code. (Read more about companies that have tackled network automation: ‘Too many devices to copy-paste configs. Automate or die’)
Soares says Nautobot provided the granular permission controls and validation capabilities Ørsted needed, and its focus on automation also distinguished it from other offerings the company considered. “We were looking for something more of an automation platform with a real automation roadmap,” Soares says.
Ørsted customized Nautobot for its environment by developing custom validators to control how new data enters the platform. Soares says they also built Nautobot applications to model concepts specific to Ørsted’s network architecture, including network zones and their associated policies. This allows Ørsted to connect network information such as IP addresses with the zones and policies governing those resources.
For Soares, getting the data right is a prerequisite for automation. Soares says before Ørsted could build network automation, it needed a centralized platform that could provide access to network data while supporting granular controls over who could access it and change it.
“It’s all about the data, starting with a solid foundation—a flexible data platform where you can build your own validation,” he says. “The first question was, ‘Where is our data? And how can we make it accessible for automation?’”
Taking on a firewall process
One process Ørsted initially targeted for automation was firewall rule management. In the past, an internal customer submitted a firewall request through ServiceNow, and a network security engineer reviewed the request, checking IP addresses, fully qualified domain names, and directory groups. Depending on the type, the request was then sent to the change advisory board (CAB) for approval. Once validation and approvals were complete, another team implemented the rule on the firewall.
The process involved many teams, and if a problem was discovered at any stage, the request would be sent back to the customer for revisions. Then the review process began again, Soares explains. “This sort of loop could happen across days, weeks,” Soares says. “All this process was just very tedious.”
The teams involved were already at capacity, and streamlining the existing process could only go so far. Engineers would still need to validate incoming requests, and many of those checks could be performed automatically. “A lot of the validations we were doing was something that a machine could do much better than us,” he says.
Embedding compliance into automation
Network automation wasn’t primarily about accelerating deployment for Ørsted.
Ørsted wanted the same tasks performed consistently using valid data. As an energy company that must comply with regulations and undergo audits, it also needed processes that could demonstrate that network changes followed required controls.
Ørsted’s network is divided into zones, each of which can have a different security profile. Working with its security organization, the automation team identified lower-risk traffic flows that could be handled with peer review rather than requiring CAB approval. Those preapproved requests account for roughly 60 to 70% of incoming requests, Soares says. Other requests must still go to CAB. “If it doesn’t fit into this low-risk, pre-approved request type, then we need to ensure it goes to CAB. It cannot be optional,” he says.
For Ørsted, automation also provides traceability. Logs and metadata connect firewall rules to the change requests that created them and identify the customer and team associated with that request. Information that previously depended on an engineer remembering to include it is now part of the automation process.
Firewall requests drop from weeks to minutes
The automated process has reduced the time required to complete firewall requests. A pre-approved request can be deployed in about 10 minutes, including the time for a customer to submit the request and have a teammate review it. Requests requiring CAB approval can still take a few days because they must wait for human review.
Automation has also changed how Ørsted’s network and security engineers spend their time. Engineers no longer maintain most customer-facing firewall rules. Some have moved into developing the automation platform, while others support end users of the system. Engineers also continue to maintain and patch firewall platforms and address security vulnerabilities.
And at Ørsted, humans remain part of the process because peer review is enforced for customer-created rules, CAB continues to review changes requiring its approval, and developers maintain the automation and its integrations. “This has just offloaded the firewall rule maintenance part of it,” Soares says.
Successful automation requires more than technology
Ørsted needed network engineers, security teams, developers, product owners, and internal customers to agree on how the automated process should work. Soares says the different perspectives represented a cultural challenge in their automation efforts.
“The technical part was solid,” he says. “It was hard to get the message across that automation is actually safe to run, and just because something is automated doesn’t mean that things are going to be deployed without any control.”
The company conducted a design sprint involving internal customers, network security engineers, IT security colleagues, and product owners to examine the firewall process and determine what could work better.
For enterprises pursuing automation projects, Soares says to start with a strong data foundation. He also notes there is a difference between automating individual tasks and building an automation platform that internal customers can use directly. This requires more validation and guardrails because managing firewall rules moves closer to those customers, he says. Ørsted could have focused only on automating firewall configuration, he explains, but the team automated validation and its integration with the CAB process.
Soares recommends treating network automation as a product rather than a collection of individual scripts. He says to version the automation, maintain change logs, and provide support for the people who use it. “You need to start small, but think big,” Soares says. “Treat it like a real product.”