SecureOneLabs Logo

CONCEPTS

The Entity

An Entity can be an organization, a department, unit, or division, or an external vendor or supplier. These are all essentially "administrative entities" with very similar data attributes, but the major difference between them is their "type".

Why did we take this approach? If we were to have one Platform Module for internal business groups and another Module for external vendors or suppliers, having duplicate data and elements between them is a certain outcome, as well as the variation in depth and scope of the data recorded. This painfully leads to a wide range of data quality issues across the organization, and requires the financial and labor expense to manage and maintain. Taking a unified approach for the "Entity" therefore eliminates many of these issues by design.

Additionally, it enables you to now have a much more detailed view of your external risk since you have the ability to manage and track the same level of details as your own. The Entity is the main component that owns everything else such as Applications, Databases, Locations, etc.

For the same reason you can't have two businesses with the same legal name, Entity names must be unique.


The Environment

The "Environment" includes those components that make your business function such as applications, assets, networks, and identities. This is your main "inventory/CMDB" so that when you later conduct control assessments or want to track down where data risk is, you will know where to look and what relationships they have with other components with potential risk.

This also provides the advantage and control of having one source of truth eliminating many data quality and integrity problems prevalent in many organizations as a result of having multiple systems with overlapping use and functions.


Hierarchy

Using a flexible hierarchical design, you can configure BOSSS to mimic your current organizational hierarchy and risk taxonomy without making custom code changes.

For example, if you have a level 1 business Organization (e.g., Finance) that is a parent of level 2 departments (e.g., Accounting) that in turn have level 3 sub divisions, you can define the hierarchy exactly like that in the platform and it will automatically implement access controls based on your own unique environment.

This design makes it a strong contender for adoption in almost any environment. Setting (or accepting the default) hierarchy is one of the first things you would need to do.


Identity

An identity could belong to a traditional user account like the one you use to log into web sites, or it could be a service or system account that is used by computers directly without human intervention. Since these accounts tend to run applications and have privileges on systems, they too have very similar data elements to traditional accounts that need to be tracked.

Combining them into one module is an efficient architectural approach which solves problems similar to the Entity design. This approach also allows you to have multiple identities for one person/user/system and track/reference them separately in your environment providing for maximum flexibility.


Assets

Assets can be servers, systems, workstations, firewalls, phones, Mobile, IoT devices, or any other valuable asset in your environment. This inventory allows you to ensure that each asset is recorded, and that it has the proper controls assigned to them.


Authorities

Authorities provide governance or compliance requirements to, or for, your organization. They could be regulating bodies such as OCC, FDA, industry Frameworks such as NIST, ISO, and OWASP, industry authorities such as PCI, or stem from regulations such as GLBA, SOX, or HIPAA. The idea is that each of these authorities in turn have policies you can or need to adopt for your organization, which will then be the basis of your control environment.


Selection Options

These are the options you see when you click on a menu to select an option (pun intended). For example, Organizations may have their own taxonomy in describing different status options (e.g., New, Assigned, Closed, etc.) based on their industry or some form of standard they adopted.

The Platform provides the capability to instantly create and change options to form selections. A reference to each Module and the available menu options have been coded into the system. All you have to do now is decide if the built-in options satisfy your needs or if you need to make some updates or changes.


Role-based Access Controls

Groups are automatically created for Entities that you assign a "Hierarchy" to in the system. This alleviates the need for you to manually create groups for each Entity created. By default, each Entity created will have separate groups created to control which modules (e.g., Applications, Audit) can be accessed for that Entity, as well as separate groups that control the specific permissions (Admins, Support, Viewers) allowed for that specific Entity and module pair. Each Group that the system automatically creates for Entities with assigned hierarchies, controls access to four different dimensions:

  • Hierarchy: Organization high level vs. sub division. By default, if access is granted to a parent, it will include its children by default.
  • Entity: Specific entities such as HR or Finance departments
  • Module: Applications, Assessments, Audit, Risks, etc.
  • Role: Admins with full control versus viewers only versus support with limited permissions.

Example group: Grants the following access:

  • Hierarchy: Level 2 | Department (and everything under it)
  • Entity: Finance Controller
  • Module: APPLICATION
  • Role: Admins

Default roles:

  • Admins: View, Add, Change, Delete
  • Support: View, Change
  • Viewers: View

As you will see in the remainder of this Guide, assigning access and permissions using this approach and design becomes incredibly easy and powerful.

For example, single User account can have access at level 2 under one Entity as an Admin for all the Modules, but can also have access at level 3 for a different Entity with different support roles for the same Modules. It wasn't easy, but we made it happen!


Now that we have the basics down, let's dive in!

Was this page helpful?