Empowering Executives with Security Effectiveness Evidence

After decades of presentations and prayers, security has finally become a business imperative for executives and boards alike. Business leaders are speaking publicly about championing security investments, as it’s important for shareholder value and future expectations. In fact, evidence-based security effectiveness measures are finding their way into annual reports (10-Ks), committee charters, and corporate governance documents.

Because of the spotlight that is on security, your business leaders are demanding security effectiveness evidence from you. This evidence is similar to the data-driven measurements and KPIs seen in other strategic business units such as shareholder return, client assets, financial performance, client satisfaction, and loss-absorbing resources.

Your leaders are making decisions predicated on these non-security measures every day to increase value for their shareholders, address stakeholder requirements, and mitigate business risks. Security is simply another variable in the business risk equation. In fact, your security program isn’t about security risk in and of itself, but rather, the financial, brand, and operational risk from security incidents.

One area where the need for security effectiveness evidence is profusely obvious is around rationalization. For example, many auditors no longer ask, “Do you have security tools in place to mitigate risk?” because the answer is always, “Yes, but we need more tools, training, and people anyhow.” Now auditors are asking for rationalization in terms of, “Can you prove, with quantitative measures, that our security tools are adding value? And can you supply proof regarding the necessity for future security investment?”

This evidence-based, rationalization methodology, often characterized as security instrumentation, aligns with the reality that your organization has finite resources to invest in security and that all investments need to be prioritized. Every dollar invested in security is a dollar not applied to other imperatives.

Measuring your security effectiveness: where you’ve been
The sad truth is that most security effectiveness measures are assumption-based instead of evidence-based. Because of a lack of ongoing security instrumentation, you assume your tools and configurations are doing what is needed and incident response capabilities are a well-choreographed integration of people, processes, and technologies. You know that assumption-based security is flawed. But historically, you haven’t had a way to empirically measure security effectiveness. You get some value from penetration testing, the endless march of scan-patch-scan, surveys, and return on security investment calculations, but these approaches don’t truly measure your security effectiveness. As a result, your business leaders are relying on incomplete and/or inaccurate data to make their decisions.

Where you need to be
You need to know if your security tools are working as intended. Once they are, you can optimize those tools to get the most value, rationalize, and prioritize where greater investment is required, and retire tools no longer needed. Then you can monitor for environmental drift so that when a tool is no longer working as needed, you are alerted to the drift and how to fix it. Finally, from a leadership perspective, your team can consider security effectiveness measures when calculating the business risks.

How to get there
By safely testing your actual, production security tools with security instrumentation solutions, not scanning for vulnerabilities, not looking for unpatched systems, and not launching exploits on target assets, but actually testing the efficacy of the security tools protecting your assets, you can start measuring security effectiveness of individual tools as well as security effectiveness overall. When gaps are discovered, you can use prescriptive instrumentation recommendations to address those gaps. Then you can apply configuration assurance to retest the security tools to validate that the prescriptive changes implemented resulted in the desired outcome. Once you have your security tools in a known good state, automated testing can continue validation in perpetuity, alerting you when there is environmental drift.

The end result of security instrumentation is security effectiveness that can be measured, managed, improved, and communicated in an automated way. Your security teams are armed with evidence-based data that can be used to instrument security tools, prioritize future investments, and retire redundant tools. This newfound ability to communicate security effectiveness and trends based on actual proof allows your decision-makers to incorporate security effectives measures when making business decisions.

Author’s note: Brian Contos is the CISO & VP Technology Innovation at Verodin. He is a seasoned executive with over two decades of experience in the security industry, board advisor, entrepreneur and author. After getting his start in security with the Defense Information Systems Agency (DISA) and later Bell Labs, he began the process of building security startups and taking multiple companies through successful IPOs and acquisitions including: Riptech, ArcSight, Imperva, McAfee and Solera Networks. Brian has worked in over 50 countries across six continents. He has authored several security books, his latest with the former Deputy Director of the NSA, spoken at leading security events globally, and frequently appears in the news. He was recently featured in a cyberwar documentary alongside General Michael Hayden (former Director NSA and CIA).

[ISACA Now Blog]

Source: https://www.isaca.org/Knowledge-Center/Blog/Lists/Posts/Post.aspx?ID=1060

Avoiding the Security Pitfalls of Digital Transformation

By 2020, 60 percent of enterprises will be implementing a digital transformation strategy as they seek to leverage technologies such as cloud and software-defined infrastructures. However, as they embark on a digitization journey, too many are ignoring security risks that could bite them back later.

Earlier this year, telecommunications giant AT&T developed a cybersecurity report based on interviews with 15 subject matter experts, including several (ISC)² members, to determine who holds responsibility for this transformation process. The report cautions organizations to be sure they evaluate and update their defense systems before implementing digitization plans. “Security models are changing as infrastructure goes virtual. If the number of cyberattacks in the news points to any one pattern, it’s that companies are grappling with how to secure their businesses from ‘edge-to-edge,’ across their endpoints, networks and cloud services,” the report says.

Some companies are taking a short-term approach to cybersecurity by overly relying on cyber insurance. “More than a quarter (28 percent) of organizations see cyber insurance as a substitute for cyber defense investment, rather than as one component of a multi-layered cybersecurity strategy.”

While cybersecurity can address the immediate impact of a breach, it cannot prevent long-term reputational damage. Instead, organizations should take a more balanced, comprehensive approach that includes layered security implementations and help from third parties where appropriate.

The report points out that U.S. companies are the least confident in their in-house security, according to the AT&T 2017 Global State of Cybersecurity survey, with 56 percent of U.S. respondents expressing confidence, compared to 70 percent in EMEA and 72 percent in APAC.

Security Steps

Properly planning for digital transformation requires several steps. The first is to gain an understanding of all security implications and then come up with a plan to address them. Organizations need a solid understanding of the security controls they have in place to determine if they are appropriate as their infrastructures evolve to include software-defined systems and Internet of Things (IoT) devices.

Then they should address whatever gaps they identify through a multi-layered security strategy and advanced security measures. For instance, it makes sense to virtualize security to replace simple firewalls with advanced web filtering and data loss prevention, the report suggests.

Another recommendation is to get buy-in not only from the top but also across the entire enterprise. For one thing, it’s important to recognize that the CFO is often the executive in charge of digital transformation, which means the CFO needs to be part of the team in charge of cybersecurity.

“This might seem counterintuitive for a technical project, but the CFO’s compliance and risk management responsibilities and their budget-allocation powers make them an obvious leader,” the report says. But because of the CFO’s “traditional lack of technical expertise,” the cybersecurity team also needs to include the CISO, CTO or whoever else is responsible for security.

Raising Awareness

To ensure everyone within the organization is invested in digital transformation and security, it makes sense to run training programs and workshops explaining how the new infrastructure will affect day-to-day operations. Cybersecurity awareness training should be ongoing, the report says.

The better a company’s employees understand security risks, the more likely they are to avoid doing something that could cause a breach. As companies become more reliant on digital and automated processes, this will become more important than ever.

[(ISC)² Blog]

Source: http://blog.isc2.org/isc2_blog/2018/08/avoiding-the-security-pitfalls-of-digital-transformation.html

Software-Defined Perimeter Architecture Guide Preview: Part 2

Thanks for returning for the second blog posting, providing a preview of the forthcoming Software-Defined Perimeter (SDP) Architecture Guide (Read Part 1). In this article, we focus on the “SDP Scenarios” section of the document, which briefly introduces the primary scenarios for SDP, explains why organizations should consider adopting SDP, and lists the benefits that SDP delivers for that scenario.

This section is—by design—concise. We’re passionate about SDP and network security, and could write an entire novel on this topic (in which our hero, network security architect Reavis Macdonald, uses SDP to prevail against a malicious adversary and save his organization from a record-breaking GDPR fine!). Sadly, our editor assures us that such a story wouldn’t be a bestseller, and that our Architecture Guide should likewise err of the side of brevity.

In this blog posting, we’ve chosen to elaborate on several of the scenarios and to provide some color commentary. Let’s get started!

SDP Scenarios at a Glance

Scenario 1: Identity-Driven Network Access Control

This scenario is the heart of the value that an SDP architecture provides. It enables organizations to fundamentally change the way they’re viewing security—shifting away from IP addresses and subnets, and toward identities and business systems. This is more than a technical shift—at least, it should be more than that. We’ll discuss this more in the SDP Policy section in the main document, but SDP allows for policies to be described in terms that are meaningful to the business, yet are enforced by the network.

Scenario 2: Network Microsegmentation

The concept of network microsegmentation—often part of a Zero Trust initiative—is driven by the imperative to enforce the principle of least privilege at the application and network level. But microsegmentation is only a means to an end. It requires a policy model, and a mechanism for automated enforcement of these microsegments in order to deliver efficient and effective value to the enterprise.

Shifting gears slightly, we now introduce several use cases that organizations commonly use to get started with Software-Defined Perimeter projects.

Scenario 3: Secure Remote Access (VPN Alternative)

Virtual private networks (VPN), while widely deployed, nevertheless suffer from a variety of shortcomings that frequently drive organizations to consider the Software-Defined Perimeter as an alternative. In addition to being disruptive to the user experience, VPNs typically provide too-broad network access, exposing far more services and protocols than necessary. VPNs are also difficult or awkward to use when people need to concurrently access many distributed resources —either across data centers or cloud environments. And finally, VPNs are a point solution. Because they are only used for remote access, their access policies are by definition unable to apply to on-premises users. SDP solves all these problems with VPNs, providing a single consistent and user-friendly platform that secures access for both remote and on-premises users with fine-grained control of access rights.

Scenario 4: Third-party User Access

Third-party access is another very common use case for SDP. While remote third-parties may fall under the VPN scenario, many organizations have considerable numbers of third-party users working on-premises. These users often need very specific (and limited) network access, while nevertheless using the same network as employees with broader access. A Software-Defined Perimeter provides a simple solution for this, which ensures that these third-party users have a consistently secured and managed set of network privileges, regardless of whether they are remote or on-premises.

Scenario 5: Enabling Secure Transition to IaaS Cloud Environments

Finally, we’re seeing many organizations leverage SDP to more easily and securely adopt IaaS cloud environments. Rather than relying on direct site-to-cloud connections (which provide too-broad network access), or traditional VPNs (which are awkward to use in multi-account or multi-site environments). SDP allows for precise access control to cloud environments, managed on a per-user basis.

Conclusion

We hope that this preview blog post gave you a good sense for some of the SDP scenarios, as well as a bit of expository context on our thinking around them. In our next blog posting, we’ll be reviewing the core concepts of the Software-Defined Perimeter , explaining their benefits, and listing some of the associated threats that they mitigate.

Jason Garbis is Vice President of Secure Access Products at Cyxtera, a provider of secure infrastructure for today’s hybrid environments, where he leads strategy and management for the company’s security solutions. Jason has over 25 years of product management, engineering, and consulting experience at security and technology firms including RSA, HPE, BMC, and Iona. He is co-chair of the Software Defined Perimeter (SDP) Working Group at the Cloud Security Alliance, holds a CISSP certification, is a published author, and led the creation of the Cloud Security Alliance initiative applying Software-Defined Perimeter to Infrastructure-as-a-Service environments.

Jason Garbis, Vice President/Secure Access Products, Cyxtera Technologies Inc.

[Cloud Security Alliance Blog]

FedRAMP: Friend or Foe for Cloud Security?

Cloud security is on everyone’s minds these days. You can’t go a day without reading about an organization either planning its move to the cloud or actively deploying a cloud-based architecture. A great example is the latest news about the US Department of Defense and its ongoing move to the cloud.

The US government is leading the charge by encouraging the private sector to provide secure cloud service offerings that enable federal agencies to adopt the cloud-first policy (established by the Office of Management and Budget in 2016) using FedRAMP. FedRAMP is a US government-wide approach for security assessment, authorization and continuous monitoring for cloud products and services. It sets a high bar for compliance with standards that ensure effective risk management of cloud systems used by the federal government.

There is even some chatter now about efforts to establish FedRAMP as a law, in an effort to encourage agencies to adopt the cloud at a more rapid pace. The delay in adoption is by no small measure related to the complexity, the intensive resource requirements of the current FedRAMP processes and finding providers that are FedRAMP-certified.

One of the main considerations to the adoption of FedRAMP on a wider scale is the difficulty for the industry, Third Party Assessment Organization (3PAO) and Cloud Service Providers (CSP) to determine what the profitability model is for engaging in the FedRAMP program.

Establishing such metrics can offer key drivers for industry adoption, perhaps by allowing CSPs to determine how offering FedRAMP-accredited IaaS/SaaS/PaaS can be truly beneficial and profitable for the company’s bottom line, at the same time allowing the agencies to determine the cost effectiveness of a move to the cloud.

While achieving FedRAMP accreditation has many challenges (as TalaTek learned over the past 18 months during deployment of its own cloud-based solution), there are clear benefits for the federal agencies and the industry to work with a FedRAMP-authorized service providers. At a high level, these include an established trust in the effectiveness of implemented controls and improvement of data protection measures.

Despite the many challenges for adoption, I am a big believer in the benefits outweighing the challenges of the FedRAMP program, especially in the long run, after the kinks are ironed out and the program maturity improves through increased adoption of both government and private industry.

The FedRAMP program provides significant value by increasing protection of data in a consistent and efficient manner – a key need among government organizations and especially among information sharing agencies – by providing these key benefits:

  • Enables a more successful move to the cloud for federal agencies;
  • Ensures a minimum security baseline for all cloud services;
  • Provides managed security continuity for a cloud offering versus a onetime compliance activity;
  • Standardizes requirements for all cloud service providers; and
  • Creates a 3PAO cadre that is capable, certified and can ensure quality assurance for cloud implementations.

By providing a unified, government-wide framework for managing risk, FedRAMP overcomes the downside of duplication of effort and inefficiency associated with existing federal assessment and authorization processes.

When considering a move to the cloud and the level of security that is necessary, we should all take risk management seriously and invest in skill development and knowledge, as well as in adapting the processes for the 21st century and getting ready for the reality of the dominance of the cloud in our near future. FedRAMP provides the roadmap for any organization to achieve these goals.

Baan Alsinawi, TalaTek founder and president

[ISACA Now Blog]

Threat Brief: Information on Critical Apache Struts Vulnerability CVE-2018-11776

Situation Overview

On August 22, 2018, the Apache Foundation released a critical security update for CVE-2018-1176, a remote code execution vulnerability affecting Apache Struts versions 2.3 to 2.3.34 and 2.5 to 2.5.16. The Apache Foundation has urged everyone to apply the security updates as soon as possible.

This blog is to provide information to help organizations assess their risk of the vulnerability and to inform Palo Alto Networks customers of protections in place that can help mitigate their risk until they can apply the security updates. Palo Alto Networks customers who have deployed the latest vulnerability signatures released on August 24, 2018, are protected.

 

Vulnerability Information

According to both the Apache Foundation and security researcher Man Yue Mo, this vulnerability can enable remote code execution on a server running a vulnerable version of Apache Struts. The method of attack would be through a specially crafted URL sent to the vulnerable system. In most cases, this means no authentication is required to exploit the vulnerability.

A successful attack would run code in the security context that Struts is using. In some cases, this could effectively lead to a total compromise of the system.

It’s important to note, however, that the vulnerability is not exploitable in default configurations. The following two conditions must both be met for a system to be vulnerable to attack:

  1. The alwaysSelectFullNamespace flag is set to “true” in the Struts configuration. (Note: If your application uses the popular Struts Convention plugin this is set to “true” by default by the plugin.
  2. The Struts application uses “actions” that are configured without specifying a namespace, or with a wildcard namespace. This condition applies to actions and namespaces specified in the Struts configuration file . NOTE: your application uses the popular Struts Convention plugin this condition also applies to actions and namespaces specified in Java code.

If your Struts application does not meet both of these conditions, your application may still be vulnerable but not (currently) exploitable via CVE-2018-11776.

In particular, if your application uses the popular Struts Convention plugin, it appears to potentially increase your risk of exploitability vis-à-vis other Struts implementations that do not use that plugin.

 

Threat Environment Information

The vulnerability was disclosed on August 22 in conjunction with security updates that address it. There is detailed information about the vulnerability and how to exploit it available currently. There is also proof of concept (PoC) code available already. As noted above, the PoC works only against systems that are vulnerable and meet both conditions for exploitability.

Some have noted that a previous critical Struts vulnerability was actively attacked last year only three days after the release of the security update and vulnerability information.

There are no known active attacks at this time and the current requirement that two, non-default conditions need to be met for the vulnerability to be exploitable makes for a different threat environment.

However with active PoC available we can expect at the minimum probing, if not active exploitation of this vulnerability in the near term.

Organizations should focus their risk assessments for possible attack until they can patch on four things:

  1. Are they using the Struts Convention plugin?
  2. Do they meet both of the required conditions for exploitation?
  3. Any weaponization or indication of attacks using the current PoC
  4. Developments of new PoC or attacks that render moot the two conditions required for exploitability?

 

Guidance and Protections for Palo Alto Networks Customers

All organizations running vulnerable versions of Apache Struts should deploy the security updates as soon as possible.

Organizations can and should prioritize scheduling and deployment of the security updates based on their security policy and risk assessment, and  on currently available information.

Palo Alto Networks customers who have deployed vulnerability signatures in content release version 8057 released on August 24, 2018, which include ID 33948 Name: Apache Struts 2 Remote Code Execution Vulnerability, are protected against currently known exploits against that vulnerability.

Our customers should still deploy the security update as recommended above, but can and should deploy the latest vulnerability signature immediate for additional protection. With this addition protection available, our customers can and should include that as part of their decisions around security and deployment of the security updates and their risk assessment of the vulnerability and threat environment.

As always, we are monitoring the situation closely and will provide additional details as they become available.

[Palo Alto Networks Research Center]

English
Exit mobile version