This article provides an explanation of the key concepts of Instances, Organizations, Projects and Asset Groups, and instructs you on how to structure your Nucleus tenant to ensure that you are able to effectively analyze and prioritize asset and finding, report and control access to it.
It is essential that this article is read carefully prior to implementing Nucleus as the project and asset group architecture that you choose will have wide ranging implications on your ability to organize and run your vulnerability program, and ability to effectively drive remediation and reporting outcomes.
Nucleus Platform Hierarchy
Nucleus is a tenanted environment with a structured hierarchy that enables you to flexibly group asset and finding data for analysis, triage, prioritization, reporting and remediation purposes. Nucleus is comprised of four layers of hierarchy:
Instance
An instance is a deployment of Nucleus on infrastructure within a cloud provider region. Customers may select the region that they are deployed after which they will be allocated to an instance with available capacity within that region. Nucleus tenants are instance bound, and data and settings cannot be moved to another instance after deployment.
The instance region and number is identified by your login URL, which follows the naming convention https://nucleus-<region><number>.nucleussec.com. For example, if you are in the US1 region, your instance URL is https://nucleus-us1.nucleussec.com.
Organization
An organization is the top most logical grouping of data within an instance of Nucleus and is considered your tenant. When customers are first provisioned access to Nucleus, an organization is created and configured on their behalf. Organizations contain users and projects, and are used by Nucleus administrators to setup and manage SSO, configure user settings, roles and permissions, track licensing consumption and perform limited high level reporting.
Each customer has a single organization which licenses are allocated to.
Project
A project is the second logical grouping of data within an instance of Nucleus and is contained within your Nucleus organization. Projects are highly scalable self-contained environments that contains any and all data relating to your vulnerability management program such as assets, findings, automation rules, connectors, scheduled reports, tickets, users and teams.
Projects were designed to encapsulate the data and operations for your organization's entire vulnerability management program and contain powerful tools to enable you to do so automatically at scale.
Within a project you can:
- manage assets and their ownership within your organization
- represent and navigate your organizational's hierarchy as it pertains to asset and vulnerability ownership and remediation
- ingest and synchronize data from many sources
- automatically analyze, triage and prioritize newly discovered assets and findings alongside existing data according to your company's unique policies and procedures
- drive remediation by assigning work to users and teams inside and outside of Nucleus, and
- track and report on trends and other insights over time.
It is essential that you carefully evaluate your approach to project architecture as projects are logical groupings that cannot share data. All features of Nucleus are bound to a project, and entities like assets and findings cannot be moved between projects.
Project architecture also has implications for the consumption of licensing. Asset and finding correlation and de-duplication is performed within projects, not outside of them. For example, if you have three projects and ingest the same scan with the same asset into all three projects, this will consume three asset licenses instead of one.
Asset Group
An asset group is the final logical grouping of data within a project and as its name suggests, groups assets within a project. Asset groups themselves are nested and are an extremely flexible tool that can be used to represent your organization's hierarchy, control user access to subsets of assets, act as custom asset filters, and drive automation and reporting outcomes.
Assets and their groups have a many to many relationship. That is, asset groups can contain multiple assets, and assets can be contained in multiple groups. There is no limit to the number of groups an asset can be in.
Relationship Flexibility
An asset's relationship to each group that it's in is either dynamic or static.
A dynamic relationship between an asset and an asset group means that the asset's link to that group is driven by asset processing rules and will be dynamically chosen based on the underlying ruleset. As asset processing rules are both orderable (meaning one rule's criteria can be triggered by the outcome of a previous rule) and can be driven by the Nucleus dynamic field templating language, groups can be rapidly created and assets added to or removed from them based on both the intricate requirements of your organization as well as the frequently changing underlying data in your source tools.
A static relationship between an asset and an asset group is one where the asset was manually added to that group by a user such as a Nucleus project administrator. Assets that are dragged and dropped into groups in the Asset Management page will remain pinned in that group until such time that the asset is removed by user.
Access Control
Asset groups can also be used to control a user or team's access to assets within a project. Both individual users as well as teams can be granted access to one or more asset groups, at which time the only data that they will see in the project are the assets that exist within those groups. If and when assets are moved into or out of a group (dynamically or manually), the user or team's access to those assets updates automatically alongside the change.
This link between asset groups and access control means that as organizations change and new data and information is introduced, asset processing rules can automatically organize data to meet these changes and flow on to user and team access too.
Project & Asset Group Architectural Patterns
Almost all customers will only need a single Nucleus production project, however in some situations a more complex project structure may be required. Continue reading below to understand these situations and if they apply to you.
Key Considerations & Motivations
When designing the architecture of your projects and asset groups, it is important to remember that this design must complement and enable your company's current and future business and technical operations and support your company and it's vulnerability management program as they both continue to grow, adapt and mature.
It is the nature of every company irrespective of it's size to change frequently in small and large ways to respond to market conditions and other factors inside and outside of its control. In our experience, it is common for medium and large enterprises to conduct major departmental restructures at least every three months. These changes may occur due to a myriad of reasons, but in the context of Nucleus what is most important is not why the company changed, but how your vulnerability management program can respond quickly to this change and continue to closely mirror and support the organization with the least amount of management overhead and friction. At the end of the day, bad actors do not wait for your vulnerability management program to catch up to your company's restructure before attempting a breach.
Companies don't just change internally, but they change externally as well. That is, depending on your size, your company may perform mergers and acquisitions, sell subsidiaries and assets, and even be acquired itself.
For these reasons, it is important to consider not just your company's size and current departmental hierarchy when designing your vulnerability management program in Nucleus, but also the rate at which the company is growing, the frequency that it changes, and your company's merger and acquisition strategy.
Patterns
There are two main architectural patterns for choosing how many projects to create in Nucleus, each taking into account the above considerations. These are the Centralized Operations Pattern, and the Isolated Entities Pattern.
Centralized Operations Pattern (COP)
The COP architecture is best suited to companies that are a small to medium in size and which either have no subsidiaries, or otherwise own subsidiaries whose business and technical operations are centrally managed and which have a single continugous network address space within the umbrella company. The company may or may not have teams, applications and ownership defined in a CMDB. We find that this pattern is best suited to most customers.
A single continguous network address space (i.e. centralized managed internal IP addresses) is not a hard requirement for this pattern, but in some situations overlapping address spaces may result in over-merged assets. This usually occurs when customers have a large on-premise or self-managed data center footprint and use scanning technology that doesn't provide strong unique identifiers. If in doubt, please speak with your Nucleus implementation lead or customer success manager, or reach out to the support team for guidance.
In this architecture, a single Nucleus project is used for all assets and findings across the technology landscape and asset groups are used to (amongst other things) flexibly represent the organization's departmental, value stream and enterprise application hierarchy. This hierarchy is built and managed automatically using dynamic fields in asset processing rules, and may or may not rely on asset only sources such as a CMDB or home-grown asset management tool.
Example Deployment
ACME Corporation Production (Nucleus Project)
---- Departments (Top-level Asset Group)
|- Technology (Department Asset Group)
| |- Warehouse Operations (Value Stream Asset Group)
| | |- A123 - AutoPacker (Application Asset Group with App ID)
| | |- B222 - Catalogue Pro
| | |- etc.
| |- eCommerce
| | |- A509 - Consumer Web Application
| | |- A407 - Merchant Web Application
| | |- etc.
| |- etc.
|
|- Data Science
|- Finance
|- Human Resources
|- etc.
In this example, the company has represented their departmental hierarchy, value streams and applications as nested asset groups in a single Nucleus. Assets are automatically added to these groups based on dynamic fields and asset additional metadata that is synced in regularly from a CMDB source. As this underlying data changes in the CMDB, the application that an asset belows to may stay the same, but the application itself may move from one value stream to the next (such as if value streams are merged and owned by a single manager), or move entire departments. In these situations, as the underlying data changes, the application and its assets will automatically move from one value stream or department to anther one, thereby automating away the otherwise manual effort that would have been associated with keeping this up to date.
Isolated Entities Pattern (ISEP)
The ISEP pattern is an architecture that best fits large enterprises with isolated subsidiaries (i.e. the business, technical and/or security operations remain segregated from the umbrella company), or active merger and acquisition operations where new acquisitions may be run permanently as an isolated subsidiary, or may be done so temporarily so that the subsidiary can be merged into the umbrella company.
In this architecture, it would be common to have a single project representing the umbrella company and it's business and technical operations (similar to the COP architecture), but to also create a project for each subsidiary. By creating separate projects for each subsidiary, you can more easily keep data logically separated, prevent assets from merging where they shouldn't (such as if IPAM is not distinct) and manage access and ownership/administration to the subsidiary's data. This architecture also has the benefit of being able to easily remove data if the subsidiary is sold or otherwise no longer under the purvue of a single cyber security department.
Common project structure misconceptions
It can be easy to begin your implementation of Nucleus without realizing that the design of your project architecture has not set you up for success. Below are some examples of project architectures that will be difficult to maintain over time, and may hold back the efficiency and effectiveness of your vulnerability management program.
Example 1: Projects for business units, departments, locations or teams
Larger enterprises typically have a more complex organization structure and the need to control access at a much finer level than an smaller organizations. Consequently, a large enterprise may see the flexibility of Nucleus projects and mistakenly assume that they should create anywhere from 5 - 50 different projects representing business units, divisions, geographical locations, and/or development teams.
Example 2: Project per application development team
In many cases, Nucleus is used by an organization to primarily support DevSecOps and application security use cases. Consequently an application security team may think that each application team is best served by its own project in Nucleus. This approach is not ideal as it reduces your ability to track and report on findings holistically, and doesn't cater to scenarios of change such as if applications move teams.
Example 3: Project per scanning vertical
It's common for security departments to separate the roles and responsibility of application security (such as the security of custom built applications) and infrastructure security (such as managing vulnerabilities and misconfigurations of servers, workstations and corporate devices) into different teams. Consequently each team may think that they are best suited to having their own Nucleus project with just their assets and findings. This is not an ideal project structure because it prevents the organization from effectively representing ownership of the entire tech stack from a single view, and makes it difficult to prioritize, remediate and report at a macro level.
In summary, the above examples face the following problems making them not an ideal choice for running an effective vulnerability management program in Nucleus:
- Any restructure or change to the organization's business hierarchy will mean substantial re-importing of data and lack of continuity of findings.
- Importing only the right data for that project will be challenging as source tools are often inflexible.
- The same asset is likely to be imported multiple times into different projects resulting in higher licensing costs.
- Difficulties identifying ownership of assets and findings at various levels of the organization's hierarchy, resulting in ineffective remediation efforts and reporting.
Ultimately the project architecture of your Nucleus implementation is up to you to decide, however we recommend carefully considering the pro's and con's of these architectures against the COP or ISEP architectures when implementing Nucleus within your organization.