Polonious Architecture (AWS hosting)
All our AWS hosting option for Polonious are based on the following minimal setup. Based on client needs, additional components can be included (see Knox-grade security below).
The Polonious web application is running inside a dedicated J2EE Apache-Tomcat application container on an Amazon EC2 instance in a public subnet within a dedicated VPC. Access to the instance is secured via Amazon security groups to only allow external access on ports 443 (HTTPS) and 22 (SSH-RSA). Additional security is provided by strict IPTables and DenyHost rules. Those rules and general Linux hardening rules are controlled and updated via Puppet.
A separate RDS EC2 instance is hosting the client database and is running in a private subnet which is not directly accessible from the internet. Security groups ensure that only the application server can access the database to make queries or update data. We utilize the Amazon RDS service to power our database. PostgreSQL is our database of choice. The RDS instance is managed and auto-patched by AWS.
RDS can be configured in Multi-Availability-Zone mode at an additional cost. Multi-AZ means that all data is replicated to a secondary RDS instance within the same region. RDS automatically fails over to the replicate in case of an outage or the primary instance.
Documents which are uploaded via the Polonious user interface are transferred to a dedicated S3 bucket. Only the client’s EC2 instance has access to this client bucket (configured via security groups). Recently accessed files are cached in the local filesystem of the EC2 instance for faster access and anti-virus scanning and are removed from cache if they are not accessed within a configured time.
Core components
| Component | Recommended version | Notes |
| Java | OpenJDK 8 Oracle JDK 8 | Polonious is a J2EE application and requires a Java environment to be installed on the server which hosts the J2EE application server. |
| Apache Tomcat | Tomcat 8.5.x | Apache Tomcat is a free and open-source J2EE application container used to run the Polonious application. |
| pims | 19.2 and later | The core Polonious applications is a WAR file. A WAR file is a Web Application Archive which is a JAR file containing all the application logic defining the Polonious web application. The WAR file is deployed to and run in the J2EE application container Tomcat. |
| pims-ng | 19.2 and later | With 18.2, we have begun the process of creating more re-usable, robust microservices in anticipation with client sizes of 1,000+. This architecture uses Spring Boot along with the eventual use of zuul, hystrix and other Spring Cloud components. We expect a number of other microservices and capability in 19.1, we have our best engineers working on it. |
| Polonious Front-End | 19.2 and later | With 18.2, we have begun splitting out the new User Experience into it’s own package for deployment to tomcat. This allows the MVC Javascript application to secure itself with OAuth and then use REST calls to pims-ng to get and update data. |
| postgresql rdbms | 9.6 | Postgresql has been an extremely reliable database that supports Polonious Investigation Management Systems. It is also the standard database when deploying to RDS on Amazon Web Services. |
| libreoffice (as a service) | 4.x / 5.x | LibreOffice is a free open source software which is used by the Polonious Application to generate case reports in various file formats (e.g. PDF, DOC, XLS, ODT files). Polonious has been tested with version OpenOffice 3 and 4 as well as LibreOffice 3 and 4. It is recommended to run LibreOffice as a daemon on the application server, otherwise network has to be configured to allow access to LibreOffice. |
| Postfix | 3.x and later | Polonious requires an SMTP service. We usually configure Postfix if the customer does not have an alternative requirement such as Exchange server. |
| IMAP Service | Polonious has a feature to parse incoming emails and load the content of those emails including attachments into the system. It analyses the sender email and email subject and if it finds a matching case record in the system, the email is attached to that case. This feature requires the application server to access an IMAP account which can be set up by Polonious for this purpose. We can also configure to load such emails from an existing email account such as exchange server given that the IMAP protocol is supported. This component is included by default. |
Optional System Components & Services
| Polonious Online User Help | Polonious has user help system which explains certain UI elements within the application of the software in the various screens. The help texts are stored in our Polonious User Help System. In order to use the context help from within the Polonious application, the application server needs to be able to access polusa.poloniouslive.com via HTTPS. This component is enabled by default. | |
| Polonious User Manual | On top of the context help system, Polonious also allows user to generate the full user manual as a PDF document. This user manual generator is hosted on server regimo.poloniouslive.com so the network needs to be configured to allow HTTP access from the application server to the remote service. This component is enabled by default. | |
| Virus Scanning (optional paid service) | Polonious can be configured to perform a virus scan on any file which is stored in the document repository via the Polonious application. Kaspersky AntiÂVirus for File Server and McAfee VirusScan® for UNIX Version 6.0 are currently the only supported virus scanners that integrates with Polonious. This component is not included by default. It can be selected from the order book. | |
| Geo-coding (optional paid service) | If the mapping module is required, Polonious uses a third-party service to provide geo-coding of addresses attached to cases, updates and persons. To access the service the network needs to be configured to allow HTTP/HTTPS access to the third-party service. This feature works in combination with the Mapping module mentioned below. This component is not enabled by default. | |
| Mapping (optional paid service) | Polonious can be configured to display case locations, person locations and other locations on a map and e.g. assign investigators from the map view. Polonious uses third-party services to download tiles and provide the mapping framework. If the mapping module in Polonious is enabled the network needs to be configured to allow HTTP/HTTPS access to the selected service provider. This feature works in combination with the Geo-coding module mentioned above. This component is not included by default. | |
| Social Searches (optional paid service) | Polonious provides several plugins to integrate with social media search engines to perform background checks on persons of interest. Those features require configuration of access keys provided by the third-parties per client. Also network rules need to be defined to allow access to those external services. This component is not included by default. | |
| Single sign-on (optional) | Polonious provides integration with SAML2 compliant SSO providers. This feature requires exchanging security details between the provider and polonious and network rules to be configured. |
Knox-grade SecurityÂ
Our Knox-grade offering adds several additional security components and features to our standard set-up on AWS as outlined in the previous section. The following diagram outlines the high-level architecture of those components with separate sections describing each component in more detail. The VPC set-up, as well as the application server, RDS server, and S3 are set up similar to our standard deployment outlined in previous section.
Web Application Firewall (WAF)
Our web application firewall (WAF) capability is configured via Cloudflare. Cloudflare’s enterprise-class WAF protects your services from common vulnerabilities like SQL injection attacks, cross-site scripting, and cross-site forgery requests with no changes to your existing infrastructure.
Network Intrusion Detection System (NIDS)
Internal NIDS plays an important role in any cyber security program. By detecting malicious network events, it provides vital information for correlation directives and cross-correlation rules. Combining this information with the events collected from other devices, the SIEM presents a complete picture of the malicious activity.
Host Intrusion Detection System (HIDS) & Monitoring
A host-based intrusion detection system (HIDS) gives you deep visibility of what is happening on your critical systems. With it, you can detect and respond to malicious or anomalous activities that are discovered in your environment. The SIEM agent provides the following:
- Detect Changes & Threats to Systems
- Implement File Integrity Monitoring (FIM) monitoring for key system changes
- Deploy and manage the agent through the central management platform
- Analyze all system network traffic and activity against IDS signatures and dozens of other security indicators
- The agent logs all critical system activities such as software installation/uninstall, configuration changes, log clearing, privilege changes, authentications, scheduled jobs and network activity. Those logs are stored for 1 year.
Next Generation SIEM Analysis
The SIEM solution compares up to 3,250 metadata points across nearly 40 supervised machine learning anomaly detections, 14 commercial threat intelligence feeds, 0-Day file sandboxing, IDS analysis, Asset Risk analytic scoring and many other correlations to determine malicious activity.
SIEM - Security Incident & Events Monitoring
We embed specialised SIEM components into our offering which provides the ability to start detecting from day one. Our professionally managed SIEM provider solution is shipped with an extensive and continuously growing library of correlation rules researched and written by a specialised SOC team. This team of seasoned security experts tracks emerging threats in the wild and continuously updates the platform with the latest security intelligence, so you have an always-up-to-date security monitoring platform. The threat intelligence database is updated several times per day and the platform is continuously upgraded to remain vigilant against modern threats, typically once every 6 weeks.
VPN-based Access
All backend access to Knox Grade servers is secured via VPN. SSH users are managed via our central configuration management tool Puppet. SSH is configured to deny root user access so only public/private key access for dedicated support staff is possible.
Encryption at rest and in transit
All data stored is encrypted at rest including EBS volumes attached to EC2 Virtual Machines instances, RDS database, as well as S3 document store. All network traffic is encrypted SSL communication channels.
Backups & Point-in-time-recovery
We configure RDS to create daily snapshots of the database and keep backups of the transaction logs for 35 days (created in 5 minute intervals). This transaction log can be used to roll back data to any day and time within the last 35 days and allows a RPO of only 5 minutes.
Additionally nightly snapshots of the database are created and stored for a minimum of 10 days.
Data Replication
Additionally we can configure the RDS instance to run in Multi-AZ replication & fail-over mode. This means that a separate database instance is running in a different availability zone within the same region with an exact copy of the primary database. Amazon guarantees automatic and instant fail-over to the secondary instance in case of an outage of the primary database instance.
