Multi-Cloud security challenges
- Feedback from practitioners

Vishwas Manral, CEO, Founder of NanoSec Co.

This blog consolidates the feedback, we got from a diverse set of practitioners. We will have detailed blogs from individual practitioners as we move forward.

As the CEO of NanoSec, a company focused on revolutionizing how organizations secure applications and critical business assets, I spend a lot of time working with enterprises that are developing and adopting new cloud-native applications, and in turn diverse hybrid infrastructures, at an ever-growing pace. With a lot of business value still trapped in legacy applications, however, those applications aren't going away any time soon. With such diverse and fast changing infrastructure, enterprises are now staring at a multi-cloud reality.

Adopting a multi-cloud approach to enterprise IT can provide long-term strategic benefits such as reduced pricing risk, reduced risk of service disruption, increased business agility, and the ability to deliver capabilities beyond what’s possible with a single cloud. These benefits don’t come for free however, as enterprises face a host of significant challenges securing these new multi-cloud architectures.

The key challenges enterprises face are:

Complexity managing disparate security tools
Security budgets have expanded and more security tools are now adopted by Enterprises. There are now way too many tools to manage even in a single environment, all with disparate dashboards, alerts, databases and systems. The complexity is greatly increasing in the multi-cloud world.

Speed of deployment
All security tools are designed to secure a single enterprise domain/ private cloud and are not multi-cloud aware. There are a different set of tools, databases, data lakes for different environments. Deploying applications in such diverse environments leads to lag in application deployment times – with so many different people, processes and products involved.

Risk with shared responsibility
In cloud environments, there is a model of shared security responsibilities. In regulated industries there are still concerns about cloud provider insider threats i.e. collusion between a couple of Cloud Provider admins and getting hold of sensitive data. It is extremely hard to get complete transparency into admin logs of CSP's.

Threat landscapes are also changing quickly. In the face of more sophisticated attacks, a more streamlined model of security is needed. Diverse tools lead to different processes and responsibilities, leading to gaps greatly magnifying the risk.

Vendor lockin
No Enterprise wants to be locked into a single cloud provider. However, with challenges around getting to business faster being top priority and the unavailability of tools, Enterprises are often having to compromise on this factor.

Skills and resource shortage
The cloud trend has lead to security teams being stretched and overwhelmed. There is a severe lack of understanding of the various tooling and infrastructures. There is now a severe skills gap.

What is needed Multi-cloud/ Hybrid-cloud tooling is now essential for enterprises. Tools that can span infrastructures, geographies and provide a more integrated view of security are required.
NanoSec is one such product that works in the Hybrid Cloud, across infrastructures and application types, while still being easy to manage and integrate with existing and modern environments.

Author: Vishwas Manral is the CEO and founder of NanoSec. He was earlier the founder of Ionos Networks and a Chief Technologist - responsible for the vision, direction and roadmap of over $250M of products. He has written over 30 RFC's including standards like IPsec, ADVPN etc

Disclaimer: Any views or opinions represented in this blog are personal and belong solely to the blog owner and do not represent in any way those of people, institutions or organizations that the owner may or may not be associated with in a current or prior professional or personal capacity, unless explicitly stated.

All content provided in this blog is for informational purposes only. The author of this blog makes no representations as to the accuracy or completeness of any information on this site or found by following any link on this site. The author will not be liable for any errors or omissions in this information nor for the availability of this information. The author will not be liable for any losses, injuries, or damages from the display or use of this information.


Open-Source code requires the next iteration of Zero Trust

Vishwas Manral, CEO, Founder of NanoSec Co.

The key factors often cited for the fast diminishing value of Perimeter security is the advent of the cloud and the mobilization of the workforce. One big factor often overlooked that further diminishes the value of the perimeter is the very broad and fast adoption of open source software. Open source enables business to develop new applications fast but it also greatly adds risk. These risks arise due to short release cycles using unknown third party libraries, malpractices by adversarial developers who can push malicious code, well published vulnerabilities and others. The latest such vulnerability was discovered in jQuery plugin that was exploited for atleast 3 years by adversaries.

While there has been a broad adoption of Open source software, the percentage of open source components even in proprietary applications has been on the rise. According to Blackduck On-demand Audit Services group, 96 percent of the scanned proprietary applications contain open-source components, with an average 257 components per application.

The Zero Trust model first introduced by Forrester Research, works on an assumption that any component irrespective of where it resides with respect to the perimeter is untrusted and can be malicious. It works on a model of “always verify, as if untrusted”.

The vast adoption of open source needs a new iteration in the Zero-Trust model, applied not just to endpoints, users and applications, but down to nano-units of applications; processes and components

This new approach to Zero-trust is necessary for the open source model of applications and relies on implementing an application process identity-centric zero trust model. One that provides granular contextual visibility and behavioral nano-segmentation at the application process level, and control and reporting on all application and system level process interactions. This solution would provide instant insights, visibility and control, allowing intended legitimate process flows and prevent backdoors that may be in the open source software. This provides a new dimension to application security in QA/Dev and production environments.

NanoSec brings a nano-segmentation approach to Application Security, by understanding the behavior of every process, of every component of any application. NanoSec then models the behavior to identify normal and deviations from the model to detect anomalies and prevent attacks. NanoSec is able to identify and stop any command and control communication in the open source software that may otherwise go undetected, or prevent lateral movement in case of compromised components.
Based on the opensource vulnerability, Nanosec would be able to maintain appropriate security posture with compensating controls thus allowing your security/SecDevOps organization adequate time to do a more thorough check/test of the vulnerability before deploying a patch remedy as opposed to blindly applying the patch code. You may read and explore more at www.nanosec.io

Author: Vishwas Manral is the CEO and founder of NanoSec. He was earlier the founder of Ionos Networks and a Chief Technologist - responsible for the vision, direction and roadmap of over $250M of products. He has written over 30 RFC's including standards like IPsec, ADVPN etc

Disclaimer: Any views or opinions represented in this blog are personal and belong solely to the blog owner and do not represent in any way those of people, institutions or organizations that the owner may or may not be associated with in a current or prior professional or personal capacity, unless explicitly stated.

All content provided in this blog is for informational purposes only. The author of this blog makes no representations as to the accuracy or completeness of any information on this site or found by following any link on this site. The author will not be liable for any errors or omissions in this information nor for the availability of this information. The author will not be liable for any losses, injuries, or damages from the display or use of this information.


Cyber Security Low Bar : If Google search finds it,
then Blockchain won't solve it

David Giambruno, CIO/ CTO/ Cyber Security CISO / Transformations

This blog is extracted from an earlier post on Linkedin by David Giambruno

CEO of NanoSec, Vishwas Manral tried using Google while researching breaches. After all every nerd’s response to someone is "Google it" - might as well give it a shot. BTW, NanoSec provides deep security, monitoring and visibility tools.

Being savvy, he asked himself what would get indexed by Google from a security perspective? Keys, CRLs & Certificates and other cryptographic material.

What this is basically asking: Are people storing their Private keys & Certificates on unsecured servers and exposing it to the world?

In roughly 60 minutes, he found many companies (Large & Small) had their Private Keys, in the clear, on the Internet. Examples:

     1) Big Service Provider in Pacific Rim
     2) Large Telco in Pacific Rim
     3) State's EBT service
     4) Big Open Source software vendor

What this means is that any of these companies could be impersonated on many dimensions.

Vishwas, reached out to me for help getting hold of people to get the system’s secured was challenging. Using my Rolodex I reached out to people to get the issues fixed where I had contacts.

So, if anyone thinks Blockchain is the ultimate answer for security, when you cannot even secure your Private keys.... you'd be wrong.

NanoSec solution is designed to work with an assumption of breach. It protects from both known and unknown attacks by inverting the model of security. Instead of being focused on threats the solution works by accumulating a deep behavioral understanding of applications and their communication patterns. You may read and explore more at NanoSec product.

Author: David Giambruno builds Fortune 500 companies and other organizations as a CIO / CTO / CISO and Consultant who streamlines processes and increases revenues through leadership and strategic planning.

Disclaimer: Any views or opinions represented in this blog are personal and belong solely to the blog owner and do not represent in any way those of people, institutions or organizations that the owner may or may not be associated with in a current or prior professional or personal capacity, unless explicitly stated.

All content provided in this blog is for informational purposes only. The author of this blog makes no representations as to the accuracy or completeness of any information on this site or found by following any link on this site. The author will not be liable for any errors or omissions in this information nor for the availability of this information. The author will not be liable for any losses, injuries, or damages from the display or use of this information.


A NEW ERA FOR SECDEVOPS AND APPLICATION SECURITY,
IT’S TIME TO CHANGE THE STATUS QUO

Conrad Menezes, ex-SVP Bank of America

Major security breaches making news headlines seem to be the norm in current times. These breaches occur in stark contrast to the plethora of security tools and platforms deployed from a security perspective. These tool and platform security posture capabilities, when combined with a robust application security practice entailing static & dynamic application source code analysis, penetration testing, vulnerability scans and pursuant to all applicable code changes, should as an expected outcome and at the very least equate to a “breach resistant” state for each of the applications under scrutiny. Which begs the question, why do we still continue to see application breaches?

In today’s demanding business environments with agile SecDevOps and continuous integration/continuous delivery, it is likely that the above outlined security practice around deploying secure applications and subsequent iterative application code updates to get to a secure application state either get bypassed or overlooked as, more often than not, time to market, not security, dictates deployment schedules. This may well be caused by an over reliance on segmentation, Access Control Lists (ACLs) and associated network security tools.

Let’s talk about segmentation and ACLs, both of which are not new security constructs in the network world. Fundamentally, segmentation done at Layer 2 (VLAN) or Layer 3 (IP) affects areas, zones of traffic isolation while static ACLs either allow or prevent traffic reachability between these isolated zones. This aspect of network segmentation and static ACLs have received heightened coverage in recent times and based on reported breaches that allowed free omnidirectional network reign to malicious actors and their activities. However, this technique is a traditional legacy approach to security.

This type of basic blocking and tackling works well when an application and its processes function solely within the intended realms of application code functionality, inclusive of all process interactions with other applications and systems. However, if any of the application processes spawn, invoke and/or interact with “unintended” yet “legitimate” external applications, processes including authentication/Single Sign On, then this legitimate traffic is simply allowed to pass across traditional security mechanisms of network segmentation, ACLs, firewalls and IPS/IDS. In most cases, these “unintended legitimate” interactions will go undetected until such time network activity across these monitored zones reach abnormal peaks and is subsequently picked up by traffic monitors and subsequent alerting, reporting. By this time, it’s usually too late!

A new alternate approach is required, one that provides granular contextual visibility and behavioral segmentation at the application process level, and control and reporting on all application and system level process interactions. This solution would provide instant insight, visibility and control, allowing intended legitimate application process flows while preventing unintended legitimate application process flows, thus giving new meaning to “breach resistance” in QA/Dev and production environments.

NanoSec brings precisely this innovative approach to SecDevOps teams at firms that are application security focused, time conscious and desiring of a deep actionable visual pane not easily reflected by traditional security tools and platforms. You may read and explore more at www.nanosec.io

Author: Conrad Menezes is currently an independent consultant, executive in transition having served in technical leadership CTO, CISO roles at Fortune 100 firms over the last two decades.

Disclaimer: Any views or opinions represented in this blog are personal and belong solely to the blog owner and do not represent in any way those of people, institutions or organizations that the owner may or may not be associated with in a current or prior professional or personal capacity, unless explicitly stated.

All content provided in this blog is for informational purposes only. The author of this blog makes no representations as to the accuracy or completeness of any information on this site or found by following any link on this site. The author will not be liable for any errors or omissions in this information nor for the availability of this information. The author will not be liable for any losses, injuries, or damages from the display or use of this information.