March 23, 2022
New Features and Improvements
- If Compliance frameworks and controls are configured before instituting Policies and Procedures, controls are now automatically mapped back to corresponding procedures within Policies.
- The last evaluation date for frameworks within Compliance is now displayed, both at the framework level, and the requirement level.
- Failed evaluations of frameworks in Compliance now display a message, calling attention to the frameworks that failed.
Integrations
Azure
- Fixed an issue with the relationships being created between
azure_subnet and azure_vm entities that was causing duplicate key errors.
Google Cloud
Updated several dependencies in the data ingestion steps so that more steps complete successfully when an integration job executes:
- Decoupled the
fetch-compute-region-disks step from KMS keys dependencies. This change allows the Region Disks step to execute successfully even if KMS keys steps are disabled.
- Decoupled the
fetch-memcache-instances step from compute network dependencies. This change allows the Memcache Instances step to execute successfully even if the compute network steps are disabled.
- Decoupled the
fetch-dataproc-clusters step from KMS keys dependencies. This change allows the Compute Dataproc Clusters step to execute successfully even if the KMS keys steps are disabled.
- Decoupled the
fetch-pubsub-topics step from KMS keys dependencies. This change allows the PubSub Topics step to execute successfully even if the KMS keys steps are disabled.
- Decoupled the
fetch-redis-instances step from compute network dependencies. This change allows the Redis Instances step to execute successfully even if the compute network steps are disabled.
- Decoupled the
fetch-app-engine-application step from storage dependencies. This change allows the App Engine Applications step to execute successfully even if the storage steps are disabled.
- Decoupled the
fetch-compute-backend-buckets step from storage dependencies. This change allows the Compute Backend Buckets step to execute successfully even if storage steps are disabled.
- Decoupled the
fetch-private-ca-certificate-authorities step from storage dependencies. This change allows the CA Certificate Authorities step to execute successfully even if the storage steps are disabled.
- Decoupled the
fetch-compute-images step from KMS keys dependencies. This change allows the Compute Images step to execute successfully even if the KMS keys steps are disabled.
- Decoupled the
fetch-logging-project-sinks step from storage dependencies. This change allows the Logging Project Sinks step to execute successfully even if the storage steps are disabled.
Improved the accuracy of the boolean google_storage_bucket.public property by factoring in the project’s storage.publicAccessPrevention policy (see https://cloud.google.com/storage/docs/public-access-prevention).
- Note: this change requires an additional permission,
orgpolicy.policies.get, to be added to your custom access role.
Jira
- Removed the raw data from the
jira_issue entity to prevent ingestion failures.
JupiterOne
- The JupiterOne integration now ingests
jupiterone_api_token entities. The properties include displayName, createdOn, and expiresOn.
KnowBe4
- Added support for Canadian accounts. The integration now allows for
us, eu, and ca accounts.
Microsoft 365
- Entities that are produced by the Microsoft 365 integration that meet the following criteria, will have their _type value renamed to user_endpoint:
- The entity currently has the _type value of smartphone
- The entity has a deviceType property with the value windowsRT
Note: Devices that run Windows RT can technically be smartphones, tablets, laptops, etc. Windows RT is traditionally a mobile operating system, but can run on multiple different device types. This makes it difficult to reliably determine the actual real-world device type (e.g. smartphone) on the JupiterOne entity.
- Removed raw data from the following entities:
- Detected Application entity
- Compliance Policy entity
Salesforce
- Added the
active and userType properties to the salesforce_user entity.
Splunk
- Released version 1.3 of the JupiterOne Add-on on Splunkbase. This release adds a Custom Command, allowing Splunk users to execute a J1QL query and display the response in Splunk.
Veracode
The Veracode integration was rewritten to take advantage of the latest Veracode APIs and to use the current JupiterOne Integration SDK.
The following entities are ingested:
| Veracode Entity Resource |
Entity _type |
Entity _class |
|---|
| Account |
veracode_account |
Account |
| Scan Type |
veracode_scan |
Service |
| CWE |
cwe |
Weakness |
| Vulnerability |
veracode_vulnerability |
Vulnerability |
| Finding |
veracode_finding |
Finding |
The following relationships are created:
| From |
Type |
To |
|---|
veracode_account |
HAS |
veracode_scan |
veracode_scan |
IDENTIFIED |
veracode_vulnerability |
veracode_vulnerability |
EXPLOITS |
cwe |
veracode_finding |
IS |
veracode_vulnerability |
The following mapped relationships are created:
| From |
Type |
To |
|---|
CodeRepo/Project/Application |
HAS/HAD |
veracode_finding Note: This is mapped automatically only when the name of the Veracode Application the finding belongs to matches the name of a CodeRepo/Project/Application in JupiterOne. |
.png)