Closing Risk Appetite Loopholes to Shore Up Security

Managing risk is daunting in a threat environment that is subject to fast-paced change and novel attack scenarios. Enterprises take great pains to assess how much risk they can afford to bear. Setting the bar too high can interfere with core operations and threaten the bottom line, but setting it too low can invite an intrusion that could quickly morph into a cybersecurity disaster.

Suppose an organization believes its risk appetite is set just right. What happens if weaknesses in its monitoring and detection capabilities cloud its visibility so severely that it has no idea how much risk it is truly absorbing? Even a carefully determined risk appetite cannot provide meaningful guardrails if it is out of sync with reality.

This is what happened to a large Japan-based telecommunications company. The security operations center (SOC) was receiving some unwelcome surprises: Sophisticated white hat attacks that targeted the system escaped detection more than once. Eventually, external penetration testing and other red team activities traced many of the problems to vulnerabilities in unmonitored applications that were not included in the enterprise’s asset inventories.

The vulnerability detection misses were adding up, and the number of entry points for an attacker to drop malware into the system was unknown. A serious exploit could have resulted in the theft of intellectual property, reputational damage, loss of customer trust, legal actions, and severe financial consequences. The need for a risk appetite reassessment was painfullyclear.

Namrata Barpanda has more than 10 years of experience in information security engineering, including three years with the aforementioned telecom company. While there, she applied the skills and knowledge acquired through her Certified Information Security Manager^® (CISM^®) training to help reassess the enterprise risk appetite, bolster its detection capabilities, and prioritize mitigation of the security gaps.¹ She was initially employed as a cybersecurity engineer with the SOC, where she developed a specialty in detection engineering. After a year, she advanced to a leadership role, overseeing the work of nine other engineers for the next two years.

Monitoring in the Dark

The security problems that ultimately led to the reassessment did not appear all at once. In fact, many did not appear at all. Often, it was only when something went wrong in the system that the SOC realized there had been a detection miss.

The organization’s security operation involved multiple C-level executives, departments, and teams (figure 1).

The SOC monitored security alerts on a 24/7 basis using a handful of assets, but it had no asset discovery tool capable of detecting whether a new hosted application came online or if an untested application was onboarded to the production environment. The SOC staff knew there were many gaping loopholes. Because they did not have visibility into all the assets the enterprise owned, an unknown number were not being monitored. They saw evidence of system glitches and intrusion attempts that were detected only after a failure occurred. They knew that vendor products were, in some cases, outdated and unpatched.

For example, a third-party product the company was using was not patched to the prior major version (N-1). Instead, a much older version (N-3 or N-4) was in use. The company needed vendor support to upgrade the software, and the security team needed to make sure the upgraded version was stable. It had to be tested to ensure that it worked with the other applications in use and would not break the system. Many security measures and detection capabilities needed to be in place before the vulnerabilities could be safely and effectively patched.

Under ideal circumstances, developers would test applications in a carefully controlled lab setting before releasing them to production, but due to time constraints, they occasionally onboarded software without even building a lab environment. In those cases, any testing that was done occurred in the real world, where cyberintruders were eagerly scanning their surroundings for low-hanging fruit.

Sometimes, the developers built a lab environment for software testing but failed to implement proper security controls—for example, changing default settings to unique user ID and password combinations. When that critical step was overlooked, anyone could log into the system easily, often with credentials as obvious as admin/admin.

That was not a concern when the enterprise’s original risk assessment was conducted and risk factors identified in the lab environment were rated as minimal. The landscape changed, though. The risk scoring used in the first assessment no longer matched reality. Having gained access to the lab, an intruder could move laterally from the lab environment to the production environment.

That is exactly what external pen testers did, without the SOC’s knowledge. The red team activities were carried out by an external vendor engaged by the CISO. The internal team could see evidence of unauthorized access but did not know who was attacking the system. They realized the company’s detection was inadequate, and that the lack of comprehensive multifactor authentication (MFA) and privileged access management (PAM) policies was placing the enterprise at serious risk.

To address the issue, a detection engineering team was formedtobuildmore robust detection technology for the SOC. Barpanda led that effort. During the buildout phase, the team tested its new system by mimicking attacks—a process known as purple teaming—to gauge how well the system would work in real time.

Shocking Revelations

Still, the security and risk challenges mounted, and management was increasing their scrutiny. During weekly meetings, executives had many questions for the SOC team:

• How many alerts were they receiving?
• What was the true number of negatives?
• How many threats were missed?
• What were the new advanced persistent threats (APTs)?
• Were any visible threat actors targeting the company?
• How many devices were scanned?
• How many vulnerabilities were found?

The engineers gave their updates, acknowledging issues such as the lack of lab testing, which was already known, and the need to consistently employ good practices such as zero trust access management, the principle of least privilege, and MFA. During that time, unbeknownst to the SOC, the third-party red teams were attacking the system. This continued for approximately two months.

At one fateful meeting, the external red team presented its findings in a 23-page document. “We had no idea what was going on,” Barpanda recalled. “Then we saw the report: ‘This was missed, this was missed, this was missed.’ That was the most disastrous meeting in my life.”

The business stakes could not have been higher. “Imagine that an attacker had discovered any of the vulnerabilities the external red team found,” Barpanda said. “The lack of access management in the lab could have allowed an attacker to move laterally into the production environment and then into the entire system. They could have dropped in malware or stolen data or intellectual property. The company could have faced lawsuits and financial damages—loss of reputation and customertrust.”

It was imperative to address the problem with a new approach. After the red team exercise concluded, the enterprise decided to restructure its security operations to function not only from the top down, but also from the bottom up. Executives would ask the engineers what approach they recommended before issuing mandates for actions to take. Further, the executives more clearly defined the scope of work between the SOC and the new detection engineering team. Also, a greater emphasis was placed on collaboration with the enterprise’s GRC and data governance teams.

Reassessment Without Disruption

The company’s risk guidelines also needed to be completely revamped. For starters, the newly reorganized security team needed visibility into all the assets the enterprise owned. To assist with that effort, the company licensed Shodan, a search engine for internet-connected devices.²

Shodan allows users to search for various types of servers connected to the internet. It scans Internet of Things (IoT) devices and collects data on:

• Web servers
• File Transfer Protocol (FTP) servers
• Secure Socket Shell (SSH) servers
• Telnet servers
• Simple Network Management Protocol (SNMP) servers
• Internet Message Access Protocol (IMAP) servers
• Simple Mail Transfer Protocol (SMTP) servers
• Session Initiation Protocol (SIP) servers
• Real-Time Streaming Protocol (RTSP) servers

Shodan can monitor internet-facing devices on enterprise networks, track the use of smart devices, provide information on exposure to cyberrisk, and track ransomware on devices, among other capabilities.

The company also needed to adopt a set of standards that would align with its business goals. It chose the US National Institute of Standards and Technology (NIST) Risk Management Framework (RMF) and its associated rules, which did not exist when the first risk appetite assessment was conducted years earlier.³

The CISO met twice weekly with participants from the risk, security assurance, detection engineering, external auditing, and other departments who were responsible for examining changes in the proposed risk reassessment from their perspective. It was critical to prioritize each risk factor. A high technical risk might be a vulnerability that could result in a zero-day attack. A high business risk might be a vulnerability that would be costly to remediate.

“Risk was changing and evolving every day as tactics, techniques, and procedures changed,” Barpanda said. “We had to change our risk posture, but everything couldn’t be high risk any more than everything could be low risk. The risk had to be mapped to the business problems. The new assessment had to be up-to-date. We didn’t want to create a document that would soon grow stale on a bookshelf.”

It was also necessary to determine how long the organization could wait to address each risk: one month? Two? Six? The team decided that all high-risk issues needed to be resolved within six months. Remediation was complicated by the use of third-party products because vendor cooperation was necessary. In one case, a vendor took eight months to implement patches to its software in all of the company’s servers.

Maintaining enterprise operations during the reassessment and remediation period was a high priority. While avoiding disruption, the technical team had to confirm that all applications in use were being adequately monitored. It established strong identity access management (IAM) and PAM policies.

It also had to enhance security controls, such as activating protections that were not enabled, and fix problems with the system’s firewall, such as adding rules that were missing in the lockdown program.

Among the team’s recommendations to executives was to increase the budget to acquire additional scanning tools, especially for comprehensive vulnerability assessment. Increased allocations were needed both for security and to develop a proper incident response plan. Additional funding was also needed to ensure that risk was correctly mapped to the enterprise’s business strategies.

The team recommended that managers enroll in technical training, such as CISM and Certified Information Systems Auditor^® (CISA^®), and that cybersecurity awareness training be conducted across the enterprise.⁴

Further, a third-party security audit was recommended to evaluate the enterprise’s compliance with regulatory requirements, the appropriateness of the encryption methods it was using, and the effectiveness of its newly adopted governance framework.

Healthy Suspicion

While the risk appetite reassessment and remediation efforts were ongoing, the enterprise’s newly formed detection team was observing constant threats.

The detection team built the detection logic based on the attack signature to determine whether anyone was trying to mount an exploit. In 2021, red teaming activity found that the Log4Shell zero-day vulnerability appeared in the Java Log4j tool the company was using.⁵ “That’s how we found out we were missing a lot,” Barpanda said. “Then all the security engineers adopted the mindset, ‘Consider everything suspicious.’ Even if someone just forgot their password, their unsuccessful login attempts were viewed as a possible brute force attack.”

“That was the appropriate mindset for security engineers,” said Barpanda. Previously, the SOC team focused on production only, but after the red team exercise, it realized the importance of giving equal priority to lab testing. The team implemented Axonius for asset management.⁶ They used the new tool to create an inventory of all assets, including devices and software, and to aid in the identification of vulnerabilities, security coverage gaps, and other risk.

They also used it to map the company’s assets for monitoring, which qualified it as the enterprise’s best security investment, from Barpanda’s perspective. Many of the lab assets were missed before Axonious was implemented. For example, a sensor-monitoring tool was identified that previously was not on the SOC’s radar. Since the security team did not know it belonged to the company, it was never monitored. That particular asset had default credentials and was not patched.

There were other obstacles to overcome as the reassessment and remediation effort got underway. Despite the commitment to collaboration, executives and engineers frequently disagreed. There were often big gaps between executive expectations regarding the time and cost required to remediate a security issue and the reality the engineers had to wrestle with to get the job done.

Engineers would typically be met with executive resistance to making new security investments until an incident occurred. An ongoing security challenge was the misalignment between the interests of company stakeholders and the interests of third-party vendors providing products or services.

Effective Risk Mapping

Having the right tools is essential to effective risk reassessment and remediation. Open-source products might be useful for some purposes, but they are not right for everything, Barpanda pointed out. For example, Metasploit—an open-source penetration testing framework that security personnel use to test and exploit system vulnerabilities—is a great tool for security engineers, but it can pose significant risk if not used responsibly.

Because Metasploit’s code is open and accessible, anyone with the technical know-how can modify and rerelease it without attribution or license compliance, potentially leading to intellectual property theft, with the malicious actor claiming ownership of the original code or repackaging it with harmful modifications.

Another example is Shodan. Although it can help security engineers identify vulnerabilities, misuse of Shodan or failure to comply with licensing terms can heighten security risk. By indexing systems that are not properly secured, Shodan can increase the attack surface for cybercriminals and make it easier for them to steal sensitive data from exposed devices and systems.

Barpanda relied heavily on the skills she gained from her professional training to carry out her responsibilities in the comprehensive analysis performed by the risk reassessment and remediation team. She also leveraged the knowledge gained while studying for the CISM exam, which focuses on risk assessment, governance, and incident response—all integral to the overall effort.

Understanding how to align risk prioritization with industry standards was one of the most valuable items in Barpanda’s CISM toolbox. It was important to apply the correct risk mapping to the red team’s findings, she explained. The mapping strategy the team adopted was to establish high, medium, and low risk categories. They needed to know their assets, identify what was exposed, evaluate their defense procedures, and prepare to respond appropriately in a timely fashion.

In particular, Barpanda valued the MITRE techniques she had learned, which were invaluable in mapping risk within the correct framework.⁷ MITRE ATT&CK charts cybercriminal tactics, techniques, and procedures from the initial information-gathering stage to an attack launch. It allows users to test their defenses in simulations in order to better detect, prevent, and mitigate cyberthreats. Ultimately, it helps them develop stronger policies, controls, and incident response plans.⁸

“A lot of people knew how to solve the technical problems, but they didn’t know how to map them to the business problem to determine their priorities,” she pointed out. “The CISM certification helped me to align risk with business goals.”

In the case of the telecom company, for instance, it was critically important to ensure high network availability and customer trust. “Telcos prioritize 99.99% uptime as a key business goal to maintain customer satisfaction, comply with SLAs, and avoid financial losses,” Barpanda noted.

Aligning the enterprise’s risk to that goal meant recognizing three essential priorities:

1. Implement real-time threat monitoring and incident response to detect and mitigate cyberthreats before they impact services.
2. Conduct regular risk assessments to identify vulnerabilities in network infrastructure.
3. Align cybersecurity investments with business priorities, ensuring that critical network infrastructure is protected first to prevent major outages.

More Clarity, Less Risk

The telecom company executives were pleased with the outcomes that resulted from the risk appetite reassessment and security remediation efforts. The SOC and GRC teams jointly solved high-risk problems in three to five months. Medium-risk concerns were addressed within nine months.

Some issues, however, were not resolved. The enterprise decided that its risk appetite would allow it to accept a certain amount of residual risk. If mitigating an issue would cause underlying applications to stop working, for example, or if the downtime required to fix a problem would be excessively long, the known consequences of eliminating the risk might be worse than the potential consequences of accepting it.

To the extent that technical problems were solved, the company’s main business problem was also solved. The telecom company was able to maintain high network availability, thus maintaining customer trust. Risk was either eliminated, mitigated, or accepted, and it was done with visibility into the costs, gains, and potential consequences.

The company benefited from better detection engineering, detection coverage, detection accuracy, third-party risk assessment, and compliance with regulations and industry standards (figure2).

FIGURE 2 Postive Outcomes

Although the company previously assigned risk audits to its internal GRC team, the red team exercise prompted it to mandate a third-party audit to ensure compliance with NIST/ISO/US Federal Risk and Authorization Management Program (FedRAMP) standards. Among the outcomes: The company successfully passed the NIST International TelecommunicationUnion—Telecommunication (ITU-T) audit with minor-to-zero critical findings, confirming that its security controls met international telecom security standards.¹⁰ Internal security audits showed 96% compliance with the Center for Internet Security (CIS) Critical Security Controls, reducing vulnerabilities across the core network infrastructure.¹¹ The work Barpanda’s team carried out resulted in positive outcomes that enabled the company to strengthen its security posture and align its risk appetite with its real-world exposure. The enterprise collectively was more aware of security and better prepared to deflect or respond to potential threats.

Endnotes

¹ ISACA^®, “What Is the CISM Difference?”
² Shodan, “Search Engine for the Internet of Everything”
³ National Institute of Standards and Technology (NIST), “NISTRisk Management Framework,” USA
⁴ ISACA, “What Is the CISA Difference?”
⁵ IBM, “What Is the Log4j Vulnerability?”
⁶ Axonius, “Bring Truth to Action With the Axonius Asset Cloud”
⁷ MITRE, “Cybersecurity”
⁸ IBM, “What Is the MITRE ATT&CK Framework?”
⁹ International Organization for Standardization (ISO) and International Electrotechnical Commission (IEC), Joint Technical Committee on Information Technology (ISO/IEC JTC 1), ISO/IEC 27001:2022 Information security, cybersecurity and privacy protection.Information security management systems.Requirements, Edition 3, 2022
¹⁰ National Institute of Standards and Technology, “ITU-T,” USA
¹¹ Center for Internet Security (CIS), “CIS Critical Security Controls”

MICK BRADY

Is a freelance technology communicator with more than 20 years of experience editing and writing for technology-focused publications.