Easing the Tension between Convenience and Security

Within my work and outside of it, I am consistently reminded of the inherent tension between convenience and security. The easier something is to use, inevitably the less secure, and vice-versa. It’s like a seesaw: the more you have of one, the less you have of the other.

Nowhere is this tension more apparent than with enterprise security software, which is notoriously painful to use, not to mention install, configure, maintain, support, upgrade, document, train, etc.

While commercial security products are crucial to the enterprise, it’s often at the expense of those left to do the dirty work of actually using the product the CISO bought.

Many of my colleagues here at ShiftLeft have blogged about our technical innovations to help companies secure their cloud-native workloads. Our engineering team is laser-focused on modernizing application security for the cloud, building something that has never been built before.

But ShiftLeft is also quietly innovating in another important way: developing an enterprise software security platform that is…truly easy-to-use.

Yep, I said it. An enterprise security platform that is user-friendly. Even if you have not used a legacy security product, it’s foreseeable you will have doubts. So, what I want to do here is describe and demonstrate how ShiftLeft is easing the inherent tension between security and convenience by creating a platform that will be an important ally in any CISO’s security tool chest, while also be easy-to-use for those who are tasked with doing so.

Building a Security Product that is Easy to Use

Building a user-friendly enterprise security platform is not easy. Going the last mile takes hard work, abundant patience, and constant vigilance, and if you haven’t laid the groundwork, good luck.

Here’s what we are doing at ShiftLeft to create an innovative, enterprise-class security product that is easy to use:

  • Cloud-based service
  • Simple integration points
  • Integrated workflow
  • Intuitive dashboard
  • Simple policy language
  • Optimized runtime agent
  • Dedicated UX culture

Cloud Service

ShiftLeft is a cloud-based security service that helps protect applications by creating a comprehensive security profile and enforcing that profile at runtime using a lightweight agent.

Because ShiftLeft is a SaaS application, you are immediately relieved of three major pain points that afflict traditional enterprise security software: installation, maintenance, and upgrade. The ShiftLeft cloud-based service model ensures that new code is deployed quickly to add features and fix bugs, upgrades that you don’t have to deal with anymore.

Upgrade horror stories are a dime-a-dozen, and when it comes to enterprise security products, maintenance can be especially harrowing. As we enter 2018, there is little reason not to leverage the cloud for application security.

The ShiftLeft cloud service provides a single-tenant environment for your organization; it is not a multi-tenancy. For your organization we create an isolated VPC environment and VPN for processing and storing all customer assets. We use end-to-end encryption for all data, and provide you with a single, controlled access point to your data.

Simple Integration Points

There are two integration points with ShiftLeft: build and runtime.

At build-time you include a single shell command in your CI/CD pipeline that automates ShiftLeft security analysis and profiling for each target application build.

At runtime you deploy the ShiftLeft Microagent with the application for streaming metrics and monitoring.

And that’s all you have to do to integrate with ShiftLeft. The only tool you need to install is the the ShiftLeft CLI. It prepares and uploads security metadata and bytecode for analysis, and downloads and runs the latest ShiftLeft Microagent with your application. The CLI plugs in seamlessly with any existing build automation framework, whether commercial or custom. In terms of runtime monitoring, there is nothing to install. Your code remains separate from and unchanged by the microagent.

Integrated Workflow

The ShiftLeft CLI is the only tool you need to integrate with ShiftLeft.

The SL CLI has three simple commands: auth, analyze, and run. It is supported on Linux, Mac, and Windows.

You install the CLI by placing the sl binary in your path, then run sl help to verify installation and view usage details.

sl auth

The sl auth command authenticates you with your organization in ShiftLeft. To to do so you provide your Org ID and Token. Once authenticated the applications you submit for analysis will be associated with your organization. When you log in to the ShiftLeft Dashboard, you see all the applications associated with your organization.

You can configure two types of users in ShiftLeft: administrators and collaborators. Both can view the applications in the organization, and admins can invite others to join the organization, and define their role.

sl analyze

Once authenticated the next step is to analyze the code. Code analysis and policy application is done in the ShiftLeft cloud. The CLI prepares the code for analysis by packaging it up and submitting it to the service via HTTPS. The code analysis pipeline results in a detailed security profile of the application.

A question often arises, what are we sending to the cloud? You have two options: The base command sl analyze submits application bytecode for both proprietary and open-source code. Using the — — cpg flag generates and uploads security metadata for proprietary code (in lieu of bytecode).

Which option you choose depends on your business requirements. If are concerned about uploading proprietary bytecode to the secure ShiftLeft cloud, use the flag.

Note that you don’t have to specify the application JAR. As long as it uses a supported build tool (Maven, Gradle, SBT), the CLI will detect the application bytecode and process it.

sl run

This sl run command targeted at the application runtime deploys the latest version of the ShiftLeft Microagent with the application for monitoring and metrics. Or, if you prefer, you can run the microagent standalone using a single Java command. Using the CLI to run the microagent ensures that you are always running the latest version.

And that’s it! With these simple commands you can integrate ShiftLeft with your CI/CD environment of choice and automate application security end-to-end.

Intuitive Dashboard

The ShiftLeft Dashboard aspires to the principle often espoused by the likes of Steve Jobs and Elon Musk, that is, it shouldn’t need documentation to use.

The ShiftLeft Dashboard tells you everything you need to know about the security posture of your application. We focus on what’s important: sensitive data and the vulnerabilities it may be subject to. The layout shows the ingress and egress points of this critical data for your application.

What you see in the dashboard is security profile for the application, what we call “Security DNA.” Each area of the UI is filterable, so you can drill into what you want to see. In this regard our dashboard endeavors to be similar to using a good housing search tool. You don’t have to read documentation to filter results using these tools, so why should you to understand your own code?

Simple Policy Language

This is my favorite area to highlight ShiftLeft ease-of-use because I have seen my share of policy disasters. Here’s a couple rules of thumb I have picked up along the way. If you overhear negative comments from DevOps folks, chances are your policy language isn’t great. And, if a highly technical employee of the company that developed the policy language is able to wipe himself and his whole team from access to the system during a client demo with a single typo, you may want to rethink the policy administration burdens you have forced mere mortals to overcome.

When it comes to policy-based systems for enterprise security products, it all comes down to the language (or syntax or grammar if you prefer). Policy that expects too much from the user in this regard may fail to be used (bad) or be unmaintainable (worse). Policy needs to be straightforward to use out-of-the-box, easily extended and customized, never brittle or tough to change, and of course secured with proper levels of encryption and access control.

Many vendors have failed at providing good policy experience because they created policy languages rife with jargon, idiosyncrasies, and steep learning curves. Here’s another rule of thumb for policy: folks shouldn’t need X days of training and X weeks/months of practice to master your policy language. They have too much to do already. It’s not all bad, though. A vendor who I think has done a relatively good job in this regard is Amazon’s policy language for IAM (functional UI, wide-selection of policy templates, standard format, extensible, stored in the cloud).

The ShiftLeft policy language is influenced by Docker, specifically the Dockerfile format. ShfitLeft policy is a *.policy text file that looks like this:

IMPORT default.policy

# Comment
INSTRUCTION arguments

Out-of-the-box we provide default policy to classify vulnerabilities and identify and tag sensitive data variables and their method flow in and out of the application. The policy syntax is easily understood within seconds of viewing the policy. We provide a base instruction set (such as vulnerability categories, sensitive data types, and transformations), and you can extend policy by adding your own instructions. In your policy you can add methods and data types specific to your code that you want to track and monitor.

ShiftLeft policy is chained by creating your own policy that references other policy (such as default, as shown above). Our simplicity here should not be overlooked because policy chaining is a feature people love to overthink. Put it this way, if you allow forward and backward chaining, for both rules and exceptions, across content, context, and identity, don’t be surprised when customers create policy matrices so complex your policy engine chokes under load. If your policy language does what it is supposed to do, you should not need to give your users this many ways to shoot themselves in the foot.

Over time as we add support for different languages, ShiftLeft intends to provide default policy for major verticals so that policy customization is a seldom used option. And, although we are not yet exposing policy to the user, we have laid the groundwork for an intuitive experience by creating a simple policy language that is easy to understand, implement, maintain and extend.

Optimized Runtime Agent

The ShiftLeft Microagent is lightweight and runs in parallel with your application. You do not have to modify your application code to instrument it Instrumentation is done via the security profile for runtime (SPR) that is downloaded by the microagent. With the microagent running we can detect incidents (violations in the code we see at runtime) and alert on them.

All agent communications are over HTTPS via a proxy that runs in our cloud or yours (even on-prem if you prefer). The microagent batches metrics and events before sending them to the proxy, and the proxy aggregates the data before sending it to the ShiftLeft gateway. The microagent provides three configuration options (JSON, Java properties, environment variables) with a wide range of settings for tuning security and logging levels.

Legacy security products provide agents of all types, often with mixed results, including crashing, hogging resources, and inconsistent features across operating systems. Our microagent derives from the APM-style of agent, such as New Relic and Sumo Logic, which we test with to ensure compatibility.

Dedicated UX Culture

Last but not least is the team of engineers ShiftLeft has assembled who believe passionately about providing a world-class user experience.

It is easy to pay lip service to UX, and product managers can plan all they want, but if the engineers building the platform do not care about user experience, no amount of UI gloss can overcome it. Hard technical decisions are constantly being made by engineers, sometimes as a team but often individually. If there are shortcuts taken at lower-levels of the product, technical debt will mount and eventually surface as poor user experience. Good UX is ultimately won in the trenches.

At ShiftLeft the engineering culture is all about the customer experience. It is our watchword. When hard decisions have to be made, individually and collectively we always choose the route that will ultimately yield the better user experience, even though this often means more work and time.

We have formal weekly sessions where we all gather (engineering, product, sales) and experience the product as a customer would, filing bugs and enhancements and refining the end-to-end user experience. We are users of the product, and it is always a very eye-opening and educational endeavor.

We also run monthly customer advisory board meetings where our executive team listens to key customers and early adopters about the features they want to see in the product. And we don’t dogfood in vain. We actually use what we build to secure our own code base.

Demo

Want to see ShiftLeft in action? Checkout this quick demo that shows how easy it is to integrate with ShiftLeft and secure your applications.

Conclusion

We might be inclined to think of UX as a journey. But in fact it’s not because there is no destination. You can never achieve UX nirvana; there is always room to improve.

As ShiftLeft rethinks application security for the cloud, we are focused on building a world-class enterprise security product that is simple to use. We are laying the groundwork for an innovative UX when it comes to security, and will continually improve and evolve the experience for our customers.

To learn more about ShiftLeft, checkout out our website and request a demo.


Easing the Tension between Convenience and Security was originally published in ShiftLeft Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

This is a Security Bloggers Network syndicated blog post authored by Lorenzo Paris. Read the original post at: ShiftLeft Blog - Medium