Blog

Posted on

The Inverted Cloud of Operability

It may be argued that the genesis of the cloud actually evolved from the early concept of the outsourcing model, where organizations sought to place their operations in the hands of suppliers who did technology—eventually evolving into the dynamic/elastic offering we see today as the cloud, or as I see it, the “Inverted Operational Environment”—but why inverted? Well, consider the definition of the word:

  • To turn upside down
  • To reverse in position, order, direction or relationship
  • To turn or change to the opposite or contrary, as in nature, bearing or effect
  • To invert a process
  • To turn inward or back upon itself
  • To turn inside out

In the context of this article I am focusing on two elements from the above list: 1) to reverse in position, order, direction or relationship, and 2) to turn inside out, insofar as the placement of all, or some elements of the technological support are being reversed against, what has been the operational norm of internal hosting; and that what has been accepted as an operational model based behind the logical-perimeter walls of the company, now being supported by an external actor in the guise of a cloud provider.

The benefit of a well-selected cloud provider is that they focus on delivering technology, maintaining currency in skills, and do tend to run optimized and well protected infrastructures. Please note that I have used the term well-selected cloud provider. However, the obtuse to this position is, as I have observed in some companies who did not exercise the required level of due diligence at the time of contracting out their operations into the hands of, what may be referred to as cheap-and-cheerful providers, only to realize their mistake when things go wrong.

When establishing a relationship with any external provider, in particular cloud, it is important to identify the areas of criticality which support the company. For example, is the selected provider aware of the policies, standards and guides to which the contracting company wishes them to adhere to? Another area which tends to get missed is that of incident response, with plug in from internal-to-external, establishing joined-up-thinking and cross-enterprise protocols and communications, which may be invoked when encountering cyber-adversity.

It is also essential when engaging the selected provider that there is an agreement around what the actual technological internals look like when it comes to segregation, platforms and the type of storage. It is at this juncture that it is also well advised to agree that no logical lock-ins are in place that could impact any future migrations if the provider is to be swapped out.

We then look to the governance and compliance challenges which must be addressed to ensure that the data objects that are being migrated out are in complete accord with the mandated obligations. For example, consider the financial institution that did not apply the required depth of due diligence at time of establishing their new partnership, further compounded by the lack of clarification around the profile of storage, resulting in PCI DSS data being sent to a multi-shared insecure jump server located within the cloud provider’s premises, leaving the bank exposed to a serious PCI breach situation.

We then come to all of the other elements which should be at the forefront of the operational mind-set, ranging from monitoring, service reviews, and of course, where applicable, escrow agreements. It is here in an ISACA webinar on 20 April we will explore the topic of the cloud and will dig deep into some of the operational and management challenges that should be considered prior to going live with any such external migrations.

John Walker, CEO, HEXFORENSICS LTD

[ISACA Now Blog]

Posted on

Exploitation Demystified, Part 3: Heap-Based Exploits

In my previous blog post in the Exploitation Demystified series, we learned how memory corruption exploits are implemented using stack-based overflow vulnerabilities. Let’s talk now about a main alternative path: heap-based vulnerabilities.

What Is the Heap?

An operating system (OS) allocates memory to a computer program, with respect to the size of the data this program consumes, which is either known before or determined at runtime. We have already introduced the stack, which is the OS allocation mechanism to the former. We will now get to know the heap, which serves the same allocation function to the latter.

The heap is the memory pool from which dynamic data requests are fulfilled. From a vulnerability/exploitation perspective, the two material differences between the stack and the heap are:

  1. Heap memory must be requested explicitly. The program asks for a memory chunk in a certain size and gets a pointer to the first address of this chunk. The program should alsofree this chunk when it has completed its task. The request-free logic is the root cause to the common vulnerabilities class of use-after-free/double –free.
  2. The heap is significantly larger in size than the stack. This makes an accurate prediction of the shellcode’s address much more complicated than in the stack. This complication is the development driver of the heap spray exploitation technique, which is practically common practice in most to all heap-based exploits.

Memory Corruption Recap

Let’s remember what we have learned so far about memory corruption exploits. This class of exploits involves placing a shellcode into a data input file, which is crafted to trigger a vulnerability in the processing application. The vulnerability renders a foothold in the process memory space, which the attacker leverages to redirect the execution flow towards the shellcode address. I’ll explain how both the Overwrite and Redirect parts are implemented on the heap.

Heap-Based Vulnerabilities Overview

In this post we will not deep dive into the subtleties of heap-based vulnerabilities. This is because the role of vulnerabilities in the exploitation lifecycle is to enable the initial address overwrite. From a security standpoint, this initial overwrite can hardly be prevented (except by a vendor patch). But proactive prevention can be applied to the Redirect and Execute parts of the exploits, so we will focus on these.

For our purposes, it suffices to know that there are two main groups of heap-based vulnerabilities: heap overflows and use-after-free. Let’s see what address is overwritten in each of these groups.

Heap overflows take advantage of the heap internal structure. Consecutive heap requests generate consecutive memory chunks. Each chunk consists of a header, which contains the chunk’s metadata, and the actual memory space in the requested size. Heap overflow vulnerabilities will overflow the memory space and overwrite the next chunk’s header.

Use-after-free vulnerabilities take advantage of the explicit call/free feature we have previously described. As we have explained before, dynamic memory requests render a pointer to the first address of a newly allocated chunk. If this pointer maintains validity despite the pointed object being freed, attackers can overwrite it to point to their own code (i.e., the placed shellcode). Use-after-free were the most exploited vulnerabilities on Windows 7 and later versions of Windows during 2015.

Heap-Based Exploitation Redirection – Heap Spray

Once the attacker is able to overwrite and control a heap address, the main objective is to resolve the shellcode’s address. Due to the heap’s size and allocation architecture, it is a much harder task relative to the equivalent stack scenario.

The Prediction Challenge

When placing a shellcode into a data input that is loaded to the heap, the attacker can know theaddresses range in which this shellcode resides but not the exact address of the shellcode itself. I’ll explain the technique that has evolved in response to this challenge.

No Operation (NOP) Instruction

Attackers have overcome the prediction problem by loading multiple byte sequences and shellcode into the heap. The basic implementation of these sequences is to use NOPs. NOP stands for “No Operation”, and it instructs the CPU to move to and execute the instructions in an adjacent address.

NOPs can solve the heap address prediction problem. Consider a block that contains a NOP sequence, followed by a shellcode. Let’s assume that we fetch the CPU a NOP address. The CPU will simply move to the next address and so on and so forth until reaching the shellcode and executing it. The NOPs have exponentially raised the probability of a successful shellcode execution because, instead of just one “good address” (the shellcode’s), we have multiple.

Heap Spray

What I’ve just described is the basis for the Heap Spray technique, which, as the name implies, sprays a vast area in the heap chunk with many NOPs and shellcode sequences. The spray ensures that, no matter which address the execution flow will jump, it will end up with executing the shellcode.

Constant Evolution

Exploit writers continuously advance their heap prediction capabilities. The more accurate prediction capabilities are, the smaller a heap spray can get. The heap sprays that were featured in exploits from 2014–2015 are considerably smaller and more targeted than the ones from before this period.

Conclusion

In this post we have concluded our description of memory corruption exploitation essential building blocks. The three blogs together render basic understanding of what a memory corruption exploit is, and how it is implemented.  Of course there is a lot more to learn and know on this vast subject, and we hope that this is the first step to encourage you to proceed onwards.

[Palo Alto Networks Research Center]

Posted on

COBIT Celebrates 20 Years of Guidance

Spawned from a humble white paper titled “Control Objectives” and developed into broader guidance on control objectives, the COBIT framework is celebrating its 20th anniversary this year.COBIT was first published in April 1996 and is now in its fifth version. Initially, COBIT was intended to provide guidance for auditors. As it gained use, there were calls for greater guidance for internal control.

The next iteration, COBIT 2, was published in 1998 and offered additional guidance for controls. As an audit and controls guidance framework, COBIT 2 gained broader exposure. The marketplace then began asking ISACA to provide greater assistance in managing the entire IT function. Additional guidance was developed and COBIT 3rd Edition was released as a management framework in 2000.

IT governance is more inclusive than management, and the marketplace needed still greater guidance on aligning IT strategy with management. Thus, COBIT 4.0 was released as an IT governance framework in 2005. Market feedback indicated that the structure of the control objectives was more complicated than necessary, so two years later COBIT 4.1 was released with a reduced set of control objectives.

The latest evolution of the framework, COBIT 5, was published in 2012 and provides a comprehensive business framework for the governance of enterprise IT. COBIT 5 presents a model for the alignment of overall enterprise strategy with IT strategy, operates on a relatively simple foundation of five principles with seven enablers, and is aligned with several significant internationally recognized standards bodies, such as ISO/IEC and ITIL. More than 800 people provided input into the design of COBIT 5, which required nearly two years to develop and is now available in 16 languages.

COBIT user surveys have shown that COBIT 5 is very beneficial in helping enterprises manage their risks and more clearly demonstrate the delivery of value to stakeholders. In a recent survey of COBIT 5 purchasers and downloaders, more than 9 in 10 said they would recommend COBIT 5 to others.

Because governance guidance must reflect the needs of practitioners, and as the technological and threat landscapes evolve, COBIT also will continue to evolve to best serve its users.

To access infographics, testimonials and information on COBIT’s history—or to submit your own COBIT stories and photos—click here.

Peter Tessin, Technical Research Manager, ISACA

[ISACA Now Blog]

Posted on

Panama Papers Expose Data Security Deficiencies in Law Firms

The unprecedented leak of 11.5 million files from the database of the world’s fourth biggest offshore law firm is riveting. As details continue to emerge about the Panama Papers leak, the money laundering and secretive tax regimes and high-profile clientele make for a juicy story. But from an enterprise data security perspective, here at Code42 we’re shaking our heads.

It’s hard to imagine a situation where the stakes for data protection could be higher. This is an organization whose entire “empire” is built on “secret” data. And it was an all-or-nothing game: Mossack Fonseca will likely never recover to earn the trust of a future client—tax evader or otherwise. If there ever was an organization that warranted exceptional network security tools and data security measures, Mossack Fonseca was it.

A data security wake-up call for honest law firms everywhere
If a massive international law firm dealing exclusively in extremely sensitive data is this easily hacked, how vulnerable is your average, above board law firm?

According to the statistics, the answer is “very.” John McAfee penned an article for Business Insider in which he concludes that “law firms are easy pickings for hackers.” Bloomberg found that 80 percent of large U.S. law firms were hacked in 2015. Even more alarming, in the 2015 ABA Technology Survey, 23 percent of firms surveyed said they “don’t know” if they’ve experienced a breach, and only 10 percent have any sort of cyber liability coverage. For a cohort that knows a thing or two about liability lawsuits—and certainly knows that “ignorance of the law” is a poor defense—this is surprising.

Data protection is a high-stakes game for every law firm
And while a data breach at your average law-abiding law firm isn’t likely to result in indictments for fraud, the stakes are still extremely high. “The implications of law firm breaches are mind boggling,” Philip Lieberman, president of Lieberman Software, told Computer Business Review.

Most clearly, a firm stands to destroy every shred of trust with its clients—a reputation bomb that will be tough to recover from. In many cases, a leak could compromise legal proceedings and eliminate advantages by placing litigation strategy and privileged information out in the open.

Even if a firm’s clients and reputation escapes unscathed, data loss of any kind can trigger significant financial impact. A damaged laptop, or ransomware that holds data hostage, can leave an associate without access to critical information. The loss of billable hours quickly adds up. Add to that breach reporting requirements and potential fines, and the ROI of modern enterprise data security tools is easily apparent.

It will be interesting to watch the continued fallout from the Panama Papers, and we’re happy to count this as a win for the “good guys.” But as it dominates headlines and newsfeeds, we hope it’s also a major reminder for law firms—and enterprises in every industry—to re-examine what they’re doing to protect their data.

Download The Guide to Modern Endpoint Backup and Data Visibility to learn more about selecting a modern endpoint backup solution in a dangerous world.

Rick Orloff, Chief Security Officer, Code42

[Cloud Security Alliance Blog]

Posted on

Maximizing your Panorama Deployment, Part 2

Customize Your Panorama Deployment to Meet Your Needs

In my last blog post, I described the overall benefits of moving to a network security management solution such as Panorama. I also hinted at three additional steps you can take to ensure optimal performance of your management platform. In this blog post, I’ll go into more detail on these three steps.

Step 1. Move from Virtual Machine (VM) to a Hardware Platform

Deploying Panorama on a VM is a great option for those who want fewer appliances in their security deployments, but it can come with drawbacks. You have to ask a VM management team to add processing power when VM resources are oversubscribed. Deploying a hardware appliance (either an M-100 or M-500 appliance) in your network ensures available resources when you need them. Free yourself from dependence on third-party hardware vendors.

Step 2. Add Dedicated Log Collectors

Combining management and log collection into one piece of hardware may work in some instances, especially for small networks; but, as soon as your log retention increases, you are sacrificing valuable management resources for logging.

Adding dedicated log collectors (additional M-100 or M-500 appliances) to your Panorama deployment will increase log ingestion rates, lengthen log retention, and free up valuable resources. Adding log collectors strategically across your distributed deployment will also cut back on the need to backhaul all logs over WAN links and provide better access to configuration-wide data for analysis.

Step 3. Deploy Panorama in High Availability (HA)

It’s no secret, HA decreases the chance of downtime for hardware. Panorama can be deployed in HA, effectively increasing availability and eliminating single points of failure. Improve availability by deploying Panorama in HA.

Check back next week for the final post in this series where I’ll share the importance of planning for the future state of a company when deploying Panorama. In the meantime, watch the Panorama demo to learn more.

[Palo Alto Networks Research Center]

English
English
Exit mobile version