This site is the archived OWASP Foundation Wiki and is no longer accepting Account Requests.
To view the new OWASP Foundation website, please visit https://owasp.org

Difference between revisions of "OWASP Jupiter"

From OWASP
Jump to: navigation, search
(Added Roadmap and FAQ)
m
Line 37: Line 37:
 
|Jupiter is a microservice-based solution that consists of several components.
 
|Jupiter is a microservice-based solution that consists of several components.
  
−
First, the '''Inventory Antecessor Collector Service''' can gather primitive inventory data (antecessors) directly from DevOps tools, such as continuous integration servers like Jenkins via the '''Jupiter Inventory Plugin''', when the software is built and deployed.
+
First, the '''Jupiter Collector Service''' can gather primitive inventory data (antecessors) directly from DevOps tools, such as continuous integration servers like Jenkins via the '''Jupiter Collector Plugin''', when the software is built and deployed.
  
 
The '''Inventory Management Console''' connects to the collector service and facilitates enrichment of the antecessor data into “gold records” representing an application.  These records are stored by the '''Curated Inventory Service''' via REST API or through the management console.
 
The '''Inventory Management Console''' connects to the collector service and facilitates enrichment of the antecessor data into “gold records” representing an application.  These records are stored by the '''Curated Inventory Service''' via REST API or through the management console.

Revision as of 03:22, 9 April 2019

OWASP Project Header.jpg

Introduction

An Application Security program is more successful when coverage of its processes and tooling can be proven. Unfortunately, software inventory lists consist of some custom-written applications for an organization but also include systems and software that aren't in scope for a traditional AppSec program (Active Directory or Adobe Reader, for instance).

Making matters worse, organizations are constantly transforming the ways they operate. New software is being written and deployed every day:

  • Microservices
  • Marketing sites
  • Batch jobs
  • New e-commerce features
  • Mobile apps

Traditional ITAM solutions aren't tracking these custom-written applications that are the lifeblood of your organization because they aren't designed to find them.

If "who owns this?" or "did you know this was in production?" sounds familiar, you're not alone.

OWASP Jupiter - Application Inventory Management System

Existing DevOps processes already know what software is being built and when it is being deployed.

What if we leveraged those DevOps processes to gather crucial information about the organization’s software applications?

Jupiter.png
 Having quality application inventory data enables:
  • Improved insight into what is being built and deployed across the software portfolio
  • Efficient onboarding to Application Security tools and processes (static analysis, dynamic analysis, open source software component analysis, penetration testing, vulnerability management)
  • Enhanced metrics capabilities to determine tool and process coverage as well as the organization’s Application Security maturity level

High Level Design

Jupiter is a microservice-based solution that consists of several components.

First, the Jupiter Collector Service can gather primitive inventory data (antecessors) directly from DevOps tools, such as continuous integration servers like Jenkins via the Jupiter Collector Plugin, when the software is built and deployed.

The Inventory Management Console connects to the collector service and facilitates enrichment of the antecessor data into “gold records” representing an application.  These records are stored by the Curated Inventory Service via REST API or through the management console.

Jupiter High Level Design
Jupiter High Level Design

Project Resources

Source Code

Project Leader

Matt Stanchek

Classifications

Project Type Files TOOL.jpg
Incubator Project Owasp-builders-small.png
Owasp-defenders-small.png

Jupiter Application Inventory Management System Roadmap

  1. Collector Service
    1. Authentication
      • Utilize Auth Service for JWT validation
    2. Authorization
      • Based on JWT payload, enforce restrictions on CRUD operations
    3. Database Connectivity
      • Update Mongo connection code to update deprecated connection method
    4. Input Validation
      • Input length checks
      • Input type checks
    5. Data Fields
      • Enable data fields beyond Common Name and Primary Owner
    6. Containerization
      • Prepare Dockerfile
      • Build Docker container
      • Deploy and test Docker container
  2. Curated Inventory Service
    1. Authentication
      • Utilize Auth Service for JWT validation
    2. Authorization
      • Based on JWT payload, enforce restrictions on CRUD operations
    3. Input Validation
      • Input length checks
      • Input type checks
    4. Data Fields
      • Enable Application-specific data fields beyond Common Name and Primary Owner
      • Enable capture of Collector Service instance ID
    5. Data Integrity
      • Restrict Common Name to unique values
    6. Containerization
      • Prepare Dockerfile
      • Build Docker container
      • Deploy and test Docker container
  3. Auth Service
    1. Authentication
      1. Enable LDAP authentication
        • Build LDAP integration capabilities
        • Based on successful username/password LDAP authentication, provide time-limited JSON Web Token for subsequent requests
        • Enable facility to validate expiration of tokens and deny access to expired tokens
    2. Authentication
      • Define user roles (administrator, reader, creator/updater)
      • Enable issuance of tokens that restrict access based on user role
  4. Management Console
    1. Base Architecture
      1. Add Local SQLite Database
        • Enable saving of configuration and preferences
    2. Authentication
      1. Collector Services
        • Build an interface to allow configuration of Collector Services
      2. Curated Inventory Service
        • Build an interface to allow configuration of Curated Inventory Service
    3. Data Fields
      • Enable Application-specific data fields beyond Common Name and Primary Owner
    4. External Integrations
      Consistent naming across multiple external Application Security tools will allow for greater future automation and reporting as well as utilization.
      • Enable set up of Application in Fortify Software Security Center
      • Enable set up of Application in OWASP Dependency-Track
      • Enable set up of Application in OWASP Defect Dojo
      • Enable set up of Application in OWASP SecurityRAT
    5. User Experience
      1. Antecessors
        • Aggregate all Collectors’ data in available Antecessors list when there is more than one Collector Service defined
  5. Jenkins Collector Plugin
    1. Input Validation
      • Input length checks
      • Input type checks
    2. Connectivity Validation
      • Add a “Test Connection…” button to the Global config screen to test the Collector URL and token
    3. Data Fields
      • Enable Application-specific data fields beyond Common Name and Primary Owner under “Advanced”


FAQ

Q: Why is this project named "Jupiter"?

A: In 2001: A Space Odyssey, the Discovery One embarked on a mission to investigate the signal sent from the monolith on the Moon to Jupiter. In 2010: The Year We Make Contact, the crews of the Discovery and Leonov witness countless monoliths emerge from Jupiter before it is converted into a star. Aside from the cool sci-fi reference, there is an analog to what this project is for -- to start with a small amount of information about software applications in an organization's portfolio and build upon that knowledge to find more.

Retrieved from "https://wiki.owasp.org/index.php?title=OWASP_Jupiter&oldid=249838"