Trace spans are captured in the runtime after decrypting the request. This means that any sensitive data is available in plain text. This is also the case for logging; however, logging requires an explicit log statement to be coded by the engineer. Additionally, engineers can add arbitrary information to trace spans, which could expose sensitive information.
Collecting sensitive information in trace spans or logging events could expose an organization to a number of risks.
Data Breaches—Unauthorized access to logs or traces can leak sensitive data into the public domain. Employees or contractors may misuse sensitive data for fraudulent activities.
Compliance Violations—Losing control of sensitive information breaches data legislation, e.g., PCI and GDPR. This could lead to significant fines or loss of license to operate.
Privacy—Exposure to personally identifiable information compromises individuals’ privacy and can be used to profile people for hacking attempts.
Attack Surface—Tracing and logging data can provide potential attackers useful information about system architecture and vulnerabilities.
Debugging and Maintenance—Sharing logs and traces during debugging sessions potentially exposes sensitive data to a broader audience that may not be trustworthy. Backups containing traces and logs must be securely managed; dumping them into an insecure AWS S3 bucket is a great way to make the front page.
How Lumigo Secures Data in Traces
Lumigo automatic tracing automatically collects the request and response payload and metadata about the request. This could potentially include sensitive information without the proper security protocols in place. Fortunately, Lumigo has been designed from the ground up with security in mind. We only collect what metadata is essential in trace spans and log events; if it’s not collected, it can not leak.
Lumigo’s automatic code instrumentation is unique in that it collects a very rich metadata set for each trace span. This saves engineers a lot of time and effort, but without the proper setup, this high level of automation could inadvertently collect some sensitive information. This is why each Lumigo instrumentation library has a setting that masks fields matching a regular expression; the default value is.
[“.*pass.*”,”.*key.*”,”.*secret.*”,”.*credential.*”,”.*passphrase.*”,”SessionToken”,”x-amz-security-token”,”Signature”,”Credential”,”Authorization”]
Masking is performed in the runtime to ensure nothing sensitive is sent to the Lumigo backend. Review and adjust the masking regular expression regularly as required to ensure that any sensitive fields are masked. The field is defined by an environment variable, making it easy to update without changing a line of code.
A broader approach may be more appropriate for some areas of your application environment. Again, this setting is applied at the instrumentation library, and by default, it will mask all fields that match the regular expressions for calls to the AWS services: Secrets Manager, SSM, KMS, and STS. This list may be extended to include your domains and/or other external domains, such as payment gateways.
All users of a Lumigo project can see everything inside that project. For large organizations, using different Lumigo projects for different applications or parts of a large application may be appropriate.
Protecting Your Data
Lumigo is committed to security, holding SOC2, ISO 27001, HIPAA, and GDPR certifications. Lumigo is built on AWS, making full use of this market-leading cloud provider’s security and resilience. Lumigo regularly has external reviews and audits of system architecture, operational procedures, and penetration testing. All observability data Lumigo collects is transmitted via TLS v1.2 and encrypted at rest. This means that even if you accidentally collect sensitive information, it’s in safe hands while it resides in the Lumigo backend.