AlgoSec SaaS Services Security Practices

This topic provides the information needed to assess the impact of AlgoSec SaaS Services on the overall Data Management and Security posture, by detailing how data may be captured, processed, and stored by and within the SaaS products used.

AlgoSec SaaS Service Security Considerations

AlgoSec is committed to upholding the highest levels of data protection. As cyber professionals, we are keenly aware of the criticality of ensuring the security and privacy of user data. Any customer data stored on or processed by AlgoSec is secured with state-of-the-art technologies. We operate ongoing rigorous technical and organizational security controls on all the services listed in this document, focusing on monitoring, change management, security updates and closing gaps from yearly penetration tests.

AlgoSec holds multiple certifications, demonstrating our firm commitment to top-tier security. We strive to comply with and maintain high-quality standards in line with globally recognized frameworks. AlgoSec is certified for the ISO/IEC 27001:2013 & ISO/IEC 27017:2015 standards which outlines the best practices for information security management systems. In addition, AlgoSec has been certified following a SOC 2 Type II audit conducted by an independent service auditor. This audit evaluates the design, implementation, and effectiveness of the controls we have in place for our products.

Tenant and user management

Tenant and user management data is stored securely as follows:

• Isolation of data between tenants
• Role Based Access Control (RBAC)
• User management and authentication
• Prevasio adheres to the Principle of Least Privilege

Isolation of data between tenants

AlgoSec SaaS does the following to isolate data between tenants:

• AlgoSec SaaS uses stateless services. AlgoSec SaaS services do not store data of any kind in memory that may leak between actions of different tenants.

• AlgoSec SaaS isolates data at rest.

  CloudFlow, ObjectFlow, AppViz	We deploy dedicated tenant infrastructure and separate databases for each customer. Each designated database requires access credentials. The access credentials are available only to AlgoSec services and applications and not directly to the user. These credentials are held in AWS KMS service (see below) and are accessible only by users of that tenant.
  Prevasio	Prevasio uses a multi-tenant architecture where info about different tenants is stored in separate database tables and separate S3 buckets. Encryption key management of the database tables is owned by Amazon DynamoDB. Encryption key management of the S3 buckets is owned by Amazon S3.

Refer to the diagram above.

User management and authentication

AlgoSec SaaS uses the Cognito AWS service to manage users and create unique identities for users and federate them with identity providers (AAD). AlgoSec SaaS allocates a designated user pool for each tenant, which is isolated from other tenants. Users of one tenant cannot access other tenants, even if usernames are identical.

AlgoSec SaaS runs OAuth 2.0 authentication against these designated user pools, where each user must specify their tenant ID. The tenant ID indicates which Cognito user pool AlgoSec SaaS should redirect to.

AlgoSec SaaS provides the option of setting Multiple Factor Authentication (MFA) enforcement for each user in the system with secure MFA device setup and routine authentication powered by the AWS Cognito service.

AlgoSec SaaS service allows Single Sign-On (SSO) using external identity providers (IdP) such as Microsoft Azure Active Directory via SAML 2.0 Authentication method.

Prevasio adheres to the Principle of Least Privilege

For our Prevasio solution to provide the best value for our customers, we require certain read-only permissions to the customer cloud account(s).

The read-only permissions required for Prevasio are listed on the relevant web pages. These permissions are designed to align with Zero Trust principles and ensure the security of our customers' critical information. It's important to note that the Prevasio Role has no read access to nonessential but sensitive data, such as customer cloud computing secrets.

Write permissions/roles that Prevasio requests are:

• AWS ecr:SetRepositoryPolicy: This permission allows setting/changing a policy of a container image, detected to be a high risk, so that it could not be pulled from the registry into a workload.

• Azure AcrPush: This role is needed to set "canRead" property to the image metadata.

For more information about permissions and roles required by Prevasio, see:

• AWS

• Azure

• Google Cloud

Data handling

AlgoSec SaaS stores sensitive data, such as passwords and tokens, encrypted using the AWS KMS service. For more details, see https://aws.amazon.com/kms/features/.

Encryption

Data is encrypted both at rest as well as in transit.

Product	Data Encryption at Rest	Data Encryption in Transit
CloudFlow, ObjectFlow, AppViz	All data at rest is encrypted using the AES-256 algorithm.	All data in transit is encrypted using TLS 1.2.
Prevasio	All data at rest uses DynamoDB tables, encrypted with Amazon Managed Keys.

Protocol Internal communication

Each AlgoSec SaaS service communicates with others using a REST API or message queues.

• REST calls run over HTTPS, using server-side authentication.

• Queue messages are handled by AWS SQS and are accessible only for some of the services. Queue messages are not exposed to external calls. Messages to and from the queue are done via HTTPS.

Data not exposed to AlgoSec SaaS

AlgoSec does not access, store, or manage any highly sensitive, US regulated PII data across its SaaS solutions. Specific data contained by each AlgoSec SaaS solution is as follows:

• CloudFlow: CloudFlow contains cloud asset inventory, cloud-native firewall, and security policy data.

• ObjectFlow: ObjectFlow contains object name, content, and their relationships (Object group members).

• AppViz: AppViz contains application connectivity specifications, risk, and vulnerability data. AppViz is out of band and does not process or observe application traffic.

• Prevasio: Prevasio only collects and saves data that is essential for the operation of the cloud security solution for our customers. All user data is sent and stored in a highly secure and encrypted manner to prevent any unauthorized access or data breaches. Furthermore, any data that is collected is anonymous (without any privacy identifiers).

  This data includes:

  • Cloud Asset Metadata: Metadata related to cloud assets and configuration is collected to facilitate the optimal operation of the Prevasio solution and to deliver the intended value to our customers.

  • Docker images:

    • Initial Storage and Analysis: Analyzed layers of container images are initially stored in a tenant-specific cache. This method ensures that the unique data pertaining to each tenant is securely isolated.

    • Shared Caching Mechanism: To enhance efficiency, image layers that are not unique to a single tenant and are utilized by multiple tenants are moved to a communal cache. This shared resource allows for the optimized analysis of container images while maintaining the necessary separation of tenant-specific data.

    • Metadata Storage: For reporting and display purposes, we store only the metadata of analyzed Docker images in an encrypted format within AWS S3 Buckets. This includes crucial information such as the base image details, identified vulnerabilities and malware, and the runtime behavior of the image under isolated conditions.

• Prevasio never stores user passwords and delegates user authentication functions, such as new user registration, login, logout, and password recovery, to AWS Cognito.

• No IPs of the end user registration is stored.

You may choose to connect your AlgoSec SaaS tenant to your on-premises ASMS system*. Even if you do so, your AlgoSaaS tenant is not exposed to the credentials that are used to access the security devices managed by ASMS.

*Benefits to doing this include, for example: for CloudFlow, connectivity check, for ObjectFlow, object sync, FireFlow change requests and more, and for AppViz , object sync, FireFlow change requests, Application Discovery data, connectivity checks, ASMS application-level risks, scanner information sharing and more. Prevasio does not connect directly to ASMS.

Privacy Regulations

Data gathered by AlgoSec SaaS services is almost entirely free of personally identifying information (PII). The only sensitive data that may be found in the data is names, business email addresses, and IP addresses of customer employees. AlgoSec is committed to protecting personal data processed by AlgoSec SaaS . We will not access the content of the information in a way that would allow the service to acquire meaningful information about natural persons, other than in exceptional cases where it is necessary for identifying security threats or investigating suspicious behavior indicative of attack.

Any information stored on or processed by AlgoSec SaaS are secured with state-of-the-art technologies, and AlgoSec operates rigorous technical and organizational security controls.

ASMS-AlgoSec SaaS trust and communication

Protocols

AlgoSec SaaS uses the following communication protocols:

Protocol	CloudFlow, ObjectFlow, AppViz	Prevasio
HTTPS	✔️	✔️	Used for the following types of REST calls: Between services, and with externally available API calls. Port: 443
Kafka	✔️		Encrypted messaging protocol. (no specific network configuration is required)
HTTPS tunneling	✔️		Encrypted TLS over HTTPS tunnel. Used in Kafka proxy. Port: 8082

Regions

AlgoSec deployment locations are hosted in several AWS regions and the default assignment of tenants to AWS regions is based on the customer’s country of origin.

Important: To maintain the security of your ASMS instance, the SaaS product is barred from establishing inbound connections to the ASMS host. SaaS product-ASMS integration communication is always initiated by ASMS.

The following AWS regions are offered:

Region	AWS Deployment location	Prevasio	CloudFlow	ObjectFlow	AppViz
North America	N. Virginia (us-east-1) region	✔	✔	✔	✔
EMEA	Frankfurt (eu-central-1) region		✔	✔	✔
APAC (ANZ)	Sydney (ap-southeast-2) region	✔	✔	✔	✔
Middle East	Bahrain (me-south-1) region		✔

Secured connectivity endpoints

Below is a list of the necessary secured connectivity endpoints for ASMS and SaaS product integration, categorized by region:

Region	FQDNs
North America	kafka1.us.algocare.algosec.com kafka2.us.algocare.algosec.com kafka3.us.algocare.algosec.com
EMEA	kafka1.eu.algocare.algosec.com kafka2.eu.algocare.algosec.com kafka3.eu.algocare.algosec.com
APAC (ANZ)	kafka1.anz.algocare.algosec.com kafka2.anz.algocare.algosec.com kafka3.anz.algocare.algosec.com
Middle East (ME)	kafka1.me.algocare.algosec.com kafka2.me.algocare.algosec.com kafka3.me.algocare.algosec.com

Session timeout

To protect your data, user sessions are automatically logged out after 60 minutes of inactivity.

Log back in to continue where you left off.

Changes to on-premises devices

Some AlgoSec SaaS services have the capability to trigger changes to the security policies and network object definitions within on-premises devices. All such changes like creating or editing network objects or filtering rules are executed by creating change requests in the on-premises AlgoSec FireFlow. The objects and policies are pushed into the on-premises devices by FireFlow which introduces additional controls (like approvers and reviewers) and is audited with the name of the user who initiated the request, approved, and executed it.

Availability

AlgoSec uses commercially reasonable efforts to make AlgoSec SaaS services available with a Monthly Uptime Percentage of at least 99.9%.

Scanning for misconfigurations

We use advanced CSPM and cloud security monitoring tools, plus AlgoSec CloudFlow, to scan across the entire AlgoSec SaaS environment. Detected misconfigurations are handled according to severity.

 

â See also:

• ASMS integration to SaaS services