Security was one of the core requirements during the design and initial development of CPR
Security was one of the core requirements during the design and initial development of CPR.
This page covers the publicly releasable security facts and features about the product.
RBAC and need to know
On the server-side we have implemented Role Based Access Control (RBAC) which means that administration accounts (those adding other users to the system) and managing the server have no access to the cases or incidents.
In addition we use a complete ‘Need-to-Know’ concept within the application so a user that can create an incident file, gets to choose who assists them on that incident. Only those included in the incident can see it listed or can search for it. Those removed from an incident lose all access to all CPR hosted data instantly.
We implemented this because in many cases even knowledge of the incident can result in reputational damage.
We use TLS for the encryption between the client browser and the server with the option for an organisation to be able to add their own certificate.
2 factor authentication
Two Factor authentication (with Google Auth) is available on all accounts and can be used to provide peace of mind about session control.
We allow users to have multiple sessions open but there is a nag pop-up to remind you on each page that you have multiple sessions open.
This ensures you don’t forget and also alerts users if another person logged into their account.
As you can see in the screenshot, the option to log out of the other session is easily presented.
Encryption of data
Server side we encrypt all evidence uploaded using SAH256 with individual per-evidence item keys, and all evidence files are moved to read-only directories to prevent deletion.
Evidence and notes put into CPR are immutable (not deletable) to prevent accidental or deliberate removal of evidence; if items are uploaded in error, they can be made private so only the uploading user can see them. This provides evidence integrity but overcomes issues surrounding uploading the wrong evidence to a case.
Users access the system via a browser (we prefer Chrome and Firefox over Safari or IE/Edge), and all activities are contained in the application. This means that most modern OS’s are compatible with the tool, and even mobile devices can log in and use all the features of CPR – although the screen may be a little small.
Files can be uploaded and downloaded from the application and through clever coding and chunking of data, we can accept up to several TB of data upload as evidence. The advantage of this is that large server logs can easily be moved securely to the evidence vault via the TLS session.
This is important when dealing with Personal data, Financial data or other regulated data as things like SMB file shares as they are generally not secure in transit (they are not encrypted by default).
Inside each incident there is a chat feature. This allows incident team members to chat and exchange snippets of found code or command output securely and in a permanent way; all chats are stored with the incident and are also ‘Need-to-Know’.
Convergent is pleased to announce that it has acquired Logically Secure Limited, the Cheltenham headquartered, technical testing, incident response and cyber security consultancy business. Logically Secure’s market leading CyberCPR™ incident response and case management platform
What are the phases of incident response and what are the key points within each? In this article we look at the 6 phases of incident response, to help you defend your business, in detail:
Exposing administrative interfaces can be dangerous – SQL injection in Aptean TLDR; We have found a time-based SQL injection in Aptean Product Configurator v4.0 SP6 – 4.61.0000 which allowed for database access. Have you ever wondered