September 9, 2021
New Features and Improvements
Introduced a new filter to define critical assets in the Assets app, and a smart class query shorthand.
Critical assets are defined using a preset combination of entities classes and attributes (such as hosts and applications tagged as production). You can easily customize this configuration to match your specific definition of what critical assets mean for your organization.
You can reference critical assets in a query using a specific smart class shorthand:
#CriticalAsset. This feature allows you to easily query and monitor important changes and receive alerts when a drift or problem occurs for any of the critical assets that are important to you. It allows you to focus and prioritize on the most important risks.
For example, to identify and alert on new critical assets added in the last 24 hours:
Find #CriticalAsset with _createdOn > date.now - 24hours
This is the initial release of this capability. We will be adding some pre-built alert rules and Insights dashboards for critical assets soon.
Learn more about how to customize and configure your critical assets here.
Updated the query language to follow De Morgan's Law.
To maintain language correctness, J1QL fulfills shorthand filters in accordance with De Morgan's Law. This improvement only impacts queries that use the operators
!$=when operating on a group of values.
FIND jira_user WITH accountType != ('atlassian' OR 'app' OR 'customer')
is the equivalent of:
FIND jira_user WITH accountType != 'atlassian' AND accountType != 'app' AND accountType != 'customer'
Basically, J1QL interprets the above query to return all
excluding those that have an
accountType value of
This is a breaking change! We have taken precautions to ensure saved questions and queries are not inadvertently affected.
We have run maintenance jobs to update all saved queries in questions, alerts, and Insights dashboard widgets. You do NOT have to make any changes manually in JupiterOne.
However, if you have stored queries outside of your JupiterOne account (such as in a custom script), please update those queries accordingly.
- Updated the JupiterOne query language to enable relationship direction with the use
of double arrows,
>>. Relationship direction can be important, depending on your requirements, giving J1QL more specificity on exactly how entities should relate to each other. For example, if you were to use the following query:
FIND aws_iam_role as trusting THAT TRUSTS aws_iam_role as trusted return trusting.name, trusted.name
The above query does not specify direction, so aliasing one as trusted and the other trusting does not behave as expected. Both entities will be represented in either column. By using double arrows, you can indicate the relationship direction:
FIND UNIQUE aws_iam_role as trusting THAT TRUSTS >> aws_iam_role as trusted return trusting.name, trusted.name`
Added traversal filters for use with the
whereclause to support filtering via
ORoperators upon a single field, for example:
find User where User.id=(1 or 2 or 3).
Added search functionality to the Groups page in the Users & Access menu.
Improved the text wrapping in the query search window.
Query Anywhere now auto-focuses when opened so you can immediately start typing.
Improved error messaging in the UI when bulk synchronization fails.
Added new reporting/visualization widgets to the S3 Security Insights dashboard:
- Buckets granted access to AWS services without source condition
- Public buckets with sensitive data or secrets
- S3 cross account access via VPC peering
- SAML SSO users with access to production s3 buckets
- S3 buckets with server access logging enabled
- S3 buckets with object level logging enabled
- Production S3 buckets without any logging enabled
- S3 buckets publishing inventory reports
Reimport the dashboard from the Insights app to get these new widgets in your account.
Stay tuned as additional dashboards, alert rules, managed questions, and compliance frameworks, and mappings are updated.
Resolved an issue where the Policy app would not load under certain conditions.
Resolved an error where users could not accept an invite if they were logged into another account with SSO.
Resolved an auto-complete issue in Query Anywhere.
Resolved the double scroll bars issue on the landing page.
Ingested EC2 settings:
Created mapped relationships between the
aws_ec2service entity and the default
This change requires the additional
ec2:GetEbsEncryptionByDefault permissions in the
JupiterOneSecurityAudit IAM policy of each AWS account being monitored.
ebsOptimizationSupportedBoolean flags on EC2 instance assets. See AWS docs.
Ingested AutoScaling policies and built
Mapped relationships from
aws_sns_subscriptionto the endpoint asset on each subscription (such as an HTTP endpoint, a person by email, or a Lambda function).
Ingested roots and OUs in an AWS organization and mapped sub-accounts to each root/OU.
Added ELB attributes to properties. The attributes are mapped to properties as follows:
ELB Entity Property ELB Attribute
Fixed a false positive where some buckets were incorrectly identified as public (with permission relationships to
everyone) when the policy condition contains specific OrgIds or AccountIds.
Added support for parsing
aws:PrincipalOrgIDIAM policy conditions and mapped relationships to the corresponding
Improved IAM resource policy condition parsing to map permissions to services instead of the account when certain services are specified in the action.
- Fixed the authorization token expiration to support steps that execute for more than one hour.
Improved accuracy of the CIS 4.3 managed question, "Is blocking of project-wide SSK keys enabled for my Google Cloud VM instances?"
google_cloud_projects are now created for deleted projects.
google_bigquery_datasetstep to be independent from
google_kms_crypto_keystep to ensure BigQuery data is ingested even when KMS Keys ingestion is disabled or fails.
Added the following new properties to these resources:
truewhen the storage bucket does not have Uniform Bucket Access Level enabled. We cannot determine if the bucket is public or not when this setting is disabled.
Application Rules are now
Configurationassets in the graph.
Users are related to the AWS IAM roles they have access to based on the presence of IAM role ARNs in the application rules. This change requires that the IAM Role asset already exists in the J1 graph (the AWS integration is installed).
Added raw data to assets.