Why Portal?

Portal was built to address the needs of our users who want an improved way of interacting with their clients. Current practices are built around static documents, email and other tools not fit for the purpose of efficiently and safely sharing security assessment results and reports. Our clients wanted a single experience for their users to:

• Request and approve assessments,

• Track the progress of assessments, and

• Easily review the results of their security assessments in one place.

Portal is CheckSec’s approach to moving the security assessment sector off the static document model. Portal’s web-driven process allows users and assessment teams to collaborate better, and to fix security issues more quickly.

Why didn’t we just add “restricted user views” to Canopy?

Good question :) We built Portal as a simplified front-end to Canopy. Canopy stores a lot of sensitive data, and we knew that our users might feel uncomfortable about that increased exposure should external clients be allowed to access the main Canopy infrastructure. Portal was created as a separate application to facilitate “air gaps”, as required. It also allows us to ensure Portal’s functionality and features are focused on its users, and not constrained by Canopy.

Example deployment scenarios:

• Client A, Client B and Client C are synchronized to Portal 1 hosted on a multi-tenant server.

• Client D is synchronized to Portal 2 hosted on a dedicated server.

• Client E is synchronized to Portal 3 hosted on Client E’s DMZ.

• Client F is not synchronized to any Portal.