micro-segmentation

Getting up to speed with Micro-Segmentation

High-profile cyber attacks are frequently in the news these days, putting IT security at the forefront of everyone&#rsquo;s minds. The WannaCry and Petya ransomware assaults, in particular, hit major businesses across the world in nations as diverse as the US, Russia, India, Taiwan and Britain.

The WannaCry extortion attack alone impacted more than 300,000 PCs that companies thought were protected, by targeting unpatched Windows 7 systems.

The message is clear. In order to survive the next security threat, you&#rsquo;re going to need to approach security in a completely new way.

Many businesses discovered their perimeter network security no longer gives them adequate protection. In fact, VMware&#rsquo;s Garry Owen says, in this video, that perimeter security &#rsquo;is no longer fit for purpose&#rdquo;.

What we need is to secure the inside of the network, as well as the edge of it, argues Garry in What have we learned from WannaCry? How to future-proof your IT security.

One way to do this is by bringing security up to date, which you can do with virtualization. See the video, and the Dummies Guides below, to discover how VMware can help you to make sure your security stays strong going forward.

This new networking approach means if an attacker breaks in through the outside door, their movements are limited to the &#lsquo;room&#rsquo; they&#rsquo;re in. It&#rsquo;s a completely new way of doing network security, Garry says: a way to future-proof your IT security.

Micro-segmentation - get up to speed

To find out all about micro-segmentation and Zero Trust security, download this free, must-have resource from VMware: Micro-segmentation For Dummies – and get the jump on the next WannaCry wannabe.

Network virtualization - rethink networking

And for a comprehensive and free guide to network virtualization in six chapters, get VMware&#rsquo;s Network Virtualization For Dummies . Make your network move as fast as your business!

Read more..

Networking Challenges in OpenStack Clouds

Did you decided that is time to implement OpenStack to build your Cloud? Have you tested in the lab? Evaluated many distributions available and hired specialized OpenStack resources? However, when the environment goes into production, Neutron is not integrating with the physical network?

If the above story closely resembles what you have faced, this post will unconceal the many challenges of Networking with any OpenStack distribution and how VMware NSX is the missing piece for your Cloud.

Networking and Security Challenges with OpenStack

Since its creation, the biggest challenges of OpenStack Clouds implementations are automation, integration and orchestration of the required networking and security components at the physical infrastructure layer. The main difficulty is that these environments are extremely heterogeneous and most of the devices do not have an open and programmable interface for configuration and, thus, the initial way of running OpenStack was to pre-provisioning the network manually and only use basics functionalities when implementing security services.

With the rise of Network Virtualization solutions and evolution of Open vSwitch, some of these challenges were solved, making it possible to create an abstraction layer from the physical elements of infrastructure and automate the virtual network through the programmable interface of Network Virtualization solutions.

However, the Neutron project (responsible for managing all OpenStack Cloud Security and Network services) has been undergoing constant modifications, especially regarding the need for more advanced functionalities, such as dynamic routing, VPN , firewall functionality and others. With those constant changes, maturity, consistency and resilience were eventually undermined.

If you are interested in how VMware is currently contributing to OpenStack community, please read Scott Lowe‘s post - Making OpenStack Neutron Better for Everyone - on our VMware OpenStack Blog.

The table below, extracted from the 2017 OpenStack Foundation User Survey, exemplifies which features of Neutron that are being used the most or currently required in the majority of OpenStack Clouds.

Growth without planning has brought major challenges to the Neutron project. What is most debated today is whether the architecture of this project needs to be reworked, in order to simplify its use and improve its integration with Network Virtualization Solutions.

VMware NSX Integration with OpenStack

Few companies today are using OpenStack in production without a networkvirtualization platform, and those that are not, usually face major challenges like the ones mentioned above.

The benefits that VMware NSX brings to Neutron can be listed below:

  • Agility: Create Networks at the same speed as the applications;
  • Mobility: Provision and mobility of instances;
  • Security: Micro-segmentation and chaining of partner services for advanced features;
  • Multi-tenant: Possibility of using shared infrastructure among multiple tenants;
  • Simplified Operations: Centralized control and single monitoring;

As mentioned, the challenges with Neutron can be addressed with NSX as follows:

  • Simplified implementation of Neutron services;
  • Stability, scalability and high availability;
  • Continuous development of new functionalities;
  • Higher performance due to distributed NSX architecture;
  • Management, Day 2 Operations, and native Troubleshooting Tools in NSX;

To perform integration with Neutron, VMware NSX has an open plugin available on the GitHub page that can be used by any OpenStack distribution or implementation.

This plugin translates the Neutron APIs calls into NSX APIs calls at the NSX Manager and thus builds the network and security services. The figure below exemplifies and shows an example of what can be deployed using this approach:

VMware NSX supports OpenStack environments regardless of the underlying hypervisors and has plug-ins available for any OpenStack distribution to use its benefits.

Meet some of our customers who are benefiting not only from NSX, but also from VMware Integrated OpenStack at the links below:

  • HedgeServ - https://youtu.be/NFcIa314X5k
  • Rakuten - https://youtu.be/11ew7zEPOso
  • Charter - https://youtu.be/mw6fdkpvzoY
  • Amadeus - https://youtu.be/HmdqPDK-cLY
  • IBM - https://youtu.be/4a3EeROQTxI

On the Road

If you would like to understand more about this topic, I will be delivering sessions regarding Networking and Security Challenges in the following events:

VMworld’17 - Las Vegas - USA

August 27 - 31, 2017

Mandalay Bay Hotel & Convention Center
3950 S Las Vegas Blvd
Las Vegas, NV - 89119 - USA

My session will be Tuesday, 29th August at 4pm.

To know more about VMworld’17 click here.

OpenStack Day 2017 - São Paulo - Brazil

Saturday, July 15, 2017, 08:30 a.m. to 8:00 p.m.

Gamaro Theater
Doctor Almeida Lima, 1176 - Mooca
São Paulo, SP - 03164-000 - Brazil

My session will be at 2:40pm at the main stage.

To know more about OpenStack Day São Paulo click here.

If you have the opportunity to be in any of these events, don’t hesitate to reach me!

I hope you have enjoyed this post and contact me if you have any questions.

 

The post Networking Challenges in OpenStack Clouds appeared first on Network Virtualization.

Read more..

Progressive Dutch Municipality Protects Citizen Data and Meets Compliance with VMware NSX

Summary: Municipality of Zoetermeer implements Zero-Trust model with VMware NSX-enabled micro-segmentation for advanced security inside data centers. Zoetermeer follows the Dutch BIG (Baseline Information Security Dutch Municipalities) regulations

Zoetermeer is a modern, fast-growing municipality in the province of South Holland. It provides local services such as water supply, sewage and garbage disposal to around 125,000 residents. As a forward-thinking organization, the municipality of Zoetermeer recognizes that the increasing volume of cyber attacks against organizations today has shown that traditional, perimeter-centric security models are no longer effective.

The municipality responded by working with VMware partner ON2IT IT Services on a solution that wouldn&#rsquo;t treat everything inside the network as trusted. Zoetermeer deployed VMware NSX® network virtualization to facilitate a Zero Trust security model. This Zero Trust model is enabled by the unique micro-segmentation capabilities of VMware NSX. Zoetermeer is now compartmentalizing different segments of its network and applying automated, fine-grained security policies to individual applications.

&#rsquo;The municipality of Zoetermeer is committed to delivering digital services to our citizens, and also digital tools to enable the best experience for our employees,&#rdquo; said Mr. Van Gaalen, IT Manager, Municipality of Zoetermeer. &#rsquo;But security must remain paramount. Thanks to VMware, we can provide the right person – citizen or employee - with secure access to the right data, from anywhere.&#rdquo;

In addition to providing advanced security inside its data center, the solutions have enabled the municipality to meet rigorous regulatory compliance requirements. VMware NSX has been instrumental in enabling the municipality of Zoetermeer to conform to BIG (Baseline Information Security Dutch Municipalities). These BIG rules have been introduced by the information security service (IBD) of the Association of Dutch Municipalities (VNG) and consist of a set of security measures that ensure a good basic level of security for municipalities. To meet these guidelines, optimal and transparent IT processes and security rules are required.

Mr. Van Gaalen also noted, &#rsquo;VMware helps us meet the rigorous government requirements for security and data protection. With micro-segmentation, we can better manage security policies across our network, aligning them with individual applications and ultimately reducing risk. It was the clear next step in achieving a secure software-defined data center,&#rdquo; said

A longstanding VMware customer, Zoetermeer was the first Dutch municipality to use VMware Horizon desktop virtualization. As it continues on its journey of mobile digitization, the municipality will soon provide the majority of its employees with digital workspaces when its newly-built town hall opens. It will deploy VMware AirWatch® Mobile Device Management to securely manage its fleet of mobile devices and to support its growing mobile workforce.

The post Progressive Dutch Municipality Protects Citizen Data and Meets Compliance with VMware NSX appeared first on Network Virtualization.

Read more..

Enabling the Software-Defined Branch with NSX

Reimagining the edge

While the importance of the cloudis obvious to anyone,the increasing importance of the edge is often overlooked. As digitization and the Internet of Things are leading to an exponential growth in the number of devices, the amount of data that is being generated by sensors in devices such as self-driving-cars, mobile endpoints and people tracking systems for retail is astronomical. Analyzing and turning that data into immediate actions is key to success in the era of digitization. The cloud enables massive data storage and processing, but it does not always lend itself to real time processing and immediate actions. Latency and the sheer amount of data to be transmitted are much less of a factor for the edge compared to the data center. In order to make instant decisions, some of the data processing needs to happen at the edge. At the same time, a large number of employees no longer work form the corporate HQ, but have ever increasing expectations with regards to application access regardless of their physical location. Distributed computingacross the edge, along with high performance cloud access and distributed security enforcement give organizations “the edge”. Centralizing management and operations with distributed control and enforcementcould define theNext-Generation Branch.

Challenges with legacy branch architecture

While digital transformation has lead to organizations embracing the Software-Defined Data Center, the Remote and Branch Office (ROBO) infrastructure has remained largely unchanged. The static nature of branch architecture does not only result in high operational expenses, but also slows down the organization as it impacts the rolloutof new applications to those branches. Bringing up a new branch typically involves shipping and configuring a number of infrastructure hardware and appliances, such as pairs of firewalls, routers, file/print servers, point of sale, etc. The logistics involved with getting those appliances delivered and configured is complex, slow, and often requires specialized personnel to spend time on site. SendingCCIE certified engineers out to branch locations to configure a branch router is not a rarity, and yet certainly not scalable nor efficient. These challenges extend beyond the initial branch deployment, as any change to the branch infrastructure or even day-to-day management and operations of a large number of branches, each with their own stack of appliances is a heavy lift operation.

In addition,while branches often don’t have the same level of security controls as the corporate HQ, employees at the branches have the same expectations as employees at the HQ when it comes to accessing corporate resources; as a result, branches are often leveraged as an attack vector to targetthe corporate data center. While many companies still backhaul all branch traffic to a centralized location and provide Internet access services and security from that central location, organizations are increasingly leveraging public broadband connections to provide Internet access services and access to cloud applications from the branch. This effectively introducesa new perimeter at every branch, which in turn needs to be secured.

The increase in cloud utilization, massive uptake in number of connected devices, as well as customer and employee expectations are at the base of another challenge with the traditional branch. Often branches are using private links such as MPLS through a service provider. Those circuits come with a very high operational expense, take multiple months to get provisioned, and are very inflexible.

Building a Software-Defined Branch

Given the above challenges with traditional branch infrastructure, what are the characteristics of a next-generation branch solution? Whatwould a Software-Defined Branch look like?

Key requirements of the Software-Defined Branch solutionare depicted in the diagram. With these, the branch can evolve to be more agile asset of the organization, adaptable and open to new innovations. In addition, these canlower capital and operating expenses compared to the traditional branch infrastructure by enabling a more streamlined operational IT model.

Central Management and Operations

Managing infrastructure and applications across a large number of geographically dispersed branches is challenging due to distributed nature of these appliances. In addition, the multitude of services that exist at those branches often forces a siloed and costly model of operations and management. In order to deal with those challenges, enterprises are looking at how branch management and operations can be centralized, with fewer panes of glass.The VMware ROBO solution allows the management plane to be centralized, so that the central management functions vCenter, NSX, and partner solutions can be deployed at the HQ to manage branch IT remotely.

Infrastructure Consolidation

Another branch pain point is thequantityand footprint of physical appliances that are deployed at each branch. Each appliance is a potential point of failure, and replacing hardware either requires costly RMA contracts or a large number of different purpose-built spare devices collecting dust in a depot. Many of the services that run as physical appliances in the branch can be virtualized and consolidated on a single x86 server with ESXi and NSX as the converged software platform.The VMware stack provides a smart fabric, leveraging native network and security services. Additional infrastructure solutions such as SD-WAN along with branch applications can be deployed over this platform.

Streamlined Provisioning

Enterprises want to drastically reduce the time and expense associated with bringing up new branch infrastructure. Because remote and branch offices often have such similar requirements, virtualization and automation are key in solving the provisioning problem. With VMware vSphere and NSX, templates and policies (such as security groups and security policies) can be used to pre-define the ROBO software stack and security requirements for a set of branches. Leveraging IT automation tools or vSphere and NSX APIs and tools such as PXE, the provisioning of x86 from bare-metal to branch-ready can be automated.

Reliability and Availability

Corporations need their branch infrastructure to be resilient to failure such as failure of individual appliances or applications, or failure of a WAN link. vSphere for ROBO includes vSphere HA and vSphere Replication for High Availability and Resiliency. vSAN for ROBOenables hyper-converged storage optimized for VMs. NSX for ROBO provides high availability functionality for the Edge Services Gateway, and 3rd party SD-WAN solutions enable a highly available WAN whichcan typically be deployed as a HA pair of VMs.

Adaptable Network

Organizationswant to be able to define local area networking in software, distributed across the branches and controlled centrally, which enables them to provision applications and infrastructure rapidly with great flexibility. Additionally,there’s a growing interest in usingmultiple business broadband links in an active/active fashion, with business policies defining how different applications use the available pool of Internet/WAN connectivity, and/or use secured tunnels to connect branches to each other and to the data center. NSX allows network connectivity, services, and security policies between applications tobe orchestrated or manually changed remotely and without physical changes. Software-Defined WAN enables the use of multiple different types of WAN/Internet circuits in an active/active fashion based on an administratively defined business-policy.By running an SD-WAN Virtual Machine on the branch ESXi host running NSX, enterprises can implement hybrid WAN as a function of a software defined branch platform, aswell as security and visibility for East-West and Internet/WAN traffic through the NSX Distributed Firewall and partner firewall services.Alternatively, an existing router can remain in place or can be replaced by the NSX Edge Services Gateway whichprovides functionality including first hop routing for all users, workloads and physical compute resources, DHCP server/relay and security for all North/South traffic (in addition to East/West traffic) from the branch to the Internet or WAN. The ESG also enables IPSec VPN tunnel termination between the branches and data center. NSXallows networking to be centrally defined in software, and distributed across the hypervisors in the data center and in the branches.

Visibility and Security

A branch security solution needs to be able to protect the perimeter, which typically involves Next-Generation Firewall functionality such as Application Visibility and Control and URL filtering. This perimeter protection should be able to protect users, virtual workloads and physical appliances. In addition to protecting the perimeter, the branch security solution should also provide the ability to segment branch workloads, and enable organizations to move to extend the Zero Trust architecture from the data center to their branches. As the WannaCry global ransomware attack - which spreads laterally through SMB and RPD - made painfully clear, a least privilege/ zero-trust security model is foundational to security in the datacenter and beyond in order to contain laterally moving attacks.. NSX Micro-Segmentation can be leveraged in the branch in order to segment different workloads from each otherwithin a branch or across branch locations.In addition, the NSX Service Insertion framework allows for additional partner services such as NGFW, IPS or AV to be applied granularly to select VM traffic.The NSX Edge Services Gateway provides L3/L4 filtering and can act as a router for all traffic, including traffic from users and physical appliances. If SD-WAN is deployed as a virtual machine on the branch host,the NSX Distributed Firewall can be applied to the SD-WAN VM to provide native L3/L4 filtering as well as NGFW partners services to all traffic crossing the perimeter.

The below diagram depicts VMware ESXi and NSX as the converged software platform for the branch, consolidating branch application workloads and virtual network functions:

NSX for ROBO Licensing

In addition to existing ROBO licenses for vSphere and vSAN, ROBO Licensing for NSX is now available as of therelease of NSX for vSphere® 6.3. Licensed features include distributed switching and firewalling, edge services, service insertion and more.

Learn More

If you want to learn more about how the VMware ROBO solution enables the Software-Defined Branch, check outthis whitepaper: NSX for Remote and Branch Offices (ROBO).

The post Enabling the Software-Defined Branch with NSX appeared first on Network Virtualization.

Read more..

Use a Zero Trust Approach to Protect Against WannaCry

Micro-segmentation with VMware NSX compartmentalizes the data center to contain the lateral spread of ransomware attacks such as WannaCry

On May 12 2017,reports began to appear of theWannaCrymalware attacking organizations worldwide in one of the largest ransomware cyber incidents to date. TheEuropean Union Agency for Law Enforcement Cooperation (Europol) has reported more than 200,000 attacks in over150 countries and in 27 languages byWannaCry, with the full scope of the attack yet to be determined.Victims include organizations from all verticals.

WannaCrytargets Microsoft Windows machines, seizing control of computer systems through a critical vulnerability in Windows SMBand RDP. It encrypts seized systems and demands a ransom be paid before decrypting the system and giving back control. The threat propagates laterally to other systems on the network via SMB or RDP and then repeats the process. An initial analysis ofWannaCryby the US Computer Emergency Readiness Team (US-CERT) can be foundhere.

One foundational aspect of increasing cybersecurity hygiene in an organization to help mitigate such attacks from proliferating is enabling a least privilege (zero trust) model by embedding security directly into the data center network. The core concept of zero trust is to only allow for necessary communication between systems using a stateful firewall, assuming all network traffic is untrusted. This dramatically reduces the attack surface area.

VMware NSX micro-segmentation provides this intrinsic level of security to effectively compartmentalize the data center to contain the lateral spread of ransomware attacks such as WannaCry.

In this blog, we will focus on how NSX can help:

  • Contain the spread of the malware such asWannaCry
  • Provide visibility into on-going attacks
  • Identify systems that are still infected
  • Mitigate future risk through a micro-segmentation approach

Stages of theWannaCry cyber attack

Before we provide our attack mitigation recommendations, let us review the WannaCry ransomware attack lifecycle.

  1. Weaponization:

WannaCryuses theEternalBlueexploit that was leaked from the NSA to exploit the MS17-010 vulnerability in Windows.WannaCrythen encrypts data on the system including office files, emails, databases, and source code, using RSA-2048 encryption that isimpossible to break.WannaCryends the &#rsquo;weaponization&#rdquo; stage by posting a message to the user demanding $300 in bitcoin as a ransom in order to decrypt the data.

  1. Installation / Exploitation / Encryption / Command and Control:

WannaCrycycles through every open RDP session since it is also a worm that contains the malware payload that drops itself onto systems and spreads itself. As soon as the ransomware is dropped, it tries to connect to a command and control URL to seize control and encrypt the system. The code has both direct as well a proxy access to the internet. Next step for the worm is to install a service called “mssecsvc2.0” with display name “MicrosoftSecurity Center (2.0) service”. The worm loads the crypto module when the service is installed and proceeds to encrypt the system.

  1. Propagation:

WannaCryenters through email phishing or other means of breaching the network perimeter and scans all of the systems on the network based and spreads laterally from vulnerable system-to-system. Scans are not just restricted to systems actively communicating but also IP addresses obtained via multicast traffic, unicast traffic, andDNStraffic. OnceWannaCryobtains a list of IPs to target, it probes port 445 with a randomly generated spoofed source IP address. If the connection on port 445 of a vulnerable system is successful,WannaCryproceeds to infect and encrypt the system. Additionally, it scans for the entire /24 subnet for the system (10 IP addresses at a time), probing for additional vulnerable systems.

Preventing the attack with VMware NSX

NSX can be used to implement micro-segmentation to compartmentalize the data center, containing the lateral spread of ransomware attacks such as WannaCry and achieving a zero trust network security model.

The following are recommendations in order of priority, to create a micro-segmented environment that can interrupt the WannaCry attack lifecycle.

  1. Detect traffic on port 445 in the NSX distributed firewall. This would provide visibility into aWannaCryattack in progress. Allow or Block logs can be sent from NSX to a log analyzer of your choice (for example, vRealizeLog Insight), for further analysis.
  1. Enable environmental redirection rules in NSX so that any traffic destined for critical systems is steered to an NSX-integrated IPS solutions to detectattempted exploits ofCVE-2017-0144. Even if the perimeter did not detect the malware, east-west traffic within the environment can be analyzed to detect the CVE.
  1. Create an NSX Security Group for all VMs running the Windows Operating System, to identify potentially vulnerable machines. This is really simple to do in NSX as you can group VMs based on attributes like operating system, regardless of their IP address.
  1. Enable Endpoint Monitoring (NSX 6.3+ feature) on VMs that are part of the Windows operating system to detect mssecsvc2.0. If detected, verify and check what VMs it has started communicatingwithon port 445.
  1. Create a distributed firewall rule to immediately block/monitor all traffic with a destination port of 445 on the /24 subnet ofany VMs that is found on that list.
  1. Use Endpoint Monitoring to detect if mssecssvc2.0 is running on systems that are not patched so that NSX can detect if a new attack starts.

Additional precautions include blockingRDP communication between systems andblocking all desktop-to-desktop communications in VDI environments. With NSX, this level of enforcement can be achieved with a single rule.

Architecting a secure datacenter using NSX Micro-segmentation

With NSX micro-segmentation, security architects can enable a least privilege, zero trust model in their environment. For environments utilizing NSX, the distributed firewall applies security controls to everyvNICof every VM. This controls communications between all VMs in the environment (even if they are on the same subnet), unlike the traditional firewall model in which flows within a subnet are typically not restricted, allowing malware to spread laterally with ease. With a zero trust architecture enabled by NSX, any non-approved flow will be discarded by default, regardless of what services have been enabled the VM, and ransomware likeWannaCrywill not be able to propagate - immediately blunting the amount of damage to data center operations and hence the organization.

The post Use a Zero Trust Approach to Protect Against WannaCry appeared first on Network Virtualization.

Read more..

VMware AirWatch – NSX Integration

 

Integrate VMware AirWatch Enterprise Mobility Management with VMware NSX Network Virtualization and Security Platformto extend security policies from the data center to mobile application endpoints. VMware AirWatch – NSX Integration brings speed and simplicity to networking and micro-segmentation capabilities. By creating policies that dynamically follow mobile applications, it eliminates the need to dotime-consuming network provisioning. Keep reading to learn how to integrate NSX with VMware AirWatch.

Next Level Per-App VPN

While per-app VPN addresses some of the security concerns ofdevice-level VPN, it still exposes all the domain’s endpoints and services to an application. In comparison,micro-segmentation takes endpoint management to the next level,restricting application-level access to a specified endpoint on the datacenter.

[Related: VMware AirWatch 101: Per-App VPN]

What is NSX Micro-Segmentation?

NSX micro-segmentation is a logical, bi-directional firewall thatmonitors inbound and outbound access controls for individual endpoints. It uses the NSX virtualization tool, making it a streamlined, cost-effective alternative to a physical firewall.

VMware AirWatch – NSX Integration Health Care Use Case

Considera doctor referencing patient health records from an enterprise health app.In this use case, only the health app, and not any of the device’s other applications, can establish a per-app VPN connection. Then, micro-segmentation dictates a designated endpoint for the health app. In this case, a patient database.

This level of restriction means that the healthcare app cannot access the e-mail server, an inventory database, or other unrelated services.The application’s assigned groups also mean that data access gets filtered on an employee level as well. Nurses, or doctors from a different department using the same health app cannot access the specifieddatabase without permission.

Additional Use Cases

  • Enhanced network security and granular controls for mobile workflows
  • Accelerated digital workspace and BYOD deployments
  • Policy defined network access for mobile apps and users
  • Reduced mobile access footprint to data center minimizing attack surface
  • Accelerated mobile app delivery, testing and automation

VMware AirWatch–NSX IntegrationSolution Overview

Starting with a sucessfully installed instance of NSX, sync the NSX Security Groups thatrepresent data center endpoints and services in the AirWatch Console. This actionsharesdatacenter logic with VMware AirWatch.Then,configure and installthe VMware Per-App Tunnel. This server establishes the secure connection between mobile applications and the network.Next, configure a Per-App VPN profile todirects managed applications to specified endpoints. Finally, configure applications.

VMware Tunnel Application

Device communication with the VMware Per-App Tunnel server goes through the VMware Tunnel application.Without this application, a per-app VPN connection cannot establish.Therefore, the VMware Tunnel Application is the most important application to configure and deploy.

The other applications you configure depend on the specific scenario and use case, but are generally the apps that end users accesses internal resources from. When configuring these apps, consider using Assignment Groupswithin AirWatch Console to control access on a user level.

Plan VMwareNSX Implementation

  • Determinethe types of devices accessing your network
  • Identify the endpoints (apps) in your network access.
  • Group applications by level of vulnerability/risk
  • Define the security requirements for each level of access.

InstallVMware NSXfor vSphere 6.1.x+

  • Designate a separate network range for each Security Level to identify incoming traffic
  • Define IP set-based Security Groups in NSX
  • Define internal resource based Security Groups in NSX
  • Determine firewall rules for Security Groups
  • Identify application endpoint addresses
  • Set traffic routing patterns

Meet VMware AirWatch–NSX Integration Requirements

  • AirWatch Admin Console v8.3+
  • AirWatch Tunnel server using the Linux Installer. The AirWatch Tunnel virtual appliance deployment method is currently not supported for NSX integration.
  • AirWatch Cloud Connector (For SaaS Customers)
  • Managed Android or iOS devices

VMware AirWatch – NSX Integration Steps

This post highlights the configurations most important for VMware AirWatch integration with NSX. For comprehensive instructions in AirWatch Console v9.1, click the suggested links.

Step 1: Configure and Download the VMware Per-App Tunnel for Linux Installer

To Configure VMware Tunnel , you need the details of the server where you plan to install. Before configuration determine the deployment model, hostname(s), port(s), and which VMware Tunnel features to implement.

Available VMware Tunnel Features:

Micro-Segmentation with NSX requiresNSX integration and installation of the Per-App VPN component. However, other configuration options remain. Available features include: access log integration, SSL offloading, enterprise certificate authority integration, and more.

Then, use the configuration wizard to go through the installer settings step-by-step. Next, download the installer from the AirWatch Console, for use during Linux server installation. Please note, changing the details in this wizard creates a new configuration, and requires a reinstall of the VMware Tunnel.

AirWatch Console Configurations:
  1. Navigate to Groups & Settings > All Settings > System > Enterprise Integration > VMware Tunnel > Network Accessibility.
  2. Select Enable AirWatch Tunnel.
  3. Click Enabled for NSX Communicationand provide the NSX Manager URL and Admin Username and Password.

4. Sync Security Groups and block all non-compliant devices from the same configuration screen.

5. Select Download Linux Installer. This button downloads a single TAR file used for deploying the relay and endpoints.

6. Select Save.

Step 2: Install VMware Per-App Tunnel with NSX Enabled

After meeting the VMware Tunnel for Linux System Requirements, configuring VMware Tunnel settings, and downloading the installer, begin installation. Run the installer on a Linux server, and enable the service.

During VMware Tunnel configuration, you specify whether you are installing in a multi-tier or single-tier configuration.

  • For multi-tier configurations, continue with the Install the AirWatchTunnel Front-End Server(Linux)steps.
  • For single-tier configurations Install the VMware Tunnel – Basic (Linux).

Important: After accepting the licensing agreement during installation, specifythe components to install. Enter 1to install Per-App Tunnel only.

Step 3: Create a Per-App VPN Profile

After configuring the VMware Tunnel server,Configure Per-App Tunnel Profile for iOS or Configure Per-App Tunnel Profile for Android.This profile enables specified applications to route HTTP(S) and TCP traffic through the VMware Per-App Tunnel. However, please note that the VPN profile can only take effect on devices with the VMware Tunnel application installed.

AirWatch Console Configurations
    1. Navigate to Devices > Profiles > List View > Add.
    2. Select the appropriate platform (iOS or Android).
    3. Configure a VPN Payload.
    4. Set the Connection Type to AirWatch Tunnel.
    5. Select the Per-App VPN Rules checkbox.

Step 4: Configure VMware Tunnel App

The VMware Tunnel application enables access to internal resources through managed applications. To Access the VMware Tunnel App for iOS or Access the VMware Tunnel App for Android end users must download and install the VMware Tunnel application from the App Store.

Step 5: Apply the Per-App VPN Profile and Security Group Mapping to Apps

After you create a per-app tunnel profile, Configure Public Apps to Use Per App Profile in the application configuration screen. This tells that application to use the defined VPNprofile when establishing connections.

On the application configuration screen, select the following options:

Learn More About VMware AirWatch – NSX Integration

To learn more about VMware NSX, check out the links below:

  • NSXproduct page
  • Next Generation Security with VMware AirWatch and NSX Integration Webinar
  • NSX Integration Hands On Lab(All Labs > AirWatch – NSX Integration)
  • VMware AirWatch and NSX Integration External FAQ
  • VMware AirWatch and VMware NSX Integration Guide

Because you liked this blog:

  • VMware NSX Micro-segmentation Day 1 Book Available!
  • New! VMware 2016 State of the Digital Workspace Report
  • Challenges & Benefits of Digital Workspace Transformation: Q&A with VMware&#rsquo;s Shankar Iyer

The post VMware AirWatch – NSX Integration appeared first on VMware End-User Computing Blog.

Read more..

vRealize Network Insight, NSX and Palo Alto Networks for micro-segmentation

 

Data Center cyber security is a fast-moving target where the IT teams need to constantly stay ahead of those that wish to do evil things. As security attacks can come from all directions, externally, and internally as well, the IT teams must fortify all the data, with a zero-trust security approach. Perimeter security augmented with intrusion detection and protection at the application level are the tools of choice for most data centers. This protects outsiders from getting in, as well as ensuring that the applications do not get impacted by a virus or other forms of malicious activities.

What has not been addressed is the intercommunications of applications amongst themselves, especially within the hypervisor layer, where virtual machines are communicating in an East-West traffic pattern. Traffic never hits the perimeter, and the conversations are happening several layers below the application layers where IDS sits. East-west traffic, from within the data center, has been an area overlooked as there is a gap organizationally. Simply put no one is paying attention to this area of vulnerability. The network infrastructure security teams are fortifying the perimeter, while the server teams are deploying IDS/IPS solutions. What has gone unnoticed is the East-West traffic that is flowing between virtual machines and the ease that an intruder could tap into these conversation, as there is little, to no firewalling, for denying access.

The VMware NSX Distributed Firewall (DFW) protects East-West L2-L4 traffic within the virtual data center. The DFW operates in the vSphere kernel and provides a firewall at the NIC of every VM. This enables micro-segmented, zero-trust networking with dynamic security policy leveraging the vCenter knowledge of VMs and applications to build policy rather than using IP or MAC addresses that may change. Tools for automation and orchestration as well as a rich set of APIs for partner and customer extensibility complete the toolset for security without impossible management overhead. While this is a dramatic improvement in the security posture of most data centers, layer 4 policies may not prevent malware or other threats that propagate via standard, likely permitted, protocols.

The NSX NetX API allows the insertion of 3rd party security services into the VM traffic flow, including streamlining their deployment and the sharing of security tags in order that security policy can still be dynamic. Palo Alto Networks integration with NSX automatically deploys a Palo Alto Next-Generation firewall to every host in a cluster then steers traffic to it within the host for inspection according to policy. Combining the high throughput DFW with the inspection depth of the App-ID and Threat prevention feature sets from Palo Alto Networks permits the blocking of malware and tunneled bad traffic while retaining the distributed nature of NSX traffic flow. Flows take an optimal path between VMs, remaining within the host where possible, delivering on the NSX objective of controlling lateral movement within the data center with micro-segmentation without becoming an administrative burden.Identifying legitimate East-West traffic is a key step to setup micro-segmentation in an existing data center.

VMware offers an analytic tool known as vRealize Network Insight (vRNI) for observing traffic conversations within the hypervisor. vRNI identifies and documents traffic flows, and provides suggested security policies which can be applied to both NSX and Palo Alto firewalls. vRNI analyzes IPFIX output from the Distributed Virtual Switch to provide suggested security policies and security groups. Additionally, including Palo Alto Networks either using existing production devices or during the planning phase of a deployment adding a device temporarily in tap mode, to provide more data for the assessment.The vRNI assessment results enable the addition of NSX based micro-segmentation and the Palo Alto Next-Generation firewall to a brownfield data center with confidence that existing application flows will not be erroneously blocked. The Palo Alto services can either be deployed as virtual appliances to give Threat and anti-malware protection to East-West traffic or hardware to protect North-South traffic at the edge of the data center.

 

Join us for an Upcoming Webinar:

Using vRNI to Visualize and Secure Your Data Center Virtual Network

Learn how to analyze traffic patterns non-disruptively within your production vSphere data centers, and how to use the vRNI assessment to fortify your data center virtual machines, with zero trust security and enforcement policies.

Speaker: Frank Snyder, Sr. Systems Engineer, VMware

Thursday, May 4, 2017 | 12:00pm - 1:00pm Central Time

Register today!

 

We also have a session at Palo Alto Networks Ignite:

Real World Perspectives on Implementing and Operationalizing Software Defined Security and Micro-Segmentation in Data Center and Cloud

Thursday, June 15, 1:30-2:20 PM

It&#rsquo;s 2017. Software continues to eat the world. Data centers are undergoing rapid transformation and becoming software-defined (SDDC). Workloads are moving to public clouds creating a hybrid environment for IT to manage. Amidst this sea change, Security continues to be the #1 priority and driver. Micro-segmentation has emerged as a clear winner among all security models to protecting next generation and cloud ready applications. A key obstacle to successful micro-segmentation is lack of visibility and operational readiness. In this session, we will have real world customers talk about how they overcame this obstacle and went about successfully implementing a SDDC. You will learn how they used VMware vRealize Network Insight (vRNI) platform to get pervasive visibility, high automation and efficient operations for their SDDC, built upon VMware NSX platform and Palo Alto Networks Firewalls.

Ignite registrants, click here to select your sessions.


To learn more about VMware NSX and Palo Alto Networks

  • Solution Brief
  • Watch our joint customer sessions from VMworld 2016 SEC10020 - Managing Cybersecurity Risks Within SDDC: VMware and Palo Alto Networks Customers Discuss Their Perspectives and Experiences with NSX and VM-Series Deployments
  • Test drive a free Hands-On-Lab (HOL)
    • Intro to vRealize Network Insight
    • Palo Alto Networks Next-Generation Security Platform with VMware NSX

The post vRealize Network Insight, NSX and Palo Alto Networks for micro-segmentation appeared first on Network Virtualization.

Read more..

MicroSegmentation of Applications using Application Rule Manager

Micro-Segmentation provides a way to build a zero-trust network - where all networks, perimeters and application are inherently untrusted.” - declared Forrester Consulting in 2015 with their white paper Leveraging Micro-Segmentation to build zero-trust model. The last mile in creating a truly zero-trust network impliesnot trusting each application andalso tiers within an application (Figure 1). To complete the last mile, network, security and risk professionals are increasingly looking for tools to understand application communication patterns and providing access controls to them. With version 6.3.0, NSX has unveiled 2 new tools, namely, Application Rule Manager (ARM) and Endpoint Monitoring (EM), to help professionals understand application patterns.

Figure 1: Zero-Trust Model using NSX

From Theory to Practice

Micro-Segmenting each application requires understanding of application communication patterns. Users should allow the flows required by the application. To accomplish zero-trust, users should be closing all unwanted flows & ports. Figure 2., is a samplepractical firewall policy model to achieve that. In this model, ARM/EM provides application patterns and a one-click conversion of those patterns into distributed firewall rules to achieve inter/intra application rules.

Figure 2: Firewall Policy Model

Generating Distributed Firewall RulesRapidly

Any application in thedatacenter can be put in a monitoring mode tocapture the raw 5-tuple flowin NSX. Application Rule Manager can auto-analyze these raw flows and provide an intelligent view of the patterns. These analyzed patterns can now be used to create distributedfirewall rules with one-click. Itcan be used with both new applications being on-boarded or existing applications that are already deployed. Bothallowed flows andblocked flows due to existing firewall rules. This helps in not just creating new firewall rules, but also enables you to analyze existing rules and change them for the application to work.

Analyzing what your application does in your datacenter and not just providing raw flows - makes Application Rule Manager very potent. It replaces raw IP addresses seen on the wire with actual VMs that the application is communicating to. It shows the details of the VMs - which Security Group it is part of, which Security Tags areattached with it. It understands the nature of flows not only in terms of the port and protocol but also ALGs (application level gateways) so that multiple flows consolidate to a single pattern. It auto-suppresses broadcast and multicast flows for targeted application level flows. And finally, it allows you to create Security Groups and Distributed Firewall Rules that can be published for that application.

EnhancedVisibility - with Endpoint Monitoring

We did not just stop at the wire for providing application patterns. NSX 6.3.0 introduces Endpoint Monitoring that goes a level deep into the nature of an application. It provides you a way to see processes inside a VM that are making network communications. With Endpoint Monitoring - you can see which processes are listening on which ports and which processes are making active connections. You can also see the details of the processes - for example - process name, application name, version number. In short you can go beyond the wire to construct your information as “A SQL client of version in VM1 is opening a network connection and communicating with a SQL server of version in VM2.

Figure 3: End to End Visibility

 

Application Rule Manager for real Applications

Users who had early access bits have been running this for a while. One user used ARM to micro-segment Skype Application. In 20 minutes of monitoring by ARM, the user saw 2.5K raw flows, which was analyzed by ARM and consolidated to around 300 unique flows. From there ARM, provided information that only 79 flows did not hit any existing firewall rules and finally the user created a very small set of firewall rules for those 79 flows. Another user, used ARM for micro-segmenting the entire Pivotal Cloud Foundry infrastructure. A user exclaimed with Endpoint monitoring, that he can now solve his current firewall ticket by providing the application owner - which process of his application is actually getting blocked due to distributed firewall.

We will provide you more stories as we hear them in the coming days of users using them and telling us. We encourage you all to tell us your experiences with the tool.And finally, a sneak preview if you would like to test-drive a new feature - see Layer 7 information about a flow - that will be released later this year in ARM/EM please contact me.

As I sign off for today - I am adding links to a you-tube video on how Application Rule Manager works, and a blog on ARM helped micro-segmentan application like a Electronic Medical Record (EMR) Application.

  • YouTube Videoon ARM
  • Practical Implementation using ARM of an EMR Application - Healthcare.

 

The post MicroSegmentation of Applications using Application Rule Manager appeared first on The Network Virtualization Blog.

Read more..

Application Rule Manager (ARM) Practical Implementation – Healthcare

This post originally appears as part of a series of VMware NSX in Healthcare blogs on Geoff Wilmington&#rsquo;s blog, vWilmo. To read more about VMware NSX and its applications in healthcare, check out Geoff&#rsquo;s blog series.

Originally this series on Micro-segmentation was only going to cover Log Insight, vRealize Network Insight (vRNI), and VMware NSX. With the release of VMware NSX 6.3, there is a new toolset within NSX that can be leveraged for quick micro-segmentation planning The Application Rule Manager (ARM) within NSX, provides a new way to help create security rulesets quickly for new or existing applications on a bigger scale than Log Insight, but smaller scale than vRNI. With that in mind, we&#rsquo;re going to take the previous post using Log Insight, and perform the same procedures with ARM in NSX to create our rulesets using the same basic methodologies.

The Application Rule Manager in VMware NSX leverages real-time flow information to discover the communications both in and out, and between an application workload so a security model can be built around the application. ARM can monitor up to 30 VMs in one session and have 5 sessions running at a time. The beauty of ARM is that it can correlate the information that you would typically have to either have or look up in Log Insight to create your rulesets and significantly reduces time to value. ARM can also show you blocked flows and the rules that are doing the blocking.

Let&#rsquo;s bring back our use case from the previous post and sub in, ARM instead.

Use case - Provide a Zero Trust security model around a Healthcare Organization&#rsquo;s EMR system. Facilitate only the necessary communications both to the application and between the components of the application.

  • Allow EMR Client Application to communicate with EMR Web/App Server
  • Allow EMR Web/App Server to communicate with EMR Database Server
  • Block any unknown communications except the actual application traffic and restrict access to the EMR application to only a Clinician Desktop system running the EMR Client Application.
  • Allow bi-directional communication between the Infrastructure Services and the entire EMR Application

Problem – The Healthcare organization does not have a clear understanding of how the application communicates within and outside the organization. Organization wants to lock down the EMR application so that only known good workstations can access.

Technology used -

Windows Clients:

  • Windows 10 – Clinician Desktop – Client-01a (192.168.0.36)
  • Windows 10 – HR Desktop – Client-02a (192.168.0.33)

VMware Products

  • vSphere
  • vCenter
  • NSX and Application Rule Manager

Application in question -

Open Source Healthcare Application:

  • OpenMRS – Open Source EMR system
    • Apache/PHP Web Server
    • MySQL Database Server

Infrastructure Services:

  • NTP

The first thing we need to do to utilize ARM is establish the VM&#rsquo;s that we&#rsquo;re going to look at the flows from. These systems will represent the session that we will build and run for a period of time to examine what flows are coming in and going out, and between these systems.

Talking with our applications team, we have determined that the VM&#rsquo;s in question are:

  • EMR-WEB-01a
  • EMR-DB-01a

Now that we know the names of the VM&#rsquo;s, we can go into the Flow Monitoring section of the NSX Management console and select Application Rule Manager. From here we can Start New Session.

We&#rsquo;ll select the VM&#rsquo;s we discussed above, EMR-WEB-01a and EMR-DB-01a, and we&#rsquo;ll add them to the session. This will start collection of flow data from the vNIC&#rsquo;s of these VM&#rsquo;s and post them in the View Flows table.

The amount of time that you collect flows for is up to you. My advice is the following:

  • Understand the application you&#rsquo;re planning for. If this application is a billing cycle application that does 30 day monthly cycles, ARM my not be the tool to use. ARM was built to monitor flows in real-time over the maximum of a 7-day period. If the application you&#rsquo;re looking at has periodic flows that occur over a longer period of time, I suggest using vRealize Network Insight for those applications. It has a longer retention period for looking up flows.
  • Keep the applications small. ARM has a 30 VM upper limit on monitoring of flows per session, with up to 5 sessions. While most applications may fall into this range, some applications may have more than 30 machines. In that case, my suggestion is breaking up the application into smaller chunks and running the chunks in different sessions to keep the numbers down.
  • ARM uses NSX Manager resources. Just like Flow Monitoring, ARM uses resources from the NSX Manager to collect flow data. Be careful of NSX Manager utilization during this process. Unlike Flow Monitoring, if you exit the interface, ARM will continue to run until you stop the session collection.

From here we will create a new session, calling it EMR Monitor, and add in our VM&#rsquo;s to the session. Once we hit OK, the collection will start and we can stop the collection when we&#rsquo;re comfortable with the period of time we collected for. In this instance, I&#rsquo;m going to collect data for 15 minutes. I have automated tasks running to provide traffic to the EMR so we can see flows that run every 5 minutes, so this should be long enough for this demonstration.

Once we have stopped the collection, we should see the View Flows table has several flows showing. ARM will attempt to de-duplicate repeated flows as much as possible. As you can see from the picture below, we went from 17 flows seen down to 7 unique flows total.

From here, we need to Analyze the flows. When you click on Analyze, ARM will attempt to correlate the flow information into VM names as necessary or IP addresses if the flows fall outside of the NSX environment. It will also attempt to resolve services that are being leveraged in that flow as well.

Now that ARM has analyzed our flow data and matched where it can we can see a few things:

  • Direction – This tells us in what direction the flow came to the source
    • IN – Inbound
    • OUT – Outbound
    • INTRA – Between
  • Source – Resolved to a VM name if the VM falls under the scope of the vCenter/NSX Manager relationship. If an IP address, represents an external IP system that is not resolvable in the vCenter/NSX Manager relationship.
  • Destination - Resolved to a VM name if the VM falls under the scope of the vCenter/NSX Manager relationship. If an IP address, represents an external IP system that is not resolvable in the vCenter/NSX Manager relationship.
  • Service – Resolved to all services that exist within NSX. If more than one service is shown, this means that the user will need to manually pick the service it correlates to because NSX has more than one service definition with that corresponding port number. If you want to create a custom Service or Service Group, which we will

With the information shown we have the following:

  • Inbound 192.168.0.99 > EMR-WEB-01a TCP 8080
    • 168.0.99 is identified as the Management Jumpbox for the infrastructure.
  • Outbound EMR-DB-01a > NTP-01a UDP 123
  • Outbound EMR-WEB-01a > NTP-01a UDP 123
  • Inbound 192.168.0.36 > EMR-WEB-01a TCP 8080
    • 168.0.36 is identified as the Clinician Desktop
  • Intra EMR-WEB-01a > EMR-DB-01a TCP 3306

From this view, we can start creating our Security Groups, IP Sets, and Services as necessary for our rule sets. But first, we need to establish our naming scheme and methodology to writing our rule sets. Below is a chart I use when creating my rules for the applications. It helps me lay things out logically and then apply it quickly in the DFW.

EMR Access Communications:

Name Source Destination Service Action Applied To
Clinician DT Access EMR-SG-ACCESS EMR-SG-WEB EMR-SVG-WEB Allow EMR-SG-WEB
MGMT DT Access EMR-SG-ACCESS EMR-SG-WEB EMR-SVG-WEB Allow EMR-SG-WEB

Intra-EMR Application Communications:

Name Source Destination Service Action Applied To
EMR Web to DB EMR-SG-WEB EMR-SG-DB EMR-SVG-DB Allow EMR-SG-WEB

EMR-SG-DB

Block All EMR Communications:

Name Source Destination Service Action Applied To
Block Inbound EMR EMR-SG-ALL Any Any Block EMR-SG-ALL
Block Outbound EMR Any EMR-SG-ALL Any Block EMR-SG-ALL

NSX Groupings:

Security Group SG-Contains SG-Inclusion Criteria
EMR-SG-ACCESS CLINIC-DT-IPSET (192.168.0.36)

MGMT-DT-IPSET (192.168.0.99)

Static
EMR-SG-WEB EMR-WEB-01a Static
EMR-SG-DB EMR-DB-01a Static
EMR-SG-ALL EMR-SG-WEB

EMR-SG-DB

Static

Service Group Service Included Port
EMR-SVG-WEB EMR-SV-8080 TCP 8080
EMR-SVG-DB EMR-SV-MYSQL TCP 3306

We also notice that the infrastructure services for NTP are showing up in our flows as well. We&#rsquo;ll need to account for these services, but we&#rsquo;ll put them in their own section as other applications may need access to those services as well. Below is the layout for the infrastructure services based on the groupings we created for the EMR above.

Infrastructure Access Communications:

Name Source Destination Service Action Applied To
EMR Access Infra EMR-SG-ALL INFRA-SG-ALL INFRA-SVG-ALL Allow EMR-SG-ALL

INFRA-SG-ALL

MGMT Access Infra MGMT-SG-ALL INFRA-SG-ALL MGMT-SVG-ALL Allow MGMT-SG-ALL

INFRA-SG-ALL

Block All Infrastructure Communications:

Name Source Destination Service Action Applied To
Block Inbound Infra INFRA-SG-ALL Any Any Block INFRA-SG-ALL
Block Outbound Infra Any INFRA-SG-ALL Any Block INFRA-SG-ALL

NSX Groupings:

Security Group SG-Contains SG-Inclusion Criteria
INFRA-SG-ALL INFRA-SG-NTP Static
INFRA-SG-NTP NTP-01a Static

Service Group Service Included Port
INFRA-SVG-ALL  

INFRA-SV-NTP

 

UDP 123

You will notice that I like to nest my Security, Services, and Groups. I do this because at scale, this makes changing things much simpler and more efficient. If I have to swap in a service or change a port, I want the changes to be reflected to all affected groupings down the table without having to seek out where else I might need to make a change. This has consequences as well, you must pay attention to what you&#rsquo;re doing when you make a change as it can have effect on other applications. This is why I name things the way I do, to ensure that any change you make that you understand the implications.

Now that we have all our custom services and naming convention in place, we can go back to the ARM and start resolving Services, Service Groups, and building out rules. We&#rsquo;re going to take these flows and squeeze them down even further to create very succinct rules with as few entries as possible.

The first thing we need to do is to create our Security Group structure that we defined above. We&#rsquo;ll start with the EMR servers and then do the Infrastructure systems. In the Source Field for the EMR-WEB-01a, we&#rsquo;re going to click the gear icon in the box and select &#lsquo;Create Security Group and Replace&#rsquo;

This will bring up the Security Group configuration dialogues and we&#rsquo;ll statically add the EMR-WEB-01a VM to the Security Group.

Once we complete this step, the View Flows section for the Source of EMR-WEB-01a will be replaced by the Security Group for EMR-SG-WEB.

We&#rsquo;ll repeat this process for all the rest of the VM&#rsquo;s that were resolved in the Flows and then we&#rsquo;ll deal with the IP addresses of the Jumpbox and Clinician Desktops. For repeated VM names where you&#rsquo;ve already created the Security Group, you can select &#lsquo;Add to existing Security Group and Replace&#rsquo; instead. This will bring up the Security Group memberships and allow you to choose the appropriate one.

We should look like this now.

For the IP addresses, since we&#rsquo;re not using VM&#rsquo;s themselves, we&#rsquo;ll need to create the IP Sets for each of these machines. Similar to how we created the Security Groups, above, we will create the IP Sets, and then the Security Groups, and replace the IP addresses with the EMR-SG-ACCESS Security Group with the IP Set&#rsquo;s in each. This will continue to follow our methodology similarly to how we did the VM&#rsquo;s.

Once we&#rsquo;re all done we should look like this now.

Now if you take a look at the results posted above, we could group a few of these Security Groups into ALL groups and narrow down our rules even further. For example, we have both the DB and the WEB systems talking to NTP. We could create an ALL group with both Security Groups inside, and remove one of the flows from the table. Here&#rsquo;s what we need to do. We&#rsquo;re going to pick one of the flows and select &#lsquo;Create Security Group and Replace&#rsquo;.

We&#rsquo;ll create the EMR-SG-ALL that we had in our table above. And we&#rsquo;ll add the EMR-SG-WEB and EMR-SG-DB which contains both servers into this ALL group.

Since we now have a Security Group that has both VM&#rsquo;s in it, we can hide one of the flow entries as it&#rsquo;s already covered in the EMR-SG-ALL Group.

We then hide the other unneeded entry and we&#rsquo;re getting closer to the minimum number of rules necessary to segment this application. As you can see we also have another set of Sources talking to the same Destination over the same protocol of TCP 8080. We can collapse these two flows as well.

We&#rsquo;re now left with the minimum flows and we can now resolve Services to our custom Services we were planning to create. This process is no different than what we did with the Security Groups and then putting them into an ALL Security Group. We&#rsquo;re going to create the custom Service, and then replace it with a Service Group with that custom Service inside it.

Repeating the process until we&#rsquo;re all done, nets us this final result.

With all of this work now done, we can go ahead and create our DFW rule sets. We&#rsquo;ll start with the Infrastructure Section and the associated rules. To create a rule from the View Flows table, we simply right click on the row and select &#lsquo;Create Rule&#rsquo;.

You&#rsquo;ll be prompted to put in a name and confirm the entries in the other lists. ARM will default to picking the vNIC&#rsquo;s of the VM&#rsquo;s in question. If you recall with Flow Monitoring, you have to specify a vNIC to capture flows from. ARM is taking that model and applying it here as well. The nice thing is is that you do not have to constrain the DFW rule to the vNIC of the VM. What you should do is change the &#lsquo;Applied To&#rsquo; field to the Source. We also need to change the &#lsquo;Direction&#rsquo; to Out instead of In/Out.

When you complete the rule build, you can select the &#lsquo;Firewall Rules&#rsquo; tab and see the new rule you just created.

We&#rsquo;re going to repeat this process for the other two flows as well.

Create a section for the EMR and publish the rules to the DFW.

Verify our results in the DFW interface.

We can now add our block rules to the DFW for the EMR application. Unless we specifically allowed the traffic to pass, we&#rsquo;re blocking all other communications.

Now we test our verification of our requirements:

  • Allow EMR Client Application to communicate with EMR Web/App Server
  • Allow EMR Web/App Server to communicate with EMR Database Server
  • Block any unknown communications except the actual application traffic and restrict access to the EMR application to only a Clinician Desktop system running the EMR Client Application.

 

When we attempt to access the EMR from the Jumpbox system, we can see that we&#rsquo;re getting prompted to login. This means that the Web and DB systems are talking to each other properly. Looking at Live Flows of the vNIC of the EMR-WEB-01a VM, we can see that we&#rsquo;re hitting the proper Firewall rule sets.

We can also see that the block rule is working as I attempt to access the EMR system from another workstation 192.168.0.18, and I&#rsquo;m getting blocked by the DFW. We just need to check access from the Clinician Desktop and verify working properly.

Looks like we&#rsquo;re fulfilling all the requirements so far. Time for our last check.

  • Allow bi-directional communication between the Infrastructure Services and the entire EMR Application

Here we have EMR-WEB-01a reaching out to the NTP server.

Here we have EMR-DB-01a reaching out to the NTP server.

As you can see, ARM is very adept at helping simply micro-segmentation with VMware NSX. Taking the concepts we learned and leveraged with Log Insight, we can remove quite a bit of manual processes involved with resolving services and VM&#rsquo;s IP addresses to their names. I was able to perform this process in about 15 minutes outside of flow capture time from start to finish and that&#rsquo;s what makes ARM another very useful toolset to use for reducing the complexity of micro-segmentation.


 

 

 

 

 

 

 

 

The post Application Rule Manager (ARM) Practical Implementation - Healthcare appeared first on The Network Virtualization Blog.

Read more..

Essential Elements of Micro-segmentation

The free Micro‐segmentation For Dummies®, VMware Special Editionebook by Lawrence Miller, CISSP, and Joshua Soto provides a broad overview of micro-segmentation, including how it can help you defend your data center from attack, automating security workflows, as well as steps to getting started.

But before you can get started, you need to understand the essential elements of micro-segmentation, which they explain in Chapter 2:

Micro-segmentation enables organizations to logically divide the data center into distinct security segments down to the individual workload level, and then define security controls and deliver services for each unique segment. This restricts an attacker&#rsquo;s ability to move laterally in the data center, even after the perimeter has been breached— much like safe deposit boxes in a bank vault protect the valuables of individual bank customers, even if the safe has been cracked….

…the network hypervisor is uniquely positioned to provide both context and isolation throughout the SDDC— not too close to the workload where it can be disabled by an attack, and not so far removed that it doesn&#rsquo;t have context into the workload. Thus, the network hypervisor is ideally suited to implement three key elements of micro-segmentation: persistence, ubiquity, and extensibility.

Download your free copy today.

The post Essential Elements of Micro-segmentation appeared first on VMware Education & Certification.

Read more..

Go Que Newsroom Categories

Fatal error: Allowed memory size of 67108864 bytes exhausted (tried to allocate 20 bytes)
in /home/content/36/8658336/html/goquecom/wp-includes/wp-db.php on line 2022

Query Monitor