A1. Addendum: AWS Lambda Specificities

Due to AWS Lambda concept of ephemeral containers, pyrasp behavior is slighlty different and has a few limitations compared to other platforms. Specific settings must also be applied in the Lambda function configuration.

Settings

Machine Learning engines are quite resource intensive and require specific configuration settings

Memory

pyrasp requires additional memory to run with the lambda function. This is mostly due to the machine learning engines (and related libraries) used for XSS and SQL Injection detection. If XSS or SQL Injection detections are enabled, an additional 165MB of memory must be added to the Lambda function configuration. (See related AWS Lambda documentation)

Timeout

The pyrasp XSS and SQL Injection machine learning engines are loaded at the Lambda function startup, noticeably increasing the overall startup time (~5 seconds). If XSS or SQL Injection detections are enabled, the Lambda function timeout must be increased by minimum 5 seconds (See related AWS Lambda documentation)

Limitations

Function code size

AWS Lambda total code size (including layers) has a limit of 250MB. PyRASP layer size is 80MB, limiting the rest of the function code to 170MB.

Beacons

Beacon is implemented in a different way for in pyrasp for Lambda functions for 2 reasons: multithreading is not supported and containers are ephemeral.

Consequently beacons are sent in 2 specific cases:

• At agent startup

• When a request is received and the last beacon was sent in a time period greater than the value specified in the BEACON_DELAY parameter

Therefore, on low traffic functions, monitoring may report agents as down while they remain active (but didn't process any request in the BEACON_DELAY timeframe).

Latency

With all security modules enabled, the processing of a request doesn't add noticeable latency. However, when the lambda instance is in "cold" state (meaning the container needs to be restarted), the processing of the request requires restart of the pyrasp module. This adds about 5 seconds latency to the global processing if the request.

Logs

As threads are not supported in AWS Lambda environment, country of source IP is not resolved, this prevents from additional latency in the requests processing. The field in logs is set to an empty string.

Headers content analysis

Request headers being heavily modified by AWS Gateways, their content is not analyzed by pyrasp as it generates high number of false positives.

The PyRASP Layer

Content

The AWS Lambda layer required to run the pyrasp module is about 230 MB size and contains the modules listed below.

• scikit-learn==1.3.0

• numpy==1.*

• requests>=2.32.2

• psutil>=6.0.0

• certifi==2024.6.2

• charset_normalizer==3.3.2

• idna==3.7

• joblib==1.4.2

• scipy==1.13.1

• urllib3==2.2.1

• threadpoolctl==3.5.0

• pyjwt==2.8.0

If some modules are already loaded from another layer, it is possible to rebuild a custom PyRASP layer to lower its size (See related AWS Lambda documentation).

Available Layers

Several layers are made available to allow custom deployment. It is strongly recommended to use the latest version, at least in the beta stage (version 0.x.x). But is up to you...

Name	Version	Archive Size	Layer Size	Comments	ARN
PyRASP-Full-0-8-2	0.8.2	70 MB	227 MB	PyRASP module and dependencies	arn:aws:lambda:eu-west-1:359790667553:layer:PyRASP-Full-0-8-2:2
PyRASP-Standalone-0-8-2	0.8.2	1.4 MB	5 MB	PyRASP module, no dependencies	arn:aws:lambda:eu-west-1:359790667553:layer:PyRASP-Standalone-0-8-2:2
PyRASP-Deps-0-8-2	0.8.2	68 MB	222 MB	PyRASP dependencies	arn:aws:lambda:eu-west-1:359790667553:layer:PyRASP-Deps-0-8-2:2
PyRASP-Full-0-8-1	0.8.1	70 MB	227 MB	PyRASP module and dependencies	arn:aws:lambda:eu-west-1:359790667553:layer:PyRASP-Full-0-8-1:1
PyRASP-Standalone-0-8-1	0.8.1	1.4 MB	5 MB	PyRASP module, no dependencies	arn:aws:lambda:eu-west-1:359790667553:layer:PyRASP-Standalone-0-8-1:1
PyRASP-Deps-0-8-1	0.8.1	68 MB	222 MB	PyRASP dependencies	arn:aws:lambda:eu-west-1:359790667553:layer:PyRASP-Deps-0-8-1:1