Case Study: Building an Enterprise Security Program

Author: Katie Teitler-Santullo
Date Published: 30 June 2020

Mercury NZ, a US$2 billion renewable energy generation and retail company, has the most NZ Stock Exchange shareholders of any New Zealand company, serving more than 373,000 residential, commercial, industrial and spot customers across New Zealand. The company employs 775 full-time employees (FTEs) plus an additional approximately 700 contractors. Founded in 1999, Mercury NZ has grown organically over the last 21 years and has transitioned over time to adopt increased use of connected technologies. As an energy producer and retailer, Mercury NZ manages operational technology (OT) and information technology (IT) infrastructures and networks.

As the business has evolved and new connected technologies have been deployed, structured security at Mercury NZ, as with many growing organizations, was introduced post-operationalization of many systems, delivering services to both internal and external customers and other stakeholders.

The Challenge

Mercury NZ is an innovative technology-driven business. The business realized that to be able to take full advantage of technology, it must optimize technology-related business risk and, in 2018, began the journey to mature its security management capabilities.

Like many similar organizations, security activities were decentralized and dotted across the organization and lacked formal rigor and formal capability maturity assurance processes. Anecdotally, capability maturity was relatively low, and the business was not optimizing the value of security controls through new business technology solutions. New technologies were often implemented at pace but without the necessary formal security rigor. Therefore, Mercury NZ took the initiative to centralize security management and formalize security rigor around its technology innovations and general security operations to uplift security capability maturity across the organization.

The Mercury NZ executive team realized that the establishment of an effective enterprise security management function was fundamental to the business’s ability to maintain the trust and confidence of its stakeholders—both internal and external.

The Solution

By June 2018, Gabriel T. Akindeju, a seasoned security industry professional, joined the employ of Mercury NZ as its first enterprise security manager.1 Akindeju’s charge was to annex, leverage and reorient various security activities within the business and build a strategic program that would enhance protection of the organization’s infrastructure and data and instill a security culture. This had to be accomplished despite the challenges of a highly distributed workforce (corporate office workers, field workers and contractors), two distinct business units (generation and retail), separate technology environments and limited history of security awareness.

Akindeju instantly realized that building a security and risk program that would suit the company’s needs required more than a single-person effort. For the program to achieve success, he would need to engage company leadership and enlist organizationwide champions.

Listen, Learn, Educate, Recommend

On his first day at Mercury NZ, Akindeju reached out to colleagues to schedule coffee sessions and informal meetings. Understanding that executives’ time is valuable, Akindeju stuck to a strict policy of scheduling no more than 15–30 minutes with each individual, and the agenda for each meeting was not security—it was to meet people, introduce himself, and listen to business leaders’ goals and objectives for their area of responsibility.

“Understanding what is important to people, how they work, how their teams work, what their priorities are—these are factors that need to be built into a security and risk program. Technology had already been brought in to enable the business—to make things work better, to be more efficient—so security could not stand in the way of that progress. I knew I needed to enable productivity but do so in a secure way and in a way that would instill confidence,” Akindeju said.

Though the purist security-centric approach to some of Mercury’s technology concerns might have been to make major adjustments right away, Akindeju decided that forming relationships and recruiting business partners would serve the company—and his eventual team—better in the long term. He understood that the business’s primary responsibilities were to customers and other stakeholders and that any security deliverables must support the company’s purpose “to inspire New Zealanders to enjoy energy in more wonderful ways.”2

Akindeju learned that Mercury’s employees were friendly and willing to help. This was a positive attribute for company culture and workplace satisfaction, but as a security practitioner, Akindeju knew that these inclinations also created a vulnerability, namely, social engineering. Considering that social engineering (phishing and stolen credentials, in particular) is often the initial vector in a cyberattack, Akindeju decided that the first official security activity would be to scope the extent of the problem.

Akindeju hired external consultants to conduct penetration tests focused specifically on socially engineering Mercury’s employees. Immediately following, when the exercise was fresh in people’s minds, Akindeju presented the findings to executives and used the findings to demonstrate what had happened and explain why and how (in a real-life situation) particular employee behaviors put the business at increased risk for a cyber incident. “It was important,” Akindeju said, “to bring home the message that the social engineering threat is real, that it is not something we only see on TV or movies; it is something that can happen here, and it can negatively impact our business.”

 

After he had fully explained the business risk, Akindeju worked with the company’s People and Performance (i.e., human resources [HR]) team and recommended new policies and practices the organization could use to reduce the likelihood of a successful social engineering attack. Some of the recommendations included:

  • Implementation of a staff identification (ID) and physical access policy
  • A security awareness training program to include theater-style presentations, video skits, guidance on how to comply with the policy and instructions for what to do if noncompliance was observed
  • New systems access processes to enforce technical system controls

By establishing a direct link between action and risk, Akindeju was able to gain support and approval for his program and affect a positive security outcome for the security program.

Simplicity and Clarity

His next action item was to develop a more robust security and risk management plan that he could present to Mercury’s leadership team. While the concept of “robust” implies “exhaustive,” Akindeju committed himself to creating a one-page plan that was easy for nonsecurity people to understand. “If there is one thing I have learned over the course of my career,” he said, “it is that if you make things too complex, people will not be able to follow. If they cannot follow, they will not buy in to your ideas.” Because his responsibility was to gain support for a new program, he needed to be clear, concise and straightforward.

To ensure simplicity for a complex problem, Akindeju drew on established industry frameworks including COBIT®, the International Organization for Standardization (ISO)/International Electrotechnical Commission (IEC) standard ISO/IEC 27001-2/5 and the International Society for Automation (ISA) standard ISA/IEC 62443 to map the current state and the potential path to the desired target state. Once he could see the company’s security posture laid out on paper, it was easier to identify areas of greatest concern. For instance, Akindeju observed that the rate of change in the technology environment at Mercury was high, but solutions were not always formally assessed for security. Also, although anecdotal practices suggested some controls were put in place, they were not optimized for value.

Fortunately, Akindeju also recognized that this was a learned behavior, not malicious or stubborn behavior. Employees wanted to deliver technology to improve internal and external operations, but they had never received effective training on how to include security or compliance in their processes. Thus, Akindeju began speaking with architects about how to properly design security and avoid compliance issues. He again relied on COBIT, ISO 27001-2/5 and ISA/IEC 62443 to map risk, demonstrate gaps and explain the consequences of risky decisions to his colleagues, and he provided actionable recommendations they could employ going forward (figure 1).

Education became Akindeju’s tool for influence and he found Mercury employees willing to learn. He focused on the value of technology to the organization—something that was already established when he joined the company—and explained how a malware infection, for instance, could render tools, systems and data unavailable. Without access to or availability of those assets, those tools’ and systems’ value would be significantly diminished and could negate the “Energy Freedom” mission of the company. As a mission-driven organization, the message of deprecated value resonated.

Recruit, Train, Execute

An integral part of Akindeju’s plan was the tried and true method of identifying and recruiting security champions from different functional units within the company. As a new security practice, he knew he needed support. He focused on finding individuals who influenced the way their departments functioned. These did not have to be people with management titles, but they had to be leaders among peers. Because he did not want security to be perceived as a hammer, Akindeju decided to ask employees for nominations for his task force, the Security Chapter. In parallel, he wrote his own private list of individuals he thought might make good champions; not so coincidentally, the nominations and Akindeju’s list overlapped.

Though the goal of the exercise was to identify potential champions, Akindeju had grander plans. With the support of upper management, he organized three days of security fundamentals training for all technology employees and provided an extra two days for the individuals nominated by peers. The latter group, totaling 25 employees from marketing, IT, service management and more, sat for a certification exam, received certificates and became an extended security team of sorts that helped push the security message throughout the organization (figure 2). This team helped ensure that security was part of the conversation for new technology and process deployments across the entire business.

As Akindeju did not yet have a fully-fledged security team, his workload increased significantly. He developed and presented a business case for an elastic co-sourcing arrangement that would allow him to hire external security consultants who could help drive secure-by-design principles, review new and existing deployments, handle exemptions based on risk, identify and remediate security gaps (when possible) with existing tools, and ensure that delivery processes met the principles of the security organization. Further, Akindeju plugged into existing technology governance functions and also established enterprise-level technology risk and security governance over technology procurement to avoid shadow IT and insecure implementation, and for healthy discussions on return on investment (ROI) on security investments.

The Benefits

Once Akindeju established and started executing on his two-part plan, the organization was better positioned to identify security gaps in processes and system controls. Employees grew increasingly aware of the importance of security in their ability to deliver on-time, valuable services and products, both internally and externally. Awareness drove secure execution, which, in turn, resulted in improved confidentiality, integrity and availability of systems and data.

By recruiting security champions who were already recognized leaders and influencers within the company, Akindeju created a support system that collectively spread the message of the importance of security.

The Results

While not leading with a “security first” message was more time-consuming, the approach adopted by Akindeju meant that he was better suited to put security in context of the organization’s needs and, as a result, was able to gain support and buy-in for the security and risk management programs. This backing from the top smoothed a transition to a security-aware culture.

More tangibly, as Akindeju’s workload increased, the elastic co-sourcing arrangement with external experts allowed him to demonstrate the need for full-time security staff. After a period of time, he submitted a request for internal headcount; he now has a team of four permanent FTEs and up to six contractors. Using a capability map he developed, he is planning to hire three additional FTEs. Recently, Akindeju deployed a SOC model and monitoring platform that is jointly maintained by his internal team and an external security co-sourcing partner.

AWARENESS DROVE SECURE EXECUTION, WHICH, IN TURN, RESULTED IN IMPROVED CONFIDENTIALITY, INTEGRITY AND AVAILABILITY OF SYSTEMS AND DATA.

In a short period of time, Akindeju was able to institute an end-to-end security culture. His success was based on his willingness to learn the business, to learn from colleagues and to educate teammates who would eventually help him with his mission. Akindeju was able to leverage the innovative, technology-driven culture already in place to help the company become a more secure and compliant technology-forward innovator (figure 3).

Akindeju is using the COBIT maturity benchmark to work through governance and reporting to ensure that his team can objectively measure progress against goals. When he started his journey at Mercury, Akindeju says the company did not have a formalized security maturity assessment framework in place. This has now changed and, working with an external firm, Mercury has set an overall maturity level 4 as its target operating state and is well on its way to achieving that objective. (figure 4).

Akindeju notes marked improvement in service management, perimeter security, overall engagement and operations. These positive results have been presented to executives and the board, which is helping him clinch funding commitments that allow the security and risk team to, in Akindeju’s words, “be more proactive and introduce better processes to identify vulnerabilities, prioritize remediation, and become more strategic in meeting the security needs of the business.”

Author’s Note

Akindeju noted that he could not have achieved any success without the unflinching support of Mercury’s senior leadership team. He acknowledges Tim Aynsley, head of information and communications technology (ICT), Kevin Angland, general manager retail and digital, Graeme Hill, infrastructure asset manager, and others.

Endnotes

1 Technology risk management was brought into Akindeju’s remit in 2019 to drive enterprisewide technology risk management activities.
2 Mercury, Investor Centre, https://www.mercury.co.nz/investors

Katie Teitler

Is a senior analyst at TAG Cyber, where she collaborates with security product companies on market messaging, positioning and strategy. In previous roles, she has managed, written and published content for two research firms, a cybersecurity events company and a security software vendor. Teitler is a co-author of Zero Trust Security for Dummies.