I made this mock CLI tool, inspired by the original Stanford Startup Engineering Class via Coursera

Startup Security Engineering: It’s Not About Failing Fast

This article was originally published last February, 2015 as a two-part blog at LinkedIn Pulse Information Privacy and Security Channel

“Failing fast” in Lean Startup speak is the ability to determine and abandon ideas that are not working at the early stage of your startup. However, failing fast in the context of security engineering alone is not good, especially if your Minimum Viable Product (MVP) is storing a considerable amount of Personally Identifiable Information (PII). The worst thing that can happen to you as a founder is finding a dump of your customer’s database in pastebin.com, and circulating the industry via Twitter, the day after your launch.

Backlash from your investors are the least your problems. Once you start providing customers with an app that helps solve their problem and you store their data as a part of the service, you now have a moral responsibility to protect their data.

The worst thing that can happen to you as a founder is finding a dump of your customer’s database in pastebin.com, and circulating the industry via Twitter, the day after you launched.

If your app fails fast in the context of security it means the confidentiality, integrity and availability of your app can be easily circumvented; intentionally or unintentionally. A break in confidentiality is when unauthorized users can view data that they are not supposed to see. A break in integrity means data residing in your app can easily be modified while stored or in transit. A break in availability is when legitimate users cannot access your app when they need it. These are the foundations of security that a founder must prioritize in building her MVP.

Instead of failing fast you should design your app to be resilient even before the first lines of code are written. This can be achieved by starting with well-crafted User Stories, and demonstrated visually through low-fidelity prototypes. One doesn’t need to be a coder to participate in these exercises. A security engineer can easily explain the purpose of the feature using paper prototypes in front of developers and product managers. The “Persona” you are building for are bad-guys who wants to break the app.

Majority of developers are smart and highly technical, capable of thinking outside the box to solve problems. Unfortunately not all of them are security savvy. This is where you play an integral part as a security leader for your startup. Before you introduce new security tools to your development team, best to send them to foundational security training.

By learning the techniques on how software gets owned or compromised by bad guys, and how to protect software from these attacks, developers will be more security conscious on every line of code they write.

Developers will be more conscious to ensure the function they plan to use is not deprecated or vulnerable, they will ensure that they are using updated third-party libraries and vulnerability-free, and they will understand the importance of conducting static and dynamic security analysis on the codebase and application before it gets deployed in production.

By learning the techniques on how software gets owned or compromised by bad guys, and how to protect software from these attacks, developers will be more security conscious on every line of code they write.

There is a plethora of quality and free training videos on the web focusing on software development security. However, I do have a Top 3 List of resources.

Currently there are only four videos but still an excellent introduction to the world of web app security. Each video is approximately 5–10 minutes long and highlights one or more specific application security concepts, tools, or methodologies. The goal of the project is quite simple and yet quite audacious — provide top-notch application security video based training… for free!

This is my current favorite resource. Not only the videos are of high quality, the training videos also go beyond web app security. It has a training video for Secure Java Programming 101, and also a training video for Product Penetration Testing 101. Not to mention the excellent materials available on SAFECode.org on how to integrate Security in your Agile Software Development environment.

Coursera doesn’t need a lengthy introduction, some of the world’s best courses, online, for free. They do have a couple of quality and up-to-date free courses for security engineering. My personal favorites are the Cryptography courses from Stanford, and the Usable Security course from University of Maryland.

Now that your team is properly introduced to the concepts of security engineering through training, they can now further sharpen their axes in practice by using tools that are highly vetted by the security community to help discover, track and remediate vulnerabilities in the code or in the infrastructure.

Assuming the MVP is a web app using Ruby/Ruby on Rails, here are some tools that I highly recommend.

This is my favorite tool. Easy installation and zero configurations. A lot of startups are running Ruby on Rails framework for their MVP, knowing how to use this tool is really handy in your career as a security professional.

Brakeman is an open source vulnerability scanner specifically designed for Ruby on Rails applications. It statically analyzes Rails application code to find security issues at any stage of the development. Of course it is still prone to false positives like other static analyzers, this is why as a best practice, a code walkthrough by the developer with the security professional is the best way to verify potential vulnerabilities in code.

You can easily add it to your Rails Application via RubyGems by issuing the command below:

gem install brakeman

Then go to the root directory of your Rails app and simply run it by issuing the command:

brakeman

The results of the scan can easily be exported in TEXT, HTML, JSON or CSV. I always go with the HTML report:

a code walkthrough by the developer with the security engineer is the best way to verify potential vulnerabilities in code.

Having Jenkins in your software development process will give you a solid foundation in integrating security in your agile software development lifecycle.

Jenkins automate the non-human part of the whole software development process, with now common things like continuous integration, but by further empowering teams to implement the technical part of a Continuous Delivery.

It provides hundreds of plugins to support building, deploying and automating any project, including the security plugins we need.

A plugin for Brakeman is available so you can integrate static source code security analysis in your Continuous Delivery Pipeline.

The next Jenkins security plugin I highly recommend to use is the “OWASP Zed Attack Proxy Jenkins Plugin”. It can help you automatically find security vulnerabilities in your web app MVP during development and testing.

The last Jenkins security plugin that I highly recommend is the “OWASP Dependency-Check Plugin” This plugin will scan for any vulnerable open source software dependency or third-party libraries you are using in your MVP.

Monitoring the third-party libraries you are using is very important, not only for security purposes but to manage the technical debt of your MVP.

When you are building things too fast just to meet a release date, we often forget about our software bill of materials — a detailed inventory of resources your MVP requires to function. Are the libraries up-to-date? Do not blindly trust code you acquire via RubyGems.org, NPM or from Github in general.

So let’s summarize what we have so far:

  • We are using Jenkins to automate our software build and deployment process.
  • We are using Brakeman Jenkins Plugin to conduct static source code security analysis of our Ruby on Rails MVP
  • We are using OWASP Zed Attack Proxy Jenkins Plugin to conduct dynamic security scanning of our Ruby on Rails MVP to automatically find security vulnerabilities during development and testing.
  • We are using OWASP Dependency-Check Plugin for Jenkins to scan third-party libraries our Ruby on Rails MVP are using to ensure none are affected by security vulnerabilities.

So far we have a solid Application Security initiative in our Startup Security Engineering methodology, thanks to Jenkins and its security plugins.

You can take your Application Security initiative a notch higher by using Sonarqube, another quality open source software that promotes writing quality code — and quality code is secure code. You cannot separate the two from each other.

Sonarqube is a multi-programming language code scanner to detect bugs including security vulnerabilities. Issues raised by SonarQube are on either demonstrably wrong code, or code that is more likely not giving the intended behavior. Examples include null-pointer dereferences, memory leaks, and logic errors.

Check this sample Sonarqube Issue on a code written in Javascript:

Image courtesy of Sonarqube blog entry “Detecting Type Issues in JavaScript” https://blog.sonarsource.com/detecting-type-issues-in-javascript/

Sonarqube integrates with Jenkins. They can talk to each other. The best use-case from a security engineering perspective is creating a dedicated executive dashboard within Sonarqube that tracks all security-related issues detected in your code.

Image courtesy of Sonarsource blog https://blog.sonarsource.com/sonarqube-5-3-in-screenshots/

Now that our MVP’s code passed our requirements to make it to production, it is time to deploy it in every bootstrapper’s favorite cloud computing company, Amazon Web Services (AWS).

Deploying on AWS is easy — ensuring everything is set properly for security is not. Setting up IAM, CloudTrail, CloudWatch, etc. are enough to make a lean startup founder doing everything cringe and hide under his desk for a day or two.

And history tells us that startup companies that failed to take note of securing their AWS infrastructure will suffer the dire consequences.

Which is a perfect segue to the next tool I recommend in our Startup Security Engineering methodology.

Prowler will automatically scan your AWS infrastructure to ensure adherence to security best practices defined in CIS Amazon Web Services Foundations Benchmark 1.1

It covers hardening and security best practices for all regions related to:

  • Identity and Access Management (24 checks)
  • Logging (8 checks)
  • Monitoring (15 checks)
  • Networking (5 checks)

This tool can be automated as it runs on a command line interface (CLI). You can include it in your pre-deployment script to ensure AWS is configured according to security baseline requirements before going live.

Please note that the use of this tool (and other tools) is not a silver bullet — practice common sense security in everything you do. Double-check, trust but verify.

So we made it to deployment, code is running live in production, you see casual customer activities. Looks like your Ruby on Rails MVP is getting traction and helping solve customer problems.

The last set of tools I recommend are the built-in monitoring tools in AWS such as the AWS Trusted Advisor.

AWS Trusted Advisor image courtesy of Amazon https://aws.amazon.com/premiumsupport/trustedadvisor/

AWS Trusted Advisor will check the following configuration of your AWS account to ensure security best practices are in-place:

AWS Trusted Advisor security capabilities

However, the beauty of AWS Trusted Advisor goes beyond security as it acts your main dashboard in monitoring your AWS infrastructure in terms of Cost Optimization (Because a startup will always have a low, finite amount of $$$ resource), Performance (your MVP’s performance is a feature), Security, and Fault Tolerance (Something you inherit if you configure your AWS properly)

AWS Trusted Advisor capabilities

To summarize:

(This should go to your MVP pitch deck)

  • We built an MVP that is solving customer problems.
  • We integrated security during the product ideation stage using Security User Stories and low fidelity prototypes.
  • We trained our developer(s) in security
  • We integrated automated security checks in our software build and deployment lifecycle.
  • We enforced automated security checks and baseline configurations of our AWS instances before going into live.
  • We monitor our AWS instances from a security and general operations perspective.

Security must always be part of your MVPs value proposition if you want to survive in today’s red ocean.

Lean Startup Circle

The Lean Startup Circle is a worldwide community of Lean Startup practitioners, educators, consultants, and investors

Ron Flores Del Rosario

Written by

The Complexities: The Universe, Human Behavior and Software

Lean Startup Circle

The Lean Startup Circle is a worldwide community of Lean Startup practitioners, educators, consultants, and investors