Difference between revisions of "OWASP Jupiter"

Latest revision as of 02:36, 18 April 2019

Main
Roadmap
About Jupiter

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?

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

Defining Application

What is an application? Asking that question to five different people will probably yield five different answers. In terms of what the Jupiter Application Inventory Management System considers an application, it can be thought of as a singular module or code project unit that is built and deployed independently (aside from data or operating environment dependencies).

Taking another step, an application has certain attributes. It has a name. It has a codebase and thus a code repository. Where is that repository? It might have a team that supports it and somebody who is ultimately responsible for it. Who owns it? These are the types of questions Jupiter helps to solve.

Data collected includes:

Common Name: The most widely known or current name of the application
Aliases: Other names the application might have or have had previously
Description: A brief synopsis of the application’s purpose for existing
Code Repository URL: The location where the application’s code is stored and versioned
Binary Repository URL: The location where build artifacts are stored and versioned
Primary Language: The most prominent programming language used in the application’s codebase
Secondary Languages: Additional programming languages used in the application’s codebase
Type: Applications might have a particular role inside of an application ecosystem, such as a microservice, user interface, batch job, etc.
Primary Owner: A person who has ultimate responsibility for the direction or well-being of the application
Secondary Owners: Other people who may be delegates of the Primary Owner
Business Unit: Particularly important in large organizations, this is the specific group within the organization to which the application belongs
Exposure: Applications have varying ways they can be exposed – internal to the organization, publicly available on the internet, or to a select group of users
Number of Users: The number of users (or an estimate) of the application
Data Classification: Many organizations have a data risk classification hierarchy and applications may fall into one of the categories
Deployment Environment: Because the Collector captures information at the build and deployment stages, the specific environment to which the build is destined can be recorded (e.g. QA, UAT, Production, etc.)
Deployment Environment URL: Correlating to the Deployment Environment, this is a URL for the application if it is a web application or service
Risk Level: Many organizations have formal risk levels that determine prioritization of resources aside from data categorization (can be a factor of data classification and exposure)
Regulations: Applicable regulations such as PCI, SOX, HIPPA, etc. can be listed
Chat Channel: Many application development and support teams have a way to communicate with each other and to collaborate within their organization such as Slack or Glip
Agile Scrum Board URL: Development teams often keep a list of their in-flight work and backlog in a project tracking system such as Jira or Redmine
Build Server URL: The CI server from which the recorded build or deployment originated
Age: Applications can have a long life and understanding a given application’s age can help determine risk and gauge other implications
Lifecycle Stage: Similar to age, an application can be New, in a Maintenance steady-state, or in Retirement
Last Deployment Date: The last date on which the application was deployed

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

Inventory Management Console (COMING SOON)

Jupiter Inventory Management Console Home
Manage Antecessors
Manage Collector Instances

Project Resources

Source Code

Project Leader

Matt Stanchek

Classifications

Jupiter Application Inventory Management System Roadmap

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
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
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
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
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.

Difference between revisions of "OWASP Jupiter"

Latest revision as of 02:36, 18 April 2019

Introduction

OWASP Jupiter - Application Inventory Management System

Defining Application

High Level Design

Inventory Management Console (COMING SOON)

Project Resources

Project Leader

Classifications

Jupiter Application Inventory Management System Roadmap

FAQ

Navigation menu

Personal tools

Namespaces

Variants

Views

More

Search

Navigation

Reference

Tools

@@ Line 1: / Line 1: @@
+= Main =
 <div style="width:100%;height:160px;border:0,margin:0;overflow: hidden;">[[File:OWASP_Project_Header.jpg|link=]]</div>
 {| style="padding: 0;margin:0;margin-top:10px;text-align:left;" |-
-| valign="top"  style="border-right: 1px dotted gray;padding-right:25px;" |
+| style="border-right: 1px dotted gray;padding-right:25px;" valign="top" |
+== 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).
-<span style="color:#ff0000">
+Making matters worse, organizations are constantly transforming the ways they operate. New software is being written and deployed every day:
-Instructions are in RED text and should be removed from your document by deleting the text with the span tags. This document is intended to serve as an example of what is required of an OWASP project wiki page. The text in red serves as instructions, while the text in black serves as an example. Text in black is expected to be replaced entirely with information specific to your OWASP project.
+* Microservices
-</span>
+* Marketing sites
-==Project About==
+* Batch jobs
-<span style="color:#ff0000">
+* New e-commerce features
-{{Template:Project_About
+* Mobile apps
-  | leader_name1=Matt Stanchek
-}}
+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''.
-==OWASP Tool Project Template==
+If "who owns this?" or "did you know this was in production?" sounds familiar, you're not alone.
-<span style="color:#ff0000">
+|}
-	This section should include an overview of what the project is, why the project was started, and what security issue is being addressed by the project deliverable. Some readers may be discouraged from looking further at the project if they do not understand the significance of the security concern that is being addressed, so provide enough context so the average reader will continue on with reading the description. You shouldn't assume the reader will understand the objective by providing security terminology, e.g. this project builds cryptographic algorithms, but should also endeavor to explain what they are used for.
-</span>
-The OWASP Tool Template Project is a template designed to help Project Leaders create suitable project pages for OWASP Projects.  By following the instructional text in red (and then deleting it) it should be easier to understand what information OWASP and the project users are looking for.  And it's easy to get started by simply creating a new project from the appropriate project template.
+== OWASP Jupiter - Application Inventory Management System ==
+{|
+| colspan="2" |Existing DevOps processes already know what software is being built and when it is being deployed.
-==Description==
+What if we leveraged those DevOps processes to gather crucial information about the organization’s software applications?
-<span style="color:#ff0000">
+|-
-	This is where you need to add your more robust project description. A project description should outline the purpose of the project, how it is used, and the value it provides to application security. Ideally, project descriptions should be written in such a way that there is no question what value the project provides to the software security community. This section will be seen and used in various places within the Projects Portal. Poorly written project descriptions therefore detract from a project’s visibility, so project leaders should ensure that the description is meaningful.
+|[[File:Jupiter.png|left|frameless|200x200px]]
-</span>
+|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
+|}
-The Tool Project Template is simply a sample project that was developed for instructional purposes that can be used to create default project pages for a Tool project.  After copying this template to your new project, all you have to do is follow the instructions in red, replace the sample text with text suited for your project, and then delete the sections in red.  Doing so should make it clearer to both consumers of this project, as well as OWASP reviewers who are trying to determine if the project can be promoted to the next category.  The information requested is also intended to help Project Leaders think about the roadmap and feature priorities, and give guidance to the reviews as a result of that effort.
+== Defining Application ==
+What is an application?  Asking that question to five different people will probably yield five different answers.  In terms of what the Jupiter Application Inventory Management System considers an application, it can be thought of as a singular module or code project unit that is built and deployed independently (aside from data or operating environment dependencies).
-Creating a new set of project pages from scratch can be a challenging task.  By providing a sample layout, with instructional text and examples, the OWASP Tool Project Template makes it easier for Project Leaders to create effective security projects and hence helps promote security.
+Taking another step, an application has certain attributes.  It has a name.  It has a codebase and thus a code repository.  Where is that repository?  It might have a team that supports it and somebody who is ultimately responsible for it.  Who owns it?  These are the types of questions Jupiter helps to solve.
-Contextual custom dictionary builder with character substitution and word variations for pen-testers
+Data collected includes:
+* Common Name: The most widely known or current name of the application
+* Aliases: Other names the application might have or have had previously
+* Description: A brief synopsis of the application’s purpose for existing
+* Code Repository URL: The location where the application’s code is stored and versioned
+* Binary Repository URL: The location where build artifacts are stored and versioned
+* Primary Language: The most prominent programming language used in the application’s codebase
+* Secondary Languages: Additional programming languages used in the application’s codebase
+* Type: Applications might have a particular role inside of an application ecosystem, such as a microservice, user interface, batch job, etc.
+* Primary Owner: A person who has ultimate responsibility for the direction or well-being of the application
+* Secondary Owners: Other people who may be delegates of the Primary Owner
+* Business Unit: Particularly important in large organizations, this is the specific group within the organization to which the application belongs
+* Exposure: Applications have varying ways they can be exposed – internal to the organization, publicly available on the internet, or to a select group of users
+* Number of Users: The number of users (or an estimate) of the application
+* Data Classification: Many organizations have a data risk classification hierarchy and applications may fall into one of the categories
+* Deployment Environment: Because the Collector captures information at the build and deployment stages, the specific environment to which the build is destined can be recorded (e.g. QA, UAT, Production, etc.)
+* Deployment Environment URL: Correlating to the Deployment Environment, this is a URL for the application if it is a web application or service
+* Risk Level: Many organizations have formal risk levels that determine prioritization of resources aside from data categorization (can be a factor of data classification and exposure)
+* Regulations: Applicable regulations such as PCI, SOX, HIPPA, etc. can be listed
+* Chat Channel: Many application development and support teams have a way to communicate with each other and to collaborate within their organization such as Slack or Glip
+* Agile Scrum Board URL: Development teams often keep a list of their in-flight work and backlog in a project tracking system such as Jira or Redmine
+* Build Server URL: The CI server from which the recorded build or deployment originated
+* Age: Applications can have a long life and understanding a given application’s age can help determine risk and gauge other implications
+* Lifecycle Stage: Similar to age, an application can be New, in a Maintenance steady-state, or in Retirement
+* Last Deployment Date: The last date on which the application was deployed
-==Licensing==
-<span style="color:#ff0000">
-A project must be licensed under a community friendly or open source license.  For more information on OWASP recommended licenses, please see [https://www.owasp.org/index.php/OWASP_Licenses OWASP Licenses]. While OWASP does not promote any particular license over another, the vast majority of projects have chosen a Creative Commons license variant for documentation projects, or a GNU General Public License variant for tools and code projects.  This example assumes that you want to use the AGPL 3.0 license.
-</span>
-This program is free software: you can redistribute it and/or modify it under the terms of the [http://www.gnu.org/licenses/agpl-3.0.html link GNU Affero General Public License 3.0] as published by the Free Software Foundation, either version 3 of the License, or (at your option) any later version.  OWASP XXX and any contributions are Copyright &copy; by {the Project Leader(s) or OWASP} {Year(s)}.
+== High Level Design ==
+{|
+|Jupiter is a microservice-based solution that consists of several components.
-==Roadmap==
+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.
-<span style="color:#ff0000">
-As of <strong>November, 2013, the highest priorities for the next 6 months</strong> are:
-<strong>
-* Complete the first draft of the Tool Project Template
-* Get other people to review the Tool Project Template and provide feedback
-* Incorporate feedback into changes in the Tool Project Template
-* Finalize the Tool Project template and have it reviewed to be promoted from an Incubator Project to a Lab Project
-</strong>
-Subsequent Releases will add
+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.
-<strong>
+|[[File:Jupiter HLD.png|alt=Jupiter High Level Design|thumb|Jupiter High Level Design]]
-* Internationalization Support
+|}
-* Additional Unit Tests
-* Automated Regression tests
-</strong>
-==Getting Involved==
+== Inventory Management Console (COMING SOON) ==
-<span style="color:#ff0000">
+<gallery>
-Involvement in the development and promotion of <strong>Tool Project Template</strong> is actively encouraged!
+login.png|Jupiter Inventory Management Console Home
-You do not have to be a security expert or a programmer to contribute.
+antecessors.png|Manage Antecessors
-Some of the ways you can help are as follows:
+collectors.png|Manage Collector Instances
+</gallery>
-| valign="top"  style="padding-left:25px;width:200px;border-right: 1px dotted gray;padding-right:25px;" |
+| style="padding-left:25px;width:200px;border-right: 1px dotted gray;padding-right:25px;" valign="top" |
 == Project Resources ==
-<span style="color:#ff0000">
+[https://github.com/xpert98?tab=repositories Source Code]
-	This is where you can link to the key locations for project files, including setup programs, the source code repository, online documentation, a Wiki Home Page, threaded discussions about the project, and Issue Tracking system, etc.
-</span>
-[https://github.com/SamanthaGroves Installation Package]
-[https://github.com/SamanthaGroves Source Code]
-[https://github.com/SamanthaGroves What's New (Revision History)]
-[https://github.com/SamanthaGroves Documentation]
-[https://github.com/SamanthaGroves Wiki Home Page]
-[https://github.com/SamanthaGroves Issue Tracker]
-[https://github.com/SamanthaGroves Slide Presentation]
-[https://github.com/SamanthaGroves Video]
 == Project Leader ==
-<span style="color:#ff0000">
-	A project leader is the individual who decides to lead the project throughout its lifecycle. The project leader is responsible for communicating the project’s progress to the OWASP Foundation, and he/she is ultimately responsible for the project’s deliverables. The project leader must provide OWASP with his/her real name and contact e-mail address for his/her project application to be accepted, as OWASP prides itself on the openness of its products, operations, and members.
-</span>
 Matt Stanchek
-== Related Projects ==
-<span style="color:#ff0000">
-	This is where you can link to other OWASP Projects that are similar to yours.
-</span>
-* [[OWASP_Code_Project_Template]]
-* [[OWASP_Documentation_Project_Template]]
 ==Classifications==
@@ Line 103: / Line 94: @@
     {| width="200" cellpadding="2"
     |-
-    | colspan="2" align="center"  | [[File:Project_Type_Files_TOOL.jpg|link=https://www.owasp.org/index.php/Category:OWASP_Tool]]
+    | colspan="2" align="center" | [[File:Project_Type_Files_TOOL.jpg|link=https://www.owasp.org/index.php/Category:OWASP_Tool]]
     |-
-    | align="center" valign="top" width="50%" rowspan="2"| [[File:Owasp-incubator-trans-85.png|link=https://www.owasp.org/index.php/OWASP_Project_Stages#tab=Incubator_Projects|Incubator Project]]
+    | rowspan="2" width="50%" valign="top" align="center" | [[File:Owasp-incubator-trans-85.png|link=https://www.owasp.org/index.php/OWASP_Project_Stages#tab=Incubator_Projects|Incubator Project]]
-    | align="center" valign="top" width="50%"| [[File:Owasp-builders-small.png|link=Builders]]
+    | width="50%" valign="top" align="center" | [[File:Owasp-builders-small.png|link=Builders]]
     |-
-    | align="center" valign="top" width="50%"| [[File:Owasp-defenders-small.png|link=Defenders]]
+    | width="50%" valign="top" align="center" | [[File:Owasp-defenders-small.png|link=Defenders]]
     |-
-    | colspan="2" align="center"  | [[File:Agplv3-155x51.png|link=http://www.gnu.org/licenses/agpl-3.0.html|Affero General Public License 3.0]]
+    | align="center" |
+|
     |}
 |}
+= Roadmap =
+==Jupiter Application Inventory Management System Roadmap==
+# Collector Service
+## Authentication
+##* Utilize Auth Service for JWT validation
+## Authorization
+##* Based on JWT payload, enforce restrictions on CRUD operations
+## Database Connectivity
+##*Update Mongo connection code to update deprecated connection method
+##Input Validation
+##*Input length checks
+##*Input type checks
+##Data Fields
+##*Enable data fields beyond Common Name and Primary Owner
+##Containerization
+##*Prepare Dockerfile
+##*Build Docker container
+##*Deploy and test Docker container
+#Curated Inventory Service
+##Authentication
+##*Utilize Auth Service for JWT validation
+##Authorization
+##*Based on JWT payload, enforce restrictions on CRUD operations
+##Input Validation
+##*Input length checks
+##*Input type checks
+##Data Fields
+##*Enable Application-specific data fields beyond Common Name and Primary Owner
+##*Enable capture of Collector Service instance ID
+##Data Integrity
+##*Restrict Common Name to unique values
+##Containerization
+##*Prepare Dockerfile
+##*Build Docker container
+##*Deploy and test Docker container
+#Auth Service
+##Authentication
+###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
+##Authentication
+##*Define user roles (administrator, reader, creator/updater)
+##*Enable issuance of tokens that restrict access based on user role
+#Management Console
+##Base Architecture
+###Add Local SQLite Database
+###*Enable saving of configuration and preferences
+##Authentication
+###Collector Services
+###*Build an interface to allow configuration of Collector Services
+###Curated Inventory Service
+###*Build an interface to allow configuration of Curated Inventory Service
+##Data Fields
+##*Enable Application-specific data fields beyond Common Name and Primary Owner
+##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
+##User Experience
+###Antecessors
+###*Aggregate all Collectors’ data in available Antecessors list when there is more than one Collector Service defined
+#Jenkins Collector Plugin
+##Input Validation
+##*Input length checks
+##*Input type checks
+##Connectivity Validation
+##*Add a “Test Connection…” button to the Global config screen to test the Collector URL and token
+##Data Fields
+##*Enable Application-specific data fields beyond Common Name and Primary Owner under “Advanced”
+= About Jupiter =
+==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.
-__NOTOC__ <headertabs />
+__NOTOC__ <headertabs></headertabs>
-[[Category:OWASP Project]]  [[Category:OWASP_Builders]] [[Category:OWASP_Defenders]]  [[Category:OWASP_Tool]]
+[[Category:OWASP Project]]
+[[Category:OWASP_Builders]]
+[[Category:OWASP_Defenders]]
+[[Category:OWASP_Tool]]