Security professionals have probably noticed that containers, such as Docker and Rkt, as well as container orchestration — for example, Kubernetes — are gaining traction in a big way. This is because, as developers have discovered the power of microservices, they are moving away from monolithic or tightly coupled component design architectures and moving instead toward more decoupled models — i.e., models where REST is used as a layer of abstraction.

This offers several advantages from a developer point of view. First, it scopes out the implementation details of components communicating data from point A to point B. That’s a huge win already, but it also lets developers create versions of an interface, enabling them to add new functionality to an API in support of future development without the need to recode, recompile or alter the existing code base. This is one of the most powerful aspects from a development point of view of a microservices architecture — a software architecture strategy where functionality is modularized into small, discrete units of functionality, all accessible to each other through RESTful APIs.

As with anything, scale makes this complex. Imagine there are 500 RESTful APIs. Each API has a unique URL within the environment and is, more or less, agnostic about the underlying implementation details of the other services in the application that enables the overall application to function. Say, though, that either a broad change needs to be made to services en masse — for example, to enable TLS mutual authentication everywhere — or a targeted but disruptive change needs to be made to one service that affects the behavior of every other service — for example, changing the URL of an often-used service. Does every other service need to be changed? Do configuration changes need to be made to the containers those services are hosted on? These are exactly the kinds of things that microservices are designed to help prevent in the first place.

One technology that helps address the challenges in scale is service mesh. Service mesh introduces a method to enable changes to service operation without having to change underlying code. This is done usually using a sidecar proxy — i.e., a container image that lives next to the service that is responsible for directing traffic from that service. In this model, because services are talking through a proxy rather than communicating directly with each other, it provides a hook where designers can make changes to how that communication happens. Want to move services around? Sure, that can be done. Want to selectively turn off or on mutual authentication, rate limiting or HTTP headers? Those can be done too. And they can be completed without changing application code or the configuration of the container where the service lives.

New challenge: Threat modeling service mesh

These benefits turn the operations side of a service mesh deployment from a nightmare to something more manageable. However, it does have a byproduct of making application security analysts’ lives more complex due to challenges in threat modeling that come about when a static pathway through the application can no longer be presupposed.

For those unfamiliar with application threat modeling, the idea is to decompose an application into its components parts, look from an attacker’s point of view at the interaction points between those components and then systematically map out how specifically each interaction can be misused to gain leverage. To do this, security pros often start by making a data flow diagram — a document that maps out how data is sent through an application and the components it interacts with along the way. From there, security pros look at specific types of misuse cases that can affect each interaction. For example, each element could be systematically worked through a mnemonic threat model, such as STRIDE — spoofing, tampering, repudiation, information disclosure, denial of service, elevation of privilege — to determine how an attacker might target each component.

The challenge with this approach, however, is that under a microservices model generally — and service mesh specifically — the pathway through the application won’t stay static over time. An application may work a particular way today, but it might work differently two weeks from now — for example, having different security controls or talking to different APIs.

How to analyze service mesh

So, what can be done to perform application threat modeling in a microservices and service mesh environment?

One approach is to modularize the threat management process itself. Just as security teams would look in detail at component interactions from an attacker’s point of view with a monolithic application or tightly bound components in a traditional application, so too would they for each service in a mesh. The difference is that, instead of focusing solely on one pathway through the application and the components used to support it, security pros must look also at each service independently. This is for two reasons:

1. Because each service is nonstatic, meaning it can move or change context rapidly. For example, a service might be not accessible to the internet today — i.e., being used only by other pieces of the application and not directly by end users — and be exposed tomorrow.
2. Because doing so enables security teams to keep up as developers release new or updated services on a continual basis.

Looked at through this lens, threat modeling becomes even more useful in a microservices context than it already was. Decomposing the application is fairly easy to do — arguably easier than it would be otherwise — because services are already loosely coupled. Likewise, for shops that are pushing DevOps or continuous integration/continuous delivery, analysis is no longer a bottleneck since they don’t have to redo existing work when or if they release a new service.

To start threat modeling service mesh, begin by looking at each API in isolation, examining inputs, outputs and how they can be abused. Using STRIDE or another threat modeling methodology, examine and harden the service across each dimension. At the end of the process, there will be a small, hardened nugget of functionality about how an attacker might abuse the API, and resiliency will be increased.

It’s important to bear in mind there are advantages in evaluating the overall application, as well as looking at individual services in isolation, meaning doing this additively rather than entirely replacing full application decomposition. This might sound strange at first since interactions between services are expected to change rapidly over time. They will but looking at the overall flow has advantages, too. For example, it can help find and catch business logic errors that can affect security — for example, when input to one service is used and has ripple effects down the chain.

Threat modeling methods can and should be adapted for use in a microservices and service mesh architecture, even though service mesh changes the way that applications fit together. By looking at individual services in isolation, in addition to broader decomposition of the application overall, security pros can get better at accounting for changes in context, as well as streamline workloads.

The post Best practices for threat modeling service mesh, microservices appeared first on Artificial Intelligence.

In practicing data analytics for more than 30 years, and leading, advising, interviewing and teaching executives in many industries on data analytics for five years, I’ve observed that their approaches generally fall into one of five scenarios: two that typically fail, two that sometimes work partially, and one that has emerged as best. Let’s take a look at each:

1. We’re here to help — do you have any problems to solve?

This scenario often starts with the CEO (sometimes prompted by the board) deciding to hire a data scientist and establish a data analytics group. The data team sets out in the organization with great aspirations but without specific guidance to find business problems to solve. The data scientists, however, don’t have a practical understanding of the business, and the business leaders don’t know what, exactly, the data analysts are supposed to do or how to use them. As a senior executive of a very large enterprise said, “Our CEO hired a data scientist who reports to me, but I’m not sure what he does or what to do with him.” As the business leaders and the data scientists try to figure out how to relate, not much business value is created.

2. Boil the ocean.

Well-intended enthusiasm for putting data science to use can lead to overly ambitious aspirations to impact the entire company at once. The reality, however, particularly in large companies, is there are too many legacy data systems, too many practical issues, and too few people on the data science team to produce a significant business lift across the whole company in short order. Business results typically fall well short of high expectations. As an executive of a multinational European manufacturing company observed, “We’ve been at this for three years, and spent millions of euros, but we don’t have much to show for it.” In the end, not much business value is actually realized.

3. Let a thousand flowers bloom. 

The third scenario has promise: C-level leaders direct that data analytics should be adopted throughout the company. The practical use is left to the discretion of each business unit leader or function head. While data analytics gets grounded in and kept close to the business, much depends on if and how individual business heads choose to use it. Some embrace it and achieve significant results; others aren’t sure what to do or else avoid it. “Data analytics” often becomes just enhanced business reporting. Databases, systems and tools proliferate. With fragmented efforts, it is difficult to scale the resultant activities and determine how much business value is being created.

4. Three years and $10 million from now, it’s going to be great.

This rational approach is undertaken with all the right intentions — that data analytics can create business value, but require commitment, investment, and time. The problem is this approach typically results more in process than business outcomes. Often it involves a series of workshops, committees, and meetings that drag on without much to show for it. Multiyear investments are difficult to sustain without any business results in the face of competing budget demands and changing business conditions. A large industrial company, for example, has been planning, developing, and discussing their data analytics initiatives for years, but executives wonder where the effort is headed and when it will show business value. Despite a promising start, too much time passes without business results, and support wanes.

5. Start with high-leverage business problems.

Finally, the approach that works best: Identify a small number of “high-leverage” business problems that are tightly defined, promptly addressable, and will produce evident business value, and then focus on those to show business results. The specific business problem drives the team to identify the data needed and analytics to be used. Quick wins demonstrate business value. For example, a company that operates medical imaging clinics saw a high-leverage problem in patient “no shows.” The company set out to predict and reduce no-shows for the benefit of all involved: patients, doctors and technicians. Reducing “no shows” directly improves the bottom line. There’s no substitute for business results to build credibility for data analytics and sustain commitment.

Best Practices for Data Analytics

As we look across these scenarios, best practices become clear, including:

• Data science can’t happen in a silo. It must be tightly integrated into the business organization, operations and processes.
• There needs to be joint prioritization. Business leaders and data scientists should jointly decide which business problems to focus on. If there is any question about priority, the final call should go the business heads.
• Leaders need to be conversant in data science. Business leaders don’t need in-depth expertise in data science, but they require a basic, working understanding. Being conversant enables business leaders to work effectively with their data science teams.
• You may need to accept “inconvenient outcomes.” Data inevitably creates transparency and reveals business insights that can be unexpected, uncomfortable, and unwelcome. Data analytics will unearth inefficiencies and misconceptions that complicate leadership and disrupt conventional thinking. Business leaders who crush or ignore answers they don’t like will rapidly undercut the value of data analytics.

By observing the different approaches taken by a wide range of companies, we can see what works and what doesn’t to connect data analytics to creating real business value.  Because if your data analytics isn’t adding real value to the business, it’s not going to be successful or sustainable.

The post What’s the Best Approach to Data Analytics? appeared first on Artificial Intelligence.

Google this week made a case for moving beyond firewalls to secure microservices-based applications built using containers by sharing the best practices for a zero-trust networking model it relies on to secure its own web-scale IT environment.

Maya Kaczorowski, a product manager for Google, says Google makes extensive use of a BeyondProd framework, a cloud-native networking model that, among other things, ensures there is no inherent mutual trust between services and that chokepoints for consistent policy enforcement across services are created. Other concepts embedded into BeyondProd include mutually authenticated service endpoints, transport security, edge termination with global load balancing and denial of service protection, end-to-end code provenance and runtime sandboxing.

All the services Google provides run atop the Borg container orchestration engine, a pre-cursor to Kubernetes that Google still employs, on which BeyondProd is deployed.

BeyondProd is not intended to replace the need for firewalls as much as it is designed to augment them, says Kaczorowski. In fact, Google this week announced it has expanded its relationship with a dozen providers of cybersecurity platforms, including firewall providers Palo Alto Networks and Fortinet. It’s not at all clear, however, that any of the three major cloud platforms are all that much more secure than the other. In fact, just about every third-party cybersecurity vendor that supports Google Cloud also supports Amazon Web Services (AWS) and Microsoft Azure.

Google, like other cloud service providers, is highly committed to securing its own infrastructure. However, the security of the applications running on top of any cloud platform remain the responsibility of the IT team that deployed them. As IT teams increasingly embrace microservices-based applications, many are discovering that legacy approaches to securing applications are now insufficient.

Kaczorowski says Google is sharing how BeyondProd is constructed to encourage IT organizations to build their own zero-trust networking model for securing microservices-based applications.

The challenge many organizations will encounter in the months and years ahead is the need to deploy a zero-trust networking model across multiple clouds and on-premises IT environments that are likely to be running hundreds, if not thousands, of microservices. Unfortunately, most IT organizations are still struggling with how to secure monolithic applications on public clouds.

The highly dynamic nature of the containers that make up the bulk of the microservices being deployed presents organizations with a major challenge that in most cases will require them to define and adopt a range of best DevSecOps practices around a zero-trust networking model that needs to be continuously updated and managed. In many cases, roles surrounding who is responsible for building and deploying the zero-trust network across a team of cybersecurity and networking professionals have yet to be defined. Similarly, many organizations are still trying to determine to what degree developers will be held accountable for maintaining the security of their applications before and after they are deployed in a production environment.

Cybersecurity is likely to remain one of the biggest barriers of adoption when it comes to building and deploying cloud-native applications for the foreseeable future. The issue, however, is not so much the security of the cloud platforms being employed as much as it is the immaturity of the processes being employed to secure the applications running on those clouds

The post Google Shares Best Practices for Securing Microservices appeared first on Artificial Intelligence.

Artificial Intelligence and Machine Learning are all the rage right now. Many companies feel the pressure to invest in an AI strategy before fully understanding what they are aiming to achieve. We talked with JAX London speakers Sumanas Sarma and Rob Hinds about the different types of ML tasks, the most suitable programming language for ML, misconceptions and more.

JAXenter: Among the different types of ML tasks, a very important distinction is drawn between supervised and unsupervised learning. What is the difference between the two?

Sumanas Sarma & Rob Hinds: Supervised Learning and Unsupervised Learning are considered two of the fundamental categories of Machine Learning (or any type of statistical learning).

The post Machine Learning essentials: Best practices, categories and misconceptions appeared first on Artificial Intelligence.