Open-Source code requires the next iteration of Zero Trust

Vishwas Manral, CEO, Founder of NanoSec Co.

The key factors often sighted 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 moribund 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.

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 the next iteration in the Zero-Trust model. The Zero Trust model now needs to be applied not just to endpoints, users and applications, but needs to be brought down to nano-units of applications; processes and components

A new alternate approach to Zero-trust is necessary for the open source model of applications. This 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.